material de clase

Manual Aseguramiento Calidad de Software

UNIDAD I (ELEMENTOSY PRINCIPIOS DE LA CALIDAD)

1.1. LA CALIDAD REAL Calidad es satisfacer al cliente cumpliendo con sus requisitos, requerimientos y/o especificaciones. Calidad es respetar al pueblo [La Habana, 2002]. Calidad es tener la oportunidad de mejorar y aportar valor a tu vida. Calidad es vivir, compartir tus sentimientos, soar, inventar proyectos lindos, bellos. La tica, los valores, nuestra identidad de calidad. Las personas, eje central de nuestras vidas, son los motores de la calidad. Calidad es disfrutar de cada instante, de cada momento. Calidad es una filosofa de la vida, el deseo de hacer las cosas bien desde el principio. La adopcin de un Sistema de la Calidad Total debe ser una decisin estratgica dentro de la organizacin. De igual forma que los proyectos de TI ya se consideran como una inversin, la calidad no tiene coste, el costo real es de la NO CALIDAD, es decir, el coste de tener que volver a hacer las cosas. Para conseguir este objetivo es necesario desarrollar un plan de aseguramiento de calidad especfico que se aplicar en la planificacin y gestin del proyecto.

1.2. DEFINICION DE CALIDAD

1. La calidad es el conjunto de propiedades y caractersticas de un producto, proceso o servicio que le confieren su aptitud para satisfacer necesidades expresadas o implcitas. (ISO). 2. La calidad es la aptitud de un producto o de un servicio para satisfacer las necesidades de los utilizadores. (AENOR). 3. La calidad es dar respuesta a las exigencias: conformidad. (CROSBY).

1


Control de calidad: Conjunto de tcnicas y actividades de carcter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio.

Aseguramiento de la calidad: Conjunto de acciones planificadas y sistemticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfar los requerimientos dados sobre calidad.

Gestin de la calidad: Aspectos de la funcin de gestin que determinan y aplican la poltica de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificacin de la calidad, el control de la calidad, la garanta de calidad y la mejora de la calidad.

Sistema de gestin de la calidad: Estructura de la organizacin, responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a trmino la gestin de calidad.

1.3. CALIDAD (OCHO PRINCIPIOS GENERALES)

Organizacin orientada al cliente. Liderazgo. Enfoque a procesos. Enfoque a un sistema para la gestin. Vocacin de mejora continua. Relaciones mutuamente provechosas con los proveedores. Participacin del personal. Procesos de toma de decisiones basados en hechos.

2


1.4. LAS TRES ESCUELAS DE LA CALIDAD TOTAL

Crosby da una orientacin prctica y sencilla al programa de implantacin de la Calidad Total.

Deming se centra ms en aspectos relativos a las conductas y actitudes.

Juran focaliza en la alta direccin la responsabilidad de la aplicacin y control de los programas de calidad.

PHILIP CROSBY Menciona que la calidad es gratis, definindola como Conformidad con los requerimientos" e indicando que el 100% de la conformidad es igual a cero defectos.

Establece que en las organizaciones que no se trabaja con un plan que contemple la calidad, los retrabajos y desperdicios alcanzan del 20 al 40%.

Promueve sus 14 pasos para administrar la calidad en un libro denominado "Calidad sin Lgrimas". Autor del libro " La Calidad es Gratis ", se le conoce por su lema de Cero Defectos. La aproximacin de CROSBY Compromiso de la direccin. Equipo de mejora de la calidad. Medicin de la calidad. Evaluacin del coste de la calidad. Conciencia de la calidad. Accin correctora. Planificacin del cero defectos. El da cero defectos. Entrenamiento de los supervisores. Fijacin de metas.

3


Eliminacin de metas. Eliminacin de causas de error. Reconocimiento. Consejos de calidad. Hacerlo todo de nuevo.

WILLIAM EDWARD DEMING Impulsor del desarrollo en calidad de Japn, fue invitado en 1950 por la Unin de Cientficos e Ingenieros del Japn (JUSE), logrando que implementaran el Control Total de Calidad usando el ciclo PHVA (Planear, Hacer, Verificar y Actuar) de Shewhart y el Control Estadstico de Procesos. Se le considera el "Padre" de la Tercera Revolucin Industrial o La Revolucin de la Calidad, con sus famosos 14 puntos. Entre sus libros se puede citar "Calidad, Productividad y Competitividad", en donde hace ver la necesidad del liderazgo en la calidad.

La aproximacin de DEMING: No se pueden tolerar los niveles aceptados de error. Crear constancia en el propsito de mejorar el producto/servicio. Dejar de depender de la inspeccin en masa. Dejar hacer negocios sobre la base del precio. Mejorar el sistema de produccin y servicio. Implantar la formacin. Erradicar el miedo. Adoptar e implantar el liderazgo. Derribar las barreras entre departamentos. Eliminar los eslganes exhortaciones y metas Eliminar cuotas numricas. Fomentar el orgullo por el trabajo. Estimular la educacin y la auto mejora. Lograr la transformacin.

4


JOSEPH M. JURAN Afirma que la Alta Administracin es la responsable del cambio, abogando por crear el cambio cuando el proceso necesita mejorarse y por prevenir el cambio cuando los problemas son espordicos. Logr desarrollar la tcnica de los Costos de Calidad, elaborando un Manual de Calidad, en donde existe un fuerte contenido administrativo enfocado a la planeacin, organizacin y responsabilidad. En 1954 fue invitado por el JUSE para dar conferencias en Japn, por lo que junto con Deming e Ishikawa se les considera los principales promotores del xito de Japn.

La aproximacin de JURAN Planificacin de la calidad. Identificar los clientes. Establecer las necesidades de los clientes. Desarrollo de productos/servicios segn necesidades del cliente. Desarrollo de procesos acorde con los productos anteriores. Transferir los planes resultantes al personal.

Control de calidad. Evaluar los resultados operativos. Comparar los resultados con los objetivos. Actuar en funcin de las diferencias corrigiendo las desviaciones.

Mejora de la calidad. Establecer las infraestructuras necesarias para conseguirla. Identificar las necesidades concretas para mejorar. Establecer un equipo responsable. Proporcionar los recursos, motivacin y formacin al equipo.

5


WALTER A. SHEWHART La mayor parte de su carrera profesional la ejerci como ingeniero en Western Electric de 1918 a 1924, y en los laboratorios Bell Telephone como miembro del cuerpo tcnico de 1925 hasta su retiro en 1956. Tambin dio ctedras sobre control de calidad y estadsticas aplicadas en la Universidad de Londres, el Instituto Stevens de Tecnologa, la escuela de graduados del Departamento de Agricultura de Estados Unidos y en la India. Fue miembro del comit de visitas en el Departamento de Relaciones Sociales de Harvard, profesor honorario en Rutgers y miembro del comit consultivo del departamento de matemticas de Princeton. Miembro fundador de la Sociedad Americana de Calidad (ASQ).

1.5. LA CALIDAD Y LOS DEFECTOS

Originalmente, la calidad de un programa o sistema se evaluaba de acuerdo al nmero de defectos por cada mil lneas de cdigo. En 1988, un estudio realizado en los EEUU, demostr que se introducan cerca de sesenta defectos por cada mil lneas de cdigo (60 def/KLOC), Lograr un alto nivel de calidad de un producto o servicios es el objetivo de muchas organizaciones. Ya no se acepta entregar productos de calidad pobre y luego arreglar los problemas y deficiencias despus de la entrega al cliente. A este respecto, el software tiene as mismas caractersticas que cualquier otro producto manufacturado como los automviles, los televisores o las computadoras.

Sin embargo, la calidad del software es un concepto complejo que no se puede definir de una forma simple. Clsicamente, la nocin de calidad es que el producto desarrollado cumple sus especificaciones (Crosby), 1979). En un mundo ideal, esta definicin aplica a todos los productos pero, para sistemas de software, existen problemas:

1. La especificacin se orienta hacia las caractersticas del producto que el consumidor quiere. Sin embargo, la organizacin desarrolladora tambin tiene requerimientos (como los de mantenimiento) que no se incluyen en la especificacin.

6


2. No se sabe como especificar ciertas caractersticas de calidad (por ejemplo, mantenimiento) de una forma no ambigua.

Obviamente, se han hecho esfuerzos para mejorar las especificaciones, pero en la actualidad se tiene que aceptar que son imperfectas. Se reconocen los problemas con las especificaciones existentes y se disean procedimientos para mejorar la calidad dentro de las restricciones impuestas por una especificacin imperfecta. En particular, los atributos de software, como la mantenibilidad, la portabilidad o la eficiencia, son atributos de calidad crticos que no se especifican explcitamente pero que afectan la calidad percibida del sistema.

La responsabilidad de los administradores de la calidad en una organizacin es asegurar que se cumpla el nivel requerido de la calidad de un producto. En principio, la administracin de calidad comprende simplemente definir procedimientos y estndares a utilizar durante el desarrollo de software y comprobar que todos los ingenieros los sigan. Pero en la prctica la administracin de la calidad es ms que esto.

Los buenos administradores de la calidad tienen como propsito desarrollar una cultura de la calidad donde cada persona responsable del desarrollo del producto es motivada para que logre un alto nivel de la calidad del producto. Fomentan en los equipos a tomar responsabilidad de la calidad de su trabajo y a desarrollar nuevos enfoques de mejora de la calidad. Aunque los estndares y los procedimientos son la base de la administracin de la calidad, los administradores de la calidad experimentando reconocen que existen aspectos intangible para la calidad del software (elegancia, transparencia, etc) que no estn incluidas en los estndares. Apoyan al personal interesado en estos aspectos inteligibles de la calidad y fomentan el comportamiento profesional en todos los miembros del equipo.

7


UNIDAD II (ADMINISTRACION, ESTANDARES Y SEGURAMIENTO DE LA CALIDAD) 2.1 LA ADMINISTRACIN DE LA CALIDAD DEL SOFTWARE SE ENCUENTRA EN TRES ACTIVIDADES PRINCIPALES:

