CALIDAD DE SOFTWARE

INSTITUTO TECNOLGICO DE AGUASCALIENTES

LA CALIDAD DE SOFTWARE

PRODUCTO DE AO SABATICO

OPCIN 5 LIBRO DE TEXTO

M.C. EN A. HCTOR DE JESS CARLOS PREZ

Aguascalientes, Ags., MAYO 2011

CALIDAD DE SOFTWARE

NDICE

PGINA

UNIDAD I CONCEPTOS BSICOS DE CALIDAD ........................................................ 1 1.1 Definicin de calidad......................................................................................................... 2 1.2 Definicin de calidad de software. .................................................................................. 17 1.3 Quin define la calidad. ................................................................................................... 33 1.4 Importancia de la calidad................................................................................................. 40 1.5 La calidad y el mundo globalizado. ................................................................................. 43 1.6 Calidad de vida. ............................................................................................................... 46 1.7 Calidad total. ................................................................................................................... 51 UNIDAD II ASEGURAMIENTO DE LA CALIDAD DE SOFTWARE (SQA)............. 61 2.1 Relacin de la Ingeniera del software con SQA. ............................................................ 62 2.2 Definicin y propsito del SQA. ..................................................................................... 68 2.3 Problemas que resuelve la SQA. ..................................................................................... 72 2.4 Calidad del software en el ciclo de vida del mismo. ....................................................... 80 2.5 Roles y responsabilidades de los equipos de desarrollo. ................................................. 91 2.6 Habilidades y capacidades del personal del SQA. .......................................................... 98 2.7 Actividades del SQA. .................................................................................................... 101 2.8 Mtodos y herramientas. ............................................................................................... 105 UNIDAD III ESTNDARES DE CALIDAD APLICADOS AL SOFTWARE112 3.1 ISO................................................................................................................................. 113 3.2 SPICE ............................................................................................................................ 120 3.3 CMM ............................................................................................................................. 122 3.3.1 Definicin del modelo. ............................................................................................... 124 3.3.2 Nivel inicial. ............................................................................................................... 124 3.3.3 Nivel repetido. ............................................................................................................ 125 3.3.4 Nivel definido. ............................................................................................................ 126 3.3.5 Nivel administrado. .................................................................................................... 126 3.3.6 Nivel optimizado. ....................................................................................................... 127 UNIDAD IV CALIDAD ENFOCADA AL DESARROLLO DE SOFTWARE 4.1 Qu es la calidad del software. ...................................................................................... 152 4.2 Cmo obtener calidad de software (mtodos, metodologas, estndares). .................... 154 4.3 Cmo controlar la calidad del software. ........................................................................ 156 4.4 Costo de la calidad del software. ................................................................................... 164 4.5 Nomenclatura y certificacin ISO 9001:2000. .............................................................. 169 4.6 La norma ISO/IEC 9126................................................................................................ 175 4.7 Anlisis de factores que determinan la calidad del software. ........................................ 178 4.8 Anlisis del proceso del ciclo de vida del software. ...................................................... 181 4.9 Funciones de evaluacin del software. .......................................................................... 187 BIBLIOGRAFIA..204

CALIDAD DE SOFTWARE

NDICE DE FIGURAS Figura 1. Premio Deming ........................................................................................................... 11 Figura 3. Triloga de Juran ......................................................................................................... 14 Figura 4. Grafica de Pareto ......................................................................................................... 17 Figura 5. Hoja de Verificacin ................................................................................................... 18 Figura 6. Etapas del ciclo de vida del software .......................................................................... 25 Figura 7. Modelo de ciclo de vida del software ......................................................................... 29 Figura 10. ISO 9000 versin 2000. ............................................................................................ 49 Figura 11. Pases con ms alto IDH. .......................................................................................... 60 Figura 12. La calidad de vida desde la subjetividad ................................................................... 61 Figura 13. Ciclo de mejora contina. ......................................................................................... 62 Figura 14. Trabajo en Equipo ..................................................................................................... 63 Figura 15. Proceso de Calidad Total .......................................................................................... 65 Figura 16. Proceso de Solucin de Problemas ........................................................................... 66 Figura 17. Diagrama de Ingeniera de Software. ........................................................................ 75 Figura 18. Ciclo de vida del Software. ....................................................................................... 76 Figura 19. Revisin del Software. .............................................................................................. 82 Figura 20. Errores clsicos. ........................................................................................................ 86 Figura 21. Muestra de un Ciclo de Vida Genrico. .................................................................... 96 Figura 22. Ciclo de Vida Representativo para la Adquisicin de Defensa, segn la US DCDI 5000.2 (Borrador Final de Coordinacin, Abril del 2000). ........................................................ 97 Figura 24. Modelo de Desarrollo Evolutivo. ............................................................................ 102 Figura 25. Modelo de Desarrollo de Prototipado. .................................................................... 103 Figura 26. Modelo Espiral Tipico. ........................................................................................... 104 Figura 27. Modelo Concurrente. .............................................................................................. 105 Figura 28. Designacin de Roles. ............................................................................................. 108 Figura 29. Entorno de trabajo de los Desarrolladores de Software. ......................................... 115 Figura 30. Documentacin. ...................................................................................................... 117 Figura 31. SQA......................................................................................................................... 118 Figura 32. Revisin en busca de errores. .................................................................................. 122 Figura 33................................................................................................................................... 127 Figura 34. Principales Herramientas de Calidad ...................................................................... 129 Figura 35. Sello de ISO. ........................................................................................................... 131 Figura 36: Mapa del alcance de ISO ........................................................................................ 134 Figura 37. ISO en Latinoamrica ............................................................................................. 137

CALIDAD DE SOFTWARE

Figura 38. ISO 9000 ................................................................................................................. 138 Figura 39. ISO 14000 ............................................................................................................... 139 Figura 40. Estndares genricos para sistemas de gestin ...................................................... 140 Figura 41. ISO/IEC 15504........................................................................................................ 141 Figura 42. niveles de SPICE ..................................................................................................... 142 Figura 43. Logo de CMMi ....................................................................................................... 144 Figura 44. Nivel 1 inicial ......................................................................................................... 146 Figura 45. CMMi nivel 2 .......................................................................................................... 147 Figura 46. Documentacin y cumplimiento ............................................................................. 148 Figura 47. CMMi Nivel 3 ......................................................................................................... 149 Figura 48. Medicin y planeacin ............................................................................................ 149 Figura 49. Cuantitavamente gestionado ................................................................................... 150 Figura 50. Procesos del nivel 4................................................................................................ 151 Figura 51. Logo del nivel 5 ...................................................................................................... 151 Figura 52 : Modelo CMM ........................................................................................................ 176 Figura 53: Ejemplo de metodologa de una empresa (proceso de desarrollo de Sw.) .............. 179 Figura 54. Control de calidad del software. ............................................................................. 180 Figura 55. Proceso de Aprendizaje. .......................................................................................... 184 Figura 56. El modelo PEF. ....................................................................................................... 188 Figura 57. El modelo PEF cada categora del costo en porcentaje........................................... 189 Figura 58. Requerimientos de ISO 9001:2000 ........................................................................ 193 Figura 59. ISO 9001:2000 ........................................................................................................ 198 Figura 60. Modelo de Calidad ................................................................................................ 200 Figura 61: Modelo MacCall ..................................................................................................... 203 Figura 62: Modelo Boehm ....................................................................................................... 205 Figura 63: Ciclo de vida en cascada ......................................................................................... 208 Figura 64: Modelo espiral ........................................................................................................ 211 Figura 65 : Ciclo de vida del software...................................................................................... 213 Figura 66. Abstraccin de la Relacin entre Evaluacin y Proceso Software ......................... 215 Figura 67. Modelo en V de Evaluacin de Software................................................................ 216

CALIDAD DE SOFTWARE

UNIDAD I CONCEPTOS BSICOS DE CALIDAD

CALIDAD DE SOFTWARE

1.1 Definicin de calidad. Para poder comprender amplia y totalmente el concepto, es necesario revisarlo desde varios enfoques por lo que primeramente el anlisis partir desde un punto de vista epistemolgico, posteriormente se vern diferentes corrientes que han existido a travs de los tiempos. La palabra cualidad, tiene una historia larga relacionada con los filsofos de la antigedad, la misma proviene del latn "qualitas" y fue empleada por primera vez por Cicern para transmitir este concepto de la lengua griega. Aunque la palabra se difundi rpidamente, su concepto y aplicacin variaron, originando ciertas confusiones. Esta con frecuencia se utiliza como sinnimo de "propiedad". El trmino en condicin de categora, as como su concepcin filosfica, fue introducido en la Filosofa por Aristteles, por ser ste el primero en elaborar un sistema de conceptos universales donde introduce la categora cualidad, la que forma una constante del pensamiento filosfico durante muchos siglos. Posteriormente Kant (1724-1804) la incluye en su sistema de conceptos y Hegel tambin investig esta categora en una forma ms completa, incluyndola en el primer grupo de las categoras del ser. La Filosofa ha continuado su posterior elaboracin, as se encuentran en las enciclopedias filosficas y autores como: Kursanov, Kusinen y otros, que coinciden al declarar su significado como: "el conjunto de rasgos esenciales que hacen que un objeto o fenmeno sea lo que es y no otro". Federico Engels seal: "que con el desarrollo de las ciencias, las definiciones de las categoras se podran completar con ideas ms actuales" (Engels, F. 1961, p.197), por lo que en el campo tcnico concreto de la calidad de la produccin y los servicios esto no ha constituido una excepcin, ya que sta se ha apoyado firmemente en primer lugar en la categora filosfica cualidad y con el de cursar del tiempo se le han agregado otros elementos, teniendo de este modo mltiples significados, llegndose a considerar por diversos especialistas el carcter poli semntico caracterstico en este trmino, donde cada vez ms se ensancha la multidimensionalidad del mismo. Por ejemplo, en la literatura especializada sobre calidad se pueden encontrar las definiciones siguientes: 1- Aptitud para el uso. 2- Satisfaccin del cliente. 3- Conveniencia al uso o conveniencia al propsito. 4- Conformidad con los requisitos. 5- Un producto libre de defectos. 6- Capacidad para satisfacer las expectativas del consumidor. 7- El cumplimiento o superacin de las expectativas del cliente a un costo que le represente valor. 8- Grado a la excelencia. 9- Cumplir necesidades del cliente Lo que ha sucedido en este caso es que estudiosos de las disciplinas: filosofa, economa, comercializacin y direccin han considerado el tema, pero cada grupo lo ha enfocado desde un punto de vista diferente. La filosofa se ha centrado en las cuestiones de definicin; la economa en la maximizacin de ganancias y el equilibrio del mercado; la comercializacin en las determinantes del comportamiento adquisitivo y la satisfaccin del cliente y la direccin operativa, en las prcticas de ingeniera y el control de la fabricacin.

CALIDAD DE SOFTWARE

El resultado ha sido una multitud de aristas de un mismo objeto, partiendo cada una de ellas de un marco de referencia analtico diferente y cada una con su propia terminologa. Es por todo esto que David Garvin ha planteado que pueden identificarse cinco aproximaciones principales de calidad: 1- La trascendente de la filosofa 2- La basada en el producto 3- La basada en el usuario 4- La basada en la fabricacin 5- La basada en el valor. (Garving, D.A. 1992, p.154) Se puede afirmar que casi todas las definiciones existentes de calidad se sitan en algunas de las aproximaciones antes enumeradas. Todo esto indica el error que se comete al absolutizar y tener confianza en una sola definicin, lo que provoca inevitablemente una fuente frecuente de problemas. Es necesario entonces desplazar activamente la aproximacin a la calidad a medida que los productos pasan del mercado al diseo y de ste a la fabricacin y luego al servicio de posventa en interrelacin con los aspectos de la gestin estratgica de la calidad. Las caractersticas que connotan la calidad deben identificarse primero mediante una investigacin de mercados (aproximacin basada en el usuario); estas caractersticas deben traducirse entonces en atributos identificables del producto (aproximacin basada en el producto); y el proceso de fabricacin debe organizarse para asegurar que los productos cumplan exactamente con las especificaciones (aproximacin basada en la fabricacin). Un producto que ignore cualquiera de estos pasos no se traducir en un producto de buena calidad. Ya se ha expuesto cmo el hecho de considerar una aproximacin especfica obviando las restantes implica un anlisis vago e impreciso al tratar de describir los elementos bsicos de la calidad de un producto, pues como aqu se quiere expresar debido a la naturaleza holstica de la misma se necesitan anlisis integrales. Teniendo en cuenta los aspectos antes mencionados se observa, no obstante a lo analizado, que en esta rama del saber en pocas recientes algunos autores de reconocido prestigio y la Organizacin Internacional de Normalizacin (ISO) han planteado definiciones bastante abarcadoras sin cometer el error de absolutizar algunas de las aproximaciones vistas anteriormente. Por ejemplo, el japons Keiichi Yamaguchi considera que: "la buena calidad no solamente es la calidad de los productos, que es la calidad interpretada de manera estrecha (cualidades), sino significa tambin, el volumen de produccin que, cuando se quiere, se obtiene la cantidad necesaria y al costo ms bajo posible para que tenga un buen precio, o por lo menos un precio razonable, y adems, un servicio de posventa, rpido y bueno para la tranquilidad del comprador, incluyendo todo lo mencionado anteriormente de que su carcter total sea el ms propicio" (Yamaguchi, K. 1989, p.33).

CALIDAD DE SOFTWARE

Esta definicin de Yamaguchi incluye algunas de las aproximaciones anteriormente analizadas (la del producto, la del valor y la del usuario); adems, agrega nuevos elementos que se deben considerar en la calidad como: el volumen de produccin y la oportunidad. Por otro lado, Juran ha sealado lo siguiente: la palabra calidad tiene mltiples significados. Dos son los ms importantes: 1. Calidad es el conjunto de caractersticas de un producto que satisfacen las necesidades de los clientes y, en consecuencia, hacen satisfactorio al producto. 2. La calidad consiste en no tener deficiencias (Juran, J.M. 1993, p. 2.1 y 2.2) En el primer significado, una mayor calidad capacita a las empresas para: aumentar la satisfaccin del cliente, hacer productos vendibles, ser competitivos, incrementar la participacin en el mercado, proporcionar ingresos por ventas y obtener buenos precios. En este caso, el efecto principal se obtiene en las ventas y, generalmente, la mayor calidad cuesta ms. En el segundo significado una mayor calidad capacita a la empresa para reducir los ndices de error, reducir los reprocesos, reducir los fallos posventa y gastos de garanta, reducir la insatisfaccin del cliente, acortar el tiempo para introducir nuevos productos en el mercado, aumentar los rendimientos y la capacidad y mejorar los plazos de entrega. De esta forma, el efecto principal se refleja en los costos y generalmente la mayor calidad cuesta menos. Es necesario tener en cuenta simultneamente estos dos conceptos dados por Juran para cualquier anlisis de la calidad y ambos abarcan la aproximacin del usuario, la del valor y la de la fabricacin. Teniendo en cuenta todos los anlisis anteriores se puede afirmar que en el campo de la calidad, la identificacin de conceptos universales ha seguido un curso errtico. La bsqueda de stos y de los principios universales es un fenmeno relativamente reciente. En consecuencia, la normalizacin de la terminologa est an en sus inicios. Muchas palabras y frases son utilizadas con significados especiales que difieren de los que figuran en el diccionario. Al respecto Juran ha planteado que existen serios obstculos antepuestos a la normalizacin: las diferencias de argot e historia cultural de las distintas industrias, los rpidamente cambiantes ingredientes de aptitud para el uso y los deliberados esfuerzos humanos para crear y utilizar una terminologa que asegure ciertas ventajas para sus organizaciones y para ellos mismos. (Juran, J.M. 1993, p. 2.13) Debido a estas dificultades se cre en la ISO el Comit Tcnico nmero 176, con el objetivo de elaborar un conjunto de normas internacionales y lineamientos sobre gestin de la calidad. As surge en el ao 1986 la norma ISO 8402:1986. Calidad. Vocabulario, donde se expresa el siguiente concepto de calidad: "conjunto de propiedades y caractersticas de un producto o servicio que le confieren su aptitud para satisfacer necesidades expresadas o implcitas (NC ISO 8402:1986, p.2).

CALIDAD DE SOFTWARE

Esta propia norma ha sido objeto posteriormente de revisiones y en el ao 1994 surge la norma ISO 8402:1994. Gestin de la Calidad y Aseguramiento de la Calidad. Vocabulario, donde se plantea la siguiente definicin de calidad: "Totalidad de las caractersticas de una entidad que influyen en su capacidad para satisfacer necesidades expresadas o implcitas" (NC ISO 8402:1994, p.2). Esta nueva definicin tiene un mayor alcance en el sentido de que no se circunscribe a productos o servicios como la anterior y en su lugar incorpora el trmino entidad, el cual en la propia norma se define como: " Lo que se puede describir y considerar individualmente" (NC ISO 8402:1994, p.3) y puede ser, por ejemplo: una actividad o un proceso, un producto, una organizacin, un sistema o una persona, o alguna combinacin de los anteriores. En el ao 1999 estas normas que han adquirido reputacin a nivel mundial como la base para establecer Sistemas de Gestin de Calidad fueron objeto tambin de revisin y es en la norma ISO 9000:2000 donde aparece la siguiente definicin de calidad: grado en el que un conjunto de caractersticas inherentes cumple con los requisitos (Norma ISO 9000:2000, p.8). En la norma ISO 9004:2000 aparecen normalizados por primera vez los principios para la gestin de la calidad: enfoque al cliente, liderazgo, participacin del personal, enfoque basado en procesos, enfoque de sistema para la gestin, mejora continua, enfoque basado en hechos para la toma de decisin, relaciones mutuamente beneficiosas con el proveedor (Norma ISO 9004:2000, p.5). La doctora Michelena opina que la definicin y aplicacin de la calidad depende del contexto y momento en que se observa y analiza, y la misma considera que la calidad es el conjunto de atributos o propiedades de un producto o servicio que satisface los requisitos o necesidades de los clientes y que permiten emitir un juicio de valor acerca de l, dentro de un ambiente organizacional comprometido con la mejora continua, la eficacia y la efectividad (Michelena, E. 2000, p.7). As, es importante tener conciencia de que hay conceptos diversos de calidad, autores con distintas definiciones abordan en ellas variadas dimensiones, de manera que si se multiplican los conceptos por los autores y tambin por las dimensiones, se tendr idea de la verdadera complejidad del asunto de la calidad, por lo que ahora se vera algunos de esos autores que a travs de la historia han generado alguna corriente filosfica o de trabajo. Las definiciones de calidad estn ordenadas por categoras de enfoque. 1. Basadas en la fabricacin: "Calidad (significa) conformidad con los requisitos" Philip B. Crosby. "Calidad es la medida en que un producto especfico se ajusta a un diseo o especificacin" Harold L. Gilmore. La capacidad de cumplir con las necesidades y expectativas del cliente. Feigenbaum [2]

2. Basadas en el cliente: "Calidad es aptitud para el uso". J. M. Juran. "Calidad total es liderazgo de la marca en sus resultados al satisfacer los requisitos del cliente haciendo la primera vez bien lo que haya que hacer". Westinghouse.

CALIDAD DE SOFTWARE

"Calidad es satisfacer las expectativas del cliente. El Proceso de Mejora de la Calidad es un conjunto de principios, polticas, estructuras de apoyo y prcticas destinadas a mejorar continuamente la eficiencia y la eficacia de nuestro estilo de vida". AT & T "Se logra la satisfaccin del cliente al vender mercancas que no se devuelven a un cliente que s vuelve". Stanley Marcus. Disear, producir y ofrecer un buen servicio que sea til, lo mas econmico posible, y siempre satisfactorio para el cliente. Ishikawa. [2]

3. Basado en el producto: "Las diferencias en calidad son equivalentes a las diferencias en la cantidad de algn ingrediente o atributo deseado". Lawrence Abbott. "La calidad se refiere a la cantidad del atributo no apreciado contenido en cada unidad del atributo apreciado". Keith B. Leffler. La mnima perdida que un producto o servicio ocasiona a la sociedad desde que es entregado. Taguchy [2] 4. Basado en el valor: "Calidad es el grado de excelencia a un precio aceptable y el control de la variabilidad a un costo aceptable". Robert A. Broh. "Calidad significa lo mejor para ciertas condiciones del cliente. Estas condiciones son: a) el uso actual y b) el precio de venta del producto". Armand V. Feigenbaum. Grado predecible de uniformidad y fiabilidad a bajo costo y adecuado a las necesidades del mercado. Deming [2] La calidad significa aportar valor al cliente, esto es, ofrecer unas condiciones de uso del producto o servicio superiores a las que el cliente espera recibir y a un precio accesible [1] 5. Trascendente: "Calidad no es ni materia ni espritu, sino una tercera entidad independiente de las otras dos..., aun cuando la calidad no pueda definirse, usted sabe bien qu es". Robert Pirsing. "Una condicin de excelencia que implica una buena calidad a diferencia de la baja calidad... Calidad es lograr o alcanzar el ms alto nivel en vez de contentarse con lo chapucero o lo fraudulento". Barbara W. Tuchman. Ahora revisando a algunos autores clsicos y de renombre: Edwards W. Deming Durante la Segunda Guerra Mundial, Deming enseo a los tcnicos e ingenieros americanos estadsticas que pudieran mejorar la calidad de los materiales de guerra. Fue este trabajo el que atrajo la atencin de los japoneses. Adems trabajo en la Universidad de Stanford capacitando a cientos de ingenieros militares en el control estadstico del proceso. Entre 1942 y 1945 Deming fue invitado a Japn por el comando de ocupacin de los Estados Unidos, en donde tuvo un papel importante en cuanto la evaluacin de calidad. En Julio de 1950, Deming se reuni con la Unin quien lo present con los administradores principales de las compaas japonesas. Durante los prximos treinta aos, Deming dedicara

10

CALIDAD DE SOFTWARE

su tiempo y esfuerzo a la enseanza de los Japoneses y "transformo su reputacin en la produccin de un motivo de risa a un motivo de admiracin y elogio". Por que fue Deming un xito en Japn y desconocido en Amrica? Deming fue invitado a Japn cuando su industria y economa se encontraba en crisis. Ellos escucharon, cambiaron su forma de pensar, su estilo de administrar, su trato a los empleados y tomaron su tiempo. Al seguir la filosofa de Deming, los japoneses giraron su economa y productividad por completo para convertirse en los lderes del mercado mundial. Tan impresionados por este cambio, el Emperador Horohito condecor a Deming con la Medalla del Tesoro Sagrado de Japn en su Segundo Grado. La mencin deca "El pueblo de Japn atribuyen el renacimiento de la industria Japonesa y su xito mundial a Deming". No fue sino hasta la transmisin de un documental por NBC en Junio de 1980 detallando el xito industrial de Japn que las corporaciones Americanas prestaron atencin. Enfrentados a una produccin decadente y costos incrementados, los Presidentes de las corporaciones comenzaron a consultar con Deming acerca de negocios. Encontraron que las soluciones rpidas y fciles tpicas de las corporaciones Americanas no funcionaban. Los principios de Deming establecan que mediante el uso de mediciones estadsticas, una compaa debera ser capaz de graficar como un sistema en particular estaba funcionando para luego desarrollar maneras para mejorar dicho sistema. A travs de un proceso de transformacin en avance, y siguiendo los Catorce Puntos y Siete Pecados Mortales, las compaas estaran en posicin de mantenerse a la par con los constantes cambios del entorno econmico. Edwards W. Deming revolucion la gestin en las empresas de fabricacin y de servicios al insistir en que la alta direccin es responsable de la mejora continua de la calidad; conocido internacionalmente como consultor, cuyos trabajos introdujeron en la industria japonesa los nuevos principios de la gestin y revolucionaron su calidad y productividad. En agradecimiento a su contribucin a la economa japonesa, la Unin de Ciencia e Ingeniera Japonesa (JUSE) instituy el Premio Anual Deming (Figura 1) para las aportaciones a la calidad y fiabilidad de los productos.

Figura 1. Premio Deming

11

CALIDAD DE SOFTWARE

Sus aportaciones revolucionaron el estilo de direccin americano y su participacin en un programa de televisin que se llam "Si Japn puede, porque nosotros no". Y sus seminarios atrajeron la atencin de todos los directivos de empresas. Las teoras de Deming se obtienen de observaciones directas, de ah la certeza de su conocimiento. Phillip B. Crosby l implementa la palabra de la PREVENCIN como una palabra clave en la definicin de la calidad total. Ya que l paradigma que Crosby quiere eliminar es el de que la calidad se da por medio de inspeccin, de pruebas, y de revisiones. Esto nos originaria perdidas tanto de tiempo como de materiales, ya que con la mentalidad de inspeccin esto esta preparando al personal a fallar, as que hay que prevenir y no corregir. Crosby propone 4 pilares que debe incluir un programa corporativo de la calidad, los cuales son: 1. Participacin y actitud de la administracin. La administracin debe comenzar tomando la actitud que desea implementar en la organizacin, ya que como se dice, las escaleras se barren de arriba hacia abajo y si el personal no ve que todos los niveles tienen la misma responsabilidad en cuanto a la actitud, este no se vera motivado. 2. Administracin profesional de la calidad. Deber capacitarse a todos los integrantes de la organizacin, de esta manera todos hablaran el mismo idioma y pueden entender de la misma manera cada programa de calidad. 3. Programas originales. Aqu se presentan los 14 pasos de Crosby, tambin conocidos como los 14 pasos de la administracin de la calidad. 1. Compromiso en la direccin. 2. Equipos de mejoramiento de la calidad. 3. Medicin de la calidad. 4. Evaluacin del costo de la calidad (Figura 2). 5. Concientizacin de la calidad. 6. Equipos de accin correctiva. 7. Comits de accin. 8. Capacitacin. 9. Da cero defecto. 10. Establecimiento de metas. 11. Eliminacin de la causa de error. 12. Reconocimiento. 13. Consejo de calidad. 14. Repetir el proceso de mejoramiento de calidad.

12

CALIDAD DE SOFTWARE

Figura 2. Estructura de costos de la calidad.

4. Reconocimiento. Debemos de apoyar al personal que se esforz de manera sobresaliente en el cumplimiento del programa de calidad. Esto podemos hacerlo mediante un reconocimiento durante cierto periodo de tiempo en el cual el trabajador haya logrado alguna accin nica o distinta de los dems a favor de la organizacin y con miras a contribuir en el programa de calidad. Feigenbaum. Sostiene que los mtodos individuales son parte de un programa de control. Feigenbaum, afirma que el decir calidad no significa mejor sino el mejor servicio y precio para el cliente, al igual que la palabra control que representa una herramienta de la administracin y tiene 4 pasos: -Definir las caractersticas de calidad que son importantes. -Establecer estndares. -Actuar cuando los estndares se exceden. -Mejorar los estndares de calidad. Es necesario establecer controles muy eficaces para enfrentar los factores que afectan la calidad de los productos: -Control de nuevos diseos. -Control de recepcin de materiales. -Control del producto. -Estudios especiales de proceso. Costos de calidad Estos costos se pueden definir como lo que una empresa necesita invertir de cierta forma para brindar al cliente un producto de calidad. De acuerdo con su origen se dividen en: Costos de prevencin. Son aquellos en los que se incurre para evitar fallas, y los costos que estas puedan originar, prevenir ms costos. Y se manejan conceptos como: costos de planeacin, entrenamiento, revisin de nuevos productos, reportes de calidad, inversiones en proyectos de mejora, entre otros.

13

CALIDAD DE SOFTWARE

Costos de reevaluacin. Estos se llevan a cabo al medir las condiciones del producto en todas sus etapas de produccin. Se consideran algunos conceptos como: inspeccin de materias primas, reevaluacin de inventarios, inspeccin y pruebas del proceso y producto. Costos de fallas internas. Son los generados durante la operacin hasta antes de que el producto sea embarcado, por ejemplo: desperdicios, reproceso, pruebas, fallas de equipo, y prdidas por rendimientos. Costos de fallas externas. Son los costos que se generan cuando el producto ya fue embarcado, por ejemplo: ajuste de precio por reclamaciones, retorno de productos, descuentos y cargos por garanta.

Joseph M. Juran

Nacido en Estados Unidos, public su primer libro en 1951, el manual de Control de Calidad. Tal como Deming fue invitado a Japn para dar seminarios y conferencias a altos ejecutivos. Sus conferencias tienen un fuerte contenido administrativo, y se enfocan a la planeacin, organizacin y responsabilidades de la administracin en la calidad, y en la necesidad que tienen de establecer metas y objetivos para la mejora. Enfatiz que el control de la calidad debe realizarse como una parte integral del control administrativo. Algunos de sus principios son su definicin de la calidad de un producto como adecuacin al uso; su triloga de la calidad (Figura 3), consistente en planeacin de la calidad, control de calidad y mejora de la calidad; el concepto de autocontrol y la secuencia universal de mejoramiento.

Figura 3. Triloga de Juran

14

CALIDAD DE SOFTWARE

Todas las instituciones humanas han tenido la presentacin de productos o servicios para seres humanos. La relacin que se da es constructiva solo cuando se respeta a las necesidades de precio, de fecha de entrega y adecuacin al uso. Solo cuando se han cumplido las necesidades del cliente se dice que el producto o servicio es vendible. La adecuacin al uso implica todas las caractersticas de un producto que el usuario reconoce que lo van a beneficiar. Esta adecuacin siempre ser determinada por el usuario o comprador, y nunca por el vendedor, o el fabricante. La calidad de diseo nos asegura que el producto va a satisfacer las necesidades del usuario y que su diseo contemple el uso que le va a dar. Para poder hacer esto, primero se tiene que llevar a cabo una completa investigacin del mercado, para definir las caractersticas del producto y las necesidades del cliente. La calidad de conformancia tiene que ver con el grado en que el producto o servicio se apegue a las caractersticas planeadas y que se cumplan las especificaciones de proceso y de diseo. Para poder lograr esto, debe contarse con la tecnologa, administracin y mano de obra adecuada. La disponibilidad es otro factor de la adecuacin de la calidad al uso, este se define durante el uso del producto, y tiene que ver con el desempeo que tenga y su vida til. Si usamos un artculo y falla a la semana entonces este no ser disponible aunque hubiera sido la mejor opcin en el momento de la compra. El artculo debe de servir de manera continua al usuario. El servicio tcnico, por ultimo este define la parte de la calidad que tiene que ver con el factor humano de la compaa. El servicio de soporte tcnico, debe estar latamente capacitado y actuar de manera inmediata para poder causar al cliente la sensacin de que esta en buenas manos. La triloga de la calidad. El mejoramiento de la calidad se compone de tres tipos de acciones, segn Juran: * Control de calidad. * Mejora de nivel o cambio significativo. * Planeacin de la calidad.

Cuando ya existe un proceso se empieza con acciones de control y cuando el proceso es nuevo, con las de planeacin. Acciones de control: Para poder mejorar un proceso necesitamos primero tenerlo bajo control. Acciones de mejora de nivel: Estas van encaminadas a cambiar el proceso para que nos permita alcanzar mejores niveles promedio de calidad, y para esto se deben de atacar las causas comunes ms importantes. Acciones de planeacin de calidad: aqu se trabaja para integrar todos los cambios y nuevos diseos de forma permanente a la operacin que normalmente llevamos del proceso, pero

15

CALIDAD DE SOFTWARE

siempre buscando asegurar no perder lo ganado. Estos cambios pueden ser para satisfacer los nuevos requerimientos que haga el mercado. Planeacin de la calidad Hay que identificar quien es el cliente. Determinar sus necesidades (de los clientes). El mapa de la planeacin de la calidad consiste en los siguientes pasos: Traducir las necesidades al lenguaje de la empresa. Desarrollar un producto que pueda responder a esas necesidades. Optimizar el producto, de manera que cumpla con la empresa y con el cliente. Desarrollar un proceso que pueda producir el producto. Optimizar dicho proceso. Probar que ese proceso pueda producir el producto en condiciones normales de operacin. Transferir el proceso a operacin.

Kaoru Ishikawa. El gur de la calidad Kaoru Ishikawa, naci en la ciudad de Tokio, Japn en el ao de 1915, es graduado de la Universidad de Tokio. Ishikawa es hoy conocido como uno de los ms famosos gurs de la calidad mundial, y en este trabajo profundizare todos sus logros y las herramientas que a l le dieron tanto reconocimiento. La teora de Ishikawa era manufacturar a bajo costo. Dentro de su filosofa de calidad el dice que la calidad debe ser una revolucin de la gerencia. El control de calidad es desarrollar, disear, manufacturar y mantener un producto de calidad. Hay algunas indicaciones que nos hacen pensar que los crculos de calidad pudieron haberse utilizado en los Estados Unidos en los aos 50, pero a pesar de esto se atribuye al profesor Ishikawa ser pionero del movimiento de los crculos. Al igual que otros, Ishikawa puso especial atencin a los mtodos estadsticos y prcticos para la industria. Prcticamente su trabajo se basa en la recopilacin de datos. Una valiosa aportacin de Ishikawa es el diagrama causa- efecto que lleva tambin su nombre (o de pescado). El diagrama causa-efecto es utilizado como una herramienta que sirve para encontrar, seleccionar y documentarse sobre las causas de variacin de calidad en la produccin. De acuerdo con Ishikawa el control de calidad en Japn, tiene una caracterstica muy peculiar, que es la participacin de todos, desde los ms altos directivos hasta los empleados de ms bajo nivel jerrquico. El doctor Ishikawa expuso que el movimiento de calidad deba de imponerse y mostrarse ante toda la empresa, a la calidad del servicio, a la venta, a lo administrativo, etc. Y los efectos que causa son: -El producto empieza a subir de calidad, y cada vez tiene menos defectos. -Los productos son ms confiables.

16

CALIDAD DE SOFTWARE

-Los costos bajan. -Aumentan los niveles de produccin, de forma que se puedan elaborar programas ms racionales. -Hay menos desperdicios y se reprocesa en menor cantidad. -Se establece una tcnica mejorada. -Se disminuyen las inspecciones y pruebas. -Los contratos entre vendedor y comprador se hacen ms racionales. -Crecen las ventas. -Los departamentos mejoran su relacin entre ellos. -Se disminuye la cantidad de reportes falsos. -Se discute en un ambiente de madurez y democracia. -Las juntas son ms tranquilas y clamadas. -Se vuelven ms racionales las reparaciones y las instalaciones. -Las relaciones humanas mejoran. La naturaleza de estos Crculos de Calidad, vara junto con sus objetivos segn la empresa de que se trate. Las metas de los Crculos de Calidad son: a) Que la empresa se desarrolle y mejore. b) Contribuir a que los trabajadores se sientan satisfechos mediante talleres, y respetar las relaciones humanas. c) Descubrir en cada empleado sus capacidades, para mejorar su potencial. En los crculos de calidad se les enseaban 7 herramientas a todos: 1. La Grfica de Pareto (figura 4). 2. El diagrama de causa-efecto. 3. La estratificacin. 4. La hoja de verificacin (figura 5). 5. El histograma. 6. El diagrama de dispersin. 7. La Grfica de Control de Shewhart.

Figura 4. Grafica de Pareto

17

CALIDAD DE SOFTWARE

Figura 5. Hoja de Verificacin

Todos los que pertenezcan a un crculo, reciben la capacitacin adecuada en las reas de control y mejora. En ciertas ocasiones el mismo crculo piensa en las soluciones y puede presionar a la alta gerencia a llevarlo a cabo, aunque esta siempre esta dispuesta a escuchar y dialogar. Estos crculos son muy recomendados en Japn, debido al xito que han tenido en la mayora de las empresas donde se han aplicado, pero se debe de tener cuidado al adaptarlos, debido a que cada organizacin es distinta y tiene necesidades muy variadas, una mala adaptacin puede hacer que fracase el crculo.

Genichi Taguchi Desarroll sus propios mtodos estadsticos al trabajar en una compaa de telfonos, lo aplic al incremento de la productividad y calidad en la industria. Cre el concepto de diseo robusto, este exceda sus expectativas de calidad, para as lograr la satisfaccin del cliente. Cada vez que se disea un producto, se hace pensando en que va a cumplir con las necesidades de los clientes, pero siempre dentro de un cierto estndar, a esto se le llama calidad aceptable, y as cuando el cliente no tiene otra opcin mas que comprar, pues a la empresa le sale mas barato reponer algunos artculos defectuosos, que no producirlos. Pero no siempre ser as, por que en un tiempo la gente desconfiara de la empresa y se irn alejando los clientes. El tipo de diseo que Taguchi propone es que se haga mayor nfasis en las necesidades que le interesan al consumidor y que a su vez, se ahorre dinero en las que no le interesen, as rebasara las expectativas que el cliente tiene del producto. Asegura que es ms econmico hacer un diseo robusto que pagar los controles de calidad y reponer las fallas. Al hacer un diseo robusto de determinado producto maximizamos la posibilidad de xito en el mercado. Y aunque esta estrategia parece costosa, en realidad no lo es, por que a la vez que gastamos en excedernos en las caractersticas que de verdad le interesan al consumidor, ahorramos en las que no les dan importancia.

18

CALIDAD DE SOFTWARE

Taguchi trat de orientar a los productores a que redujeran las variaciones en la calidad. Para poder revirtuar esta perdida, se utiliza una ecuacin cuadrtica que se ajusta a los datos de costos y desempeo del producto. Conforme el desempeo del producto se vaya alejando la ecuacin va aumentando de valor y se incrementa el costo de calidad para la sociedad. Por ultimo se hace referencia a algunas teoras recientes de la calidad: Shigeo Shingo

Es tal vez uno de los menos conocidos, pero su impacto en la industria japonesa, incluso en la estadounidense ha sido muy grande. Junto con Taiichi Ohno, desarrollo un conjunto de innovaciones llamadas el sistema de produccin de Toyota. En cierta compaa, Shingo fue responsable de reducir el tiempo de ensamble de cascos de cuatro meses a dos meses. Sus contribuciones son caracterizadas por que dio un giro enorme a la administracin, haciendo varios cambios en ella, ya que sus tcnicas eran todo lo contrario a las tradicionales. Los que estudian sus mtodos de una forma superficial, piensan que sus teoras no son muy correctas, pero la mejor prueba de que si lo son, es el nombre TOYOTA que respalda a una de las ms grandes empresas automotrices a cargo de Shingo. El sistema de produccin de Toyota y el justo a tiempo: stos sistema tienen una filosofa de cero inventarios en proceso. Este no solo es un sistema, sino que es un conjunto de sistemas que nos permiten llegar a un determinado nivel de produccin que nos permita cumplir el justo a tiempo. Hay varias ventajas que nos proporciona el sistema de cero inventarios: Los defectos de la produccin se reducen al 0 % por que al momento en que se presenta uno, la produccin se detiene, hasta eliminar sus causas. Al hacer esta reduccin de cero defectos, se reducen tambin los desperdicios y otros materiales consumibles quedan tambin en ceros. El espacio de las fbricas tambin se ve beneficiado, ya que no tiene necesidad de almacenar productos defectuosos ni materiales desviados. Este sistema es confiable en cuanto a la entrega justo a tiempo, ya que se obliga a trabajar sin errores. El sistema de justo a tiempo, es muy difcil y constituye un reto que solo puede ser aplicable en las empresas que han resuelto todos sus problemas y pueden dominar los imprevistos que se les presenten.

19

CALIDAD DE SOFTWARE

Poka - Yoke Este tambin conocido como a prueba de errores, o como cero defectos. Consiste en que al momento de que se detecta algn defecto en el proceso, este se detiene y se investigan todas las causas y las posibles causas futuras, no se utilizan las estadsticas ya que es 100% inspeccin, donde pieza por pieza se verifica que no tenga ningn defecto. Hay dos caractersticas muy importantes para el proceso Toyota, que son el orden y la limpieza, por que es ms difcil trabajas bien, cuando el lugar de trabajo esta desordenado y sucio, as que debemos de ver que es necesario y que no, poner un lugar para cada cosa, y siempre mantener ordenado, y hacer de esto un habito para que siempre este limpio y ordenado. Existen varios niveles de prevencin Poka Yoke, estos se pueden poner en prctica en diferentes niveles. Nivel cero. Este es un nivel en donde los trabajadores nunca saben cuando han contribuido al xito de la empresa, pero por lo general siempre se les informa cuando su trabajo esta mal, casi no recibe informacin, y solo se establecen estndares que ellos deben de seguir. Nivel 1. Aqu por el contrario se informa a los trabajadores cada vez que su trabajo ayuda a lograr las actividades de control, para que cada uno vea que su desempeo es necesario. Nivel 2. En este nivel se informa al trabajador de los estndares y mtodos para que cada uno pueda identificarlos en el momento en que ocurren, as como una lista de defectos que pudieran surgir. Nivel 3. Hacemos estndares dentro de su propio ambiente de trabajo, con sus propias herramientas y materiales, se les explica cual es la mejor manera de hacer las cosas, de una forma fcil de comprender. Nivel 4. Instalar alarmas es muy buena idea, para hacer ms rpido el tiempo que tarda un trabajador en darse cuenta que algo anda fuera de control, as como encenderse una luz cuando los insumos no sean suficientes o cuando alguien necesite ayuda. Nivel 5. Un sistema de control visual nos ayuda a eliminar cualquier tipo de anomala que se pudiera presentar, y as se descubren las causas y se busca la manera de impedir que se repitan. Nivel 6. Este nivel es a prueba de errores, se verifican los productos al 100% los productos y se garantiza que la anomala no se vuelva a repetir.

Jan Carlzon Es conocido como uno de los especialistas en calidad ms importantes en el rea de servicios.

20

CALIDAD DE SOFTWARE

Carlzon es el creador de momentos de la verdad, a partir de este desarrollo un programa de administracin de la calidad, para empresas especialmente de servicios. Este sistema se trata de momentos en que los empleados de una organizacin tienen con sus clientes que duran aproximadamente 15 segundos, y son utilizados para entregar un servicio. La empresa confa en que el empleado lograr causarle una buena impresin al cliente, y toda la empresa se pone en riesgo, y depende de las habilidades que tenga el empleado, para con el cliente. La estrategia de la calidad de Carlzon, se trata de documentar de todos los pasos que el cliente debe seguir para recibir el servicio, se le llama el ciclo del servicio. Una persona sin informacin no es capaz de asumir responsabilidades, una persona con informacin tal vez no sea de gran ayuda, pero sirve para asumir responsabilidades. No importa que tan grande o importante sea la empresa, todo depender de la forma en que el empleado que se encuentra frente al cliente acte, ya sea libre, o con carisma, o todo lo contrario. La pirmide invertida. Segn Carlzon, es necesario que todos los empleados sientan que son muy importantes dentro de la empresa, as que se considera a la motivacin una pieza fundamental para lograr la calidad a travs de la gente. Si damos libertades a otras personas para tomar decisiones, saldrn a flote recursos en las personas que nunca hubiramos conocido, y siempre estaran ocultos. A los clientes debemos de tratarlos de una forma distinta, por que a nadie le gusta ser tratado como uno mas, sino como alguien distinto, un cliente nico diferente a todos los dems, por ese el empleado que se encuentre en algn mostrador, deber de olvidarse de las polticas de que todos los clientes son iguales, por que l mejor que nadie, sabr que cada uno es distinto y tienen distintas necesidades. Harrington H. James Es un ejecutivo de calidad de IBM. Elaboro documentos describiendo el progreso de la revolucin de la calidad de IBM. En 1987 escribi un libro "The improvement process", donde habla de su experiencia y los esfuerzos de otras organizaciones. Dice que el unido enfoque que tendr efecto en la calidad es aquel que la convierta en la vida predominante de la empresa. La calidad no es solo un estilo de administracin sino tan bien una serie de tcnicos o motivacin hacia el trabajador. Insiste en la "propiedad" de los procesos por parte de la administracin cruzando barreras departamentales.

William E. Conway

21

CALIDAD DE SOFTWARE

El habla de la "forma correcta de administrar" y de un "nuevo sistema de administracin" en lugar de la mejora de la calidad. Su experiencia y su perspectiva ms amplia desde el punto de vista de la administracin se reflejan en todo su trabajo. Esta de acuerdo con los gurs en que el problema mayor es que la alta direccin no esta convencida de que la calidad aumenta la productividad y disminuye los costos. Sin embargo, cambien reconoce que la "administracin quiere y necesita una ayuda real, no una critica destructiva". Conway centra su atencin en el sistema de administracin como el medio de lograr una mejora continua, ms bien que sobre funciones especficas o problemas de calidad. Conway defiende los mtodos estadsticos. El dice que la administracin contempla la calidad en un sentido general. El dice:"el uso de la estadstica es una forma con sentido comn de llegar a cosas especificas", despus aade: "la estadstica no soluciona problemas. Identifica donde se encuentran los problemas y le seala soluciones a los gerentes y a las personas. El contempla las tcnicas estadsticas como herramientas de la administracin e insiste en el uso de herramientas estadsticas sencillas que pueda aprender cualquiera con rapidez, ms bien que las tcnicas complejas. Las herramientas sencillas pueden ayudar a solucionar el 85 % de los problemas .Las herramientas bsicas para la mejora de la calidad son: -Habilidades de relaciones humanas. -Encuestas estadsticos. -Tcnicas estadsticas sencillas. -Control estadstica del proceso. -Utilizacin de la imaginacin. -Ingeniera Industrial. Richard J. Schonberger La administracin de las estrategias de la calidad es un elemento central de sus escritos. Schonberger afirma que la capacidad para responder a las cambiantes necesidades del mercado es un tema constante para los negocios modernos. Proporciona lo que el denomina una "agenda de accin para la excelencia en la fabricacin" de diecisiete partidas: 1) Llegue a conocer al consumidor. 2) Rebaje la producan en proceso. 3) Rebaje los tiempos de flujos. 4) Rebaje los tiempos de preparacin y de cambios. 5) Aumente la frecuencia de hacer/entregar para cada articulo requerido. 6) Rebaje el nmero de proveedores a unos pocos buenos. 7) Rebaje la cantidad de nmeros de piezas. 8) Haga que sea fcil fabricar el producto sin errores. 9) Arregle el lugar de trabajo para eliminar tiempos de bsquedas. 10) Realice un entrenamiento cruzado para dominar ms de una tarea. 11) Registre y conserve en el lugar de trabajo datos sobre produccin, calidad y problemas.

22

CALIDAD DE SOFTWARE

12) Asegurase de que el personal de lnea sea el primero en intentar la solucin del problema antes que los expertos. 13) Mantenga y mejore el equipo existente y la fuerza de trabajo humano antes de pensar en nuevos equipos. 14) Busque equipo sencillo, barato y fcil de mover de lugar. 15) Busque tener estaciones de trabajo, maquinas, celdas y lneas mltiples en lugar de nicas, para cada producto. 16) Automatice en forma incremental, cuando no se pueda reducir de otra forma la variabilidad del proceso. Ahora que se ha revisado a diversos autores as como su funcin epistemolgica, podemos concluir que el concepto calidad es difuso y personal, as como absolutista en su enfoque y como meta difcil de alcanzar. Esto no quiere decir que no haya manera alguna de lograrla y mejorarla continuamente. Significa que es importante tener presentes sus diversos aspectos, pues esta multidimensionalidad tiene implicaciones prcticas para el establecimiento de sistemas y procedimientos para alcanzarla. En realidad se observa cmo sobre un mismo trmino se manejan interpretaciones diversas. Ante esta situacin ms que adoptar y defender un concepto nico de manera absoluta, resulta ms beneficioso y prctico tener conciencia de los diferentes caracteres de la calidad; los cuales son: dual (los fabricantes y prestadores de servicios deben ser capaces de ponerse en el lugar de los clientes y no slo como productores o prestadores de servicios ), relativo (lo que para algunas personas resulta de excelente calidad, para otras no y viceversa ), dinmico ( lo que es hoy de excelente calidad, en un perodo posterior, ya sea a largo, mediano o corto plazo, puede que ya no lo sea, debido a la existencia de la ley de las necesidades siempre crecientes del ser humano ), participativo ( en el logro de la calidad como totalidad, todas las personas en una organizacin empresarial aportan para alcanzar la misma ), multidimensional ( debido a las mltiples dimensiones que en la actualidad ya se tienen presentes como: cualidad, cantidad, oportunidad, el precio, el servicio de posventa, medioambiental), holstico y procesal ( la calidad como totalidad se obtiene de la interrelacin de un conjunto de procesos claves que la aseguran, los cuales forman un sistema de procesos de alta complejidad ).

23

CALIDAD DE SOFTWARE

1.2 Definicin de calidad de software. Uno de los problemas que se afrontan actualmente en la esfera de la computacin es la calidad del software. Desde la dcada del 70, este tema ha sido motivo de preocupacin para especialistas, ingenieros, investigadores y comercializadores de softwares, los cuales han realizado gran cantidad de investigaciones al respecto con dos objetivos fundamentales: 1. 2. Cmo obtener un software con calidad? Cmo evaluar la calidad del software?

Ambas interrogantes conllevan amplias respuestas, pero estn estrechamente ligadas con el concepto de la calidad del software, que es el resultado de la primera y la fuente de la segunda. A continuacin 4 definiciones reconocidas actualmente a nivel mundial: La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. (IEEE, Std. 610-1990). Concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente R. S. Pressman (1992). [2] El conjunto de caractersticas de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implcitas ISO 8402 (UNE 66-001-92). [2] Concordancia del software producido con los requerimientos explcitamente establecidos, con los estndares de desarrollo prefijados y con los requerimientos implcitos no establecidos formalmente, que desea el usuario (Pressman, 1998) Segn estndares IEEE 1983: Es la totalidad de caractersticas de un producto de software que lo refieren a su habilidad de satisfacer las necesidades dadas, por ejemplo la conformidad con los requerimientos. El grado en el cual un software posee una combinacin de atributos deseada. El grado en el que un cliente o usuario percibe que el software cumple con sus expectativas. La composicin de caractersticas del software que determinan el grado con el cual el software cumplir con las expectativas del cliente.[4] Por lo que tambin se podra deducir que La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinnimo de eficiencia, flexibilidad, correccin, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. La calidad del software es medible y vara de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de

24

CALIDAD DE SOFTWARE

"cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo perodo (10 aos o ms), necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotacin. Existen 3 puntos importantes de la definicin de calidad de software: 1- los requerimientos del software son los fundamentos desde los que se mide la calidad. 2- los estndares especficos definen un conjunto de criterios de desarrollo que guan la forma de aplicacin de la ingeniera de software. 3- existen requerimientos implcitos que no se menciona. [3] La calidad del software puede medirse despus de que es elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseo, por lo que es imprescindible tener en cuenta tanto la obtencin de la calidad como su control durante todas las etapas del ciclo de vida del software (Figura 6).

Figura 6. Etapas del ciclo de vida del software

La calidad de los programas es una preocupacin primordial de los especialistas en programacin, las caractersticas importantes de la calidad dependern, obviamente, del producto en particular, como ya se ha mencionado. En algunos casos, la transportabilidad del producto entre diversas mquinas podr ser un atributo de importancia capital, mientras que en otras ocasiones el uso eficiente de la memoria puede ser lo fundamental; por otro lado, existen algunas caractersticas de calidad que son fundamentales en todo producto de programacin; entre ellas estn la utilidad, claridad, confiabilidad, eficiencia y economa. El factor ms importante de la calidad de un producto es su utilidad, es decir, que el producto de programacin satisfaga las necesidades del usuario. Esto podr parecer obvio, pero muchos paquetes entregados a los usuarios con frecuencia no desempean las funciones esperadas; este problema es sntoma de la pobre comunicacin existente entre el cliente, los usuarios y los ingenieros de programacin. La planeacin cuidadosa, el anlisis y la participacin del cliente, son obligatorias para el desarrollo de productos de programacin tiles.

25

CALIDAD DE SOFTWARE

La confiabilidad Es la probabilidad de operacin libre de fallas de un programa de computadora en un entorno determinado y durante un tiempo especfico. [3] La confiabilidad del producto est definida como la "capacidad de un programa para desempear una funcin requerida bajo ciertas condiciones durante un tiempo especfico" (IEE83). El grado de confiabilidad deseado en un producto particular puede ser expresado en trminos del costo de la falla del producto. Existe ciertamente una gran diferencia entre las imperfecciones de un producto que implica una irritacin pequea en el usuario y la falla que contribuye a la muerte de una vida humana; as, la cantidad de esfuerzo gastado en obtener confiabilidad debe ser funcin del costo de las imperfecciones del producto; sin embargo, en cualquier caso, existe un nivel mnimo de confiabilidad que todo producto debe poseer. La confiabilidad del software se encuentra en un etapa de formacin de desarrollo y es la caracterstica de rendimiento ms costosa de conseguir, difcil de conseguir y difcil de garantizar. Los modelos de confiabilidad del software se usan para caracterizar y predecir el comportamiento importante para directores e ingenieros, estos modelos son: Modelo de McCall (1976) Modelo de Bohm (1978) Modelo de Ghezzi (1991) [4]

Los modelos de confiabilidad del software son generalmente procesos aleatorios. Estos modelos se pueden dividir en 2 grandes categoras: 1- modelos que predicen la confiabilidad como una funcin cronolgica del tiempo 2- modelos que predicen la confiabilidad como una funcin del tiempo de procesamiento transcurrid. [3] Los productos de programacin deben estar escritos con claridad y ser fciles de entender. Como se notar, las pruebas y actividades de mantenimiento consumen gran cantidad del presupuesto del proyecto. La clave para realizar un sistema fcil de probar y mantener radica en hacerlo comprensible; los productos de programacin que se presentarn a los usuarios deben tener una integridad conceptual y ser claros en el propsito del proyecto. Muchas de las tcnicas analizadas en este texto tienen como meta mejorar las claridades interna y externa de los productos. Un producto de programacin deber ser eficiente, pero slo tanto como la aplicacin particular lo amerite. En los primeros das de las computadoras digitales el equipo electrnico era muy costoso y lento, si se consideran las normas actuales; por esto se haca hincapi en aprovechar al mximo el ciclo de operacin de la memoria, de modo que la caracterstica ms importante del producto era su eficiencia. Conforme los productos se hacen ms complejos y grandes, los atributos de utilidad, confiabilidad y claridad van cobrando prioridad en dichos productos. Por otro lado, existen productos (sistemas en tiempo real corriendo en una microcomputadora) que estn limitados crticamente por el tamao de memoria y la velocidad de ejecucin; en estos casos, la eficiencia permanece como el atributo principal. Por lo tanto se dice que la eficiencia es fundamental, pero se sujeta a la aplicacin en particular.

26

CALIDAD DE SOFTWARE

Un producto de software debe de ser costeable en su desarrollo, mantenimiento y uso; los esfuerzos en el desarrollo y mantenimiento dedicados al aumento de la eficacia y la confiabilidad del producto deben de ser los apropiados para las aplicaciones de ste. De manera que la elegancia que genera nicamente una utilidad sea evitada. Un producto de programacin debe desempear, da a da, una tarea especfica usando menos tiempo o menos recursos humanos o industriales que los que se requeran antes de tenerlo. La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y prueba del software que permitan uniformar la filosofa de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. La poltica establecida debe estar sustentada sobre tres principios bsicos: tecnolgico, administrativo y ergonmico. El principio tecnolgico define las tcnicas a utilizar en el proceso de desarrollo del software. El principio administrativo contempla las funciones de planificacin y control del desarrollo del software, as como la organizacin del ambiente o centro de ingeniera de software. El principio ergonmico define la interfaz entre el usuario y el ambiente automatizado. La adopcin de una buena poltica contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluacin. Para controlar la calidad del software es necesario, ante todo, definir los parmetros, indicadores o criterios de medicin, ya que, como bien plantea Tom De Marco, "usted no puede controlar lo que no se puede medir". Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define mtricas de calidad y criterios, donde cada mtrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodologa para la evaluacin de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerrquicos: factor, criterio, mtrica, elemento de evaluacin, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categoras de mtricas: de complejidad de programa o cdigo, y de complejidad de sistema o estructura. Todos los autores coinciden en que el software posee determinados ndices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad. Una vez seleccionados los ndices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos: Definir el software que va a ser controlado: clasificacin por tipo, esfera de aplicacin, complejidad, etc., de acuerdo con los estndares establecidos para el desarrollo del software.

27

CALIDAD DE SOFTWARE

Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes. Crear o determinar los mtodos de valoracin de los indicadores: mtodos manuales como cuestionarios o encuestas estndares para la medicin de criterios periciales y herramientas automatizadas para medir los criterios de clculo. Definir las regulaciones organizativas para realizar el control: quines participan en el control de la calidad, cundo se realiza, qu documentos deben ser revisados y elaborados, etc. A partir del anlisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un proyecto para el Aseguramiento de la Calidad del Software (SQA), vlido para cualquier entidad que se dedique a la investigacin, produccin y comercializacin del software, el cual incluye la elaboracin de un Sistema de Indicadores de la Calidad del Software, la confeccin de una Metodologa para el Aseguramiento de la Calidad del Software y el desarrollo de herramientas manuales y automatizadas de apoyo para la aplicacin de las tcnicas y procedimientos del ACS, de forma tal que se conforme un Sistema de Aseguramiento de la Calidad del Software lo cual se revisara mas adelante.

Al hablar del concepto de calidad de software y la evolucin que ha habido a travs del tiempo desde sus inicios con los conceptos bsicos en ingeniera de software hasta las estructuras que componen su definicin hoy en da dentro de diversos marcos de trabajo (MT), para ello a continuacin se describir esos marcos de trabajo al cual se esta refiriendo en este prrafo. Los MT corresponden a estructuras escritas de una idea y/o conjunto de metas para facilitar a una organizacin la aplicacin de las mismas. Es decir, mediante los MT se permite que todo el personal de una organizacin se dirija en la misma "direccin". En el rea de Ingeniera de Software se puede catalogar a los MT por el propsito que cumplen: 1. 2. 3. 4. 5. 6. Estndares y Guas. Modelos de mejoramiento de procesos y mtodos internos de evaluacin. Pautas de seleccin de 3 o empresas o contratistas. Premios de Calidad. Modelos de ciclo de vida de software (figura 7). Modelos de ingeniera de sistemas.

28

CALIDAD DE SOFTWARE

Figura 7. Modelo de ciclo de vida del software

La finalidad de los marcos de trabajo es la de mejorar los procesos de software, brindar pautas para efectuar evaluaciones de la unidad informtica, determinar la potencialidad y la performance de sus procesos, y la madurez de la organizacin. En algunos MT estos temes se encuentran ms explcitos y por consiguiente ocupan un rea central en el mismo. En definitiva los MT buscan: mejorar los procesos de software, aumentar la productividad y la calidad, disminuir el costo. Es conveniente definir los elementos que manejan los MT vistos en el prrafo anterior, dado la diversidad de "versiones" de muchos de los trminos involucrados y con el fin de evitar ambigedades. Proceso de software: Es un conjunto de actividades, mtodos, prcticas y transformaciones que l personal usa para desarrollar y mantener el software, y los productos asociados (planificacin del proyecto, diseo de documentos, cdigo, casos de prueba, manuales de usuario, entre otros). Capacidad / Potencialidad (capability) de un proceso de software: Describe el rango de resultados esperados que se pueden llevar a cabo siguiendo un proceso de software. Una capacidad o potencial del proceso de software de una organizacin es un modo de predecir el resultado ms probable del siguiente proyecto de software que se emprenda.

29

CALIDAD DE SOFTWARE

Performance de un proceso de software: Representa los resultados actuales logrados habiendo seguido un proceso de software. La performance de un proceso, por tanto, se enfoca en resultados logrados, mientras que el potencial de un proceso se centra en resultados esperados. Madurez de un proceso de software: Se refiere a un proceso especfico que est explcitamente definido, administrado, medido, controlado, y es efectivo. Madurez: Implica la potencialidad de poder crecer e indica tanto la riqueza de un proceso de software de una organizacin como la consistencia con que se aplica en proyectos toda la organizacin. Organizacin inmadura: Los procesos de software generalmente se improvisan, esto incluye la posibilidad que, an especificados los procesos, ellos no se desarrollen en forma rigurosa. Organizacin madura: Posee la habilidad en toda su organizacin para administrar tanto el desarrollo como el mantenimiento de proyectos. A continuacin se muestran diferentes MT y sus relaciones cabe sealar que los que muestran un asterisco significa que aun no han sido publicados.

FIGURA 8 MARCOS DE TRABAJO.

30

CALIDAD DE SOFTWARE

FIGURA 9. LOS PRINCIPALES MARCOS DE TRABAJO POR CATEGORA. Sera muy difcil y complejo plasmar y tratar todos los marcos de trabajo que existen actualmente o en perodo de estudio. La sola observacin es indicativa de lo complejo que es discernir entre las variadas alternativas. Otras incgnitas que se derivan y cuyas respuestas no son fciles: Cul MT se debe aplicar a una organizacin? Qu caractersticas presentes en los MT hay que tomar en cuenta para seleccionar un MT? Se deben aplicar en forma estricta y completa los MT o hay que ajustarlos de acuerdo a las caractersticas de la unidad informtica en cuestin? Lamentablemente no existe una frmula mgica que permita responder en forma taxativa estas incgnitas. En los prximos prrafos hay algunos puntos que ayudan a conseguir las respuestas y aspectos a considerar de los MT. Los aspectos que se tienen que tomar en cuanta en los MT son los siguientes: Los MT nos permiten determinar "dnde estamos" hacia "dnde queremos ir" y "cmo" podemos hacerlo. (En la mayora de los casos "cmo" no es muy explcito y concreto, es un "cmo" muy difuso) Segn un artculo de la IEEE Computer, los MT describen "el recipiente, los utensilios y las tcnicas de cocina, asumiendo que la torta sabr bien. El mismo artculo indica que la mayora de los MT el grado de objetividad es puramente subjetivo en comparacin con el grado ideal que es objetivo. Los MT permiten (y de hecho se hace) adaptar los mismos de acuerdo a las caractersticas de la unidad informtica. (Recursos, experiencias, objetivos, etc.) Lo que no se indica es cmo hacerlo y cules puntos hay que adaptar. La etapa ms difcil y traumtica por el cual muchas organizaciones no se adhieren hacia un MT es el inicio. Si se habla de modelos de madurez correspondera al nivel 0 (varios modelos)

31

CALIDAD DE SOFTWARE

1 (CMM). Es difcil justificar la relacin costos-beneficios a los gerentes para promover el uso de un MT. Hay que tomar en cuenta que el esfuerzo de las evaluaciones no supere a las del desarrollo. Incoherencia de los MT de proponer evaluaciones en los primeros niveles si la mayora de las organizaciones inmaduras no existen algunos de los procesos o prcticas que indican los MT para evaluar en los niveles iniciales. Algunos expertos critican a los MT que contienen evaluaciones, el hecho de que estos son derivaciones artificiales. Es decir, cuando una organizacin se compara a s mismo con el modelo de evaluacin, se estn comparando prcticas del mundo real con una lista idealizada. La mayora de los MT considera necesario un conjunto de equipos especiales como por ejemplo una unidad de Aseguramiento de Calidad de Software (SQA), costo que muchas empresas pequeas de la realidad observada normalmente no pueden afrontar. La mayora de los MT considera que el personal posee un alto conocimiento y experiencia de ciertas prcticas propuestas por l, como as tambin de conceptos generales. En la experiencia reflejada en este trabajo y en la encuesta, hay muchos profesionales que tienen solo vagas nociones de ingeniera de software. La mayora de los MT considera el empleo de herramientas especiales. Para el caso de las PyMES el uso de estas implica un alto costo en recursos, (costo de compra, entrenamiento del personal, tiempo, etc.) estos factores influyen en su uso. La mayora de los estudios sobre los resultados de mejoramientos de procesos estn basados sobre el anlisis de unos pocos puntos de datos (Data points). Hay muy pocos puntos de datos analizados sobre los costos actuales de los programas de mejoramiento de procesos. Por consiguiente los resultados positivos arrojados por el uso de estos programas son datos "tentadores" ms que hechos establecidos. No olvidar que los procesos involucrados en los MT son elementos que ayudan a las soluciones ms que una solucin en s misma. La finalidad directa o indirecta de los MT es de aumentar la calidad del software, pero la gran mayora no define en sus documentos qu es calidad de software? Debido a la alta exigencia y presin para el mejoramiento de procesos, es muy factible "padecer" lo que se denomina "parlisis de procesos". Este trmino fue definido por Yourdon, y se refiere al efecto sobre el equipo del proyecto que es abrumado por la nueva tecnologa y gradualmente terminan por perder todo el tiempo en: - Tratar de entender la nueva tecnologa, - Argumentar los mritos de la nueva tecnologa, - Tratar que trabaje o funcione la nueva tecnologa. Esta parlisis puede causar a los equipos olvidar que se desarrolla software ms que procesos. Parte de este problema se puede atribuir el no entender qu son procesos de software.

32

CALIDAD DE SOFTWARE

As pues se obtienen las siguientes Conclusiones sobre los marcos de trabajo: Sin lugar a dudas que la decisin por parte de una organizacin de aplicar un MT trae aparejado muchos beneficios, por ejemplo: -Disminucin de costos y tiempo -Aumento de la productividad y de la calidad de los productos -Coordinar al personal hacia unas metas/objetivos con una misma "visin". Pero, cunto es esa disminucin de costo, en qu porcentaje se puede expresar, cmo vara este valor por cada MT. Son preguntas que todava no tienen una respuesta directa y formal. Algunos motivos de esta situacin: Los MT prcticamente son "nuevos", los ms antiguos tienen un promedio de existencia 7 a 10 aos. Se necesita tiempo para observar los resultados y analizarlos Son muy pocas las organizaciones que publican los resultados obtenidos al utilizar un MT en particular y que se preste para dicho estudio. A quin le gusta mostrar sus defectos y errores La tecnologa y herramientas (anlisis, diseo, mtricas, etc.) informticas evolucionan ms rpidamente en comparacin con la actualizacin de los MT. Ser una carrera perdida? O Ser cierto que los MT son totalmente independientes a esta realidad? Todava no se ha masificado el uso de los MT. La decisin de adoptar un MT implica estudios de factibilidad. Todava no hay una exigencia de mercado importante para certificarse en un MT en particular. Actualmente los profesionales e investigadores estn enfrentando estos problemas y los comentados anteriormente para conseguir un conjunto de soluciones posibles. Quizs se est muy cerca de hallar estas soluciones pero existe un obstculo por soslayar, y es el de crear un mtodo dentro o anexo a los marcos de trabajo que permita: "Si una unidad informtica est certificada y/o se encuentra en un nivel de madurez en particular determinado por un MT, determinar cul nivel de madurez le correspondera con respecto a otro MT y poder certificarse, o tendra que cumplir otros requisitos para hacerlo." Ahora que ya se ha visto los diferentes MT es importante retomar cuales serian los criterios bsicos para definir una buena calidad de software, esto, independiente del marco en el que se este trabajando. El desarrollo y mantenimiento de productos de software son tareas muy complejas a quienes han escrito solo pequeos programas para uso personal o como tareas escolares puede dificultrseles entender la importancia de un desarrollo sistemtico. El grado de formalidad y la cantidad de tiempo asignada vara de acuerdo con el tamao y complejidad del producto que se desarrollar; sin embargo, las actividades sistemticas son necesarias. Existe una diferencia

33

CALIDAD DE SOFTWARE

enorme entre escribir un pequeo programa para uso propio y el desarrollo y mantenimiento de un producto de programacin. Es posible observar que los ingenieros electrnicos no producen circuitos electrnicos por medio de la soldadura de diversos componentes; es absurdo pensar que ellos trabajan sentados en una banca de laboratorio seleccionando componentes, conectndolos, descansando a ratos, volviendo a seleccionar ms componentes, rascndose la cabeza y, as, arreglar y desarreglar circuitos con el fin de construir un sistema. Empero, esta sera la analoga a la forma como se considera que muchos programadores construyen un producto de programacin sin anlisis, sin diseo, sin pruebas y sin revisiones; simplemente la "-codificacin del asiento". El desarrollo y mantenimiento de productos de alta calidad requiere de habilidades tcnicas y gerenciales comparables con las de las otras ramas de la ingeniera. La calidad del producto y la productividad del programador, puede elevarse al mejorar los procesos necesarios para el desarrollo y .mantenimiento de los productos. Segn (Fairley, 1993) Algunos factores que influyen sobre la calidad y productividad se muestran a continuacin: - Capacidad individual. - Comunicacin del grupo. - Complejidad del producto. - Notacin adecuada. - Enfoque sistemtico. - Cambio de control. - Nivel tecnolgico. - Confiabilidad requerida. - Tiempo disponible. - Entendimiento del problema. - Estabilidad de los requerimientos. - Habilidades necesarias. - Facilidades y recursos. - Entrenamiento adecuado. - Habilidades administrativas. - Metas adecuadas. - Expectativas crecientes. Y se analizan a continuacin; las tcnicas que atienden a estos factores: Capacidad individual. La produccin y mantenimiento de productos de programacin son tareas laboriosas, por lo que la productividad y la calidad son funciones directas de la capacidad y esfuerzo individuales. Existen dos aspectos en la capacidad: la competencia global del individuo y su familiaridad con el rea particular de aplicacin; programadores que se muestran competentes en el procesamiento de datos, suelen no serlo en reas cientficas, y de igual forma, un buen programador cientfico no es, forzosamente, un buen programador de sistemas. La falta de familiaridad con el rea de aplicacin puede implicar baja productividad y poca calidad. Se entiende como "competencia general bsica" a la capacidad bsica para escribir programas de computadora correctos.

34

CALIDAD DE SOFTWARE

En la programacin, como en el deporte, el mejor consejo es utilizar gente de lo mejor; sin embargo, no siempre es posible contratar a personas excepcionales. Una de las metas de la certificacin de software es la de proveer notaciones, herramientas y tcnicas que permitan a los programadores de buena, aunque no de extraordinaria, capacidad para desempearse en su trabajo de manera competente y profesional. Mediante la inversin en mejores equipos y herramientas de programacin, las organizaciones pueden lograr que la ingeniera de programacin se transforme de una actividad con fuertes requisitos de recursos humanos a una actividad industrial de capital. Pero, an as, la capacidad individual ser un factor primordial que repercutir en la calidad y productividad en un futuro cercano. Comunicacin en el grupo. Por tradicin, se considera que la programacin es una actividad individual y privada de modo que muchos programadores tienen poco contacto social y prefieren trabajar en forma aislada (COU78). Los programas son pocas veces tomados como documentos pblicos, y los programadores en raras ocasiones analizan los detalles exactos de su trabajo de manera sistemtica. Como resultado, es posible que los programadores malentiendan el papel de sus mdulos o formas en el ambiente creciente del desarrollo de un sistema y que cometan errores que no sean detectados hasta despus de algn tiempo. Muchas de las innovaciones de la ingeniera de programacin, como la revisin de diseos, recorridos estructurados y los ejercicios de lectura de cdigo, tienen como propsito lograr que los programas sean ms sociables, lo cual mejora la comunicacin entre programadores. Por otro lado, con el incremento del tamao de un producto, disminuye la productividad debido al aumento en complejidad de las interacciones entre los diversos componentes del sistema, y a causa del incremento de comunicacin necesario entre programadores, gerentes y clientes. Brooks ha observado que el nmero de rutas de comunicacin entre programadores crece a razn de n (n-I) I2, donde n es el nmero de programadores en el grupo de un proyecto cualquiera (BR075); as, resulta que al incrementar el nmero de tres a cuatro y a cinco aumenta el nmero de rutas de comunicacin de tres a seis y a diez, respectivamente. Adems ntese que cada miembro del grupo debe aprender el proyecto y sobrepasar el efecto de la "curva de aprendizaje" antes de convertirse en un miembro apartador del grupo; esto incrementa an ms la carga de trabajo, reduciendo la productividad total. Sobre todo lo anterior, se debe mencionar que muchos procesos de desarrollo de productos son interdependientes y deben ocurrir en forma secuencial; as que agregar ms programadores a un proyecto puede resultar contraproducente, a menos que existan tareas independientes y que los nuevos programadores puedan desempearse sin incurrir en la carga adicional de aprendizaje de todos los detalles del proyecto. Esto fue expresado por Brooks de la siguiente manera: "Los hombres y los meses son recursos intercambiables slo cuando una tarea puede ser partida entre varios trabajadores incomunicados entre s; lo antes dicho vale para el desgranado del trigo y la recoleccin del algodn, pero no lo es, ni siquiera aproximadamente, para... la programacin". Brooks aade que este mismo principio es el que evita que pueda gestarse un nio en un mes por medio de nueve mujeres. Las consideraciones precedentes hicieron que Brooks formulara su ya famosa ley, la cual es parafraseada aqu como: LEY DE BROOKS (versin modificada): Agregar ms programadores a un proyecto retrasado puede hacer que se retrase ms.

35

CALIDAD DE SOFTWARE

Complejidad del producto. Existen tres niveles o tipos de complejidad en un producto generalmente aceptados: programas de aplicacin, programas de apoyo y programas del sistema operativo. En la primera clase se incluyen rutinas cientficas o de procesamiento de datos escritos en un sper lenguaje como FORTRAN, Pascal o COBOL. La clasificacin de programas de apoyo comprende compiladores, ensambladores, ligadores y cargadores, stos pueden estar escritos en un superlenguaje como Pascal o Ada o en lenguaje ensamblador. Los programas del sistema operativo se relacionan con rutinas de comunicacin de datos, procesamiento en tiempo real para sistemas de control y las rutinas bsicas del sistema operativo, los cuales suelen escribirse en lenguaje ensamblador o en un lenguaje de desarrollo de sistemas como PL/l o Ada. Los programas de aplicacin tienen el ms alto nivel de productividad mientras que los programas de sistema operativo tienen el menor, medido en trmino del nmero de lneas de cdigo por da de programador. Los programas de apoyo pueden producirse a una velocidad cinco o diez veces mayor que los anteriores; para los de aplicacin, la velocidad suele ser entre 25 y 100 veces mayor. Algunos datos caractersticos para lneas de cdigo por da de programador, en funcin de la complejidad del proyecto son los siguientes: menos de una lnea de cdigo al da por programador para programas de sistema; de cinco a diez para programas de apoyo, y de 25 a 100 lneas de cdigo al da por programador para programas de aplicacin, cabe sealar que tales datos deben tomarse slo como guas y no considerarse definitivos, ya que se encuentran bajo la influencia de diversos factores. El esfuerzo requerido para desarrollar y mantener un producto de programacin es una funcin no lineal del tamao del producto y su complejidad. Un producto del doble de tamao o doblemente difcil que otro producto, usando cualquier mtrica diferente del esfuerzo, puede requerir diez o tal vez 100 veces ms esfuerzo para obtener el producto. La falla de no permitir un escalamiento no lineal en tamao y complejidad es una de las primeras razones para un sobre costo o una entrega retrasada en muchos proyectos de programacin. Notaciones apropiadas. En la computacin, como en otras disciplinas, los esquemas de representacin son de fundamental importancia. Una buena notacin puede aclarar las relaciones e interacciones de importancia, mientras que las notaciones deficientes complican e interfieren con la buena prctica de la disciplina. Los lenguajes de programacin proporcionan notaciones concisas en la fase de instrumentacin del desarrollo, pero no existen notaciones globalmente aceptadas para definir los requisitos funcionales del producto, las especificaciones de diseo, los planes de prueba o los criterios de desempeo. Varias notaciones se han desarrollado en estas reas, y en el texto se presentan algunas; sin embargo, ninguna se acepta universalmente para la ingeniera de software, como el caso de los diagramas de alambre de la ingeniera electrnica y los planos de estructuras de la ingeniera civil. Las notaciones apropiadas son vehculos de comunicacin entre el personal asignado al proyecto y plantean la posibilidad de usar una herramienta automatizada de programacin para manejar las notaciones verificando su uso correcto. Esto puede beneficiar un proyecto en particular, pero se obtendrn ms beneficios cuando se adopte, en todas las organizaciones e industrias, un conjunto pequeo de notaciones bien definidas para los proyectos de programacin.

36

CALIDAD DE SOFTWARE

Enfoques sistemticos. En cada campo del conocimiento existen ciertos procedimientos y tcnicas aceptadas, la existencia de estas prcticas normales es una de las caractersticas que distinguen esa disciplina profesional. Control de cambios. Desde un punto de vista muy real, los programas sirven para que un equipo de uso general se adapte al empleo de una aplicacin especfica; algunas veces, el software debe compensar las deficiencias de diseo en el equipo, de tal suerte que se suele estilizarse para satisfacer diferentes requisitos de clientes diversos. La flexibilidad en un programa es un gran beneficio y a su vez una gran fuente de dificultad en la ingeniera de software. Como el cdigo fuente es fcil de modificar, suele dificultarse la resolucin de diferentes detalles de los algoritmos, o que el cliente solicite cambios que el gerente de proyecto est dispuesto a aceptar. As el desarrollo de software comnmente queda amarrado entre un equipo inadecuado y un cliente que quiere un producto un "poco diferente" del normal. Los requisitos tambin pueden cambiar debido a un escaso entendimiento del problema, o debido a factores econmicos o polticos externos, ajenos al cliente o al experto. Algunos proyectos estn sujetos a cambios constantes de sus especificaciones, que con rapidez desaniman y desmoralizan a los expertos. Las notaciones y procedimientos que permitan seguir la secuencia y determinar el impacto de un posible cambio son necesarios para hacer visible el costo verdadero de una modificacin aparentemente pequea al cdigo fuente; estos cambios por lo comn se vuelven mayores cuando se incluyen los costos de modificacin de manuales, requisitos y planes de prueba. Por otro lado, el uso de notaciones y tcnicas apropiadas hace que se puedan realizar cambios controlados, sin menoscabo de la calidad del producto. Nivel tecnolgico. El nivel tecnolgico utilizado en un proyecto de programacin incluye aspectos como seleccin del lenguaje, ambiente computacional, prcticas de programacin y herramientas de programacin disponibles. Los lenguajes de programacin modernos proveen caractersticas mejoradas para la definicin y manejo de datos, estructuras de construccin mejoradas para la definicin del flujo de control, mejores facilidades de modularizacin, manejo eficiente de condiciones y facilidades para cualquier tipo de programacin. El ambiente computacional se refiere al conjunto de caractersticas del equipo y los programas disponibles para el desarrollo, uso y mantenimiento del producto. La estabilidad y disponibilidad del ambiente computacional influyen notablemente en la productividad y la calidad del producto. Las tcnicas modernas de programacin comprenden el uso de un anlisis sistemtico y tcnicas de diseo, nomenclatura apropiada, codificacin estructurada, tcnicas de depuracin y estudio de documentos y cdigo fuente y pruebas sistemticas. Las herramientas de programacin van desde las herramientas ms elementales como ensambladores y depuradores sencillos hasta ambientes totales de programacin que incorporan herramientas para la administracin Y el control del desarrollo del proceso. Nivel de confiabilidad. Todo producto de programacin debe poseer un nivel elemental de confiabilidad; sin embargo, la alta confiabilidad slo se consigue con gran cuidado en el anlisis, diseo, instrumentacin, pruebas y mantenimiento del producto de programacin. Se requieren tanto recursos humanos como equipo para obtener un aumento en la confiabilidad; lo

37

CALIDAD DE SOFTWARE

anterior conduce a una reduccin en la productividad, medida slo en trminos de lneas de cdigo producido durante un mes. Boehm estima que el cociente de la productividad entre un nivel de baja confiabilidad y uno de muy alta confiabilidad es de 2: 1 (BE81). Captacin del problema. En un proyecto de programacin un asunto comn de difcil solucin es la incomprensin de la verdadera naturaleza del problema; existen diversos factores que contribuyen en esta falta de conocimiento. Por lo general, es el cliente quien no entiende realmente la naturaleza del problema, adems de no entender las capacidades y limitaciones de la computacin; la mayora de los clientes, ya en general toda la gente, no han sido educados para pensar en trminos lgicos y algortmicos e incluso, en ocasiones, desconocen sus verdaderas necesidades. Suele suceder que el especialista de programacin no entienda el rea de aplicacin y, por ende, tiene dificultades al comunicarse con el cliente debido a sus diferentes antecedentes educacionales, sus distintos puntos de vista y la jerga de comunicacin que cada uno maneja. Algunas veces incluso el cliente no es el usuario final del sistema y el ingeniero no tiene oportunidad real de estudiar el problema especfico del usuario. En ocasiones la naturaleza misma del problema no se revela hasta que el proyecto, o la mayor parte de ste, se ha terminado y se halla operando; otras veces, la solucin automatizada cambia la naturaleza del problema, para bien o para mal, y el cambio no es visto con claridad sino hasta que el sistema ha quedado instalado. La planeacin cuidadosa, las entrevistas con el cliente, la observacin de la tarea manual, el desarrollo de prototipos, una versin preliminar del manual del usuario y la especificacin precisa del sistema pueden incrementar el entendimiento del cliente y del experto sobre el problema en cuestin. Tiempo disponible. Aunque pareciera que un proyecto de programacin que requiere de un esfuerzo de seis meses-programador pueda ser completado por un programador en seis meses o seis programadores en un mes, los proyectos de programacin son sensibles no slo al total de esfuerzo requerido, sino tambin al nmero de personas comprendidas. El uso de seis programadores durante un mes probablemente sea menos eficiente que utilizar uno durante seis meses, y esto se debe a que la curva de aprendizaje para el grupo de seis programadores afectar notablemente al proyecto. Por otro lado, el uso de dos programadores durante tres meses puede resultar ms eficiente que usar slo uno, debido a la retroalimentacin que cada programador reciba del otro. La productividad de un programador est tambin influida por el calendario de terminacin del proyecto. Una regla famosa de programacin dice que se requiere de dos aos para desarrollar un compilador para un lenguaje nuevo, independientemente del nmero de programadores asignados al proyecto. Existe evidencia cuantitativa que sugiere que el tiempo de desarrollo no puede ser comprimido abajo del 750/0 del tiempo nominal, independientemente del personal y recursos adicionales asignados (BOE81). No ha quedado claro que al extender el tiempo de desarrollo hasta un lmite razonable (p. Ej., dos aos para un compilador) se pueda hacer que el proyecto resulte ms fcil de desarrollar. Por cierto, algunos investigadores creen que al extender un proyecto ms all de su duracin nominal se incrementa el esfuerzo requerido para ste; es evidente, sin embargo, que la dificultad de un proyecto y, por lo mismo, la productividad del programador y la calidad de los programas, son funciones sensibles al tiempo disponible para su desarrollo y modificacin.

38

CALIDAD DE SOFTWARE

Especializacin requerida. El ejercicio de programacin requiere de una gran gama de habilidades y especialidades; por ejemplo, la obtencin de la informacin de los clientes con el fin de determinar sus necesidades requiere de la habilidad de comunicarse, de cierto tacto y diplomacia, as como de un buen conocimiento del rea de aplicacin. La definicin de las necesidades y las actividades de diseo son de tipo conceptual y requieren una buena dosis de habilidad en resolucin de problemas. La implementacin de los programas exige una fuerte atencin en los detalles; la escritura correcta de un programa es comparable con la escritura de un libro de texto que no tenga errores de ortografa o puntuacin y con una extensa facilidad de referencias cruzadas. La depuracin suele requerir de habilidades de deduccin detectivescas; la planeacin de las pruebas necesita considerar todas y cada una de las posibles situaciones, as como para las pruebas de fuego es indispensable una mentalidad clara reflexiva. La preparacin de documentos externos requiere de una buena capacidad de descripcin escrita, y tambin de poderse poner en el papel del usuario o de la persona que le dar mantenimiento al programa, esto con el fin de anticipar las preguntas y preocupaciones de estas personas y contestarlas en forma directa. El trabajo con clientes y otros constructores exige la capacidad de comunicacin oral e interpersonal. Por ltimo, todas estas habilidades deben ser ejercitadas dentro de un marco tcnico y gerencial, as los ingenieros de programacin deben estar tcnicamente preparados y poseer suficientes habilidades de interaccin social para trabajar con gerentes, clientes y otros especialistas del rea computacional. Facilidades y recursos. Los estudios acerca de los factores motivadores de los programadores demuestran que los factores relacionados con el trabajo, como buen acceso a la mquina y un lugar silencioso para laborar, resultan ser ms importantes para el programador promedio que los factores relacionados en la clase, como estacionamiento privado y acceso a baos particulares (COU78). La mayora de los programadores siente que los aspectos positivos de su trabajo son las tareas que representen un reto a su variedad, y las oportunidades de crecer profesionalmente, mientras que los aspectos negativos son la ineptitud administrativa, polticas de la compaa y la burocracia organizacional. Casi todos los programadores reciben sus motivadores de la naturaleza misma de su trabajo; por tanto, son muy sensibles, estn sujetos a frustracin, recursos pobres o inadecuados. Los gerentes de un proyecto de programacin deben de ser eficaces en el manejo de los factores de motivacin y frustracin, si desean mantener la calidad de sus productos, la productividad de sus programadores y la satisfaccin del trabajo. Entrenamiento adecuado. La instrumentacin de un producto es slo un aspecto de la programacin; sin embargo, sta es la nica fase del desarrollo y mantenimiento de un producto que se ensea en muchas escuelas. Algunas instituciones ofrecen cursos de los temas de anlisis y diseo, pruebas, mantenimiento y de tcnicas de la administracin de un proyecto, pero son muy pocas. Boehm ha mencionado las habilidades que suelen faltar en programadores novatos (BOE76b); su lista incluye la incapacidad de: -Expresarse claramente en su lengua materna -Desarrollar y validar requisitos de software y disear las especificaciones -Trabajar dentro de reas especficas de aplicacin -Desempear labores de mantenimiento de programas -Efectuar anlisis econmicos

39

CALIDAD DE SOFTWARE

-Laborar con tcnicas de administracin de proyectos -Trabajar en grupo Existe, pues, todava un retraso impredecible entre la oferta educacional y la demanda industrial. Hasta el momento, la mayora de los programadores se han educado como ingenieros en computacin, ingenieros electrnicos, contadores, matemticos, ms no como ingenieros en productos de programacin. La educacin en ciencias de la computacin se preocupa por dar un entendimiento bsico de las teoras y conceptos de la informacin y su procesamiento, comprendiendo estos trminos en el sentido ms amplio posible, mientras que la especializacin en productos de programacin se ocupa del anlisis, diseo, programacin, pruebas, verificacin, documentacin, operacin y mantenimiento de software que de alguna manera son las certificaciones en procesos de desarrollo. Las universidades han formado tradicionalmente licenciados en computacin y las industrias buscan, tambin por tradicin, ingenieros de programacin; esto implica que los programadores novatos no se preparen lo suficiente como para ser especialistas de productos de programacin. Habilidades gerenciales. Los proyectos de programacin son, por lo comn, supervisados por gerentes que tienen poco conocimiento, si acaso lo tienen, acerca del rea de programacin; muchos de los problemas de esta ingeniera son nicos, incluso gerentes con experiencia en direccin de proyectos de equipos de cmputo, encuentran que los proyectos de programacin son difciles debido a las diferencias en la metodologa de diseo, notaciones, herramientas, y otros aspectos. Es comn que un programador reporte a un ingeniero electrnico o a un contador que slo tienen experiencia con la programacin a travs de un curso introductorio en el que no obtuvieron grandes conocimientos; sta es ciertamente una desafortunada situacin tanto para el gerente como para el programador. Por otro lado, la costumbre de promover a puestos administrativos de un proyecto de programacin a individuos tcnicamente competentes, con poca inclinacin gerencial y sin entrenamiento administrativo, tambin suele producir resultados negativos. Muchas organizaciones ofrecen entrenamiento en direccin de proyectos a ingenieros de programacin, pero esto no siempre conduce a resultados satisfactorios. En parte, esto se puede deber a que los programadores requieren poco contacto social en su trabajo, mientras que el gerente requiere de una adecuada capacidad de comunicacin social. Metas apropiadas. La meta principal de la ingeniera de software es el desarrollo de productos de programacin que cumplan con los requisitos del uso deseado; idealmente, todo producto de programacin debe proporcionar niveles ptimos de generalidad, eficiencia y confiabilidad. El esfuerzo desorganizado dedicado a mejorar marginalmente algunas caractersticas deseadas con una excesiva eficiencia, va en detrimento de la productividad del programador. Del mismo modo, la poca confiabilidad y eficiencia perjudican la calidad del producto. Se puede obtener un punto medio entre la productividad y los factores de calidad, mediante el mantenimiento dentro de las metas y requisitos establecidos para el producto durante la etapa de planeacin. Expectativas crecientes. El problema de mayor persistencia en el desarrollo de software es del crecimiento constante de las expectativas del producto. Existen dos aspectos interrelacionados al respecto: primero, est la preocupacin de que tanta funcionalidad, confiabilidad y desempeo puede obtenerse con un esfuerzo determinado; en segundo lugar, se halla el aspecto relacionado con las limitantes de la tecnologa de programacin. Existe un Progreso constante en el desarrollo de herramientas y tcnicas para mejorar la calidad y productividad de un

40

CALIDAD DE SOFTWARE

programador. Sin embargo, la diversidad, el tamao y la complejidad de las aplicaciones crecen con ms rapidez que nuestra capacidad de manejar tan creciente demanda. Los avances dramticos en la tecnologa de los equipos crean expectativas de que la tecnologa de programacin deber avanzar a la misma velocidad; cada nuevo xito en la ingeniera de software aumenta la presin para mejorar la calidad y la productividad de sta. No es claro si la incapacidad' actual para enfrentar la demanda presente de productos es inherente a la naturaleza de la programacin y a las capacidades humanas de resolucin de problemas o se debe la inmadurez de esta disciplina. Es real que el uso de tcnicas sistemticas para desarrollar y mantener productos de programacin genera un aumento en la productividad del programador, as como un aumento en la calidad del producto. Ciertamente, los avances futuros mejorarn la situacin, sin embargo, el grado en que estas expectativas queden satisfechas como producto de los conceptos analizados en este texto es todava una pregunta que no puede responderse.

41

CALIDAD DE SOFTWARE

1.3 Quin define la calidad. Para determinar quien define la calidad si el cliente, el proveedor, la materia prima, los procesos de produccin etc., es necesario en primera instancia comprender algunos paradigmas que podra clarificar el quien define la calidad. Por lo que es importante entender la satisfaccin del cliente que es el resultado de comparar su percepcin (o impresiones) de los beneficios que obtiene con las expectativas que tena de recibirlos: Satisfaccin = percepciones - expectativas Si las percepciones superan las expectativas, los clientes se encontraran satisfechos y considerarn que han recibido un servicio de calidad. Cuando coincidan ambas no habr satisfaccin, porque se habr recibido lo que se esperaba. Si las percepciones son inferiores a las expectativas se producir insatisfaccin. Las organizaciones deben comprender cmo perciben los clientes la calidad y qu nivel de calidad desean. En definitiva, los clientes se encuentran satisfechos cuando el producto o servicio cumple sus expectativas y encantados cuando las sobrepasa. Factores que influyen en la formacin de las expectativas Los principales factores que influyen en la formacin de las expectativas de los usuarios o clientes son: - la comunicacin boca-oreja, es decir, lo que los usuarios escuchan de otros usuarios, - las necesidades personales de cada cliente, - la experiencia previa tenida con el uso de un servicio, - la comunicacin externa de los proveedores del servicio, - el precio, sobre todo en el caso de los clientes potenciales. Factores que influyen en la percepcin de un servicio de calidad o criterios utilizados por los clientes para evaluar la calidad Los factores que influyen en la percepcin de un servicio de calidad son: - Fiabilidad. La fiabilidad es la capacidad de realizar el servicio bien a la primera, con precisin, sin errores. Ejemplo: Cuando un miembro de la organizacin se compromete a devolver una llamada a un cliente, lo hace? La informacin fue proporcionada de manera correcta, sin errores? - Capacidad de respuesta. La capacidad de respuesta o disponibilidad implica la voluntad o el deseo de dar un servicio inmediato, rpido, y de ayudar a los clientes. Ejemplo: Cuando un usuario tiene un problema con un expediente, la empresa resuelve de manera rpida el problema? El personal de la organizacin es consciente que una llamada de un cliente es una oportunidad de contactar con l, ms que una molestia en determinados momentos? - Compromiso. El compromiso implica competencia o profesionalidad, cortesa (respeto y amabilidad) y seguridad de los empleados para transmitir responsabilidad, credibilidad y confianza. La profesionalidad es esencial, ya que constituye el beneficio bsico del servicio. Ejemplo: Cuando llamo al despacho de un abogado, la persona que me atiende tiene la

42

CALIDAD DE SOFTWARE

habilidad suficiente para dar una solucin a mi problema? (profesionalidad). Mi empresa tiene una buena imagen? (credibilidad). Es seguro dar mis datos para que aquella empresa las incluya en su Web? (seguridad). El personal de recepcin es suficientemente agradable cuando me atiende? (cortesa). a) Accesibilidad. Las empresas de servicios deben facilitar que los clientes contacten con ellas y puedan recibir las prestaciones que desean. Ejemplo: La empresa tiene una Web informativa? Puedo acceder rpidamente a mi asesor cuando tengo un problema extraordinario? b) Comunicacin. Las empresas deben escuchar activamente a sus clientes e informarles en un lenguaje comprensible. Ejemplo: Cuando llamo a mi empresa aseguradora estn encantados de escucharme? c) Conocimiento o comprensin del cliente. Las empresas u organizaciones orientadas al cliente se esfuerzan por conocer a los clientes y sus necesidades. Ejemplo: Mis asesores desean saber cules son mis necesidades o las suponen? - Elementos tangibles. Los elementos tangibles incluyen las instalaciones, los equipos, el aspecto de las personas y el material de comunicacin. En definitiva, para un cliente lo que es verdaderamente importante es el nivel de calidad percibida, entendida como confrontacin entre lo que esperaba y lo que recibe. Por lo tanto, la satisfaccin de un cliente es el resultado de las impresiones recibidas a lo largo de la creacin del servicio menos las expectativas que el cliente tena al entrar en contacto con la actividad de servicios. Todo esto nos conduce a dos observaciones: 1) La respuesta a la necesidad del cliente slo debe contener los elementos que ste perciba como valiosos. Aadir ms es un despilfarro, ya que lo que no se percibe, no existe. 2) La mejora de la calidad se puede obtener actuando no slo sobre la ejecucin y las percepciones, sino tambin sobre las expectativas. Por lo tanto debe entenderse que el usuario es quien define la calidad; debiendo la empresa complacer a los clientes, y no contentarse slo con librarlos de sus problemas inmediatos, sino ir ms all para entender a fondo sus necesidades presentes y futuras, a fin de sorprenderlos con productos y servicios que ni siquiera imaginaban. Este conocimiento ya no debe ser slo del dominio exclusivo de grupos especiales de una organizacin; sino que debe ser compartido y desarrollado por todos los empleados. Una empresa que define la calidad sin tomar en cuenta a los consumidores corre con el riesgo de producir bienes y servicios con escasa o nula demanda, ya sea porque los clientes tienen otras expectativas y necesidades, o bien porque los competidores estn generando bienes con un mayor valor agregado. Por tales motivos es esencial para las empresas practicar tanto la investigacin de mercado, como la inteligencia competitiva y el benchmarking.

43

CALIDAD DE SOFTWARE

Conocidos los deseos y necesidades de los consumidores, estos deben ser traducidos en trminos cuantitativos y tangibles. Este proceso de traduccin no es sencillo y requiere de la integracin de conocimientos de mercadotecnia con ingeniera y administracin, para que las necesidades del consumidor y las expectativas que desarroll durante el proceso de seleccin del producto, puedan ser satisfechas completamente. Entre la tcnica ms importante para tales fines tenemos el Despliegue de la Funcin de Calidad (QFD), el cual sirve para realizar todo este proceso de traduccin, ayudando a que la voz del cliente se despliegue a travs de toda la organizacin. La funcin de despliegue de la calidad tiene como objetivo asegurar que se cumplan las expectativas del cliente desde el diseo del producto, durante su proceso de manufactura, y hasta que es utilizado por el consumidor. En japons se le llama ten kai lo cul significa despliegue, refirindose a la idea de llevar las necesidades y expectativas del cliente expresados en su lenguaje (voz del cliente) a todos los involucrados en la organizacin, e ir en cada etapa traducindolas al lenguaje apropiado. Quien define la calidad? Los estndares o metodologas definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. La calidad del software la define o avala una Gestin de la calidad del software por ejemplo: ISO 9000, esto como poltica de calidad, se entiende como un conjunto de actividades de la funcin general de la direccin que determina la calidad, los objetivos, el control de la calidad. Algunos de varios estndares para software provienen de ISO 9000 quien rige la calidad mundial. ISO/IEC 91261: Ingeniera de Software - Calidad de producto- Modelos de calidad. ISO/IEC TR 91264: Ingeniera de software - Calidad de producto- Calidad en mtricas de uso. ISO 924111: Guas en Usabilidad. Especificaciones: ISO 20282: Usabilidad en productos de cada da. Interfaz e interaccin ISO/IEC TR 91262: Ingeniera de software- Calidad de producto- Mtricas externas. Especificaciones: ISO 9241: Requisitos ergonmicos para trabajo en oficinas y terminales de trabajo. ISO/IEC TR 91263: Ingeniera de software- Calidad de producto- Mtricas internas. Especificaciones: ISO/IEC 107411: Interaccin de Dilogo - Control del cursor en edicin de textos. ISO 9241: Requisitos ergonmicos para oficinas con terminales visuales. Especificaciones: ISO/IEC 11581: Iconos, smbolos y funciones. ISO 11064: Diseo ergonmico para centros de control. Especificaciones: ISO 13406: Requisitos ergonmicos de trabajo de paneles planos. ISO 14915: Ergonoma de software para interfaz multimedia. Especificaciones: ISO/IEC 14754: Interfaz de escritura manual. Interaccin IEC TR 61997: Guas de interfaz de usuario en equipos multimedia de uso general. Especificaciones: ISO/IEC 18021: Interfaz de usuario para dispositivos mviles. ISO 18789: Requisitos ergonmicos y sistemas mtricos para pantallas. Documentacin ISO/IEC 18019: Guas para el diseo y preparacin de documentacin de software de usuario. Especificaciones: ISO/IEC 15910: Documentacin de procesos de software. De usuario proceso de desarrollo ISO 13407: Diseo de procesos interactivos.

44

CALIDAD DE SOFTWARE

Especificaciones: ISO/IEC 14598: Evaluacin de software. ISO TR 16982: Mtodos de soporte de diseos centrados en usuarios. Capacidad de la empresa ISO TR 18529: Procesos descriptivos de vida de producto (lifecycle) otros ISO ISO 92411: Introduccin general. ISO 92412: Gua en requisitos de acciones. ISO 100751: Principios ergonmicos de carga mental, trminos y definiciones. ISO DTS 16071: Gua de accesibilidad en interfaz de usuario. Quin define la Calidad? La mxima autoridad de la organizacin? El profesional especialista en el tema? El responsable de Control de Calidad? Aquellos que ejecutan las tareas? Estas preguntas no son "filosficas", la respuesta a las mismas define el accionar de la organizacin. En el nacimiento de la era industrial y hasta el ao 1950 haba pocas dudas al respecto, la Calidad de los productos y servicios la defina el proveedor de los mismos. Hoy nadie discute que Calidad "es cumplir siempre los requisitos (necesidades y expectativas) de los clientes y dems partes interesadas". Entonces la Calidad la definen los clientes y las dems partes interesadas. Quines son las partes interesadas? , son los empleados, los proveedores, los dueos o accionistas, y la sociedad en general. Todas estas partes tienen requisitos que la organizacin debe cumplir. Mltiples indicadores sealan que el mundo est en las postrimeras de la era industrial. Se ha iniciado una nueva era, an no tiene un nombre definitivo, algunos la llaman "era de la informtica la informacin", otros la "era del conocimiento". Segn la American Society for Quality Control calidad es: "La totalidad de funciones y caractersticas de un producto que determinan la capacidad para satisfacer las necesidades de un grupo de usuarios" (Larrea, 1991). Por supuesto que existen muchos autores y muchas definiciones similares, pero contemplada la calidad desde un concepto estratgico, quien define la calidad da con da, es el cliente. Es el cliente quien juzga. La creciente competencia origina cambios en las necesidades y expectativas de los clientes. Los productos que ayer le parecan excelentes, hoy pueden no ser satisfactorios. Por otra parte, todas las empresas que pretenden subsistir en el mercado se estn ocupando de mejorar continuamente, por lo que el precio de los productos tiende a ser muy similar entre las diferentes marcas, as que, para "ganar" clientes y retener a los actuales, las compaas requieren un elemento que les de ventaja competitiva. Ese elemento puede ser el servicio. El servicio como elemento diferenciador Pero qu es el servicio? Existen varios conceptos asociados, en algunos de ellos se entiende al servicio como un resultado psicolgico personal, en otros casos el servicio es visualizado como un proceso, por lo que su importancia depende del valor que el cliente le d a la calidad del servicio. De cualquier forma, la calidad del

45

CALIDAD DE SOFTWARE

servicio ser evaluada por el cliente sobre la base de su percepcin personal del servicio que recibe, comparada con el servicio que deseaba recibir, es decir, sus expectativas. percepcin personal del servicio que recibe Satisfaccin del cliente = ---------------------------------------------------------------expectativas que tena antes de recibir el servicio Existen diversos factores o caractersticas que hacen variar la calidad en el servicio, la cual se evala durante todo el proceso de servicio que en trminos temporales, se realiza antes, durante y despus de la venta de un producto. Esta evaluacin la hace el cliente por comparacin entre lo esperado y lo obtenido. La necesidad de medir. Si una empresa esta seriamente decidida a enfocarse al cliente y mejorar el nivel de servicio que ofrece, es necesario que desarrolle medios objetivos para medir su desempeo. Las mediciones permiten a una compaa (Horovitz, 1993): - Saber dnde se encuentra en relacin con una referencia determinada; - Comprobar la homogeneidad; - Identificar los puntos fuertes y dbiles; - Centrar los esfuerzos, - Dirigir y controlar el progreso, - Cuantificar logros, y - Aumentar el conocimiento de la calidad de servicio. Tal como Deming dijo, lo que no se mide no se conoce. Ninguna empresa puede integrarse a la mejora continua si no tiene un pleno conocimiento de sus reas de oportunidad. Entonces, es necesario medir, saber en que posicin se encuentra la organizacin y si se est realizando algn progreso en comparacin con los objetivos determinados. Las medidas del desempeo. En primera instancia, las medidas de desempeo de cualquier empresa deben dividirse en dos categoras (Butterfield, 1991): Medidas internas: Relativas al desempeo de los empleados y los procesos dentro de la organizacin, incluyendo, por ejemplo, ndices de errores y productividad. Medidas externas: Aquellos componentes de servicio que son percibidos por los clientes, por ejemplo, seguridad y tiempo de respuesta. Es evidente que las medidas internas estn directamente relacionadas con las medidas externas, de hecho, reflejan las mismas cosas, pero desde diferentes perspectivas (el punto de vista de la organizacin y el punto de vista del cliente). Medir lo intangible. Pero, cmo se puede medir lo intangible? Conceptos de este tipo, debido a sus caractersticas pueden ser difciles de medir, pero es posible lograrlo a travs de las manifestaciones tangibles, es decir, las cosas asociadas que se pueden medir o palpar. "Las mediciones para alcanzar o mejorar con respecto a un determinado nivel de referencia son vlidas en tanto que dicha referencia refleje con precisin las expectativas de servicio a los

46

CALIDAD DE SOFTWARE

clientes. De no ser as, una compaa est creando la perfeccin sin propsito alguno: el elefante blanco, totalmente intil, del proverbio" (Horovitz, 1993). Entonces es preciso dejar claro que ninguna medicin tiene valor en s misma, es decir, sin referencia, ya que su significado se pierde. Si se trata de medir la Calidad en el Servicio, las mediciones solo adquieren significado al compararse con los resultados de encuestas de satisfaccin al cliente. Por ejemplo, se pueden limpiar las aulas de una escuela y lograr que se cumplan los niveles internos de limpieza, pero los alumnos pueden no percibir que las aulas estn limpias. Los estndares de servicio que establezca cualquier compaa, deben ser expresados en trminos de qu se le debe dar al cliente en cada momento de su relacin con la compaa. Posteriormente, estos estndares pueden traducirse a otras medidas numricas de operacin interna y asignar una persona responsable de cumplir un determinado estndar. Especificar requisitos, sin vincularlos a miembros del personal o sin definir mtodos de medicin viables, es desperdiciar el tiempo. Los estndares son para los procesos, no para la Direccin. Vale la pena hacer notar que los estndares no tienen que ser de uso exclusivo para la direccin, para dirigir o controlar la calidad del servicio. Tambin deben ser de conocimiento de los empleados, los cuales deben estar totalmente involucrados y comprender el significado de los nmeros que se les muestran. Los procesos los manejan personas. Para poder obtener el compromiso tanto de la direccin como de los empleados, los estndares establecidos deben explicarse con toda claridad; de hecho lo ms recomendable es que los empleados de cada rea participen en la definicin de "Qu es lo que se debe y puede medir?" Sin duda se obtendrn tiles sugerencias. Normalmente, se requiere que la informacin fluya en cascada desde los niveles altos hacia los bajos de los resultados de todas las mediciones hechas en los distintos niveles jerrquicos de la organizacin. Esto puede ser tambin un mecanismo para motivar a la gente a actuar. En la actualidad, existen compaas que construyen bonos extra, o parte del sueldo, en funcin de los resultados de satisfaccin de los clientes. Hay muchas compaas que prestan poca importancia al hecho de compartir esta informacin con todo el mundo y que prefieren mantenerlo como un secreto. Es difcil enfrentarse a los nmeros, pero si no se reconoce que existe un problema, cmo se va a resolver? Difundir los resultados (cuando son buenos!). Por otra parte, decir a los clientes que una compaa ofrece buena calidad de servicio, muchas veces no es suficiente; hace falta proporcionar pruebas tangibles, por lo que se pueden utilizar los estndares establecidos asociados a una buena campaa de comunicacin centrada en la calidad de servicio. La compaa Equity & Law (Horovitz, 1993) hizo algo sumamente innovador. Public sus estndares en forma de folleto comunicativo publicitario, tanto para sus asesores financieros como para clientes. El folleto tambin expona lo que la compaa estaba haciendo en materia de calidad en el servicio. Por supuesto que la compaa solo publicaba estndares una vez que estaba segura de poder cumplirlos y estaba comprometida con esto. Desde una perspectiva estratgica la comunicacin de estndares y esfuerzos organizacionales reforz la posicin de Equity & Law como una empresa que ofrece servicios y productos de primera calidad.

47

CALIDAD DE SOFTWARE

Identifique qu medir, y monitoree. Para obtener una medida cuantitativa que refleje o describa las caractersticas de cualquier objeto o concepto, se crean instrumentos capaces de realizar dicha medicin. Los instrumentos usados para estas descripciones a travs de nmeros no son perfectos, sin embargo, se debe cuidar que sean lo suficientemente confiables y vlidos para que los resultados obtenidos en cualquier investigacin sean, a su vez, tiles. En conclusin como se ha visto es claro que la definicin del a calidad consta en gran medida en el cliente, esto claro sin dejar de lado los mtodos los medios o las circunstancias del entorno ya sea del producto o del servicio. Pudiendo existir los estndares o mtodos que dictan procedimientos para as ayudar a clarificar la forma adecuada de ofrecerle al cliente lo mejor.

48

CALIDAD DE SOFTWARE

1.4 Importancia de la calidad. Pues bien, se supone y as se plantea tericamente que la implementacin del sistema de la calidad garantiza el hecho o por lo menos en un alto porcentaje de que las caractersticas del producto o del servicio cumplan con los requisitos del cliente, o lo que es lo mismo satisfaga sus necesidades y expectativas, luego de aqu se concluye la importancia de la implementacin del sistema de gestin de la calidad para cualquier organizacin y es la forma ideal de garantizar el porcentaje de ventas necesario para la sustentabilidad de la empresa. Teniendo ya claridad acerca de la importancia para la organizacin de implementar un sistema de gestin de la calidad pasamos al segundo punto de la disertacin y es la asimilacin del concepto de calidad, segn lo define la norma ISO 9000 versin 2000(figura 10).

Figura 10. ISO 9000 versin 2000.

Partamos de la definicin de calidad tal y como aparece textualmente en la norma "Grado en que un conjunto de caractersticas inherentes cumple con unos requisitos" Expliquemos detalladamente esta definicin, iniciemos con el trmino "Conjunto de caractersticas inherentes" y tomemos un producto como referencia, (usted amigo lector tambin puede tomar cualquier producto como ejemplo) todo producto o servicio posee un conjunto de caractersticas que le son inherentes lo cual lo hace diferente a los dems, como son el color, tamao, peso, forma, material del que est fabricado etc. Para el caso de un servicio las caractersticas pueden ser amabilidad en la atencin, rapidez, informacin clara, etc.; estas caractersticas inherentes son las que la empresa puede manipular, controlar y modificar, son aquellos elementos reales y concretos con los que los trabajadores lidian a diario y tambin aquellas con las que el cliente tiene contacto, es decir, puede palpar, observar etc. El segundo trmino a explicar es "requisitos" el cual la misma norma define como "Necesidad o Expectativa establecida generalmente implcita u obligatoria."

49

CALIDAD DE SOFTWARE

A diferencia de las caractersticas del producto o servicio que estn bajo el control de la empresa, los "requisitos" dependen fundamentalmente del cliente y son la concrecin o representacin de sus necesidades y expectativas por lo que tenemos, de un lado, al cliente con sus necesidades y expectativas, es decir con sus "requisitos," y por el otro, a la empresa con unos productos o servicios con unas determinadas caractersticas, pues bien el grado en que las caractersticas inherentes de un producto o servicio "cumplen" con unos requisitos (necesidades y expectativas) del cliente es lo que se conoce como Calidad. As podemos ver como la calidad no es algo misterioso ni difcil de entender, sino algo con lo que la organizacin trabaja a diario, claro est que si la empresa elabora productos con unas caractersticas que no tienen nada que ver con los requisitos del cliente o sea, sin tener en cuenta las necesidades y expectativas de ste, estar muy lejos de fabricar productos de calidad y por consiguiente de venderlos, pero si por el contrario, toma como base para el diseo y fabricacin del producto los requisitos del cliente los cuales debe conocer de antemano, estar fabricando productos cada vez de mejor calidad y por lo tanto llamara la atencin del cliente quien fcilmente pagar por ellos. La calidad en la organizacin de una empresa, debe ser el nervio y motor de la misma; si de verdad la empresa desea alcanzar el xito debe cimentarse en estas dos palabras. El mensaje de la calidad debe ser comunicado a tres audiencias que son complementarias entre s: Los Trabajadores. Los Proveedores; y, Los Clientes. Los fundamentos de la calidad son los siguientes: -El objetivo bsico: la competitividad -El trabajo bien hecho. -La Mejora continuada con la colaboracin de todos: responsabilidad y compromiso individual por la calidad. -El trabajo en equipo es fundamental para la mejora permanente -Comunicacin, informacin, participacin y reconocimiento. -Prevencin del error y eliminacin temprana del defecto. -Fijacin de objetivos de mejora. -Seguimiento de resultados. -Indicadores de gestin. -Satisfacer las necesidades del cliente: calidad, precio, plazo. -Los obstculos que impiden el avance de la calidad pueden ser: -El hecho de que la direccin no defina lo que entiende por calidad. -No se trata de hacer bien las cosas, sino de que el cliente opine igual y est satisfecho. -Todos creen en su concepto, pocos en su importancia y son menos los que la practican. La Calidad es una estrategia que busca garantizar, a largo plazo, la supervivencia, el crecimiento y la rentabilidad de una organizacin optimizando su competitividad, mediante: el aseguramiento permanente de la satisfaccin de los clientes y la eliminacin de todo tipo de desperdicios. Esto se logra con la participacin activa de todo el personal, bajo nuevos estilos de liderazgo; siendo la estrategia que bien aplicada, responde a la necesidad de transformar los productos, servicios, procesos estructuras y cultura de las empresas, para asegurar su futuro.

50

CALIDAD DE SOFTWARE

Para ser competitiva a largo plazo y lograr la sobrevivencia, una empresa necesitar prepararse con un enfoque global, es decir, en los mercados internacionales y no tan slo en mercados regionales o nacionales. Pues ser excelente en el mbito local ya no es suficiente; para sobrevivir en el mundo competitivo actual es necesario serlo en el escenario mundial. Para adoptar con xito esta estrategia es necesario que la organizacin ponga en prctica un proceso de mejoramiento permanente. El proceso de conversin de personas comunes y corrientes a trabajadores excelentes se facilita si en las nuevas contrataciones se logra incorporar a personas que muestren aptitudes y actitudes compatibles con el cambio que se proponga. Para esto el proceso de seleccin no solo debe limitarse a identificar habilidades especficas y evaluar conocimientos tcnicos y experiencia que se exigen para un determinado puesto, sino a encontrar personas con: Capacidad creativa y de liderazgo. Polivalencia para despear ms de una funcin. Habilidad para trabajar en equipo. Habilidad para comunicarse e interrelacionarse. Capacidad para mejorar y reconocer errores, etc.

Esta forma de proceder distinta a la tradicional, implica disear un perfil ms exigente pero ms interesante ya que deber contemplar aspectos relacionados con los valores de la empresa, orientados hacia la Calidad, que en el pasado no se han considerado, salvo excepciones. En el contexto de la Calidad se recomienda que la seleccin de personal nuevo se haga preferiblemente para los cargos de nivel operativo, y que los cargos de mayor responsabilidad se cubran con promociones y ascensos del personal de la propia empresa. Es importante que en las entrevistas participen los directivos y formulen preguntas que permitan apreciar el grado de identificacin con las actitudes que se desean. Concluida la SELECCIN viene el proceso de INDUCCIN que consiste en hacer conocer al nuevo personal los principales aspectos de la cultura de la organizacin, como son: la visin, la misin, valores y las polticas de calidad. Esto de ser posible debe ser explicado por el mximo directivo como suelen hacerlo las organizaciones que vienen implantando procesos de Calidad. En esta etapa las personas seleccionadas debern recibir toda la informacin general relacionada con la empresa, sobre el proceso de calidad, sus derechos y deberes, las funciones y responsabilidades especficas de su cargo, la rotacin de cargos prevista etc. Deben ser presentados ante quienes sern sus compaeros de trabajo, a fin de que conozca a sus clientes y proveedores internos. Es necesario invertir el tiempo necesario en este proceso de Induccin para que el trabajador nuevo logre involucrarse y adquiera el compromiso inicial y se obtenga de el una actitud favorable hacia la Calidad. Para una buena labor de Induccin la empresa deber organizar y preparar con la debida anticipacin toda la documentacin que es requerida para este fin, incluyendo medios audiovisuales, cartillas, plan de rotacin de cargos, etc.

51

CALIDAD DE SOFTWARE

Por ltimo, podemos concluir que la importancia de implementar un sistema de calidad, radica en el hecho de que sirve de plataforma para desarrollar al interior de la organizacin, una serie de actividades, procesos y procedimientos, encaminados a lograr que las caractersticas del producto o del servicio cumplan con los requisitos del cliente, en pocas palabras sean de calidad, lo cual nos da mayores posibilidades de que sean adquiridos por este, logrando as el porcentaje de ventas planificado por la organizacin.

52

CALIDAD DE SOFTWARE

1.5 La Calidad y el Mundo Globalizado. La tendencia de la globalizacin, se ha convertido en la realidad actual de todo el mundo, ya no solo con el objetivo de aglomerarse en sectores, sino tambin, de formar bloques competitivos tanto comerciales como de cualquier ndole. Esto ya que hemos percibido que el mundo es una aldea global, en la cual se requiere continua colaboracin entre los aldeanos de esta Aldea global para lograr un objetivo comn. El TLC es parte del aspecto comercial y econmico de la globalizacin. TLC, son las siglas del Tratado de Libre Comercio, una visin inteligente del capitalismo, y ms an del imperialismo estadounidense, muchas veces un TLC equilibrado (de acuerdo a los pases que lo firman), y otras veces para explotar pases. En nuestro caso es una relacin de involucramiento casi obligatorio para pases latinoamericanos del tercer mundo, de lo contrario, quedaran aislados a la globalizacin econmica y comercial de la regin, claro est solo los pases que convienen ser explotados, es decir, EE.UU. no firmara con Hait ni aunque le suplicaran, pero en Repblica Dominicana, hay mas facilidades de explotacin. Este tratado de libre comercio, pretende establecer un bloque americano de continuo comercio internacional entre los pases pactados. Los principales objetivos de un TCL son: Eliminar barreras que afecten o mermen el comercio. Promover las condiciones para una competencia justa. Incrementar las oportunidades de inversin. Proporcionar una proteccin adecuada a los derechos de propiedad intelectual. Establecer procesos efectivos para la estimulacin de la produccin nacional. Fomentar la cooperacin entre pases amigos. Ofrecer una solucin a controversias. [5]

Podemos considerar la competitividad como factor importante del tratado, si el pas no es altamente competitivo, con mejor produccin y calidad, etc., es un pas desaventajado, es este el criterio. En realidad no son novedades los tratados de esta naturaleza, en varios pases se han establecido convenios de este tipo, como apertura a la globalizacin. En nuestro contexto, la visin de Repblica Dominicana ante el TLC sera catastrfica para muchos sectores econmicos nacionales, y de lo contrarios para unos pocos. Tan solo imaginmonos que habra una reduccin significativa en el aporte tributario al presupuesto nacional, ya que el tratado contempla una baja arancelaria circunstancial, lo que quiere decir que muchos productos y artculos posiblemente estarn exentos de impuesto y otros con impuestos bajos, por consiguiente los ingresos al estado seran reducidos. Otro aspecto negativo que le continuara a ste, sera el desplome de muchos de los productos y artculos netos dominicanos ante productos extranjeros y ms an con mejor calidad, a menos precios, establecindose un abusivo abastecimiento en el mercado dominicano de esos productos importados a bajo o tal vez sin impuesto. Este ltimo punto afecta agresivamente al sector productivo nacional, que se vera opacado principalmente por EE.UU., que impondra sus productos a nuestro mercado, lo que exterminara al sector opacado, entonces ya podramos percibir la desaparicin del sector

53

CALIDAD DE SOFTWARE

arrocero dominicano, y la economa caera va agricultura nacional, este es solo uno de los tantos sectores que seran reprimidos. El punto que nos sepultara en nuestra propia tumba, es la competitividad, "competir ante EE.UU. no nos sera fcil en aspectos de comercio". No tan solo sera competir, si no es que nuestro pas no est preparado, tanto en aspectos tecnolgicos en algunos sectores; mano de obra cara en otros; mala calidad en otros, etc. Y estos son unos pocos de los aspectos negativos, pero veamos algo positivo. Siempre que negociamos algo, lo hacemos a nuestra conveniencia, y los beneficios deben ser mayores que lo que perderamos, tal vez no es el caso de nuestro pas en el TLC. Un gran beneficio tangible, sera la instalacin de nuevas zonas francas, lo que generara empleos, etc. Otro gran beneficio es obtener productos extranjeros a bajo precio y de alta calidad en nuestras puertas y tambin el flujo constante de mercancas y por consiguiente dinero. Tan solo hemos destacados unos pocos aspectos negativos y positivos, como siempre, lo negativo resalta, pero en conclusin, es una puerta al futuro capitalista con muy cuantioso costo para nosotros, por eso cada vez ms debemos ser de los mejores hasta ser el mejor, as mismo seran nuestros productos y calidad. Ulrich Beck desarrolla siete tesis contra el hombre globalizado. Es un documento interesante e inteligente. Una de sus tesis sin embargo parece ingenua. Beck considera que el capital no es un elemento que se autocontroles, sino que necesita un control externo para no caer en los ya conocidos abusos que ha construido a lo largo de la Historia cada vez que se lo ha dejado librado a sus propias fuerzas y conciencia. El ltimo ejemplo palpable fue el del S. XIX por no citar el actual. Beck cree que el capital ser controlado y debe ser controlado por el consumidor. Es el consumidor con su poder de compra el que pone coto al capital y lo obliga a actuar de una manera responsable y til para la sociedad. Este es el razonamiento que consideramos ingenuo. El consumidor es un ser que se ve expuesto a cierto elementos que lo hacen en definitiva no solo un controlador intil sino ms bien un aliado del capital abusivo. Esto ocurre desde distintas vas que se unen todas para que el producto final sea un individuo deseoso de servir al capital. La primera va es la televisin. La tan criticada televisin es sin embargo la que queda a cargo de los nios, ya que los padres estn ocupados en nuestro mundo. La televisin es la que les ensea que es lo que vale la pena y pocos padres hacen el contrapeso necesario, aunque algunos lo intentan. De hecho el nio crece con un mensaje de que es lo que interesa y adems con la relacin con un referente especifico, la televisin. Los padres sienten este efecto a travs de los pedidos que los nios hacen de ciertos bienes y no de otros, aquellos que han sido anunciados. Los padres no sienten el efecto de otros valores que se van manifestando a lo largo del tiempo. As, cuando el nio es adolescente y luego adulto, sigue recibiendo la informacin de su referente, la televisin y tiene establecido un puente psicolgico no declarado pero efectivo. Lo que la televisin dice es criticado, pero es al mismo tiempo tomado en cuenta y lo que la televisin anuncia tiene un efecto deletreo en la persona que arrasa con cualquier otro mensaje. El adolescente, el adulto, compra eso que le anuncian.

54

CALIDAD DE SOFTWARE

Otro eje que coincide en que el consumidor no pueda ser el controlador del capital es el precio. Adems de la calidad, el precio es sin duda un elemento importante. Frente a bienes caros el consumidor se ve eliminado por falta de poder adquisitivo o cuanto menos se ve detenido a pensar si realmente quiere gastar tanto dinero. Cuando el bien es barato, la compra es casi automtica. Ahora bien el bien es barato cuando los precios sucesivos son bajos, empezando por el de fabricacin. La invasin de los productos del Oriente son el resultado de una mano de obra barata y en general explotada; los bienes que se producen en los talleres de las capitales donde las personas estn encerradas y trabajan seis o siete das en la semana, duermen en el lugar, comen y respiran en l las veinticuatro horas, son bienes baratos, porque las personas ganan remuneraciones ridculas o trabajan solamente por la casa y la comida. Esto no es un triste privilegio de una ciudad, sino de muchas, desde Nueva York en ms, donde la polica hace la vista gorda porque se dice que la economa rica necesita que se cubra la franja de los bienes baratos y porque es pagada por los productores para que no intervenga. As el consumidor tiene bienes baratos que compra rpidamente, asocindose al capital explotador de otros seres humanos que no podrn nunca comprarse estos bienes ni muchos otros. El tercer eje por el cual el consumir no podr ser el controlador del capital es la competencia. No hablamos de la competencia en la fabricacin ni en la venta, sino de la competencia en el tener. Cmo puede una persona aceptar que su vecino tenga un televisor ms grande sin hacer nada al respecto? Y no digamos si cambia el auto o si el hijo est usando una bicicleta con cambios. Que pasa cuando una amiga se compra un modelo de marca? Qu pasa cuando el otro cambia la raqueta de tenis? El mundo consumista est basado en una cualidad nsita en el ser humano: la envidia (o los celos si se lo quiere mirar de otra manera). Todos los seres humanos tenemos celos/envidia en alguna medida. El consumismo ha hecho hincapi en esa cualidad para incitar al consumidor a que tenga ms que el otro. Hay que ganar y cuando se dice hay que ganar no se piensa en que hay que ganar en ser solidario o amable, sin que se dice que hay que ganar ms dinero, tener ms cosas y otros temas por el estilo. As pues, cuando Beck dice que el capital debe ser y podr ser controlado por el consumir, es ingenuo o apela a un ltimo acto de desesperacin en vista de que al capital no hay quien lo controle y hace lo que se le da la gana. El capital hoy en da construye donde est prohibido, trafica droga por donde quiere, consigue contratos inauditos del Estado, presiona a las personas a hacer ms hasta donde quiere y hace lo que siempre ha hecho cuando no ha tenido enfrente a una sociedad con otros valores que no fueran el dinero. El capital seguir haciendo lo que quiera hasta que nos demos cuenta que globalizacin no significa explotacin. Neo-liberalismo significa explotacin, pero la globalizacin se ha dado ya en el pasado sin que fuera necesario recurrir a extremos. Se puede estar globalizado y tener otros valores adems del dinero. La plutocracia es una cosa, la globalizacin es otra y el neo-liberalismo es otra. Lo que ha ocurrido es que plutocracia y neo-liberalismo se han identificado en una sola cosa y han usado el concepto de globalizacin para presionar a los Estados a travs de entidades internacionales para aplicar las polticas que convenan. Pero Beck no podr nunca ver en nuestra sociedad como el consumidor controla al capital y ms bien ver como el consumidor se ala con el capital para poder tener lo que se supone que tiene que tener para ser tenido en cuenta en nuestra sociedad.

55

CALIDAD DE SOFTWARE

1.6 Calidad de Vida. La calidad de vida es el bienestar, felicidad, satisfaccin de la persona que le permite una capacidad de actuacin o de funcionar en un momento dado de la vida. Es un concepto subjetivo, propio de cada individuo, que est muy influido por el entorno en el que vive como la sociedad, la cultura. [6] Segn la OMS, la calidad de vida es: "la percepcin que un individuo tiene de su lugar en la existencia, en el contexto de la cultura y del sistema de valores en los que vive y en relacin con sus objetivos, sus expectativas, sus normas, sus inquietudes. Se trata de un concepto muy amplio que est influido de modo complejo por la salud fsica del sujeto, su estado psicolgico, su nivel de independencia, sus relaciones sociales, as como su relacin con los elementos esenciales de su entorno". [6] El ser humano es un ser integral que se desenvuelve dentro de un ambiente; en l influye un sinnmero de caractersticas biolgicas, psicolgicas, sociales y espirituales. Est dotado de conciencia, inteligencia, voluntad, intencionalidad, afectividad y creatividad, en sntesis, de una personalidad, que obedece a su ubicacin temporal (momento histrico) y espacial (lugar donde habita). El individuo, como se ha mencionado, es una totalidad imposible de separar en sus dimensiones, ya que no es fcil establecer cunto influye una sobre las otras o cunto depende la una de las otras frente al proceso salud-enfermedad. Para efectos didcticos se hace necesario separar al ser humano, de manera que podamos navegar por las dimensiones que lo constituyen, para conseguir aprehender y comprender mejor la complejidad de su atencin integral en salud en aras de mejorar su calidad de vida. Luis Alfonso Vlez sostiene que el concepto que tengamos del ser humano depende de nuestra cosmovisin, es decir, de la percepcin de nuestro yo y del mundo que nos rodea. Dicha percepcin, segn Vlez, es el resultado de la ciencia, la filosofa y las creencias adquiridas por cada uno de nosotros. Al tiempo destaca que: Toda persona debe introspectar los datos y experiencias vividas, analizarlos y formarse su propia idea del ser humano, a esto se lo denomina: cultura. Todos los filsofos, desde Scrates, han insistido en la necesidad de escarbar dentro de s, como nico mtodo para llegar a la verdadera sabidura y entender al otro. Samuel Ramos, mdico y filsofo, habla sobre el nuevo humanismo y sostiene que, lejos de haberse restablecido la armona y el equilibrio del ser humano, el hombre se halla desorientado entre la multitud de cosas que lo dominan: La voluntad propia del individuo, sus sentimientos, sus aspiraciones, su vocacin, sus fuerzas se revuelven impotentes bajo la mscara que le ha puesto el mundo exterior. Este autor afirma que el problema se origina en una falsa valoracin que tergiversa los valores, es decir, los invierte, y en la ausencia de una escala estimativa de ndole universal. La verdadera tragedia de los tiempos actuales es carecer de una tabla ideal de valores, de donde se saquen las normas para regular la conducta de los hombres. Hoy en da podemos observar que el individuo no ha entendido cmo vivir en el mundo real; sin embargo, se enfrenta a una nueva cultura consistente en cmo vivir en el ciberespacio. El individuo siempre est en una lucha constante en aras de la conservacin de su integridad.

56

CALIDAD DE SOFTWARE

Retomemos al profesor Vlez, quien define al ser humano a partir de tres dimensiones: El Yo, el Otro y el Universo. La percepcin del yo la describe como la percepcin ms profunda y existencial. Dice, adems, que cuando analizamos qu somos, brota inmediatamente el dualismo cuerpo-alma, materia-espritu. Esta concepcin es herencia del racionalismo cartesiano. Descartes hablaba de la res extensa, la cual puede mensurarse, y de la res cogitans, no mensurable; de aqu se deriv el concepto de que el humano est compuesto de cuerpo, formado por clulas y de un principio vital situado en la pineal o en otro sitio. La misma ciencia moderna, tal como lo seala el autor mencionado, ha revaluado este concepto dualista, pues no se puede trazar una lnea entre la materia y el principio vital. Vlez plantea que el ser humano tiene caractersticas propias, tales como: Poder exceder los instintos, conciencia del pasado, inquietarse por el futuro, capacidad de intimidad, a las que agregamos la inteligencia emocional, reconocida en el individuo y estudiada por Colernan", y que hoy en da es considerada de gran valor. De igual manera es preciso mencionar las concepciones de Morrr sobre el pensamiento complejo del individuo. Cuando se habla del Otro, un componente importante en las sociedades actuales, donde el conflicto es el pan de cada da, resulta imperioso trabajar sobre esta relacin, pues el proceso de desarrollo de la humanidad ha hecho que la sociabilidad cada da sea ms necesaria, y hoy en da se realiza a velocidades inimaginables por el uso de nuevos sistemas tecnolgicos. La muerte es no poder comunicarnos, o porque no nos entienden o porque no podemos expresarnos (Pier Paolo Passolini). Lo importante en la relacin con el otro no es slo conocerlo sino respetarlo, ayudarlo a convertirse en un mejor ser y crecer junto a l sin miedos y temores, ya que stos son la contradiccin del amor. El Universo, el ltimo elemento citado por Vlez, es bsicamente la relacin armnica del hombre y la mujer con lo que los rodea; a ello se refiere no slo el entorno material sino el cultural. Esta relacin con el universo implica entonces relaciones biolgicas, sicolgicas y ecolgicas. Cabreras, estudioso de las relaciones ecolgicas y respeto a la totalidad, dice: Todos somos parte de este planeta y a todos nos compite salvarlo porque es nuestro hogar. Las palabras de este autor fomentan el respeto por la biodiversidad y las relaciones con el todo. Si se ahonda ms en detalles del ser humano, podemos ver cmo ste participa en una serie de procesos sociales que lo influencian; es parte de un contexto variable, entre otros, el de tipo familiar, donde requiere una estimulacin afectiva e intelectiva para el desarrollo cognitivoafectivo; el de tipo poblacional inmerso en una dinmica socio-demogrfica que implica un crecimiento poblacional que se manifiesta tanto a nivel global como regional no acorde con el crecimiento econmico. El mismo est influido por mltiples eventos: localizacin geogrfica, el ndice de concentracin poblacional, la densidad poblacional, flujo de desplazados, la escolaridad, el estado de la vivienda y de los ingresos; el de tipo ambiental y socioeconmico: las relaciones ecolgicas, la influencia de poder, la poltica econmica, el grado de pobreza, la redistribucin de los ingresos, el desempleo, el deterioro de las empresas, la falta de polticas gubernamentales para el impulso del desarrollo, incremento de viviendas sin condiciones ambientales, el efecto de las externalidades, carencia de servicios pblicos y pobre participacin comunitaria, gestin y control comunitario y relaciones comunicativas poco afectivas. El individuo como una totalidad tambin se relaciona con la cultura; cualquiera que sea el concepto que se utilice, ste va a estar influenciado por ella. Este hecho determina el significado del proceso salud-enfermedad, ya que cuando hablamos de l en los pases

57

CALIDAD DE SOFTWARE

occidentales, su significado probablemente es diferente del que se tiene en los pases orientales. Aun dentro de un mismo pas estas diferencias son marcadas; as tenemos comunidades para los cuales el centro de salud y / o el hospital es sinnimo de enfermedad, y no visualizan la importancia de los programas de promocin y de prevencin que en ellos se brindan. De igual forma influye en l la adopcin de valores, conocimientos, creencias y actitudes. Estas ltimas son una parte de los elementos que influyen en el diario vivir de las personas como en los conceptos de salud. Las creencias suelen ser el resultado de los conocimientos e informaciones que van pasando de generacin en generacin, habitualmente con muy pocas modificaciones y con gran tendencia a perpetuarse en las nuevas generaciones. Podemos mencionar el caso de los desplazados; la forma de afrontar sus problemas va a depender de su capacidad de adaptacin. Todos estos aspectos se tienen en cuenta al momento de interactuar con el ser humano, para poder dinamizar las variables que influyen en l, puesto que si la tendencia de sus creencias persiste y en esa direccin siempre se piensa y acta con relacin a la salud, y no se utilizan las propias experiencias y cambios que ocurren en la sociedad y el ambiente, se estarn limitando las posibilidades de actualizar las mismas experiencias y eventualmente modificar situaciones indeseables que afectan la salud. El carcter social se complementa con las variables que corresponden a la dimensin individual, entre las que se definen la dimensin psicolgica o subjetiva; son de particular importancia las conductas asociadas a los hbitos y costumbres, tales como: higiene, nutricin, descanso, actividad fsica, hbitos de compartir con la familia, compaeros de trabajo y con la comunidad, y de compartir con nosotros mismos en la intimidad. Para una atencin integral podran examinarse las siguientes conductas de riesgo: prcticas asociadas con servicios de salud, rgimen de medicacin, higiene, condicin fsica, abuso de tabaco y alcohol, as como las destrezas de adaptacin y conductas de salud positivas como patrones de respuesta a estmulos positivos: conocimiento sobre promocin de salud, redes de apoyo, actividades vocacionales, recursos mentales y espirituales, no presentar sntomas o malestares relacionados con patologas y sus posibles factores protectores. El desarrollo individual y familiar, a lo largo de las distintas etapas tanto del ciclo individual como familiar, presenta una serie de retos: los cambios sensoriales, paso de nio o nia a adolescente, de adolescente a adulto, de adulto joven a adulto mayor. Muchos de estos retos requieren realizar ajustes y redefinir nuevos papeles sociales y condiciones biolgicas, tales como: el retiro, los cambios en la actividad psicomotora y las prdidas que acompaan las distintas etapas del ciclo de vida; todas estas variables se investigan en salud para transformar situaciones no deseadas en aras de mejorar la salud. El logro del bienestar pleno fsico, social y emocional se asocia tambin con la satisfaccin de una serie de necesidades personales: el alcance de la autonoma a travs de la participacin, membreca grupal, solidaridad, tranquilidad, relaciones de ayuda, seguridad personal, auto anlisis, valoracin, formar parte de un ambiente gratificante, la satisfaccin de proximidad afectiva, as como la oportunidad de continuar con el aprendizaje y la expresin creativa, el desarrollo del talento y el proceso de socializacin, son otros elementos adicionales que se deben considerar en el momento de la atencin. El bienestar espiritual suele ser una dimensin psicosocial de creciente importancia y cambio en el transcurso de la vida. La espiritualidad adquiere una dimensin distinta cuando se define en funcin de valores filosficos que orientan la conducta, en vez de prcticas organizadas de

58

CALIDAD DE SOFTWARE

adoracin y cultos especficos, pero stas de alguna manera influyen en el proceso saludenfermedad. Se considera que el estudio integral del ser humano implica conocer no slo el enfoque biolgico de la persona sino el psicosocial. Es por ello que se a venido insistiendo en el desglosamiento de las variables que podran ser considerados en el momento de atencin, elementos fundamentales en su nuevo rol en el universo yen los recin conformados sistemas ambientales. Es preciso mencionar nuevamente que slo en la interaccin armnica de esas dimensiones podemos considerar al ser humano en una dimensin plenamente integral. Por lo que la calidad de vida se define en trminos generales como el bienestar, felicidad y satisfaccin de un individuo, que le otorga a ste cierta capacidad de actuacin, funcionamiento o sensacin positiva de su vida. Su realizacin es muy subjetiva, ya que se ve directamente influida por la personalidad y el entorno en el que vive y se desarrolla el individuo. Segn la OMS, la calidad de vida es "la percepcin que un individuo tiene de su lugar en la existencia, en el contexto de la cultura y del sistema de valores en los que vive y en relacin con sus expectativas, sus normas, sus inquietudes. Se trata de un concepto muy amplio que est influido de modo complejo por la salud fsica del sujeto, su estado psicolgico, su nivel de independencia, sus relaciones sociales, as como su relacin con los elementos esenciales de su entorno". Un indicador comn para medir la calidad de vida es el ndice de Desarrollo Humano (IDH), establecido por las Naciones Unidas para medir el grado de desarrollo de los pases a travs del Programa de las Naciones Unidas para el Desarrollo (PNUD), cuyo clculo se realiza a partir de las siguientes variables: Esperanza de vida. Educacin, (en todos los niveles). PNB per Cpita. Los pases con el IDH ms alto son Islandia, Noruega, Australia, Suecia, Canad y Japn. De Latinoamrica, Argentina, Chile, Uruguay y Costa Rica. (Figura 11).

59

CALIDAD DE SOFTWARE

Figura 11. Pases con ms alto IDH.

Por lo que se puede concluir que a lo largo del tiempo, el concepto de Calidad de Vida ha sido definido como la calidad de las condiciones de vida de una persona, como la satisfaccin experimentada por la persona con dichas condiciones vitales, como la combinacin de componentes objetivos y subjetivos, es decir, Calidad de Vida definida como la calidad de las condiciones de vida de una persona junto a la satisfaccin que sta experimenta, y, por ltimo, como la combinacin de las condiciones de vida y la satisfaccin personal ponderadas por la escala de valores, aspiraciones y expectativas personales, no obstante, se estaran omitiendo aspectos que intervienen directamente con la forma de interpretar o no las situaciones como positivas o no, es decir, aspectos que influyen la escala de valores y las expectativas de la personas: la cultura. Adicionando a las concepciones anteriores el aspecto cultural, se propone el siguiente modelo de calidad de vida (ver figura 3): considerando a priori que ya existe cobertura de ciertas necesidades bsicas para la sobrevivencia del ser humano, ya que si ellas no se encuentran cubiertas no puede ascenderse o construir. Pues bien, Se concibe al ser humano inmerso dentro de sociedad enmarcada en un lugar determinado (fsico e histrico) y una cultura que ha adquirido mediante socializacin; ambos elementos regulan e incluso limitan -si bien no de forma terminante- las concepciones de mundo del sujeto. Desde esta arista, el sujeto se ubica para evaluar ms o menos conciente lo que le acontece y, sin duda, no es sencillo, puesto que aquel proceso se encuentra mediado por una cantidad de factores anexos a los globales antes mencionados, por nombrar algunos: el nivel evolutivo, la comparacin con otros, su historia personal, el momento actual, las expectativas futuras, etc. Todo ello se conjuga y permiten que el sujeto a cada momento de la vida, la conciba de cierta forma, y la vivencie acorde a dicha evaluacin. Por ltimo, si bien se ha planteado calidad de vida desde una evaluacin mediada por una multiplicidad de factores, no podemos obviar las caractersticas personales, el estado que se adiciona al resto de los factores antes mencionados complejizando ms aun este proceso,

60

CALIDAD DE SOFTWARE

desde aqu recatamos la subjetividad, esta forma de concebir el mundo tan particular como humanos existen en la Tierra, que a la vez est mediada por el proceso de socializacin y la cultura en la cual se desenvuelve y lo regula. Pues bien, la calidad de vida es una categora multidimensional, presupone el reconocimiento de las dimensiones materiales, culturales, psicolgicas y espirituales del hombre, combate el concepto de hombre unidimensional y uniforme y obliga a desplegar mucha creatividad para aprender la diversidad humana. Lo anterior se acopla a la perfeccin a la mayora de las tendencias actuales quienes rechazan el concebir al humano como ser lineal, ello se considera obsoleto, ya que desde su misma corporalidad la complejidad el ser humano es indescriptible, por ello acercarse a los procesos desde una forma holstica permite mayor comprensin de esta madeja de factores mutuamente influyentes; por ello el concepto de Calidad de Vida depende en gran parte de la concepcin propia de mundo que tiene el sujeto en particular: la interpretacin y valoracin que le da a lo tiene, vive y espera. En otras palabras y a modo de sntesis se recalca el valor de la interpretacin que se realiza a los hechos y lo objetivo que se tiene en la vida, es decir, el valuarte inmensurable de lo subjetivo: "los lentes con los que nos paramos y vemos el mundo".

Figura 12. La calidad de vida desde la subjetividad

61

CALIDAD DE SOFTWARE

1.7 Calidad Total. La Calidad Total es el estadio ms evolucionado dentro de las sucesivas transformaciones que ha sufrido el trmino Calidad a lo largo del tiempo. En un primer momento se habla de Control de Calidad, primera etapa en la gestin de la Calidad que se basa en tcnicas de inspeccin aplicadas a Produccin. Posteriormente nace el Aseguramiento de la Calidad, fase que persigue garantizar un nivel continuo de la calidad del producto o servicio proporcionado. Finalmente se llega a lo que hoy en da se conoce como Calidad Total, un sistema de gestin empresarial ntimamente relacionado con el concepto de Mejora Continua (figura 13) y que incluye las dos fases anteriores. Los principios fundamentales de este sistema de gestin son los siguientes:

Figura 13. Ciclo de mejora contina.

Consecucin de la plena satisfaccin de las necesidades y expectativas del cliente (interno y externo). Desarrollo de un proceso de mejora continua en todas las actividades y procesos llevados a cabo en la empresa (implantar la mejora continua tiene un principio pero no un fin). Total compromiso de la Direccin y un liderazgo activo de todo el equipo directivo. Participacin de todos los miembros de la organizacin y fomento del trabajo en equipo hacia una Gestin de Calidad Total. Involucracin del proveedor en el sistema de Calidad Total de la empresa, dado el fundamental papel de ste en la consecucin de la Calidad en la empresa. Identificacin y Gestin de los Procesos Clave de la organizacin, superando las barreras departamentales y estructurales que esconden dichos procesos. Toma de decisiones de gestin basada en datos y hechos objetivos sobre gestin basada en la intuicin. Dominio del manejo de la informacin. La filosofa de la Calidad Total proporciona una concepcin global que fomenta la Mejora Continua en la organizacin y la involucracin de todos sus miembros, centrndose en la satisfaccin tanto del cliente interno como del externo. Podemos definir esta filosofa del siguiente modo: Gestin (el cuerpo directivo est totalmente comprometido) de la Calidad (los requerimientos del cliente son comprendidos y asumidos exactamente) Total (todo miembro de la organizacin est involucrado, incluso el cliente y el proveedor, cuando esto sea posible). La Calidad total es una estrategia que busca garantizar, a largo plazo, la supervivencia, el crecimiento y la rentabilidad de una organizacin optimizando su competitividad, mediante: el

62

CALIDAD DE SOFTWARE

aseguramiento permanente de la satisfaccin de los clientes y la eliminacin de todo tipo de desperdicios. Esto se logra con la participacin activa de todo el personal, bajo nuevos estilos de liderazgo; siendo la estrategia que bien aplicada, responde a la necesidad de transformar los productos, servicios, procesos estructuras y cultura de las empresas, para asegurar su futuro. Para ser competitiva a largo plazo y lograr la sobrevivencia, una empresa necesitar prepararse con un enfoque global, es decir, en los mercados internacionales y no tan slo en mercados regionales o nacionales. Pues ser excelente en el mbito local ya no es suficiente; para sobrevivir en el mundo competitivo actual es necesario serlo en el escenario mundial. Para adoptar con xito esta estrategia es necesario que la organizacin ponga en prctica un proceso de mejoramiento permanente. El proceso de conversin de personas comunes y corrientes a trabajadores excelentes se facilita si en las nuevas contrataciones se logra incorporar a personas que muestren aptitudes y actitudes compatibles con el cambio que se proponga. Para esto el proceso de seleccin no solo debe limitarse a identificar habilidades especficas y evaluar conocimientos tcnicos y experiencia que se exigen para un determinado puesto, sino a encontrar personas con: Capacidad creativa y de liderazgo, Polivalencia para despear ms de una funcin, Habilidad para trabajar en equipo, (figura 14) Habilidad para comunicarse e interrelacionarse y Capacidad para mejorar y reconocer errores etc.

Figura 14. Trabajo en Equipo

Esta forma de proceder distinta a la tradicional, implica disear un perfil ms exigente pero ms interesante ya que deber contemplar aspectos relacionados con los valores de la empresa, orientados hacia la Calidad Total. Que en el pasado no se han considerado, salvo excepciones. En el contexto de la Calidad Total se recomienda que la seleccin de personal nuevo se haga preferiblemente para los cargos de nivel operativo, y que los cargos de mayor responsabilidad se cubran con promociones y ascensos del personal de la propia empresa. Es importante que en las entrevistas participen los directivos y formulen preguntas que permitan apreciar el grado de identificacin con las actitudes que se desean.

63

CALIDAD DE SOFTWARE

Concluida la SELECCIN viene el proceso de INDUCCIN que consiste en hacer conocer al nuevo personal los principales aspectos de la cultura de la organizacin, como son: la visin, la misin, valores y las polticas de calidad. Esto de ser posible debe ser explicado por el mximo directivo como suelen hacerlo las organizaciones que vienen implantando procesos de Calidad Total. En esta etapa las personas seleccionadas debern recibir toda la informacin general relacionada con la empresa, sobre el proceso de calidad, sus derechos y deberes, las funciones y responsabilidades especficas de su cargo, la rotacin de cargos prevista etc. Deben ser presentados ante quienes sern sus compaeros de trabajo, a fin de que conozca a sus clientes y proveedores internos. Es necesario invertir el tiempo necesario en este proceso de Induccin para que el trabajador nuevo logre involucrarse y adquiera el compromiso inicial y se obtenga de el una actitud favorable hacia la Calidad Total. Para una buena labor de Induccin la empresa deber organizar y preparar con la debida anticipacin toda la documentacin que es requerida para este fin, incluyendo medios audiovisuales, cartillas, plan de rotacin de cargos, etc. Es necesario que la empresa estructure adecuadamente su Plan de Capacitacin en Calidad, destinado a todos los niveles de la organizacin, cuyos objetivos deben guardar correspondencia con los objetivos estratgicos de la organizacin. La elaboracin de este Plan debe estar a cargo del rgano encargado de promover y apoyar la implantacin el proceso de Calidad Total, debiendo tener la aprobacin del Comit o Consejo de Calidad, que ejerce el liderazgo a nivel de toda la organizacin. Los objetivos de la capacitacin deben: Explicar que es y en que consiste el proceso de Calidad Total (Figura 15) Promover la adopcin de valores de la cultura de calidad; Desarrollar habilidades de liderazgo y Habilidades para el aseguramiento y mejoramiento contino de la calidad.

64

CALIDAD DE SOFTWARE

Figura 15. Proceso de Calidad Total

Para el Plan de Capacitacin es necesario contar con la participacin del Asesor. Las primeras acciones de capacitacin deben orientarse a los Altos Directivos, debiendo cubrir temas como la Filosofa de la Calidad, con nfasis en el aspecto estratgico, los temas de Liderazgo, Tcnicas de trabajo en equipo, Tcnicas para la Solucin Estructurada de Problemas (Figura 16) y posteriormente otras tcnicas ms avanzadas. Todos deben ser capacitados en la filosofa, metodologas y tcnicas de la Calidad Total, pero en los niveles medios y operativos el nfasis en el nivel estratgico debe ser menor; ms bien debe prestarse ms atencin a las Tcnicas para el Mejoramiento.

65

CALIDAD DE SOFTWARE

Figura 16. Proceso de Solucin de Problemas

La capacitacin en Calidad Total debe buscar no slo la adquisicin de nuevos conocimientos sino el cambio de actitudes y de comportamiento. Debe tenerse en cuenta que ello no se logra slo con unas cuantas conferencias, se requiere de una accin permanente en la que se refuerce el aprendizaje con la prctica vinculada a su propio trabajo. Para que la capacitacin sea efectiva debe ser terico- prctica, emplear ejemplos de la propia organizacin o similares, ser dosificada, capacitar en aquello que va a ser utilizado y aplicar lo aprendido en el trabajo diario. A travs de un buen Plan de Capacitacin y Entrenamiento del personal podemos lograr que este adquiera los conocimientos y habilidades. Sin embargo esto no es suficiente para lograr su involucramiento. Para que las personas lo adopten, es preciso crear las condiciones que eviten la desmotivacin y faciliten la realizacin del trabajo. Por lo tanto, es necesario por un lado mejorar fsicamente el ambiente de trabajo eliminando todos los dems factores que causan desmotivacin como los que refiere Frederick Herzberg en su teora 'Higiene y Motivacin' y en el cual seala: - Polticas, normas y procedimientos inadecuados. - Trato inadecuado de los jefes hacia sus colaboradores y entre compaeros. - Salarios con falta de equidad. - Inestabilidad laboral. - Polticas de control inadecuadas. - Temor y bsqueda de culpables. - Sobrecarga de trabajo. - Inapropiada evaluacin del desempeo. - Procesos deficientes y engorrosos. - Rivalidades y Favoritismos, etc.

66

CALIDAD DE SOFTWARE

La eliminacin de estos factores si bien, como dice Herzberg no motivan; sin embargo su presencia produce insatisfaccin y desmotivacin. A continuacin se proponen algunas acciones para generar motivacin y compromiso: Aprecio: Significa hacer importantes a las personas, ofrecerles apoyo, desplazarse a sus puestos de trabajo para saludarlos y apreciar su trabajo, tratarlo por su nombre, animarlos en los momentos difciles, darles las gracias por sus esfuerzos. Sentido de Pertenencia: Hacindolos trabajar en equipo, los har sentir motivados y comprometidos. Participacin: Para canalizar sugerencias y mejorando su propio trabajo, as como para la solucin problemas. Delegacin y Autonoma: Esta es una de las formas ms eficaces para lograr un alto grado de motivacin y compromiso. Significa otorgar a los trabajadores para mejorar procesos. Reconocimiento: Se basa en el principio de que debe existir una diferencia entre quien se esfuerza en hacer bien las cosas y quien no obra as. De esta manera se valora la actitud de mejoramiento del trabajador y se refuerza su comportamiento en favor de la calidad. Otros de los puntos que propicia un ambiente es el trabajo en equipo, el cual se acostumbra a englobar formas de colaboracin que abarcan un espectro muy amplio; desde la ayuda mutua entre dos jefes de seccin que colaboran en un asunto que afecta a sus unidades hasta el trabajo conjunto de un Comit de Directivos. La misin de un equipo no se limita a una tarea especifica, tambin se refiriere a objetivos generales como el desempeo de un proceso completo o desarrollo de nuevos productos. Cuando se piensa en equipo y no individualmente cada persona se preocupa no slo por hacer bien su trabajo sino porque los dems hagan lo mismo. De esta manera si uno ve que alguien tiene problemas le proporciona ayuda por que quiere que el trabajo salga bien para el beneficio mutuo. El trabajo en equipo en todos los niveles de la organizacin implica que las personas basen sus relaciones en la confianza y el apoyo mutuo, la comunicacin espontnea, la comprensin y la identificacin con los objetivos de la organizacin. El trabajo en equipo requiere habilidades para comunicar, colaborar, entenderse y pensar con los dems. Cuando se da el verdadero trabajo en equipo se obtienen los siguientes comportamientos: Se ofrece ayuda a los compaeros sin que estos lo soliciten. Se solicita ideas a otros dndoles el crdito y reconocimiento. Se trabaja conjuntamente en la mejora de los productos, procesos y solucin de problemas. Se acepta sugerencias y se realiza crticas constructivas. Fomenta la bsqueda de mejores ideas y aumenta el compromiso para llevarlas a la prctica. Genera identificacin de las personas con los principios, valores e intereses de la organizacin y prelacin de los objetivos colectivos sobre los individuales. Genera colaboracin, confianza y solidaridad entre compaeros.

67

CALIDAD DE SOFTWARE

Desarrolla habilidades multifuncionales. Facilita la Delegacin de autoridad y autonoma. Elimina controles innecesarios, reduce procesos y correcciones. Facilita la capacitacin en las metodologas y tcnicas para el mejoramiento de la calidad y la productividad. Elimina barreras interfuncionales y promueve la retroalimentacin y soporte entre personas que manejan distintas disciplinas.

Las formas ms comunes de trabajo en equipo son: Consejo de Calidad: Es el responsable de establecer las directivas para la implantacin de la Calidad Total, aprobar los planes y brindar el apoyo requerido. Grupos Primarios: Responsable de disear, implantar y mejorar los procesos al nivel de una rea determinada; esta conformado por el Jefe del rea y un cierto nmero de trabajadores que dependen directamente del. Equipos de Mejoramiento: Son equipos nombrados por la empresa para realizar un proyecto determinado de mejora para la empresa. Crculos de Calidad. Son equipos permanentes de trabajadores voluntarios con funciones similares al equipo de mejoramiento que aplicando tcnicas de control de calidad resuelven problemas de su rea o de sus puestos de trabajo. Comits de Aseguramiento: Son equipos constituidos por representantes de las diferentes reas que influencian el buen desempeo de un proceso. Su funcin es asegurar la SATISFACCIN de los clientes y tomar las acciones correctivas y preventivas para evitar insatisfacciones. Equipos Autodirigidos: Son equipos de personas responsables de un proceso operativo completo. Los miembros comparten muchas de las responsabilidades tradicionalmente asignadas solo a jefes. Para poner en funcionamiento los equipos de trabajo, es necesario que se organicen convenientemente. En general un equipo debe estar integrado por un directivo, un Facilitador, el lder y los miembros. En algunos casos el lder puede ser el directivo. El directivo es el patrocinador que promueve la conformacin del equipo. Identifica las necesidades del equipo y le brinda las facilidades administrativas. El Facilitador es generalmente un asesor externo y propiamente no forma parte del equipo, pero debe participar en las reuniones y es quien se encarga de la capacitacin en las herramientas y tcnicas de Calidad Total como las habilidades de liderazgo, el trabajo en equipo, etc. El lder es quien dirige al equipo. Es la persona con mas experiencia y mas comprometido con la empresa. Debe coordinar las reuniones, velar por la asistencia de los miembros, coordinar la documentacin, definir el plan de accin, buscar la participacin los miembros en forma equitativa y buscar el consenso en las decisiones. Los miembros del equipo son personas involucradas en los proyectos de mejora. Deben ser conocedores de los detalles del proceso a mejorar. Tienen que estar interesados en

68

CALIDAD DE SOFTWARE

realizar esfuerzos para mejorarlo, participar en todas las reuniones, asistir con puntualidad y aportar con su inteligencia, experiencia y creatividad. La identificacin de los clientes de una organizacin debe iniciarse averiguando donde se encuentran los clientes externos y cuales son sus necesidades. A partir de all crear una obsesin por atender y exceder sus necesidades y expectativas. Elevar permanentemente el nivel de satisfaccin para conseguir su lealtad, la que debe medirse en trminos de como los clientes vuelven a adquirir los productos y servicios, y la recomendacin que hacen a otros para que los adquieran. Para satisfacer a los clientes no basta con eliminar los motivos de insatisfaccin o de quejas, es necesario asumir una actitud proactiva que conduzca a identificar los atributos de calidad que tienen impacto en la satisfaccin y deleitan a sus clientes. Estos atributos deben ser incluidos en los productos y servicios, y en todas las interacciones con ellos. Los clientes deben percibir que en los productos y servicios que adquieren hay una relacin de COSTO- BENEFICIO que les resulta favorable. Un primer aspecto para un enfoque al cliente consiste en definir y difundir la visin de la organizacin orientada a la satisfaccin de los clientes. El enfoque a los clientes va a definir las polticas de calidad y estas deben guiar las relaciones con los clientes. Los especialistas recomiendan tener en cuenta los siguientes aspectos: Despliegue de los requerimientos a las reas involucradas. Informacin proporcionada a los clientes con respecto a los productos y servicios y la forma de relacionarse con la organizacin. Facilidades para que el cliente exprese sus sugerencias, quejas y reclamos. Atencin de las quejas. Medicin de la satisfaccin de los clientes. Garantas, etc. Despus de establecerse por escrito la visin y polticas relacionadas con los clientes externos se debe difundir y explicar adecuadamente. Esta labor debe hacerse en el proceso de induccin del personal nuevo, en las acciones de capacitacin, en las relaciones jefe-subordinado, en las reuniones de trabajo, en los puestos de trabajo, en los puntos de venta y de servicio al cliente, etc. Pero lo ms importante es asegurar su aplicacin. Para satisfacer las necesidades y expectativas de los clientes tanto externos como internos es necesario conocerlos plenamente. Este conocimiento implica principalmente: Identificacin y segmentacin de los clientes Identificacin de los atributos de calidad de nuestros productos para los clientes. Lograr la conformidad de dichos atributos por los clientes Obtener de ellos sus apreciaciones de desempeo. En la mayora de las organizaciones existen dos tipos de clientes externos: Usuarios finales: son aquellos que consumen o utilizan el producto o servicio. Clientes Intermedios: son aquellos que hacen que el producto o servicio este disponible para el usuario final.

69

CALIDAD DE SOFTWARE

Para que una organizacin logre conocer con precisin a sus clientes es necesario que efecte una segmentacin en grupos homogneos, ya que no todos tienen las mismas necesidades y expectativas. Para identificar y segmentar a los clientes es conveniente proceder respondiendo a preguntas tales como: Quienes son los clientes de nuestros productos y servicios? Quienes son los usuarios finales? Cual es su distribucin por edades, sexo, escolaridad, ingresos, etc.? Cuando usan nuestro producto? Cual es si distribucin geogrfica? Que uso le dan a nuestros productos y servicios? Como los usan? Es recomendable utilizar para la segmentacin estrategias de mercadeo utilizando factores como tamao, capacidad econmica, entre otros. Luego de segmentarse a los clientes se debe identificar sus necesidades y expectativas presentes y futuras. Tambin es necesario identificar el grado de satisfaccin de los clientes con la empresa y con la competencia; para lo cual debe recurrirse a la tcnica del Benchmarking. Por otro lado la empresa debe contar con un sistema eficaz que le permita conocer adems de los aspectos negativos en relacin con la calidad, los atributos de calidad que verdaderamente lo satisfacen, es decir aspectos positivos de la calidad. Esto significa saber escuchar la voz del cliente. Para ello se puede hacer uso combinado de diferentes tcnicas como: Entrevistas. Sesiones de Grupo Foco (grupos de clientes con caractersticas similares) Encuestas de satisfaccin de los clientes (telefnicas o visitndolo) Observaciones del cliente cuando usa el producto. Observaciones recibidas del personal de servicio de soporte. Estudios de mercado. Anlisis de la competencia. Anlisis de quejas, reclamos y sugerencias. Los estudios para conocer la voz de los clientes no deben llevarse a cabo en forma aislada o espordica, sino que debe responder a acciones planificadas y sistemticas. Todo esto nos permitir conocer: Los atributos de calidad que son importantes para sus clientes. Las calificaciones dadas a su empresa por los clientes con dichos atributos. La comparacin con la competencia. Las quejas manifestadas a cerca de los atributos. Con la informacin proporcionada por los clientes, en todos sus aspectos, la empresa estar en condiciones de planificar la calidad de sus productos y servicios. Este proceso consiste en coordinar y establecer todo lo que hay que hacer para lograr la satisfaccin de los clientes. Al respecto el Dr. Juran, seala que este proceso establece las metas para la calidad, desarrollar los medios para alcanzarlas. Agrega que la planificacin para la calidad consiste en un conjunto de pasos bastante estandarizados que se resume en los siguientes: 1. Identificar los clientes tanto externos como internos.

70

CALIDAD DE SOFTWARE

2. Determinar las necesidades de los clientes. 3. Desarrollar las caractersticas de los productos en relacin con las necesidades de los clientes. 4. Establecer metas para las caractersticas de estos productos y desarrollar un proceso para cumplir las metas de los productos. 5. Comprobar que el proceso es capaz de funcionar en condiciones operativas. El Benchmarking es un proceso en virtud del cual se identifican las mejores prcticas en un determinado proceso o actividad, se analizan y se incorporan a la operativa interna de la empresa. Dentro de la definicin de Benchmarking como proceso clave de gestin a aplicar en la organizacin para mejorar su posicin de liderazgo encontramos varios elementos clave: Competencia, que incluye un competidor interno, una organizacin admirada dentro del mismo sector o una organizacin admirada dentro de cualquier otro sector. Medicin, tanto del funcionamiento de las propias operaciones como de la empresa Benchmark, o punto de referencia que vamos a tomar como organizacin que posee las mejores cualidades en un campo determinado. Representa mucho ms que un Anlisis de la Competencia, examinndose no slo lo que se produce sino cmo se produce, o una Investigacin de Mercado, estudiando no slo la aceptacin de la organizacin o el producto en el mercado sino las prcticas de negocio de grandes compaas que satisfacen las necesidades del cliente. Satisfaccin de los clientes, entendiendo mejor sus necesidades al centrarnos en las mejores prcticas dentro del sector. Apertura a nuevas ideas, adoptando una perspectiva ms amplia y comprendiendo que hay otras formas, y tal vez mejores, de realizar las cosas. Mejora Continua: el Benchmarking es un proceso continuo de gestin y auto-mejora. Existen varios tipos de Benchmarking: Interno: utilizando a la misma empresa como base de partida para compararnos con otros. Competitivo: estudiando lo que la competencia hace y cmo lo hace. Fuera del sector: descubriendo formas ms creativas de hacer las cosas, Funcional (comparando una funcin determinada entre dos o ms empresas). Procesos de Negocio: centrndose en la mejora de los procesos crticos de negocio. Un proyecto de Benchmarking suele seguir las siguientes etapas: Preparacin: Identificacin del objeto del estudio y medicin propia. Descubrimiento de hechos: Investigacin sobre las mejores prcticas. Desarrollo de acciones: Incorporacin de las mejores prcticas a la operativa propia Monitorizacin y recalibracin. Las principales asociacin cliente-proveedor puede expresarse principalmente en las siguientes dimensiones: Desarrollo de nuevos productos: La empresa debe lograr que el proveedor le brinde su apoyo en el desarrollo de un nuevo producto, adecuando las caractersticas de las provisiones y aportando sugerencias tiles en relacin con los procesos, tecnologas, etc. Tecnologa: En este aspecto es importante el intercambio de informacin que facilite a ambas partes el proceso de industrializacin.

71

CALIDAD DE SOFTWARE

Costos: La empresa y sus proveedores deben coordinar el desarrollo de programas de reduccin de costos, en el marco del proceso de mejora continua. Capacitacin: El comprador debe propiciar y apoyar el desarrollo de acciones capacitacin y entrenamiento en aspectos relacionados con la calidad y el proceso de mejoramiento continuo, as como brindar asistencia tcnica a sus proveedores; a fin de que estos cumplan con todos los requisitos y se logre establecer la confianza en la relacin cliente proveedor. Logstica: En este aspecto se trata de lograr que se produzcan entregas justo a tiempo, reduciendo los stocks tanto por parte de los proveedores como por parte del cliente. Esto exige flexibilidad de los procesos productivos y mejora de la fiabilidad para garantizar la provisin de mercancas y servicios en el largo plazo y una capacidad de respuesta adecuada. Informacin: Debe establecerse un sistema que permita una comunicacin oportuna y eficaz entre el cliente y el proveedor, que facilite la coordinacin de los programas de produccin as como las entregas concertadas y la facturacin. Inversiones: A medida que la unin entre el comprador y su proveedor se va consolidando, es posible que la empresa cliente realice ciertas inversiones para mejorar los materiales y dems suministros del proveedor, con plena confianza de las partes involucradas. Control de proceso: La unin que se logra entre el cliente y el proveedor permite, y adems se hace necesario, que conozca y efecte inspecciones a los procesos del proveedor; e incluso el comprador puede participar en calidad de invitado en las auditorias del sistema de calidad que realiza el proveedor. Planes de largo plazo: La asociacin entre el cliente y su proveedor permite que ambos establezcan en comn estrategias y objetivos de mejora dentro de una perspectiva de largo plazo. En este sentido, a las personas encargadas de las compras les corresponde la tarea de promover y facilitar este intercambio y desarrollar un papel clave de coordinadores. Esta estrategia debe llevar a reducir el nmero de proveedores por cada tipo de material o componente que una empresa compre. Las principales actividades que se recomienda realizar para consolidar una estrategia de asociacin o unin entre una organizacin y su proveedor: Segmentacin, evaluacin y seleccin de los mejores proveedores: Con referencia a la seleccin de proveedores el Dr. Ishikawa seala que esta debe empezar con la peticin de muestras a un gran nmero de aspirantes. Un aspecto a resaltar en los planteamientos de este experto es que nunca hace referencia al precio. El objetivo es reducir progresivamente al mnimo el nmero de proveedores por cada tipo de insumo o servicio requerido, estableciendo con estos una relacin de largo plazo de mutua conveniencia y lealtad. Desde el punto de vista de la Calidad Total se considera que el proveedor debe reunir tres requisitos importantes: un buen producto, un buen sistema de control de calidad y una buena direccin o sistema de gestin. El proveedor debe demostrar capacidad para integrar innovaciones tecnolgicas y ser consciente de las obligaciones en cuanto a: precio, oportunidad en las entregas y adems del respeto por los secretos de la empresa.

72

CALIDAD DE SOFTWARE

Desarrollo de un Sistema de mejora de las Comunicaciones Visitas a las instalaciones de los proveedores Invitaciones a los proveedores seleccionados a conocer la empresa. Evaluacin de proveedores bajo Normas ISO 9000 Establecimiento de un sistema de medicin del desempeo de los proveedores. Involucramiento de los proveedores en la solucin de problemas y en el mejoramiento de los procesos. Esta accin implica comprometer al personal del proveedor en los equipos de mejoramiento encargados de eliminar los problemas que se presentan con respecto al manejo de los insumos y en el asesoramiento en el mejor aprovechamiento de los mismos. Apoyo en la implantacin de calidad certificada para eliminar las inspecciones en la recepcin. Extensin del programa de Calidad Total y de la Calidad Certificada hacia todos los proveedores. Establecimiento de un programa de entregas justo a tiempo La realizacin de estas y otras actividades deben desarrollarse en forma progresiva y en correspondencia con las etapas del proceso de mejoramiento hacia la Calidad Total. En otros trminos deben ser debidamente planeadas y desde luego concertadas con el proveedor. Es importante, por otro lado, que el proveedor comprenda la filosofa de la empresa cliente y que esta a su vez estudie y comprenda la filosofa de sus proveedores. En todo esto es importante tener en cuenta que el proveedor oportunamente estimulado y apoyado puede dar una contribucin insustituible de creatividad e innovacin tecnolgica en los suministros de su competencia y puede trabajar activamente para reducir continuamente los costos. Por ello una empresa debe compartir con sus proveedores aquellas experiencias que se relacionan con el proceso de mejoramiento hacia la Calidad Total.

73

CALIDAD DE SOFTWARE

UNIDAD II ASEGURAMIENTO DE LA CALIDAD DE SOFTWARE (SQA)

74

CALIDAD DE SOFTWARE

2.1 Relacin de la Ingeniera del software con SQA. Los componentes de los sistemas de informacin, son integrados por la ingeniera de software; aunado a ello, se encontraron las siguientes referencias: La aplicacin prctica de las ciencias computacionales y otras disciplinas, al anlisis, diseo, construccin y mantenimiento de software y a la documentacin asociada. Disciplina tecnolgica y administrativa orientada a la produccin sistemtica de productos de programacin, que son desarrollados y modificados a tiempo, dentro de un presupuesto definido.

Figura 17. Diagrama de Ingeniera de Software.

Los mtodos, procedimientos y herramientas son conjuntados en modelos conocidos como paradigmas. Existen varios paradigmas de la ingeniera de software, algunos de ellos son: cascada, prototipo, costo, espiral, entre otros. Se han identificado diversas definiciones acerca de la ingeniera de software. El ciclo de vida es el periodo de tiempo que empieza cuando un producto de software es concebido y termina cuando el producto ya no se encuentra disponible para su uso. Este ciclo de vida se compone de 5 etapas principales: (a) Planeacin, (b) Anlisis y Diseo, (c) Codificacin, (d) Pruebas, (e) Operacin y Mantenimiento.

75

CALIDAD DE SOFTWARE

Figura 18. Ciclo de vida del Software.

Objetivos bsicos de la ingeniera de software: 1. 2. 3. 4. 5. Satisfacer los requerimientos del cliente, Mejorar la calidad de los productos de software, Mejorar la productividad de los desarrolladores, Satisfaccin profesional de la gente dedicada al desarrollo, Incluir nuevas tecnologas que integran los objetivos anteriores.

Por otra parte, los mtodos procedimientos y herramientas son los elementos que integran la ingeniera de software, los cuales permiten el logro de los objetivos. El ciclo de vida que integran los sistemas de informacin incluye diversas etapas o fases. El nmero o clasificacin de ests, depende del enfoque de cada persona o autor. Independientemente del nmero de fases analizadas, se concluy que todas ellas integran un paradigma generalizado, donde interactan sinrgicamente la definicin el mantenimiento y el desarrollo de un sistema de informacin. Durante la fase de definicin, el desarrollo del sistema de informacin identifica la informacin a procesar, su funcin, rendimiento, interfaz y los criterios de validacin necesarios para definir un sistema correcto. As mismo, la fase de desarrollo se enfoca al cmo. Durante esta fase el desarrollador, intenta descubrir cmo han de implantarse los detalles de los procedimientos, cmo ha de trasladarse el diseo a un lenguaje de programacin y cmo ha de realizarse la prueba del producto.

76

CALIDAD DE SOFTWARE

Por otra parte la fase de mantenimiento se enfoca a la integridad de errores, adaptaciones requeridas por la evolucin del sistema de informacin y modificaciones de los requerimientos del cliente o usuario para reforzar o aumentar el sistema. Pressman define cada una de estas fases de la siguiente manera: a) Subsistemas de la fase de definicin, los sistemas de la fase de definicin se describen a continuacin: Anlisis: Define las razones y justificaciones de los sistemas de informacin. Planeacin: Estimacin de recursos, definicin de responsabilidades y actividades as como su secuencia de ejecucin. Anlisis de Requerimientos: Se define el qu de los sistemas de informacin.

b) Subsistemas de la fase de desarrollo, se describen a continuacin: Diseo: Convierte los requerimientos de los sistemas de informacin a representaciones, como tablas, grficas, basadas en lenguajes. Son estructuras de datos. Codificacin: Conversin del diseo de sistemas de informacin a instrucciones ejecutables por computadora. Prueba: Procedimientos para verificar que no existen errores.

c) Subsistemas de la fase de Mantenimientos, se describen a continuacin: Integridad: Eliminar errores que surgen en la etapa de prueba. Adaptacin: Adecuar el sistema de informacin al entorno externo. Funcionalidad nueva: Otorga funciones adicionales a los requerimientos originales del sistema de informacin.

La fase de planeacin y definicin, particularmente el subsistema de requerimientos de los sistemas de informacin. Se concluye al respecto que, con el fin de formalizar ms el proceso de desarrollo de productos de software, se cre el concepto de ingeniera de software. De una manera simple, la ingeniera de software puede ser definida como el establecimiento y uso de principios de ingeniera robustos, orientados a obtener econmicamente software que sea confiable y funciones eficientes sobre mquinas reales. Dentro del contexto de Ingeniera de Software, se tomar la definicin de calidad en el software propuesta por la organizacin internacional de estndares (ISO/IEC DEC 9126): La totalidad de caractersticas de un producto de software que tienen como habilidad, satisfacer necesidades

77

CALIDAD DE SOFTWARE

explcitas o implcitas. Otra definicin bastante completa de calidad en el software es la que se presenta ms adelante [35]: Se puede decir que el software tiene calidad si cumple o excede las expectativas del usuario en cuanto a: 1. 2. 3. 4. 5. Funcionalidad (que sirva un propsito), Ejecucin (que sea prctico), Confiabilidad (que haga lo que debe), Disponibilidad (que funcione bajo cualquier circunstancia) y Apoyo, a un costo menor o igual al que el usuario est dispuesto a pagar.

Resumiendo podemos decir, que la calidad de software se refiere a: Los factores de un producto de software que contribuyen a la satisfaccin completa y total de las necesidades de un usuario u organizacin. El aseguramiento de la Calidad de Software es una actividad esencial en cualquier empresa de software para asegurar la calidad de sus productos, y la competitividad frente a la oferta del mercado. Es un conjunto de actividades de la funcin general de la Direccin que determina la calidad, los objetivos y las responsabilidades." Se basa en la determinacin y aplicacin de las polticas de calidad de la empresa (objetivos y directrices generales). El aseguramiento o Administracin de la Calidad se aplica normalmente a nivel empresa. Tambin puede haber una gestin de la calidad dentro del aseguramiento de cada proyecto. El propsito de la Administracin de la Calidad de Software es, en primer lugar, entender las expectativas del cliente en trminos de calidad, y poner en prctica un plan Pro activo para satisfacer esas expectativas. Dado que la calidad est definida por el cliente, podra parecer que es completamente subjetiva. De cualquier forma, hay muchas cosas acerca de la calidad que pueden hacerse objetivamente. Esto requiere examinar cada una de las caractersticas individuales del software y determinar una o ms mtricas que pueden recolectarse para reflejar dichas caractersticas. Por ejemplo, una caracterstica de calidad puede ser que la solucin tenga la menor cantidad de errores. Esta caracterstica puede medirse contando los errores y defectos de la solucin. La Administracin de la Calidad no es un evento, en un proceso y una forma de pensamiento. Un producto de software consistente, de alta calidad no puede producirse a partir de un proceso malo. Existe la necesidad de un ciclo constante de medir la calidad, actualizar el proceso, medir otra vez, actualizar, etc. Para hacer que la administracin de calidad del software funcione, es vital recolectar mtricas. Si no se capturan mtricas ser difcil mejorar los procesos a partir de una iniciativa de administracin de calidad. Uno de los propsitos de la administracin de la calidad del software es encontrar errores y defectos en el proyecto tan pronto como sea posible. Entonces, un buen proceso de administracin de calidad tomar ms esfuerzo y costo. De cualquier manera, habr una gran recompensa al tiempo que el proyecto avanza.

Por ejemplo, es mucho ms fcil arreglar un problema con los requerimientos de negocio durante la fase de anlisis que tener que arreglar problemas durante las pruebas. En otras palabras, el equipo de proyecto debe intentar mantener una alta calidad durante el proceso de desarrollo de los productos de software, en vez de esperar arreglar problemas durante las pruebas cercanas al final del proyecto (o en el peor de los casos, cuando el cliente encuentra el problema despus que el proyecto se complet).

78

CALIDAD DE SOFTWARE

La ingeniera de software es, por definicin, un tipo de ingeniera y, por lo tanto, tiene el mismo conjunto de responsabilidades sociales que todas las otras ingenieras. Durante la historia de la computacin, una gran parte del trabajo de los profesionales de software se ha considerado como "desarrollo" que requiere aptitudes de lenguajes de programacin, pero muy poco de la disciplina de ingeniera. El Consejo de Acreditacin de Ingeniera y Tecnologa (ABET, Accreditation Board for Engineering and Technology) define ingeniera como la profesin en la que el conocimiento de las ciencias naturales y matemticas obtenido con el estudio, la experiencia y la practica se aplica con juicio para desarrollar formas de utilizar, de modo econmico, los materiales y fuerzas de la naturaleza para beneficio de la humanidad. Se ha pensado mucho en la ingeniera como una iniciativa humana desde mucho antes del surgimiento del software. En los albores de los aos 2000, la ingeniera de software comienza a exigir el mismo grado de disciplina en quienes la practican que otras ramas de la ingeniera como elctrica, mecnica y civil. En qu difiere la ingeniera de software de otros tipos de ingeniera y en qu es similar? Una propiedad que la ingeniera de software comparte con las otras es la necesidad de una descripcin exhaustiva de lo que debe producirse, un proceso llamado "anlisis de requerimientos". Por otra parte, los proyectos de software estn sujetos a cambios frecuentes, que incluyen los impuestos durante el desarrollo del producto. En las dcadas de 1980 y 1990, dos tendencias dominaron la ingeniera de software, Una fue el crecimiento explosivo de aplicaciones, incluidas las asociadas con Internet. La otra, el florecimiento de nuevas herramientas y paradigmas (formas de pensamiento, como la orientacin a objetos). Sin embargo, a pesar del advenimiento de nuevas tendencias, las actividades bsicas requeridas para la construccin del software han permanecido estables. La Ingeniera de software designa el conjunto de tcnicas destinadas a la produccin de un programa de computadora, ms all de la sola actividad de programacin. Forman parte de esta disciplina las ciencias computacionales y el manejo de proyectos, entre otros campos, propios de la rama ms genrica denominada Ingeniera informtica. Un objetivo de dcadas ha sido el encontrar procesos o metodologas predecibles y repetibles que mejoren la productividad y la calidad. La ingeniera de software requiere llevar a cabo muchas tareas, sobre todo las siguientes: Anlisis de requisitos: Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniera de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del anlisis de requisitos con el cliente se plasma en el documento ERS, Especificacin de Requerimientos del Sistema, cuya estructura puede venir definida por varios estndares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relacin, en el que se plasman las principales entidades que participarn en el desarrollo del software.

79

CALIDAD DE SOFTWARE

Especificacin: Es la tarea de describir detalladamente el software a ser escrito, en una forma matemticamente rigurosa. En la realidad, la mayora de las buenas especificaciones han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son ms importantes para las interfaces externas, que deben permanecer estables. Diseo y arquitectura: Se refiere a determinar como funcionar de forma general sin entrar en detalles. Segn Yourdon consiste en incorporar consideraciones de la implementacin tecnolgica, como el hardware, la red, etc. Se definen los casos de uso para cubrir las funciones que realizar el sistema, y se transforman las entidades definidas en el anlisis de requisitos en clases de diseo, obteniendo un modelo cercano a la programacin orientada a objetos.

Conversaciones con programadores experimentados y muchos que recin incursionan, toman las herramientas para el modelamiento y planificacin como algo que no sirve y solo har demorar su trabajo, sin sentido, mas que la misma perdida de tiempo en algo que ellos consideran sin importancia, ya que la programacin, segn dicen, no tiene nada que ver con Administracin. Muchas de las empresas, algunas con trayectoria, otras que recin inician, adolecen de este mal. El resultado, trabajos planificados para dos meses, que luego de los seis meses no se terminan, y cuando este software se termina, se desea revisar, es difcil reconocer que hacia cada parte del cdigo, incluso para su autor; claro si es que se llego al final del desarrollo, sobre tareas que nunca se planificaron y solo se echaron a andar, sin un norte definido. Pero todo esto no es nuevo, es un problema que trae muchos aos desde que se inicio la industria del desarrollo de software, y que pase a haber pasado ya bastante tiempo y existir herramientas para poder planificar todo esto de alguna forma, muchos de los actuales desarrolladores, aun se resisten a usar estas herramientas, excusndose en distintos argumentos, ya sea que la programacin no es administracin, o que no es documentacin, o la documentacin no sirve, cuando los programadores se resisten y no quieren hacer las cosas bien, existen muchos argumentos, hasta los mas pintorescos o irritables como Las metodologas no sirven. Y cuando los trabajos no salen como realmente se quiere. Tambin existen argumentos, como: El desarrollo de software no es como uno piensa, o era ms complicado de lo que se piensa, en fin, y en realidad, suele ser as, pero la nica razn, la falta de estudio del problema y su posterior planificacin. La Ingeniera de Software entonces nos ayuda a prevenir todos estos males, pero ms importante que usar la Ingeniera de Software para ayudar en los procesos de desarrollo de software, es que los programadores entiendan la importancia de esto. Adems de la importancia de esta rama, es importante saber que existen tambin certificaciones a la calidad de software como por ejemplo CMMI, que evala la capacidad de madurez de los procesos de desarrollo de software, el cual hace que un producto desarrollado por empresas con esta certificacin tenga un valor mucho mayor que las que no lo tienen. Tambin tenemos normas que contratantes exigen antes de decidir a que empresa desarrolladora confiaran sus necesidades de software, normas como la ISO/IEC 12207 o la

80

CALIDAD DE SOFTWARE

ISO/IEC 15504, que hablan sobre procesos desarrollo de software, que no es mas que Ingeniera de Software.

81

CALIDAD DE SOFTWARE

2.2. Definicin y Propsito del SQA. Segn la Norma ISO 9000:2000, el aseguramiento de la calidad es la parte de la gestin de la calidad orientada a proporcionar confianza en que se cumplirn los requisitos de calidad. El Aseguramiento de Calidad del Software es el conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza que el software satisfar los requisitos dados de calidad 11. Este aseguramiento se disea para cada aplicacin antes de comenzar a desarrollarla y no despus. El aseguramiento de la calidad del software engloba: (1) un enfoque de gestin de calidad, (2) mtodos y herramientas de Ingeniera del Software, (3) revisiones tcnicas formales aplicables en el proceso de software, (4) una estrategia de prueba multiescala, (5) el control de la documentacin del software y de los cambios realizados, (6) procedimientos para ajustarse a los estndares de desarrollo del software y (7) mecanismos de medicin y de generacin de informes. El aseguramiento de calidad dentro de la empresa es bsicamente un sistema documental de trabajo, en el cual se establecen reglas claras, fijas y objetivas, sobre todos los aspectos ligados al proceso operativo, es decir, desde el diseo, planeacin, produccin, presentacin, distribucin, servicio posventa y las tcnicas estadsticas de control del proceso y, desde luego, la capacitacin del personal. [7]

Las revisiones del software son un "filtro" para el proceso de Ingeniera del Software. Esto es, las revisiones se aplican a varios momentos del desarrollo del software y sirven para detectar errores y defectos que pueden ser eliminados. Las revisiones del software sirven para "purificar" las actividades de la Ingeniera del Software que suceden como resultado del anlisis, diseo y codificacin.

Figura 19. Revisin del Software.

La revisin tcnica formal (RTF), a veces llamada inspeccin, es el filtro ms efectivo desde el punto de vista del aseguramiento de la calidad y es un medio efectivo para mejorar la calidad del software. El defecto se define como una anomala del producto. Dentro del contexto del proceso del software, los trminos defecto y fallo son sinnimos. Ambos implican un problema de calidad que es descubierto despus de entregar el software a los usuarios finales.

82

CALIDAD DE SOFTWARE

El objetivo de la revisin formal (RTF) es descubrir errores en la funcin, la lgica la implementacin de cualquier producto del software durante el proceso de desarrollo del mismo, verificar que satisface sus especificaciones, que se ajusta a los estndares establecidos, sealando las posibles desviaciones detectadas. Es un proceso de revisin riguroso, su objetivo es llegar a detectar lo antes posible, los posibles defectos o desviaciones en los productos que se van generando a lo largo del desarrollo. Esta caracterstica fuerza a que se adopte esta prctica nicamente para productos que son de especial importancia, porque de otro modo podra frenar la marcha del proyecto. [8] Las actividades de diseo introducen entre el 50 y 65% de todos los errores durante el proceso de software. Sin embargo, se ha demostrado que las RTF son efectivas en un 75% a la hora de detectar errores. Con la deteccin y la eliminacin de un gran porcentaje de errores, el proceso de revisin reduce substancialmente el coste de los pasos siguientes en las fases de desarrollo y mantenimiento. Los objetivos de la RTF son: (1) Descubrir errores en la funcin, la lgica o la implementacin de cualquier representacin del software, (2) Verificar que el software bajo revisin alcanza sus requisitos, (3) Garantizar que el software ha sido representado de acuerdo con ciertos estndares predefinidos, (4) Conseguir un software desarrollado en forma uniforme y (5) Hacer que los proyectos sean ms manejables. La RTF sirve para promover la seguridad y la continuidad, ya que vanas personas se familiarizarn con partes del software que, de otro modo, no hubieran visto nunca. Es una clase de revisin que incluye recorridos, inspecciones, revisiones s cclicas y otro pequeo grupo de evaluaciones tcnicas del software. Cada RTF se lleva a cabo mediante una reunin y solo tendr xito si es bien planificada, controlada y atendida. El aseguramiento de calidad se refiere a validar los procesos usados para crear los productos. Es una herramienta especialmente til para administradores y patrocinadores, ya que permite discutir los procesos usados para crear los productos para determinar si son razonables. Este aseguramiento tiene asociado 2 constitutivos diferentes: los Ingenieros de Software que realizan el trabajo tcnico y un grupo de SQA (Software Quality Assurance) que tiene la responsabilidad de la planificacin de aseguramiento de la calidad, supervisin, mantenimiento de registros, anlisis e informes. El concepto de calidad se ha ampliado con el transcurso del tiempo, para reflejar un enfoque de la organizacin, ms que exclusivamente de produccin. En lugar de concebir la calidad como el control del nmero de productos defectuosos que se producen, la calidad se considera ahora como un proceso evolutivo hacia la perfeccin, que se denomina el aseguramiento de la calidad total (TQA). El nfasis en la calidad se ha desplazado desde los niveles operativos hacia la alta direccin, ocasionado un incremento de la atencin en la productividad administrativa. La informacin relativa a la evolucin del desempeo dentro de los negocios se ha vuelto cada vez ms comn entre el personal de todos los niveles. La aceptacin de la "administracin por objetivos" acompaado de las tcnicas de administracin participativa, han implicado que los empleados se preocupen por s mismos de su desempeo, as como de su

83

CALIDAD DE SOFTWARE

evaluacin. Esto es importante en relacin con el aseguramiento de la calidad total, ya que este concepto funciona solo si cada individuo esta involucrado en un trabajo de calidad. El incremento del compromiso de las empresas hacia el TQA coincide con los objetivos del anlisis y diseo de sistemas. La Calidad Total en Informtica, es resultado del movimiento global dentro del proceso de mejoramiento continuo de los estndares de produccin en todos los sectores industriales, en particular, en la produccin de sistemas de informacin y software especializado. La demanda de software y la complejidad del producto en s, parecen crecer a mayor velocidad que las metodologas, el personal capacitado y las herramientas para automatizar la produccin. A pesar de la incorporacin de herramientas CASE (Computer Assisted Software Engineering), la produccin de software contina siendo una actividad con alta participacin de recursos humanos, cien por cien intelectual y en cierto sentido, sin insumos ni materias primas. Estas circunstancias han producido una prolongada crisis del software, donde los productos se entregan con demoras, los desarrollos exceden lo inicialmente presupuestado y no cumplen con los requerimientos originales. Esta problemtica se extiende tanto a la enorme dificultad de proporcionar mantenimiento, como al cumplimiento de criterios de calidad. Con un nivel bajo de calidad, el cuello de botella se presentar en el esfuerzo de mantenimiento que, en la actualidad, requiere de una tasa de desarrollo y produccin entre tres y diez veces ms rpida que antes. Una forma de lograr la gestin y el aseguramiento de la calidad en la produccin de software consiste en la implantacin de un programa de calidad total en la produccin de software. Estos programas implican necesariamente el establecer un compromiso muy fuerte en todos los niveles de la organizacin y entre todas las partes involucradas en la produccin, incluyendo los servicios y el mantenimiento despus de la venta. Un programa de gestin y aseguramiento de la calidad comienza por elegir un modelo y establecer una definicin de calidad. Siendo los dos siguientes pasos importantes dentro del ciclo contino de un programa de calidad: El control de la calidad y la garanta de la calidad. Calidad se puede definir como "una caracterstica o atributo de una cosa". De esta forma se podra decir que la calidad de los productos puede medirse como una comparacin de sus caractersticas y atributos y as, este concepto puede aplicarse a cualquier producto. Uno de los principales objetivos de dar calidad a los productos es minimizar las diferencias entre unidades producidas. Para obtener una definicin aceptable de calidad del software como producto, se hace uso de los conceptos: medida y mtrica. Una medida puede definirse como la evaluacin de una variable de control. Es necesario recalcar que no es fcil hacer deducciones sobre una medida. : Por ejemplo, una medida de un programa es el nmero de lneas de cdigo o el tiempo que tarda un usuario en manejar bien el programa. Una mtrica es la combinacin de dos medidas, las cuales conducen a la valuacin de una unidad de control. Por ejemplo, el total de defectos sobre el nmero de lneas de cdigo es una mtrica de la calidad de programacin, y cuando esta mtrica se eleva, podemos inferir que los programadores estn siendo menos cuidadosos o que existe otro problema. Otra mtrica es el nmero de funciones de un programa sobre el tiempo promedio que toma a usuarios inexpertos

84

CALIDAD DE SOFTWARE

el dominio del mismo. Esta ltima puede categorizarse como una mtrica de la facilidad de asimilacin Para controlar la calidad, los niveles directivos deben establecer y monitorear conjuntos de mtricas, que les proporcionen informacin suficiente para actuar con base a hechos. El conjunto de medidas que maneja cada directivo debe concordar con su capacidad de accin para poder actuar efectivamente y garantizar calidad. El aseguramiento de la calidad a lo largo del proceso de desarrollo de un sistema reduce los riesgos y ayuda a que el sistema resultante sea el que necesitamos y deseamos. Son tres los enfoques con que dispone el analista para garantizar la calidad durante el anlisis y diseo a travs de la ingeniera de software: Diseo de sistemas y de software con un enfoque descendente y modular. El diseo y la documentacin de los sistemas y del software mediante el uso de mtodos sistemticos. La evaluacin y prueba se los sistemas y del software, de tal forma que se les pueda dar fcil mantenimiento y realizarles auditorias.

Son dos las ideas subyacentes para el aseguramiento de la calidad: El usuario es el elemento ms importante para establecer y evaluar la calidad. Gran proporcin de la responsabilidad de la calidad del SI descansa en los usuarios y en los administradores de los sistemas. A travs del trabajo de los crculos de calidad deben desarrollar los lineamientos para establecer estndares de calidad de los sistemas de informacin. Se espera que contribuyan con conocimientos sobre la operacin de su Departamento y lo que consideraran una calidad aceptable para la entrada, el procesamiento y la salida del sistema. Esto evita errores costosos o que se comiencen desarrollos innecesarios. Es menos costoso corregir problemas en sus etapas iniciales que esperar que el usuario exprese sus quejas o que la crisis se evidencie: las inspecciones estructuradas de rutina permite detectar errores o problemas potenciales para que el responsable realice los cambios correspondientes. Se realiza al concluir una porcin de codificacin, un subsistema o un sistema.

SQA implica revisar y auditar los productos y actividades de software para verificar que se cumplen los procedimientos y los estndares, adems de proveer a las gerencias apropiadas (incluyendo a la de proyectos) con los resultados de estas revisiones. Por lo tanto, SQA envuelve al PROCESO de desarrollo de software completo: monitoreando y mejorando el proceso; asegurndose que cualquier Standard y procedimientos adoptados sean seguidos; y, asegurndose que los problemas sean encontrados y tratados.

85

CALIDAD DE SOFTWARE

2.3 Problemas que resuelve la SQA. Los desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman, y la apariencia seductora de los errores clsicos es una de las razones de que esos errores se cometan tan a menudo. Pero debido a que se han cometido muchas veces, sus consecuencias se han hecho fciles de predecir. Y los errores rara vez producen los resultados que la gente espera. A continuacin aparecen algunos de los errores clsicos relacionados con las personas.

Figura 20. Errores clsicos.

1. Motivacin dbil: Estudio tras estudio ha mostrado que la motivacin probablemente tiene mayor efecto sobre la productividad y la calidad que ningn otro factor (Boehm 1981). Ejemplo: directivos que a lo largo de todo el proyecto toman medidas que minan la moral: como dar nimos a diario al principio para pedir horas extras en la mitad, y como irse de vacaciones mientras el equipo esta trabajando incluso los das de fiesta, para dar recompensas al final del proyecto que resultan ser de menos de un dlar por cada hora extra. 2. Personal mediocre: Despus de la motivacin, la capacidad individual de los miembros del equipo, as como sus relaciones como equipo, probablemente tienen la mayor influencia en la productividad (Boehm, 1981; Lakhanpal, 1993). Contratar apurando el fondo del barril supondr una amenaza al desarrollo. Ejemplo, hacer la seleccin del personal buscando quin puede contratarse ms rpido, en vez de quin realizar la mayora del trabajo durante la vida del proyecto. Esta tcnica consigue un inicio rpido del proyecto, pero no determina un final rpido. 3. Empleados problemticos incontrolados: Un fallo al tratar con personal problemtico tambin amenaza la velocidad de desarrollo. Un fallo al tomar una decisin cuando se trata con un empleado problemtico es una de las quejas ms comunes que tienen los miembros del equipo respecto de sus responsabilidades (Larson y La fasto, 1989). Ejemplo, el equipo sabe que uno de ellos es una manzana podrida, pero el jefe del equipo no hace nada. El resultado es predecible: rehacer el trabajo de la manzana podrida. 4. Hazaas: Algunos desarrolladores de software ponen un gran nfasis en la realizacin de hazaas en los proyectos (Bach, 1995). Pero lo que hacen tiene ms de malo que de

86

CALIDAD DE SOFTWARE

bueno. Ejemplo, los directivos de nivel medio dan mayores aplausos a actitudes del tipo ser capaz de que a los progresos firmes y consistentes y a los informes significativos de progreso. El resultado es un modelo de planificacin al lmite en el que las amenazas de desajuste del plan no se detectan, no se conocen o ni se informan a la cadena de directivos hasta el ltimo minuto. Un pequeo equipo de desarrollo y sus jefes inmediatos toman como rehenes a una compaa entera por no admitir que tiene problemas para cumplir su plan. El nfasis en los comportamientos heroicos fomenta correr un riesgo extremo, e impide la cooperacin entre los mltiples elementos que contribuyen al proceso de desarrollo del software. Algunos directivos fomentan el comportamiento heroico cuando se concentran con demasiada firmeza en actitudes del tipo "ser capaz de". Elevando estas actitudes por encima de informes del estado exactos, y a veces pesimistas, los directivos de estos proyectos coartan su capacidad de tomar medidas correctivas. Ni siquiera saben que tienen que emprender acciones correctoras hasta que el dao ya est hecho. Como dijo Tom DeMarco, las actitudes ser capaz de convierten pequeos contratiempos en autnticos desastres (DeMarco, 1995). 5. Aadir ms personal a un proyecto retrasado: Este es quizs el ms clsico de los errores clsicos. Cuando un proyecto se alarga, aadir ms gente puede quitar ms productividad a los miembros del equipo existente de la que aaden los nuevos miembros. Fred Brooks compara aadir gente a un proyecto retrasado con echar gasolina en un fuego (Brooks, 1975). 6. Oficinas repletas y ruidosas: La mayora de los desarrolladores consideran sus condiciones de trabajo como insatisfactorias. Alrededor del 60 por 100 indican que no tienen suficiente silencio ni privacidad (DeMarco y Lister, 1987). Los trabajadores que estn en oficinas silenciosas y privadas tienden a funcionar significativamente mejor que aquellos que ocupan cubculos en salas ruidosas y repletas. Los entornos repletos y ruidosos alargan los planes de desarrollo. 7. Fricciones entre los clientes y los desarrolladores: Las fricciones entre los clientes y los desarrolladores pueden presentarse de distintas formas. A los clientes pueden parecerles que los desarrolladores no cooperan cuando rehsan comprometerse con el plan de desarrollo que desean los clientes o cuando fallan al entregar lo prometido. A los desarrolladores puede parecerles que los clientes no son razonables porque insisten en planes irreales o cambios en los requerimientos despus de que stos hayan sido fijados. Pueden ser simplemente conflictos de personalidad entre dos grupos. El principal efecto de esta friccin es la mala comunicacin, y los efectos secundarios de la mala comunicacin incluyen el pobre entendimiento de los requerimientos, pobre diseo de la interfaz de usuario y, en el peor caso, el rechazo del cliente a aceptar el producto acabado. En el caso medio, las fricciones entre clientes y desarrolladores de software llegan a ser tan severas que ambas partes consideran la cancelacin del proyecto (Jones, 1994). Para remediar estas fricciones se consume tiempo, y distraen tanto a desarrolladores como a clientes del trabajo real en el proyecto. 8. Expectativas pocos realistas: Una de las causas ms comunes de fricciones entre los desarrolladores y sus clientes o los directivos son las expectativas poco realistas.

87

CALIDAD DE SOFTWARE

Ejemplo, no tener razones tcnicas para pensar que un software se podr desarrollar en 6 meses, pero se es el plazo en que lo quiere el comit ejecutivo de la compaa. La incapacidad del jefe de proyecto para corregir esta expectativa irreal ser la principal fuente de problemas. En otros casos, los directivos o los desarrolladores de un proyecto se buscan problemas al pedir fondos basndose en estimaciones de planificacin demasiado optimistas. Aunque por s mismas las expectativas irreales no alargan el plan, contribuyen a la percepcin de que el plan de desarrollo es demasiado largo, y de que puede ser malo. Una inspeccin de Standish Group marc las expectativas realistas como uno de los cinco factores principales necesarios para asegurar el xito de los proyectos internos de software de gestin (Standish Group, 1994). 9. Falta de un promotor efectivo del proyecto: Para soportar muchos de los aspectos del desarrollo rpido es necesario un promotor del proyecto de alto nivel, incluyendo una planificacin realista, el control de cambios y la introduccin de nuevos mtodos de desarrollo. Sin un promotor ejecutivo efectivo, el resto del personal de alto nivel de la empresa puede forzar a que se acepten fechas de entrega irreales o hacer cambios que debiliten el proyecto. El consultor australiano Rob Thomstt afirma que la falta de un promotor efectivo garantiza virtualmente el fracaso del proyecto (Thomstt, 1995). 10. Falta de participacin de los implicados: Todos los principales participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto. Incluyendo a los promotores, ejecutivos, responsables del equipo, miembros del equipo, personal de ventas, usuarios finales, clientes y cualquiera que se juegue algo con el proyecto. La cooperacin estrecha slo se produce si se han implicado todos los participantes, permitiendo una coordinacin precisa del esfuerzo para el desarrollo rpido, que es imposible conseguir sin una buena participacin. 11. Falta de participacin del usuario: La inspeccin de Standish Group descubri que la razn nmero uno de que los proyectos de Sistemas de Informacin tuviesen xito es la implicacin del usuario (Standish Group, 1994). Los proyectos que no implican al usuario desde el principio corren el riesgo de que no se comprendan los requerimientos del proyecto, y son vulnerables a que se consuma tiempo en prestaciones que ms tarde retrasarn el proyecto. 12. Poltica antes que desarrollo: Larry Constantine indic que si hay cuatro tipos diferentes de orientaciones polticas (Constantine, 1995a). Los "polticos" estn especializados en la "gestin", centrndose en las relaciones con sus directivos. Los "investigadores" se centran en explorar y reunir la informacin. Los "aislacionistas" estn solos, creando fronteras para el proyecto que mantienen cerradas a los que no son miembros del equipo. Los "generalistas" hacen un poco de todo: establecen relaciones con sus directivos, realizan investigaciones y exploran actividades, y se coordinan con otros equipos como parte de su modo de trabajo. Constantine indic que inicialmente los equipos polticos y generalistas estn bien vistos por los directivos de alto nivel. Pero despus de un ao y medio, los equipos polticos llegan a la muerte sbita. Primar la poltica en vez de los resultados es fatal para el desarrollo orientado a la velocidad.

88

CALIDAD DE SOFTWARE

13. Ilusiones: Muchos problemas del desarrollo del software se deben a la ilusin. Cuntas veces hemos escuchado cosas como stas a distintas personas: "Ninguno de los miembros del proyecto cree realmente que pueda completarse el proyecto de acuerdo con el plan que tienen, pero piensan que quizs si trabajan duro, y nada va mal, y tienen un poco de suerte, sern capaces de concluir con xito". "Nuestro equipo no hace mucho trabajo para la coordinacin de las interfaces entre las distintas partes del producto, pero tenemos una buena comunicacin para otras cosas, y las interfaces son relativamente simples, as que probablemente slo necesitaremos un da o dos para eliminar los errores". "Sabemos que contamos con un desarrollador externo de poco talento para el subsistema de la base de datos, y que es difcil ver cmo va a acabar el trabajo con los niveles de personal que ha especificado en su propuesta. No tienen tanta experiencia como algunos de los dems desarrolladores externos, pero puede que compensen con energa lo que les falta en experiencia. Probablemente acaben a tiempo". "No necesitamos reflejar la ltima lista de cambios en el prototipo para el cliente. Estoy seguro de que por ahora sabemos lo que quiere. "El equipo est diciendo que realizar un esfuerzo extraordinario para cumplir con la fecha de entrega, y que no han llegado a su primer hito por pocos das, pero creo que alcanzarn ste a tiempo." Las ilusiones no son slo optimismo. Realmente consisten en cerrar los ojos y esperar que todo funcione cuando no se tienen las bases razonables para pensar que ser as. Las ilusiones al comienzo del proyecto llevan a grandes explosiones al final. Impiden llevar a cabo una planificacin coherente y pueden ser la raz de ms problemas en el software que todas las otras causas combinadas. Los errores relacionados con el proceso malgastan el talento y el esfuerzo del personal. A continuacin se muestran algunos de los peores errores relacionados con el proceso. 14. Planificacin excesivamente optimista. Los retos a los que se enfrenta alguien que desarrolla una aplicacin en tres meses son muy diferentes de aquellos a los que se enfrenta alguien que desarrolla una aplicacin que necesita un ao. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la planificacin efectiva, y reduciendo las actividades crticas para el desarrollo, como el anlisis de requerimientos o el diseo. Tambin supone una excesiva presin para los desarrolladores, quienes a largo plazo se ven afectados en su moral y su productividad. 15. Gestin de riesgos insuficiente. Algunos errores no son lo suficientemente habituales como para considerarlos clsicos. Son los llamados "riesgos". Como con los errores clsicos, si no ejercemos una gestin activa de los riesgos, con qu slo vaya mal una cosa se pasar de tener un proyecto con un desarrollo rpido a uno con un desarrollo lento. El fallo de no gestionar uno solo de estos riesgos es un error clsico.

89

CALIDAD DE SOFTWARE

16. Fallos de los contratistas. Las compaas a veces contratan la realizacin de partes de un proyecto cuando tienen demasiada prisa para hacer el trabajo en casa. Pero los contratados frecuentemente entregan su trabajo tarde, con una calidad inaceptable o que falla al no coincidir con las especificaciones (Boehm, 1989). Riesgos como requerimientos inestables o interfaces mal definidas pueden ser enormes cuando un contratado entre en escena. Si las relaciones con los contratados no se gestionan cuidadosamente, la utilizacin de desarrolladores externos pueden retardar el proyecto en vez de acelerarlo. 17. Planificacin insuficiente. Si no planificamos para conseguir un desarrollo rpido, no podemos esperar obtenerlo. 18. Abandono de planificacin bajo presin. Los equipos de desarrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en la planificacin (Humphrey, 1989). El problema no est en el abandono del plan, sino ms bien en fallar al no crear un plan alternativo, y caer entonces en el modo de trabajo de codificar y corregir. Ejemplo, un equipo abandona su plan despus de fallar en la primera entrega, y esto es lo habitual. A partir de este punto, el trabajo no tiene coordinacin ni elegancia. 19. Prdida de tiempo en el inicio difuso. El "inicio difuso" es el tiempo que transcurre antes de que comience el proyecto; este tiempo normalmente se pierde en el proceso de aprobar y hacer el presupuesto. No es poco comn que un proyecto desperdicie meses o aos en un inicio difuso, y entonces se est a las puertas de un plan agresivo. Es mucho ms fcil y barato y menos arriesgado suprimir unas pocas semanas o meses del inicio difuso en vez de comprimir el plan de desarrollo en ese mismo tiempo. 20. Escatimar en las actividades iniciales. Los proyectos se aceleran intentando acortar las actividades "no esenciales", y puesto que el anlisis de requerimientos, la arquitectura y el diseo no producen cdigo directamente, son los candidatos fciles. Los resultados de este error, tambin conocido como "saltar a la codificacin", son todos demasiado predecibles. Los proyectos que normalmente escatiman en sus actividades iniciales tendrn que hacer ese trabajo en otro momento, con un costo de 1 O a 100 veces superior a haberlo hecho bien inicialmente (Fagan, 1976; Boehm y Papaccio, 1988). Si no podemos encontrar cinco horas para hacer el trabajo correctamente la primera vez, cmo vamos a encontrar 50 para hacerlo correctamente ms tarde? 21. Diseo inadecuado. Un caso especial de escatimar en las actividades iniciales es el diseo inadecuado. Proyectos acelerados generan un diseo indeterminado, no asignado suficiente tiempo para l y originado un entorno de alta presin que hace difcil la posibilidad de considerar alternativas en el diseo. El nfasis en el diseo est ms orientado a la conveniencia que a la calidad, por lo que necesitar varios ciclos de diseo de poder finalizar completamente el sistema. 22. Escatimar en el control de calidad. En los proyectos que se hacen con prisa se suele cortar por lo sano, eliminando las revisiones del diseo y del cdigo, eliminando la planificacin de las pruebas y realizando slo pruebas superficiales. Acortar en un da

90

CALIDAD DE SOFTWARE

las actividades de control de calidad al comienzo del proyecto probablemente supondr de 3 a 10 das de actividades finales (Jones, 1994). 23. Control insuficiente de la directiva. Poco control de la directiva para detectar a tiempo los signos de posibles retrasos en el plan, y los pocos controles definidos al comienzo se abandonan cuando el proyecto comienza a tener problemas. Antes de encarrilar un proyecto, en primer lugar debemos ser capaces de decir si va por buen camino. 24. Convergencia prematura o excesivamente frecuente. Bastante antes de que se haya programado entregar un producto, hay un impulso para preparar el producto para la entrega, mejorar el rendimiento del producto, imprimir la documentacin final, incorporar entradas en el sistema final de ayuda, pulir el programa de instalacin, eliminar las funciones que no van a estar listas a tiempo y dems. En proyectos hechos con prisa, hay una tendencia a forzar prematuramente la convergencia. Puesto que no es posible forzar la convergencia del producto cuando se desea, algunos proyectos de desarrollo rpido intentan forzar la convergencia media docena de veces o ms antes de que finalmente se produzca. Los intentos adicionales de convergencia no benefician al producto, Slo son una prdida de tiempo y prolongan el plan. 25. Omitir tareas necesarias en la estimacin. Si la gente no guarda cuidadosamente datos de proyectos anteriores, olvida las tareas menos visibles, pero son tareas que se han de aadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 o 30 por 100 (Van Genuchten, 1991). 26. Planificar ponerse al da ms adelante. Un tipo de reestimacin es responder in apropiadamente el retraso del plan. Si hemos trabajado en un proyecto durante 6 meses, y hemos empleado tres meses en llegar al hito correspondiente a los dos meses qu hacer? En muchos proyectos simplemente se plantea recuperar el retraso ms tarde, pero nunca se hace. Aprenderemos ms del producto conforme lo estamos construyendo, incluyendo ms sobre lo que nos llevar construirlo. Estos conocimientos necesitan reflejarse en la reestimacin del plan. Otro tipo de error es la reestimacin que se debe a cambios en el producto. Si el producto que estamos construyendo cambia, la cantidad de tiempo necesaria para construirlo cambiar tambin. El crecimiento de las nuevas prestaciones sin ajustar el plan garantiza que no se alcanzar la fecha de entrega. 27. Programacin a destajo. Algunas organizaciones creen que la codificacin rpida, libre, tal como salga, es el camino hacia el desarrollo rpido. Piensan que si los desarrolladores estn lo suficientemente motivados, pueden solventar cualquier obstculo. Este enfoque muchas veces se presenta como un enfoque "empresarial" al desarrollo de software, pero realmente es slo la envoltura del viejo paradigma a destajo combinado con una planificacin ambiciosa, y esta combinacin raras veces funciona. Es un ejemplo de que dos negaciones no constituyen una verdad. A continuacin se muestran los errores clsicos relacionados con la forma en la que se define el producto.

91

CALIDAD DE SOFTWARE

28. Exceso de requerimientos. Algunos proyectos tienen ms requerimientos de los que necesitan, desde el mismo inicio. La eficiencia se fija como requisito ms a menudo de lo que es necesario, y puede generar una planificacin del software innecesariamente larga. Los usuarios tienden a interesarse menos en las prestaciones complejas que en las de las secciones de marketing o de desarrollo, y las prestaciones complejas alargan desproporcionadamente el plan de desarrollo. 29. Cambio de las prestaciones. Incluso si hemos evitado con xito los requerimientos excesivos, los proyectos sufren como media sobre un 25 por 100 de cambios en los requerimientos a lo largo de su vida (Jones, 1994). Un cambio de este calibre puede producir un aumento en el plan de al menos un 25 por 100, lo que puede ser fatal para los proyectos. 30. Desarrolladores meticulosos. Los desarrolladores encuentran fascinante la nueva tecnologa, y a veces estn ansiosos por probar nuevas prestaciones de su lenguaje o entorno, o por crear su propia implementacin de una utilidad bonita que han visto en otro producto, la necesite o no su producto. El esfuerzo requerido para disear, implementar, probar, documentar o mantener estas prestaciones innecesarias alarga el plan. 31. Tiras y aflojas en la negociacin. Cuando un directivo aprueba un retraso en el plan de un proyecto que progresa ms lento de lo esperado, y entonces aade tareas completamente nuevas despus de un cambio en el plan, se produce una situacin curiosa. La razn subyacente de esto es difcil de localizar, puesto que el directivo que aprueba el retardo en el plan lo hace sabiendo implcitamente que el plan estaba equivocado. Pero una vez que se corrige, la misma persona realiza acciones explcitas para volver a equivocarse. Esto slo puede ir en contra del plan. 32. Desarrollo orientado a la investigacin. Seymour Cray, el diseador de los supercomputadores Cray, dijo que no intentaba sobrepasar los lmites de la ingeniera en ms de dos reas a la vez, porque el riesgo de un fallo es demasiado alto (Gilb, 1988). Muchos proyectos software debern aprender la leccin de Cray. Si el proyecto fuerza los lmites de la informtica porque necesita la creacin de nuevos algoritmos o de nuevas tcnicas de computacin, no estamos desarrollando software. Los planes de desarrollo de software son razonablemente predecibles; los planes en la investigacin sobre software ni siquiera son predecibles tericamente. Si el producto tiene objetivos que pretenden aumentar los conocimientos existentes, como algoritmos, velocidad, utilizacin de la memoria y dems, debemos asumir que la planificacin es altamente especulativa. Si queremos mejorar el estado del arte y tenemos algn otro punto dbil en el proyecto, recortes de personal, debilidades en el personal, requerimientos vagos, interfaces inestables con contratados externos, etc., podemos tirar por la ventana la planificacin prevista. Si queremos superar el estado del arte por todos los medios, hagmoslo. Pero no debemos esperar hacerlo rpidamente! El resto de los errores clsicos estn relacionados con el uso correcto o incorrecto de la tecnologa moderna.

92

CALIDAD DE SOFTWARE

33. Sndrome de la panacea. A veces se confa demasiado en las ventajas proclamadas de tecnologas que no se han usado antes (generadores de informes, diseo orientado a objetos y C++) y se tiene poca informacin sobre lo buenas que seran en un entorno de desarrollo concreto. Cuando el equipo del proyecto se aferra slo a una nueva tcnica, una nueva tecnologa o un proceso rgido, y espera resolver con ello sus problemas de planificacin, est inevitablemente equivocado (Jones, 1994). 34. Sobreestimacin de las ventajas del empleo de nuevas herramientas o mtodos. Las organizaciones mejoran raramente su productividad a grandes saltos, sin importar cuntas nuevas herramientas o mtodos empleen o lo bueno que sean. Los beneficios de las nuevas tcnicas son parcialmente desplazados por las curvas de aprendizaje que llevan asociadas, y aprender a utilizar nuevas tcnicas para aprovecharlas al mximo lleva su tiempo. Las nuevas tcnicas tambin suponen nuevos riesgos, que slo descubriremos usndolas. Ms bien experimentaremos mejoras lentas y continuas en un pequeo porcentaje por proyecto en lugar de grandes saltos. Un caso especial de sobreestimaciones de las mejoras se produce cuando se reutiliza cdigo de proyectos anteriores. Este tipo de reutilizacin puede ser una tcnica muy efectiva, pero el tiempo que se gana no es tan grande como se espera. 35. Cambiar de herramientas a mitad del proyecto. Es un viejo recurso que funciona raramente. A veces puede tener sentido actualizar incrementalmente dentro de la misma lnea de productos, de la versin 3 a la 3.1, o incluso a la 4. Pero cuando estamos a la mitad de un proyecto, la curva de aprendizaje, rehacer el trabajo y los inevitables errores cometidos con una herramienta totalmente nueva, normalmente anulan cualquier posible beneficio. 36. Falta de control automtico del cdigo fuente. Un fallo en la utilizacin del control automtico del cdigo fuente expone a los proyectos a riesgos innecesarios. Sin l, si dos desarrolladores estn trabajando en la misma parte del programa, deben coordinar su trabajo manualmente. Deberan ponerse de acuerdo para poner la ltima versin de cada archivo en el directorio maestro y verificarlos con los dems antes de copiarlas en este directorio. Pero invariablemente alguno sobrescribir el trabajo del otro. Se desarrolla nuevo cdigo con interfaces desfasadas, y despus se tiene que redisear el cdigo al descubrir que se ha utilizado una versin equivocada de la interfaz. Los usuarios avisan de errores que no podemos reproducir porque no hay forma de volver a crear los elementos que han utilizado. Como media, los cambios manual del cdigo fuente no deberan crecer (Jones, 1994). Al analizar los errores que suceden con las personas, proceso, producto y tecnologa se ve claramente lo necesario que es el aseguramiento de la calidad del software mediante un buen plan de trabajo y de administracin de proyecto, el SQA bien implementado y manejado ayudara a la produccin de software de mayor calidad con un menor costo, aunque los costos de control y de la calidad aumenten en un corto plazo.

93

CALIDAD DE SOFTWARE

2.4 Calidad del software en el ciclo de vida del mismo. Dado que los proyectos son empresas nicas, estos implican un grado de incertidumbre. Las organizaciones que ejecutan proyectos dividirn, generalmente, cada proyecto en varias fases de proyecto a fin de mejorar el control de la gestin y para establecer vnculos con las operaciones continuas de la organizacin ejecutante. De forma colectiva, las fases del proyecto se conocen como ciclo de vida del proyecto. Cada fase del proyecto est determinada con el trmino de una o ms prestaciones. Una prestacin es un producto de trabajo tangible y verificable como puede ser un estudio de factibilidad, un diseo de detalle, o un prototipo funcional. Las prestaciones y, por ende las fases, son parte de una lgica generalmente secuencial diseada para asegurar la correcta definicin del producto del proyecto. La conclusin de una fase de proyecto est marcada, generalmente, por una revisin tanto de las prestaciones claves como del rendimiento / desempeo del proyecto a la fecha, a fin de a) determinar si el proyecto debe continuar a su siguiente fase y, b) detectar y corregir errores de forma costo-efectiva. Estas revisiones de fin de fases se conocen, comnmente, como salidas de fase, puertas de etapas o puntos muertos. Normalmente, cada fase de proyecto incluye un conjunto de prestaciones definidas diseadas para establecer el nivel deseado de control de gestin. La mayora de estos tems dice relacin con la principal prestacin de la fase, y las fases tpicamente toman sus nombres a partir de estos tems: requerimientos, diseo, construccin, prueba, puesta en marcha, etc., segn sea el caso. El ciclo de vida del proyecto sirve para definir el inicio y el trmino de un proyecto. Por ejemplo, cuando una organizacin identifica una oportunidad a la cual le gustara responder, a menudo esta autorizar una evaluacin de necesidades y/o un estudio de factibilidad con el objeto de decidir si debe o no abordar un proyecto. La definicin del ciclo de vida del proyecto determinar si el estudio de factibilidad ser o no tratado como la primera fase del proyecto o como un proyecto separado y singular. La definicin del ciclo de vida del proyecto determinar, adems, que tipo de acciones de transicin se incluyen al comienzo y al trmino del proyecto, y cules no. De esta manera, la definicin del ciclo de vida del proyecto puede utilizarse para ligar el proyecto con las operaciones continuas de la organizacin ejecutante. La secuencia de fases definida por la mayor parte de los ciclos de vida del proyecto, generalmente implica cierta forma de transferencia o manejo de tecnologa, como son los requerimientos para el diseo, la construccin para las operaciones, o el diseo para la fabricacin. Las prestaciones de la fase anterior se aprueban, generalmente, antes de que comience el trabajo en la siguiente fase. No obstante, a veces se inicia una fase posterior antes de la aprobacin de las prestaciones de la fase previa, toda vez que los riesgos involucrados sean considerados como aceptables. Esta prctica de traslapar fases se conoce a menudo como fast tracking.

Los ciclos de vida del proyecto definen generalmente:

94

CALIDAD DE SOFTWARE

Qu tipo de trabajo tcnico se debe realizar en cada una de las fases? (por ejemplo, Corresponde el trabajo a la parte arquitectnica de 13. fase de definicin o a la parte de la fase de ejecucin? Quin debera participar en cada una de las fases? (Por ejemplo, las personas a cargo de la implementacin, quienes deben estar involucrados con los requerimientos y el diseo).

Las descripciones de los ciclos de vida del proyecto pueden ser muy generales o muy detalladas. Las descripciones altamente detalladas pueden tener numerosos formatos, grficos y listas de verificacin con el objeto de proporcionar una estructura y consistencia. Tales enfoques o metodologas detalladas reciben frecuentemente el nombre de metodologas para la gestin de proyectos. La mayor parte de las descripciones de ciclo de vida de los proyectos comparten una cantidad comn de caractersticas: Los niveles de costos y dotacin son bajos al comienzo, ms altos hacia el final y caen rpidamente a medida que el proyecto se acerca a su trmino. Este patrn queda ilustrado en la Figura 4. La probabilidad de terminar exitosamente el proyecto es la ms baja y, por ende, tanto el riesgo como la incertidumbre son los ms altos al inicio del proyecto. La probabilidad de alcanzar un trmino exitoso se hace progresivamente mayor a medida que el proyecto contina. La capacidad de los clientes para influenciar en las caractersticas finales del producto del proyecto y en el costo final del proyecto es la ms alta al principio y se hace progresivamente menor a medida que el proyecto contina. Uno de los principales causantes de este fenmeno es que el costo cambia y, generalmente, aumenta la correccin de errores a medida que el proyecto contina.

95

CALIDAD DE SOFTWARE

Figura 21. Muestra de un Ciclo de Vida Genrico.

Hay que tener cuidado al momento de distinguir entre el ciclo de vida del proyecto y el ciclo de vida del producto. Por ejemplo, la realizacin de proyecto para introducir un nuevo computador al mercado es slo una fase o etapa del ciclo de vida del producto. Aunque muchos ciclos de vida de proyectos tienen nombres de fases similares donde se requieren prestaciones similares, slo unos pocos son idnticos. La mayora tiene cuatro o cinco fases, pero hay algunos que tienen nueve o ms. Incluso dentro de una sola rea de aplicacin, puede haber variaciones importantes - el ciclo de vida del desarrollo de software de una organizacin puede tener una sola fase de diseo, mientras que otro tiene fases separadas en cuanto a diseo funcional y de detalle. Los sub-proyectos dentro de los proyectos pueden tener tambin distintos ciclos de vida de proyectos. Por ejemplo, una oficina arquitectnica contratada para disear un nuevo edificio de oficinas se involucra primero con la fase de definicin del dueo al momento de realizar el diseo, y en la fase de implementacin del dueo, cuando se respalda la tarea de construccin. No obstante, el proyecto de diseo del arquitecto tendr su propia serie de fases desde la de desarrollo conceptual, pasando por la de definicin e implementacin hasta llegar finalmente a la de cierre. El arquitecto puede incluso tratar de disear la instalacin y de respaldar la construccin como proyectos separados con sus propias fases distintas. Se han seleccionado los siguientes ciclos de vida de proyectos de forma tal de ilustrar la diversidad de las metodologas que se utilizan. Los ejemplos que se muestran son tpicos; no son ni los preferidos ni los recomendados.

96

CALIDAD DE SOFTWARE

Figura 22. Ciclo de Vida Representativo para la Adquisicin de Defensa, segn la US DCDI 5000.2 (Borrador Final de Coordinacin, Abril del 2000).

Adquisicin de defensa. El Instructivo 5000.2 del Departamento de Defensa de los Estados Unidos, en su Borrador Final de Coordinacin, Abril del 2000, describe una serie de hitos de adquisicin y cuyas fases se ilustran en la Figura 5. Desarrollo de concepto y tecnologa: Estudios de los conceptos alternativos para cumplir una necesidad de misin; desarrollo de subsistemas / componentes y demostracin del concepto / tecnologa de los nuevos conceptos sistmicos. Termina con la seleccin de una arquitectura de sistemas y una tecnologa madura a ser utilizadas. Desarrollo y demostracin del sistema: Integracin del sistema; reduccin del riesgo; demostracin de los modelos de desarrollo de ingeniera; desarrollo y prueba operacional prematura y evaluacin. Termina con la demostracin del sistema en un ambiente operacional. Produccin y despliegue: Produccin inicial de baja velocidad (LRIP); desarrollo completo de la capacidad de fabricacin; la fase se traslapa con las operaciones continuas y de soporte. Soporte: Esta fase es parte del ciclo de vida del producto, pero corresponde en realidad a una gestin continua. Durante esta fase, se pueden llevar a cabo varios proyectos de forma tal de mejorar la capacidad, corregir los defectos, etc.

97

CALIDAD DE SOFTWARE

Construccin. Adaptada de Morris (1) describe el ciclo de vida de un proyecto de construccin: Factibilidad: Formulacin del proyecto, estudios de factibilidad, diseo de la estrategia y aprobacin. Se toma la decisin de continuar o no al final de esta fase. Planificacin y diseo: Diseo base, costo y programa, trminos y condiciones de contrato, y planificacin detallada. Los principales contratos se dejan para el final de esta fase. Construccin: Fabricacin, entrega, obras civiles, instalacin y pruebas.

La instalacin queda significativamente terminada al final de esta fase. Entrega y puesta en marcha: Prueba final y mantenimiento. Al final de esta fase, la instalacin queda totalmente operativa.

Desarrollo de software. Existe una serie de modelos de ciclo de vida del software actualmente en uso como es el modelo de cascada. Muench, y otros (3) describen un modelo espiral para el desarrollo de software con cuatro ciclos y cuatro cuadrantes, como se describe: Ciclo de prueba del concepto: Captura de los requerimientos del negocio, definicin de los objetivos de la prueba del concepto, produccin del diseo conceptual del sistema y diseo de la lgica, construccin de la prueba del concepto, produccin de los planes de aceptacin de pruebas, realizacin del anlisis de riesgo y recomendaciones. Primer ciclo de construccin: Derivacin de los requerimientos del sistema, definicin de los objetivos para la primera construccin, produccin del diseo del sistema lgico, construccin de la primera partida, produccin de los planes de prueba del sistema, evaluacin de la primera partida, y recomendaciones. Segundo ciclo de construccin: Derivacin de los requerimientos de los subsistemas, definicin de los objetivos para la segunda partida, evaluacin de la segunda partida y recomendaciones. Ciclo final: Completar los requerimientos de las unidades y diseo final; construccin final y ejecucin de las pruebas de unidades, subsistemas, sistemas y de aceptacin.

Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 aos atrs, el modelo cascada ha sido sujeto a numerosas crticas, debido a que es restrictivo y rgido, lo cual dificulta el desarrollo de proyectos de software. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software ms rpidamente, o ms incrementalmente o de una forma ms evolutiva, o precediendo el desarrollo a escala total con algn conjunto de prototipos rpidos.

98

CALIDAD DE SOFTWARE

Un modelo de ciclo de vida de software es una visin de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transicin asociadas entre estas etapas. Un modelo de ciclo de vida del software: Describe las fases principales de desarrollo de software. Define las fases primarias esperadas de ser ejecutadas durante esas fases. Ayuda a administrar el progreso del desarrollo, y Provee un espacio de trabajo para la definicin de un detallado proceso de desarrollo de software.

As, los modelos por una parte suministran una gua para los ingenieros de software con el fin de ordenar las diversas actividades tcnicas en el proyecto, por otra parte suministran un marco para la administracin del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc. Existen alternativas de modelos del ciclo de vida por lo que a continuacin se explicaran: MODELO CASCADA. Este es el ms bsico de todos los modelos, y sirve como bloque de construccin para los dems modelos de ciclo de vida. La visin del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a travs de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfaccin de metas de esa fase o quizs a una subsecuencia de metas de la fase. Las flechas muestran el flujo de informacin entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrs representan la retroalimentacin.

Figura 23. Modelo Cascada.

99

CALIDAD DE SOFTWARE

El modelo de ciclo de vida cascada, captura algunos principios bsicos: Planear un proyecto antes de embarcarse en l. Definir el comportamiento externo deseado del sistema antes de disear su arquitectura interna. Documentar los resultados de cada actividad. Disear un sistema antes de codificarlo. Testear un sistema despus de construirlo.

Las fases del modelo son: 1. Anlisis de requerimientos: En esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. 2. Diseo del Sistema: Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. 3. Diseo del Programa: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin. 4. Codificacin: Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregir errores. 5. Pruebas: Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final. 6. Implantacin: Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. 7. Mantenimiento: Una de las etapas que creo considerables porque se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas. Una de las contribuciones ms importantes del modelo cascada es para los administradores, posibilitndoles avanzar en el desarrollo, aunque en una escala muy bruta.

MODELO DE DESARROLLO INCREMENTAL. Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema. Tpicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.

100

CALIDAD DE SOFTWARE

Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma especfica de observar el desarrollo de algn otro incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.

El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos: Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande. Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Si un error importante es realizado, slo la ltima iteracin necesita ser descartada. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. Si un error importante es realizado, el incremento previo puede ser usado. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del prximo incremento. MODELO DE DESARROLLO EVOLUTIVO. Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximacin incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto. En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementacin parcial del sistema que recibe slo estos requerimientos. El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es actualizada, y una segunda versin del producto es desarrollada y desplegada. El proceso se repite indefinidamente.

101

CALIDAD DE SOFTWARE

Figura 24. Modelo de Desarrollo Evolutivo.

Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma especfica de observar el desarrollo de algn incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado tambin. Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado. El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentacin debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada. MODELO DE PROTOTIPADO DE REQUERIMIENTOS. El prototipado de requerimientos es la creacin de una implementacin parcial de un sistema, para el propsito explcito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rpida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentacin sobre lo que a ellos les gust y no les gust acerca del prototipo proporcionado, quienes capturan en la documentacin actual de la especificacin de requerimientos la informacin entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar

102

CALIDAD DE SOFTWARE

requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algn o todo el desarrollo incremental en modelos incremental o evolutivo.

Figura 25. Modelo de Desarrollo de Prototipado.

El Prototipado ha sido usado frecuentemente en los 90, porque la especificacin de requerimientos para sistemas complejos tiende a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho ms fcil proveer retroalimentacin convenientemente, basado en la manipulacin desde un prototipo, en vez de leer una especificacin de requerimientos potencialmente ambigua y extensa. Diferente del modelo evolutivo donde los requerimientos mejor entendidos estn incorporados, un prototipo generalmente se construye con los requerimientos entendidos ms pobremente. En caso que ustedes construyan requerimientos bien entendidos, el cliente podra responder con "s, as es", y nada podra ser aprendido de la experiencia.

MODELO ESPIRAL. El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Adems, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos: 1. Determinar qu se quiere lograr. 2. Determinar las rutas alternativas que se pueden tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor. 3. Seguir la alternativa seleccionada en el paso 2. 4. Establecer qu se tiene terminado.

103

CALIDAD DE SOFTWARE

Figura 26. Modelo Espiral Tipico.

Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situacin y determinamos que los mayores riesgos son la interfaz del usuario. Despus de un cuidadoso anlisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificacin de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de accin es construir un prototipo. Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentacin til. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer slo despus de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximacin es construir un incremento del sistema que satisfaga slo los requerimientos mejor entendidos. Hagmoslo ya. Despus del despliegue, el cliente nos provee de retroalimentacin que dir si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarn en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.

El modelo espiral captura algunos principios bsicos: Decidir qu problema se quiere resolver antes de viajar a resolverlo. Examinar tus mltiples alternativas de accin y elegir una de las ms convenientes. Evaluar qu tienes hecho y qu tienes que haber aprendido despus de hacer algo. No ser tan ingenuo para pensar que el sistema que ests construyendo ser "EL" sistema que el cliente necesita, y Conocer (comprender) los niveles de riesgo, que tendrs que tolerar.

104

CALIDAD DE SOFTWARE

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.

MODELO CONCURRENTE. Como el modelo espiral, el modelo concurrente provee una meta-descripcin del proceso software. Mientras que la contribucin primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribucin del modelo concurrente es su capacidad de describir las mltiples actividades del software ocurriendo simultneamente.

Figura 27. Modelo Concurrente.

Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algn tiempo del proceso de desarrollo de software. Discutamos un poco tales casos: Los requerimientos son usualmente "lneas de base", cuando una mayora de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseo. Sin embargo, una vez que comienza el diseo, cambios a los requerimientos son comunes y frecuentes (despus de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados tambin). Es desaconsejado detener el diseo en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer lneas de base de los requerimientos mientras progresa el diseo. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseo puede no ser afectado, medianamente afectado o se requerir comenzar todo de nuevo. Durante el diseo de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseo detallado en esos componentes estables. Similarmente, durante el diseo

105

CALIDAD DE SOFTWARE

detallado, puede ser posible proceder con la codificacin y quizs regular testeando en forma unitaria o realizando testeo de integracin previo a llevar a cabo el diseo detallado de todos los componentes. En algunos proyectos, mltiples etapas de un producto se han desarrollado concurrentemente. Por ejemplo, no es inusual estar haciendo mantencin de la etapa 1 de un producto, y al mismo tiempo estar haciendo mantencin sobre un componente 2, mientras que se est haciendo codificacin sobre un componente 3, mientras se realiza diseo sobre una etapa 4, y especificacin de requisitos sobre un componente 5. En todos estos casos, diversas actividades estn ocurriendo simultneamente. Eligiendo seguir un proyecto usando tcnicas de modelacin concurrente, se posibilita el conocimiento del estado verdadero en el que se encuentra el proyecto. Los modelos presentados, suministran una gua con el fin de ordenar las diversas actividades tcnicas en el proyecto de desarrollo de software e intentan suministrar un marco para la administracin en el desarrollo y el mantenimiento. Aunque todos ellos son compatibles unos con otros, un proyecto puede decidir cules enfoques son ms tiles en situaciones especiales. Criterios a considerar: Madurez de la aplicacin (relacionado a la probabilidad que muchos requerimientos comenzarn a conocerse slo despus del uso del sistema). Complejidad del problema y de la solucin. Frecuencias y magnitudes esperadas de los cambios de requerimientos. Financiamiento disponible, y su perfil como una funcin del tiempo. Acceso de los desarrolladores a los usuarios. Certeza de requerimientos conocidos.

Considerando la importancia de la planificacin se recomienda realizar el desarrollo de un proyecto de software bajo el modelo espiral insertando en l, cualquier otro modelo que se requiera dependiendo de las necesidades que se presenten. Este modelo permite realizar una planificacin del proceso de desarrollo del software considerando los riesgos asociados en cada etapa identificada. El identificar los riesgos en proyectos, evaluar su impacto, monitorear y controlar el avance del desarrollo del proyecto, permite al administrador aumentar las posibilidades de xito de un proyecto o, minimizar las posibilidades de fracaso de ste. Uno de los factores que ms influyen en el proceso de desarrollo de software y que prcticamente acompaa a toda aplicacin es el hecho de que en su mayora, no hay forma de tener todos los requerimientos corregidos antes del desarrollo del software. Muchas veces los requerimientos emergen a medida que la aplicacin o partes de ella estn disponibles para experimentacin prctica. En todos los casos, el trabajo comienza con la determinacin de objetivos, alternativas y restricciones, paso que a veces se llama recoleccin preliminar de requisitos. El prototipado es ampliamente recomendado para realizar la especificacin de requerimientos, se debe notar que la idea del prototipado es capturar por retroalimentacin los objetivos, necesidades y expectativas del cliente por lo cual no se debe caer en una utilizacin de estos

106

CALIDAD DE SOFTWARE

prototipos como partes finales del sistema, ya que en su desarrollo generalmente no se consideran aspectos de calidad, ni otros asociados con facilitar la etapa de mantencin del sistema. El prototipo trata de minimizar los cambios en los requerimientos, mientras que el diseo modular (incremental, en funcionalidades) trata de minimizar el impacto de los cambios en los requerimientos. El cambio es una propiedad intrnseca del software. Hoy en da el software debe poseer un enfoque evolutivo, un sistema debe evolucionar para acomodar la naturaleza evolutiva de los grandes sistemas. El software cambia constantemente, debido a la necesidad de reparar el software (eliminando errores no detectados anteriormente) como a la necesidad de apoyar la evolucin de los sistemas a medida que aparecen nuevos requerimientos o cambian los antiguos. Por lo cual es importante enfatizar que no tiene sentido entonces que un proyecto tome estrictamente una decisin concerniente con cual modelo se adherir. Los modelos de ciclo de vida presentados, son complementarios en vez de excluyentes. En muchos casos, los paradigmas pueden y deben combinarse de forma que puedan utilizarse las ventajas de cada uno en un nico proyecto. El paradigma del modelo en espiral lo hace directamente, combinando la creacin de prototipos y algunos elementos del ciclo de vida clsico, en un enfoque evolutivo para la ingeniera de software. No hay necesidad por tanto de ser dogmtico en la eleccin de los paradigmas para la ingeniera de software: la naturaleza de la aplicacin debe dictar el mtodo a elegir.

107

CALIDAD DE SOFTWARE

2.5 Roles y responsabilidades de los equipos de desarrollo. El proceso de la direccin denota el influjo interpersonal mediante el cual los gerentes o directores se comunican con sus subalternos para la ejecucin de un trabajo. La justificacin de este proceso radica en que se facilita el trabajo cuando existe una buena comunicacin acerca de los problemas tcnicos, de coordinacin y de motivacin. Para poder realizar la direccin de una forma efectiva, es necesaria la utilizacin de una estructura organizacional que nos permita trabajar en forma ptima con los recursos disponibles.

Figura 28. Designacin de Roles.

Lamentablemente, una nica estructura organizacional que se adapte perfectamente para dirigir todos los tipos de proyectos no existe, aunque, sin embargo, existe una variada gama de estructuras organizacionales alternativas que se adaptan de mejor o peor forma a los distintos tipos de proyectos, y que son presentadas a continuacin. La organizacin funcional es la forma de organizacin ms comn, y se basa en una estructura jerrquica bsica. El organigrama de este tipo de organizacin tiene forma piramidal, encontrndose en el parte superior a los grados mas altos de direccin, con los grados de direccin medio y bajo distribuyndose hacia abajo de la pirmide. Esta organizacin generalmente se descompone en varias unidades funcionales diferentes, como por ejemplo ingeniera, contabilidad, administracin. La razn de ser de esta estructura radica en las teoras de administracin basadas en la especializacin, las cuales consideran que es ms fcil dirigir a especialistas si estos son agrupados segn su especialidad y el jefe de departamento tiene conocimientos de esa disciplina en particular.

108

CALIDAD DE SOFTWARE

Este tipo de organizacin posee ventajas que descansan sobre su centralizacin de recursos similares, ya que, por ejemplo, brinda caminos de integracin claros y bien definidos para especialistas jvenes y adems, la ayuda mutua es fcilmente encontrada gracias a la proximidad fsica. Sin embargo, este tipo de organizacin posee debilidades. Por ejemplo, cuando se trabaja en proyectos mltiples, generalmente surgen problemas por el uso de los recursos. Otro ejemplo a citar es el de que cada departamento funcional pone nfasis en su especialidad ms que en los objetivos del proyecto. Pese a esto, la mayora de las compaas usan este tipo de organizacin no slo para sus proyectos, sino para todas sus actividades. La organizacin de proyecto es un tipo de organizacin que representa el opuesto a la organizacin funcional. En una organizacin de proyecto, todos los recursos necesarios para realizar un proyecto son separados de sus unidades funcionales regulares y se renen como una unidad independiente de trabajo dirigida por un jefe de proyecto. Al jefe de proyecto se le concede una amplia autoridad sobre los recursos del proyecto y pueden adquirir nuevos recursos ya sea dentro o fuera de la organizacin. Todo el personal del proyecto esta bajo la autoridad del jefe de proyecto por el periodo que el proyecto dure. Las ventajas de este tipo de organizacin vienen de su objetivo nico y su unidad de comando. Se desarrolla un verdadero espritu de equipo bajo el claro entendimiento de, y enfocado a, un objetivo nico. La comunicacin informal es efectiva en un equipo fuertemente enlazado, y el director de proyecto tiene todos los recursos bajo su disposicin. Sin embargo, la organizacin de proyecto no es la solucin perfecta para todos los problemas de la direccin de proyectos, ya que por lo general, las instalaciones se duplican y los recursos son utilizados de forma ineficiente. Otro problema serio radica en que se produce inestabilidad laboral luego de terminado el proyecto temporal. La organizacin jerrquica est estructurada alrededor de entradas tcnicas. La organizacin de proyecto estructura un propsito nico construido alrededor de las salidas del proyecto. Estas son estructuras unidimensionales en un mundo multidimensional. El problema de cada una es conseguir un balance apropiado entre los objetivos a largo plazo de los departamentos funcionales en formar tcnicos expertos y los objetivos a corto plazo del proyecto. La organizacin de matriz es una estructura multidimensional que trata de maximizar los puntos fuertes y minimizar los dbiles tanto de la estructura funcional como la de proyectos. Combina la estructura jerrquica vertical standard con una estructura lateral u horizontal sobrepuesta de un coordinador de proyecto. Los mayores beneficios de la estructura de matriz son el balance de objetivos, la coordinacin a travs de las lneas de los departamentos funcionales, y la visibilidad de los objetivos del proyecto a travs de la oficina del coordinador de proyecto.

109

CALIDAD DE SOFTWARE

La mayor desventaja es que el hombre en el medio trabaja para dos jefes. Verticalmente, responde al jefe del departamento funcional. Horizontalmente, responde al coordinador de proyecto o jefe de proyecto. En una situacin de conflicto puede quedar atrapado en el medio. El director de proyecto a menudo siente que no posee la autoridad suficiente sobre los departamentos funcionales. Por otro lado, el jefe del departamento funcional a menudo siente que el coordinador de proyecto esta interviniendo en su territorio. La experiencia ha demostrado que ningn acercamiento en particular es perfecto para todas las situaciones y proyectos. La moda actual en la literatura de direccin es el modelo de contingencia. Esta teora plantea que la mejor solucin es contingente a los factores claves en el ambiente en el cual la solucin tendr que operar. Lo mismo es cierto para la eleccin de la estructura organizacional. La base para decidir est en los diversos factores claves en un proyecto especfico los cuales nos ayudarn a elegir la estructura organizacional correcta para las condiciones dadas, con una organizacin dada y en un ambiente particular. Por ejemplo, una organizacin desarrollando muchos, pero pequeos, nuevos proyectos utilizando una tecnologa standard tendera a funcionar de la mejor forma con una estructura funcional. Por otra parte, una compaa con un proyecto grande, extenso, complejo e importante optar por una estructura organizacional por proyecto. Una firma en el negocio farmacutico con muchas tecnologas complejas probablemente trabajara con una estructura matricial. Es tambin posible ocupar las tres estructuras en una misma compaa, en diferentes proyectos. Tambin todas estas estructuras pueden ser utilizadas en un mismo proyecto en diferentes niveles -por ejemplo, una organizacin global de matriz con estructura funcional en ingeniera y una organizacin de proyecto dentro de otra sub rea funcional. No es posible decidir el diseo organizacional sin definir tambin quien ser seleccionado como el jefe de proyecto y que tipo de diseo se quiere para los sistemas de reporte y planeamiento. Por ejemplo, una organizacin de proyecto exitosa requiere un jefe de proyecto con amplia capacidad para la direccin general. Debe combinar conocimiento tcnico en la materia adems de habilidades de direccin antes de poder dirigir a todo el personal del proyecto. No tiene sentido elegir una forma de organizacin de proyecto si tal jefe de proyecto no se encuentra. Los sistemas de reporte y planeamiento en una organizacin de proyecto pueden ser bastante simples ya que el equipo trabaja con una gran proximidad. Lo opuesto es cierto en la direccin de proyectos a travs de una organizacin funcional. Por esto, un sistema de planeamiento y reporte mas sofisticado es necesario en una organizacin funcional que en una organizacin de proyecto. Las organizaciones usualmente cambian a una organizacin de proyecto o una organizacin de matriz debido a que la estructura funcional regular fall en una serie de proyectos. Esto no es absolutamente necesario. Antes de abandonar la organizacin funcional, se debe analizar el problema real y ver si se puede tomar algn camino para una rpida reorganizacin. Algunos

110

CALIDAD DE SOFTWARE

resultados de la reorganizacin pueden resultar favorables, pero otras consecuencias no intencionadas pero lgicas seguramente sern desfavorables. Los mtodos de comunicacin lateral u horizontal necesitan ser construidos en los lmites de los departamentos funcionales. Acercamientos alternativos para la comunicacin lateral incluyen: Procedimientos como planes, presupuestos, inventarios y juntas de revisin. Contacto directo entre jefes de proyecto. Roles de relaciones informales. Equipos

Estos son mecanismos de integracin de la organizacin matricial. Ayudan a romper las barreras que separan a las diferentes disciplinas, departamentos y ubicaciones geogrficas. No existe una estructura organizacional perfecta para manejar los distintos tipos de proyecto. La organizacin funcional, la de proyecto y la matricial tienen todas fuerzas y debilidades. La eleccin final deber venir luego de considerar varios factores de la naturaleza de la tarea a realizar, las necesidades de la organizacin y el ambiente del proyecto. La estructura funcional funcionara para muchos proyectos, en muchas organizaciones, especialmente si las comunicaciones laterales son reforzadas a travs de mecanismos de integracin. Si se escoge una estructura de matriz, toda la organizacin deber poner gran empeo para que esta funcione. En particular, el director de proyecto debe ser cuidadosamente escogido y entrenado. Sus habilidades interpersonales son ms importantes que sus habilidades tcnicas. En muchas situaciones, una organizacin de proyecto puede parecer la solucin ms simple desde la perspectiva del director de proyecto. Sin embargo, los directores funcionales y la alta administracin tal vez no la consideren como la mejor solucin a largo plazo o la decisin ms estratgica. En esta rea el principal objetivo es sumar adecuadamente personas a cargos vacantes en un equipo de desarrollo de sistemas Software, o bien la conformacin de un equipo. En este momento hay que establecer cules son las condiciones deseables para dicho equipo. Y para poder establecer estas condiciones deseables se debe tener un adecuado conocimiento de como actan los equipos de trabajo. Este conocimiento, necesario para poder realizar la seleccin de las personas adecuadas, es responsabilidad de los administradores de Software y futuros jefes de proyecto, de acuerdo con las polticas de la empresa. De esta forma, con relacin a los equipos de trabajo se debe tener en cuenta: Los equipos de trabajo estn conformados por individuos, y estos individuos interactan entre s. El administrador debe entender las limitaciones humanas e intentar no llevar a cabo proyectos irrealizables. Los sistemas de Software son utilizados por personas. Si las limitaciones y capacidades de los desarrolladores no son tomadas en cuenta, difcilmente los sistemas sern bien aprovechados por los usuarios.

111

CALIDAD DE SOFTWARE

De esta forma la seleccin es importante teniendo en cuenta muchos factores de la personalidad de los postulantes. Sin embargo, no slo se debe tener en cuenta esta vista al momento de escoger, sino tambin considerar experiencias anteriores, habilidades en ciertos aspectos del desarrollo, etc. Para tener xito en la seleccin de los futuros integrantes de los equipos de trabajo, basarse slo en la personalidad de los postulantes puede ser una mala decisin, debido a que: La personalidad es dinmica, no esttica. Esta puede cambiar en el transcurso de una carrera profesional o por cambios en el ambiente de trabajo. Diferentes personalidades pueden resultar adecuadas a diferentes aspectos del desarrollo, tales como diseo, testing y otras. Los postulantes pueden hacer trampa al completar los tests de personalidad, llenndolos no con sus datos reales, sino con lo que piensan que podra ser la personalidad ms adecuada al trabajo. Por esto la realizacin de una buena entrevista es vital para la seleccin.

Idealmente el equipo de desarrollo de un proyecto debe alcanzar, con la totalidad de sus miembros, el sistema final que se ha planeado. Es decir, todos los miembros de una organizacin o equipo deben mantenerse en ella en el tiempo, ya que de esta forma el equipo se va solidificando en su accionar. En la realidad hay que considerar la rotacin de los miembros de un equipo ya sea dentro de la misma organizacin, teniendo ascensos o cambios de proyectos; o bien alejndose de la organizacin. Esta rotacin puede traer consecuencias tanto positivas como negativas al trabajo del equipo y a las relaciones dentro de estas. Dentro de las posibles consecuencias negativas pueden encontrarse: Interrupcin en el desarrollo: Cuando se produce un alejamiento de un integrante clave del equipo de trabajo existe la posibilidad de un retraso en el desarrollo. Esta interrupcin es ms o menos grave dependiendo de la fase en que se encuentre el desarrollo, siendo las primeras las ms crticas. Por ejemplo, en la etapa de anlisis la perdida de un integrante puede producirse una grave perdida de informacin no documentada. En etapas posteriores puede producirse un retraso importante al acercarse las fechas de entrega del producto final. Reemplazos inadecuados: Por la situacin de perdida de un integrante del equipo se busca rpidamente un reemplazo que no siempre ser lo ms adecuado debido a la inexperiencia de trabajar en ese equipo particular. Dependiendo de la etapa de avance del proyecto, en determinadas situaciones no se hace conveniente reemplazar la persona que ha dimitido del proyecto y es mejor dejar el equipo conformado de igual forma. Perdida de oportunidades estratgicas: La interrupcin del trabajo en el desarrollo en un proyecto, cuando los tiempos de entrega son crticos, pueden hacer que la organizacin pierda oportunidades en el mercado relativas a sus competidores.

112

CALIDAD DE SOFTWARE

Costos de seleccin y contratacin: Cuando una organizacin debe conformar o completar un equipo de trabajo para un nuevo proyecto, se deben considerar los costos de seleccin y contratacin de los nuevos integrantes. Estos abarcan desde publicacin de avisos, honorarios a agencias de colocacin, realizacin de entrevistas y gastos administrativos en general.

Costos del entrenamiento y del desarrollo. Una vez seleccionados los nuevos integrantes del equipo estos deben ser entrenados para el nivel de desarrollo esperado. Tanto los costos anteriores como estos costos de entrenamiento involucran no slo desembolsos econmicos sino tambin un costo en tiempo, como el entrenamiento en las tcnicas utilizadas o la integracin a un equipo que ya esta trabajando o pronto a iniciar un proyecto. Este coste de tiempo, aunque el nuevo integrante tenga experiencia, involucra el tiempo que lleva en hacerse familiar con la organizacin. Declinacin en la moral del grupo de trabajo. Cuando un lder, o una persona estimada, se alejan del equipo se produce una declinacin en el rendimiento del desarrollo. Esta situacin puede llevar a que otros miembros se alejen, sobre todo cuando el lder se ha ido contra su voluntad; o bien, un rechazo hacia el reemplazante cuando se contrata alguien para llenar el cupo dejado. Tambin se produce un desaliento en los integrantes de un equipo cuando ha habido errores importantes en alguna etapa del proyecto o existe una rivalidad entre dos miembros del equipo.

Entre las consecuencias positivas de la rotacin de los integrantes de los equipos de trabajo se pueden mencionar: Funcionamiento Creciente: Es la suposicin de que el reemplazante es mejor capacitado y habilidoso que el integrante que ha abandonado el equipo. Esto puede mejorar la calidad del trabajo del equipo. Ahorro de costos: Al tener equipos de trabajo conformado por antiguos miembros de la organizacin, los costos de mantener este equipo pueden ser ms elevados que mantener un equipo joven. Por ejemplo, disminucin de sueldos al pagar individuos jvenes y con menos experiencia, menos extensin de los periodos de vacaciones de los miembros antiguos, pago de pensiones y beneficios, etc. En todo caso, la organizacin debe evaluar a conciencia el sacrificar experiencia por la disminucin de costos de trabajo. Innovacin y adaptabilidad: La contratacin de nuevos individuos puede traer consigo nuevos puntos de vista en el uso de la tecnologa y experiencia ganada de otra organizacin. De esta forma, la organizacin tendra un mtodo rpido de adaptacin al uso de nuevas tecnologas y de ambientes cambiantes en el rea de desarrollo de sistemas. Ascensos internos crecientes: Cuando los integrantes mayores e importantes de los equipos de desarrollo abandonan la organizacin se abre la posibilidad de una movilidad interna que permita a integrantes de inferior grado ascender en la escala

113

CALIDAD DE SOFTWARE

interna de responsabilidades y sueldos. Esto puede considerarse como un premio al esfuerzo demostrado al desarrollar junto al equipo. Moral creciente: Cuando existe un conflicto al interior de un equipo, la productividad decae debido a una baja anmica o moral del resto de los integrantes del equipo. Cuando un individuo no cumple con los plazos, o la calidad de su trabajo es menor a la esperada, resiente la calidad del trabajo del resto. Por ello la separacin del equipo de esta persona hace elevar la moral del trabajo. Esta separacin de una persona que no cumple con las metas de la organizacin puede elevar las opiniones de que la organizacin valora el trabajo de alta calidad. Eliminacin de los malos comportamientos: La rotacin de personas infelices dentro del equipo termina con conductas contrarias a la organizacin. Se ha observado que estos individuos descontentos no abandonan la organizacin por su propia cuenta e incurren en conductas impropias, tales como, ausentismo, baja calidad del trabajo, e incluso sabotaje. Este sabotaje, incluso, puede ser peligroso a la organizacin, cuando el individuo tiene acceso a la seguridad o programacin de los sistemas en los cuales se est trabajando.

Estas consecuencias positivas y negativas de la rotacin de integrantes de equipos de desarrollo siguieren que, como ya se dijo, los equipos de trabajo son dinmicos, al igual que la personalidad de sus integrantes. Es por ello que la principal tarea de un jefe de proyecto, en compaa con la organizacin, es evaluar las necesidades de recursos humanos que se necesitan para conformar los equipos de trabajo con relacin a los proyectos que se pretendan desarrollar. Por otro lado, tambin es necesario evaluar el desempeo de los integrantes ya existentes en los equipos ya conformados, con relacin a la calidad de su trabajo y la posibilidad de reemplazo de ellos. Para ello se utiliza una matriz Calidad-Reemplazo que ayuda a determinar al jefe de proyecto, cual es la real necesidad de los individuos dentro de los equipos de desarrollo. Como ayuda a esta tarea se debe mantener una clasificacin, dinmica en el tiempo, de la categora del individuo dentro de la organizacin y de su integracin. Es importante decir que, aparte de mantener relaciones estables de los integrantes dentro del equipo, esta clasificacin est orientada a mantener y aumentar la calidad y productividad del trabajo de desarrollo. Junto a las clasificaciones anteriores, el jefe de proyecto debe realizar una serie de actividades que permitan el buen desarrollo del trabajo en equipo y un adecuado manejo de los recursos humanos, tarea que contribuye a solidificar la posicin de la organizacin en el rea de la Ingeniera de Software.

114

CALIDAD DE SOFTWARE

2.6 Habilidades y capacidades del personal del SQA. Los equipos de desarrollo varan tanto la secuencia como la frecuencia de estas actividades. El desarrollo de software en el mundo real, por lo general depende de una demandante lista de caractersticas as como de estrictas fechas de entrega determinadas por el mercado. Como resultado, slo los grupos bien organizados de ingenieros con conocimientos de los mtodos de ingeniera de software son capaces de llevar a cabo estas actividades de modo apropiado. Con frecuencia, la alternativa es el caos y en ocasiones el desastre.

Figura 29. Entorno de trabajo de los Desarrolladores de Software.

La ingeniera de software incluye personas, proceso, proyecto y producto. Los smbolos usados son acordes con el "proceso de desarrollo de software unificado" (USDP, Unified Software Development Process) de Jacobson, Booch y Rumbaugh, que es uno de los procesos para desarrollo de software. Los "productos" de un esfuerzo de desarrollo de software consisten en mucho ms que el cdigo objeto y el cdigo fuente. Por ejemplo, tambin incluyen documentacin, resultados de las pruebas y medidas de productividad. En cumplimiento del USDP, estos productos se llamarn artefactos. Este libro describe un conjunto completo de artefactos. Con frecuencia, las decisiones acerca del proceso del software tienen lugar a nivel organizacional (compaa, departamento, grupos, etctera) y, por lo tanto, resulta importante medir la capacidad de desarrollar software de las organizaciones. Las habilidades de ingeniera de software de cada ingeniero se pueden desarrollar y medir mediante el "proceso de software personal" (PSP, Personal Software Process) creado por Humphrey. Un tercer nivel de organizacin del software es el "proceso de software en equipo" (TSP, Team Software Process) tambin de Humphrey que describe el proceso mediante el cual

115

CALIDAD DE SOFTWARE

los equipos de ingenieros de software realizan su trabajo. Se cree que los marcos de trabajo disciplinados como CMM, PSP y TSP constituirn la base para el ingeniero de software profesional en el siglo XXI. Algunos estndares bien pensados para la documentacin facilitan la produccin de artefactos tiles y confiables. Se dispone de varios estndares. Para la mayor parte de este libro se aplican los estndares de ingeniera de software del IEEE (Institute of Electrical and Electronics Engineers), muchos de los cuales han sido ratificados por ANSI (American National Standards Institute). Muchas compaas proporcionan estndares internos. Aunque los estndares deben modificarse con el tiempo para reflejar nuevos aspectos, la esencia de los buenos estndares ha permanecido estable durante varios aos. A menos que trabajen a partir de las normas y, de ser posible, con las aplicaciones en casos de estudio, los equipos suelen perder una gran cantidad de tiempo soando con la estructura (en lugar de con la esencia) de los documentos. Los estndares centran el proceso al proporcionar una lnea base para ingenieros, profesores y estudiantes. En la prctica, los proyectos especficos se modifican para hacerlos a la medida. El grupo de SQA trabaja con la gerencia de proyectos durante los inicios del desarrollo para establecer los planes, estndares y los procedimientos que agregarn valor al proyecto de software y satisfacer los problemas del proyecto y de las polticas de la organizacin. Participa en establecer los planes, estndares y procedimientos. El SQA ayuda a asegurar que se cumple con las necesidades del proyecto y verifica que sean usables para realizar revisiones e intervenciones durante el ciclo de vida del software. Las revisiones del grupo de SQA proyectan las actividades y revisan el producto del trabajo de software a travs del ciclo de vida del software, adems de proveer a la gerencia la posibilidad de saber si el proyecto est de acuerdo a los planes, estndares y procedimientos establecidos. Solucionar problemas es un proceso de alta-visibilidad; la prevencin de problemas es de bajavisibilidad. Esto es ilustrado por una vieja parbola: En la China antigua haba una familia de curanderos, uno de ellos era conocido por toda la comarca y empleado como mdico por un gran seor. Preguntaron al mdico quin era el curandero ms experto de su familia. l contest, "atiendo al enfermo y al moribundo con tratamientos drsticos y dramticos, y en ocasiones algunos se curan y mi nombre es escuchado por los seores. Mi hermano mayor cura la enfermedad cuando apenas comienza y sus habilidades se conocen entre los campesinos y los vecinos. El mayor de mis hermanos puede detectar el espritu de la enfermedad y suprimirlo antes de que aparezca. Su nombre es desconocido fuera de nuestro hogar.". Anlogamente a esta parbola, SQA est orientada a la Prevencin y por lo tanto es como el hermano mayor, en cambio las pruebas de software estn orientadas a la Deteccin, y por lo tanto tan visibles como el hermano menor del cuento. No obstante las diferencias, las organizaciones varan considerablemente en cmo se asignan las responsabilidades a SQA y pruebas. En ocasiones son responsabilidades combinadas de un grupo o individuo. Tambin comunes son los grupos de proyectos que incluyen una mezcla de testers y desarrolladores que trabajan juntos, con SQA de procesos monitoreados por el administrador de proyectos. Esto depender de lo que mejor se ajuste al tamao de la organizacin y estructura del negocio. El software de calidad est razonablemente libre de errores, es desarrollado a tiempo y con los recursos estimados, cumple con los requerimientos y/o expectativas y es mantenible. Sin embargo, calidad es un trmino subjetivo y depender de quin es el cliente y su influencia

116

CALIDAD DE SOFTWARE

general en el esquema de las cosas. Una visin amplia del cliente de un proyecto de desarrollo de software puede incluir al usuario final, clientes de aceptacin, oficiales de contrato, gerentes, etc. Cada tipo de cliente tendr su propia visin de qu es calidad. Pero, Qu hace a un buen ingeniero de SQA? Un buen ingeniero de software debe ser capaz de entender el proceso de desarrollo de software y cmo se ajusta al negocio y metas de la organizacin. Habilidades de comunicacin y entendimiento de distintos puntos de vista son necesarios. En organizaciones con nacientes implementaciones de SQA de procesos, la diplomacia y paciencia son cualidades especialmente necesarias. La habilidad de encontrar problemas, as como ver qu es lo que falta es importante para inspecciones y revisiones.

Cul es el rol de la documentacin en SQA? La documentacin es crtica. Las prcticas de QA debieran ser documentadas para que puedan ser repetibles. Especificaciones, diseo, reglas del negocio, reportes de inspeccin, configuraciones, cambios de cdigo, planes de pruebas, pruebas de casos, reportes de fallas, manuales de usuario, etc. Deben ser completamente documentados.

Figura 30. Documentacin.

Idealmente debiera existir un sistema para encontrar y obtener fcilmente los documentos y determinar qu documento tendrn informacin particular. El manejo del cambio de la documentacin debe ser usada, de ser posible.

117

CALIDAD DE SOFTWARE

2.7 Actividades del SQA. La Actividad de SQA es el proceso de verificacin de que los estndares sean aplicados correctamente empleando las actividades de: (1) Establecimiento de un plan de SQA para un proyecto, (2) Participacin en el desarrollo de la descripcin del proceso de software del proyecto, (3) Revisin de las actividades de Ingeniera del Software para verificar su ajuste al proceso de software definido, (4) Auditoria de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software, (5) Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido, y (6) Registrar lo que no se ajuste a los requisitos e informar a sus superiores.

Figura 31. SQA

Adems de estas actividades, el grupo de SQA coordina el control y la gestin de cambios y; ayuda a recopilar y analizar las mtricas del software. Las mtricas son escalas de unidades sobre las cuales puede medirse un atributo cuantificable. Cuando se habla de software nos referimos a la disciplina de recopilar y analizar datos basndonos en mediciones reales de software, as como a las escalas de medicin. Los atributos son caractersticas observables del producto o del proceso de software, que proporciona alguna informacin til sobre el estado del producto o sobre el progreso del proyecto. El trmino producto se utiliza para referirse a las especificaciones, a los diseos y a los listados del cdigo. Los valores de las mtricas no se obtienen slo por mediciones. Algunos valores de mtricas se derivan de los requisitos del cliente o de los usuarios y, por lo tanto, actan como restricciones dentro del proyecto. Los principios bsicos de la medicin son: (1) los objetivos de la medicin deberan establecerse antes de empezar la recopilacin de datos, (2) todas las tcnicas sobre mtricas deberan definirse sin ambigedades, (3) las mtricas deberan obtenerse basndose en una teora vlida para el dominio de aplicacin, (4) hay que hacer las mtricas a medida para acomodar mejor los productos y procesos especficos, (5) siempre que sea posible, la recopilacin de datos y el anlisis debera automatizarse, y (6) se deberan aplicar tcnicas estadsticas vlidas para establecer las relaciones entre los atributos internos del producto y las caractersticas externas de la calidad. Las Razones que justifican la Medicin del Software son: (1) Para indicar la calidad del producto, (2) Para evaluar la productividad de la gente que desarrolla el producto, (3) Para

118

CALIDAD DE SOFTWARE

evaluar los beneficios (en trminos de productividad y calidad) derivados del uso de nuevos mtodos y herramientas de Ingeniera de Software, (4) Para establecer una lnea base de estimacin y (5) Para ayudar a justificar el uso de nuevas herramientas o formacin adicional. Las actividades del proceso de medicin son: (1) Formulacin: Obtencin medidas y mtricas apropiadas para la presentacin del software, (2) Coleccin: Mecanismo empleado para acumular datos necesarios para obtener las mtricas formuladas, (3) Anlisis: Clculo de las mtricas y aplicacin de herramientas matemticas, (4) Interpretacin: La evaluacin de los resultados de las mtricas en un esfuerzo por conseguir una visin interna de la calidad de la presentacin, (5) Retroalimentacin: Recomendaciones obtenidas de la interpretacin de mtricas y tcnicas transmitidas al equipo de desarrollo de software. Los sistemas mtricos necesitan tres tipos de valores: (1) Objetivos: Se basan habitualmente en consideraciones comerciales, (2) Predicciones: Indican la viabilidad de los objetivos. Se basan en las caractersticas del producto con el que tratamos. Y (3) Valores reales: Pueden ser comparados con los objetivos para supervisar la progresin 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 ms que medirse se evala. Las medidas de Calidad del Software deben comenzar desde la especificacin y terminar con la implementacin, implantacin y mantenimiento o post-implantacin. Debe aplicarse a lo largo de todo el proceso de Ingeniera de Software. Bsicamente, la medicin es una fase normal de cualquier actividad industrial Sin mediciones es imposible perseguir objetivos comerciales normales de una manera racional. Existen mtricas a nivel Proyecto, Proceso y Producto respectivamente. Las mtricas del Proyecto se consolidan para crear mtricas de proceso que sean pblicas para toda la organizacin del software. El uso de mtricas para el Proyecto tiene 2 aspectos fundamentales: (1) minimizar la planificacin del desarrollo haciendo los ajustes necesarios que eviten retrasos y reducir problemas/riesgos potenciales; y (2) evaluar la calidad de los productos en el momento actual y cuando sea necesario, modificando el enfoque tcnico que mejore la calidad. Los indicadores de proyecto permiten al gestor de proyectos de software: (1) evaluar el estado del proyecto, (2) seguir la pista de los riesgos potenciales, (3) detectar las reas de problemas antes de que se conviertan en "crticas", (4) ajustar el flujo y las tareas del trabajo; y (5) evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo del software. Las mtricas del Proceso se recopilan de todos los proyectos y durante un largo perodo de tiempo. Su intento es proporcionar indicadores que lleven a mejorar los procesos de software a largo plazo. Se tendrn mtricas asociadas a cada proceso del software (Po ejemplo: mtricas de implementacin). Estos indicadores de proceso permiten que una organizacin de Ingeniera de Software pueda tener una visin ms profunda de la eficacia de un proceso ya existente y permiten que los gestores evalen lo que funciona y lo que no. En realidad, las medidas que recopila un equipo de proyecto y las convierte en mtricas para utilizarse durante un proyecto, tambin pueden trasmitirse a los que tienen la responsabilidad

119

CALIDAD DE SOFTWARE

de mejorar el proceso de software. Por esta razn, se utilizan muchas de las mismas mtricas tanto en el dominio del proceso como en el del proyecto. La nica forma racional de mejorar cualquier proceso es medir atributos del proceso, desarrollar un juego de mtricas significativas segn estos atributos y utilizar las mtricas para proporcionar indicadores que conducirn a una estrategia de mejora. Las mtricas del proceso se caracterizan por: (1) El control y ejecucin del proyecto, (2) Medicin de tiempos del anlisis, diseo, implementacin, implantacin y post implantacin, (3) Medicin de las pruebas (errores, cubrimiento, resultado en nmero de defectos y nmero de xito) y (4) Medicin de la transformacin o evolucin del producto. Las mtricas de Producto son privadas para un individuo y a menudo se combinan para desarrollar mtricas del proyecto que sean pblicas para un equipo de software. Estn enfocadas a predecir y controlar: (1) El tamao (lneas de cdigo, bytes de cdigo, operadores y operandos), (2) La estructura (control de flujo, relacin entre componentes, cohesin y acoplamiento), (3) La complejidad (combinacin de tamao y estructura), (4) Los ndices para controlar la documentacin, (5) La calidad (independencia, completo, entendible, aumentado) y (6) La estabilidad (los cambios aumentan el nmero de fallas, los cambios se pueden dar por definicin de requerimientos o por cambios del entorno). Las mtricas del software deberan tener las siguientes caractersticas: (1) Simple y fcil de calcular, (2) Emprica e intuitivamente persuasiva: Debe satisfacer las nociones intuitivas del desarrollador sobre el atributo del producto en evaluacin, (3) Consistente y objetiva: Presentar resultados sin ambigedad, (4) Consistente en el empleo de unidades y tamaos: Deben emplearse medidas que no conduzcan a extraas combinaciones de unidades, (5) Independiente del lenguaje de programacin y (6) Mecanismo para retroalimentacin de calidad: Debe proporcionar informacin para obtener un producto final de mayor calidad. Las mtricas a recabar dependen de los objetivos del negocio en particular. Los desarrolladores tienen a la vez objetivos comunes como, respetar el presupuesto y respetar los plazos, minimizar las tasas de defectos antes y despus de la entrega del producto e intentar mejorar la calidad y la productividad. Las mtricas deben ayudar a la evaluacin de las representaciones del modelo lgico y fsico, deben tener la capacidad de intuir sobre la complejidad del diseo y construccin; y deben ayudar en el diseo de casos de prueba. Prcticas claves de SQA Metas: Planificar las actividades de SQA Verificar la adherencia de los productos y actividades de software a los estndares, a los procedimientos y a los requisitos aplicables. Los grupos y los individuos afectados son informados de las actividades y de los resultados de la SQA. Las tareas que no cumplen con los estndares o procedimientos y que no se pueden resolver dentro del proyecto del software son tratadas por la gerencia general.

Actividades principales:

120

CALIDAD DE SOFTWARE

Un plan de SQA es preparado para el proyecto de software de acuerdo a procedimientos documentados. Las actividades del grupo de SQA son realizadas de acuerdo a los planes de SQA. El grupo de SQA participa en la preparacin y revisin de los planes de desarrollo, estndares y procedimientos del proyecto. El grupo de SQA revisa las actividades de ingeniera de software para verificar el cumplimiento de lo anterior. El grupo de SQA audita los productos del trabajo designado para verificar el cumplimiento de lo anterior. El grupo de SQA peridicamente reporta los resultados de sus actividades al grupo de ingeniera de software. Las desviaciones detectadas en las actividades del software y en los productos del trabajo de software son documentadas y manejadas de acuerdo a procedimientos previamente documentados. El grupo de SQA conduce peridicamente revisiones de sus actividades y reuniones con el personal de SQA del cliente, segn sea necesario.

Uno de los principales problemas con los que se encuentra la actividad de aseguramiento de la calidad en el software es la falta de apoyo por parte de la alta direccin de las organizaciones. Este apoyo es esencial para que la funcin de aseguramiento de calidad tenga xito. Los costos econmicos de la funcin de aseguramiento de la calidad en el software se han estimado que vara entre un 2.5 y 5 por ciento del costo total de un proyecto de desarrollo de un producto de software. El costo se localiza en las actividades (como son revisiones peridicas y constantes de las aplicaciones) que tienen que realizar algunos desarrolladores de software, mismas que se deben de integrar a sus actividades ordinarias. Son las Tcnicas y actividades de carcter operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradas en dos objetivos fundamentales: 1. Mantener bajo control los Productos de Desarrollo de software. 2. Eliminar las causas de los defectos en las diferentes fases del ciclo de vida, que puedan presentarse en los desarrollos de los productos de software. Es de suma importancia entender las diferencias que existen entre el control de la calidad y el aseguramiento de la calidad. El aseguramiento de la calidad aprovecha los resultados del control de calidad para evaluar y mejorar los procesos con los que se desarrolla el producto. Esto dicho, el control de calidad se enfoca en productos, mientras que el aseguramiento de la calidad lo hace en los procesos.

121

CALIDAD DE SOFTWARE

2.8 Mtodos y herramientas. Las pruebas de SW son tanto un arte como una ciencia en general, en aplicaciones complejas, como los sistemas operativos, es prcticamente imposible eliminar todos los errores antes de liberar la versin, esto se debe a los diferentes puntos de vista y a las limitaciones de tiempo. Diferentes aplicaciones de SW requieren distintos enfoques en lo que respecta a las pruebas.

Figura 32. Revisin en busca de errores.

Los mtodos ms comunes para el aseguramiento de la calidad son los siguientes: 1. Auditorias PPQA (Process and Product Quality Assurance) Es la actividad de garantizar que el proceso y el producto de trabajo se ajustan al plan acordado. 2. Pruebas de Validacin: Es el acto de introducir datos, los cuales el tester sabe que son errneos en la aplicacin. 3. Comparacin de datos: Tcnica que se realiza comparando los resultados de una aplicacin con parmetros especficos con los resultados de otra aplicacin previamente creada, introduciendo los mismos parmetros de manera que se obtenga un resultado exacto. 4. Prueba de esfuerzo (Stress Testing) Se realiza cuando el SW es utilizado de la manera ms ruda posible en un perodo de tiempo para ver si trabaja con altos niveles de carga. 5. Pruebas de Uso: A veces conseguir usuarios que no estn familiarizados con el SW para probarlo por un tiempo determinado, ofrece retroalimentacin a los desarrolladores acerca de las dificultades que encontraron. Esta es la mejor maneta de realizar mejoras a la interfaz.

122

CALIDAD DE SOFTWARE

6. Revisiones por Pares (Peer Reviews). Son actividades efectivas para el control de la calidad. Pueden aplicarse al anlisis, diseo y codificacin. 7. Revisin Tcnica formal (RTF): Es una actividad de garanta de calidad de SW. Es una revisin que incluye recorridos, inspecciones y revisiones cclicas.

REVISIONES POR PARES (PEER REVIEWS) Consiste en la revisin del cdigo de un programador por otros programadores (sus pares). Se puede poner en prctica creando un panel que encarga de revisar peridicamente muestras de cdigo. En la revisin por pares se analizan o revisan factores tcnicos, de procedimiento y humanos. Las revisiones por pares son las siguientes: Walkthroughs (recorridos) Revisiones Inspecciones de cdigo

Walkthroughs Objetivos: Detectar posibles defectos. Identificar oportunidades de mejora. Examinar alternativas.

El walkthrough es usado para revisar especificaciones de requerimientos o de diseo. Procedimientos: A partir del cdigo regular, el walkthrough es realizado al menos una vez por cada bucle a travs del modelo espiral y se realizar en forma circular (programador i-th revisar el cdigo del programador 1-th+1). Todas las deficiencias sern anotadas y utilizadas para el mejoramiento del proceso. Durante cada cdigo revisado en el walkthrough se tomarn dos mediciones: relativas y objetivas. Las deficiencias relativas son: cdigo eficiente (pocos recursos son consumidos) y cdigo exacto (que tan cerca est el producto con las especificaciones). Las deficiencias objetivas son: errores de formato, nombre de variables no estandarizado, falta de documentacin (comentarios en el cdigo) y falta de normas de codificacin. INSPECCIONES DE CDIGO No son excluyentes con el testing. Cada desarrollador puede encontrar distintos tipos de defectos. No hay tiempo ni dinero para inspeccionar todo. Se suele centrar la inspeccin en los mdulos ms crticos.

123

CALIDAD DE SOFTWARE

Es recomendable realizarla despus de una prueba bsica.

Objetivos primarios: Detectar defectos. Elegir el camino de resolucin. Verificar la resolucin (Los defectos deben ser corregidos). Objetivos secundarios: Asegurar consenso sobre el trabajo y la calidad. Potenciar el trabajo en equipo. Obtener datos para las mtricas. LA REUNIN El presentador o moderador conoce a fondo el producto. Los asistentes son especialistas del negocio, la tecnologa usada o son conocedores de los sistemas donde hay impacto. Se pueden discutir brevemente los temas planteados (problemas, sugerencias de mejora, etc.). Si funciona bien: Buenos resultados y buena relacin calidad/esfuerzo. Se debe ser cuidadoso con el tiempo y el tema importante de la reunin. ROLES DE LA REUNIN Moderador Responsable de la inspeccin Asegura que todos estn preparados. Aclara las reglas. Hace cumplir las reglas. Revisores Buscan y describen los defectos. Toman decisiones para solucionar los errores. Autor del Cdigo (Desarrollador) Explica el cdigo que l realiz. Responde las dudas. Lector Lee el programa lnea por lnea. Registrador Anota los defectos encontrados. BENEFICIOS DE LA REUNIN Directos Mayor calidad que lleva a aumentos de productividad.

124

CALIDAD DE SOFTWARE

Mayor visibilidad del proceso. Trabajo en equipo y mejor comunicacin. Mejora en la calidad de estndares y mtodos.

REVISIONES Se utilizar un checklist para realizar las revisiones. REVISIN TCNICA FORMAL (RTF) Una revisin tcnica formal es una actividad de garanta de calidad del SW llevada a cabo por los ingenieros de SW y el equipo de SQA. Los objetivos de la RTF son: 1. Descubrir errores en la funcin, la lgica o la implementacin, de cualquier representacin del SW. 2. Verificar que el SW bajo revisin alcance sus requisitos. 3. Garantizar que el SW ha sido realizado con los estndares predefinidos. 4. Conseguir un SW desarrollado de forma uniforme. 5. Hacer que los proyectos sean manejables. La RTF tambin sirve para promover la seguridad y continuidad, ya que varias personas se familiarizarn con partes del SW que de algn modo no haban visto. Cada RTF se lleva a cabo mediante una reunin y solo tendr xito si es bien planificada, controlada y atendida. REUNIN RTF La reunin debe ajustarse a las siguientes restricciones. Deben convocarse para la revisin entre 3 y 5 personas. Se debe preparar por adelantado pero sin que requiera ms de dos horas de trabajo por cada persona. La reunin debe ser menor de 2 horas. Con las anteriores limitaciones, debe resultar obvio que cada RTF se centra en una parte especfica del SW total. Al limitar el centro de atencin de la RTF la probabilidad de descubrir errores es mayor. Proceso El desarrollo informa al jefe de proyecto que el producto est terminado y que requiere revisin. El jefe de proyecto contacta con un jefe de revisin que evala la disponibilidad del producto, genera copias del material y las distribuye a otros revisores. Cada revisor tomar notas para conocer el trabajo. De forma simultnea, el jefe de revisin, analiza el producto y establece una fecha para la reunin. La reunin es llevada a cabo por el jefe de revisin, los revisores y el desarrollador. La reunin comienza con una breve explicacin del desarrollo para despus continuar con el recorrido de la inspeccin explicando el material, mientras los revisores exponen sus comentarios cuando se descubren problemas o errores vlidos, sern registrados.

125

CALIDAD DE SOFTWARE

Al final de la reunin los participantes deben decidir si: 1. Aceptar el producto sin posteriores modificaciones. 2. Rechazar el producto debido a los serios errores encontrados. Una vez corregidos debe hacerse otra reunin. 3. Aceptar el producto provisionalmente. Se han encontrado errores menores que deben ser corregidos sin necesidad de otra reunin. REGISTR E INFORME DE LA REVISIN Durante la reunin se van registrando todas las dudas y errores que vayan surgiendo. Al final de la reunin se resumen todas las incidencias y se genera una lista de sucesos de revisin. Adems se prepara un informe de la RTF que debe responder a 3 preguntas. 1. Qu fue revisado? 2. Quin lo revis? 3. Qu se descubri y cules son las conclusiones? La lista de sucesos de revisin tiene dos propsitos: Identifica las reas problemticas dentro del producto. Sirve como lista de comprobacin de puntos de accin que guan al programador para realizar correcciones.

DIRECTRICES PARA LA REVISIN Se deben establecer de antemano directrices para conducir la RTF. Las directrices ms comunes son las siguientes: 1. Revisar al producto no al productor. 2. Fijar una agenda y mantener. La RTF debe seguir un plan de trabajo concreto. El jefe de revisin es el encargado de mantener el plan de la reunin. 3. Limitar el debate y las impugnaciones. Cuando se identifique alguna indecencia, puede o no haber unanimidad sobre su impacto. Sin embargo no se deber perder el tiempo debatiendo la cuestin si no que debe ser registrada y resolverse en otro momento. 4. Enunciar las reas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto. La resolucin de problemas deber ser propuesta para despus de la revisin. 5. Tomar notas. De preferencia, estas notas deber ser escritas en un pizarrn de forma que puedan ser comprobadas por el resto de los revisores. 6. Limitar el nmero de participantes e insistir en la preparacin adecuada.

126

CALIDAD DE SOFTWARE

7. Desarrollar una lista de comprobacin para cada producto que ser revisado. Esta lista ayuda al jefe de revisin a estructurar la reunin. Se deben desarrollar listas de comprobacin para los documentos de anlisis, diseo, codificacin y prueba. 8. Llevar a cabo un buen entrenamiento formal de todos los revisores. 9. Disponer recursos y una agenda para las RTF para que las revisiones sean efectivas, se deben planificar como una tarea de ingeniera del SW. 10. Repasar las revisiones anteriores. Las sesiones de informacin pueden ser beneficiosas para descubrir problemas en el propio proceso de revisin. El primer producto que se haya revisado puede establecer las propias directivas de revisin. TCNICAS ASOCIADAS A SQA A NIVEL DE PROYECTO SQA aborda principalmente 3 reas o tcnicas. Mtricas de SW. Verificacin y valoracin. Gestin de la configuracin.

Las tcnicas de revisin de los productos de SW y las pruebas estn fundamentalmente orientadas a la deteccin de defectos en el SW que a la evaluacin de aspectos orientados a la calidad.

Figura 33.

Este aseguramiento de la calidad se realiza a travs de modelos. Los ms conocidos son los siguientes: Modelo de Boehm. Modelo factores/criterios & mtricas.

127

CALIDAD DE SOFTWARE

Marco ISO 9126. Paradigma GQM (Goal Question - Metric). Modelo Gilb. Modelo CMM (Capability Maturity Model). Modelo SPICE (Software Process Improvement and capability Determination).

MTRICAS Es una metodologa de planificacin, desarrollo y mantenimiento de sistemas de informacin, o una asignacin de un valor y un atributo de una entidad de SW. Las mtricas nos ayudan a entender tanto el proceso tcnico que se utiliza para desarrollar un producto, como el propio producto, as como el proceso para intentar mejorarlo, el producto se mide para intentar aumentar su calidad. [9]

Clasificacin de las mtricas de SW: Clasificacin 1 Mtricas de producto. Mtricas de proceso. Clasificacin 2 Mtricas basadas en atributos internos del producto. Medidas de estructuracin de un programa. Mtricas de complejidad. Mtricas de cobertura de pruebas. Mtricas de calidad y diseo. Mtricas basadas en atributos externos del producto. Mtricas de portabilidad. Mtricas de defectos. Mtricas de usabilidad. Mtricas de Mantenibilidad. Mtricas de Fiabilidad. Mtricas basadas en el cdigo fuente. No. de lneas de cdigo. No. de lneas de comentarios. No. de instrucciones (funciones). Densidad de documentacin. Mtricas basadas en estructura de diseo. Relacionadas con el control intramodular. Relacionadas con el acoplamiento entre clases. Mtricas para sistemas orientados a objetos. Acoplamiento. Herencia.

128

CALIDAD DE SOFTWARE

HERRAMIENTAS DE CALIDAD

Figura 34. Principales Herramientas de Calidad

Herramientas bsicas. Diagrama de flujo: Es una representacin grafica de la secuencia de pasos a realizar para producir un cierto resultado, que puede ser un producto material, informacin o servicio o combinacin de los 3. Diagrama causa efecto: Es una herramienta que ayuda a identificar, clasificar y poner de manifiesto posibles causas, tanto de problemas especficos como de caractersticas de calidad. Checklist. Grfica de control: Herramienta de calidad que consiste en una grafica en la que se hace corresponder un punto a cada valor de un estadstico calculado a travs de muestras sustradas de un proceso sucesivo. Histograma: Conjunto grafico del resultado de la variacin de un conjunto de datos, nos permite ver pautas imposibles de ver a simple vista. Diagrama de dispersin: Se utiliza para ver si dos variables se encuentran relacionadas y en qu medida. [10]

Herramientas de gestin. Herramientas de creatividad. Herramientas estadsticas. Herramientas de diseo. Herramientas de medicin. Niveles de madurez.

129

CALIDAD DE SOFTWARE

UNIDAD III ESTNDARES DE CALIDAD APLICADOS AL SOFTWARE

130

CALIDAD DE SOFTWARE

3.1 ISO.

Figura 35. Sello de ISO.

La ISO (International Standarization Organization) es la entidad internacional encargada de favorecer la normalizacin en el mundo. Con sede en Ginebra, es una federacin de organismos nacionales, stos, a su vez, son oficinas de normalizacin que actan de delegadas en cada pas, como por ejemplo: AENOR en Espaa, AFNOR en Francia, DIN en Alemania, etc. con comits tcnicos que llevan a trmino las normas. Se cre para dar ms eficacia a las normas nacionales.

Qu es una norma? Las normas son un modelo, un patrn, ejemplo o criterio a seguir. Una norma es una frmula que tiene valor de regla y tiene por finalidad definir las caractersticas que debe poseer un objeto y los productos que han de tener una compatibilidad para ser usados a nivel internacional. Pongamos, por ejemplo, el problema que ocasiona a muchos usuarios los distintos modelos de enchufes que existen a escala internacional para poder acoplar pequeas mquinas de uso personal: secadores de cabello, mquinas de afeitar, etc. cuando se viaja. La incompatibilidad repercute en muchos campos. La normalizacin de los productos es, pues, importante. La finalidad principal de las normas ISO es orientar, coordinar, simplificar y unificar los usos para conseguir menores costes y efectividad. Tiene valor indicativo y de gua. Actualmente su uso se va extendiendo y hay un gran inters en seguir las normas existentes porque desde el punto de vista econmico reduce costes, tiempo y trabajo. Criterios de eficacia y de capacidad de respuesta a los cambios. Por eso, las normas que presentemos, del campo de la informacin y documentacin, son de gran utilidad porque dan respuesta al reto de las nuevas tecnologias

131

CALIDAD DE SOFTWARE

Tipologa

de

normas

Las normas pueden ser cuantitativas (normas de dimensin, por ej. las DIN-A, etc) y cualitativas (las 9000 de cualidad, etc.) [11] (MCarmeSansBibliotecria-documentalista) (http://www.ub.edu/geocrit/b3w-129.htm) La Organizacin Internacional para la Estandarizacin, ISO por sus siglas en ingls (International Organization for Standardization), es una federacin mundial que agrupa a representantes de cada uno de los organismos nacionales de estandarizacin (como lo es el IRAM en la Argentina), y que tiene como objeto desarrollar estndares internacionales que faciliten el comercio internacional. El objetivo de ISO es promover el desarrollo de la normalizacin y actividades conexas en el mundo, con el fin de facilitar el intercambio internacional de bienes y servicios, y desarrollar la cooperacin en las esferas de actividad intelectual, cientfica, tecnolgica y econmica. Cuando las organizaciones tienen una forma objetiva de evaluar la calidad de los procesos de un proveedor, el riesgo de hacer negocios con dicho proveedor se reduce en gran medida, y si los estndares de calidad son los mismos para todo el mundo, el comercio entre empresas de diferentes pases puede potenciarse en forma significativa y de hecho, as ha ocurrido . Durante las ltimas dcadas, organizaciones de todos los lugares del mundo se han estado preocupando cada vez ms en satisfacer eficazmente las necesidades de sus clientes, pero las empresas no contaban, en general, con literatura sobre calidad que les indicara de qu forma, exactamente, podan alcanzar y mantener la calidad de sus productos y servicios. De forma paralela, las tendencias crecientes del comercio entre naciones reforzaba la necesidad de contar con estndares universales de la calidad. Sin embargo, no exista una referencia estandarizada para que las organizaciones de todo el mundo pudieran demostrar sus prcticas de calidad o mejorar sus procesos de fabricacin o de servicio. Teniendo como base diferentes antecedentes sobre normas de estandarizacin que se fueron desarrollando principalmente en Gran Bretaa, la ISO cre y public en 1987 sus primeros estndares de direccin de la calidad: los estndares de calidad de la serie ISO 9000. Con base en Ginebra, Suiza, esta organizacin ha sido desde entonces la encargada de desarrollar y publicar estndares voluntarios de calidad, facilitando as la coordinacin y unificacin de normas internacionales e incorporando la idea de que las prcticas pueden estandarizarse tanto para beneficiar a los productores como a los compradores de bienes y servicios. Particularmente, los estndares ISO 9000 han jugado y juegan un importante papel al promover un nico estndar de calidad a nivel mundial. [12] ISO es un organismo de mbito mundial dedicado a la creacin de normalizacin principalmente de la calidad. La finalidad de estar normas es orientar, coordinar, simplificar y unificar la gestin de una organizacin, con la expectacin de mejorar los costos y efectividad. Las normas que son reglas o patrones, son formulas con la finalidad de definir las

132

CALIDAD DE SOFTWARE

caractersticas de debe poseer un objeto, y los productos que deben tener una compatibilidad para ser usados a niveles internacionales permitiendo acoplar mquinas de uso personal. ISO lleva un valor indicativo y gua, su uso se ha extendido, demostrando el inters que se tiene sobre el seguimiento de normas gracias a los ahorros econmicos que estas han presentado las organizaciones que aplican las normas, ISO crese a gran medida durante las ltimos aos es muy comn ver el logotipo de ISO en las empresas, inclusive se a confundido esto a con una Moda que infravalora el cometido de ISO y la finalidad para la cual fue creada, la cultura en general y la bsqueda de economa de las empresas, propensa que una certificacin, sea solo eso un simple documento que indica que tal o cual empresa esta certificando con normas ISO, y se deja atrs todo lo que envuelve una certificacin, esto no quiere decir que certificarse sea un proceso simple y fcil de llevar, la seriedad con la que una empresa involucra a sus actores puede es determinante para el xito de la implantacin de la norma y la obtencin de resultados favorables. ISO puede llegar a ser tan desapercibido que no nos damos cuenta que se encuentra en circunstancias muy cotidianas, y contribuye a que tengamos una mejor de calidad de vida, con cosas tan pequeas como una llamada telefnica o en cosas tan importantes como es la educacin. CMMI es una importante metodologa de estandarizacin diseada para el proceso de desarrollo de software, basada en niveles de madurez, creada en el Software Engineering Institute, y actualmente es de las ms importantes estandarizaciones enfocadas al software. Para el diseo de software ISO crea SPICE que tambin se basa niveles de madurez en procesos, actualmente se est desarrollando una variante de SPICE dirigida alas las pequeas y medianas empresas desarrolladoras de software, con el fin de apoyar y fomentar el desarrollo de las mismas y as como tambin mejorar el futuro del desarrollo del software. Las siguientes pginas sern dedicadas a enfatizan en los temas descritos anteriormente. Organizacin Internacional para la Normalizacin (ISO) Las siglas ISO hacen referencia al nombre en ingles de la organizacin: International Organization for Standardization, incluyendo que la palabra ISO viene del griego isos que significa igual. La organizacin se fundada por Willy Kuert despus de la segunda guerra mundial el 23 febrero en el ao de 1947, los legados de 25 pases se reunieron en Londres, buscando crear un organismo que facilitara la coordinacin internacional y la unificacin de las normas del sector. Visto de manera general, se encargada de promover el desarrollo de estndares de fabricacin, comercio y comunicacin, en la mayora de las ramas industriales, dejando a un lado la elctrica y la electrnica ya que se rigen por los estadales del IEEE (Institute of Electrical and Electronics Engineers). La principal funcin de ISO es llegar a una estandarizacin de normas de productos y seguridad aplicable a empresas u organizadores de nivel internacional. ISO se constituye de una red de 162 pases (figura 1), sobre la base de un miembro por pas y su sede se encuentra en Secretara Central en Ginebra (Suiza), encarada de la coordinacin en el sistema. ISO se constituye tanto por instituciones gubernamentales y no gubernamentales.

133

CALIDAD DE SOFTWARE

Siendo una organizacin no gubernamental ISO no puede imponer sus normas, por lo tanto sus normas son voluntarias, incluido a esto ISO tiene vnculos con la organizacin de la normalizacin (ON) que se dedica a producir normas internacionales industriales y comerciales que son conocidas como normas ISO. En la siguiente figura se aprecia el alcance mundial que ISO tiene:

Miembros natos Miembros correspondientes Miembros suscritos Otros Estados clasificados ISO 3166-1, no miembros de la ISO

Figura 36: Mapa del alcance de ISO

Primordialmente la intencin que ISO tiene es llegar a constituir un punto de calidad medible, que permita establecer que tanta calidad o ausencia de esta hay en los procesos que implican la creacin de un producto o la generacin de un servicio, para ello ISO crea y especifica diferentes normas enfocadas en rubros como puede ser Calidad (ISO 9000) o Medio Ambiente (ISO 14000), a la fecha se han creado ms de 17.500 normas internacionales. Por qu hacer estndares? Los estndares nos dan numerosas y positivas contribuciones a los ms importantes aspecto de nuestras vidas Los estndares garantizas las caractersticas deseadas de los productos y servicios tales como calidad, medio ambiente, fiabilidad eficiencia y capacidad de intercambio con un costo econmico. Cuando los productos o servicios satisfacen nuestras expectativas, tendemos a aprovecharlo y desconocemos el papel que los estndares desempean en dicha satisfaccin. De cualquier modo, cuando los estndares estn ausentes, pronto ser notorio, los artculos comienzan a ser incompatibles, no son confiables o incluso peligrosos.

134

CALIDAD DE SOFTWARE

Los estndares influyen para el desarrollo, fabricacin y suministro de productos y servicios ms seguros eficientes y claros, facilitan el comercio entre pases, hacindolo comn y objetivo, proporcionan una base tcnica a los gobiernos para la salud, la seguridad y la legislacin ambiental y permitiendo compartir avances tecnolgicos. Para un empresa adoptar los estndares ISO implica que pueden desarrollar y ofrecer, productos y servicios que cumplen con las especificaciones y tiene compatibilidad entre competidores, lo cual mejora a gran medida la idea de venta, ya que un consumidor puede usar productos de diferentes marcas y mantener una buena calidad y funcionamiento entre los distintos productos. En la innovacin permiten acelerar la difusin de las nuevas creaciones dejando un desarrollo en comn, para cualquiera que pretende innovar, la existencia de diferentes normas o estndares provoca dificultades tecnolgicas que pueden impedir el avance tecnolgico. En la actualidad el problema del la preservacin del medio ambiente es de gran prioridad, ISO ha creado normas que regulen el uso de los recursos naturales que como aire, agua, suelo, adems de regular los residuos industriales y el reus de estos.

Los estndares internacionales que la ISO desarrolla son muy tiles. Son tiles a las organizaciones industriales y de negocio de todos los tipos, a los gobiernos y a otros cuerpos reguladores, negociar a funcionarios, a los profesionales del gravamen de la conformidad, a los suplidores y a los clientes de productos y de servicios en sectores pblicos y privados, y, en ltima instancia, a la gente en general en sus papeles como consumidores y usuarios finles. Los estndares de ISO contribuyen a hacer el desarrollo, la fabricacin y la fuente de los productos y de los servicios ms eficientes, ms seguros y ms limpios. Hacen comercio entre los pases ms fcil y ms favorablemente. Proveen de gobiernos una base tcnica para la salud, la seguridad y la legislacin ambiental. Ayudan en tecnologa de transferencia a los pases en vas de desarrollo. Los estndares de ISO tambin sirven para salvaguardar consumidores, y a usuarios en general, de productos y de servicios - as como para hacer sus vidas ms simples. Cuando las cosas van bien - por ejemplo, cuando los sistemas, la maquinaria y los dispositivos trabajan bien y con seguridad - es entonces porque ellos llegan a cumplir con los estndares y la organizacin responsable de muchos millares de los estndares que benefician a sociedad alrededor del mundo es ISO. El plan estratgico 2005-2010 de ISO conforma la visin global de la organizacin en 2010, junto con los siete objetivos estratgicos precisados para resolver las expectativas de los miembros y accionistas de la ISO. [13]

Beneficio de los estndares El gran ganador de la aplicacin de estndares es el cliente mismo, ya que con esto se puede garantizar que se est consumiendo un producto de calidad, existe una la amplia cantidad de productos a escoger y adherido a esto, la existencia de competencia entre empresas mejora los costos y su calidad.

135

CALIDAD DE SOFTWARE

Hay una serie de beneficios superficiales o poco previsibles a simple vista, ya que estos se vuelven cotidianos, alguna vez nos hemos preguntado qu pasara si cada producto de electrnica tuvieras sus propias caractersticas, cul sera el costo de mantenimiento o una reparacin a cada tipo producto, que pasara si en un pas extranjero existiera un smbolo distinto para sealar un alto voltaje, o que una sustancia es venenosa, o que tan difcil seria efectuar una llamada de larga distancia si en cada pas existiera un protocolo de comunicacin distinto, o simplemente como seria la comunicacin por Internet, o algo tan comn como una tarjeta bancaria, que pasara si cada banco usara la propia, las normas ISO no implican una simple estandarizacin para generar un producto igual y de calidad a pesar de las diferentes polticas en las empresas, ISO envuelve un factor muy importante Calidad de vida, cosas tan cotidianas mencionadas al inicio de este prrafo mejoran la calidad de vida a gran medida y de manera mundial. Cmo se decide hacer un estndar? ISO desarrolla nueva normas en base a las necesidades que el mercado presenta, cuando un sector expresa de manera clara una necesidad por una norma esta debe comunicarla a los representante nacionales de ISO, este ultimo propone la norma si es aceptada se asigna una comisin tcnica. Existen diferentes comits tcnicas, formados por expertos de los sectores industriales, tcnicos, y empresariales, cada uno es especfico y especializado en un rubro para tener un mejor trato sobre la creacin de normas, es posible que dependiendo de la necesidad por la norma se creen nuevos comits especializados en lo que sea requerido. Es muy probable que una norma ISO este propensa a los cambios para ellos cada norma es marcada con una versin.

Como los estndares de ISO benefician a sociedad Para los negocios, la adopcin extensa de estndares internacionales significa que los suplidores puedan basar el desarrollo de sus productos y servicios en las especificaciones que tienen aceptacin amplia en sus sectores. Esto, alternadamente, significa que los negocios que usan estndares internacionales son cada vez ms libremente competir en muchos ms mercados alrededor del mundo. Para los clientes, la compatibilidad mundial de la tecnologa se alcanza que cuando los productos y los servicios se basan en estndares internacionales les trae una opcin cada vez ms amplia de ofertas, y tambin les beneficia de los efectos de la compencia entre suplidores. Para los gobiernos, los estndares internacionales proporcionan las bases tecnolgicas y cientficas que sostienen salud, seguridad y la legislacin ambiental. Para los funcionarios comerciales negociar la aparicin de mercados regionales y globales, los estndares internacionales crean "un campo que juego de nivel" para todos los competidores en esos mercados. La existencia de estndares nacionales o regionales divergentes puede crear

136

CALIDAD DE SOFTWARE

trabas tcnicas de comercio, incluso cuando hay acuerdo poltico de eliminar cupos de importaciones restrictivos y los similares. Los estndares internacionales son los medios tcnicos por los cuales los acuerdos comerciales polticos se pueden poner en prctica. Para los pases en vas de desarrollo, los estndares internacionales que representan un consenso internacional de primer nivel constituyen una fuente importante de los conocimientos tecnolgicos. Definiendo las caractersticas que los productos y servicios se esperan que lleguen a los mercados de exportacin, los estndares internacionales dan a pases en vas de desarrollo una base para tomar las decisiones derechas al invertir sus recursos escasos y evitan as de malgastarlos. Para los consumidores, la conformidad de productos y los servicios a los estndares Para todos, los estndares internacionales pueden contribuir a la calidad de la vida en general asegurndose de que el transporte, la maquinaria y las herramientas que utilizan sean seguras. Para el planeta habitamos, los estndares internacionales en el aire, en el agua y el suelo, y en emisiones de gases y de la radiacin, podemos contribuir a los esfuerzos de preservar el medio ambiente. Internacionales proporcionan seguro sobre su calidad, seguridad y confiabilidad. [14]

ISO en Mxico En la actualidad, Mxico, mantiene un gran nmero de empresas certificadas en IS0 9000 (calidad) y mismas que comienzan a integrar ISO 14000 (medio ambiente), pero curiosamente para el pblico en general ISO no es ms que un sello mas para la empresa, mucha de la poblacin no sabe de que se trata o que implica una certificacin ISO, en lo personal solo adentrando en el tema fue posible comprender la importancia que esta tiene, pero, para que necesita saber una persona de que se trata una norma ISO, como ya se menciono anteriormente ISO pretende mejorar la calidad de vida, y por simple cultura es necesario entender lo que implica tener un producto certificado en mano.

Figura 37. ISO en Latinoamrica

Pareciera que el conocimiento y entendimiento de las normas est dirigido solo al sector directivo de las empresas, esto claro, dirigido a la toma de decisiones y la aplicacin de la las normas sobre los procesos propios de las empresa, siendo que es ms que notoria la influencia que tienen las normas ISO en la vida cotidiana de cada mexicano. Cada vez es ms comn

137

CALIDAD DE SOFTWARE

encontrar el logo de ISO las empresas confundiendo esto con una moda sin tomar la importancia que desempea el papel de este logo. Como criterio personal, las autoridades responsables de la difusin no han tenido el desempeo adecuado, que permita conocer el por qu de usar estndares. Con respecto al software existe un problema cultural que es afectado por la poca informacin sobre el uso de estndares, como es sabido desde sus inicios el software a tenido muchos problemas en cuanto como medir su calidad, no exista ningn tipo de control o disciplina, con el tiempo Watts Humphrey y el Software Engineering Institute crearon algunos de los estndares, mtodos y metodologas ms conocidos para regular el software como lo es PSP (Personal Software Process), TSP (Team Software Process) y CMMi (Capability Maturity Model integated), y por su parte ISO con SPICE (Software Process Improvement and Capability Etermination). La problemtica existente con respecto al conocimiento de la importancia del uso de los estndares, incluyendo la cultura general y la necesidad por el cambio educativo a un enfoque ms apegado al seguimiento de estndares en lo que a software se refiere, (este ltimo es un problema mundial no solo de Mxico), provoca que la aplicacin de un estndar se vuelva complejo, e impide el mejoramiento de los mismos, manteniendo un estancamiento en lo que avance tecnolgico del software refiere. Actualmente se comienza a salir de este hoyo desarrollando ms carreras como Ingeniera de Requerimientos, por su parte empresas mexicanas desarrolladoras de software comienzan a crear sus propias universidades con la finalidad de mantener la aplicacin adecuada de estndares y mejorar la educacin sobre el desarrollo de software al igual que adoptando nuevas metodologas de pases lderes en desarrollo de software como la India.

ISO 9000

Figura 38. ISO 9000

Una de las normas importantes y por consecuente de las ms comnmente vistas en las empresas por su inters sobre la calidad y el concepto de gestin continua de calidad. Mantiene una serie de ventajas y grandes aportes al sistema de calidad de las empresas que la aplican: Monitoreo de los principales procesos asegurando su efectividad Mantener un registro de apropiados de la gestin, procesos y procedimientos

138

CALIDAD DE SOFTWARE

Satisfacer de los clientes o usuarios Mejora continua de procesos operacionales y de calidad Procedimientos para la correccin de problemas Monitoreo de los procesos

Fue creada en 1987 en base a un estndar britnico (BS), actualmente se encuentra en su versin 2008, publicada el 13 de noviembre del 2008. Es parte de una familia de normas enfocadas a la gestin de calidad. Para que una organizacin pueda certificarse con la norma ISO 9000 debe elegir el alcance de la actividad que vaya a registrarse, se selecciona un registro y se audita, dicha auditoria debe ser completada con xito, y para mantener la certificacin cada ao se efecta una inspeccin, en caso de que el auditor encuentre areas de incumplimiento, se otorga un plazo para correccin de errores, periodo en el cual se continua con el proceso de la certificacin, o en caso de que exista una certificacin esta no se pierde. La implementacin de un sistema de calidad ISO 9000 requiere ms que educacin sobre la norma, es necesaria la concientizacin de todo el crculo organizacional, buscando que dicho crculo tenga la facilidad de comprender la norma y adaptarse al cambio, de este modo se crea un ambiente favorable para el sistema de calidad entrante. La norma ISO 9000 puede tener un efecto negativo, que comnmente es a causa que se pierde el concepto real de la norma y simplemente se ve como un requisito ms para competir en el mercado. Esto en ocasiones afecta la norma de manera que minimiza el valor real que esta puede aportar a la calidad y se mas como un estorbo ms que una mejora, esto provoca graves problemas organizacionales y lo empeora el panorama es que afecta la satisfaccin del cliente. La seriedad y grado de conciencia con la que los empresarios tomen las normas, la flexibilidad al cambio o adaptacin, son factores importantes en el xito de la norma.

ISO 14000

Figura 39. ISO 14000

La incierta situacin del medio ambiente durante las ltimas 2 dcadas ha incitado un movimiento mundial enfocado a la bsqueda de la preservacin ambiental, con la implantacin te conceptos como sostenibilidad se han efectuado grandes esfuerzos de parte de las ms importantes organizaciones internacionales, buscando unacuerdo comn entre naciones para ejercer un esfuerzo mutuo en aspectos como proteccin a los animales y ahorro de recursos.

139

CALIDAD DE SOFTWARE

ISO tomando la responsabilidad correspondiente como un instituto internacional crea una serie de normas orientadas a la regulacin de los desechos industriales, el ahorro y reuso de recursos en las empresas, que aunque existen distintas leyes que obligan a que las empresas sigan un proceso sobre la contaminacin que producen, ISO pretende concientizar a las empresas sobre la importancia que tiene la preservacin del medio ambiente, creando la norma ISO 14000. ISO 14000, tambin llamado ISO Verde por su relacin con el medio ambiente, busca que cualquier empresa tome una postura amigable hacia el medio ambiente, ISO 14000 requiere que la existencia de una poltica ambiental, no solo para la parte directiva de la organizacin, tambin incluye todo personal que tenga que ver con el proceso organizacional, dicha poltica de ser clara acorde a la legislacin ambiental.Pareciera que esta norma esta solo enfocada al cumplimiento de las leyes correspondientes al medio ambiente, sin embargo tiene distintas aportaciones: 1. Evita todo tipo de multas, sanciones o costos jurdicos reduciendo los riesgos de incumplimiento de leyes 2. Permite el acceso a ayudas econmicas de proteccin ambiental 3. Reduce los costos de produccin, controlando y el ahorrando materia prima 4. Permite el ahorro de energa y agua 5. Minimiza los residuo El reto en esta norma ISO se encuentra en demostrar la mejora continua y la existencia de una responsabilidad seria hacia la aplicacin de esta norma mediante los llamados Sistemas de Gestin Ambiental, un concepto nuevo que en los ha ido creciendo conforme a la gravedad de la problemtica ambiental.

Figura 40. Estndares genricos para sistemas de gestin

140

CALIDAD DE SOFTWARE

3.2 SPICE. A medida que el software evoluciona, la calidad que este exige es cada vez ms importante en las organizaciones desarrolladoras, dado que la calidad influye en costos finales, adems marca una diferenciacin entre los compartidores, y ms importante aun la imagen que la organizacin que tienen ante el cliente. En la actualidad el proceso de calidad en el software se encuentra en sus etapas iniciales, buscando alcanzar llegar a una madurez, por esto las empresas estn aplicando modelos de control y mejora de procesos, ms concretamente aun, estudios estadsticos arrojan que de entre los procesos de mejora existente destacan dos grandes grupos que son los de mas uso en la industria de software: CMMI e ISO / IEC 15504.

Figura 41. ISO/IEC 15504

Los modelos de evaluacin de procesos sobre el desarrollo de software adoptan diferentes maneras para realizar dichas evaluaciones, la evaluacin por niveles de madurez donde la organizacin mejora sus procesos obteniendo puntuacin a nivel organizacional (departamento, proyecto, registro, etc.) y la evaluacin por niveles de capacidad donde las organizaciones obtienen puntuacin a nivel de proceso (gestin de requisitos, planificacin de proyectos, etc.). Segn el Software Engineering Institute (SEI), el modelo la evaluacin por niveles es ms extendida, actualmente existen ms de 3000 organizaciones certificadas en distintos niveles de madurez de CMMI. A diferencia de la norma ISO/ IEC 15504, mejor conocida como SPICE (Software Process Improvement and Capability Etermination), CMMI incorpora la evaluacin por niveles de madurez, dando una puntuacin a la organizacin. Como se explica en prrafos anteriores, un ISO nace gracias a las necesidades de un sector industrial, y debido a que dicha necesidad aparece sobre el software, ISO crea una norma para el desarrollo de software, basndose en niveles de madurez, y como todo ISO creando un marco de trabajo que permita llegar a la meta para la cual es creada la norma. A la fecha SPICE estaba hecha para la aplicarse sobre procesos y careca de un anlisis de la organizacin en total (como hace CMMI).Con la nueva estructura de SPICE (ISO/IEC 155047), las certificaciones organizacionales fueron contempladas, incluso SPICE tiene una versin aplicable a las PyMes, con la clara intencin de mejorar la cultura de desarrollo de software en las empresas desde sus inicio.

141

CALIDAD DE SOFTWARE

Estructura de SPICE La norma ISO/IEC 15504-7 establece 6 niveles de madurez, para clasificar las organizaciones el siguiente esquema muestra la escritura de dichos niveles: Nivel 0 - Inmadura: La organizacin no tiene una implementacin efectiva de los proceso o carece de estos Nivel 1 - Bsico: La organizacin implementa los procesos y alcanza los objetivos que tienen los procesos. Nivel 2 - Gestionada: Adems de implementar los procesos, son gestionados y los productos se establecen, controlan y mantienen. Nivel 3 - Establecida: Se implanta la utilizacin de estndares en los procesos Nivel 4 - Predecible: Se empieza la aplicacin de mtricas y los procesos son gestionados de manera cuantitativa. Nivel 5 - Optimizado: La organizacin entre en una mejora continua de manera que permita cumplir los objetivos del negocio.

Figura 42. niveles de SPICE

SPICE mantiene un estructura es muy similar a la CMMI, aunque tiene 3 clases de certificacin, de las cuales 2 son internas y no tienen una validez oficial, a diferencia de la clase 1 que es ms exhaustiva y rigurosa, permitiendo obtener una puntuacin suficiente para obtener una certificacin oficial.

142

CALIDAD DE SOFTWARE

Uno de los detalles marcado dentro de modelo de evolucin dice que para poder evaluar un proceso se necesita es necesaria una serie de atributos de proceso los cuales definen un aspecto particular del proceso. De manera concreta para definir el cumplimiento de un proceso, cada proceso debe tener un conjunto de prcticas que deben hacerse a llegar comprobar el cumplimiento del proceso. Todos los estndares estn dirigidos a grandes organizaciones, que resultan costosos de implantar y no visualizan las necesidades actuales de las PYMEs y los pequeos grupos de desarrollo que no pueden costear la implantacin de estndares a dems que implica un gran esfuerzo tiempo y recursos, adems de que el beneficio es a largo plazo. Las PYMEs que cada vez son ms numerosas, la manera de gestionar un proceso desde el inicio de las empresas representa la velocidad de crecimiento que esta tenga, una empresa que comienza adaptndose a un estndar desde sus comienzos tiende a obtener un prestigio sobre sus cliente y a sobre salir rpidamente. Gran parte de la problemtica que tiene una empresa al implantar un estndar es que en sus desarrollos en base a software artesanal, para prevenir esta problemtica, ISO propone un estndar adaptable a los empresarios emprendedores. Tomando como referencia la problemtica antes descrita el grupo formado por AENOR, Universidad de Castilla La Mancha, Universidad Rey Juan Carlos, Kybele Consulting y Prysma, crea un modelo enfocado a las PYMEs, y grupos pequeos de desarrollo, que permita evaluarlas con el modelo de niveles de madurez, y apegada a la norma ISO/IEC 15504 PYME. El modelo es avalado por la norma ISO/IEC 17021. Es importante como se ha buscado la llegada de estndares a empresas en desarrollo, la cuales han sido un sector del mercado olvidado por este tipo de normas, y como en un futuro, esto llegara a favorecer ampliamente el desarrollo de software y el avance tecnolgico, solo el tiempo demostrar como la implementacin de estndares puede mejorar el avance de la cientfico, y en el caso de SPICE, como la informtica evoluciona. Es necesario romper con algunos esquemas culturales para poder comenzar con un correcto uso de normas que mejorara en gran medida un aspecto importante en la humanidad: Calidad de vida, a pesar de ser algo como marcado a la vista de la poblacin, es primordial concientizarse en la importancia del uso de las normas, e incluso ir ms all, y hablar de lo que implica no el solo aplicar un norma su no la continuidad que se necesita para que exista un resultado favorable. Personalmente y dada la experiencia en la aplicacin de normas para el desarrollo de software, considero que la idea de la cultura mexicana es un reto muy grande a romper, una de las soluciones se encuentra principalmente en el sistema educativo universitario, no es que este mal en su totalidad, la idea de solucin se encuentra en acercarse a las empresa desarrolladoras de software y tratar los temas necesarios para preparar profesionales competentes en el rea informtica y sus derivadas, ya que es posible encontrar que un profesional en computacin tiene poca o nula, experiencia en temas aplicables en la realidad del desarrollo de software.

143

CALIDAD DE SOFTWARE

3.3 CMM. El origen primordial del software proviene, principalmente, de la existencia de un problema a solucionar y se pretende resolver mediante la implantacin de un sistema o proceso de informacin, el cual tiene que pasar por un proceso de concepcin, algo extenso, pero que a la larga ofrezca beneficios, tanto para quien lo necesita como para el que lo desarrolla. En este proceso de desarrollo estn involucradas varias personas, de las cuales se pueden mencionar a varias destacables, como lo son el cliente, el analista y el desarrollador, ya que jugaran papeles importantes en este ciclo de desarrollo, ya que uno debe brindar los requerimientos deseados en el software y el otro los debe llevar a un plano ejecutable mediante un concepto creado por el otro.

Figura 43. Logo de CMMi

Pero que es el software y que tareas implica su desarrollo? El termino <<software>> fue utilizado por primera vez en la dcada de los 50s por John W. Tukey en el ms amplio y completo de sus sentidos, es decir, que el software es un conjunto funciona de programas de computo, procedimientos, reglas, documentacin y datos asociados que forman parte de las operaciones de un sistema de computacin. En otras palabras el software no solo es un programa computacional que ejecuta tareas y cumple un objetivo en particular, si no que conlleva otros elemento ms, como los son los documentos que se deben producir junto el programa y ser as una unidad funcional de trabajo. Es decir, el software debe ser un conjunto funcional de todos los elementos no tangibles producidos durante todo el proceso de vida del software. Sin embargo este aspecto es un tema muy descuidado por parte de las personas encargadas de la produccin de software, sobre todo en la parte de la documentacin es donde ms se encuentran debilidad sobre el punto especifico de la documentacin. En muchas ocasiones esto deriva en productos poco confiables o de escasa calidad y confiabilidad por no contar con elementos bien definidos y bien hechos que conformaran un producto de software completo de calidad y prestigio. A raz de esta situacin los desarrolladores han tratado de disear alguna metodologa efectiva de desarrollo que ayude de manera integral en el desarrollo y construccin de aplicaciones

144

CALIDAD DE SOFTWARE

informticas que puedan llamarse software en toda la extensin de la palabra, que adems incluya una calidad alta y as tambin una efectividad como la deseada por el cliente. Con base en un desarrollo sin pautas bien establecidas, ni un proceso de trabajo definido y con bases slidas, la industria del software se encontraba en un predicamento que pona en peligro su evolucin y por tanto su existencia como tal. A pesar de que el problema en el desarrollo de software era algo latente, fue hasta 1984 cuando se dio uno de los pasos ms importantes para el futuro del software. En 1984 se aprob la creacin de un organismo de investigacin para el desarrollo de modelo de mejora para los problemas en el desarrollo de los sistemas de software, y para evaluar la capacidad de respuesta y fiabilidad de las compaas que suministran software; esta aprobacin fue hecha por el Congreso del Gobierno Americano, ya que le interesaba evaluar y mejorar la fiabilidad de los sistemas suministrados al Departamento de Defensa. Despus de esta aprobacin, se cre el SEI (Software Engineering Institute), el cual fue fundado por el Departamento de Defensa Americano y la Universidad Carnegie Mellon. El SEI comenz sus investigaciones con en 1985 en busca de un marco de madurez de procesos que permita evaluar las empresas productoras de software, es decir, se comienza a trabajar en algn proceso o manera de trabajar que ayude a las empresas productoras alcanzar diferentes niveles de madurez, tanto es sus procesos y manera de trabajar como en sus productos generados a travs del ciclo de vida del software. Pero que es la madurez? La madurez de una empresa esta expresa en que procesos siguen para la produccin de software, adems de que tanto estos procesos esta homogneamente implantados en la organizacin, la definicin de su rigor o flexibilidad, deben estar en conocimiento de todos y cada uno de los empleados de la organizacin, adems de su correcta ejecucin, tienen que medirse y ser mejorados de manera constante a travs del tiempo y en medida que esto se lleve a cabo, se dice que las organizaciones son ms o menos maduras, segn aplique. Tras una amplia investigacin y arduo trabajo de diseo y metodologa de procesos, al fin sale a luz un proyecto llamado Modelo de Madurez de las Capacidades (CMM) que viene a suponer la evolucin de la investigacin en el ramo. El CMM (Capability Maturity Model) o Modelo de Capacidad De Madurez se trata de un modelo de calidad aplicado a software que clasifica a las empresas en niveles de madurez. En 1991 se integra el modelo, de manera que este evoluciona a CMMi. Segn este modelo de calidad, dichos niveles nos sirven para conocer la madurez de los procesos que se ejecutan dentro de la empresa para disear, implementar y desarrollar software. El Modelo coloca como una organizacin inmadura a aquella que muestra los siguientes sntomas: Procesos improvisados e implementados por administradores y desarrolladores.

145

CALIDAD DE SOFTWARE

Se resuelven las crisis inmediatas. La organizacin no cuenta con bases objetivas para resolver los problemas o para juzgar la calidad. En cambio, para decir que una empresa es madura, se toman las siguientes caractersticas: La organizacin tiene la habilidad de administrar los procesos de desarrollo y mantenimiento necesario. Los procesos marcados como obligatorios en la organizacin estn documentados de manera adecuada, son usables y consistentes con la forma en la que se trabaja. Los papeles y las responsabilidades son lo suficientemente claros. Los procesos son revisados cuando es requerido. El monitoreo de calidad se realizan sobre bases cuantitativas y objetivas. El calendario y el presupuesto son realistas, se cumplen las metas de tiempo, calidad y presupuesto. Definicin del modelo. Adems de ubicar a las empresas como maduras o no maduras el CMMi, el modelo maneja cinco niveles de madurez, los cuales a continuacin se mencionan y describen de manera general. Inicial o Nivel 1 CMM CMMI

Figura 44. Nivel 1 inicial

En este nivel se encuentran todas las empresas, por el simple hecho de ser empresas que producen productos de software. En estas empresas los presupuestos se elevan de manera descontrolada, tanto para los clientes como para la empresa, provocando un costo excesivo del proyecto. Las fechas de entregan se desfasan hasta niveles insospechados, ya que no se planeo de manera adecuada y solo se hizo una estimacin con un juicio no basado en datos confiables, ya sea porque no se hace as o por no contar con esos datos histricos de desarrollo, por eso se

146

CALIDAD DE SOFTWARE

presentan las desveladas en los trabajadores adems de sus incontable fines de semana trabajando en el proyecto. No se cuenta con un control adecuado sobre el estado que guarda el proyecto, ni si se lleva avance o lleva algn tipo de retraso, no se registra el trabajo avanzado, el desarrollo del proyecto es completamente opaco, la organizacin no sabe lo que pasa con el proyecto durante su desarrollo. Es muy comn que en estas organizaciones que suceda una situacin de premura tpica en los casos en los que se dice: - Cmo va el proyecto? - Bien, bien Un mes despus - Cmo va el proyecto? - Bien, bien Dos meses despus - Oye el lunes se entrega el proyecto, tenlo listo. - Qu?, cmo que el lunes? No, no, no falta muchsimo todava - Cmo que falta mucho? T me dijiste que el proyecto iba bien, yo no se cmo le hagas pero el lunes quiero el proyecto!!! - Si no conoces que tamao va a tener tu proyecto, no sabes cunto te vas a tardar en hacerlo, no sabes cmo va tu proyecto, no sabes cundo va a acabar tu proyecto nunca sabrs cuando vas a acabar. Repetible o nivel 2 CMM-CMMI.

Figura 45. CMMi nivel 2

Este nivel se refiere a que si en el pasado la organizacin tuvo un proyecto exitoso, la metodologa usada se puede repetir, es decir, ya una vez se tuvo xito con la manera de trabajar esto se puede volver a lograr.

147

CALIDAD DE SOFTWARE

La principal diferencia entre este nivel y el anterior reside en que el proyecto es controlado de mejor manera adems de ser gestionado e inspeccionado durante todas las etapas del desarrollo de producto de software. En este nivel el desarrollo no es opaco y siempre se cuenta con la certeza de poder saber en qu estado se encuentra el proyecto, pudiendo identificar posibles atrasos y as corregirlos. Los procesos que hay que implantar para considerarse a una empresa dentro de este nivel son: Gestin de requisitos Planificacin de proyectos Seguimiento y control de proyectos Gestin de proveedores Aseguramiento de la calidad Gestin de la configuracin

Reafirmando la idea general en este nivel la empresa ya implanta el uso de procesos para controlas diferentes aspectos relacionados con el proyecto e importantes para el mismo, tales como: avance actual, nivel de calidad, fechas trmino y entrega; adems integra conceptos de control y seguimiento a actores importantes en el proceso tales como los proveedores de la organizacin. Claro est que esto se logra a travs de proceso bien diseados y estructurados, adems de si amplio conocimiento por parte de los integrantes de la organizacin encargados de ejecutarlos y verificar que realmente las tareas relacionadas con el cumplimiento del proceso se estn llevando en tiempo y forma.

Figura 46. Documentacin y cumplimiento

Este se supone como el primer y exitoso acercamiento de la organizacin con los procesos, lo cual implica un cambio en la forma de trabajo lo cual tambin significa un cambio de cultura organizacional, dado lo anterior no es raro que si los integrantes de la organizacin no se encuentran comprometidos con ella, no llevaran a cabo de manera precisa la ejecucin y seguimiento de los procesos de desarrollo, por lo tanto este es un paso realmente importante para que una empresa sea considerada como una empresa madura.

148

CALIDAD DE SOFTWARE

Definido o nivel 3 CMMi

Figura 47. CMMi Nivel 3 Para alcanzar este nivel de madurez la empresa debe de fijar procesos an ms especficos y detallados enfocndose ms a la forma en que los proyecto son desarrollados tanto en el aspecto de la gestin como de la ingeniera de procesos aplicada al proyecto de manera que estas formas se encuentran perfectamente definidas. Al decir definidas se busca que sta se encuentre plenamente establecida, de manera formal t entendida por los elementos de la organizacin involucrados en su ejecucin. Aunado a estas formas la organizacin debe establecer mtricas, las cuales deben recolectar datos fidedignos acerca de cada fase y si es posible de cada miembro de la organizacin. Todo lo anterior con el mero fin de acercar una proyeccin tanto de trabajo como de esfuerzo para la consecucin tanto de datos histricos de la organizacin como de un producto de alta calidad y perfectamente medido y planeado.

Figura 48. Medicin y planeacin

Para que la organizacin se pueda encaminar hacia este nivel de madurez del modelo, se sugiere que como mnimo implante los procesos enumerados a continuacin: Desarrollo de requisitos Solucin Tcnica Integracin del producto Verificacin

149

CALIDAD DE SOFTWARE

Validacin Desarrollo y mejora de los procesos de la organizacin Definicin de los procesos de la organizacin Planificacin de la formacin Gestin de riesgos Anlisis y resolucin de toma de decisiones

Aunque el proceso de mejora continua es un proceso que por su naturaleza sigue y sigue la gran mayora de las organizaciones que alcanzan este nivel de madurez simplemente se detienen en decir ya no aplican el modelo como tal. Lo anterior se debe a que a este nivel del modelo la organizacin prcticamente ha dejado de ser un caos y la mayora de los errores y mala planeacin y estimacin han sido eliminados, en otras palabras, la organizacin ha visto tantas mejoras tanto en la forma de trabajar como en los productos de software obtenidos bajos estos procesos, que no sienten la necesidad de seguir avanzando, ir ms all ya que tienen la inmensa mayora de sus necesidades plenamente cubiertas. Cuantitativamente Gestionado o Nivel 4 CMM-CMMi En esta parte del proceso de madurez para el modelo CMMi , la organizacin ya hace uso de tcnicas para fijar objetivos medibles, es decir, ya fija metas medibles a corto plazo que con su consecucin acercan ms a lograr el objetivo marcado como principal para esa parte del proceso de produccin del software.

Figura 49. Cuantitavamente gestionado

Estos objetos medibles fijados se usan principalmente para alcanzar las necesidades o requerimientos de los clientes de la organizacin. En este nivel de madurez se utilizan las mtricas generadas y empleadas con anterioridad, pero en esta ocasin son usadas para gestionar de manera integral la organizacin. Los procesos que la organizacin debe implantar para alcanzar este nivel de madurez son: Gestin cuantitativa de proyectos Mejora de los procesos de la organizacin

150

CALIDAD DE SOFTWARE

Figura 50. Procesos del nivel 4

Optimizado o Nivel 5 CMM CMMi

Figura 51. Logo del nivel 5

En esta etapa del modelo todos los procesos para los proyectos de la organizacin y de la organizacin se perfilan para cumplir una tarea mas como es la mejora sustantiva de las actividades dentro de la organizacin. Se trata de que estas mejoras sustanciales tambin son incrementales y fundamentales innovadoras, de manera que en ocasiones estas son empleadas de manera algo atrevida, pero que por lo general y maduro de la organizacin dan los mejores resultados, ya que los integrantes de la empresa han crecido junto a esta y saben que se puede mejorar e implementar para lograr cada vez ser ms eficientes y de gran calidad. Las mejoras mencionadas se identifican con las ya famosas mtricas establecidas, lo cual permite tanto su evaluacin como su puesta en prctica, convirtindolas as en estrategias perfectamente viables como modo de accin y trabajo. Los procesos que hay que implantar para alcanzar este nivel son: Innovacin organizacional Anlisis y resolucin de las causas

151

CALIDAD DE SOFTWARE

Normalmente las empresas logran los niveles 4 y 5 del modelo de madurez al mismo tiempo, dada la estrecha relacin que llevan estos dos niveles y por tanto es casi automtico y relativamente sencillo completar el nivel 5 con mnimos cambios del 4. Pero bien, no todo en la vida es miel sobre hojuelas, as que como existen quienes defienden el modelo CMMi a capa y espada la metodologa ultmate para llevar a cabo un producto de calidad, existen muchos detractores del modelo de madurez. El principal argumento de quienes critican al modelo, es que si, si haces todo lo que dice pues s, logras alcanzar tus objetivos, tus productos son buenospero el modelo CMMi solo te dice que hacerpero nunca te dice cmo hacerlo. Es decir, te dice que hagas esto y lo otro, pero lo dems tu lo tienes que resolver, es decir , el diseo de procesos, su seguimiento, implantacin, verificacin y dems, son responsabilidad entera de la organizacin, y por tanto lo toman como una respuesta a medias para su organizacin Dada esta crtica y desesperacin por parte de los principales productores de la industria del software recibieron con agrado un buena nueva: Watts Humphrey, uno de los padres y principales contribuyentes del modelo CMMi, diseo 2 metodologas de trabajo las cuales ayudara de manera puntual a las empresas para alcanzar de manera ms compacta y guiada, con proceso definidos y scripts de trabajo, a alcanzar de manera casi automtica el nivel 3 del modelo CMMi, estas son PSP y TSP. En trminos sencillos, PSP (Personal Software Process) est diseado para recolectar los datos estadsticos e histricos de los individuos que desarrollan el software, brindando mtricas confiables de estos personajes, para as, realizar una planeacin muy acercada a la realidad, de cuanto tomara, en esencia, el desarrollo de producto hasta su implantacin.

Para complementar, tambin se proporciona la metodologa TSP, la cual es bsicamente un equipo de desarrollo formado con integrantes con formacin en PSP que llevan un plan de desarrollo detallado, con tareas balanceadas entre cada uno de ellos, tomando roles diseados dentro de la metodologa para enfocarse en reas crticas del proyecto y as lograr un proceso de desarrolla exitoso e igual un producto de calidad. Cabe aclarar que en ciertas partes de la mayora de los procesos a emplear en cada una de las reas involucradas en el desarrollo, son flexibles hasta cierto punto. Esto ha hecho que muchas empresas cuenten con una versin personalizada del modelo y sus procesos, por lo tanto existe un sinfn de modelos diferentes y personalizados que han ayudado a muchsimas empresas a nivel mundial a alcanzar sus objetivos tanto organizacionales como en los productos de software producidos.

152

CALIDAD DE SOFTWARE

Nivel inicial A lo largo de toda la historia se han tratado de encontrar mejoras en el proceso de desarrollo de un producto de software y una de ellas es el nacimiento del modelo CMM. Si hablamos de CMM es necesario entender primero a lo que se refieren las palabras calidad de software; calidad de software es el desarrollo de software basado en estndares y modelos con la funcionalidad y rendimiento total que satisfacen los requerimientos del cliente. Un modelo de calidad para el desarrollo de software servir como punto de referencia para imitarlo; ha esto agregara el que se aplica a los procesos que se deben realizar (o proceso de desarrollo; como se menciona en algunas fuentes), a las personas y a la tecnologa para lograr el producto de software. El modelo de calidad CMM por sus siglas en ingls Capability Maturity Model nos va a facilitar catalogar a las organizaciones con el nivel de capacidad de madurez de su proceso de desarrollo. Es importante entender cmo es que funciona este modelo; CMM como ya se mencion es un modelo que indica el nivel de madurez de una organizacin; estos niveles, que son cinco; tienen caractersticas especiales o requisitos a cumplir; si la organizacin o la empresa cumple con esas caractersticas o requisitos, entonces ese nivel se puede marcar como superado; cuantos ms niveles la empresa tenga superados, mayor ser su nivel de madurez. Los cinco niveles de madurez del modelo CMM son los siguientes: nivel 1: nivel inicial, nivel 2: nivel repetido, nivel 3: nivel definido, nivel 4: nivel cuantitativamente administrado y por ltimo nivel 5: nivel optimizado. En este ensayo se hablar profundamente de los primeros dos niveles del modelo; nivel 1: nivel inicial y nivel 2: nivel repetido; adems de los beneficios de que la empresa supere el nivel 1: nivel inicial, pase a nivel 2: repetido y sienta el deseo de seguir subiendo los niveles. Se mencionarn ejemplos a modo de que la explicacin de estos dos niveles del modelo sea lo ms entendible y clara posible. El nivel 1 del modelo CMM nivel inicial puedo explicarlo como el ms cmodo de los niveles, con esta palabra (cmodo) me refiero al hecho de que en este nivel la empresa no sigue procesos; porque no existen pues no se han establecido; o porque las personas involucradas no los siguen pues estn en la posicin cmoda en la que creen que su proceso personal, descontrolado y para nada eficiente es mejor. El no seguir procesos sea cual sea la causa lleva a productos fuera de tiempo, fuera de presupuesto, y lo peor de todo que ni siquiera cumplen con los requerimientos que el cliente especific al inicio. Se puede decir que el nivel 1 es el nivel en el que estn todas las empresas, en este punto se entiende que es el nivel inicial (valga la redundancia), o sea en donde inician todas, pero incluso tal vez tendran que llamarlo nivel 0 o no ser manejado como nivel de madurez dentro del modelo; pues la empresa solo por el simple hecho de estar o de existir como tal (como empresa) ha llegado a este nivel; lo que quiero decir es que la empresa no debe esforzarse para conseguir estar en este punto o nivel de madurez. El nivel inicial se refiere pues a una empresa en la cual los procesos no se siguen o no existen.

153

CALIDAD DE SOFTWARE

Es en las empresas que se encuentran en este nivel 1 en donde se ve mucho el sndrome del ingeniero explotado; pues los desarrolladores tienen que quedarse a cubrir tiempo extra; e incluso durante noches y fines de semana cuando ven que la fecha de entrega se les viene encima. Por ejemplo; si en una empresa no se siguen los procesos para conocer el tamao del proyecto y no se siguen procesos para saber cunto del tamao final del proyecto se lleva actualmente o a la fecha; es lgico que no se sepa cundo se va a terminar ese proyecto, la fecha de entrega ser irreal y el ingeniero de software o desarrollador ser el que deba tratar de remediar esta falta en el seguimiento de procesos con trabajar ms tiempo; y es ah cuando se presenta otro fenmeno; el de los esfuerzos heroicos cuando el desarrollador debe salvar al proyecto del fracaso aun a costa de su tiempo, su familia e incluso su salud; esto la mayora de las veces es totalmente innecesario si se siguieran procesos. Considero importante, en los casos en los que los procesos en la empresa existen pero no son seguidos por los desarrolladores de la misma; lograr nivel de motivacin en ellos, pero cmo es que aplicara la motivacin en lograr el cumplimiento de los procesos organizacionales y adems en seguir obteniendo niveles de madurez ms altos? Pues muy sencillo; si existe motivacin; es decir, si los desarrolladores se sienten involucrados, con responsabilidad, capaces de tomar sus propias decisiones, importantes en el buen funcionamiento como empresa y sobre todo, si los desarrolladores creen que el proceso les va a beneficiar; entonces el lograr el siguiente nivel de madurez est ms cerca. Un principio muy importante de la calidad de software y del seguimiento de procesos y por lo tanto de la clasificacin de empresas en niveles de madurez es el que dice que los buenos productos no se obtienen por azar; sino como consecuencia de un esfuerzo positivo para hacer un trabajo de calidad; si el desarrollador no tiene una posicin positiva ante el seguimiento de procesos, no hay forma de que los siga correcta y totalmente; y una empresa que no sigue procesos no funciona en la mejor manera, tiende a cometer mayor nmero de errores y no slo eso; tiende a repetir estos errores. La motivacin lograr pues que se entienda la importancia de que se siga el proceso de desarrollo, haciendo hincapi en el hecho de que seguir procesos no slo ser un beneficio a nivel empresa; sino adems ser un gran beneficio a nivel individual, de cada trabajador. Y en los casos en los que los procesos organizacionales no existen, creo importante tomar en cuenta los beneficios que traera el que se estableciera y se siguieran estos procesos; el ms importante para m es el que se tendr control sobre el estado de los proyectos de software en desarrollo; de este modo las fechas de entregas se cumplirn en mayor porcentaje y no ser frecuentemente necesario que el desarrollador trabaje en das u horarios fuera de lo establecido. Estos beneficios anteriores yo los veo como los beneficios directos; pero adems puedo identificar beneficios indirectos que son de gran tamao como el hecho de que la empresa gana buena proyeccin ante el mercado, empieza a ser competitiva, gana renombre, empieza a sobresalir, es tomada en cuenta en mayor medida y esto trae como consecuencia conseguir mayor cantidad de clientes, los cuales se traducen en mayores ganancias econmicas; adems de mayor productividad y calidad en los productos. Nivel repetido. En cambio si no se llevan los procesos en el desarrollo existe un alto grado de riesgo y desgaste en la empresa; riesgos en el proyecto y desgaste de las personas.

154

CALIDAD DE SOFTWARE

Al hablar del nivel 2: nivel repetido del modelo CMM, es necesario entender que la empresa en este punto debe tener gestionado y controlado todo el proceso de desarrollo de los productos de software. Como el nivel 1 se obtiene por default al existir como empresa; el nivel 2 es el nivel al que todas las empresas que quieren mejorar su forma de trabajar o desean implantar CMM desean avanzar. Esto es porque una empresa de desarrollo de software estar y en nivel 1 aunque su intencin no sea la de escalar niveles de madurez CMM; pero en el nivel 2: nivel repetido es diferente; pues requiere que la empresa conozca e identifique mtodos o tcnicas para lograr los requisitos necesarios para el cumplimiento de los procesos de este nivel; es decir que la empresa que desea avanzar a este nivel debe dedicarse a ello. Y al mencionar el trmino dedicarse a ello me refiero a que no va a ser fcil de alcanzar; pues requiere que la empresa cambie la forma de trabajar, lo que involucra primero que las personas cambien su forma individual de hacerlo; esto puede implicar incluso cambios de ideas; pues a nadie nos gusta que nos digan que la forma en la que trabajamos no es la ideal y que existe una manera mejor de hacerlo que no es la que utilizamos. Con respecto a este punto se dice lo siguiente No intentes alcanzar el CMM-CMMI nivel 2 sin un firme apoyo de la direccin; esto quiere decir que es necesario que sean los directivos los que manejen la autoridad al momento de que los trabajadores empiezan a resentir el cambio; los directivos podrn dar un gran apoyo para enfrentarlo (al cambio). La idea principal que yo puedo apreciar en cuanto al nivel repetido de CMM es bsicamente que los procesos se siguen; pero adems, estos procesos son repetibles, lo que quiero decir es que las tareas aprendidas previamente se van a repetir para todos los proyectos y con estas se tienen buenos resultados. En este nivel no es frecuente ver el sndrome del ingeniero explotado o del ingeniero hroe o los esfuerzos heroicos; pues siempre se sabe en qu parte del proyecto se est o cunto es lo que se ha avanzado de ese proyecto; por lo tanto las fechas de entrega estn fundamentadas y son ms realistas para cumplirse. Lo que quiere decir que ya existe una planificacin en cuanto a costos, calendario y requerimientos. Lo que se pretende con el nivel repetido es lograr que los proyectos de la organizacin tengan un proceso de administracin de requerimientos y cuente con procesos planeados para el desarrollo del software, que se sigan estos procesos, se aprenda de ellos y se mantengan en control y poder hacerlo as repetidamente para cada proyecto y que funcione en cada uno. Si una organizacin o empresa desea lograr alcanzar el nivel 2: nivel repetido de CMM existen procesos que tienen que implantar, los cuales son: Gestin de requerimientos Planificacin de proyectos Seguimiento y control de proyectos Medicin y anlisis Aseguramiento de la calidad Gestin de la configuracin

155

CALIDAD DE SOFTWARE

Cada uno de estos procesos ayuda a la empresa a superar el nivel 2 del modelo; estos procesos estn en orden de ejecucin y se pueden ver como los pasos necesarios para cubrir el nivel mismo. Cada proceso cuenta con sus caractersticas especiales; las cuales se explicarn a continuacin En lo que se refiere a la gestin de requerimientos que es definido por Leffingwell y Widrig como Un enfoque sistemtico para levantar, organizar y documentar los requerimientos del sistema y un proceso que establece y mantiene el acuerdo entre el cliente y el equipo del proyecto sobre los requerimientos cambiantes del sistema; se puede notar que es la base de todo; son los fundamentos del proyecto, lo que el cliente quiere que realice el producto de software; es por lo que est pagando, la gestin de estos es adems lo que marca la pauta para los cambios que el cliente solicite a la empresa que desarrolla y tambin ayuda a identificar inconsistencias entre los mismos requerimientos. La importancia de este proceso radica en que a partir de ellos, de los requerimientos; se empieza a construir el producto final o software, si los requerimientos sufren cambios, entonces el equipo debe tomar las decisiones correctas sobre el plan a seguir para incluir o no estos cambios. Por ejemplo; en una empresa en donde no se sigue el proceso de administracin o gestin de requerimientos; cuando se levantan requerimientos se realiza en una sola entrevista de muy poco tiempo, no se documentan ordenadamente y el cliente llama por telfono cada que se le ocurre alguna otra nueva funcionalidad que quiere en el sistema o algn cambio en las que ya se tienen; en este caso se incurren en muchos errores, en primer lugar un buen levantamiento de requerimientos necesita agotar todas las posibles dudas que se tengan sobre lo que el cliente est pidiendo y sobre los procesos en los que se utilizar el sistema, no se trata de adivinar qu es lo que se est pidiendo; lo cual lleva ms de una entrevista que adems es corta; lo segundo es que cuando se piensa que los requerimientos que se tienen son los necesarios para construir un sistema, estos se deben documentar pues servirn tanto para los desarrolladores como para los mismos clientes para que no existan dudas ni discrepancias sobre estos; lo tercero es que en cuestin de cambios del sistema se tiene que ser muy cuidadoso porque el cliente como en el ejemplo puede seguir agregando o cambiando ms cosas al sistema, pero sin tomar en cuenta que a mayor funcionalidad pedida o modificada despus del levantamiento, mayor pago y adems se atrasa la fecha de entrega. Por eso en la gestin de requerimientos se debe evaluar si los cambios o agregados de requerimientos son factibles de realizar, esto mediante un anlisis detallado sobre el impacto que tendra el que se aceptara el cambio; si el impacto no es mucho, entonces tal vez se pueda ser flexible para su aceptacin; pero en cambio si el impacto es muy grande y es posible que desfase las fechas del proyecto, entonces tal vez se deber rechazar este cambio; si el cliente an as quiere que se lleve a cabo el cambio, entonces la fecha de entrega se atrasa y adems se agrega el costo al monto de lo pedido. Todo esto hay que tenerlo muy claro y siempre gestionar los requerimientos; una empresa que sigue este proceso es una empresa que llega al fondo de lo que el cliente est pidiendo y adems est en comunicacin con el mismo hablndole claro; por lo tanto es una empresa que muy frecuentemente tiene clientes satisfechos. Trabajar con el cliente es de las cosas ms difciles que se hacen; levantar requerimientos no es tan fcil como se escucha; es necesario que la persona que se encargue de eso tenga tacto con los dems, que sepa escuchar y comunicar, obtener la atencin del cliente y guiar la entrevista a los puntos importantes; adems de que tiene que saber actuar ante posibles presiones y malentendidos con o de parte de los clientes. Para m, este proceso es el ms importante pues si no sabemos lo que el cliente quiere; entonces tampoco sabemos qu es lo que se va a desarrollar, mequeda claro que un buen levantamiento de requerimientos se traduce en un cliente contento.

156

CALIDAD DE SOFTWARE

Despus de identificar y gestionar los requerimientos, se debe seguir con los procesos de planificacin del proyecto; es aqu en donde se debe establecer el plan de accin para el desarrollo de software; definiendo actividades a realizar, quin las va a realizar y en cunto tiempo. Para esto es muy importante que todos los involucrados en el desarrollo del producto de software se comprometan de sobremanera; en mi opinin la dificultad de esto radica en que como el trabajo se va a realizar en equipo; primero este debe lograr ser un equipo cohesivo, a veces las personas creen difcil confiar en otras o se les dificulta el que su xito o fracaso dependa tambin de otros; por eso es importante que exista una muy buena comunicacin entre todos sus miembros. Un tema muy delicado en este aspecto es el de los egos ente los miembros; con los desarrolladores de software se ve mucho el que siempre se quiera ser el hroe del equipo y el que no se quiera que otros toquen el cdigo fuente pues lo consideran personal y slo para ellos. Esto no debe pasar en un equipo cohesivo; los egos se deben dejar de lado porque al final de cuentas el xito o fracaso del proyecto recaer en el equipo completo y no solo en uno o dos integrantes. Un ejemplo de equipo cohesivo es en el que cada quien realiza su trabajo y lo acaba en el tiempo acordado; pero adems se apoyan unos a otros cuando alguno no ha terminado o tiene problemas para hacerlo, se comunican, se escuchan, dejan los egos en otro lado y salen a flote entre todos logrando xito con el proyecto. Cuando se ha formado un equipo se debe realizar el balanceo de trabajo para cada uno de los integrantes, se estiman tareas que se deben realizar y se reparten, las fechas lmites para que cada quien entregue la parte o partes que le corresponden, los recursos que son necesarios para que se lleve a cabo el proyecto, los riesgos posibles y sobre todo se establece el compromiso del equipo. Considero que es de suma importancia seguir este proceso porque es en este plan en donde se realizarn las modificaciones posteriores cuando los requisitos cambian y si este es el caso; el plan de proyecto se debe tener como puntos a seguir durante el desarrollo del software. Despus de que se ha establecido el plan de proyecto; lo siguiente a realizar es la monitorizacin y control de proyectos; lo cual es la parte en donde se est checando el avance que tiene el proyecto a la fecha y; cmo se consigue esto?, pues comparado lo actual en relacin a tareas que se han terminado y avance en cuanto a tiempo, esto contra lo que se encuentra en el plan de proyecto referente a los mismos criterios; tareas terminadas planeadas para la fecha actual y avance en cuanto al tiempo planeado para la fecha actual. En resumen de esta parte lo que se hace es comparar los datos reales actuales contra los datos planeados que se encuentran en el plan de proyectos. Esto para qu sirve?, pues para ver el estado actual del proyecto y en base a eso poder tomar decisiones que corrijan los muy posibles fallos de estimacin; antes de que se desve mucho de lo planeado. Las decisiones que se tomen tienen que actualizarse o rehacerse en el plan de proyecto. Esto es como darse cuenta de en qu lugar se est al momento, cunto nos falta y cunto tenamos planeado que nos faltara y con esa informacin decidir si se modifica el camino para llegar al lugar que se quiere; que en este caso es el producto terminado.

157

CALIDAD DE SOFTWARE

Lo siguiente a realizar son los procesos de medicin y anlisis; esto se refiere a los datos que deben ser acopiados y seleccionando indicadores que permitan medir la evolucin de los procesos crticos del proyecto. Es necesario que la empresa valore el trabajo de su gente porque es en ellos en quienes recae todo el desarrollo de un producto de software. Si por ejemplo; tenemos los datos de los involucrados o miembros de equipo se pueden analizar oportunidades de mejora para los integrantes de ese equipo y se toman decisiones para abarcar con mayor rendimiento todos los procesos de desarrollo de software. Adems, algo muy importante es el que los datos que se acopien aqu servirn de base para aadir mtricas en los procesos futuros. Estos datos son pues datos histricos que se pueden utilizar para los procesos; esto porque se toman como fundamento a la hora de establecer fechas por ejemplo; es como dejar de ir a ciegas en los procesos; porque ya se pas alguna vez por ah y podemos tratar de pronosticar con los datos cmo ser el siguiente recorrido. Si en un sistema anterior se realizaron 100 lneas de cdigo en 8 horas; entonces si para el siguiente sistema se estiman 200 lneas de cdigo; si nos vamos a los datos histricos que seran las 100 lneas en 8 horas; se puede estimar que las 200 lneas tomarn 16 horas; este es un ejemplo con datos pequeos pero as es como funciona si 100 lneas de cdigo se realizaron en 8 horas; quiere decir que por hora esta persona realiz 12.5 lneas de cdigo, entonces si se quiere saber el tiempo estimado para la estimacin de 200 lneas slo se debe convertir las 200 lneas entre las 12.5 por hora y el resultado es 16. Este dato sirve para la planeacin de calendarios. As tambin se pueden hacer otras estimaciones utilizando datos histricos. Adems con estos datos se puede observar en dnde tiene que mejorar cada quien para superar sus datos que en este momento toman el nombre de mtricas. El siguiente proceso Aseguramiento de la Calidad no es ms que un conjunto de actividades que ya han sido planificadas incluso antes de desarrollar el software y que se han seguido de manera constante; esto para lograr asegurar que el software va a cumplir con ciertos criterios esperados de calidad. Esto se va a conseguir de la siguiente manera: primero se debe evaluar cmo fue que se llev a cabo la ejecucin de los procesos, los elementos de trabajo y servicios y que estos hayan seguido las descripciones de proceso y de procedimientos; o sino es el caso documentar cul fue el proceso que no se sigui y el por qu no se sigui y evaluar su validez; en caso de que la validez de la no ejecucin o del cambio en la ejecucin del proceso esta informacin se tiene que documentar y dar a conocer a los desarrolladores que son los que siguen los procesos. Sin este proceso no sera posible implantar un modelo de calidad como lo es CMM y es por eso que no debe de pasarse por alto este proceso. El ltimo proceso para alcanzar el nivel 2: nivel repetido del modelo CMM es el de Gestin de la configuracin, cuyo objetivo es establecer y mantener la integridad del producto de software, controlando y auditando este producto. Esto es en gran medida porque en una empresa de desarrollo de software es muy comn el hecho de que varios o todos los miembros del equipo puedan intervenir en el desarrollo de algn elemento; lo cual, si se lleva de la forma incorrecta puede reflejarse en inconsistencias, errores e incluso pleitos entre los diferentes miembros. Tal vez hasta ahorita no queda muy claro de qu se trata este proceso; pero es ms simple de lo que se escucha, lo nico que se quiere decir es que se debe de utilizar un sistema de control y gestin de versiones.

158

CALIDAD DE SOFTWARE

Un sistema de control y gestin de versiones evita que exista el cdigo inconsistente; adems de lo principal que es el hecho de que permite seguir la evolucin, cambios y mejoras de un producto; esta herramienta permite saber qu desarrollador modific qu parte; pero si esta modificacin se realiza de manera correcta o no era necesaria siempre podemos rescatar lo anterior pues se guarda como una versin anterior que se puede recuperar posteriormente. El objetivo de todo esto es mantener la integridad de la lnea base la cual es definida por los autores como una especificacin o producto revisado y aprobado formalmente, que sirve como base para el desarrollo posterior, y puede ser modificado solo a travs de procedimientos formales de control de cambios. En pocas palabras son los nmeros que se manejan para conocer de manera ordenada las modificaciones que se le han realizado a un producto de software; los nmeros como V 0.1, V 0.2. . . V 3.5 y as sucesivamente. Este proceso es el ms largo y solo va a terminar cuando el producto de software es retirado de circulacin o del mercado. Creo importante agregar que este proceso requiere una organizacin impecable para que se ejecute como debe de ser; ya que es muy fcil perderse en los nmeros o que se dejen pasar modificaciones o actualizaciones del software sin documentarlas y por supuesto sin manejar nmeros de versiones. Si la empresa u organizacin cumple o realiza todos estos procesos entonces se puede ver que dej el nivel inicial atrs y avanz al nivel 2: nivel repetido como nivel de madurez. Me parece importante decir que CMM te dice qu se tiene que hacer para llegar a cada uno de los niveles de madurez; sin embargo no te dice exactamente cmo hacerlo; la empresa debe de valerse de tcnicas, mtodos y procesos para cumplir con cada uno de los requisitos del nivel de madurez; y eso es en todos y cada uno de los niveles. Adems la empresa debe estar comprometida con la idea de avanzar niveles de madurez porque ir escalonando niveles requiere de mucho tiempo y de muchos recursos financieros; adems de que es muy difcil y cansado hacer, sobre todo si se est solo en nivel inicial; que los trabajadores cambien de forma de pensar en cuanto a la forma en la que trabajan; ms porque en algunos casos sta forma ha estado con ellos por aos y aos. Con este documento he abarcado los dos primeros niveles de madurez del modelo CMM; que son el nivel 1: nivel inicial y el nivel 2: nivel repetido. En el presente ensayo se vio algo de introduccin de lo que es calidad de software y la definicin del modelo CMM.

159

CALIDAD DE SOFTWARE

Se ha visto de forma introductoria pero profunda qu es CMM Nivel 1 y CMM Nivel 2; qu procesos son necesarios en cada uno de ellos y la descripcin de estos procesos; adems de la importancia de que se sigan y los beneficios que trae el que se sigan. Esta frase me pareci interesante de analizar Trabajar bien es siempre la forma ms rpida y econmica de trabajar, a lo cual yo agregara que es la forma ms segura de generar una empresa estable, madura y rentable; pero para trabajar bien se debe hacer en conjunto, la empresa con los desarrolladores; estos deben sentirse importantes para la empresa y deben estar motivados en conseguir que esta crezca y se siga superando. Para que una empresa sea madura necesita contar con individuos maduros; los individuos se consideran como maduros en este caso cuando entienden la importancia de seguir el proceso y de tomar datos del mismo, cuando el proceso complementa la personalidad del individuo y este cree que el proceso en realidad lo va a ayudar a desempearse mejor en sus actividades y sobre todo en tiempos de crisis durante el desarrollo del proyecto; si slo simulan que entienden y que siguen el proceso en esos tiempos de crisis lo primero que estos individuos simuladores harn es botar el proceso. Esto no funciona as, an en pocas difciles y de crisis no se debe dejar de seguir los procesos. La empresa tiene la obligacin pues de hacerles saber a los desarrolladores lo importante que es que dejen sus vicios de trabajo y comiencen a seguir procesos. Este tipo de situaciones se evitan haciendo que los individuos tomen cierto tipo de cursos que como objetivo principal es que se empapen de la idea de seguir procesos, y como objetivo segundario, que dejen sus vicios. Lograr superar niveles de calidad es un beneficio para todos y cada unos de los involucrados en el proceso de desarrollo. A pesar de que como ya lo mencion el escalar niveles de madurez de este modelo lleva mucho tiempo, esfuerzo y dinero; aun as el beneficio obtenido para la empresa es mucho mayor que lo invertido. Es importante recordar que existen otros tres niveles de madurez que no se analizaron; pero que siguen del nivel 2; entre ms niveles cumpla la empresa; mayor ser su nivel de madurez; mejor ser su proyeccin al mercado y ante la competencia y adems los desarrolladores de esta empresa tendrn un mejor entorno laboral y estarn ms felices haciendo su trabajo; eliminado casi por completo la posibilidad de quedarse diario tiempo extra para poder cumplir con los compromisos de tiempo, costo y calidad. Nivel Definido. El nivel definido de CMM indica que las empresas cuentan con una serie de procesos que estn definidos y respaldados, con los cuales se apoya para alcanzar sus objetivos. Muchas veces estos procesos son propios de la empresa, los cuales reflejan sus polticas y a su vez, su nivel de madurez. En este nivel es normal que los individuos que van a ingresar a la organizacin reciban una capacitacin previa para poder ser parte de esta, el objetivo de estas capacitaciones es el de que estos individuos asimilen esta serie de procesos de una forma ms eficiente, con lo cual se asegura adems que estos individuos mantengan el nivel actual que se tiene y contribuyan a alcanzar los siguientes niveles. Adems, con estas capacitaciones se puede observar que

160

CALIDAD DE SOFTWARE

individuos no cumplen con el perfil de la organizacin, o quienes tienen cierto tipo de perfil que pueda ser explotado a beneficio de la misma. A estos procesos de les conoce como gestin de ingeniera definida, y son el resultado de trabajar en base a estndares y mtricas con las cuales se sigue una lnea de trabajo que satisface las necesidades de tiempo, costo y forma con el fin de que los proyectos sigan un proceso de desarrollo estable para obtener objetivos concretos. Las mtricas utilizadas por las organizaciones con un nivel CMM 3 sirven mucho para la obtencin de objetivos especficos, adems de ser un parmetro de referencia preciso, rpido y exacto del estado de un componente del proyecto o del proyecto en s mismo, ya que son ms completos que los utilizados en el nivel 2. Otro elemento importante que identifica a las organizaciones de este nivel, es el uso de herramientas, en muchos casos personalizadas, que complementan los procesos o estndares organizacionales. Muchas veces estas herramientas tambin son desarrolladas por la misma organizacin. Esto es un punto importante y constante en las organizaciones de este nivel de madurez; y a su vez es lgico, ya que la organizacin es la que mejor panorama tiene de cules son sus deficiencias y virtudes, por lo cual el desarrollar las herramientas que cubren sus deficiencias y maximiza sus virtudes ayuda a la organizacin a enfocar a los individuos a que alcancen sus objetivos de una forma ms directa; y por consecuencia, si los individuos logran sus objetivos, es ms factible que la organizacin tambin alcance los suyos. Otro factor a considerar es el hecho de que, tanto los estndares, procesos, herramientas y todos los factores que involucran a una organizacin con un nivel de madurez CMM 3 estn en una bsqueda de mejora, con el fin de formar procesos lo suficientemente elaborados a la medida de la organizacin, para que esta consiga la consistencia mxima en la elaboracin de sus proyectos. En este sentido, los procesos del nivel 3 contemplan tambin una serie de elementos a considerar; como procesos definidos, plantean propsitos (el por qu de ese proceso), entradas (elementos que el proceso necesita para que siga con un flujo del proceso), criterios de entrada (e se necesita que el proceso para avanzar en el proceso), actividades (funciones de los individuos realizan durante el proceso), roles (que tipo de usuario es el que se encuentra durante una parte del proceso), mtricas (como se medir si el proceso est cumpliendo con sus objetivos o no), verificaciones (comparar resultados obtenidos en el proceso con los esperados), salidas (lo que se obtuvo del proceso) y criterios de salida (si se cumple o no con todos los parmetros esperados para que el proceso llegue a su fin o para iniciar un proceso consecuente). Cabe mencionar que este nivel es el ms comn entre las organizaciones, esto porque es un nivel mejor estructurado que el nivel 2, pero menor complejo en cuanto a requerimientos de crecimiento que el nivel 4, adems de que este nivel brinda muchos beneficios al cubrir la mayora de las necesidades de la organizacin, por lo que mantiene un nivel de estabilidad y confort alto para la organizacin. Para poder alcanzar el tercer nivel de madurez del CMM, es necesario cubrir con una serie de procesos que permitan avalar la calidad de los procesos utilizados en el desarrollo de los proyectos, estos son los siguientes:

161

CALIDAD DE SOFTWARE

Desarrollo de requisitos Solucin Tcnica Integracin del producto Verificacin Validacin Desarrollo y mejora de los procesos de la organizacin Definicin de los procesos de la organizacin Planificacin de la formacin Gestin de riesgos Anlisis y resolucin de toma de decisiones

Por desarrollo de requisitos se debe entender el conjunto de necesidades que necesitan ser cubiertas por un producto, en este caso, las necesidades deben ser cubiertas por un desarrollo de software. Este punto toma importancia y marca el desempeo y el grado de xito de los siguientes, ya que si no se entiende lo que se quiere hacer, no importa que tan bien se hagan las siguientes fases, el producto final no vaya a ser el esperado por el usuario final que necesitaba cubrir una necesidad. La mayor parte de las veces, la falla de este proceso es la causa de que no se alcancen los niveles superiores de modelo CMM. Est claro que los requisitos son la parte medular de un desarrollo de software, de ah radica el por qu son incluidos en este nivel y tambin da una idea de el por qu el nivel 3 es el ms comn en las organizaciones, al cubrir varios aspectos con un solo proceso, hace que este nivel sea demasiado robusto y competitivo. Hay muchas tcnicas para mejorar la toma de requerimientos, sin embargo existe una metodologa, la cual es la Ingeniera de requerimientos, que cubre perfectamente con este proceso, consiste en identificar las partes de la organizacin que mejor informacin tienen sobre la problemtica que se quiere resolver, de modo que toda esa informacin puede convertirse de un nivel abstracto a un nivel donde los desarrolladores entienden lo que se tiene que resolver, logrando as evitar muchos conflictos en el resto del proceso. El siguiente proceso es el de solucin tcnica, el cual, en base al desarrollo de los requerimientos, se plantea una solucin, la cual se evala que sea la ms apropiada, contemplando adems factores que no se toman en el desarrollo de requisitos, como limitantes externas, limitantes de hardware, funcionalidad con otros sistemas, plataforma en la que habr de desempearse, de ah la importancia del proceso anterior. Puede decirse que este proceso es de los ms laboriosos debido a la carga de planeacin que contiene. El siguiente proceso habla de la integracin del producto, en el cual se tratan no solo temas de integracin o funcionalidad entre los mdulos de un mismo producto, si no que se planteen proyectos que ofrezcan soluciones conformadas por varios productos de software, lo que hace que el proceso de pruebas de integracin tome un enfoque ms amplio y completo. Este enfoque se da por la razn de que es ms fcil trabajar con partes pequeas que con un componente grande, manteniendo el requerimiento de los productos establecidos.

162

CALIDAD DE SOFTWARE

Terminado la integracin del producto, sigue el proceso de verificacin, en esta parte del proceso se demuestra que el producto, as como sus componentes y/o artefactos cumplen con los requerimientos establecidos, con lo cual se sigue demostrando la importancia del desarrollo de requisitos. Despus viene la validacin, donde el producto y todos sus componentes tienen que demostrar que hacen para lo que fueron hechos. Muchas ocasiones se entregan productos muy ambiciosos y robustos para cubrir una necesidad que el cliente nunca tuvo o viceversa, es importante asimilar los requerimientos para evitar este tipo de situaciones que son las que ms tiempo de re trabajo generan (se debe de entender por re trabajo a un tipo de trabajo que ya se haba realizado, pero que por diferentes motivos se tiene que hacer de nuevo), ya que muchas veces estas situaciones, si no se detectaron en la fase de requisitos, se terminaran demostrando en las fases finales del desarrollo. Estos dos procesos anteriores estn relacionados en el sentido de que se revisan de una forma similar, pasando por varios elementos de inspeccin que suelen los mismos pero con diferentes parmetros de observacin. El siguiente proceso es el de desarrollo y mejora de los procesos de la organizacin, este proceso establece y mantiene un conjunto de estndares, ya sea en procesos organizacionales como en ambientes de trabajo, con el fin de buscar una mejora al proceso. Otro proceso del nivel 3 del CMM es el de definicin de los procesos de la organizacin el cual consiste en mantener un entendimiento de los procesos por parte de todos los miembros de la organizacin, adems de identificar las posibles mejoras a los procesos. Muchas ocasiones esta parte del proceso se apoya de tcnicas de mejora conocidas como PIP`S (ProcessImprovementProporsal por sus siglas en ingles) que quiere decir Propuesta de Mejora al Proceso, donde los desarrolladores proponen una mejora al proceso para hacerlo ms eficiente. Estas propuestas son evaluadas y si son aceptadas, se implementan. El siguiente proceso es el de planificacin de la formacin, el cual desarrolla y mantiene planes del proyecto, compromisos adquiridos por parte de los participantes del proyecto y gestiona las partes interesadas del proyecto. Este proceso nos apoya en la administracin del proyecto, en elementos como la asignacin de personas o creacin de un equipo, los tiempos y fases que el proyecto ha de incluir, uno de los procesos que hacen que se distinga el nivel 2 de CMM con el nivel 3, es el de gestin de riesgos, el cual es otro proceso de peso en el nivel 3. El proceso de gestin de riesgos ayuda a identificar los posibles riesgos del proyecto, ya sean por parte del cliente o por parte del grupo de desarrollo, con el fin de analizar su probabilidad, el nivel de peligro que representa para el proyecto, el impacto que este tendra para con el proyecto, as como un plan de contingencia en el sentido de que un riesgo se vuelva problema. Es importante aclarar que este punto toma mucha relevancia en el sentido de que se tienen que considerar muchos factores que pueden ser riesgos de que el proyecto peligre, por lo cual es necesario llevar una revisin peridica (lo recomendable es cada semana) para monitorear los riesgos, una tcnica que sirve en gran medida a evitar este tipo de situaciones es asignando a un responsable del riesgo para que este nunca llegue a suceder. Si por alguna razn, el riesgo aparece, entonces es tiempo de aplicar el plan de contingencia para anularlo.

163

CALIDAD DE SOFTWARE

El ltimo proceso del nivel 3 del CMM es anlisis y resolucin de toma de decisiones, el cual proporciona una estructura que ayuda a cierto nivel de jerarqua a una toma de decisiones mejor fundamentada, la cual asegura que las alternativas se comparan con criterios establecidos y objetivos para apoyarse a tomar la decisin que, a conciencia de quien la toma, se cree que es la mejor para la organizacin. Estos procesos en su mayora producen informes que van dirigidos al nivel ejecutivo de la organizacin con los cuales les es ms fcil tomar una decisin sintindose apoyados en datos histricos con los cuales poder entender el comportamiento de una situacin en especifico. Un punto importante a considerar es que las organizaciones que han alcanzado el nivel 3 de CMM han aprendido que los procesos por si mismos no hacen que una organizacin obtenga el nivel de madurez; los procesos son solo una base que sirve de apoyo para obtener mejores resultados y productos de calidad, sin embargo tienen que seguirse tal y como dicen, esto debido a que solamente con consistencia de accin es como se logran los verdaderos resultados y beneficios, adems de que otro punto importante es en creer que los procesos pueden ayudar a desempearse mejor; ya que de nada sirve que uno realice los procesos si no cree de verdad que puedan ayudarle, esto es ms que claro porque a nadie le gusta que le digan la forma de trabajar, de ah nace la dificultad que es muy comn en organizaciones debajo del nivel 3; los procesos no son para todas las personas, seguir los procesos puede parecer complicado en un principio, ya que exigen cambiar muchas veces la forma de trabajo de las personas, y al ser no tan flexibles como un lugar sin procesos a seguir, hace que la transicin de no tener procesos a tenerlos no sea tan rpida como se puede llegar a pensar. Una vez realizada la transicin de nivel 2 a 3, y por la cantidad de procesos nuevos que se siguen, se obtiene una consistencia en los productos y en la forma de trabajo que muchas organizaciones prefieren ya no tocar para mantener ese tipo de productividad, aun cuando hay otros dos niveles en el CMM que ofrecen ms oportunidades de mejorar la organizacin y obtener el nivel de madurez mximo. Una vez que los proyectos son realizados bajo este esquema de procesos, y que los resultados de estos procesos sean medibles y superen un nivel de auditora, puede decirse que la organizacin se encuentra en el nivel 3 de CMM. Nivel Administrado o Gestionado. El siguiente nivel del CMM es el Gestionado, este nivel de madurez indica el nivel de calidad que tienen los productos que la organizacin desarrolla, adems de la calidad del proceso de una forma cuantitativa en base a mtricas establecidas. En este nivel, la capacidad de los procesos empleados es previsible, y el sistema de medicin que la organizacin utiliza le permite detectar si las variaciones de capacidad se encuentran por encima de los rangos aceptables con el fin de tomar decisiones correctivas de una forma ms rpida e inteligente. Adems, los proyectos en este nivel de CMM usan objetivos medibles para alcanzar las necesidades de los clientes en conjunto con los de la organizacin. Esto se logra apoyndose en mtricas para gestionar la organizacin. Para poder alcanzar este nivel, la organizacin debe implantar dos procesos, los cuales se mencionan a continuacin, estos son:

164

CALIDAD DE SOFTWARE

Gestin cuantitativa de proyectos Mejora de los procesos de la organizacin

La organizacin y sus proyectos establecen dichos objetivos y mtricas cuantitativas para medir la calidad y el modo de llevar los procesos de acuerdo a estndares y metodologas, las cuales pueden ser propias o no, y los usa como criterios en el manejo de ellos. Los objetivos cuantitativos son definidos en base a las necesidades de clientes, usuarios finales, organizacin, y actores de los procesos. La calidad y realizacin de procesos son entendidos en trminos estadsticos y son manejados durante todo el ciclo de vida del proceso . Para subprocesos seleccionados, se recolectan y analizan estadsticamente medidas sobre la realizacin de procesos. Estas mtricas son incorporadas en el repositorio de mtricas de la organizacin para apoyar la toma de decisiones. Si se detectan causas especiales de variacin de los procesos, estas deben de ser identificadas y, cuando sea necesario, las fuentes de estas causas deben de ser corregidas para prevenir futuras ocurrencias, lo cual ayuda a mejorar el proceso. Una diferencia importante entre los niveles 3 y 4 es la capacidad de prediccin de la realizacin del proceso; en el nivel de madurez 4, la realizacin de procesos es controlada usando tcnicas estadsticas y cuantitativas (le dan un mayor valor a los datos histricos), lo que ocasiona que el proceso se vuelva un tanto predecible, lo que ayuda a que se vigile mejor, en cambio en el nivel de madurez 3 la realizacin del proceso es slo predecible en el aspecto cualitativo. En el nivel 4, se asumen procesos que pueden ser un factor clave del negocio, los cuales la organizacin quiere administrar usando tcnicas cuantitativas y estadsticas. Estos anlisis se hacen con el fin de darle a la organizacin una visibilidad del rendimiento de determinados subprocesos, lo cual los har ms competitivos en el mercado, ya sea actualizndolos en caso de que estn bien diseados, detectando el momento en que no son efectivos, si necesitan ser rediseados o si simplemente no son los adecuados para cumplir con un objetivo especifico. Las mtricas utilizadas en este nivel no son subjetivas, estas mtricas deben de establecerse con criterios cuantitativos que estn formalmente definidos (pueden estar definidos en base a comportamientos organizacionales, datos estadsticos, etc.). Los beneficios de estos controles se encuentran con el tiempo, ya que estos controles nos brindaran informacin ms veraz y confiable sobre la calidad y estado del proyecto, permitiendo tomarlo como referencia o compararlo con otros proyectos similares y notar cualquier desviacin tempranera para corregir el rumbo de accin y componer su estado en caso de ser necesario. Una vez que los proyectos son realizados bajo este esquema de calidad, y que los resultados de estos procesos sean los necesarios aprobatorios de la auditoria de procesos, se puede dar el nivel 4 de CMM. Algo que se debe de considerar es hasta qu nivel de madurez quiere llegar la organizacin, como mencionaba anteriormente, el nivel 3 de CMM provee la serie de procesos con los cuales la organizacin se vuelve altamente competitiva, por lo cual muchas organizaciones ya no buscan llegar a los siguientes niveles, aun cuando el nivel 4 puede brindar otro nivel de calidad, y el nivel 5 brinda una constante mejora de la efectividad de los procesos organizacionales. La

165

CALIDAD DE SOFTWARE

decisin debe de ser tomada por la alta direccin de hacia dnde se quiere llegar en el alcance de los proyectos y el modo en el que estos se deben de desarrollar. Llegar a este nivel de desarrollo productivo tiene muchas ventajas, aun cuando no se llegue a los ms altos niveles, el modelo CMM proporciona todos los elementos para llevar una administracin, gestin y procuracin de los proyectos ms eficiente, adems de obtener los beneficios del seguir los procesos, los cuales al final se traducen en conocer el estatus real del proyecto, realizar una estimacin en caso de ser necesario, verificar que elementos del proyecto necesitan alguna modificacin, verificar si un componente tiene calidad o no, se reduce la posibilidad de desfase de tiempos de entrega de los proyectos, una mayor tolerancia a los cambios o adaptaciones de nuevas tecnologas, mejora la rapidez y efectividad de respuesta ante exigencias del negocio, mejora la colaboracin y comunicacin de los integrantes del grupo de desarrollo y de la organizacin en s, reduce los costos del proyecto, es un modelo especifico para el desarrollo y mantenimiento de software, tiene un modelo de evaluacin para ver si puede adoptarse por una organizacin, es un modelo que presenta una gran flexibilidad para que puedan integrarse nuevos procesos, ayuda a implementar tcnicas proactivas de gestin mitigando los riesgos que afectan los proyectos y un aspecto que no se haba tocado antes; la cantidad de errores. El modelo est planeado para detectar la mayor cantidad de errores antes de las pruebas de integracin, y a lo largo de los procesos que se llevan en CMM, se hace uso de herramientas propias de las organizaciones; la sabia eleccin de estas herramientas, o en su defecto un desarrollo bien planeado de las mismas abarcando los puntos frgiles de la organizacin, contribuyen a un mayor ndice de deteccin y correccin de errores, haciendo que estos sean demasiado mnimos o nulos en las versiones liberadas. Esto es a grandes rasgos lo que CMM ofrece, menciono que es a grandes rasgos debido a que se tiene que experimentar el estar en una organizacin con este modelo implementado para poder comparar lo que es implementando el modelo y lo que es sin siquiera conocerlo. Los niveles del CMM 3 y 4 proporcionan un nivel de organizacin alto para poder aplicar los procesos que el modelo incluye, el grado de xito que el modelo puede o no tener depende directamente del grado de compromiso que los individuos de la organizacin estn dispuestos a dedicarle al proceso, pero sobre todo, que ellos crean que el proceso funciona para desempear sus labores. Tambin es claro que estos niveles se abordan o intentan abordar cuando la empresa tiene bien definido un plan de desarrollo y crecimiento institucional, por lo cual el compromiso puede entenderse que est implcito en la organizacin. Seguir la metodologa del CMM no es algo que pueda lograrse inmediatamente, para conseguir el segundo nivel, que es el primer paso que se debe de tomar cuando se ha decidido crecer institucionalmente, debe de realizarse un cambio cultural y laboral que lleva tiempo, al cual tiene que apegarse si quieren conseguir todos los beneficios que el modelo brinda. A un nivel muy personal, creo que las bases criticas para subir de nivel en la metodologa CMM es el recurso humano, ya que como principal materia prima de esa industria, se tienen que tener no solo las actitudes, sino tambin las aptitudes para poder seguir los procesos, ya que no es una tarea fcil, sobre todo para individuos que no tienen paciencia o que son demasiado

166

CALIDAD DE SOFTWARE

activos; se debe de encontrar a los que cumplen con un balance que pueda ayudar a seguir hacia otro nivel; si es lo que se desea; as como tambin a los que cumplen con el perfil de seguir solo hasta cierto nivel de desarrollo, porque es claro que no todas las organizaciones tienen como objetivo llegar a la cima del modelo CMM. Una empresa que decide implementar el modelo CMM, indica que no slo se preocupa por la calidad de su organizacin sino que quiere constituir un proceso continuo de mejora. Nivel Optimizado En este nivel la madurez de la organizacin es la ms alta, aunque no significa que ah pare su mejora, al contrario la organizacin, debe seguir en continua mejora para lograr eficiencia en sus procesos, siguiendo obviamente la reglas de niveles anteriores. Los procesos de los proyectos y de la organizacin estn orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante mtricas son identificadas, evaluadas y puestas en prctica. Los procesos que hay que implantar para alcanzar este nivel son: Innovacin organizacional Anlisis y resolucin de las causas

Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultneamente ya que estn muy relacionados. Una empresa que se base en el modelo CMM, debe estar enfocada en ofrecer soluciones basadas en software de calidad que le den un valor agregado a clientes. Estar evaluado en el nivel 5 del CMM es lograr crear software de alta calidad, en el precio adecuado y en el tiempo en que lo requiere el cliente, demanda de procesos productivos y administrativos sumamente precisos y eficientes, adems de contar con un plan de desarrollo acelerado, enfocados a la calidad. Las empresas que son evaluadas en el nivel 5 Optimizado de CMM trabajan bajo procesos de desarrollo como PSP (Personal Software Process) y TSP (Team Software Process) que adquirieron al ser evaluados con el nivel 3, estos procesos de desarrollo siguen paso a paso. La implantacin de un modelo de estas caractersticas es un proceso largo y costoso que puede costar varios aos de esfuerzo. Aun as el beneficio obtenido para la empresa es mucho mayor que lo invertido. Podr ser un proceso largo, porque PSP maneja ciertos procesos como llevar el tiempo exacto de cada una de las actividades que se van realizando, se debe de tener cuidado para que las estadsticas sean correctas. Se analizan los defectos de los proyectos para determinar las causas, y el seguimiento sobre los procesos. Es el nivel ms alto de CMM por el momento, es el optimizado. En el cual adems, la organizacin hace uso intensivo de las mtricas y se gestiona el proceso de innovacin.

167

CALIDAD DE SOFTWARE

Adems de ser un proceso que se revisa y modifica o cambia para adaptarlo a los objetivos del negocio. En dos palabras: Mejora continua. La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en funcin de la normalizacin (ISO 9000, CMMI). Sabemos que para obtener la calidad de software, se debe acatar a seguimientos de procesos, pero CMM adems ofrece PSP Y TSP que no solamente que se sigan procesos si no tambin explica como es el seguimiento de ellos. Para medir la calidad de software, tenemos algunas mtricas: Nmero de errores durante un periodo determinado. Fallo en la codificacin o diseo de un sistema que causa que el programa no funcione correctamente o falle. Tamao de un producto informtico (lneas de cdigo) Mtrica de punto funcin (IBM): relaciona funcionalidades que ofreca. Estimacin de costes y esfuerzos.

Cabe mencionar, que todas estas medidas se usan y registran en un seguimiento de procesos de PSP Y TSP. El concepto de medida va de ms a menos, va de lo general a lo concreto y lo concreto es asociado a la mtrica, cuya combinacin dara el nivel de calidad o seguridad del producto. Las ciencias bien estructuradas se basan en medidas bien hechas, se basan en la matemtica. Pues bien, se han visto muchos de los apoyos para complementar el concepto de la calidad de software, ahora se vern los factores que determinan si el software en realidad es de calidad, se clasifican en tres grupos: 1. Operaciones del producto: caractersticas operativas a. Correccin. El grado en que una aplicacin consigue los objetivos encomendados por el cliente b. Fiabilidad. El grado que se puede esperar de una aplicacin c. Eficiencia. La cantidad de recursos hardware y software que necesita una aplicacin para realizar las operaciones. d. Integridad. El grado con que puede controlarse el acceso al software o a los datos a personal no autorizado e. Facilidad de uso. El esfuerzo requerido para aprender el manejo de una aplicacin. 2. Revisin del producto: capacidad para soportar cambios a. Facilidad de mantenimiento. El esfuerzo requerido para localizar y reparar errores b. Flexibilidad. El esfuerzo requerido para modificar una aplicacin en funcionamiento c. Facilidad de prueba. El esfuerzo requerido para probar una aplicacin de forma que cumpla con lo especificado en los requisitos

168

CALIDAD DE SOFTWARE

3. Transicin del producto: adaptabilidad a nuevos entornos a. Portabilidad. El esfuerzo requerido para transferir la aplicacin a otro hardware o sistema operativo b. Reusabilidad. Grado en que partes de una aplicacin pueden utilizarse en otras aplicaciones c. Interoperabilidad. El esfuerzo necesario para comunicar la aplicacin con otras aplicaciones. Quiz sea difcil establecer las mtricas para determinar los factores de calidad. Muchas organizaciones alcanzan el Nivel de Madurez 5 del modelo Capability Maturity Model (CMM) con la aplicacin superficial de mtodos estadsticos. Es slo entonces que intentan construir su comprensin de lo que significa gestin cuantitativa, lo que a menudo lleva a una implementacin superficial de las prcticas del Nivel 4, al extremo de no satisfacer los objetivos del modelo. En este artculo describimos experiencias de nuestra historia como Lead Appraiser con este fenmeno recurrente, sugerimos una explicacin por su similitud a travs de fronteras culturales y polticas, e intentamos ofrecer una versin mejorada de un proceso de uso comn para analizar la estabilidad de los procesos. Dentro de la calidad de software existe un trmino llamado El Aseguramiento de Calidad del Software que es un conjunto de actividades planeadas y sistemticas que se emplean para aportar la confianza en que el producto (software) satisfar los requisitos dados de calidad. Algunos autores prefieren decir garanta en vez de aseguramiento, que al final de cuentas solo se pretende dar confianza en que el producto tiene calidad, para verificar esto hay algunas actividades para el aseguramiento de calidad del software por ejemplo: Mtricas de software para el control del proyecto Verificacin y validacin del software a lo largo del ciclo de vida Incluye las pruebas y los procesos de revisin e inspeccin La gestin de la configuracin del software

La funcin de aseguramiento de la calidad tiene como finalidad primaria el determinar si las necesidades de los usuarios estn siendo satisfechas adecuadamente. Otra de sus funciones, aunque no se tocar mucho en la presente investigacin, es la de determinar los costos que puede causar el aadir ciertas caractersticas al producto, ya que tarde o temprano, la economa resulta ser un factor decisivo para obtener un producto de calidad. Para determinar si las necesidades de los usuarios estn siendo satisfechas, se deben de evaluar tres reas: Objetivos: Los objetivos de la organizacin son primero, luego vienen los requerimientos del usuario. Los objetivos de cualquier usuario deben de estar en armona con los objetivos de la organizacin. Mtodos: Deben de utilizarse mtodos que contengan u observen las polticas, procedimientos y estndares de la organizacin. Ejecucin: Optimizacin del uso de hardware y software al implementar los productos de software.

169

CALIDAD DE SOFTWARE

Para evaluar las reas expuestas con anterioridad, es necesario que se cuente con un programa de aseguramiento de calidad que sea efectivo y que tenga un impacto dentro del desarrollo y prueba del producto de software final. De hecho para el aseguramiento de la calidad de software, es necesario contar un equipo que se distribuya para ser ms objetivos en la revisin de procesos, aunque esto normalmente no se lleve a cabo de tal manera, si no una revisin en general de aseguramiento de la calidad. Incluyamos tambin el concepto de Gestin de la Calidad del Software que es un conjunto de actividades de la direccin que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificacin de la calidad, el control de la calidad, el aseguramiento (garanta) de la calidad y la mejora de la calidad, en el marco del sistema de calidad. Para controlar la calidad del software es necesario, ante todo, definir los parmetros, indicadores o criterios de medicin. Una vez seleccionados los ndices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos: Definir el software que va a ser controlado: clasificacin por tipo, esfera de aplicacin, complejidad, etc., de acuerdo con los estndares establecidos para el desarrollo del software. Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes. Crear o determinar los mtodos de valoracin de los indicadores: mtodos manuales como cuestionarios o encuestas estndares para la medicin de criterios periciales y herramientas automatizadas para medir los criterios de clculo. Definir las regulaciones organizativas para realizar el control: quines participan en el control de la calidad, cundo se realiza, qu documentos deben ser revisados y elaborados, etc. Es vital que las organizaciones adquieran rpidamente un procedimiento y, al menos, un nivel 2 de madurez. Esto implica estandarizar el sistema de desarrollo de software a travs de procesos definidos que permitan realizar proyectos de un modo repetitivo. Muchas organizaciones se sorprenden porque no pueden estimar correctamente el coste de sus proyectos, la pregunta es: hacen dos iguales? Alcanzar el nivel 3 de madurez sin haber alcanzado el 2 cuando menos requiere suerte. Ir de un proceso confuso a un proceso optimizado requiere: Un cambio de mentalidad en la organizacin. Un proceso de formacin continua.

170

CALIDAD DE SOFTWARE

Personal externo a la organizacin que sea crtico e imparcial. Paciencia, tiempo y un poco de suerte.

Adems, la disciplina debe ser asumida y no impuesta. Las personas odiamos que nos impongan las cosas y tenemos miedo al cambio. Pretender contratar un experto que escriba de un modo aislado un documento con los procedimientos que se deben seguir a partir de ese momento en la organizacin provocar desconfianza y rechazo. Toda la organizacin se debe sentir participe de los procedimientos establecidos, cosa que requiere su arte. Para darse una idea de los problemas que causa el no utilizar algn nivel de madurez o especficamente seguimiento de procesos, se presentan algunas estadsticas: 25% de los proyectos software se descartan. Las empresas estn entregando productos a sus clientes con un 15% de errores Muchas empresas gastan del 30% al 44% de su tiempo y dinero en reescribir software que ya haban escrito Las empresas cumplen sus planificaciones slo el 50% de las veces Pero ahora se presentan, los resultados de la mejora, al utilizar los procesos y obtener nivel de madurez: Reducir el nmero de defectos entregados al cliente en un 95% Los programas exitosos de mejora del proceso software pueden conseguir: Reducir la planificacin del desarrollo de software un 71% Incrementar la productividad (medida en lneas de cdigo) en un 222%.

Se deben identificar los procesos inmaduros de alguna manera, para que sean eliminados y algunas caractersticas para hacerlo son: Ahora, Cmo saber que es un proceso maduro? Las actividades se llevan a cabo siguiendo procesos planificados Los procesos de desarrollo de software son improvisados Los procesos no se siguen rigurosamente No hay gestin de proyectos Ausencia de planes Los calendarios y presupuestos se sobrepasan Las fechas lmite comprometen la funcionalidad y calidad No hay medicin objetiva de la calidad No hay maneras objetivas de resolver problemas de producto o proceso

171

CALIDAD DE SOFTWARE

Los procesos de desarrollo se comunican al personal Los procesos son usables y consistentes con la forma de trabajo Los procesos se actualizan si es preciso Roles y responsabilidades claros en el proyecto Hay seguimiento de la calidad de los productos y procesos Criterios objetivos para evaluar la calidad y resolver problemas

Actualmente, muchas empresas dedicadas al desarrollo de software, utilizan los modelos ms comunes de certificacin, en este caso ISO-9000 y CMM no es fcil llegar a cumplir los niveles de madurez, ya que los procesos son revisados minuciosamente, adems de que una empresa madura, deber contar con personal maduro, as que esto significa que aquella empresa que logre estar certificada por uno de estos modelos, es reconocida ampliamente, y por lo consiguiente es buscada por cliente potenciales y reconocidos que la harn crecer. No se puede medir la calidad del software de forma correcta debido a su naturaleza, la certificacin se da a los procesos, la correcta consecucin de los mismos garantizara un buen software. No se puede medir al software como tal, sino los atributos que la conforman, tales mtodos de medida deben ser exactos. El usuario final mide la calidad del software segn lo que tenga o no, es en ese sentido de que la calidad del software depende de quien la juzgue. El hecho de que una empresa tenga certificacin en calidad de software no garantiza que su software sea de calidad. Destaquemos los puntos ms importantes del nivel 5 Optimizacin: La empresa emplea mtricas con propsitos de optimizacin. En este nivel se tienen los medios para identificar los elementos ms dbiles del proceso y mejorarlos. Los factores que imposibilitan la realizacin, son identificados y eliminados. La mejora continua est institucionalizada La transicin a nuevas tecnologas es practicada rutinariamente Prevencin de defectos Gestin del cambio de tecnologa Gestin del cambio del proceso

172

CALIDAD DE SOFTWARE

UNIDAD IV CALIDAD ENFOCADA AL DESARROLLO DE SOFTWARE

173

CALIDAD DE SOFTWARE

4.1 QUE ES LA CALIDAD DE SOFTWARE. Antes que nada, se tiene que discutir el concepto de calidad, para diferentes personas tiene un significado distinto. Hay para quienes calidad es lo que el cliente pide, lo que la mayora de la gente exige al adquirir un producto. Pero para otras personas, calidad es hacer un producto con los menos errores posibles, en la cual se puede exigir una garanta. Qu es Software? Es una conjuncin de los programas, e instrucciones, que son reglas informticas, que al funcionar juntas se ejecutan las tareas que el usuario ha determinado usar en una computadora. Otro concepto muy importante dejar en claro, es ISO (International Organization for Standardizacion), que son las siglas de la Organizacin Internacional de Normalizacin, esta organizacin se encarga de regular normas nacionales. Nace en 1947 en Ginebra, cada pas est representado en esta sede. Esta institucin tiene por tarea desarrollar la normalizacin con carcter mundial y, a tal efecto, pblica normas internacionales conocidas como "normas ISO", que intentan acercar las normas nacionales de cada Estado miembro. La ISO es un organismo consultivo de las Naciones Unidas. Otra institucin que se relaciona con la Calidad de Software es la IEEE (Institute of Electric and Electronics Engineers) que en espaol significa, Instituto de Ingenieros Elctricos y Electrnicos. Es un instituto que es de Estados Unidos y se dedica muy especialmente a todo lo que tiene que ver con el desarrollo de computadoras. Alguna otra de sus actividades es definir estndares para todo aquello que tiene que ver con la elctrica y la electrnica. Le interesa la difusin del conocimiento de su rea para promover el desarrollo y la integracin de las tecnologas para que sean usadas en la sociedad. Por eso es que integr a la IEEE el modelo CMM que trata de que las organizaciones cumplan con procesos. Hablar de calidad de software, es hablar de satisfaccin para el usuario, en el cual el software ha pasado ya por un proceso de revisin, en donde ha cumplido con los establecido dentro de las normas de calidad. Es la cualidad de todos los productos, no solamente de equipos sino tambin de programas. La calidad tiene caractersticas propias del software aquellas que se quieren controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan fsicamente, sino que se desarrolla; El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carcter fsico. La calidad del software es muy parecida al concepto de calidad en general, un concepto seria el propuesto por R.S. Pressman el cual dice que la calidad de software es: Concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente. [15]

174

CALIDAD DE SOFTWARE

El concepto de calidad en general tiene varias dcadas de historia, mientras que la calidad de software tiene 50 a 60 aos. Los requisitos del software son la base de las medidas de calidad. Para poder afrontar el estudio de calidad del software debemos conocer primeros los principales trminos empleados en esta rea: Gestin de la Calidad de Software (Software Quality Management). Aseguramiento de la Calidad Software (Software Quality Assurance). Control de la Calidad de Software (Software Quality Control). Verificacin y Validacin de Software (Software Verification and Validation).[16]

Para revisar dicha calidad, existen organizaciones dedicadas a someterlas a pruebas para garantizarle calidad al usuario, tal es el caso de la normas ISO, que dedican a hacer revisiones a procesos y estndares de las organizaciones para que el usuario tenga mayor confianza de adquirir productos en alguna de las organizaciones que estn certificadas por la ISO u otras normas. Otro de los modelos para garantizar calidad, es el Modelo de Capacidad y Madurez, tambin conocido como CMM, que consta de 5 niveles, siendo el nivel 1 de menor calidad, y el nivel 5 el de mayor grado de madurez. Existe tambin el modelo PSP (Personal Software Process) /TSP (Team Software Process): Que es una tecnologa que tiene como justificacin la premisa de que la calidad de software depende del trabajo de cada uno de los ingenieros de software y de aqu que el proceso diseado debe ayudar a controlar, manejar y mejorar el trabajo de los ingenieros. El objetivo de PSP es lograr una mejor planeacin del trabajo, conocer con precisin el desempeo, medir la calidad de productos y mejorar las tcnicas para su desarrollo. [17] La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en funcin de la normalizacin. No se puede medir la calidad del software de forma correcta debido a su medio, la certificacin se da a los procesos, el logro de los mismos garantizara un buen software. No se puede medir al software, sino los atributos que la conforman, tales mtodos de medida deben ser exactos. Por ejemplo, 5 mtodos, 120 LOCs, etc. El usuario final mide la calidad del software segn lo que tenga o no. El hecho de que una empresa tenga certificacin en calidad de software no garantiza que su software sea de calidad. Cada vez ms organizaciones se preocupan por la implantacin de modelos de calidad en el desarrollo del software. Existen numerosas iniciativas, siendo las ms importantes:

Las normas ISO

175

CALIDAD DE SOFTWARE

El Capability Maturity Model (CMM)

En objetivo consiste en mejorar los procesos de desarrollo de software de tal modo los proyectos sean ms predecibles, se reduzcan los riesgos en el desarrollo, etc. Se analizar el nivel 5 del modelo CMM. CMM es un Modelo de Capacidad de Madurez, por medio de ste es posible llevar a cabo evaluaciones del seguimiento de procesos en una organizacin. Fue desarrollado por la universidad Carnegie Mellon principalmente para los procesos que tienen que ver con el desarrollo e implementacin de software que se llevaban a cabo en el Instituto de Ingeniera de Software.

Figura 52 : Modelo CMM

Para el seguimiento de este modelo, se determinan reas de procesos que deben de cumplir con ciertas prcticas para tener un desempeo exitoso y cumplir con el nivel de calidad solicitado, entre dichas prcticas podemos mencionar el tener bien definidas las practicas de una documentacin, practicas que se puedan medir, practicas que puedan ser verificadas. A su vez las reas de procesos de dividen en cinco niveles de madurez, de manera que en una organizacin que lleve a cabo todas las practicas que encierra un nivel y los niveles que vengan debajo de ste, se considere que se ha logrado ese nivel de madurez. Los niveles son: Inicial, Repetible, Definido, Gestionado y Optimizado, cada uno pueden ser numerados de 1 al 5 respectivamente. Una breve descripcin de cada uno de ellos: 1. Inicial. Es el nivel ms bajo de la escala, describe a compaas sin procesos repetibles, en donde mucho del trabajo es un caos. El xito de sus proyectos depende de la fortaleza y habilidades del equipo de trabajo.

176

CALIDAD DE SOFTWARE

2. Repetible. Se implementan procesos estandarizados, para establecer cimientos de mejora para un futuro. 3. Definido. Se est tratando de alcanzar la estandarizacin en el proceso de desarrollo de software. 4. Gestionado. Se dispone de un conjunto de mtricas significativas de calidad y productividad 5. Optimizado. Se tiene un ciclo cerrado de ejecucin de procesos, medicin de desempeo y mejora continua. A lo largo de este documento se ahondara en el seguimiento de este ltimo nivel. Se har una explicacin ms a fondo de lo que significa que una organizacin llegue a este nivel de madurez. Es muy importante mencionar que el aplicar este modelo en una organizacin, es indicio de que se est usando la calidad de software, pues se est luchando por tener un producto que sea altamente de calidad. Tambin a largo del desarrollo se hablar de que es, lo que significa aplicar este concepto al desarrollo de software.

177

CALIDAD DE SOFTWARE

4.2. COMO OBTENER CALIDAD DE SOFTWARE.

La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y prueba del software que permitan uniformar la filosofa de trabajo, en reas de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. La poltica establecida debe estar sustentada sobre tres principios bsicos: tecnolgico, administrativo y ergonmico.

El principio tecnolgico: Define las tcnicas a utilizar en el proceso de desarrollo del software. El principio administrativo: Contempla las funciones de planificacin y control del desarrollo del software, as como la organizacin del ambiente o centro de ingeniera de software. El principio ergonmico: Define la interfaz entre el usuario y el ambiente automatizado.

La adopcin de una buena poltica contribuye en gran medida a lograr la calidad del software, pero no la asegura. [19]

En la actualidad la competencia en las empresas ha evolucionado en base al crecimiento y desarrollo de la tecnologa destacando la oportunidad de expandir el mercado mundialmente a travs de Internet, ya que esta herramienta ha ayudado en las comunicaciones tanto personales como empresariales debido a que la facilidad de comunicarse con una persona al otro lado del mundo en una video-llamada en tiempo real; lo que ha orillado a la mayora de estas empresas a buscar algo ms que ofrecer a sus clientes en sus productos, encontrando en la calidad el plus agregado para el poder sobresalir ante la competencia. Para esto se han creado instituciones que solamente se dediquen a evaluar a otras instituciones el nivel de calidad de sus productos, procesos y determinar si cumplen con los requisitos especficos para poder ser una empresa certificada en con calidad, un ejemplo de estas empresas es ISO (International Organization for Standarization) y la IEEE (Institute of Electric and Electronics Engineers); las cuales se han dedicado a evaluar la forma en que otras empresas llevan a cabo tanto el contacto con el cliente como el desarrollo de los trabajos y el desempeo

178

CALIDAD DE SOFTWARE

de los trabajadores; y desarrollando los estndares en los cuales las instituciones que quieran obtener un certificado de calidad se deben de basar y seguir para conseguir dicha acreditacin. Otra de las instituciones dedicadas a este tipo de giro que es el certificar empresas es el Software Engineering Institute (SEI), el cual utiliza un modelo llamado CMMI que es muy reconocido y del cual hablare mas adelante con 2 de sus metodologas. Sin embargo el obtener una certificacin de calidad no es el final del camino, ya que para poder conservarla se deben de seguir los mismos procesos siempre, aunque las empresas siempre deben de buscar mejorar esos certificados y obtener el mximo nivel de certificacin si se pudiera, ya que esto hablara mejor de la empresa al mostrar sus credenciales. En este ensayo nos enfocaremos ms a la descripcin de las metodologas y a los mtodos que se emplean para controlar la calidad del software en las empresas dedicadas a este rubro, que es el diseo y desarrollo de software, a que se refieren para que sirven, etc. Se deben de seguir ciertos mtodos y metodologas que se han estandarizado para poder tener un punto de referencia para partir en la evaluacin, estos estndares se refieren como lo menciona la definicin anterior al anlisis del sistema, el diseo de la solucin, la implementacin de la solucin y las pruebas necesarias para poder entregar el producto terminado y sin errores para poder garantizar un trabajo bien hecho y de una buena calidad. Con el transcurso del tiempo estos mtodos y metodologas elevaran la productividad de la empresa al desarrollar los proyectos futuros que se pudieran tener y obviamente un control de la calidad que se tiene.

Figura 53: Ejemplo de metodologa de una empresa (proceso de desarrollo de Sw.)

La gestin de la calidad se divide en el control de calidad y aseguramiento de la calidad, donde el aseguramiento de la calidad es dar la confianza al cliente de que el software que se entregara satisfar los requerimientos que se han pedido se lleven a cabo en el desarrollo del proyecto y el cliente estar cmodo con esa nueva adquisicin.

179

CALIDAD DE SOFTWARE

4.3 COMO CONTROLAR LA CALIDAD DEL SOFTWARE. En trminos generales entendemos por Control de Calidad, un conjunto de actividades para evaluar la calidad de los productos desarrollados. Control de calidad implica vigilar el proceso de desarrollo de software para asegurar que se sigan los procedimientos y los estndares de garanta de calidad, en el proceso de control de calidad se comprueba que las entregas cumplan con los estndares definidos. Consiste en revisar que al final el producto cumpla los requerimientos del cliente. [20] El control de calidad se lleva a cabo a nivel operativo, es decir mientras se lleva a cabo el desarrollo del software se sigue de cerca que se cumplan los acuerdos a los que se llego con el cliente y eliminar los posibles errores que surjan en cada fase del proceso de desarrollo antes de entregar el producto para que solo sean defectos y se demuestre la eficiencia en el trabajo y no surjan errores a la hora de presentar el proyecto al cliente y mostrar una mala imagen al cliente y demostrar que no se puede con el proyecto. Por lo tanto se puede decir que se busca cumplir dos objetivos con el control de calidad, el llevar el control de los procesos y eliminar los defectos que se pudieran suscitar antes de que se conviertan en errores. Los trminos anteriores se pueden resumir en una estrategia como la siguiente:

Figura 54. Control de calidad del software.

Donde podemos observar que para asegurar la calidad del software se hace un marco de referencia con el cual comparar y se elabora una estrategia de mejora en caso de que lo planeado no concuerde con la referencia, despus para mantener el control de la calidad se llevan a cabo revisiones constantes y auditorias de los procesos y lo que se va a entregar para

180

CALIDAD DE SOFTWARE

ser certificado, se presenta y si pasa las pruebas se aprueba y se entrega el producto final y las organizaciones se enteran de que se manejan procesos y se entregan productos con calidad. Un ejemplo es lo que hace la empresa SDL el cual en su pgina seala que tiene un mtodo infalible que ofrece una solucin infalible para obtener software de calidad, debido a que en su laboratorio de calidad llevaban a cabo una serie de pasos como:

Anlisis Plan general de la prueba Esquema detallado de la prueba Prueba de funcionamiento Prueba de la interfaz de usuario (UI) Inspeccin final del cliente (FCI) Herramientas automatizadas Localizacin y regresin de errores Coordinacin de proyectos

Con estos pasos nos dicen que el control de la calidad es muy bien manejado y se reducen los costos al mnimo, cosa que varias metodologas buscan el reducir los costos y los tiempos al mnimo, y obteniendo software de calidad. Para que una empresa lleve a cabo el control de la calidad de software es necesario saber cmo se va a desarrollar el proceso, para esto primero se debe saber que metodologas se van a llevar a cabo para este fin. Para esto cada empresa debe definir con que metodologas sera mejor trabajar o se le facilitara mas llevar a cabo la obtencin de la calidad en sus procesos y cuales certificaciones les convendran obtener para tener ms prestigio. Existen una gran diversidad de metodologas que pueden ayudar a conseguir la certificacin o acercar a la empresa a ella, como lo son XP o Extreme Programming, Scrum, MSF o Microsoft Solution Framework, CMMI, Rapid Application Development (RAD), Rational Unified Process (RUP), Agile Unified Process (AUP), entre otras, las cuales veremos ms delante y describir lo mas entendible posible. La metodologa XP es una metodologa destinada a la calidad del software cuando un cliente realiza cambios, para poder tener una capacidad de respuesta ante estas situaciones y mejorar la productividad para adoptar las nuevas necesidades de los clientes. Otros elementos de Extreme Programming son: llevar a cabo la programacin en parejas o realizando una revisin de cdigo amplia, tambin llevando a cabo pruebas de unidad del cdigo, evitando que se programen las funciones hasta que sean realmente necesarias para el funcionamiento del programa, usando la simplicidad y la claridad en el cdigo para realizar posteriores cambios, con el paso del tiempo el problema se entiende mejor, y crece la frecuencia de comunicacin entre los programadores con el cliente. La metodologa toma su nombre debido a que se llevan a cabo a niveles extremos de la teora de que si algo es bueno, ms es mejor. Sin embargo, algunos crticos han sealado varios posibles inconvenientes, como los problemas con requisitos inestables, compromisos no documentados, de los conflictos con los usuarios no documentados, y la falta de un diseo global o un documento de especificaciones.

181

CALIDAD DE SOFTWARE

Su principal objetivo es el organizar a la gente para producir software de calidad de una manera ms productiva y de manera superior. Otra de las metodologas es la llamada Scrum, es una metodologa gil, siendo un marco de la gestin de trabajo complejo iterativo incremental (como el desarrollo de productos nuevos) de uso comn con el desarrollo gil de software. Aunque Scrum se pretenda utilizar para la gestin de proyectos de desarrollo de software, tambin puede ser utilizado para ejecutar software de mantenimiento de equipos, o como un proyecto o programa de gestin. Scrum es un "proceso de esqueleto", que contiene un conjunto de prcticas y funciones predefinidas. Los principales roles en Scrum son: 1. "ScrumMaster", que mantiene los procesos (por lo general, se desempea en lugar de un director de proyecto). 2. "Propietario del producto", que representa a las partes interesadas, en este caso vienen siendo los clientes. 3. "Equipo", un grupo funcional compuesto de unas 7 personas que hacen el anlisis, diseo, implementacin, pruebas, etc., para desarrollar un producto de calidad. Esta metodologa se lleva a cabo a travs de sprints que son ciclos de 2 a 4 semanas dependiendo de lo que decida el equipo, donde se llevan a cabo los clculos del tiempo que se va a necesitar para llevar a cabo el programa tal y como el cliente lo solicito y el costo del mismo, mas adelante veremos que existen otras metodologas que se parecen a esta. Una metodologa gil que no haba escuchado y que tan solo considero es bueno nombrar debido a que no ha sido muy mencionada es la MSF o Microsoft Solution Framework la cual sigue muy de cerca la metodologa que aplico alguna vez Bill Gates sobre Steve Jobs, en aquellos aos donde Microsoft apenas apareca al mercado y Apple (Macintosh) estaba en pleno apogeo, y Bill Gates utilizo el xito de Steve Jobs para que su industria creciera robando la idea de las ventanas; diciendo que la forma ms fcil de llegar al xito es siguiendo los pasos de los exitosos, mas sin embargo no se refiere a esperar a ver qu hace la competencia y luego copiar y mejorar el producto, la idea es aprender a hacer las cosas como los expertos y siguiendo sus planes de accin para despus dividirlas en modelos y estos aplicarlos ya sea individualmente o combinados, estos modelos son los siguientes:

Team Model (Modelo de Equipo) Process Model (Modelo de Procesos) Application Model (Modelo de Aplicacin)

Solution Design Model (Modelo de Diseo de Soluciones) Enterprise Architecture Model (Modelo de Arquitectura Empresarial)

182

CALIDAD DE SOFTWARE

Infraestructure Model (Modelo de Infraestructura)

Total Cost Ownership Model (Modelo de Costo Total de Propiedad) CMMI es un tipo de metodologa formal cuyo origen es del departamento de defensa de los Estados Unidos la cual clasifica las empresas por nivel de madurez que tienen en los procesos para el desarrollo de software, consta de 5 niveles las cuales son: 1. Inicial o nivel 1. En esta estn todas las empresas que no tienen procesos. 2. Repetible o nivel 2. El proyecto es gestionado y controlado durante el desarrollo. 3. Definido o nivel 3. Se tiene una gestin y una ingeniera definida para desarrollar proyectos. 4. Cuantitativamente gestionado o nivel 4. Se usan mtricas para evaluar las necesidades de los clientes y la organizacin. 5. Optimizado o nivel 5. Los procesos de los proyectos y de la organizacin estn orientados a la mejora de actividades. En esta metodologa o ms bien modelo existen 2 sub metodologas por as decirlo, desarrolladas por el SEI por medio de la universidad de Carnegie Mellon llamadas Personal Software Process (PSP) y Team Software process (TSP) gracias a Watts Humphrey; las cuales nos permiten medir la forma en que programamos para llevar a cabo la calidad en el desarrollo del software. PSP es una herramienta de proceso personal del software para el diseo y desarrollo de software con calidad, consta del desarrollo de 8 programas en el transcurso de 2 semanas, se utiliza una herramienta donde se ingresan los datos que sern tomados como datos histricos y en los que el programador se basara para hacer estimaciones tanto de tiempo como de tamao, tambin esta herramienta calcula la productividad del desarrollador y los puntos fuertes y dbiles del mismo, en el curso para utilizar esta herramienta se ensea cmo interpretar los datos y de donde obtenerlos para su anlisis, ya que se debe de hacer un reporte intermedio al finalizar el cuarto programa en base a esos 4 programas y un reporte final al termino del curso con los 8 programas. Sus principios son:

Cada ingeniero es diferente; para ser ms eficiente, debe planificar su trabajo basndose en datos tomados de su propia trayectoria profesional. Para mejorar autnticamente su trabajo, los ingenieros deben usar procesos personales bien definidos y cuantificados. Para obtener productos de calidad, el ingeniero debe asumir la responsabilidad personal de la calidad de sus productos. Los buenos productos no se obtienen por azar, sino como consecuencia de un esfuerzo positivo para hacer un trabajo de calidad. Cuanto antes se detecten y corrijan los defectos menos esfuerzo ser necesario. Es ms efectivo evitar los defectos que detectarlos y corregirlos. Trabajar bien es siempre la forma ms rpida y econmica de trabajar.

Y para cumplir estos principios el ingeniero en software debe de planificar el trabajo para no realizar a ciegas el proyecto que vaya a hacer, esforzarse por cumplir la planificacin debido a

183

CALIDAD DE SOFTWARE

que el hacerlo en ms tiempo de lo planeado repercute en el costo del proyecto, esforzarse por obtener productos de la mejor calidad, cumpliendo con lo planeado como se menciona anteriormente y cometiendo el mnimo de errores posibles a la hora de disear, programar, codificar y realizar las pruebas, debido a que esto es lo que cuida la metodologa, y tambin el conocer la forma en que cada programador trabaja para poder realizar estimaciones correctas de tiempos y tamaos de desarrollo de software y dar fechas aproximadas ms reales y con fundamentos. TSP es una herramienta muy similar al PSP la diferencia es que en TSP los datos son en equipo y para esta herramienta no existe un curso como tal, sino que solo se instruye a los que deseen ser lideres de equipo, y este mismo solo guiara a sus compaeros para el desarrollo del proyecto por medio de esta herramienta, cabe sealar que para poder ser un lder de equipo en TSP es necesario haber tomado el curso de PSP y ser certificado en l, en esta herramienta se toman en cuenta los datos de cada programador del curso de PSP y se llevan a cabo un total de 9 juntas, necesarias para llevar a cabo lo que se llama un levantamiento de proyecto, el cual se trata de analizar y planear como se llevara a cabo el proyecto antes de hablar con el cliente, para el momento de levantar los requerimientos y el cliente nos pida algo con lo que no habamos contado el ajuste de tiempos sea ms corto y podamos dar una respuesta lo ms rpido posible. Este par de metodologas no es muy empleada en la actualidad debido a que sus procesos son demasiado estrictos, pero la calidad de los proyectos desarrollados tiende a ser optima dando resultados inigualables, una de las pocas empresas que manejan estos procesos es la empresa Quarksoft S.C. y su ndice de errores es de 0.03% por cada 1,000 lneas de cdigo, una muestra demasiado fehaciente de que el uso de estas metodologas funciona para crear productos de software con calidad y si no exentos de errores con un valor mnimo de errores.
TSP
Team development

PSP2
Code reviews Design reviews

PSP2.1
Design templates

PSP1
Size estimating Test report

PSP1.1
Task planning Schedule planning

PSP0
Current process Time recording Defect recording Defect type standard

PSP0.1
Coding standard Size measurement Process improvement proposal (PIP)

Figura 55. Proceso de Aprendizaje.

En la imagen se muestra como es el proceso de aprendizaje de estas dos poderosas herramientas para el desarrollo de software con calidad, podemos observar que el flujo es entre los nmeros enteros donde se ven los temas ms importantes y bsicos para el buen desempeo del programador en el curso, los puntos en color azul son anexos de formatos para el control de

184

CALIDAD DE SOFTWARE

tiempos y tamaos; por ultimo podemos observar que TSP es el final de la escalera pues como dije anteriormente es el curso final. La metodologa Rapid Application Development (RAD) fue desarrollada entre los aos 70s y 80s por James Martin pero se formalizo hasta el ao de 1991 en la publicacin de un libro llamado desarrollo rpido de aplicaciones, esta metodologa consta de elaborar prototipos y dividir los programas en pequeos mdulos que faciliten la programacin del proyecto y adems facilita la insercin de nuevos requerimientos que pida el usuario, ya que se agregaran a los mdulos correspondientes y una vez finalizado se acopla todo el proyecto en uno solo, esto permite mayor manejabilidad y menos errores debido a que el desarrollo del modulo permite detectar los errores de cada uno de ellos y al momento de unirlos se supone que no debe de haber errores, sin embargo los profesionales expertos en RAD reconocen que hasta el momento no existe una metodologa rpida para generalizar a todos los proyectos, debido a que depende mucho de la cultura corporativa, el ciclo de liberacin del software, tipo de proyecto, y el calendario de trabajo de la empresa. El Rational Unified Process (RUP) fue diseado por una empresa perteneciente a IBM; el RUP se basa en un conjunto de bloques de construccin de los elementos de contenido, describiendo lo que se van a producir, los conocimientos necesarios y el paso a paso la explicacin que describe los objetivos de desarrollo concretos de cmo se lograran. En enero de 2007, se libero el examen de certificacin RUP para IBM Certified Solution Designer - Rational Unified Process 7.0, que sustituye a la anteriormente llamada IBM Rational Certified Specialist - Rational Unified Process. El nuevo examen no slo es la prueba de conocimientos relacionados con el contenido de RUP, sino tambin a los elementos de la estructura del proceso. Para aprobar el examen de certificacin RUP, una persona debe tener pruebas de IBM 839: Rational Unified Process v7.0. Se le da 75 minutos para tomar el examen de 52 preguntas.La calificacin de aprobacin es del 62%. Agile Unified Process (AUP) es una versin simplificada de Rational Unified Process (RUP) desarrollado por Scott Ambler. Se describe un sencillo y fcil de comprender enfoque al desarrollo de software para aplicaciones empresariales utilizando tcnicas y conceptos de agilidad y an se mantiene fiel a la RUP. El AUP aplica tcnicas giles como Test Driven Development (TDD), Administracin de modelado del cambio gil, y refactorizacin de base de datos para mejorar la productividad. Tiene siete disciplinas: 1. Modelo. Entender el problema que aborda el proyecto, e identificar una solucin viable para hacer frente al dominio del problema. 2. Aplicacin. Transformar el modelo (s) en cdigo ejecutable y realizar un nivel bsico de las pruebas, en pruebas de unidades particulares. 3. Prueba. Realizar una evaluacin objetiva para garantizar la calidad y verificar que se cumplan los requisitos. 4. De implementacin. Plan para la entrega del sistema.

185

CALIDAD DE SOFTWARE

5. Gestin de la Configuracin. Gestionar el acceso a los artefactos del proyecto, el control y la gestin de los cambios para ellos. 6. Gestin de Proyectos Dirigir las actividades que lleva a cabo dentro del proyecto, y coordinar con las personas y los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a tiempo y dentro del presupuesto. 7. Entorno. El apoyo del resto de los esfuerzos por garantizar que el proceso adecuado, normas de orientacin (y directrices), y herramientas (hardware, software) estn disponibles para el equipo segn sea necesario. Como podemos observar todas las metodologas llevan una serie de procedimientos o mtodos para que la calidad se logre, ya que las metodologas y los mtodos estn muy de la mano en esta situacin de la calidad ya que uno no puede estar sin el otro para que se pueda dar la calidad al 100 por ciento, debido a que una metodologa dentro de la ingeniera de software, se encarga de elaborar estrategias de desarrollo de software que promuevan prcticas adaptativas en vez de predictivas; centradas en las personas o los equipos, orientadas hacia la funcionalidad y la entrega, de comunicacin intensiva y que requieren implicacin directa del cliente.Un mtodo hace referencia al medio para llegar a un fin siendo la serie de pasos que tiene una metodologa para llevarla a cabo y llegar a la meta que busca la metodologa. En conclusin la competitividad es una causa de la bsqueda de la calidad, deseando abarcar ms y mejor mercado en todo el mundo para que las empresas lleguen a ser la nmero 1 y obtener un reconocimiento para poder monopolizar el mercado, que al fin de cuentas es lo que busca una empresa, siempre crecer y ser mejor que los dems, es la ley de la vida y siempre lo ser mientras exista la competitividad y se aproveche el avance tecnolgico para realizar la comunicacin con otros pases y continentes y lograr adquirir ms mercado mundial. Lo primero que se debe hacer para poder ser una empresa con calidad, es tener trabajadores y procesos de calidad, y para poder conseguirlos se debe investigar cuales son los procesos y metodologas que se ajusten mejor a las necesidades de la empresa, para despus investigar cuales son los requerimientos necesarios para cumplir con esos procesos y buscar una certificacin de calidad para poder ganar posicin en el mercado. Una vez decidido cuales sern los procesos se buscan las metodologas para lograr una certificacin y capacitar a los empleados en esta nueva etapa de crecimiento de la empresa, debido a que una certificacin puede ser una etapa de maduracin a la cual las personas le tienen miedo debido a que existe un cambio, por lo tanto estas personas no estarn al 100 por ciento convencidas de que sea lo mejor para la empresa ya que tendrn que aprender cosas nuevas y eso no es del total agrado de las personas y no cooperaran tan fcilmente; por lo que tambin debern tomar en cuenta la psicologa con la que se llegara a plantear la situacin a los empleados y convencerlos de que es la mejor de las de las opciones para el bien de la empresa, mas no obligarlos a trabajar bajo ese rgimen y que de cierto modo ellos crecern con la empresa y adquirirn ms experiencia que les puede servir en un futuro prximo. Al momento de conseguir la certificacin se entra a la siguiente etapa, la cual es el control de la calidad donde se ponen en marcha todas y cada una de las metodologas seleccionadas para llevar a cabo este control, tomando en cuenta que sea una metodologa que se pueda adaptar fcilmente a la forma de trabajo de la empresa, al ciclo de vida del software y a los procesos que se manejan en la empresa para que no sea difcil para los trabajadores el adaptarse a la

186

CALIDAD DE SOFTWARE

nueva forma de trabajo a la que se dedicaran y no estn apticos en el momento de trabajar con ella. Al momento de trabajar con un cliente se notara la diferencia de manejar una metodologa con sus mtodos para llevar a cabo el desarrollo del software o aplicacin y el cliente estar satisfecho al encontrar una empresa que toma con seriedad el asunto de la atencin al cliente con calidad, y ver que no trata con una empresa que solo busca el bien propio, sino que tambin sacrifica parte de su tiempo para que l y su empresa estn en total satisfaccin con el producto que se le est entregando, creando un vinculo para que nos recomiende a otras empresas y as se pueda madurar en un nivel ms alto de certificacin creando una mejor imagen para la empresa. Es de suma importancia en la actualidad contar con certificaciones de calidad tanto a nivel empresarial como a nivel personal para poder obtener un mejor trabajo y un mejor curriculum; adems de posicionarse mejor en el mercado para poder crecer y llamar la atencin para bien tanto con empresas que requieran los servicios o empresas que quisieran fusionarse con la empresa certificada para ellos tambin buscar ese plus laboral.

187

CALIDAD DE SOFTWARE

4.4 COSTO DE LA CALIDAD DEL SOFTWARE. Se puede iniciar resumiendo lo que es la calidad del software, la calidad del software es la totalidad de caractersticas de un producto de software que tienen como habilidad, satisfacer necesidades explcitas o implcitas ; en esta definicin se observa que estas caractersticas de las que se habla son las que conllevan la responsabilidad de que un producto de software sea de calidad o no, es aqu donde entra el costo de la calidad de software. El Costo de la Calidad del Software CoQ, es una tcnica inicialmente introducida por Juran en 1996 para proporcionar a los directores de proyectos instrumentos que les permitan justificar la promocin de mejoras en el proceso de desarrollo.

Hablar de costo de la calidad de software nos obliga a hablar de los distintos tipos de costos de calidad de software que existen, entre ellos se encuentran:

Figura 56. El modelo PEF. Costos de prevencin: Cuyas actividades consisten en: planificacin de la calidad, revisiones, tcnicas formales, equipo de pruebas, formacin. Costos de Evaluacin: En este tipo de costos se engloban caractersticas como inspeccin de cada proceso y entre los procesos y las pruebas. Costos de Fallos internos: Estos ocurren antes de la estrategia, se encuentran entre ellos reparacin, revisin y anlisis. Costos de Fallos Externos: Estos ocurren despus de la estrategia, incluiran: resolucin, soporte y reemplazo entre otras caractersticas.

188

CALIDAD DE SOFTWARE

Figura 57. El modelo PEF cada categora del costo en porcentaje.

Profundizando ms acerca de estos tipos de costos, tenemos que: En el costo de prevencin se engloban actividades dedicadas a la prevencin de defectos que ocurren durante el desarrollo, produccin, almacenamiento etc., en pocas palabras es el costo de la calidad antes de que una sola unidad sea desarrollada, el propsito de realizar una prevencin es minimizar aquellos problemas globales que se puedan presentar por causa de que en un inicio no se llevo de manera correcta una planeacin. En el costo de Evaluacin en este tipo de costos se incluyen inspecciones y ensayos. Con las inspecciones nos aseguramos de que la materia prima es de calidad; podemos decir que este es el tipo de costo ms fcil de medir. Con los ensayos obtenemos resultados que nos ayudan a tomar decisiones con respecto a los procesos que estamos realizando tanto internamente como pruebas de productos intermedios y productos finales. Los costos de fallos internos se manifiestan dentro de la empresa y se originan por una baja calidad dentro de estos costos podemos encontrar materiales rechazados, reproceso de inspecciones, destruccin de materias primas, producto terminado rechazado, en fin errores que le ocurren a la empresa internamente. Se pueden resumir los fallos externos como los fallos unas ves que el producto ha salido de la empresa como terminada, algunos detalles que pueden presentarse son como por ejemplo gastos por devoluciones, reclamaciones por calidad, o reclamaciones por faltantes. Aparte de los costos antes mencionados, podemos encontrarnos con otros tipos de costos, como los costos totales de calidad, los costos ocultos adicionales, los costos ocultos - punta de iceberg etc.

189

CALIDAD DE SOFTWARE

Costos totales de calidad Es la suma de todos los costos, regularmente los sistemas contables no son capaces de detectar estos costos. Costos ocultos adicionales Son los costos intangibles que resultan de los productos o servicios, no conformes a los requerimientos ni necesidades del cliente, en ocasiones pueden ser 3 o 4 veces el costo de la calidad. Costos ocultos - punta de iceberg Este tipo de costos representan aquellos costos que se encuentran debajo de los costos de fallos, y que pueden en determinado momento hundir el barco , o acabar con el proyecto. Medir el costo de la calidad resulta fundamental en un programa de mejoramiento de la calidad. Los dos trminos ms utilizados con respecto a la calidad podran ser: lo que invertimos para obtener buena calidad y lo que pagamos por no lograrla . En el primer caso depende de nosotros el hecho de si deseamos tener buena calidad y de que en nosotros esta el obtenerla, en el segundo caso depende indirectamente de nosotros, ya que por no tener buena calidad en nuestros procesos y productos, pagamos las consecuencias a largo plazo; como tener menos clientes, o recibir muchas devoluciones de productos. Existen ciertas formulas para obtener el costo de la calidad y el costo de la mala calidad, la correcta forma de evaluar los costos de la calidad es: Medir el costo de la calidad durante el desarrollo de software registrando el esfuerzo dedicado a las tareas relacionadas con la calidad, en teora este proceso debera ser barato, si es que se tiene con reportes de de horas de proyectos, de lo contrario el esquema podra cambiar. Dando una breve explicacin del proceso de medicin, obtendramos que: Los miembros del equipo reportan las horas dedicadas a cada actividad mensualmente, a partir de eso se suman las horas dedicadas al proyecto por cada categora, esto resulta ser simple de realizar, solo se ingresan los datos al sistema de medida, el cual puede ser desde uno muy complejo hasta una plantilla de Excel, el cual se alimenta del informe de los reportes de horas. Mtrica peligrosa: Uno de los casos que se pueden presentar es si la gerencia plantea objetivos de reduccin de las mtricas de costo de calidad y costo de la mala calidad pueden producirse algunos vicios, especialmente si las mtricas estn ligadas a la evaluacin del personal. El problema es que si el autor de un documento no quiere tener fallas internas podra dedicar demasiado tiempo a las revisiones personales informales, en otras palabras el autor dedica ms tiempo a revisar en forma personal para asegurar una inspeccin satisfactoria. Este tiempo extra ser medido como creacin. Lo que pasa con las mtricas es que ha aumentado el tiempo de creacin y ha bajado el tiempo de falla, lo que genera un Costo de la calidad y un Costo de la mala calidad mucho mejor. Pero en realidad el tiempo de las revisiones personales del autor debi haberse medido como evaluacin, empeorando la mtrica de Costo de la calidad en lugar de mejorarla. Medir la productividad:

190

CALIDAD DE SOFTWARE

Debemos complementar las mtricas de costo de la calidad con alguna medida de productividad. Complementada con una medida de productividad, entonces s tiene sentido usar las mtricas de costo de calidad. Algunas medidas son simplemente nmero de lneas de cdigo y pginas de documentacin. Otras medidas cuentan puntos de funcin o alguna mtrica similar, que tiene la ventaja que se acerca un poco ms al problema y depende menos de la tecnologa usada. Desde ese punto de vista, una mtrica ideal sera algo as como requerimientos de usuario implementados a la satisfaccin del cliente. En resumen, si bien el costo de la calidad es muy importante, el costo del producto lo es ms. Medir slo el costo de la calidad puede tener impactos negativos en el costo del producto. El objetivo primordial del sistema de costos de calidad es facilitar los esfuerzos de mejorar la calidad enfocados a oportunidades de reduccin de costo operativas, atacar los costos de falla tratando de eliminarlos, invertir en ciertas actividades adecuadas de prevencin, reducir los costos, mejorar los esfuerzos de prevencin, en general de lo que se trata es de aumentar la prevencin ya que es el factor primordial que acta en un sistema de costos. Cada vez que prevenimos los costos de la calidad, estamos contribuyendo a que en el transcurso del proyecto no ocurran errores o por lo menos minimizarlos, para que el impacto que tengan sobre el sea menor, ya que bien lo mencionaba Taguchi no se pueden reducir los costos sin afectar la calidad y no se puede mejorar la calidad sin incrementar el costo , Enfoques de la gestin de los costos de calidad: Existen tres tipos de enfoques con respecto a la gestin de los costos de la calidad, los cuales son enfoque de costos de calidad, enfoques de costos de proceso, enfoque de prdida de calidad. En el primer enfoque nos menciona las cuatro categoras antes mencionadas, las cuales son prevencin, evaluacin, falla interna y falla externa, hace mencin de estos trminos y de cmo utilizarlos para reducir el costo de la falla, nos menciona tambin que este tipo de enfoque se puede llevar a cabo en toda la empresa, tomando estos costos como un porcentaje de alguna base como por ejemplo la manufactura o las ventas. El siguiente enfoque nos habla de la perdida de la calidad, en este se describe la filosofa de Taguchi, se intentan capturar los costos tangibles e intangibles, esto debido a la pobre calidad, los separa mencionando que los tangibles son aquellos que son desperdicio y retrabado, y los intangibles son como costos ocultos , un factor seria la perdida de los clientes por la insatisfaccin. En los defectos con mayor ndice de falla, los efectos de mejora son visibles eso si solo se consideran los costos tangibles, de otro modo si se agregan los intangibles el costo podra ser mayor, ya que el impacto seria mayor. En el costo de costo del proceso, se consideran los costos del proceso en lugar del de un producto o centro de costo, se nos menciona tambin que un proceso incluye todas las actividades agrupadas, ligadas y enfocadas, al cumplimiento de los requerimientos del cliente internos y externo, dentro de este enfoque se muestran tambin los costos de conformancia, en los que se mencionan materiales, personal , energa, gastos variables etc. y los costos de

191

CALIDAD DE SOFTWARE

inconformidad son aquellos que son causados debido a fallas. Este enfoque tiene la ventaja de que permite el monitoreo de la reduccin de costos asociados con la eficiencia y la calidad, y en el caso de las empresas que ya tienen un sistema maduro de costos de la calidad resulta ser ms eficiente, hay que mencionar tambin que este tipo de enfoque permite eliminar los costos ocultos de la calidad, lo cual es una gran ventaja ya que estos son los costos que menos se toman en cuenta durante el monitoreo de los costos.

En vista de lo que se ha examinado anteriormente, nos podemos dar cuenta de que los costos de la calidad pueden aparecer en cualquier parte de la creacin del software, como antes de su concepcin, durante la produccin del mismo e incluso despus de terminarlo y entregarlo, Existen muchos autores que escriben acerca de este tema, muchos de ellos incluso han creado modelos, estrategias y filosofas con el fin de solucionar los dilemas de los costos de la calidad del software. En general los costos de la no calidad son mucho mayores a los costos de la calidad, y con mucha razn ya que al implementar la calidad en nuestros procesos nos podemos encontrar con un sin fin de costos entre los cuales estn, dentro de de la categora de los evidentes, los trabajos repetidos, las inspecciones, los defectos, los desechos etc.; por otro lado sin implementar la calidad nos encontramos con costos como devoluciones e inconformidades por parte de los clientes. Concluyendo con el tema se puede decir que en el proceso de calidad se pasa por ciertas fases, muchas de las cuales implican costos de muchos tipos, sin embargo es preferible aceptar este tipo de costos a exponerse a otros costos muchos mayores.

192

CALIDAD DE SOFTWARE

4.5 NOMENCLATURA Y CERTIFICACIN ISO 9001:2000. El modelo propuesto en la norma ISO 9001 en su versin del ao 2000, es sin lugar a dudas, una evolucin natural de las demandas de las organizaciones pblicas y privadas para contar con herramientas de gestin ms slidas y efectivas para hacerse al incierto mar de la globalizacin y capitalizar sus esfuerzos. ISO 9001:2000 tiene muchas semejanzas con el famoso Crculo de Deming: acrnimo de Plan, Do, Check, Act (Planificar, Hacer, Verificar, Actuar). Est estructurada en cuatro grandes bloques, completamente lgicos, y esto significa que con el modelo de sistema de gestin de calidad basado en ISO se puede desarrollar en su seno cualquier actividad. La ISO 9000:2000 se va a presentar con una estructura vlida para disear e implantar cualquier sistema de gestin, no solo el de calidad, e incluso, para integrar diferentes sistemas. [21]

Figura 58. Requerimientos de ISO 9001:2000

En el grafico anterior se muestran los requerimientos que se deben de obtener para obtener una certificacin de tipo ISO 9001:2000, se puede observar que consta de cuatro bloques , cada uno de los cuales engloba actividades especificadas cuales son: responsabilidad de la direccin, realizacin del producto, administracin de recursos, administracin , mediciones y anlisis de mejora, todas ellas conforman lo que es el sistema de gestin de calidad, y dentro del sistema de gestin de calidad se establecen ciertas actividades como son el hacer, revisar, actuar y planear, todas ellas ligadas a cada uno de los requerimientos que se mencionaron anteriormente. De esta forma es en la que acta la certificacin del ISO 9001:2000.

Para la certificacin ISO 9001:2000, se requieren ciertos requisitos, los cuales se mencionan a continuacin:

193

CALIDAD DE SOFTWARE

Requisitos de la documentacin Responsabilidad de la Direccin Gestin de Recursos Realizacin del producto Mediciones y anlisis de mejora

Dentro de los requisitos de la documentacin nos podemos encontrar con ciertos factores que contribuyen a la obtencin de estos requisitos los cuales se dividen en dos y son: Requisitos generales Requisitos de la Documentacin

Verificar que los procesos definidos para la gestin de calidad se estn llevando a cabo y en forma. Otra de las cosas que la organizacin debe hacer es determinar la secuencia e interaccin de los procesos antes mencionados, lo cual quiere decir que se deben establecer estrategias y guas para el seguimiento de estos procesos. La organizacin debe Determinar los criterios y mtodos para asegurar que la operacin y el control de estos procesos sea eficaz: establecer ciertas metodologas para la correcta verificacin y gestin de las estrategias. Se debe asegurar de que la disponibilidad de los recursos e informacin necesarios para a poyar la operacin y el seguimiento de los procesos: Organizar los recursos de manera efectiva, tomando en cuenta de que para el seguimiento de los procesos existirn ciertos factores no planeados que se pueden presentar y para los cuales se debe tener un plan de contingencia. Realizar el seguimiento de, la medicin y el anlisis de esos procesos: Utilizar una herramienta de medicin para que no existan fallas en las mediciones. Implementar acciones necesarias para alcanzar los resultados planificados y la mejora continua de estos procesos. Otro de los requisitos que se tienen que tomar en cuenta es la responsabilidad de la direccin, en este caso la direccin debe de tener compromiso con el sistema de gestin de calidad y su mejora contina. Dentro de este requisito se mencionan ciertas fases las cuales son: Enfoque al cliente Poltica de calidad Planificacin Compromiso de la direccin Responsabilidad, autoridad y comunicacin Revisin por la direccin

194

CALIDAD DE SOFTWARE

Enfoque al cliente: Dentro de este enfoque se presentan cuestiones como asegurarse de que se cuenta con un enfoque al cliente, muchas veces se cuenta con enfoques hacia productos y procesos ms sin embargo se deja de lado el enfoque al cliente y es de eso a lo que se refiere este punto. Se debe de implementar un sper operador. Nos debemos de asegurar de que comprendemos las necesidades del cliente, en ocasiones intentamos comprender cosas que no son de nuestro mbito y a causa de nuestro ego no entendemos bien los requerimientos o los mal interpretamos, debemos asegurarnos de que los requerimientos son entendidos de acuerdo a como el cliente los necesita y en caso de estar mal de plantearle una alternativa a sus necesidades. Planificacin: La planificacin se destaca por dividirse en dos fases las cuales son: Objetivos de la calidad Planificacin del sistema de Gestin de calidad Los objetivos de la calidad nos dice de que la direccin se debe plantar objetivos que sean medibles, este es un grave problema en la actualidad , la implantacin de objetivos, a menudo planteamos objetivos que no son medibles como por ejemplo la satisfaccin, como se puede medir la satisfaccin de una persona?, acaso existe alguna unidad numrica para ello?, es por eso que se debe de tener cuidado en cuanto a la implantacin de los objetivos, adems de ello debemos de asegurarnos de que los objetivos coinciden con la poltica de calidad, como se veran nuestros objetivos contradiciendo la poltica de calidad de la empresa ?, eso en realidad sera desastroso, se debe de tener cuidado en ese aspecto. Planificacin del sistema de gestin de calidad: En esta seccin solo se especifica que la direccin debe de asegurarse de que el sistema de gestin de calidad se implemente, si es que se planean cambios al sistema de gestin de calidad y se debe de asegurar por ultimo de que el proceso de transicin que el producto debe de pasar de realice de manera correcta y de acuerdo a lo planeado, no se debe de salir de la planeacin ni de juzgar subjetivamente las actividades a realizar. Compromiso de la direccin: Dentro del compromiso de la direccin existen ciertos lineamientos que debemos de seguir, entre ellos destacan: Comunicacin de la importancia del cumplimiento de los requisitos, Establecimiento de la poltica de calidad antes mencionada, establecimiento de los objetivos de calidad en base a la poltica de calidad, revisar el sistema de calidad y proporcionar los recursos adecuados antes durante y despus del proceso. Responsabilidad, autoridad y comunicacin: Estos requerimientos se dividen en dos que son: Responsabilidad y autoridad Representante de la direccin Comunicacin interna

195

CALIDAD DE SOFTWARE

Durante la responsabilidad y autoridad se siguen ciertos puntos que se tiene que tener muy en cuenta durante el desarrollo de estos requerimientos, la autoridad debe de asegurarse de que las autoridades correspondientes deben de ser seleccionadas y notificadas con anterioridad. Representante de la direccin: La alta direccin debe definir un representante del sistema de gestin de calidad con responsabilidad y autoridad para mantener informada a la direccin, asegurar que se implemente el sistema de gestin de calidad, asegurar que se tiene el enfoque al cliente en todos los niveles de la organizacin. Comunicacin interna: La direccin se debe de asegurar de que exista buena comunicacin dentro de la organizacin, ya que de va a auditar que los procesos de comunicacin estn bien definidos, por ejemplo que se envi informacin y que se notifique su recepcin as como el estado en el que la informacin llego. Revisin por la direccin: Este tipo de requerimiento se divide en tres fases o partes las cuales son: Generalidades Entradas para la revisin Salidas de la revisin

En las Generalidades: Se deben llevar acabo revisiones durante ciertos intervalos, ya que se pueden auditar estas actividades, durante las generalidades se debe de Asegurar la continua consistencia adecuacin y efectividad del SGC ( sistema de gestin de la calidad ), tambin se deben de Visualizar oportunidades para mejora, Determinar la necesidad de cambios, Revisar la poltica de Calidad, Monitorear los objetivos, aparte de estas actividades se deben de generar registros y reportes de las mismas , ayudando de este modo a la toma de dediciones y de datos histricos. Entradas para la revisin: En este apartado es donde se obtiene la informacin que va a ser usada en la revisin de la alta direccin, dentro de esta informacin se encuentran los resultados de las auditorias, la retroalimentacin de los clientes, desempeo de los procesos y la conformidad del producto, situacin de las acciones correctivas y preventivas, se deben de tomar en cuenta tambin los Seguimientos de las acciones derivadas de las revisiones anteriores de la direccin, los Cambios planeados que podran afectar al Sistema de Gestin de la Calidad y sobre todo las recomendaciones de mejora aportadas. Salidas de la revisin: Para que las dediciones de la direccin sean satisfactorias se debe analizar la mejora del sistema de gestin de calidad y sus procesos as como la mejora del producto en relacin con los requerimientos del cliente y las necesidades de los recursos. Uno ms de los requisitos que se deben de considerar y cumplir para la certificacin es la gestin de recursos, en esta fase solo debemos de tomar en cuenta las provisiones de los

196

CALIDAD DE SOFTWARE

recursos, si es que los tenemos disponibles, si necesitamos conseguir alguno, si es as en donde etc. Es necesario tambin analizar el factor de los recursos humanos , se tienen que contemplar todas las personas que participaran en tal proyecto, en que fechas , con que disponibilidad etc., Despus de esto se tiene que analizar la infraestructura, cerciorarnos de que contamos con los suficientes recursos, el ambiente de trabajo tambin juega un papel importante dentro de estos requerimientos y ms que nada solicitar los recursos necesarios para que las operaciones que se realicen sean de calidad y de esta forma lograr de una forma ms satisfactoria la apreciacin del cliente. Realizacin del producto: En este aspecto solo debemos considerar ciertos aspectos que se deben de tomar en cuenta para la gestin de los sistemas de gestin de calidad los cuales son: Planificacin de la realizacin del producto Procesos relacionados con los clientes Diseo y desarrollo Compras Presentacin del servicio Control de equipos Por ltimo llegamos a la ultima especificacin de requerimientos la cual es la medicin y el anlisis de mejora, ms que nada este requerimiento trata de que se deben establecer procesos de inspeccin y de supervisin para demostrar de este modo que se est conforme con el servicio de gestin de calidad y de mejora continua, consta de cinco fases que son Generalidades Supervisin y medicin Control de servicios no conforme Anlisis de datos Mejora Durante las generalidades lo que vamos a hacer es demostrar la conformidad del producto, asegurarnos de la conformidad del sistema de gestin de calidad y si es as mejorar continuamente la eficacia del sistema. En la fase de supervisin y medicin, tenemos que cerciorarnos de la satisfaccin del cliente, realizar auditoras internas, debemos de supervisar los procesos continuamente, as como inspeccionar el servicio. En caso de que existen inconformidades con el sistema de gestin de calidad se deben de analizar los datos y de tomar una decisin conforme a los resultados obtenidos. Por ltimo se busca como siempre la mejora continua de los procesos, sin duda la etapa ms difcil de sostener, incluyendo acciones correctivas y preventivas. El cumplimiento de normas es mucho mas aprovechable, cuando hay procesos bien conocidos y repetibles, y los mismos pueden medirse y optimizarse.

197

CALIDAD DE SOFTWARE

Es dificil establecer procesos repetibles para la innovacin, pues si se tuvieran, no se estara haciendo algo realmente nuevo. Por eso es bueno, que este proceso dentro del manual de calidad, tenga gran libertad de accin (o sea poco detalle de como se realiza) y recien introducir estas mejoras al proceso ms controlado, cuando ya se haya comprobado su eficacia. Por lo tanto, la certificacin bajo la norma ISO 9001:2000 es muy buena para lo que es captura de requerimientos, analisis, programacin, atencin al cliente, documentacion e instalacin, pues es algo que la empresa debe hacer en forma controlada y repetible. [22]

Figura 59. ISO 9001:2000

Como conclusin, se puede decir que existen una serie metodologas a seguir para evitar los costos excesivos que se obtienen con la mala calidad del software, segn lo analizado en este documento se nos hizo mencin de que en la actualidad ya existen modelos para combatir la globalizacin como son el PEF de planeacin , evaluacin y fallas , el cual nos sirve para reducir o minimizar los costos de la calidad del software, siguiendo una serie de pasos que al final nos dar ese resultado satisfactorio, este modelo no solo se puede aplicar al software sino que se puede aplicar donde quiera que se quieran reducir los costos de la calidad de un producto, se nos explica cmo es que se deben de sacrificar ciertas cosas para su obtencin , como es invertir ms capital, ya que mayor calidad implica mayor inversin, por otro lado , ya en un contexto un poco mas organizacional y global , nos topamos con ISO 9001:2000, que viene a ser un modelo en el que las organizaciones encontraron las respuestas a un sistema de gestin ms slido , ISO 9001 en su versin 2000 resulta ser una de las mas revolucionarias herramientas para incrementar la competitividad en el mercado internacionalmente hablando , ya que las mtricas que se manejan son de nivel internacional, en fin se conoci un poco ms acerca de estos trminos as como su implementacin y procedencia.

4.6 LA NORMA ISO/IEC 9126

198

CALIDAD DE SOFTWARE

El ISO/IEC 9126 es un estndar para llevar a cabo la evaluacin del software, enfocndose a la calidad del mismo, este estndar se inspiro en el modelo de McCall el cual fue establecido en el ao de 1977. El objetivo fundamental de esta norma tiene por objeto abordar algunos de los sesgos conocidos humanos que pueden afectar negativamente a la entrega y la percepcin de un proyecto de desarrollo de software. Estas tendencias incluyen el cambio de prioridades despus del inicio de un proyecto o no tener una definicin clara de "xito". [23] Este estndar se basa en tres modelos de calidad: Factores de Calidad Criterios de calidad del Producto Mtricas del Producto

El modelo de factores lo que hace es una especificacin describiendo la visn que tienen los usuarios acerca del software. El modelo de criterios se enfoca a como es visto internamente el software (por el/los desarrollador(es)). El modelo de mtricas lo que logra es proveer un control y un mtodo acerca de la medida del software. El ISO/IEC 9126 est dividido en cuatro partes: Parte 1: Modelo de Calidad. Parte 2: Mtricas externas. Parte 3: Mtricas internas. Parte 4: Calidad en el uso de mtricas.

El Modelo de Calidad se basa en la calidad interna y externa, as como en la calidad de uso, donde una depende de la otra para as lograr a la vez calidad en el producto. La calidad interna est comprendida de las caractersticas del software desde un punto de vista interno y la calidad externa comprende de las caractersticas del software desde un punto de vista externo. Las caractersticas que definen las vistas interna y externa, se muestran a continuacin en la Figura y son:

199

CALIDAD DE SOFTWARE

Figura 60. Modelo de Calidad

La calidad en el uso est definida por la norma como la calidad del software que posibilita la obtencin de objetivos especficos con la efectividad, productividad, satisfaccin y seguridad. El modelo de calidad define atributos de calidad del software por medio de sus caractersticas (6 caractersticas) y sus respectivas sub-caractersticas, las cuales logran la calidad en un producto de software: La primera caracterstica es la Funcionalidad la cual es la capacidad del software para proporcionar funciones que satisfagan las necesidades especificadas; esta se divide en cuatro sub-caractersticas, las cuales son las siguientes: Adecuacin: Facilidad para brindar funciones para la realizacin de tareas especificas. Exactitud: Busca brindar resultados correctos. Interoperabilidad: Lograr la interaccin con uno o ms sistemas. Seguridad: Proteccin de informacin y de datos.

La segunda caracterstica es la Fiabilidad que es la capacidad del software para mantener un nivel especfico de rendimiento del mismo, esta caracterstica cuenta con tres subcaractersticas: Madurez: Que el software evite fallos por errores en el. Tolerancia a fallos: Que el software tenga un nivel de rendimiento en caso de que este cuente con defectos. Recuperabilidad: Recuperacin de datos afectados en caso de que ocurra algn fallo en el software.

200

CALIDAD DE SOFTWARE

La tercera caracterstica es la Usabilidad que consiste en la capacidad del software de ser entendido, aprendido, usado por el usuario; esta caracterstica cuenta con 4 sub-caractersticas: Comprensibilidad: Permitir la usuario saber si el software es el adecuado y como es que este se debe de utilizar. Facilidad de aprendizaje: Permitir al usuario aprender su aplicacin. Operabilidad: Permitir al usuario operar y controlar el software. Atraccin: Atraccin al usuario hacia el software, ose que se al usuario se le haga interesante y a su vez atractivo el manejo del software. La cuarta caracterstica es la Eficiencia la cual consiste en la capacidad con que cuenta el software para lograr un rendimiento adecuado. Cuenta con dos sub-caractersticas: Comportamiento en el tiempo: El tiempo de respuesta y procesamiento de funciones sea el adecuado. Comportamiento de recursos: La utilizacin de cantidades y tipos de recursos al realizar las funciones sea el adecuado. La quinta caracterstica es, la Mantenibilidad la cual es la capacidad del software para ser modificado, ya sea corregido o bien que este sea mejorado; esta caracterstica cuenta con cuatro sub-caractersticas: Facilidad de anlisis: Facilidad para lograr diagnosticar las deficiencias del software o el por qu de los fallos o identificar la partes a modificar. Facilidad de cambio: Implementacin de ciertas modificaciones en el software (diseo, cdigo y la documentacin). Estabilidad: Cuando el software es capaz de evitar defectos inesperados de modificaciones. Facilidad de pruebas: Cuando el software permite validar las partes modificadas. La sexta y ltima caracterstica es la Portabilidad que consiste en la, capacidad del software para ser transferido de un entorno a otro, esta caracterstica cuenta con cuatro subcaractersticas: Facilidad de instalacin: Facilidad para lograr una adecuada instalacin del software en algn ambiente determinado. Reemplazamiento: Utilizacin del software en lugar de otro con la misma finalidad. Adaptabilidad: Que el software tenga la capacidad para ser adaptado en ciertos ambientes sin realizar acciones ms que las requeridas. Coexistencia: Lograr coexistencia con software independiente compartiendo recursos a la vez. Cabe destacar que cada una de las caractersticas mencionadas anteriormente cuentan con una sub-caracterstica en particular: Cumplimiento de normas en donde de cierta forma se verifica que se cumpla con las normas impuestas para el software. Las Mtricas Externas son necesarias para medir con respecto a las caractersticas y subcaractersticas agrupadas en la parte 1, estas mtricas son aplicables al software en ejecucin. Las Mtricas Internas miden el comportamiento del software en la etapa del diseo as como en la etapa de codificacin.

201

CALIDAD DE SOFTWARE

CARACTERISTICAS Y ATRIBUTOS. Las caractersticas en las que la norma ISO 9126 descompone la calidad son influidas por atributos internos y externos propios de dichas caractersticas. Los atributos internos son indicadores de los atributos externos. Un atributo interno puede influir a una o ms caractersticas y una caracterstica puede verse influida por uno o ms atributos. Las caractersticas y subcaractersticas son medidas, por tanto, a travs de sus correspondientes atributos. De nuevo tenemos un paralelismo con la propuesta de Fenton en la que se propona la medida de entidades propias del sw. a travs de la cuantificacin de sus atributos, tambin identificados como internos y externos. La norma define las mtricas internas como aquellas medidas que se realizan sobre un producto sw. no ejecutable, tal como la norma indica un producto sw. Intermedio debera ser evaluado usando mtricas internas. Las mtricas externas son medidas del producto sw. Obtenidas del comportamiento del sistema en la fase de ejecucin del mismo. Las mtricas de la calidad del uso, como tercer gran concepto propuesto por la norma, miden la extensin en la que un producto alcanza las necesidades expuestas por el usuario de forma especfica en relacin a los objetivos de efectividad, seguridad, productividad y satisfaccin. [24]

La Calidad en el uso de las mtricas se debe de verificar o corroborar que el software es efectivo, productivo, satisfactorio y que cuente con seguridad fsica. La efectividad del software es cuando el usuario logra alcanzar los objetivos y las expectativas de una forma exacta y completa. La seguridad fsica busca alcanzar niveles de riesgo hacia el negocio, software, propiedades o bien hacia el medio ambiente. En s, de una manera general lo que busca ISO/IEC 9126 es el lograr la calidad del software mediante la aplicacin de mtricas verificando que se cumplan ciertas caractersticas y subcaractersticas.

202

CALIDAD DE SOFTWARE

4.7 ANLISIS DE FACTORES QUE DETERMINAN LA CALIDAD DEL SOFTWARE. Los factores para lograr la determinacin de la calidad del software se pueden dividir en dos: Factores que se pueden medir directamente. Cuando hablamos de los factores que se pueden medir directamente hacemos un enfoque hacia los defectos medibles tales los errores o como unidad de tiempo. Factores que se pueden medir solo indirectamente. Con respecto a los factores que son medibles indirectamente se refiere como por ejemplo a la facilidad del uso del mantenimiento. Segn McCall los factores que determinan localidad del software los podemos dividir en tres:

Figura 61: Modelo MacCall

1. Caractersticas operativas del software. Las caractersticas operativas del software consisten en hacer un enfoque sobre lo que hace el software, como lo hace, si es que lo que hace es confiable y si este es fcil de manejar (CORRECCIN, FIABILIDAD, EFICIENCIA, SEGURIDAD Y USABILIDAD). Estas caractersticas nos son de una gran ayuda ya que de esta forma nos damos cuenta si el software cumple con las expectativas esperadas en cuanto al uso al que este est dirigido. La caracterstica de CORRECCIN nos indica si el software hacerlo esperado y logra los objetivos requeridos. La caracterstica de FIABILIDAD es cuando el software lleva a cabo el desarrollo de su funcin durante todo el tiempo. La caracterstica de EFICIENCIA indica si el software esta desarrollado de tal forma que este realice su funcin designada.

203

CALIDAD DE SOFTWARE

La caracterstica de SEGURIDAD se refiere a poder llevar el control tanto del software como de los datos. La caracterstica de USABILIDAD hace un gran enfoque hacia la manejabilidad del software por el usuario, ose que el software cumpla las expectativas para lo cual fue creado.

2. Caractersticas del soporte al cambio. Las caractersticas de soporte al cambio (soportar cambios) se refieren hacia el mantenimiento, las pruebas y cambios que se le puedan realizar al software (FACILIDAD DE MANTENIMIENTO, FLEXIBILIDAD Y FACILIDAD DE PRUEBA). En donde la facilidad del mantenimiento nos sirve para hacernos una pregunta: Puedo corregirlo?, en este se trata de lograr la localizacin y el arreglo de errores. La flexibilidad se enfoca hacia el cambio en donde nos hacemos una pregunta: puedo cambiarlo? Con respecto a la facilidad de prueba no hay mucho que explicar ya esto se entiende como el esfuerzo para asegurarnos que el programa realiza su tarea especificada. 3. Caractersticas de adaptabilidad a nuevos cambios. Las caractersticas de adaptabilidad a nuevos cambios se refiere a la utilizacin del software ya ese en algn tipo de hardware, la reutilizacin del software o bien a la interaccin del software con otros sistemas (PORTABILIDAD, REUSABILIDAD, INTEROPERABILIDAD). La PORTABILIDAD se refiere a que el sistema pueda ser ejecutado en cualquier equipo de cmputo o en cualquier ambiente. La REUSABILIDAD se refiere a la reutilizacin de software o bloques de cdigo que ya fue creado con anterioridad o bien que el software o bloques de cdigo que se han creado puedan servir posteriormente para volver a ser reutilizados en la elaboracin de otro software. La INTEROPERABILIDAD consiste en lograr que el software creado sea capaz de acoplarse con algn sistema ya existente y/o de cierta forma lograr que uno necesite del otro para lograr su debida funcionalidad. Estas caractersticas nos son de gran ayuda para poder verificar que el software cumple con la calidad deseada, e identificar en que campos se ha fallado y ha repercutido para lograr la obtencin de la calidad. Aparte de los factores mencionados anteriormente no cabe el descartar otros factores que tambin son determinantes para la calidad del software: factores del problema, factores humanos, factores del proceso, factores del producto y factores del recurso. Estos factores aunque no parecen muy importantes es de gran importancia tenerlos en cuenta por muy mnimos que estos parezcan, por ejemplo el factor humano es de gran importancia ya que lo que puede influir en este puede ser la experiencia; el factor del proceso es uno de los factores que ms se debera de resaltar ya que en este influye el diseo y el proceso que se

204

CALIDAD DE SOFTWARE

utiliza, ya que para un exitoso software con calidad comienza desde el diseo de este como base. Segn Barry Bohem creador del modelo Boehm (modelo de calidad), el cual hace uso de caractersticas de alto nivel, niveles intermedios y primitivos en donde cada una de ellas contribuye a la calidad. Las caractersticas de alto nivel representan requerimientos generales de uso tales como: Utilidad per-se: Est es para ver que tan confiable es el producto. Mantenibilidad: Que tan fcil es modificarlo y entenderlo. Utilidad general: Si se puede utilizar en cualquier ambiente que se requiera.

Figura 62: Modelo Boehm

Las caractersticas de nivel intermedio como portabilidad, confiabilidad, eficiencia, usabilidad, fcil entendimiento y flexibilidad representan factores de calidad, que por cierto son muy semejantes a los utilizados por McCall. Y por ltimo el nivel ms bajo (caractersticas primitivas) que est asociado a mtricas de calidad (algunas son manejadas en el mtodo de McCall):

Portabilidad: Que pueda ser ejecutado en cualquier ambiente y/o software.

205

CALIDAD DE SOFTWARE

Confiabilidad: Como su nombre lo dice que sea confiable en las funciones que realiza. Eficiencia: Si realiza las funciones designadas a l. Usabilidad: Entendible, aprendible y empleado por el usuario. Entendibilidad: Que sea fcil de entender y a su vez que sea amigable para el usuario. Modificabilidad: Que pueda ser corregido o bien, mejorado. Testeabilidad: Verificar que se haga lo que se tiene que hacer.

Haciendo una comparacin con estos dos modelos (McCall y Boehm) la nica diferencia es que Boehm presenta mayor cantidad de caractersticas primarias, que al final hay una gran semejanza con el modelo de McCall.

Factores de Calidad segn ISO 9126 Es un modelo jerrquico con seis atributos especiales. La diferencia con McCall y Boehm es que la jerarqua es estricta, es decir, que cada caracterstica de la derecha solo est relacionada con un solo atributo del modelo. Las caractersticas de la derecha se relacionan con la visin del usuario. [25] Funcionalidad Confiabilidad Adaptacin, Exactitud, Interoperacin, Seguridad Madurez, Tolerancia a Defectos, Facilidad de Recuperacin. Comportamiento en el Tiempo, de los Recursos. Facilidad de Comprensin, de Aprendizaje, de Operacin. Facilidad de Anlisis, de Cambios, de Pruebas, Estabilidad. Adaptabilidad, Facilidad de Instalacin, de Reemplazo

Eficiencia Facilidad de Uso

Facilidad de Mantenimiento

Portabilidad

206

CALIDAD DE SOFTWARE

4.8 ANLISIS DEL PROCESO DEL CICLO DE VIDA DEL SOFTWARE. Definicin de un Modelo de Ciclo de Vida. Un modelo de ciclo de vida de software es una visin de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transicin asociadas entre estas etapas. Un modelo de ciclo de vida del software: Describe las fases principales de desarrollo de software. Define las fases primarias esperadas de ser ejecutadas durante esas fases. Ayuda a administrar el progreso del desarrollo, y Provee un espacio de trabajo para la definicin de un detallado proceso de desarrollo de software. As, los modelos por una parte suministran una gua para los ingenieros de software con el fin de ordenar las diversas actividades tcnicas en el proyecto, por otra parte suministran un marco para la administracin del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc. Modelo Cascada. Este es el ms bsico de todos los modelos, y sirve como bloque de construccin para los dems modelos de ciclo de vida. La visin del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a travs de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfaccin de metas de esa fase o quizs a una subsecuencia de metas de la fase. Las flechas muestran el flujo de informacin entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrs representan la retroalimentacin. La metodologa en cascada consiste en:

Anlisis de requisitos Diseo del Sistema Diseo del Programa Codificacin Pruebas Implantacin Mantenimiento [26]

El modelo de ciclo de vida cascada, captura algunos principios bsicos: Planear un proyecto antes de embarcarse en l. Definir el comportamiento externo deseado del sistema antes de disear su arquitectura interna. Documentar los resultados de cada actividad. Disear un sistema antes de codificarlo. Testear un sistema despus de construirlo.

207

CALIDAD DE SOFTWARE

Figura 63: Ciclo de vida en cascada

Algunas de las ventajas de este modelo son: Ventajas:

Se tiene todo bien organizado y no se mezclan las fases. Es perfecto para proyectos que son rgidos, y adems donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar

Desventajas:

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso. El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no est completo no se opera. [26]

Una de las contribuciones ms importantes del modelo cascada es para los administradores, posibilitndoles avanzar en el desarrollo, aunque en una escala muy bruta.

Modelo de Desarrollo Incremental. Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema. Tpicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo. Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma especfica de observar el desarrollo de algn otro incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.

208

CALIDAD DE SOFTWARE

El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos: Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande. Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Si un error importante es realizado, slo la ltima iteracin necesita ser descartada. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. Si un error importante es realizado, el incremento previo puede ser usado. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del prximo incremento. Modelo De Desarrollo Evolutivo. Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximacin incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto. En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementacin parcial del sistema que recibe slo estos requerimientos. El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es actualizada, y una segunda versin del producto es desarrollada y desplegada. El proceso se repite indefinidamente. Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma especfica de observar el desarrollo de algn incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado tambin. Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado. El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentacin debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada. Modelo de Prototipado de Requerimientos. El prototipado de requerimientos es la creacin de una implementacin parcial de un sistema, para el propsito explcito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rpida tal como sea posible. Esto es dado a los usuarios, clientes o

209

CALIDAD DE SOFTWARE

representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentacin sobre lo que a ellos les gust y no les gust acerca del prototipo proporcionado, quienes capturan en la documentacin actual de la especificacin de requerimientos la informacin entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algn o todo el desarrollo incremental en modelos incremental o evolutivo. El Prototipado ha sido usado frecuentemente en los 90, porque la especificacin de requerimientos para sistemas complejos tiende a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho ms fcil proveer retroalimentacin convenientemente basada en la manipulacin, leer una especificacin de requerimientos potencialmente ambigua y extensa. Diferente del modelo evolutivo donde los requerimientos mejor entendidos estn incorporados, un prototipo generalmente se construye con los requerimientos entendidos ms pobremente. En caso que ustedes construyan requerimientos bien entendidos, el cliente podra responder con s, as es, y nada podra ser aprendido de la experiencia. Modelo Espiral. El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1988. El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Adems, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:

1. Determinar qu se quiere lograr. 2. Determinar las rutas alternativas que se pueden tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor. 3. Seguir la alternativa seleccionada en el paso 2. 4. Establecer qu se tiene terminado.

210

CALIDAD DE SOFTWARE

Figura 64: Modelo espiral

Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje al rededor de la espiral, analizamos la situacin y determinamos que los mayores riesgos son la interfaz del usuario. Despus de un cuidadoso anlisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificacin de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de accin es construir un prototipo. Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentacin til. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer slo despus de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximacin es construir un incremento del sistema que satisfaga slo los requerimientos mejor entendidos. Hagmoslo ya. Despus del despliegue, el cliente nos provee de retroalimentacin que dir si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarn en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza. El modelo espiral captura algunos principios bsicos: Decidir qu problema se quiere resolver antes de viajar a resolverlo. Examinar tus mltiples alternativas de accin y elegir una de las ms convenientes. Evaluar qu tienes hecho y qu tienes que haber aprendido despus de hacer algo. No ser tan ingenuo para pensar que el sistema que ests construyendo ser EL sistema que el cliente necesita, y Conocer (comprender) los niveles de riesgo, que tendrs que tolerar.

Modelo Desarrollo por etapas El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultneamente con las diferentes versiones del cdigo. Etapas: Plan operativo Especificacin de requerimientos Especificacin Diseo Implementacin Integracin Validacin y verificacin Mantencin [26]

211

CALIDAD DE SOFTWARE

Modelo Concurrente. Como el modelo espiral, el modelo concurrente provee una meta-descripcin del proceso software. Mientras que la contribucin primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribucin del modelo concurrente es su capacidad de describir las mltiples actividades del software ocurriendo simultneamente. Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algn tiempo del proceso de desarrollo de software. Discutamos un poco tales casos: Los requerimientos son usualmente lneas de base, cuando una mayora de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseo. Sin embargo, una vez que comienza el diseo, cambios a los requerimientos son comunes y frecuentes (despus de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados tambin). Es desaconsejado detener el diseo en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer lneas de base de los requerimientos mientras progresa el diseo. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseo puede no ser afectado, medianamente afectado o se requerir comenzar todo de nuevo. Durante el diseo de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseo detallado en esos componentes estables. Similarmente, durante el diseo detallado, puede ser posible proceder con la codificacin y quizs regular testeando en forma unitaria o realizando testeo de integracin previo a llevar a cabo el diseo detallado de todos los componentes. En algunos proyectos, mltiples etapas de un producto se han desarrollado concurrentemente. Por ejemplo, no es inusual estar haciendo mantencin de la etapa 1 de un producto, y al mismo tiempo estar haciendo mantencin sobre un componente 2, mientras que se est haciendo codificacin sobre un componente 3, mientras se realiza diseo sobre una etapa 4, y especificacin de requisitos sobre un componente 5. En todos estos casos, diversas actividades estn ocurriendo simultneamente. Eligiendo seguir un proyecto usando tcnicas de modelacin concurrente, se posibilita el conocimiento del estado verdadero en el que se encuentra el proyecto.

Seleccionando Modelos de Ciclo de Vida. Los modelos presentados, suministran una gua con el fin de ordenar las diversas actividades tcnicas en el proyecto de desarrollo de software e intentan suministrar un marco para la administracin en el desarrollo y el mantenimiento. Aunque todos ellos son compatibles unos con otros, un proyecto puede decidir cules enfoques son ms tiles en situaciones especiales.

212

CALIDAD DE SOFTWARE

Figura 65: Ciclo de vida del software

Criterios a considerar: Madurez de la aplicacin (relacionado a la probabilidad que muchos requerimientos comenzarn a conocerse slo despus del uso del sistema). Complejidad del problema y de la solucin. Frecuencias y magnitudes esperadas de los cambios de requerimientos. Financiamiento disponible, y su perfil como una funcin del tiempo. Acceso de los desarrolladores a los usuarios. Certeza de requerimientos conocidos. Otros que pueden incluirse: Tolerancia al riesgo. Planes y presupuestos crticos Grado de lentitud de construccin dentro de los planes y presupuestos. Considerando la importancia de la planificacin se recomienda realizar el desarrollo de un proyecto de software bajo el modelo espiral insertando en l, cualquier otro modelo que se requiera dependiendo de las necesidades que se presenten. Este modelo permite realizar una planificacin del proceso de desarrollo del software considerando los riesgos asociados en cada etapa identificada. El identificar los riesgos en proyectos, evaluar su impacto, monitorear y controlar el avance del desarrollo del proyecto, permite al administrador aumentar las posibilidades de xito de un proyecto o, minimizar las posibilidades de fracaso de ste. Uno de los factores que ms influyen en el proceso de desarrollo de software y que prcticamente acompaa a toda aplicacin es el hecho de que en su mayora, no hay forma de

213

CALIDAD DE SOFTWARE

tener todos los requerimientos corregidos antes del desarrollo del software. Muchas veces los requerimientos emergen a medida que la aplicacin o partes de ella estn disponibles para experimentacin prctica. En todos los casos, el trabajo comienza con la determinacin de objetivos, alternativas y restricciones, paso que a veces se llama recoleccin preliminar de requisitos. El prototipado es ampliamente recomendado para realizar la especificacin de requerimientos, se debe notar que la idea del prototipado es capturar por retroalimentacin los objetivos, necesidades y expectativas del cliente por lo cual no se debe caer en una utilizacin de estos prototipos como partes finales del sistema, ya que en su desarrollo generalmente no se consideran aspectos de calidad, ni otros asociados con facilitar la etapa de mantencin del sistema. El prototipo trata de minimizar los cambios en los requerimientos, mientras que el diseo modular (incremental, en funcionalidades) trata de minimizar el impacto de los cambios en los requerimientos. El cambio es una propiedad intrnseca del software. Hoy en da el software debe poseer un enfoque evolutivo, un sistema debe evolucionar para acomodar la naturaleza evolutiva de los grandes sistemas. El software cambia constantemente, debido a la necesidad de reparar el software (eliminando errores no detectados anteriormente) como a la necesidad de apoyar la evolucin de los sistemas a medida que aparecen nuevos requerimientos o cambian los antiguos. Por lo cual es importante enfatizar que no tiene sentido entonces que un proyecto tome estrictamente una decisin concerniente con cual modelo se adherir. Los modelos de ciclo de vida presentados, son complementarios en vez de excluyentes. En muchos casos, los paradigmas pueden y deben combinarse de forma que puedan utilizarse las ventajas de cada uno en un nico proyecto. El paradigma del modelo en espiral lo hace directamente, combinando la creacin de prototipos y algunos elementos del ciclo de vida clsico, en un enfoque evolutivo para la ingeniera de software. No hay necesidad por tanto de ser dogmtico en la eleccin de los paradigmas para la ingeniera de software: la naturaleza de la aplicacin debe dictar el mtodo a elegir.

214

CALIDAD DE SOFTWARE

4.9 FUNCIONES DE EVALUACIN DEL SOFTWARE. Tal como se ha indicado anteriormente, es necesario evaluar el sistema software a medida que se va avanzando en el proceso de desarrollo de dicho sistema. De esta forma se intenta que la deteccin de defectos se haga lo antes posible y tenga menor impacto en el tiempo y esfuerzo de desarrollo. Ahora bien cmo se realiza esta evaluacin? Las tcnicas de evaluacin esttica se aplican en el mismo orden en que se van generando los distintos productos del desarrollo siguiendo una filosofa top-down. Esto es, la evaluacin esttica acompaa a las actividades de desarrollo, a diferencia de la evaluacin dinmica que nicamente puede dar comienzo cuando finaliza la actividad de codificacin, siguiendo as una estrategia botomup. La evaluacin esttica es el nico modo disponible de evaluacin de artefactos para las primeras fases del proceso de desarrollo (anlisis y diseo), cuando no existe cdigo la evaluacin esttica se realiza en el mismo sentido en que se van generando los productos del desarrollo de software, mientras que la dinmica se realiza en sentido inverso.

Figura 66. Abstraccin de la Relacin entre Evaluacin y Proceso Software

La evaluacin esttica (conocida con el nombre genrico de Revisiones) se realiza en paralelo al proceso de construccin, constando de una actividad de evaluacin emparejada con cada actividad de desarrollo. Es decir, la actividad de Definicin de Requisitos de Usuario va acompaada de una actividad de Revisin de Requisitos de Usuario, la actividad de Definicin de Requisitos Software va emparejada con su correspondiente actividad de revisin y as, sucesivamente.

215

CALIDAD DE SOFTWARE

Las actividades de revisin marcan el punto de decisin para el paso a la siguiente actividad de desarrollo. Es decir, la actividad de requisitos interacta con la actividad de revisin de requisitos en un bucle de mejora iterativa hasta el momento en que la calidad de los requisitos permite abordar la subsiguiente fase de desarrollo. Lo mismo ocurre con el diseo arquitectnico: sufrir una mejora iterativa hasta que su nivel de calidad permita pasar al diseo detallado y as, sucesivamente. Ntese que esto tambin ocurre en la fase de codificacin. La actividad siguiente a la de implementacin es la fase de pruebas unitarias. No obstante, antes de pasar a ella, los programas debern evaluarse estticamente. Del mismo modo que se ha hecho con los otros productos.

Figura 67. Modelo en V de Evaluacin de Software

Por tanto, las actividades de evaluacin esttica constituyen los puntos de control o revisin utilizados por los gestores de proyectos y las organizaciones para evaluar tanto la calidad de los productos como el progreso del proyecto. Es decir, las actividades de revisin son una herramienta de control para el producto software.

216

CALIDAD DE SOFTWARE

Una vez realizadas estas revisiones se procede con la evaluacin dinmica, que como ya se ha indicado se realiza sobre el cdigo. Aunque ms adelante se estudiarn en detalle los distintos tipos de pruebas dinmicas, se puede indicar que la primera prueba a realizar es la denominada Prueba de Unidad en la que se buscan errores en los componentes ms pequeos del programa (mdulos). Estos errores se detectan cuando dichos componentes no actan como se ha especificado en el diseo detallado. Seguidamente, se prueban los distintos componentes que constituyen el software en la denominada Prueba de Integracin. Esta prueba est orientada a detectar fallos provocados por una incorrecta (no acorde con la especificacin de diseo de alto nivel) comunicacin entre mdulos. El software se puede ejecutar en un contexto hardware concreto, por lo que la Prueba de Sistema es la que se encarga de buscar errores en este ensamblaje software/hardware. Finalmente, el usuario ha de realizar la Prueba de Aceptacin final sobre el sistema completo. Ntese cmo la evaluacin de los productos software mediante revisiones permite contar con una estimacin temprana de la calidad con que se est llevando a cabo el desarrollo. Esto es as porque las revisiones encuentran faltas, pero la cantidad de faltas encontradas en un producto dan una idea de las faltas que an pueden quedar as como de la calidad del trabajo de desarrollo de dicho producto. La experiencia parece indicar que donde hay un defecto hay otros. Es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al nmero de defectos ya descubiertos. Es en este principio sobre el que se basan los mtodos de estimacin de los defectos que quedan en un software; ya sean los modelos de fiabilidad (que utilizan como entrada los fallos encontrados durante las pruebas) ya sean los mtodos de estimacin del contenido de faltas (que utilizan como entrada las faltas encontradas mediante revisiones). No obstante, es gracias a la evaluacin esttica que se puede realizar esta estimacin de la calidad del software de manera temprana, puesto que los modelos de fiabilidad requieren el cdigo ya desarrollado para dar una indicacin de los posibles fallos que quedan remanentes en dicho cdigo. As pues, la importancia de las tcnicas estticas de evaluacin a la hora de controlar el nivel de calidad con el que se est llevando a cabo el desarrollo es crucial. Los modelos que utilizan los datos de las tcnicas de testing, ayudan a predecir la fiabilidad del software que se est entregando (cuntas fallos quedan en el sistema sin encontrar), pero poco se puede hacer ya, excepto seguir probando el sistema hasta elevar el nivel de fiabilidad del mismo. Sin embargo, la estimacin de faltas que an quedan en un producto utilizando datos de las revisiones permite dos acciones que ayudan a prevenir futuros defectos en el proyecto: Seguir revisando el producto para disminuir el nmero de faltas remanentes. Por tanto esta deteccin temprana previene encontrar estas faltas en estadios ms avanzados del desarrollo. Es decir, la falta que detectemos en los requisitos estaremos evitando contagiarla al diseo y al cdigo. Tomar medidas correctivas del desarrollo si las estimaciones indican que se est llevando a cabo un trabajo pobre. Es decir, si las estimaciones de faltas remanentes indican que un determinado producto contiene ms faltas de las habituales, algo se est haciendo mal (hay problemas en el equipo de desarrollo, algn miembro del equipo tiene problemas que est afectando a su trabajo, hay problemas con las tcnicas que se estn utilizando, quizs el equipo

217

CALIDAD DE SOFTWARE

no las conoce bien, etc.) y deben tomarse acciones que remedien o palien estos problemas antes de que afecten al resultad final del proyecto. Beneficios de las Revisiones La razn para buscar defectos en productos tempranos es porque stos se traducen en defectos en el producto final. Es decir, defectos en los requisitos se traducirn en defectos en el sistema final. Veamos una analoga con la arquitectura de edificios. Si en un plano el color de una lnea indica su significado, una confusin en el color se traducir en un error en el edificio. Por ejemplo, si el azul indica tuberas de agua y el amarillo cables elctricos y el arquitecto comete un error usando el azul en una conduccin elctrica, los electricistas que usen el plano como gua para su trabajo no colocarn cables elctricos mientras que los fontaneros colocarn tuberas de agua donde no deban ir. El plano de un edificio es el artefacto equivalente al diseo de un producto software. Si un diseo contiene defectos, seguramente estos defectos se trasmitirn al cdigo cuando los programadores usen ese diseo como gua para su trabajo. La deteccin temprana de errores acarrea grandes beneficios. Si las revisiones nicamente se aplican al cdigo mejoran la calidad y producen ahorros en los costos del proyecto. Pero los ahorros son mayores si se inspeccionan artefactos tempranos del desarrollo. Estudiando los resultados publicados sobre ahorros con las revisiones, puede afirmarse que la utilizacin de inspecciones de cdigo produce un ahorro del 39% sobre el coste de detectar y corregir defectos, frente a nicamente utilizar la evaluacin dinmica. Sin embargo, el ahorro es del 44% si se inspecciona tambin el diseo. La experiencia demuestra que entre el 30% y el 70% de los defectos, de diseo y cdigo son detectados por las tcnicas estticas. Esto supone un gran ahorro, pues la correccin es ms fcil y menos costosa durante la evaluacin esttica que durante la dinmica. Ntese que cuando durante la evaluacin dinmica del sistema se detecta un fallo en un programa, lo que se detecta es el fallo, no la falta que lo provoca. Es decir, tras la deteccin del fallo, se requiere una labor de localizacin en el programa de la falta que provoc el fallo. Sin embargo, con las tcnicas estticas, lo que se detecta son directamente faltas. Por tanto, una vez detectada, se puede pasar a la fase de correccin. Es decir, desaparece la tarea de localizacin de la falta. Esto significa, que las tcnicas estticas son ms baratas por falta que las dinmicas. Las revisiones tambin proporcionan beneficios ms generales. Entre stos se pueden citar ests: o Evaluacin del progreso del proyecto. o Potencia las capacidades de los participantes. o Mejoran la comunicacin entre el equipo de desarrollo, aumentando su motivacin, pues los productos pasan a ser documentos pblicos. o Proporciona aprendizaje, retroalimentacin y prevencin. o Forma y educa a los participantes

218

CALIDAD DE SOFTWARE

En el caso concreto de las revisiones de cdigo, stas, adems, permiten localizar secciones crticas, lo que permitir dedicar un mayor esfuerzo a ellas en la fase de pruebas. Objetivos de la Evaluacin Esttica La evaluacin esttica de los distintos artefactos o productos que se generan en el desarrollo de software (especificacin de requisitos, modelos conceptuales, diseo, cdigo, etc.) pretende comprobar su calidad. La calidad significa una cosa distinta para cada producto, precisamente porque son artefactos distintos. Del mismo modo que la calidad de un plano y la calidad de una casa significa cosas distintas. En un plano de un futuro edificio se desea que sea claro (se entienda suficientemente bien como para servir de gua a la construccin del edificio), que sea correcto (por ejemplo, que las lneas que identifican paredes indiquen, a escala, efectivamente el lugar donde se desea que vayan las paredes), que no tenga inconsistencias (por ejemplo, entre las distintas hojas que forman el plano; si una pgina se focaliza, digamos, en una habitacin que en otra pgina apareca slo sus cuatro paredes, que las medidas de las lneas en ambas pginas se correspondan con la misma medida de la realidad), etc.. Sin embargo, de una casa se espera que sea robusta (por ejemplo, que no se caiga), usable (por ejemplo, que los peldaos de las escaleras no sean tan estrechos que provoquen cadas) etc. Por tanto, cuando se est evaluando estticamente un producto software, es importante que el evaluador tenga en mente qu tipo de defectos est buscando y cul sera un producto de ese tipo de calidad adecuada. Digamos que si uno no sabe lo que busca (por ejemplo, inconsistencias al revisar la calidad de un plano) es difcil que lo encuentre, aunque lo tenga delante. Los defectos que se buscan al evaluar estticamente los productos software son: a) Para los requisitos: Correccin. Los requisitos especifican correctamente lo que el sistema debe hacer. Es decir, un requisito incorrecto es un requisito que no cumple bien su funcin. Puesto que la funcin de un requisito es indicar qu debe hacer el sistema, un requisito incorrecto ser aquel que, o bien pide que el sistema haga algo que no es lo que debe hacer, o pide que haga algo que no deba hacer. Complecin. Especificacin completamente el problema. Est especificado todo lo que tiene que hacer el sistema y no incluye nada que el sistema no deba hacer. En dos palabras: no falta nada; no sobra nada Consistencia. No hay requisitos contradictorios. oAmbigedad. Los requisitos no pueden estar sujetos a interpretacin. Si fuese as, un mismo requisito puede ser interpretado de modo distinto por dos personas diferentes y, por tanto, crear dos sistemas distintos. Si esto es as, los requisitos pierden su valor pues dejan de cumplir su funcin (indicar qu debe hacer el sistema). Las ambigedades provocan interpretacin por parte de la persona que use o lea los requisitos. Por tanto, una especificacin debe carecer de ambigedades. Claridad. Se entiende claramente lo que est especificado.

b) Para el diseo:

219

CALIDAD DE SOFTWARE

Correccin. El diseo no debe contener errores. Los errores de correccin se pueden referir a dos aspectos. Defectos de escritura, es decir, defectos en el uso de la notacin de diseo empleada (el diseo contiene detalles prohibidos por la notacin). Defectos con respecto a los requisitos: el diseo no realiza lo que el requisito establece. Hablando apropiadamente, los primeros son los puros defectos de correccin, mientras que los segundos son defectos de validez. Complecin. El diseo debe estar completo. Ya sea que disea todo el sistema marcado por los requisitos; ya sea no diseando ninguna parte no indicada en los requisitos. De nuevo, nada falta, nada sobra. Consistencia. Al igual que en los requisitos, el diseo debe ser consistente entre todas sus partes. No puede indicarse algo en una parte del diseo, y lo contrario en otra. Factibilidad. El diseo debe ser realizable. Debe poderse implementar. Trazabilidad. Se debe poder navegar desde un requisito hasta el fragmento de diseo donde ste se encuentra representado.

c) Cdigo Fuente: Correccin. El cdigo no debe contener errores. Los errores de correccin se pueden referir a dos aspectos. Defectos de escritura, es decir, lo que habitualmente se conoce por programa que no funciona. Por ejemplo, bucles infinitos, variable definida de un tipo pero utilizada de otro, contador que se sale de las dimensiones de un array, etc. Defectos con respecto al diseo: el diseo no realiza lo que el diseo establece.

De nuevo, hablando apropiadamente, los primeros son los puros defectos de correccin, mientras que los segundos son defectos de validez. Un defecto de correccin es un cdigo que est mal para cualquier dominio. Un defecto de validez es un cdigo que, en este dominio particular (el marcado por esta necesidad de usuario, estos requisitos, y este diseo) hace algo inapropiado. Por ejemplo, define una variable de un tipo (y se usa en el programa con ese tipo, es decir, a primera vista no hay nada incorrecto en la definicin del tipo y su uso) que no es la que corresponde con el problema; o define un array de un tamao que no es el que se corresponde con el problema. Ntese que para detectar los errores de validez (en cualquier producto) debe entenderse el problema que se pretende resolver, mientras que los defectos de correccin son errores siempre, an sin conocer el problema que se pretende resolver. Complecin. El cdigo debe estar completo. Una vez ms, nada falta ni nada sobra (con respecto, en este caso, al diseo). Consistencia. Al igual que en los requisitos y diseo, el cdigo debe ser consistente entre todas sus partes. No puede hacerse algo en una parte del cdigo, y lo contrario en otra. Trazabilidad. Se debe poder navegar desde un requisito hasta el fragmento de cdigo donde ste se ejecute, pasando por el fragmento de diseo.

220

CALIDAD DE SOFTWARE

Tcnicas de Evaluacin Esttica Las tcnicas de Evaluacin esttica de artefactos del desarrollo se las conoce de modo genrico por Revisiones. Las revisiones pretenden detectar manualmente defectos en cualquier producto del desarrollo. Por manualmente queremos decir que el producto en cuestin (sea requisito, diseo, cdigo, etc.) est impreso en papel y los revisores estn analizando ese producto mediante la lectura del mismo, sin ejecutarlo. Existen varios tipos de revisiones, dependiendo de qu se busca y cmo se analiza ese producto. Podemos distinguir entre: Revisiones informales, tambin llamadas inadecuadamente slo Revisiones (lo cual genera confusin con el nombre genrico de todas estas tcnicas). Las Revisiones Informales no dejan de ser un intercambio de opiniones entre los participantes. Revisiones formales o Inspecciones. En las Revisiones Formales, los participantes son responsables de la fiabilidad de la evaluacin, y generan un informe que refleja el acto de la revisin. Por tanto, slo consideramos aqu como tcnica de evaluacin las revisiones formales, puesto que las informales podemos considerarlas un antepasado poco evolucionado de esta misma tcnica. Walkthrough. Es una revisin que consiste en simular la ejecucin de casos de prueba para el programa que se est evaluando. No existe traduccin exacta en espaol y a menudo se usa el trmino en ingles. Quizs la mejor traduccin porque ilustra muy bien la idea es Recorrido. De hecho, con los walkthrough se recorre el programa imitando lo que hara la computadora. Auditorias. Las auditorias contrastan los artefactos generados durante el desarrollo con estndares, generales o de la organizacin. Tpicamente pretenden comprobar formatos de documentos, inclusin de toda la informacin necesaria, etc. Es decir, no se tratan de comprobaciones tcnicas, sino de gestin o administracin del proyecto. Inspecciones Las inspecciones de software son un mtodo de anlisis esttico para verificar y validar un producto software manualmente. Los trminos Inspecciones y Revisiones se emplean a menudo como sinnimos. Sin embargo, como ya se ha visto, este uso intercambiable no es correcto.

221

CALIDAD DE SOFTWARE

Las Inspecciones son un proceso bien definido y disciplinado donde un equipo de personas cualificadas analiza un producto software usando una tcnica de lectura con el propsito de detectar defectos. El objetivo principal de una inspeccin es detectar faltas antes de que la fase de prueba comience. Cualquier desviacin de una propiedad de calidad predefinida es considerada un defecto. Para aprender a realizar inspecciones vamos a estudiar primero el proceso que debe seguirse y luego las tcnicas de lectura. El Proceso de Inspeccin Las Inspecciones constan de dos partes: Primero, la comprensin del artefacto que se inspecciona; Y en segundo lugar, la bsqueda de faltas en dicho artefacto. Ms concretamente, una inspeccin tiene cuatro fases principales: 1. Inicio El objetivo es preparar la inspeccin y proporcionar la informacin que se necesita sobre el artefacto para realizar la inspeccin. 2. Deteccin de defectos Cada miembro del equipo realiza individualmente la lectura del materia, compresin del artefacto a revisar y la deteccin de faltas. Las Tcnicas de Lectura ayudan en esta etapa al inspector tanto a comprender el artefacto como a detectar faltas. Basndose en las faltas detectadas cada miembro debe realizar una estimacin subjetiva del nmero de faltas remanentes en el artefacto. 3. Coleccin de defectos El registro de las faltas encontrada por cada miembro del equipo es compilado en un solo documento que servir de basa a la discusin sobre faltas que se realizar en grupo. Utilizando como base las faltas comunes encontradas por los distintos inspectores se puede realizar una estimacin objetiva del nmero de faltas remanentes. En la reunin se discutir si las faltas detectadas son falsos positivos (faltas que algn inspector cree que son defectos pero que en realidad no lo son) y se intentar encontrar ms faltas ayudados por la sinergia del grupo.

222

CALIDAD DE SOFTWARE

4. Correccin y seguimiento El autor del artefacto inspeccionado debe corregir las faltas encontradas e informar de las correcciones realizadas a modo de seguimiento. Estas fases se subdividen adems en varias subfases: 1. Inicio 1.1 Planificacin 1.2 Lanzamiento 2. Deteccin de defectos 3. Coleccin de defectos 3.1 Compilacin 3.2 Inspeccin en grupo 4. Correccin y seguimiento 4.1 Correccin 4.2 Seguimiento Veamos cada una de estas fases; Durante La Planificacin se deben seleccionar los participantes, asignarles roles, preparar un calendario para la reunin y distribuir el material a inspeccionar. Tpicamente suele haber una persona en la organizacin o en el proyecto que es responsable de planificar todas las actividades de inspeccin, aunque luego juegue adems otros papeles. Los papeles que existen en una inspeccin son: Organizador. El organizador planifica las actividades de inspeccin en un proyecto, o incluso en varios proyectos (o entre proyectos, porque se intercambian participantes: los desarrollados de uno son inspectores de otro). Moderador. El moderador debe garantizar que se sigan los procedimientos de la inspeccin as como que los miembros del equipo cumplan sus responsabilidades. Adems, modera las reuniones, lo que significa que el xito de la reunin depende de esta persona y, por tanto, debe actuar como lder de la inspeccin. Es aconsejable que la persona que juegue este rol haya seguido cursos de manejo de reuniones y liderazgo. Inspector. Los inspectores son los responsables de detectar defectos en el producto software bajo inspeccin. Habitualmente, todos los participantes en una inspeccin actan tambin como inspectores, independientemente de que, adems, jueguen algn otro papel. Lector/Presentador. Durante la reunin para la inspeccin en grupo, el lector dirigir al equipo a travs del material de modo completo y lgico. El material debe ser parafraseado a una velocidad que permita su examen detallado al resto de los participantes. Parafrasear el material significa que el lector debe explicar e interpretar el producto en lugar de leerlo literalmente. Autor. El autor es la persona que ha desarrollado el producto que se est inspeccionando y es el responsable de la correccin de los defectos durante la fase de correccin. Durante la reunin, el autor contesta a las preguntas que el lector no es capaz de responder. El autor no debe actuar al mismo tiempo ni de moderador, ni de lector, ni de escriba. Escriba. El secretario o escriba es responsable de incorporar todos los defectos en una lista de defectos durante la reunin.

223

CALIDAD DE SOFTWARE

Recolector. El recolector recoge los defectos encontrados por los inspectores en caso de no haber una reunin de inspeccin. Es necesario hacer ciertas consideraciones sobre el nmero de participantes. Un equipo de inspeccin nunca debera contar con ms de cinco miembros. Por otro lado, el nmero mnimo de participantes son dos: el autor (que acta tambin de inspector) y un inspector. Lo recomendable es comenzar con un equipo de tres o cuatro personas: el autor, uno o dos inspectores y el moderador (que acta tambin como lector y escriba). Tras unas cuantas inspecciones la organizacin puede experimentar incorporando un inspector ms al grupo y evaluar si resulta rentable en trminos de defectos encontrados. Sobre el tema de cmo seleccionar las personas adecuadas para una inspeccin, los candidatos principales para actuar como inspectores es el personal involucrado en el desarrollo del producto. Se pueden incorporar inspectores externos si poseen algn tipo de experiencia especfica que enriquezca la inspeccin. Los inspectores deben tener un alto grado de experiencia y conocimiento. La fase de Lanzamiento consiste en una primera reunin donde el autor explica el producto a inspeccionar a los otros participantes. El objetivo principal de esta reunin de lanzamiento, es facilitar la comprensin e inspeccin a los participantes. No obstante, este meeting no es completamente necesario, pues en ocasiones puede consumir ms tiempo y recursos de los beneficios que reporte. Sin embargo, existen un par de condiciones bajo las cuales es recomendable realizar esta reunin. En primer lugar, cuando el artefacto a inspeccionar es complejo y difcil de comprender. En este caso una explicacin por parte del autor sobre el producto a inspeccionar facilita la comprensin al resto de participantes. En segundo lugar, cuando el artefacto a inspeccionar pertenece a un sistema software de gran tamao. En este caso, se hace necesario que el autor explique las relaciones entre el artefacto inspeccionado y el sistema software en su globalidad. La fase de Deteccin de Defectos es el corazn de la inspeccin. El objetivo de esta fase es escudriar un artefacto software pare obtener defectos. Localizar defectos es una actividad en parte individual y en parte de grupo. Si se olvida la parte individual de la inspeccin, se corre el riesgo de que los participantes sean ms pasivos durante la reunin y se escuden en el grupo para evitar hacer su contribucin. As pues, es deseable que exista una fase de deteccin individual de defectos con el objetivo explcito de que cada participante examine y entienda en solitario el producto y busque defectos. Este esfuerzo individual garantiza que los participantes irn bien preparados a la puesta en comn. Los defectos detectados por cada participante en la inspeccin deben ser reunidos y documentado. Es ms, debe decidirse si un defecto es realmente un defecto. Esta recoleccin de defectos y la discusin sobre falsos positivos se realizan, respectivamente, en la fase de Compilacin y Reunin. La recoleccin de defectos debe ayudar a tomar la decisin sobre si es necesaria una reinspeccin del artefacto o no. Esta decisin depender de la cantidad de defectos encontrados y sobre todo de la coincidencia de los defectos encontrados por distintos participantes. Una coincidencia alta de los defectos encontrados por unos y por otros (y un numero bajo de

224

CALIDAD DE SOFTWARE

defectos encontrados) hace pensar que la cantidad de defectos que permanecen ocultos sea baja. Una coincidencia pobre (y un nmero relativamente alto de defectos encontrados) hace pensar que an quedan muchos defectos por detectar y que, por tanto, es necesaria una reinspeccin (una vez acabada sta y corregidas las faltas encontradas). Dado que una reunin consume bastantes recursos (y ms cuantos ms participantes involucre) se ha pensado en una alternativa para hacer las reuniones ms ligeras. Las llamadas reuniones de deposicin, donde slo asisten tres participantes: moderador, autor, y un representante de los inspectores. Este representante suele ser el inspector de ms experiencia, el cual recibe los defectos detectados por los otros inspectores y decide l, unilateralmente, sobre los falsos positivos. Algunos autores incluso han dudado del efecto sinergia de las reuniones y han aconsejado su no realizacin. Parece que lo ms recomendable es que las organizaciones comiencen con un proceso de inspeccin tradicional, donde la reunin sirve para compilar defectos y discutir falsos positivos, y con el tiempo y la experiencia prueben a variar el proceso eliminando la reunin y estudiando si se obtienen beneficios equivalentes en trminos de defectos encontrados. Es importante resaltar, que la reunin de una inspeccin no es una sesin para resolver los defectos u otros problemas. No se deben discutir en estas reuniones ni soluciones digamos radicales (otras alternativas de diseo o implementacin, que el autor no ha utilizado pero podra haberlo hecho), ni cmo resolver los defectos detectados, y, mucho menos, discutir sobre conflictos personales o departamentales. Finalmente, el autor corrige su artefacto para resolver los defectos encontrados o bien proporciona una explicacin razonada sobre porqu cierto defecto detectado en realidad no lo es. Para esto, el autor repasa la lista de defectos recopilada y discute o corrige cada defecto. El autor deber enviar al moderador un informe sobre los defectos corregidos o, en caso de no haber corregido alguno, porqu no debe corregirse. Este informe sirve de seguimiento y cierre de la inspeccin, o, en caso de haberse decidido en la fase de recopilacin que el artefacto necesitaba reinspeccin, se iniciar de nuevo el proceso.

Estimacin de los Defectos Remanentes A pesar de que el propsito principal de las Inspecciones es detectar y reducir el nmero de defectos, un efecto colateral pero importante es que permiten realizar desde momentos muy iniciales del desarrollo predicciones de la calidad del producto. Concretamente, las estimaciones de las faltas remanentes tras una inspeccin deben utilizarse como control de la calidad del proceso de desarrollo. Hay varios momentos de estimacin de faltas remanentes en una inspeccin. Al realizar la bsqueda individual de faltas, el inspector puede tener una idea de las faltas remanentes en base a las siguientes dos heursticas: Encontrar muchas faltas es sospechoso. Muchas faltas detectadas hacen pensar que debe haber muchas ms, puesto que la creencia de que queden pocas faltas slo se puede apoyar en la confianza en el proceso de inspeccin y no en la calidad del artefacto (que parece bastante baja puesto que hemos encontrado muchas faltas)

225

CALIDAD DE SOFTWARE

Encontrar muy pocas faltas tambin resulta sospechoso, especialmente si es la primera vez que se inspecciona este artefacto. Pocas faltas hacen pensar que deben quedar muchas ms, puesto que esta situacin hace dudar sobre la calidad del proceso de inspeccin: No puede saberse si se han encontrado pocas debido a la alta calidad del artefacto o a la baja calidad de la inspeccin. La estimacin ms fiable sobre el nmero de faltas remanentes que se puede obtener en una Inspeccin es la coincidencia de faltas entre los distintos inspectores. Los mtodos que explotan coincidencias para estimar se llaman Estimaciones Captura-Recaptura y no son originarias de la Ingeniera del Software. En concreto lo us por primera vez Laplace para estimar la poblacin de Francia en 1786, y se utilizan a menudo en Biologa para estimar el tamao de poblaciones de animales. En el caso de las Inspecciones, el nivel de coincidencia de las faltas detectadas por los distintos revisores es usado como estimador1. La idea sobre la que se basa el uso de las coincidencias es la siguiente: Pocas coincidencias entre los revisores, significa un nmero alto de faltas remanentes; Muchas coincidencias, significar pocas faltas remanentes. Los casos extremos son los siguientes. Supongamos que todos los revisores han encontrado exactamente el mismo conjunto de faltas. Esto debe significar que deben quedar muy pocas faltas, puesto que el proceso de inspeccin parece haber sido bueno (los inspectores han encontrado las mismas faltas) parece poco probable que queden ms faltas por ah que ningn revisor ha encontrado. Supongamos ahora que ningn revisor ha encontrado la misma falta que otro revisor. Esto debe querer decir que quedan muchas ms por encontrar, puesto que el proceso de revisin parece haber sido pobre (a cada revisor se le han quedado ocultas n faltas todas las encontradas por los otros revisores-) vaya usted a saber cuntas faltas ms han quedado ocultas a todos los revisores. Esta situacin debera implicar una nueva inspeccin del artefacto (tanto para mejorar la calidad del mismo, como para hacer un intento de mejorar la propia inspeccin).

Tcnicas de Lectura Las tcnicas de lectura son guas que ayudan a detectar defectos en los productos software. Tpicamente, una tcnica de lectura consiste en una serie de pasos o procedimientos cuyo propsito es que el inspector adquiere un conocimiento profundo del producto software que inspecciona. La comprensin de un producto software bajo inspeccin es un prerrequisito para detectar defectos sutiles y, o, complejos. En cierto sentido, una tcnica de lectura puede verse como un mecanismo para que los inspectores detecten defectos en el producto inspeccionado. Un estimador en una frmula usada para predecir el nmero de faltas que quedan. Un modelo de estimacin es el paraguas para denominar a un conjunto de estimadores basados en los mismos prerrequisitos. Las tcnicas de lectura ms populares son la lectura Ad-hoc y la lectura basada en listas de comprobacin. Ambas tcnicas pueden aplicarse sobre cualquier artefacto software, no solo sobre cdigo. Adems de estas dos tcnicas existen otras que, aunque menos utilizadas en la industria, intentan abordar los problemas de la lectura con listas y la lectura ad-hoc: Lectura por Abstraccin, Revisin Activa de Diseo y Lectura Basada en Escenarios. Esta ltima se trata de

226

CALIDAD DE SOFTWARE

una familia de tcnicas a la que pertenecen: Lectura Basada en Defectos y Lectura Basada en Perspectivas.

Lectura sin Checklists y con Checklists En la tcnica de lectura Ad-hoc, el producto software se entrega a los inspectores sin ninguna indicacin o gua sobre cmo proceder con el producto ni qu buscar. Por eso la denominamos tambin cmo Lectura sin Checklists. Sin embargo, que los participantes no cuenten con guas de qu buscar no significa que no escudrien sistemticamente el producto inspeccionado, ni tampoco que no tengan en mente el tipo de defecto que estn buscando. Como ya hemos dicho antes, si no se sabe lo que se busca, es imposible encontrarlo. El trmino "ad-hoc" slo se refiere al hecho de no proporcionar apoyo a los inspectores. En este caso la deteccin de los defectos depende completamente de las habilidades, conocimientos y experiencia del inspector. Tpicamente, el inspector deber buscar secuencialmente los defectos tpicos del producto que est leyendo (y que hemos indicado ms arriba). Por ejemplo, si se est inspeccionando unos requisitos, el inspector, buscar sistemtica y secuencialmente defectos de correccin, de completud, de ambigedad, etc. Para practicar esta tcnica, en el Anexo A aparece unos requisitos con defectos. Intenta buscarlos de acuerdo a lo indicado en el prrafo anterior. Sin gua alguna, simplemente utilizando la lista de criterios de calidad que debe cumplir unos requisitos que hemos indicado anteriormente. La lectura basada en Listas de Comprobacin (Checklists, en ingls) proporciona un apoyo mayor mediante preguntas que los inspectores deben de responder mientras leen el artefacto. Es decir, esta tcnica proporciona listas que ayudan al inspector a saber qu tipo de faltas buscar. Aunque una lista supone ms ayuda que nada, esta tcnica presenta la debilidad de que las preguntas proporcionan poco apoyo para ayudar a un inspector a entender el artefacto inspeccionado. Adems, las preguntas son a menudo generales y no suficientemente adaptadas a un entorno de desarrollo particular. Finalmente, las preguntas en una lista de comprobacin estn limitadas a la deteccin de defectos de un tipo determinado, tpicamente de correccin, puesto que las listas establecen errores universales (independientes del contexto y el problema). Checklists para Requisitos y Diseo Las listas de comprobacin para requisitos contienen preguntas sobre los defectos tpicos que suelen aparecer en los requisitos. Preguntas tpicas que aparecen en las Checklists de requisitos son: o o o o o o Existen contradicciones en la especificacin de los requisitos? Resulta comprensible la especificacin? Est especificado el rendimiento? Puede ser eliminado algn requisito? Pueden juntarse dos requisitos? Son redundantes o contradictorios? Se han especificado todos los recursos hardware necesarios?

227

CALIDAD DE SOFTWARE

o Se han especificado las interfaces externas necesarias? o Se han definido los criterios de aceptacin para cada una de las funciones especificadas? Ntese que las cinco primeras preguntas, corresponden simplemente a los criterios de calidad de los requisitos. Mientras que las tres ltimas tratan olvidos tpicos al especificar requisitos. Las dos que aparecen en primer lugar son comprobaciones sobre la especificacin del hardware sobre el que correr el futuro sistema y sobre cmo deber interactuar con otros sistemas. La ltima comprueba que los requisitos contienen criterios de aceptacin para cuando se realicen las pruebas de aceptacin. Los requisitos necesitan ser evaluados de forma crtica para prevenir errores. En esta fase radica la calidad del producto software desde la perspectiva del usuario. Si la evaluacin en general es difcil, la de los requisitos en particular lo es ms, debido a que lo que se evala es la definicin del problema. Con respecto al diseo, los objetivos principales de su evaluacin esttica son: Determinar si la solucin elegida es la mejor de todas las opciones; es decir, si la opcin es la ms simple y la forma ms fcil de realizar el trabajo. Determinar si la solucin abarca todos los requisitos descritos en la especificacin; es decir, si la solucin elegida realizar la funcin encomendada al software. Al igual que la evaluacin de requisitos, la evaluacin de diseo es crucial, ya que los defectos de diseo que queden y sean transmitidos al cdigo, cuando sean detectados en fases ms avanzadas del desarrollo, o incluso durante el uso, implicar un rediseo del sistema, con la subsiguiente recodificacin. Es decir, existir una prdida real de trabajo. Veamos un ejemplo de preguntas para el diseo: o o o o o Cubre el diseo todos los requisitos funcionales? Resulta ambigua la documentacin del diseo? Se ha aplicado la notacin de diseo correctamente? Se han definido correctamente las interfaces entre elementos del diseo? Es el diseo suficientemente detallado como para que sea posible implementarlo en el lenguaje de programacin elegido?

Checklists para Cdigo Las listas para cdigo han sido mucho ms estudiadas que para otros artefactos. As hay listas para distintos lenguajes de programacin, para distintas partes de cdigo, etc. Una tpica lista de comprobacin para cdigo contendr varias partes (una por los distintos tipos de defecto que se buscan) cada una con preguntas sobre defectos universales y tpicos. Por ejemplo: Lgica del programa: o Es correcta la lgica del programa? o Est completa la lgica del programa?, es decir, est todo correctamente especificado sin faltar ninguna funcin?

228

CALIDAD DE SOFTWARE

Interfaces Internas: o Es igual el nmero de parmetros recibidos por el mdulo a probar al nmero de argumentos enviados?, adems, el orden es correcto? o Los atributos (por ejemplo, tipo y tamao) de cada parmetro recibido por el mdulo a probar coinciden con los atributos del argumento correspondiente? o Coinciden las unidades en las que se expresan parmetros y argumentos?. Por ejemplo, argumentos en grados y parmetros en radianes. Altera el mdulo un parmetro de slo lectura?Son consistentes las definiciones de variables globales entre los mdulos? Interfaces Externas: o Se declaran los ficheros con todos sus atributos de forma correcta? o Se abren todos los ficheros antes de usarlos? o Coincide el formato del fichero con el formato especificado en la lectura?Se manejan correctamente las condiciones de fin de fichero?. Se los libera de memoria? o Se manejan correctamente los errores de entrada/salida? Datos: o Referencias de datos. Se refieren a los accesos que se realizan a los mismos. Ejemplos tpicos son: Utilizar variables no inicializadas o Salirse del lmite de las matrices y vectores o Superar el lmite de tamao de una cadena o Declaracin de datos. El propsito es comprobar que todas las definiciones de los datos locales son correctas. Por ejemplo: o Comprobar que no hay dos variables con el mismo nombre o Comprobar que todas las variables estn declaradas o Comprobar que las longitudes y tipos de las variables sean correctos. o Clculo. Intenta localizar errores derivados del uso de las variables. Por ejemplo: o Comprobar que no se producen overflow o underflow (valores fuera de rango, por encima o por debajo) en los clculos o divisiones por cero. o Comparacin. Intenta localizar errores en las comparaciones realizadas en instrucciones tipo If-Then-Else, While, etc. Por ejemplo: o Comprobar que no existen comparaciones entre variables con diferentes tipos de datos o si las variables tienen diferente longitud. o Comprobar si los operadores utilizados en la comparacin son correctos, si utilizan operadores booleanos comprobar si los operandos usados son booleanos, etc. Lectura por Abstraccin Sucesiva La Lectura por Abstraccin Sucesiva sirve para inspeccionar cdigo, y no otro tipo de artefacto como requisitos o diseo. La idea sobre la que se basa esta tcnica de lectura para detectar defectos es en la comparacin entre la especificacin del programa (es decir, el texto que describe lo que el programa debera hacer) y lo que el programa hacer realmente. Naturalmente, todos aquellos puntos donde no coincida lo que el programa debera hacer con lo que el programa hace es un defecto. Dado que comparar cdigo con texto (la especificacin) es inapropiado pues se estaran comparando unidades distintas (peras con manzanas), se hace necesario convertir ambos artefactos a las mismas unidades. Lo que se hace, entonces, es convertir el programa en una

229

CALIDAD DE SOFTWARE

especificacin en forma de texto. De modo que podamos comparar especificacin (texto) con especificacin (texto). Obtener una especificacin a partir de un cdigo significa recorrer el camino de la programacin en sentido inverso. El sentido directo es obtener un cdigo a partir de una especificacin. Este camino se recorre en una seria de pasos (que a menudo quedan ocultos en la mente del programador y no se hacen explcitos, pero que no por eso dejan de existir). El recorrido directo del camino de la especificacin al cdigo consta de los siguientes pasos: 1. Leer la especificacin varias veces hasta que el programador ha entendido lo que el cdigo debe hacer. 2. Descomponer la tarea que el programa debe hacer en sub-tareas, que tpicamente se correspondern con las funciones o mdulos que compondrn el programa. Esta descomposicin muestra la relacin entre funciones, que no siempre es secuencial, sino tpicamente en forma de rbol: Funciones alternativas que se ejecutarn dependiendo de alguna condicin; Funciones suplementarias que se ejecutaran siempre una si se ejecuta la otra; etc. 3. Para cada uno de estas sub-tareas (funciones): 3.1. Hacer una descripcin sistemtica (tpicamente en pseudocdigo) de cmo realizar la tarea. En esta descripcin se pueden ya apreciar las principales estructuras de las que constar la funcin (bucles, condicionales, etc.) 3.2. Programar cada lnea de cdigo que compone la funcin Como puede observarse en este proceso, el programador trabaja desde la especificacin por descomposiciones sucesivas. Es decir, dividiendo una cosa compleja (la especificacin) en cosas cada vez ms sencillas (primero las funciones, luego las estructuras elementales de los programas, finalmente las lneas de cdigo). Este tipo de tarea se realiza de arriba hacia abajo, partiendo de la especificacin (arriba o nodo raz) y llegando a n lneas de cdigo (abajo o nodos hojas). Pues bien, si queremos obtener una especificacin a partir de un cdigo deberemos hacer este mismo recorrido pero en sentido contrario: de abajo hacia arriba. Por tanto, deberemos comenzar con las lneas de cdigo, agruparlas en estructuras elementales, y stas en funciones y stas en un todo que ser la descripcin del comportamiento del programa. En este caso no estamos trabajando descomponiendo, sino componiendo. La tarea que se realiza es de abstraccin. De ah el nombre de la tcnica: abstraccin sucesiva (ir sucesivamente ascendiendo en niveles cada vez superiores abstrayendo qu hace cada elemento primero las lneas, luego las estructuras, finalmente las funciones). Esta tcnica requiere que el inspector lea una serie de lneas de cdigo y que abstraiga la funcin que estas lneas computan. El inspector debe repetir este procedimiento hasta que la funcin final del cdigo que se est inspeccionando se haya abstrado y pueda compararse con la especificacin original del programa. Ms concretamente, el proceso que se debe seguir para realizar la abstraccin sucesiva es el siguiente: 1. Leer por encima el cdigo para tener una idea general del programa. 2. Determinar las dependencias entre las funciones individuales del cdigo fuente (quin llama a quin). Para esto puede usarse un rbol de llamadas para representar tales dependencias

230

CALIDAD DE SOFTWARE

comenzando por las hojas (funciones que no llaman a nadie) y acabando por la raz.(funcin principal). 3. Comprender qu hace cada funcin. Para ello se deber: Entender la estructura de cada funcin individual identificando las estructuras elementales (secuencias, condicionales, bucles, etc.) y marcndolas; Combinar las estructuras elementales para formar estructuras ms grandes hasta que se haya entendido la funcin entera. Es decir, para cada funcin y comenzando desde las funciones hoja y acabando por la raz: 3.1. Identificar las estructuras elementales de cada funcin y marcarlas de la ms interna a la ms externa. 3.2. Determinar el significado de cada estructura comenzando con la ms interna. Para ello pueden seguirse las siguientes recomendaciones: Usar los nmeros de lnea (lneas x-y) para identificar las lneas que abarca una estructura e indicar a su lado qu hace. Evitar utilizar conocimiento implcito que no resida en la estructura (valores iniciales, entradas o valores de parmetros). Usar principios generalmente aceptados del dominio de aplicacin para mantener la descripcin breve y entendible (bsqueda en profundidad en lugar de describir lo que hace la bsqueda en profundidad). 3.3. Especificar el comportamiento de la funcin entera. Es decir, utilizar la informacin de los pasos 3.1 y 3.2 para entender qu hace la funcin y describirlo en texto. 4. Combinar el comportamiento de cada funcin y las relaciones entre ellas para entender el comportamiento del programa entero. El comportamiento deber describirse en texto. Esta descripcin es la especificacin del programa obtenida a partir del cdigo. 5. Comparar la especificacin obtenida con la especificacin original del programa. Cada apunto donde especificacin original y especificacin generada a partir del cdigo no coincidan es un defecto. Anotar los defectos en una lista. Veamos un breve ejemplo para entender mejor la tcnica. El programa count ya lo conoces pues lo has usado para practicar con la tcnica de lectura con listas de comprobacin. Centrmonos en el siguiente trozo de especificacin original: Si alguno de los ficheros que se le pasa como argumento no existe, aparece por la salida de error el mensaje de error correspondiente y se contina procesando el resto de los ficheros. Que se implementa mediante las siguientes lneas de cdigo entresacadas del programa count. if (argc > 1 && (fp=fopen(argv[i], "r")) == NULL) { fprintf (stdout, "can't open %s\n", argv[i]); exit(1) } La abstraccin de estas lneas sera: Lnea 1 Si no hay ficheros que coincidan con el argumento (fp=fopen(argv[i], "r")) == NULL)

231

CALIDAD DE SOFTWARE

Lnea 2 Se imprime por la salida estndar (stdout)el mensaje de que no se puede abrir el fichero (indicando el nombre del fichero) Lnea 3 Se sale del programa Que se corresponde con la siguiente descripcin: Se proporcionan argumentos, pero no hay ficheros con nombres correspondientes a los argumentos. En este caso, el programa se para con un mensaje de error que sale por la salida estndar. Lectura Basad en Escenarios La Lectura Basada en Escenarios proporciona guas al inspector (escenarios que pueden ser preguntas pero tambin alguna descripcin ms detallada) sobre cmo realizar el examen del artefacto. Principalmente, un escenario limita la atencin de un inspector en la deteccin de defectos particulares definidos por la gua. Dado que inspectores diferentes pueden usar escenarios distintos, y como cada escenario se centra en diferentes tipos de defectos, se espera que el equipo de inspeccin resulte ms efectivo en su globalidad .Existen dos tcnicas de lectura basada en escenarios: Lectura Basada en Defectos y Lectura Basada en Perspectivas. Ambas tcnicas examinan documentos de requisitos. La Lectura Basada en Defectos focaliza cada inspector en una clase distinta de defecto mientras inspecciona un documento de requisitos. Contestar a las preguntas planteadas en el escenario ayuda al inspector a encontrar defectos de determinado tipo. La Lectura Basada en Perspectiva establece que un producto software debera inspeccionarse bajo las perspectivas de los distintos participantes en un proyecto de desarrollo. Las perspectivas dependen del papel que los distintos participantes tienen en el proyecto. Para cada perspectiva se definen uno o varios escenarios consistentes en actividades repetibles que un inspector debe realizar y preguntas que el inspector debe responder. Por ejemplo, disear los casos de prueba es una actividad tpicamente realizada por el validador. As pues, un inspector leyendo desde la perspectiva de un validador debe pensar en la obtencin de los casos de prueba. Mientras que un inspector ejerciendo la perspectiva del diseador, deber leer ese mismo artefacto pensando en que va a tener que realizar el diseo.

232

CALIDAD DE SOFTWARE

REFERNCIAS [1]http://es.wikipedia.org/wiki/Calidad [2]http://es.scribd.com/doc/41415827/Calidad [3]http://www.ub.edu.ar/catedras/ingenieria/ing_software/ubftecwwwdfd/calidadsw/calidad.hm [4] http://www.cs.uns.edu.ar/~prf/teaching/SQ07/clase2.pdf [5] http://es.wikipedia.org/wiki/Tratado_de_libre_comercio [6]http://enciclopedia.us.es/index.php/Calidad_de_vida [7] http://www.contactopyme.gob.mx/guiasempresariales/guias.asp?s=9&g=7 [8]http://www.fing.edu.uy/inco/cursos/ingsoft/pis/proceso/MUM/disciplinas/sqa/q4_revision_te cnica_formal.htm [9]http://www.willydev.net/descargas/WillyDEV_PlaneaSoftware.Pdf [10]http://www.tuveras.com/calidad/herramientas/herramientas.html [11]http://www.ub.edu/geocrit/b3w-129.htm [12]http://www.unlu.edu.ar/~ope20156/normasiso.htm [13]http://www.worldamerican.com/spanish_pages/site/quality/iso.html [14]http://www.worldamerican.com/spanish_pages/site/quality/iso.html [15]http://gidis.ing.unlpam.edu.ar/downloads/pdfs/Calidad_software.PDF [16]http://www.rodolfoquispe.org/blog/que-es-la-calidad-de-software.php [17]http://www.rodolfoquispe.org/blog/que-es-la-calidad-de-software.php [18]https://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r63453.DOCX [20]http://www.qualitrain.com.mx/Control-de-Calidad-de-Software.html [21]http://www.frvm.utn.edu.ar/servicios.php [22]http://ealmeida.blogspot.com/2008/10/iso-90012000-sirve-para-una-empresa-de.html [23]http://translate.google.com/translate?hl=es&langpair=en|es&u=http://en.wikipedia.org/wiki /ISO/IEC_9126 [24]http://lasnormasiso15504122079126.blogspot.com/2009/10/las-normas-isoiec-1550412207-9126.html

233

CALIDAD DE SOFTWARE

[25]http://noqualityinside.com/nqi/nqifiles/CalidadDeSoftware.pdf [26]http://dienteciego.wordpress.com/2009/10/10/metodologias-para-el-desarrollo-de-software/

234