1. Aseguramiento de la calidad. El establecimiento de un marco de trabajo de procedimiento y estndares organizacionales que conduce a software de alta calidad. 2. Planeacin de la calidad. La seleccin de procedimientos y estndares adecuados a partir de este marco de trabajo y la adaptacin de estos para un proyecto de software especifico. 3. Control de calidad. La definicin y promulgacin de los procesos que aseguran que los procedimientos y estndares para la calidad del producto son seguidos por el equipo de desarrollo de software.

La administracin de la calidad provee una comprobacin independiente de los procesos de desarrollo de software. El producto resultante de los procesos del software se introduce en el proceso de administracin de la calidad, donde se comprueba para asegurar que es consistente con los estndares y metas organizacionales (ver la figura 24.1).

Puesto que los miembros del equipo de aseguramiento y control de la calidad son independientes, pueden tomar una visin objetiva del proceso y reportar problemas y dificultades a los administradores principales de la organizacin.

La administracin de la calidad esta separada de la administracin de proyectos de manera que no este comprometida con las responsabilidades de administracin del presupuesto y de la duracin del proyecto. Un equipo independiente es responsable de administrar la calidad y reporta con la administracin superior del nivel de administracin del proyecto. El equipo de administracin de la calidad no esta asociado con ningn grupo de desarrollo en particular sino que tiene la responsabilidad de la administracin de la calidad del software.

8


Una estndar internacional que se puede utilizar en el desarrollo de un sistema de administracin de calidad en todas las industrias es ISO 9000. Este es un conjunto de estndares que se aplican a una gran variedad de organizaciones que van desde las de manufactura hasta las de industria de servicios. ISO 9001 es el mas general de estos estndares y se aplica a las organizaciones interesadas en el proceso de calidad del diseo, desarrollo y mantenimiento de productos. Un documento de ayuda (ISO 9000-3) interpreta a ISO 9000 para el desarrollo de software. Existen varios libros que se describen el estndar ISO 9000 (Johnson, 1993; Oskarsson y Glass, 1995; Peach, 1996).

ISO 9001 es un modelo genrico de un proceso de calidad. Describe varios aspectos de ese proceso y define que estndares y procedimientos deben existir dentro de una organizacin. Puesto que no se refiere especficamente a una industria, no estn definidos en detalle. Dentro de una organizacin especifica, el conjunto de procesos de calidad apropiados se define y documenta en un manual de calidad.

9


2.2 ASEGURAMIENTO Y ESTANDARES DE CALIDAD

Las actividades de aseguramiento de la calidad (QA) definen un marco de trabajo para lograr la calidad del software. Los procesos QA comprenden definir o seleccionar estndares aplicables al proceso de desarrollo de software o a los productos de software. Estos estndares pueden estar incrustados en procedimientos o procesos aplicables durante el desarrollo. Los procesos se pueden apoyar en herramientas que capturan el conocimiento de los estndares de calidad.

Existen dos tipos de estndares que se establecen como parte del proceso de aseguramiento de la calidad:

1. Estndares del producto. Estos son estndares que se aplican al producto de software a desarrollar. Incluyen estndares de documentos, como la estructura del documento de requerimientos a producir, estndares de documentacin, como encabezado estndar de comentarios para una definicin de clases de objetos, estndares de codificacin, que definen como utilizar un lenguaje de programacin. 2. Estndares del proceso. Estos son estndares que definen los procesos a seguir durante el desarrollo del software. Incluyen definiciones de los procesos de especificacin, de diseo y de validacin y una descripcin de los documentos a generar en el trascurso de estos procesos.

Existe una relacin muy cercana entre los estndares del producto y del proceso. Los estndares del producto se aplican a las salidas del proceso del software y, en muchos casos, los estndares del proceso incluyen actividades especficas del proceso que aseguran que se siguen los estndares del producto.

1. Proveen un conjunto compacto d las mejores practicas, o al menos de las mas apropiadas. A menudo, este conocimiento solo se adquiere despus de seguir un proceso de prueba y error. Tenerlo constituido en un estndar evita la repeticin

10


de errores anteriores. Los estndares capturan el conocimiento de valor para la organizacin. 2. Proveen un marco de trabajo alrededor del cual se implementa el proceso de aseguramiento de la calidad. Puesto que los estndares capturan las mejores practicas, el control de la calidad sencillamente segura que los estndares se siguen adecundose.

Estndares del producto y del proceso (Figura 24,4)

ESTNDARES DEL PRODUCTO Formulacin para revisin del diseo

ESTNDARES DEL PROCESO Conducto para la revisin del diseo

Estructura

del

documento

de Subministro de documento a CM

requerimientos Formato del encabezado del procedimiento Estilo de programacin en Java Proceso de aprobacin del plan del proyecto Formato de peticin de cambios Formato de plan de proyecto Proceso de registro de las pruebas Proceso de control de cambio Proceso de entregas de versiones

Los standards aseguran que todos los ingenieros dentro de una organizacin adopten las mismas prcticas. En consecuencia, se reduce el esfuerzo de aprendizaje cuando se comienza un nuevo trabajo.

El desarrollo de los estndares de proyectos de ingeniera de software es un proceso difcil y largo. Organizaciones nacionales e internacionales como el Departamento de Defensa de los Estados Unidos. ANSI, BSI, OTAN y el IEEE han estado activamente en la produccin de estndares. Estos son estndares generales que se aplican a una gran variedad de proyectos. Organizaciones, como la OTAN y otras organizaciones de defensa, requieren que sus propios estndares se sigan en los contratos de software.

11


Se han desarrollado estndares nacionales e internacionales para cubrir la terminologa de la ingeniera de soltare, los lenguaje de programacin como Ada y C++ las notaciones como las de los smbolos de diagramas, los procedimientos para derivar y redactar requerimientos de software, los procedimientos de aseguramiento de la calidad y los procesos de verificacin y validacin del software (IEEE, 1994).

Los equipos de aseguramiento de la calidad que desarrollan los estndares se apoyan en estndares organizacionales basados en estndares nacionales e internacionales. Utilizando estos estndares como un punto de partida, el equipo de aseguramiento de la calidad debe crear un manual de estndares. Este define los estndares que son apropiados para la organizacin. La (Figura 24,4) muestra ejemplos de estndares que se pueden incluir en ese manual.

Algunas veces los ingenieros de software consideran a los estndares como burocrticos e irrelevantes para las actividades tcnicas del desarrollo de software. Esto es as cuando los estndares requieren llenar formularios tediosos y registrar el trabajo. Aunque por lo general los ingenieros estn de acuerdo en que los estndares son necesarios, a menudo tienen buenas razones del porque dichos estndares no son necesariamente apropiados para su proyecto en particular.

Para evitar estos problemas, los administradores de la calidad que fijan los estndares requieren estar informando a tomar en consideracin los siguientes pasos:

1. Involucrar a los ingenieros de software en el desarrollo de los estndares del producto. As comprendern la motivacin detrs del desarrollo de los estndares y se comprometen con ellos. El documento de los estndares no debe establecer

simplemente que se sigan los estndares sino que deben incluir razones de por que se tomaron decisiones particulares.

12


2. Revisar y modificar los estndares de forma regular con el fin de reflejar las tecnologas cambiantes. Una vez que los estndares se desarrollan, tienden a plasmarse en un manual de estndares de la organizacin y a menudo existe una resistencia a cambiarlos. Un manual de estndares es esencial pero debe evolucionar acorde a las circunstancias y la tecnologa cambiantes.

3. Proveer herramientas de software para apoyar a los estndares donde sea necesario. Los estndares clericales son la causa de muchas quejas debido al trabajo tedioso que se requiere para implementarlos. Si se dispone de una herramienta de apoyo, no existe la necesidad de esfuerzo adicional en el desarrollo de los estndares.

Los estndares del proceso provocan dificultades si se impone un proceso no prctico en el equipo de desarrollo. A menudo, tales estndares simplemente dan lineamientos que deben interpretarse por los administradores de los proyectos. No existe razn para prescribir una forma particular de trabajo si esta es inapropiada para los proyectos o para el equipo del proyecto. Por lo tanto, el administrador de cada proyecto tiene la autoridad de modificar los estndares del proceso de acuerdo con las circunstancias individuales. Sin embargo, los estndares relacionados con la calidad del producto y el proceso de postentrega solo deben cambiarse despus de consideraciones cuidadosas.

El administrador del proyecto y el de la calidad pueden evitarse los problemas de los estndares inapropiados si planear cuidadosamente la calidad. Deben decidir cuales estndares del manual utilizar sin cambios alguno, cuales se modifican y cuales se ignoran. Tienen que crearse estndares nuevos como respuesta a un requerimiento particular del proyecto. Por ejemplo, se pueden requerir. Estndares para las especificaciones formales si estn no se han utilizando en proyectos previos. Se deben seguir estos nuevos estndares para evolucionar durante el proyecto.

13


2.3 ESTANDARES DE DOCUMENTACION

Los estndares de documentacin en un proyecto de software son documentos muy importantes ya que son la nica forma tangible de representar al software y al proceso del software. Los documentos estandarizados tienen una apariencia, estructura y calidad consistentes, y por lo tanto son ms fciles de leer y de comprender.

Muchos estndares y procedimientos corporativos u organizacionales se concentran en las descripciones que acompaan un conjunto de programas. Se considera como documentacin del programa al conjunto de descripciones escritas que explican al lector que hace el programa y como lo hace. La documentacin interna es el material descriptivo, escrito directamente dentro del cdigo, y cualquier otra documentacin es documentacin externa.

Documentacin interna La documentacin interna contiene informacin dirigida a quienes leern el cdigo fuente del programa. Se incluye informacin sumaria para identificar el programa y describir algoritmo, estructuras de datos y flujo de control. Usualmente esta informacin se ubica al comienzo de cada componente en un conjunto de comentarios que se denomina bloque de encabezado.

Encabezamiento: As como un buen periodista incluye el por que, el cuando, el donde, y los quienes de una historia, es necesario incluir al comienzo de los programas un encabezamiento que contenga la siguiente informacin acerca de cada componente:

1. Que denominacin tiene el componente 2. Quien ha escrito el componente 3. Donde va ubicado el componente en el diseo general del sistema 4. Cuando fue escrito, revisado o modificado 5. Por que existe el componente 6. Como utiliza sus estructuras de datos, algoritmos y control

14


Usualmente, los estndares organizacionales especifican el orden y contenido de estos bloques de comentarios. A continuacin se puede apreciar la apariencia tpica de un encabezamiento de esta clase. Ejemplo: PROGRAM SCAN: Programa para escanear lneas de texto carcter por carcter PROGRAMADOR: Beatriz Clemente (809) 345-6765/ [email protected] VERSION 1: Escrito el 3 de noviembre 2001 por B. Clemente DECLARACION DE VARIABLES Y CONTANTE ESTRUCTURA DE DATOS .. ALGORITMO Y PROCEDIMIENTO -----------------Documentacin externa Mientras la documentacin interna es concisa y esta escrita en un nivel apropiado para un programador, la documentacin externa se prepara para ser leda incluso por quienes tal vez nunca vern el cdigo real. Por ejemplo, los diseadotes pueden revisar la documentacin cuando consideran modificaciones o mejoras. Adems, la documentacin externa brinda una oportunidad de explicar las cosas en forma mas amplia que lo que es razonable hacer en los comentarios. Si se considera que el bloque de comentario del encabezamiento es una vista global o resumen del programa, entonces, la documentacin externa constituye un informe totalmente desarrollado. Responde a las mismas cuestiones quien, que, por que, cuando, donde y como desde la perspectiva del sistema, en lugar de la perspectiva de un componente.

Existen tres tipos de estndares de documentacin:

1. Estndares del proceso de documentacin. Estos definen el proceso a seguir para la produccin del documento. 2. Estndares del documento. Estos gobiernan la estructura y presentacin de los documentos.

15


3. Estndares para el intercambio de documentos. Estos aseguran que todas las copias electrnicas de los documentos sean compatibles.

Los estndares del proceso definen el proceso utilizando para producir los documentos. Esto implica definir los procedimientos involucrados en el desarrollo del documento y las herramientas de software utilizadas para la produccin del documento. Tambin definen procedimientos de comprobacin y refinamiento que aseguren que se produzcan documentos de alta calidad.

Los estndares de calidad del proceso de documentos deben se flexibles y les debe ser posible ajustarse a todos los tipos de documentos. Para los documentos de trabajo o memorando, no es necesario comprobar explcitamente la calidad. Sin embargo, si los documentos son documentos formales utilizados para desarrollos posteriores o son documentos a entregar a los clientes, se debe adoptar un proceso formal de calidad. La (figura 24.5) muestra uno de los modelos.

16


Crear un borrador, comprobarlo, revisarlo y rehacerlo es un proceso interactivo. Este contina hasta que se produce un documento de calidad aceptable. El nivel de calidad aceptable depende del tipo de documento y de los lectores potenciales de este. Los estndares del documento aplican a todos documentos producidos en el transcurso del desarrollo de software. Los documentos deben tener un estilo y una apariencia consistentes y los documentos del mismo tipo deben tener una estructura consistente. Aunque los estndares del documento se adaptan a las necesidades de un proyecto especifico, una buena prctica es que se utilice el mismo estilo en todos documentos producidos por una organizacin.

Algunos ejemplos de estndares de documentos a desarrollar son:

1. Estndares de identificacin de documentos. Puesto que los proyectos de sistemas de software grandes producen cientos documentos, cada documento debe identificarse de forma nica. Para los documentos formales, este identificador es el identificador formal definido por el administrador de la configuracin. Para documentos informales, el estilo del identificador del documento es definido por el administrador del proyecto. 2. Estndares de la estructura del documento. Cada clase de documentos producido durante un proyecto de software debe seguir alguna estructura estndar. Los estndares de estructura deben definir las secciones a incluir y especificar las convenciones utilizadas para numeracin de pginas, el encabezado de las pginas y la informacin de los pies de pginas, as como la numeracin de secciones y subsecciones. 3. Estndares de presentacin del documento. Estos estndares definen un estilo propio para los documentos y contribuyen de forma importante a la consistencia de los mismos. Incluyen la definicin de tipos de letra y estilo utilizados en el documento, la utilizacin de logotipos y los nombres de la compaa, la utilizacin de color para resaltar la estructura del documento, etc.

4. Estndar para actualizar los documentos. Conforme el documento evoluciona y refleja los cambios en el sistema, se debe utilizar una forma consistente para indicar

17


los cambios en el documento. Se pueden utilizar diversos colores de la portada para indicar una nueva versin del documento y cambiar las barras en el margen para indicar prrafos modificados o agregados.

2.4 CALIDAD DEL PROCESO Y DEL PRODUCTO

Una suposicin subyacente de la administracin de la calidad es que la calidad del proceso de desarrollo afecta directamente a la calidad de los productos a entregar. Esta suposicin se deriva de los sistemas de manufactura donde la calidad del producto esta ntimamente relacionada a los procesos de produccin. En efecto, en sistemas de informacin de produccin en masa, una vez que se ha asignado un nivel aceptable de la calidad del proceso, se sigue naturalmente la calidad del producto. La figura 24.6 ilustra este caso.

La calidad del proceso es muy impotente en el desarrollo del software. La razn esto es que es difcil medir los atributos de software, como la mantenibilidad, sin utilizar el software por un periodo largo. El mejoramiento de la calidad se centra en identificar buenos productos de calidad, examinar el proceso utilizado para desarrollar estos productos y despus generalizar estos procesos para que se apliquen a varios proyectos. Sin embargo, la relacin entre el proceso del software y la calidad del producto de software es compleja. Cambiar el proceso no siempre conduce a mejorar la calidad del producto.

18


Existe un vnculo claro entre la calidad del proceso y la calidad del producto en la manufactura debido a que el proceso es relativamente fcil de estandarizar y supervisar. Una vez que se calibran los sistemas, se ejecutan una y otra vez para producir producto de software de alta calidad. El software no se manufactura, se disea. Puesto que el desarrollo de software es un proceso creativo ms que mecnico, la influencia de las habilidades individuales y las experiencias es importante. Los factores externos, como la novedad de la aplicacin o la presin comercial para entregar un producto, tambin afectan la calidad del producto con respecto al proceso utilizado.

Sin embargo, la calidad del proceso tiene una influencia importante en la calidad del software. La administracin de la calidad del proceso comprende:

1. Definir estndares de proceso como las versiones a realizar, cuando llevarlas a cabo, etc. 2. Supervisar el proceso de desarrollo para asegurar que se sigan estndares. 3. Hacer informes del proceso para la administracin del proyecto y para el comprador del software.

Un peligro del aseguramiento de la calidad basada en procesos es que el proceso prescrito puede se inapropiado para el tipo de software a desarrollar. Por ejemplo, los estndares de calidad del proceso pueden indicar que una especificacin debe estar completa y aprobada antes que la implementacin inicie. Sin embargo, algunos sistemas requieren la construccin de prototipos, lo cual implica la implementacin del programa. El equipo de calidad puede indicar que ese prototipo no se puede llevar a cabo debido a que su calidad no se puede supervisar. En tales situaciones, el administrador principal debe intervenir para asegurar que el proceso de calidad ayude ms que impida el desarrollo del producto.

19


UNIDAD III (CONTROL Y PLANEACION DE LA CALIDAD) 3.1 PLANEACION DE LA CALIDAD

La planeacin de la calidad inicia en las primeras etapas del proceso del software. Un plan de calidad define la calidad del producto deseado. Define como valorar esta calidad. Por lo tanto define lo que significa software de alta calidad. Sin tal definicin, los diferentes ingenieros pueden trabajar en direcciones opuestas de tal forma que optimicen distintos atributos del producto. El resultado de un proceso de planeacin de la calidad es un plan de calidad del proyecto.

El plan de calidad selecciona aquellos estndares organizacionales apropiados para un producto en particular y un proceso de desarrollo. Si el proyecto utiliza nuevos mtodos y herramientas, se tienen que definir nuevos estndares. Humphrey (1989), en su libro clsico sobre administracin del software, sugiere una estructura para un plan de calidad. Esta estructura comprende:

1. Introduccin del producto. Contiene la descripcin del producto, el mercado al que se dirige y las expectativas de calidad del producto. 2. Planes del producto. Contiene las fechas de terminacin del producto y las responsabilidades importantes junto con los planes para distribucin y servicio. 3. Descripcin del proceso. Contiene los procesos de desarrollo y de servicio a utilizar para el desarrollo y administracin del producto. 4. Metas de calidad. Contiene las metas y planes de calidad par el producto, incluye una identificacin y justificacin de los atributos de calidad importantes del producto. 5. Riesgos administracin de riesgos. Contiene los riesgos clave que podran afectar la calidad del producto y las acciones para abordar estos riesgos.

20


Atributos de calidad de software

Seguridad Proteccin Fiabilidad Flexibilidad Robustez

Compresin Experimentacin Adaptabilidad Modularidad Complejidad

Portabilidad Usabilidad Reutilizacin Eficiencia Aprendizaje

3.2 CONTROL DE CALIDAD

El control de la calidad implica vigilar el proceso de desarrollo de software para asegurar que se sigan los procedimientos de aseguramiento y estndares de calidad. Los productos resultantes de un proceso de software se comprueban contra los estndares definidos del proyecto en el proceso d control de calidad.

El proceso de control de calidad tiene su propio conjunto de procedimientos e informes a utilizar durante el desarrollo de software. Estos procedimientos son directos y fcilmente comprensibles por los ingenieros de desarrollo de software.

Existen dos enfoques complementarios para el control de la calidad:

1. Revisin de la calidad en las que el software, su documentacin y los procesos utilizados para producir ese software son revisados por un grupo de personas. Son responsables de comprobar que se han seguido los estndares del proyecto y que el software y los documentos estn acordes a estos estndares. Toman las desviaciones de los estndares y las ponen a consideracin de la administracin del proyecto.

21


2. Valoracin automtica del software en la que el software y los documentos producidos se procesan por algn programa y se comparan con los estndares que aplican a este proyecto de desarrollo en particular. Esta valoracin automtica comprende una medida cuantitativa de algunos atributos del software.

3.3 REVISION DE LA CALIDAD Las revisiones son el mtodo ms utilizado para validar la calidad de un proceso o producto. Involucran a un grupo de personas que examinan parte o todo el proceso del software, los sistemas o su documentacin asociada para descubrir problemas potenciales. Las conclusiones de la revisin se registran formalmente y se pasan al autor o a quien sea responsable de corregir los problemas descubiertos.

El cometido del equipo de revisin es detectar los errores e inconsistencias y sealarlas al diseador o autor del documento. Las revisiones se basan en documentos pero no se limitan a las especificaciones, diseo o cdigo. Se revisan todos los documentos tales como los modelos del proceso, los planes de prueba, los procedimientos de administracin de la configuracin, los estndares del proceso y los manuales de usuario.

El equipo de revisin incluye aquellos miembros del proyecto que pueden hacer una contribucin efectiva. Por ejemplo, si se revisa el diseo de un subsistema, los diseadores de los subsistemas relacionados se incluyen en el equipo de revisin. Ellos proporcionan aspectos importantes en las interfaces de subsistemas que podran estar olvidadas si el subsistema se considera de forma aislada. El equipo de revisin tiene un cuerpo principal de tres a cuatros personas designadas como revisores principales. Uno de los miembros es el diseador principal que tiene responsabilidad de tomar decisiones tcnicas impotentes. Los revisores principales invitan a otros miembros del proyecto para que contribuyan en la revisin. Ellos no se involucran en la revisin de todo el documento. Ms bien, se concentran en aquellas partes que afectan a su trabajo. De forma alternativa, el equipo de revisin hace circular el documento a revisar y solicita comentarios escritos de otros miembros del equipo del proyecto.

22


Los documentos a revisar se distribuyen con anterioridad a ka revisin para dar tiempo a los revisores a que lo lean y comprendan. Aunque esto puede interrumpir el proceso de desarrollo, la revisin no es efectiva si el equipo de revisin no comprende adecuadamente los documentos antes de que tenga lugar la revisin. La revisin misma es relativamente corta (dos horas a lo ms). El autor del documento en revisin debe seguir el documento junto con el equipo de revisin. Un miembro del equipo preside la revisin y otro registra formalmente todas las decisiones de la revisin. Durante esta, el presidente es responsable de asegurar que se consideren todos los comentarios escritos. Al trmino de la revisin, se anotan las acciones y los formularios que registran los cometarios y las acciones son firmados por el diseador y el presidente de la revisin. Despus, estos pasan a formar parte de la documentacin formal del proyecto. Si solo se descubren problemas menores, no es necesaria una revisin adicional. El presidente es responsable de asegurar que se hagan los cambios requeridos. Si se requiere cambios importantes, se acuerda un seguimiento de la revisin.

3.4 TIPOS DE REVISIONES

Tipo de revisin Inspecciones de diseo o programas

Propsito principal Detectar errores finos en los

requerimientos, el diseo, o el cdigo. La revisin se conduce por una lista de verificacin de los posibles errores. Revisin de progreso Proveer informacin para administrar el progreso completo del proyecto. Esta es una revisin tanto del proceso como del producto y se refiere a los costos, planes y calendarizacin. Revisiones de calidad Llevar a cabo un anlisis tcnico de los componentes del producto o

documentacin para encontrar diferencias entre la especificacin y el diseo del

23


componente, cdigo y documentacin y para asegurar que se siguen los estndares de calidad definidos.

3.5 MEDICION Y METRICAS DE SOFTWARE

La medicin del software se refiere a derivar un valor numrico para algn atributo de un producto de software o un proceso del software. Comparando estos valores entre ellos y con los estndares aplicados en la organizacin, es posible sacar conclusiones de la calidad del software o de los procesos del software. Por ejemplo, suponga que una organizacin hace planes para introducir una nueva herramienta de prueba de software. Antes de introducir la herramienta, se registra el nmero de defectos descubiertos en el software en un tiempo dado; despus de introducir la herramienta, se repite este proceso. Si se descubren ms defectos en la misma cantidad de tiempo despus de introducir la herramienta, entonces parecera que provee ayuda til para el proceso de validacin del software. Varias compaa grandes tales como Hewlett-Packerd (Grandy, 1993) y AT&T (Barnard y Price, 1994) han introducido programas de mtricas que utilizan mtricas recolectadas en sus procesos de administracin de la calidad. El enfoque fue recolectar mtricas sobre defectos en los programas y en los procesos de verificacin y validacin. Offen y Jeffrey (1997) y Hall y Fenton (1997) discuten la introduccin de tales programas en la industria. El manual ami (Pulford 1996) da consejos detallados sobre la medicin y su utilizacin para la mejora de procesos. Sin embargo, aun es poco comn la utilizacin de medidas y mtricas sistemticas de software. Existe una reticencia para introducir medidas debido a que los beneficios no son claros. Una razn de esto es que, en muchas compaas, los procesos del software utilizados aun estn pobremente organizados y no son suficientemente maduros como para utilizar las medidas. Otra razn es que no existen estndares para las mtricas y, por lo tanto, existe ayuda limitada para la recoleccin y anlisis de datos. Muchas compaas no estarn preparadas para introducir mediciones hasta que estn disponibles tales estndares y herramientas.

24


Una mtrica de software es cualquier tipo de medida relacionada con un sistema, proceso o documentacin de software. Algunos ejemplos son las medidas que se utilizan para calcular el tamao de un producto en lneas de cdigo, el ndice de Fog (Gunning, 1962), que es una medida de la claridad de un prrafo en un texto escrito, el numero de fallas reportadas en un producto de software entregado y el numero de personas-da requeridas para desarrollar un componente del sistema. Las mtricas son de control o de prediccin. Las mtricas de control por lo general se asocian con los procesos del software; las mtricas indicadoras se asocian con los productos de software. Ejemplos de las mtricas de control o de procesos son el esfuerzo y el tiempo promedio requerido para reparar los defectos reportados. Ejemplos de mtricas de prediccin son la complejidad ciclomatica de un modulo, la longitud promedio de los indicadores en un programa y el numero de atributos y operaciones asociadas con los objetivos de un diseo. Ambas mtricas influyen en la toma de decisiones administrativas.

A menudo, es imposible medir los atributos de calidad del software de forma directa. Los atributos como la mantenibilidad, la complejidad y la compresin se ven afectados por diversos factores y no existen mtricas directas para ellos. Ms bien es necesario medir algn atributo interno del software (como el tamao) y suponer que existe una relacin entre lo que se puede medir y lo que se quiere saber. De forma ideal, existe una relacin clara valida entre los atributos de software internos y externos.

25


Figura 24.9 Metricas de prediccion Y control

Proceso de Desoftware

Producto de software

Medidas de control

Medidas de prediccion

Decisiones administrativas

La figura 24.10 muestra algunos atributos de calidad externos de inters y los atributos que pueden medirse y estar relacionados con los atributos externos. El diagrama sugiere que existe una relacin entre los atributos externos e internos pero no dice que relacin es. Si la medida del atributo interno es un indicador til de la caracterstica interna del software, se deben cumplir tres condiciones (Kitchenham, 1990).

26


1. El atributo interno debe medirse de forma precisa. 2. Debe existir una relacin entre lo que se puede medir y el atributo de comportamiento externo. 3. Esta relacin se comprende del todo, ha sido validada y se puede expresar trminos de una formula o modelo. en

3.6 PROCESO DE MESICION En la figura 24.11 se muestra el proceso de medicin del software que es parte de un proceso de control de calidad. Cada uno de los componentes del sistema se analiza por separado y los diversos valores de las mtricas se comparan entre ellos y, quizs, con los datos histricos de medicin recolectados en los proyectos previos. Las medidas anmalas se utilizan para centrar el esfuerzo de aseguramiento de la calidad de los componentes que tienen problemas de calidad.

27


Los pasos clave para este proceso son:

1. Seleccionar las medidas a realizar. Se deben formular las preguntas que la medicin intenta responder y definir las medidas requeridas para resolver estas preguntas. No se recolectan las mediciones que no sean relevantes de forma directa a estas preguntas. El paradigma GQM (Goal-Question-Metric) de basili (Basili y Rombach, 1988), es un buen enfoque a utilizar cuando se decide que datos recolectar.

2. Seleccionar los componentes a evaluar. No es necesario o deseable estimar los valores de las mtricas de todos los componentes de un sistema de software. En algunos casos, para la medicin se elige un conjunto representativo de componentes. En otros, se evalan los componentes crticos como los fundamentales que se utilizan de forma constante.

3. Medir las caractersticas de los componentes. Se miden los componentes seleccionados y se calculan los valores de las mtricas. Normalmente, esto comprende procesar la representacin del componentes (diseo, cdigo, etc) utilizando una herramienta de recoleccin de datos. Esta herramienta se puede crear de forma especial o puede estar incorporada en las herramientas CASE utilizadas en una organizacin.

4. Identificar las mediciones anmalas. Una vez que se obtienen las mediciones de los componentes, se comparan entre ellas y con las mediciones previas

registradas en una base de datos de mediciones. Se deben observar los valores ms altos y ms bajos de cada mtrica puesto que estos sugieren que puede haber problemas con los componentes que exhiben estos valores.

28


5. Analizar los componentes anmalos. Una vez identificados los componentes con valores anmalos para las mtricas particulares, se examinan estos componentes para decidir si los valores de la mtrica indican que la calidad del componente esta en peligro. Los valores de la mtrica anmalos para la complejidad (por ejemplo) no necesariamente significa que el componente tenga calidad deficiente. Puede existir alguna otra razn para el valor alto y no significa que existan problemas con la calidad del componente.

Los datos recolectados se mantienen como un recurso organizacional, de igual forma los registros histricos de todos los proyectos deben conservarse aun cuando los datos no se hayan utilizado durante un proyecto particular. Una vez que se haya creado una base de datos suficientemente grande de mediciones, se hace la comparacin con los proyectos y las mtricas especficas se refinan de acuerdo con las necesidades organizacionales.Figura 24.11 Proceso de medicion Del producto Analizar Componentes anomalos

Elegir medidas A realizar

Seleccionar Componenetes A evaluar

Identificar Medidas anomalas

Medir caracteristicas De los componentes

29


3.7 METRICAS DEL PRODUCTO

La mtrica del producto se refiere a las caractersticas del software mismo. Desafortunadamente, las caractersticas del software que se miden fcilmente como el tamao y la complejidad ciclomatica, los atributos de calidad como la compresin y la mantenibilidad no tienen una relacin clara y universal. Las relaciones varan dependiendo de los procesos y la tecnologa de desarrollo y el tipo de sistemas a desarrollar. Las organizaciones interesadas en la medicin tienen que construir una base de datos histricos. Despus, esto se puede utilizar para descubrir como se relacionan los atributos del producto de software con la calidad en la que esta interesada la organizacin.

Las mtricas del producto se dividen en dos clases:

1. Las mtricas dinmicas recolectadas por las mediciones hechas en un programa en ejecucin. 2. Las mediciones estticas recolectadas por las mediciones hechas en las representaciones del sistema como diseo, el programa o la documentacin.

Estas diferentes mtricas estn relacionadas con diversos atributos de calidad. Las mtricas dinmicas ayudan a valorar la eficiencia y la fiabilidad de un programa mientras que las estticas ayudan a valorar la complejidad, la compresin y la mantenibilidad de un sistema de software. Las mtricas dinmicas por lo general estn relacionadas de forma cercana con los atributos de calidad del software. Es relativamente fcil medir el tiempo de ejecucin requerido por funciones particulares y estimar el tiempo requerido para iniciar un sistema. Esto se relaciona directamente con la eficiencia del sistema. De forma similar, se puede registrar el nmero y el tipo de cadas del sistema y relacionarlos directamente la fiabilidad del software.

30


Mtrica de software Fan-in/Fan-out

Descripcin Fan-in es una medida del numero de funciones que llaman a otra funcin (por ejemplo, x). Fan-out es el nmero de funciones que son llamadas por una funcin X. Un valor alto de fan-in significa que X esta fundamentalmente acoplada al resto del diseo y que los cambios en X tendrn efectos extensivos contundentes. Un valor alto de Fan-out sugiere que la complejidad de X podra ser alta debido a la complejidad de la lgica de control necesaria para coordinar los componentes llamados.

Longitud del cdigo

Esta es una medida del tamao del programa. Generalmente, entre mas grande sea el tamao del cdigo de un componente del programa, mas complejo y susceptible a errores sea el componente.

Complejidad ciclomatica

Esta es una medida de la complejidad del control de un programa. Esta complejidad del control esta relacionada con la compresin del programa.

Longitud

de

los Es una medida de la longitud promedio de los diferentes identificadores en un programa. Entre mas grandes sea la longitud de los identificadores, es mas probable que tengan significado y, por lo tanto, el programa ser mas comprensible.

identificadores

Profundidad

de

la Esta es una medida de la profundidad de anidamiento de las instrucciones if en un programa. Instrucciones if profundamente anidadas son difciles de comprender y son potencialmente susceptibles a errores.

condicional anidada

Indice de fog

Esta es una medida de la longitud promedio de las palabras y declaraciones en los documentos. Entre mas grande sea el valor del ndice de Fog, el documento ser mas difcil de comprender.

31


Mtricas orientadas a objetos

Mtricas orientadas a objetos Profundidad herencia del rbol

Descripcin

de Esta representa el nmero de niveles discretos en el rbol de herencia donde las subclases heredan atributos y operaciones (mtodos) de las superclases. Entre mas profundo sea el rbol de herencia, mas complejo ser el diseo puesto que muchas clases de objetos potencialmente distintas tienen que

comprenderse para conocer las clases de objetos en la hoja del rbol. Metodo fan-in/fan-out Esta directamente relacionada a fan-in y a fan-out, como se describi antes, y significa esencialmente lo mismo. Sin embargo, es conveniente hacer una distincin entre las llamadas provenientes de otros mtodos dentro del objeto y las llamadas provenientes de los mtodos externos. Metodos pasados por clase Este es el nmero de mtodos incluidos en una clase con peso dado por la complejidad de cada mtodo. Por lo tanto, un mtodo sencillo tiene una complejidad de 1 y un mtodo grande y complejo un valor mucho ms grande. Entre ms grande sea el valor de esta mtrica, la clase ser mas compleja. Los objetos complejos tienden a ser ms difciles de comprender. No son lgicamente cohesivos por lo que no se pueden reutilizar efectivamente como superclases en un rbol de herencia. Numero anuladas de operaciones Este es el nmero de operaciones en una superclase que se anulan en una subclase. Un valor alto para esta mtrica indica que la superclase utilizada no es una madre adecuada para la subclase.

32


Mtricas de la calidad de un producto software Es difcil, y en algunos casos imposibles, desarrollar medidas directas de los factores de calidad del software Cada factor de calidad Fc se puede obtener como combinacin de una o varias mtricas: Fc= c1 * m1 + c2 * m2 + + cn *mnci factor de ponderacin de la mtrica i, que depender de cada aplicacin especfica mi mtrica i Habitualmente se puntan de 0 a 10 en las mtricas y en los factores de calidad

Mtricas para determinar los factores de calidad Facilidad de auditoria Exactitud Normalizacin de las comunicaciones Completitud Concisin Consistencia Estandarizacin de los datos Tolerancia de errores Eficiencia de la ejecucin Facilidad de expansin Generalidad Independencia del hardware Instrumentacin Modularidad Facilidad de operacin Seguridad Auto-documentacin Simplicidad Independencia del sistema software Facilidad de traza Formacin

33


UNIDAD IV (MODELO Y TECNICA DE LA CALIDAD) 4.1 MODELO DE CALIDAD

El CMM y la mejora contina del proceso de software Dentro de la competitividad actual, conseguir productos software excelentes a buen precio en mrgenes de tiempo estrechos es el sueo de miles de empresas. Ello se puede conseguir concentrando esfuerzos en torno a dos pilares fundamentales: Las personas por un lado, y los mtodos y procedimientos por otro. El Modelo de Madurez de Capacidad del Software (CMM) hace hincapi en la mejora del proceso de software en base a los procedimientos internos y sin descuidar a las personas.

4.2 LA MEJORA DEL PROCESO DE GESTIN DEL SOFTWARE Para conseguir tener un proceso de produccin de software sin fallos, adecuado a las necesidades estipuladas en un principio y entregado a tiempo, esta claro que la produccin de software debe convertirse en un proceso disciplinado y aceptado por todos.

Son varias las razones por las que puede fallar el proceso de software, mencionamos las tres principales:

1. El personal no se involucra lo suficiente en el control de calidad del trabajo. 2. La alta direccin no ha adquirido conciencia de la importancia de un buen proceso de software para su compaa, la principal consecuencia de esto es que el proceso de software no tiene los recursos adecuados ya sea en forma de tiempo, dinero, tecnologa, personal y formacin de este. 3. Las prcticas establecidas no son las adecuadas.

34


Hasta ahora hemos empleado el termino "proceso de software", pero qu queremos decir con este trmino?: "Un proceso es un conjunto de pasos definidos para lograr una tarea", mientras que "un proceso definido es aquel que esta escrito a tal detalle que permite que los ingenieros lo usen constantemente". Los procesos definidos ayudan a la planificacin y desarrollo de un trabajo. El proceso que establezcamos debe ser flexible y debe facilitar el cambio y la innovacin. Al mismo tiempo el proceso debe poder ser aprendido. Aqu es donde entra el CMM o "Modelo de Madurez de Capacidad del Software". El CMM esta destinado a la evaluacin y mejora de procesos. Se debe evaluar a la organizacin para conocerla ya que sin conocerla no se puede mejorar. El propsito de CMM es guiar a las organizaciones en la seleccin de estrategias de mejora determinando la madurez del proceso actual e identificando los puntos importantes que se deben estudiar y trabajar para mejorar tanto el proceso como la calidad del software. Dicho en palabras de Dymon [Dymon 1997] ayudar a las personas a identificar aquellas actividades crticas que indican la capacidad para realizar de la organizacin. Hay dos razones fundamentales para creer la efectividad de este modelo:

1. El modelo CMM esta construido en base a prcticas reales. 2. Cada nueva (y correcta) implementacin del CMM es un nuevo xito. El modelo de madurez de capacidad del software (cmm) Acabamos de ver una pequea introduccin al significado del CMM. Tambin consideramos brevemente las ventajas de su empleo en una organizacin. Ahora bien, tan bueno es el CMM que no tiene ningn inconveniente? Por supuesto que el CMM tiene inconvenientes, aunque mejor deberamos llamarlo riesgos.

El CMM puede ser mal interpretado, para evitarlo es conveniente que las personas que lo utilicen comprendan el modelo y sus implicaciones a la hora de aplicarlo a la organizacin. Este modelo es fruto del trabajo de SEI (Software Engineering Institute), desde 1986 centra sus esfuerzos en mejorar la practica del proceso del Software. En 1991 consiguieron

35


estabilizar la primera versin del CMM. Desde entonces este modelo se ha empleado en organizaciones tales como el Departamento de Defensa de los EEUU, sedes que necesitaban controlar de manera exhaustiva el proceso de produccin de software.

El CMM es una forma de comprender la propia gestin de procesos dentro de la organizacin. Es cierto que el CMM evala a la organizacin ya que para mejorar es preciso, antes, evaluar. Pero no podemos cometer el error de reducir el CMM a una mera lista de comprobacin, el CMM es mucho ms que eso, es una "institucionalizacin" del proceso para construir software con el objetivo de conseguir una mejora continua. A la hora de aplicar el CMM debemos tener claro una serie de aspectos sobre la organizacin, dichos aspectos son:

1. El tamao de la organizacin. 2. Su nivel cultural. 3. Las tecnologas que emplea.

Conociendo estos tres puntos podemos acometer el conocimiento de los objetivos de la organizacin. Posteriormente deberemos decidir como vamos a medir.

El CMM establece 5 posibles niveles de madurez en los que puede encontrarse una organizacin:

a) Nivel 1: El ms bsico. b) Nivel 2 (el proceso repetible). c) Nivel 3 (el proceso definido). d) Nivel 4 (el proceso gestionado). e) Nivel 5 (el proceso de optimizacin).

36


Nadie puede obtener el significado exclusive del CMM. El CMM no aporta una medida absoluta, no existe un nivel de 2'5, todos los resultados deben ser interpretados, mejor as ya que el CMM es flexible para adaptarse en su utilizacin a las peculiaridades de cada organizacin. Debido a este punto, el conocimiento del Modelo por parte de quien lo aplica se hace an ms importante.

Nos queda ahora abordar en profundidad el proceso del CMM, para ello debemos tener en cuenta las siguientes definiciones [Paulk 1994]:

a) Institucionalizar: Edificar una infraestructura y una cultura que soporte los mtodos, las prcticas y los procesos para que stos sean la forma real de hacer negocios. Ser fundamental conocer cual es el grado de conocimientos de todos sus trabajadores, as como el esquema cultural y social en que se ubica la empresa.

b) Proceso de Software: Conjunto de actividades, mtodos, prcticas y transformaciones para desarrollar y mantener software y productos asociados.

c) Capacidad de un proceso: Rango de resultados esperados que se pueden obtener tras seguir un proceso.

d) Madurez de un proceso de software: Es el punto hasta el que un determinado proceso est explcitamente definido, administrado, medido, controlado y ejecutado de manera efectiva.

e) Nivel de madurez: Plataforma bien definida desde la que podemos obtener un proceso maduro de software.

f) Procedimiento documentado: La actividad o procedimiento es un proceso rutinario y que ha sido codificado.

37


4.3 CARACTERSTICAS DEL CMM Comenzaremos este apartado dando una definicin formal al CMM [Dymon1997]. El CMM es un modelo que describe cmo las prcticas de la ingeniera del software de una organizacin evolucionan bajo ciertas condiciones:

1.- El trabajo es organizado y visto como un proceso. 2.- La evolucin del proceso es gestionada sistemticamente.

El CMM guarda cierta relacin con los estndares de calidad como ISO 9001, en palabras de Dymon, este estndar es efectivo para proporcionar una base de una buena prctica por debajo de la cual una organizacin no debera descender. Por el contrario, el CMM es un estndar progresivo con una dimensin dinmica que conduce a una organizacin a mejorar continuamente sus prcticas actuales de software.

Segn los estudios realizados por el SEI una organizacin que se encuentre en un nivel de madurez 3 podra obtener sin problemas la certificacin ISO 9001. Pero una organizacin que posea una certificacin ISO 9001 podra quedar ubicada en un nivel de madurez 2 o 3, dependiendo del caso. Para obtener mayores detalles en esta comparacin se puede consultar la obra [Paulk 1994]. CARACTERSTICAS DE LOS NIVELES DEL MODELO DE CMM

Nivel Inicial (Procesos Disciplinado)

Caractersticas Poca formalizacin, junto con herramientas informalmente aplicadas al proceso Se logro un proceso Repetible estable con un nivel (Procesos Estandarizados) repetible de control estadstico Se logro una base para un Definido progreso mayor continuo (Procesos Predecibles)

Transicin al Siguiente Nivel Iniciar una administracin rigurosa del proyecto, y asegurar la clida

Establecer un grupo de proceso y una arquitectura de proceso de desarrollo de software. Introducir mtodos y tecnologas de ingeniera de software Establecer un conjunto bsico de administraciones de proceso para identificar la calidad y costo de los parmetros y una base de datos del

38


Administrado (Procesos Mejora Continua) Optimizado

Mejoras sustanciales en calidad junto con medidas comprensivas del proceso Mejoras en Base a mayor calidad y cantidad

proceso. Juntar y mantener datos del proceso e informar a la administracin Apoyar la recopilacin automtica de datos del proceso. Usar datos para analizar y modificar el proceso Continuar Mejorando y optimizando el proceso.

Detallemos ahora un poco ms los distintos niveles de madurez:

1) Nivel 1: Nivel inicial, el proceso de software es impredecible y poco controlado. Esto no significa que una organizacin no produzca buen software, sino que el coste (financiero, humano, temporal, etc.) es demasiado alto tanto para los productores como para los usuarios.

2) Nivel 2: Nivel repetible, en este nivel existe una disciplina bsica en la gestin de procesos basada en la repeticin de tareas aprendidas previamente. Ya hay una planificacin en trminos de coste, calendario y requisitos.

3) Nivel 3: Nivel definido, el proceso es estndar y consistente, se conoce lo que hace que el proceso de software tenga xito y se aplica a toda la organizacin.

4) Nivel 4: Nivel gestionado, el proceso del nivel 3 es medido y controlado cuantitativamente, est implementado en toda la organizacin.

5) Nivel 5: Nivel optimizado, existe una evolucin continua en la optimizacin del proceso. El CMM se centra en los tres principales aspectos que influyen en una organizacin: a) Las personas: Se trata por disciplinas como el desarrollo organizativo, gestin de los RRHH y la Gestin de la Calidad Total (TQM).

39


b) La tecnologa: La tecnologa cambia a su propio ritmo a lo largo del tiempo, se puede adquirir.

c) El proceso. Pero, cmo se gestiona el proceso y cmo se mejora?, se puede comprar? La gestin del proceso se puede aprender e institucionalizar, aqu es donde entra el CMM.

La complejidad aparente del CMM se simplifica en cuatro conceptos base:

- La evolucin es posible pero lleva tiempo. - Hay etapas distinguibles en la madurez del proceso. - La evolucin implica que algunas cosas deben ser aplicadas antes que otras. - La madurez disminuir al menos que se mantenga. Los cambios duraderos requieren un esfuerzo constante [Dymon 1997]. Para cambiar el proceso del software debemos: Gestionar las influencias. Gestionar las mejoras sistemticas.

El cambio puede empezar a aplicarse a travs del ciclo de Deming: Planificar, Hacer, Verificar y Actuar [Deming 1982]. Adaptado a nuestra situacin, Iniciar es acordar el motivo y la estrategia para el cambio. Diagnosticar es acordar qu cambiar, posteriormente debemos Establecer la infraestructura (equipos y planes), Actuar (llevar a cabo los planes) e Institucionalizar (capturar y reutilizar las lecciones aprendidas).

Volvemos aqu a insistir en algo de crucial importancia, la aplicacin del modelo requiere el compromiso de la alta direccin ya que est claro que durante un tiempo ciertos recursos deberan desviarse de las actividades de generar ingresos y dedicarse a la mejora del proceso.

40


4.4 MODELO ISO 9000 Historia Se denomina ISO 9000 a una serie de estndares que pueden ser usados por diferentes empresas para establecer la gestin de un sistema de calidad. Pero hay que aclarar que ISO 9000 no tiene nada que ver con la calidad absoluta del producto; slo se refiere a la forma de establecer guas para un sistema de gestin de la calidad. Los estndares fueron publicados por primera vez en 1987, por la International Organization for Standardization (ISO), cuya sede central est en Ginebra, Suiza. Hasta cierto punto, los estndares britnicos BS 5750 sirvieron de base para las series ISO 9000. Y ms lejos an, otra referencia clara para ISO 9000 son los estndares generados durante la Segunda Guerra Mundial en los Estados Unidos, con especificaciones militares muy precisas, que tenan por objetivo evitar la falta de coordinacin entre distintos fabricantes o suministradores de armas y otros productos. Estas especificaciones pasaran posteriormente a la OTAN bajo la denominacin AQAP. La serie ISO 9000 se compone de cinco documentos independientes aunque relacionados. El estndar ISO 9000 es una gua para la seleccin y uso de los estndares reales, ISO 9001, ISO 9002 e ISO 9003. ISO 9000 incluye las siguientes definiciones para el resto de la serie: Poltica de Calidad Gestin de Calidad Sistema de Calidad Control de Calidad Aseguramiento de la Calidad

Impacto de ISO 9000 Desde su introduccin, ISO 9000 ha tenido un impacto creciente en el comercio internacional y es considerado el lenguaje comn sobre la calidad. Los estndares han sido redactados intencionadamente de manera muy amplia, as que pueden ser aplicados a empresas de muy diverso tamao en todos los sectores de actividad econmica.

41


La mayor fuerza de empuje para ISO 9000 en los ltimos aos ha sido el Acta nica Europea, ya que la Unin Europea necesitaba un sistema de harmonizacin para todos sus miembros, que han desarrollado sus respectivas industrias de manera independiente y con hbitos comerciales muy diferentes. ISO 9000 ha proporcionado una buena herramienta de puesta en comn.

Objetivos El propsito de ISO 9000 es incrementar la confianza de los clientes y consumidores en el sistema de calidad de sus suministradores. Un dato que es particularmente importante cuando se amplan las distancias entre las partes, o se usan diferentes idiomas y trminos. ISO 9000 proporciona el marco comn necesario, con requerimientos generales especficos para ambas partes. El objetivo, pues, no es determinar que un producto es superior a otro, sino ms consistente y fiable en su produccin. Es decir, ISO asegura que la produccin genera productos de una calidad homognea (sea sta alta o baja) a lo largo del tiempo. Es decir, un producto de hoy ha de ser igual que un producto de ayer y lo mismo que uno de maana.

Qu es Calidad y Sistema de Calidad El trmino Calidad designa muchas cosas distintas para distintas personas. Es una idea muy subjetiva. Adems, el producto de mayor calidad no es necesariamente el mejor para realizar un trabajo concreto, que tal vez necesite gastar su presupuesto en otras necesidades ms importantes. En trminos generales, pues, ISO se refiere a Calidad como "apropiado para el uso". Y un Sistema de Calidad es "la planificacin y sistematizacin de todas las actividades necesarias para llegar a un adecuado nivel de confianza". En palabras sencillas: "decir lo que se hace, hacer lo que se dice, archivar lo que se hizo, comprobar los resultados y actuar sobre las diferencias que se encuentren en ellos".

42


Dos tipos de estndares en ISO 9000 En la serie 9000 hay dos tipos de estndares. Unos son Estndares Gua, como ISO 9000 y 9004; su misin es describir los parmetros principales y ayudar a elegir los estndares apropiados. El segundo tipo son los Estndares de Conformidad, ISO 9001, 9002 y 9003. Las empresas u organizaciones slo pueden ser certificadas para uno de estos tres estndares de la serie. Qu diferencias existen entre los Estndares de Conformidad Debe quedar claro que los tres estndares de conformidad NO son ni representan niveles de calidad, sino que varan en el grado de amplitud de la estandarizacin.

ISO 9003 : Es un modelo para la Conformidad de Calidad en la Inspeccin Final. ISO 9002 : Es un modelo para la Conformidad de Calidad en Produccin, Instalacin y Servicios.

ISO 9001 : Es un modelo para la Conformidad de Calidad en el Diseo, Desarrollo, Produccin, Instalacin y Servicios.

Dudas y preguntas sobre ISO 9000 Cunto dura el proceso de certificacin?: Alrededor de dos aos. Decir realmente lo que se hace: cuando se describen los procedimientos productivos, no hay que tratar de que suenen bien; hay que hacerlos reales. Una vez puestos sobre el papel, hay que cumplirlos. ISO no es igual a Gestin de Calidad Total: ISO es un sistema para asegurar la consistencia en la produccin; la Gestin de Calidad Total busca generar un proceso empresarial de continua mejora. Revisiones peridicas: Una vez que una empresa consigue el certificado de estandarizacin no termina el papel de ISO; un auditor independiente puede ser requerido para realizar comprobaciones, incluso cada seis meses. Adems, los estndares ISO 9000 tienen una duracin de cinco aos, despus de los cuales deben ser revisados.

43


Beneficios de ISO 9000

1: Ayuda a centrar la empresa sobre el problema de producir con calidad. 2: Puede contribuir a superar una situacin anterior de desorganizacin productiva. 3: Determina las responsabilidades de cada uno en la cadena productiva y registra todo el proceso para verificar dnde se producen los fallos.

4: Mejora la competitividad en el mercado y la fiabilidad de los clientes 5: Puede disminuir el conjunto de los gastos productivos, al aumentar la eficacia.

4.5 FACTORES QUE DETERMINAN LA CALIDAD DE SOFTWARE

UN PRODUCTO DE

Se clasifican en tres grupos: Operaciones del producto: caractersticas operativas Correccin (Hace lo que se le pide?) El grado en que una aplicacin satisface sus especificaciones y consigue los objetivos encomendados por el cliente Fiabilidad (Lo hace de forma fiable todo el tiempo?) El grado que se puede esperar de una aplicacin lleve a cabo las operaciones especificadas y con la precisin requerida Eficiencia (Qu recursos hardware y software necesito?) La cantidad de recursos hardware y software que necesita una aplicacin para realizar las operaciones con los tiempos de respuesta adecuados Integridad (Puedo controlar su uso?) El grado con que puede controlarse el acceso al software o a los datos a personal no autorizado Facilidad de uso (Es fcil y cmodo de manejar?) El esfuerzo requerido para aprender el manejo de una aplicacin, trabajar con ella, introducir datos y conseguir resultados. Revisin del producto: capacidad para soportar cambios Facilidad de mantenimiento (Puedo localizar los fallos?)

44


El esfuerzo requerido para localizar y reparar errores Flexibilidad (Puedo aadir nuevas opciones?) El esfuerzo requerido para modificar una aplicacin en funcionamiento Facilidad de prueba (Puedo probar todas las opciones?) El esfuerzo requerido para probar una aplicacin de forma que cumpla con lo especificado en los requisitos.

Transicin del producto: adaptabilidad a nuevos entornos Portabilidad (Podr usarlo en otra mquina?) El esfuerzo requerido para transferir la aplicacin a otro hardware o sistema operativo Reusabilidad (Podr utilizar alguna parte del software en otra aplicacin?) Grado en que partes de una aplicacin pueden utilizarse en otras aplicaciones Interoperabilidad (Podr comunicarse con otras aplicaciones o sistemas informticos? El esfuerzo necesario para comunicar la aplicacin con otras aplicaciones o sistemas informticos.

4.6 CERTIFICACIN DE LA CALIDAD (QUALITY CERTIFICATION)

Un sistema de certificacin de calidad permite una valoracin independiente que debe demostrar que la organizacin es capaz de desarrollar productos y servicios de calidad Los pilares bsicos de la certificacin de calidad son tres [Sanders 1994, p. 44] : Una metodologa adecuada Un medio de valoracin de la metodologa La metodologa utilizada y el medio de valoracin de la metodologa deben estar reconocidos ampliamente por la industria

45


4.7 NORMAS DE LA SERIE ISO 9000:2000 El sistema de gestin de calidad propuesto por la norma ISO 9000:2000 se basa en 8 principios:

1. Enfoque al cliente: las organizaciones dependen de sus clientes y por lo tanto deberan comprender las necesidades actuales y futuras de los clientes, satisfacer los requisitos de los clientes y esforzarse en exceder las expectativas de los clientes.

2. Liderazgo: los lderes establecen la unidad de propsito y la orientacin de la organizacin. Ellos deberan crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organizacin

3. Participacin del personal: El personal, a todos los niveles, es la esencia de una organizacin y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de la organizacin.

4. Enfoque basado en procesos: Un resultado deseado se alcanza ms eficientemente cuando las actividades de los recursos relacionados se gestionan como un proceso.

5. Enfoque de sistema para la gestin: identificar, entender y gestionar los procesos interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una organizacin en el logro de sus objetivos.

6. Mejora continua: la mejora continua del desempeo global de la organizacin debera ser un objetivo permanente de sta.

7. Enfoque basado en hechos para la toma de decisin: las decisiones eficaces se basan en el anlisis de los datos y la informacin.

46


8. Relaciones mutuamente beneficiosas con el proveedor: una organizacin y sus proveedores son interdependientes, y una relacin mutuamente beneficiosa aumenta la capacidad de ambos para crear valor.

La figura ilustra el sistema de gestin de calidad basado en procesos descrito en la familia de normas ISO 9000. Esta ilustracin muestra que las partes interesadas juegan un papel significativo para proporcionar elementos de entrada a la organizacin. El seguimiento de la satisfaccin de las partes interesadas requiera la evaluacin de la informacin relativa a su percepcin de hasta que punto se han cumplido sus necesidades y expectativas.

47


Sistema de Gestin de Calidad Mejora continuaResponsabilidad de la direccin

C l i e n t e

SatisfaccinProducto/ Servicio

Requisitos

Gestin de recursos

Medicin, anlisis, mejora

Entrada

Realizacin del producto y/o servicio

Resultado

C l i e n t e

Sistema de Gestin de Calidad

Actividades que aportan valor Se distinguen cuatro grupo de procesos. 1) Responsabilidad de la direccin a) Compromiso de la direccin b) Enfoque al cliente c) Poltica de calidad d) Planificacin e) Responsabilidad, autoridad y comunicacin f) Revisin de la direccin 2) Gestin de los recursos a) Recursos humanos b) Infraestructura c) Ambiente de trabajo

Flujo de informacin

3) Realizacin del producto a) Planificacin de la realizacin del producto. b) Procesos relacionados con el cliente. c) Diseo y desarrollo. d) Compras. e) Produccin y prestacin del servicio. f) Control de los dispositivos de seguimiento y medicin. 4) Medicin, anlisis y mejora a) Seguimiento y medicin 48


b) Control del producto no conforme c) Anlisis de datos d) Mejora 4.8 ESTRUCTURA DE ISO 9000:2000 La serie ISO 9000:2000 est compuesta por tres normas: ISO 9000:2000- Sistemas de gestin de la calidad: Fundamentos y vocabulario ISO 9001:2000- Sistemas de gestin de la calidad: Requisitos ISO 9004:2000- Sistemas de gestin de la calidad: Directrices para la mejora del desempeo. La Norma ISO 9000:2000 constituye una norma explicativa del enfoque de procesos y de los principales elementos de un sistema de calidad. Contiene tambin una relacin completa del vocabulario utilizado en Gestin de Calidad.

Las Normas ISO 9001:2000 e ISO 9004:2000 constituyen un par consistente. Esto es, tiene la misma estructura organizativa.

La ISO 9001:2000 indica los requisitos que una organizacin debe cumplir, con relacin a su Sistema de Gestin de la Calidad, cuando este sistema es evaluado por una organizacin independiente, con relacin a su proceso de certificacin. La ISO 9004:2000, con la misma estructura de la 9001, constituye una gua para la mejora del desempeo de las organizaciones. O sea, ISO 9001 e ISO 9004 han sido diseadas para complementarse entre s.

ISO 9004 proporciona orientacin sobre un rango ms amplio de objetivos de un sistema de gestin de la calidad que ISO 9001, especialmente para la mejora continua y la eficiencia global de la organizacin, as como su eficacia. Sin embargo la Norma ISO 9004:2000 no est elaborada con propsitos de certificacin.

49


4.9 MODELOS DE EXCELENCIACRITERIOS PARA LA EXCELENCIA ACADMICA - MALCOLM BALDRIGEESTRATEGIAS, DESAFOS, RELACIONES, PLANES DE ACCION

2PLANEAMIENTO ESTRATGICO

5GESTION DE LAS PERSONAS

7RESULTADOS DEL DESEMPEO DE LA ORGANIZACIN

1LIDERAZGO

3FOCO EN LA SATISFACCION DEL ALUMNO, PARTES INVOLUCRADAS, Y MERCADO

6GESTION DE LOS PROCESOS

4

INFORMACIN Y ANALISIS

1.- Liderazgo: Liderazgo organizacional. Responsabilidad Pblica y Ciudadana. 2.- Planeamiento estratgico: Proceso de planeamiento estratgico. Planeamiento operativo. 3.- Enfoque en el alumno y en las otras partes involucradas: Conocimiento de las necesidades y expectativas del alumno (actual y potencial). Gestin de la relacin y satisfaccin del alumno y otras partes involucradas 4.- Informacin y Anlisis: Medicin del desempeo de la organizacin. Anlisis del desempeo de la organizacin 5.- Desarrollo del cuerpo docente, de gestin y apoyo: Sistema de trabajo. Educacin, entrenamiento y desarrollo del personal acadmico y de apoyo. Bienestar y satisfaccin del cuerpo docente y personal de apoyo. 6.- Gestin de los procesos educativos y de apoyo: Diseo y gestin del proyecto pedaggico-educativo. Gestin de procesos de apoyo. Gestin del las relaciones con etapas anteriores y posteriores 7.- Resultados de desempeo de la organizacin: Resultados del desempeo de los alumnos.

50


Resultados de la satisfaccin de los alumnos y otras partes involucradas.. Resultados de los docentes y personal de apoyo. Resultados financieros y presupustales. Resultados del desempeo y efectividad general de la organizacin.

Las dimensiones de evaluacin que normalmente se utilizan, en los modelos de excelencia, son tres: Enfoque: se refiere a la filosofa de diseo de los sistemas, los mtodos, principios y conceptos que son empleados para alcanzar el propsito de calidad en cada uno de los temas de evaluacin. Al analizar este aspecto, la evaluacin se har tomado en cuenta: o El grado en que se est orientado hacia la prevencin ms que la correccin o El grado en que se tiende hacia la mejora de los procesos, ms que a la correccin de los productos. o El grado en que se fomenta la toma de decisiones basadas en informacin y datos, ms que en opiniones. o El grado en que se busca estimular la autoevaluacin por parte del personal, ms que la inspeccin o supervisin. o El grado en que los procesos se orientan primordialmente a lograr la satisfaccin del cliente (procesos eficaces). o El grado en que se trabaja en la mejora de la eficiencia de los procesos. o El grado en que se tiende hacia contar con procesos sistemticos e integrales, buscando propiciar la mejora continua.

Implantacin: se refiere al nivel de aplicacin del enfoque e incluye: o El alcance con que se han introducido apropiada y efectivamente los principios de calidad en todas las reas, funciones y actividades de la organizacin. o La prctica sistemtica y rutinaria de los principios de calidad, en todas las actividades e interacciones clientes proveedor, tanto al interior como al entorno de la organizacin (clientes, proveedores y la sociedad en general) 51


Resultados: son los logros derivados de la Implantacin y el Enfoque de los sistemas en la organizacin. Incluyen informacin cuantitativa, cualitativa, comparacin de parmetros e impactos de los logros. Se toma en cuenta la calidad de los resultados, o sea los niveles alcanzados, como tambin la duracin de los resultados, o sea la tendencia. Se consideran los siguientes aspectos: o Nivel de calidad alcanzada, comparndolos con los competidores lderes, tanto nacionales como mundiales. o Tendencias de mejora continua y rapidez de dichas mejoras o Impacto que dichos logros han tenido en la posicin competitiva, participacin en los mercados, retencin de los clientes y rentabilidad de la organizacin. o Mejora de calidad de la vida de sus empleados y trabajadores. o Mejora y desarrollo de sus proveedores o Mejora del bienestar de los consumidores. o Mejora en el entorno social y en el medio ambiente.

4.10 EL MODELO DE McCALL. El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto, basndose en once factores de calidad organizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios: Puntos De Vista O Ejes Factor Criterios

OPERACIN Facilidad de uso - Facilidad de operacin: Atributos del software que DEL determinan la facilidad de operacin del software. PRODUCTO - Facilidad de comunicacin: Atributos del software que proporcionan entradas y salidas fcilmente asimilables. - Facilidad de aprendizaje: Atributos del software que facilitan la familiarizacin inicial del usuario con el software y la transicin del modo actual de operacin. - Formacin: El grado en que el software ayuda para

52


permitir que nuevos usuarios apliquen el sistema.

Integridad

- Control de accesos. Atributos del software que proporcionan control de acceso al software y los datos que maneja. - Facilidad de auditora: Atributos del software que facilitan la auditora de los accesos al software. - Seguridad: La disponibilidad de mecanismos que controlen o protejan los programas o los datos.

Correccin

- Completitud: Atributos del software que proporcionan la implementacin completa de todas las funciones requeridas. - Consistencia: Atributos del software que proporcionan uniformidad en las tcnicas y notaciones de diseo e implementacin. - Trazabilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los requisitos a la implementacin con respecto a un entorno operativo concreto.

OPERACIN DEL PRODUCTO

Fiabilidad

- Precisin: Atributos del software que proporcionan el grado de precisin requerido en los clculos y los resultados. - Consistencia. - Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales. - Modularidad: Atributos del software que proporcionan una estructura de mdulos altamente independientes. - Simplicidad: Atributos del software que posibilitan la implementacin de funciones de la forma ms comprensible posible. - Exactitud: La precisin de los clculos y del control.

53


Eficiencia

- Eficiencia en ejecucin: Atributos del software que minimizan el tiempo de procesamiento. - Eficiencia en almacenamiento: Atributos del software que minimizan el espacio de almacenamiento necesario.

REVISION DEL PRODUCTO

Facilidad de - Modularidad. mantenimiento - Simplicidad. - Consistencia. - Concisin: Atributos del software que posibilitan la implementacin de una funcin con la menor cantidad de cdigos posible. - Auto descripcin: Atributos del software que proporcionan explicaciones sobre la implementacin de las funciones. Facilidad de prueba - Modularidad. - Simplicidad. - Auto descripcin. - Instrumentacin: Atributos del software que posibilitan la observacin del comportamiento del software durante su ejecucin para facilitar las mediciones del uso o la identificacin de errores. Flexibilidad - Auto descripcin. - Capacidad de expansin: Atributos del software que posibilitan la expansin del software en cuanto a capacidades funcionales y datos. - Generalidad: Atributos del software que proporcionan amplitud a las funciones implementadas.

- Modularidad. Reusabilidad - Auto descripcin. - Generalidad.

54


- Modularidad. -Independencia entre sistema y software: Atributos del software que determinan su dependencia del entorno operativo. - Independencia del hardware: Atributos del software que determinan su dependencia del hardware. Interoperabilidad - Modularidad. - Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso de protocolos de comunicacin e interfaces estndar. - Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos estndar. - Estandarizacin en los datos: El uso de estructuras de datos y de tipos estndar a lo largo de todo el programa. Portabilidad - Auto descripcin. - Modularidad. -Independencia entre sistema y software. - Independencia del hardware.

4.11 CMO EMPLEAR EL MODELO DE McCall. Antes de comenzar a utilizar el modelo de McCall hay que seguir las siguientes pautas: 1. Se aceptan los factores, criterios y mtricas que propone el modelo. 2. Se aceptan las relaciones entre factores y criterios, y entre criterios y mtricas. 3. Se selecciona un subconjunto de factores de calidad sobre los que aplicar los requisitos de calidad establecidos para el proyecto. Al comienzo del proyecto habr que especificar los requisitos de calidad del producto software, para lo cual se seleccionarn los aspectos inherentes a la calidad deseada del producto, teniendo que considerarse para ello:

55


Las caractersticas particulares del propio producto que se est diseando: por ejemplo, su ciclo de vida que si se espera que sea largo implicar un mayor nfasis en la facilidad de mantenimiento y la flexibilidad, o bien si el sistema en desarrollo est destinado a un entorno donde el hardware evoluciona rpidamente implicar como requisito su portabilidad.

La relacin calidad-precio, que puede evaluarse a travs del coste de cada factor de calidad frente al beneficio que proporciona. La siguiente tabla muestra la relacin calidad-precio para cada factor considerado:

Factor Correccin Fiabilidad Eficiencia Integridad Facilidad de uso Facilidad de prueba Flexibilidad Portabilidad Reusabilidad Interoperabilidad

Beneficio / coste alto alto bajo bajo medio alto medio medio medio bajo

Facilidad de mantenimiento alto

La determinacin de las etapas del ciclo de vida donde es necesario evaluar cada factor de calidad para conocer en cuales se dejan sentir ms los efectos de una calidad pobre con respecto a cada uno de los factores.

Las propias interrelaciones entre los factores debido a que algunos factores pueden entrar en conflicto entre s: por ejemplo, la eficiencia plantea conflictos prcticamente con todos los dems factores de calidad. La interaccin entre los diversos factores a evaluar queda reflejada en la tabla I que indica la dependencia entre los factores de McCall.

56


Tambin habr que establecer valores deseables para los criterios, para lo cual se emplearn datos histricos, el promedio en la industria, y con ellos se concretarn los valores finales y otros intermedios o predictivos en cada perodo de medicin durante el desarrollo, as como unos valores mnimos aceptables. La explicacin para cualquier seleccin o decisin deber ser adecuadamente documentada. En la fase de desarrollo ser necesario implementar las mtricas elegidas, analizar sus resultados y tomar medidas correctivas cuando los valores obtenidos estn por debajo de los mnimos aceptables. Una vez finalizado el proyecto ser necesario contrastar las medidas predictivas utilizadas y comprobar si, en efecto, se pueden tomar como indicadores de los valores finales.

57


4.12 Proceso Unificado de Rational) RUP es un proceso para el desarrollo de un proyecto de software que define claramente quien, cmo, cundo y qu debe hacerse en el proyecto, con 3 caractersticas esenciales, est dirigido por los Casos de Uso: que orientan el proyecto a la importancia para el usuario y lo que este quiere , est centrado en la arquitectura: que Relaciona la toma de decisiones que indican cmo tiene que ser construido el sistema y en qu orden, y es iterativo e incremental: dividindose el proyecto en mini proyectos donde los casos de uso y la arquitectura cumplen sus objetivos de manera ms depurada.

58


Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de diversos artefactos y d

material de clase

Documents