Calidad de Software - Material de Estudio

CALI AD DE SOFTWAR

MAT RIAL DE ESTUDI

ING.

ELIPE ALIAGA CAVER

2010-II

CALIDAD DE SOFTWARE

CONTENIDO

NIDAD DIDÁCTICA N° 01:

FUNDAME TOS DE LA CALIDAD DEL SOFTWA E


MODELOS

ESTÁNDARES DE CALIDAD DE SOFT ARE


MÉTR CAS DE CALIDAD DEL SOFTWARE


EJECUCIÓN DEL CONTROL DE CALIDAD DE SOFT ARE

ING. FELIPE OMAR ALIAGA CAVERO

2

CALIDAD DE SOFTWARE

NIDAD NID AD DIDÁCTIC DIDÁ CTICA A N° 01 FUNDAMEN OS DE LA CALIDAD DE SOFT ARE

UNDAMENTOS DE CALIDAD Introducción La calidad es el factor b sico de decisión del cliente para un número de productos y servicios que hoy crece en form explosiva. La calidad ha llegado a ser la fuer a más importante y única que lleva al éxi o organizacional y al crecimiento de la co pañía en mercados nacionales e internacionales. Los rendimientos de programas de calid d fuerte y eficiente están generando excele tes resultados de utilidades en empresas con estrategias de calidad eficientes. Esto está d mostrado por los importantes aumentos en la penetración del mercado, por mejoras i portantes en la productividad total, por los costos muchos menores de calidad y por un li erazgo competitivo más fuerte. Cuando se enciona el término "calidad", por lo general lo asociamos con productos o servicios excel ntes, que satisfacen nuestras expectativas y, más aún, las rebasan. Tales expectativas se d finen en función del uso que se le dará al p roducto o servicio en cuestión y de su respec ivo precio de venta. Cuando un producto me ora nuestras expectativas estamos hablando de calidad. Es decir, se trata de una cualidad cu a valoración dependerá de lo que se perciba. De acuerdo a la norm A3 – 1987 ANSI / ASQC, Calidad es la tot lidad de aspectos y características de un producto o servicio que permiten satisfacer ne esidades implícita o explícitamente formulad s. Estas últimas se definen mediante un contr to, en tanto que las primeras se definen seg n las condiciones que imperen en el mercado, aunque es necesario también determinarlas y definirlas. Debido a la gran variación de resultados de calidad, la búsqueda ge uina del éxito en la calidad se ha convertido en un asunto de gran interés en la administraciión de las compañías de todo el mundo. Y la e xperiencia está abriendo una base fundamental ara lograr ese éxito. La calidad es en esencia una forma de administrar a la organizació n. Como finanzas y mercadotecnia, la calidad ha llegado a ser ahora un elemento esencial de la administración moderna. Y la eficiencia en la administración de la calidad se ha conver ido en una condición necesaria para la eficien ia de la administración industrial en sí. Origen de la Calidad Como nos tienen acostu brados, los japoneses fueron los pioneros. La II Guerra Mundial dejó la economía nipona en na situación catastrófica, con unos productos p co competitivos que no tenían cabida en los mercados internacionales. Los japoneses no tardaron en reaccionar: se lanzaron al mercado racias a la adopción de los sistemas de calidad. os resultados fueron que Japón registró un spectacular crecimiento. La iniciativa nipona pronto se transmitió a otras zonas del planeta.. Europa tardó algo más, pero también fueron los años 80 los del impulso definitivo. En 1988 nace la European Foundation for Quality Managment (EFQM), organización que apue ta por los modelos de gestión de calidad otal (GTC o TQM), estrategias encaminadas a optimizar los recursos, reducir costes y mejor r los resultados, con el objetivo de perfeccionar constantemente el proceso productivo. L implantación de la calidad total es un proce o largo y complicado, supone cambiar la filosofí de la empresa y los modos de gestión de s s responsables; se debe elegir un problema c ncreto, y analizar el punto en donde esté fall ndo la empresa. ING. FELIPE OMAR ALIAGA CAVERO

3

CALIDAD DE SOFTWARE

Los principios de gestión de la calidad total son sencillos e entender, pero complicados de asimilar: • El sistema parte de la búsqueda de la satisfacción del cliente, en odos sus aspectos. • Un primer paso s la búsqueda de la calidad de los productos/ser vicios. • Pero habrá que tener en claro que el producto/servicio ya no s rá el punto principal de calidad. Los principios elemen ales son los siguientes: • De poco sirve imponer de forma autoritaria la mejora en cada pu sto de trabajo. • La calidad la p oduce el último eslabón que termina el producto ó que está en contacto con el cliente pero nunca el director general. • El directivo tiene que estar convencido de la necesidad de la calid ad. Concepto de Calidad Es cuando en una organización se determinan las actividades y los integrantes de la misma se encuentran haciendo lo que tienen que hacer, lo están haciendo bien, para brindarle una satisfacción total al clien e. Análisis del concepto “haciendo lo que tienen ue hacer”, se refiere a: Determinación d las actividades • • Conocimiento de los requisitos a cumplir • Adiestramiento sobre esos requisitos (capacitación) • Cumplimiento estricto de esos requisitos Si se conocen los requisi os no se necesita supervisión, ya que se sabe q é hacer. “lo están haciendo bi n” Implica la predisposición o la integración de la organización (el compro iso). Es la diferencia entre tener y querer ir a trabajar, creando un mejor ambiente de trabajo. “brindar satisfacción otal al cliente” Calidad Total es cuando en la organización, los integrantes se en uentran cumpliendo exactamente con todos l s requisitos establecidos y normalizados hacia l del la búsqueda del Cero Defecto, para brind rle satisfacción total al cliente. Cliente es todo aquel q e se ve afectado por lo que haga o deje de hacer. Es aquel que depende de mí, es deci r, tiene una dependencia directa; aquel que e sigue en la línea (cliente interno) y todos aquellos que me dependen (razón trascendental). Calidad Total no se limita a una técnica administrativa o de gestión, sino que su concepción es mucho más profunda, ya que empieza y termina con las personas, es decir que es una filosofía que se demuestra en el ser, p ensar y actuar de las personas de Calidad. Personas de Calidad obtienen productos de c lidad y brindan servicios de calidad. Se ha definido al Mejora iento del personal como una forma de lograr la calidad total, y como una conversión en el me canismo viable y accesible al que las empresas de los países en vías de desarrollo cierren la recha tecnológica que mantienen con respecto l mundo competitivo y desarrollado. Para mej rar un proceso y llegar a la calidad total, y ser n consecuencia más competitivos, es necesario cambiar dicho proceso, para hacerlo más efectivo, eficiente y adaptable. Qué cambiar y cómo cambiar depende del enfoque específico del empresario y del proceso. LA CLAVE DEL ÉXITO ES LA CALIDAD TOTAL DE MANTENER SI STEMÁTICAMENTE VENTAJAS QUE LE PERMITAN ALCANZAR DETERMINADA OSICIÓN EN EL ENTORNO SOCIOECO ÓMICO. ING. FELIPE OMAR ALIAGA CAVERO

4

CALIDAD DE SOFTWARE

El término calidad to al es muy utilizado en los medios empre sariales, políticos y socioeconómicos en gen ral. A ello se debe la ampliación del marco de r ferencia de nuestros agentes económicos que han pasado de una actitud auto protectora a un planteamiento más abierto, expansivo y pro ctivo. La ventaja comparati a de una empresa estaría en su habilidad, recu sos, conocimientos y atributos, etc., de los ue dispone dicha empresa, los mismos de l os que carecen sus competidores o que est s tienen en menor medida, que hace posible la obtención de unos rendimientos superiores a los de aquellos. El uso de estos conceptos upone una continua orientación hacia el entorno y una actitud estratégica por parte de l s empresas grandes como en las pequeñas, en las de reciente creación o en las maduras y en general en cualquier clase de organización. or otra parte, el concepto de éxito nos hac pensar en la idea "excelencia", o sea, con aracterísticas de eficiencia y eficacia de la organización. El Concepto de Calida Total tiene Cuatro Etapas: 1) Hacer de la cali ad un socio pleno e igual de la innovación, d sde el comienzo del desarrollo del pr ducto. 2) Poner énfasis en que el diseño de un producto de alta calidad y el proceso coincidan en forma asce dente, no después que la planeación de l manufactura haya congelado ya las alternativas. 3) Hacer de todos los servicios de los proveedores un socio de c lidad al comenzar el diseño; en lugar de un problema de vigilancia de la calidad, más delante. 4) Hacer de la aceleración de la introducción de un nuevo produc o – no su retardo – una medida pri aria de la eficacia del programa de calidad e una compañía. El cuarto punto fu damental es que la calidad y el costo son c mplementarios y no objetivos conflictos del negocio. Estos fundamentos aclaran que el liderazgo de la calidad es hoy en día la clave del éxito del negocio de las compañías y que ello se suma a las economías nacionales. En correspondencia, las iniciativas nacionales y regionales están resultando de importancia cr ciente en el fomento del liderazgo de la calidad. ¿Qué es Calidad Total? La calidad total es un concepto, una filosofía, una estrategia, un modelo de hacer negocios y está localizado hacia el liente. La calidad total no solo se refiere al prod ucto o servicio en sí, sino que es la mejoría permanente del aspecto organizacional, ger ncial; tomando una empresa como una máquina gigantesca, donde cada trabajador, desde el gerente, hasta el funcionario del más bajo nivel jerárquico está comprometido con los objetivos empresariales. Para que la calidad total se logre a plenitud, es necesario que se rescaten los valores morales básicos de la sociedad y es aquí, donde el empresario juega un papel fundamental, empezando por la educación previa de sus trabajadores para conseguir na población laboral más predispuesta, con mejor capacidad de asimilar los problemas d calidad, con mejor criterio para sugerir ca bios en provecho de la calidad, con mejor ca acidad de análisis y observación del proceso de manufactura en caso de productos y poder enmendar errores. El uso de la calidad total conlleva ventajas, pudiendo citar como ejemplos las siguientes: • • •

Potencialmente lcanzable si hay decisión del más alto nivel. Mejora la relació del recurso humano con la dirección. Reduce los costos aumentando la productividad.

Principios de la Calidad 1. Cumplir con los requisitos. Para ello los directivos deben: • Establecer los requisitos a cumplir ING. FELIPE OMAR ALIAGA CAVERO

5

CALIDAD DE SOFTWARE

Suministrar los medios necesarios para que los empleados cu mplan • Motivar y es imular para que los requisitos sean cumplidos 2. La Calidad es la revención, no la verificación 3. El estándar de r alización es el Cero Defectos 4. La medida de la Calidad es el precio por el incumplimiento •

Factores esenciales p ra introducir el Control Total de Calidad • Conciencia: en t dos los niveles de la organización • Trabajo en equipo: es el pilar de la Calidad, trabajar en mut a cooperación y sin autoritarismo. • Control y mejor miento: mejorar sobre lo medido, ya que solo se puede mejorar lo que se puede m dir. Planes de mejora. • Sistematización: en busca de la perfección de las actividades de l organización. • Conocimiento y omparación de costos • Evaluación: deb ser constante y retroalimentadora, a la vez q e debe ser imparcial sobre los esfuerzos de los trabajadores en la actividad. • Difusión: se debe comunicar qué se hace y qué pasa en la orga nización en todos los niveles. La calidad total en la org anización de una empresa, debe ser el nervio y otor de la misma; si de verdad la empresa esea alcanzar el éxito debe cimentarse en e tas dos palabras. El mensaje de la calidad total debe ser comunicado a tres audiencias que son complementarias entre sí: • Los Trabajadore . • Los Proveedores; y, • Los Clientes. Los fundamentos de la c lidad total son los siguientes: • El objetivo básic : la competitividad El trabajo bien h cho. • • La Mejora conti uada con la colaboración de todos: responsa ilidad y compromiso individual por la calidad. • El trabajo en eq ipo es fundamental para la mejora permanente • Comunicación, información, participación y reconocimiento. • Prevención del e ror y eliminación temprana del defecto. • Fijación de objetiivos de mejora. • Seguimiento de esultados. • Indicadores de gestión. • Satisfacer las ne esidades del cliente: calidad, precio, plazo. Los obstáculos que impiden el avance de la calidad pueden ser: • El hecho de que la dirección no defina lo que entiende por calida . • 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 so menos los que la practican. El Control de la Calidad Se posesiona como una estrategia para asegurar el mejoramiento conti uo de la calidad. Es un programa para ase urar la continua satisfacción de los clientes externos e internos mediante el desarrollo p rmanente de la calidad del producto y sus serviicios. Es un concepto que involucra la orientación de la organización a la calidad manifesta a en sus productos, servicios, desarrollo de su personal y contribución al bienestar gene al. El mejoramiento continuo es una herramiienta que en la actualidad es fundamental par todas las empresas porque les permite renovar los procesos administrativos que ellos realizan, lo cual hace que ING. FELIPE OMAR ALIAGA CAVERO

6

CALIDAD DE SOFTWARE

las empresas estén en constante actualización; además, permite que las organizaciones sean más eficientes y competiitivas, fortalezas que le ayudarán a permanecer en el mercado. Para la aplicación del mejoramiento es necesario que en la organizació exista una buena comunicación entre tod s los órganos que la conforman, y también l s empleados deben estar bien compenetrados con la organización, porque ellos pueden ofrecer mucha información valiosa para llevar a cabo de forma óptima el proceso de m joramiento continuo. La definición de una estrategia asegura que la organización está haciendo las cosas que debe hacer para lograr sus ob jetivos. La definición de su sistema determina sii está haciendo estas cosas correctamente. La calidad de los procesos se mide por el grado de adecuación de estos a lograr la satisfacción d sus clientes (internos o externos). Es el proceso de alca zar los objetivos de calidad durante las o eraciones. Para el efecto, se deberán de arrollar los siguientes pasos: a) b) c) d) e) f) g)

Elegir qué contr lar. Determinar las unidades de medición. Establecer el sistema de medición. Establecer los estándares de desempeño. Medir el desemp ño actual. Interpretar la dif erencia entre lo real y el estándar. Tomar acción so re la diferencia.

El término calidad se a convertido en una de las palabras clave e nuestra sociedad, alcanzando tal grado de relevancia que iguala e incluso supera en ocasi nes al factor precio, en cuanto a la importancia otorgada por el posible comprador de un producto o servicio. Las necesidades de quie es compran nuestros productos o servicios no s n estáticas, sino que evolucionan de forma continua. Esto supone la permanente adaptación de todos nuestros procesos productivos y omerciales a dichas necesidades, si queremos seguir contando con SU FIDELIDAD. Pasos para poner en marcha el Control de Calidad Cada uno de los conce tos de la estrategia del Control Total de Cali ad conlleva muchas actividades. Por lo tanto se hace necesario establecer un plano o prog ama cuyo desarrollo asegure el éxito de su plicación en la empresa. Un plan para poner e n práctica el Control Total de Calidad, podría ontener las siguientes actividades: COMPROMISO Y ORG NIZACIÓN. 1. Establecimiento el compromiso de la alta dirección con la implementación del CTC y con las actividades de los círculos de control de calidad. Debe es tablecerse el por que de esta decisió . Para ello es básico conocer los conceptos ásicos de CTC, sus beneficios, la importancia del cliente, el valor del recurso hum no, la necesidad de optimizar recurs s y tecnología, lo vital del ciclo de control y aspectos similares. 2. Organización de un comité directivo o de un consejo. 3. Designación de l s miembros del comité de CTC. 4. Organización de una oficina de CTC para los miembros del comit o consejo, así como para la promoción CTC. 5. Designación del director de la oficina de CTC así como de los facilitadores de CTC. Estos últimos s n el apoyo metodológico para la implantación del CTC en toda la organización. PLANEACIÓN 1. Establecimiento de la política de implementación del CTC y del programa para lograrlo. Esto de e hacerlo el comité o el consejo. ING. FELIPE OMAR ALIAGA CAVERO

7

CALIDAD DE SOFTWARE

2. Visitas a otras e presas o países para visualizar la operación del CTC, por parte de la alta dirección, l s gerentes, así como del director de la ofici a de CTC y de los facilitadores. 3. Establecimiento de una plan adecuado a las condiciones de lla empresa y de su correspondiente calendario de implementación; esta actividad e responsabilidad del director de la ofi ina de CTC. EDUCACIÓN Y ENTRE AMIENTO 1. Realización de e entos de educación, dirigidos a la alta dirección. 2. Realización de actividades educativas dirigidas a la gerencia, al director de la oficina de CTC y a los f cilitadores de CTC. 3. Preparación del material educativo para la aplicación del CTC y e las 7 herramientas básicas de con rol de calidad. El material deberá ser diseñ do para directores, gerencia media, staff y supervisores. 4. Puesta en prácti a del programa de educación y entrenamiento cada nivel, según lo programado. Esto incluye la aplicación de los conceptos aprendid s. PRIMERAS ACCIONES 1. Una vez termin do el entrenamiento, "sacudida" de cada sec ión o departamento para identificar, con ayuda de los subordinados de cada s ctor, sus fuerzas y debilidades. 2. Diseño de un pr yecto (uno fácil), como ejercicio de los casos de Ruta de Calidad (o de mejoramient del control de calidad) y de la utilización e ectiva de los datos: desarrollo de es e con aplicación del ciclo de control (los ocho pasos de la ruta de calidad). Repeti ión de este ejercicio para el siguiente aspecto de menor dificultad. Cuando ya se esté familiarizado con el proceso, enfrentamien o con los proyectos críticos o import ntes para el mejoramiento. 3. Realización de e entos educativos para los supervisores, en aspe tos relacionados con los Círculos de C ntrol de Calidad. 4. Promoción e instalación de Círculos de Control de Calidad pilo o, voluntarios y con supervisión tam ién voluntaria, para practicar de nuevo los ocho pasos de la Ruta de la Calidad. Repe ición de estas actividades hasta terminar con lo estipulado en el plan y en el program . ADMINISTRACIÓN P R POLÍTICA Y ESTANDARIZACIÓN. 1. Preparación de n borrador de administración por políticas, por arte de la oficina de CTC. 2. Obtención de la probación por la alta dirección y el consejo de CTC.

CALIDAD DE SOFTWARE Introducción El desarrollo de sistema hoy en día ha tomado gran importancia en el mundo, siendo ésta cada vez más creciente. Si una empresa de software pretende competir a nivel internacional, es necesario que conte ple seriamente la necesidad de realizar una CERTIFICACION DE CALIDAD DEL SOFTWA E Y DEL SISTEMA. Muchos proyectos de siste mas presentan fallas que impiden que el sistema funcione como era de esperarse o que sea utilizado en su totalidad. Por ello, es n cesario definir e impulsar líneas de acción tendientes a mejorar el sistema producido. Dentro de estas líneas de acción, está la relacionada on el proceso mismo del desarrollo del sistema, y como necesidad primordial, la de realizar na investigación que permita conocer de prim ra mano el estado en que se encuentra su proc so de desarrollo. ING. FELIPE OMAR ALIAGA CAVERO

8

CALIDAD DE SOFTWARE

Diferenciaremos dos con eptos importantes como son: •

•

El control de calidad de sistemas está orientado a garantizar el funcionamiento de los sistemas en xplotación. El control de calidad de software está orientado a garantizar las características de los programas q e se están desarrollando.

La Ingeniería de Softw re concierne a teorías, métodos y herramient s para el desarrollo profesional de productos. Un Sistema concierne a un conjunt de componentes interrelacionados trabaj ndo conjuntamente para un fin común. El sistema puede incluir software, dispositivos mecánicos y eléctricos, hardware, y ser operad por gente. Existen varias organizaciones de estandarización internacional que realizan está dares y modelos de ingeniería de software, esto con el fin de mejorar la Calidad del Software. La Calidad La ISO (International tandard Organization), define La Calidad c mo la ausencia de deficiencias: "Es la totalidad de aspe tos y características de un producto o servicio que se refieren a su capacidad para satisface necesidades dadas en la adecuación de sus obj tivos'”. El Instituto de Ingenierí de Software (SEI) en su modelo CMM (Capa ility Maturity Model) define la calidad como: •

•

•

El grado en el cual un sistema, componente o proceso cumple con los requisitos especificados. El grado en el c al el sistema, componente o proceso cumple co las expectativas del cliente o usuario. La calidad consiste en todos aquellos aspectos del product que satisfacen las necesidades del liente y de ese modo proporcionan la satisfacción del producto.

La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. La Calidad del Softwa e es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existe ncia. La Calidad del Software es mensurable y varía de un sistema a otro o de un programa a otro. Por ejemplo: un software elaborado p ra el control de naves espaciales debe ser confi able al nivel de "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 lar o período (10 años o más) necesita ser confia le, mantenible y flexible para disminuir los cost os de mantenimiento y perfeccionamiento dur nte el tiempo de explotación. Aspectos de la Calidad La Calidad del Software puede medirse después de elaborado el produ to. Pero esto puede resultar muy costoso si e detectan problemas derivados de imperfeccio es en el diseño, por lo que es imprescindibl tener en cuenta tanto la obtención de la cali ad como su control durante todas las etapas del ciclo de vida del software. Objetivo de la Calidad en los Sistemas El Objetivo que persigue la Calidad en los Sistemas está orientada a: •

• •

Incrementar la roductividad y satisfacción al trabajo de los p ofesionales afines al campo de la co putación. Mejorar la calida del producto del software. Proveer técnicas aplicadas para automatizar el manejo de datos.


9

CALIDAD DE SOFTWARE

• • • •

Realizar una pla eación eficaz de los sistemas. Documentar. Validar y control r formalmente la calidad del trabajo realizado. Cumplir con los objetivos de la organización en cuanto a p roductividad de sus sistemas de cómputo.

Obtención de un Soft are de Calidad La obtención de un oftware con Calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prue ba del software, que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilida de prueba, a la vez que eleven la productivida , tanto para la labor de desarrollo como para el control de la Calidad del Software. •

•

•

El principio tecnológico define las técnicas a utilizar en el pro eso de desarrollo del software. El principio ad inistrativo contempla las funciones de plani icación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software. El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado. ara el aseguramiento de la calidad es nec esario su control o evaluación.

Control de la Calidad El Control de la Calidad s realizar una observación constante acerca del cumplimiento de las tareas que pueden ofrecer una calidad objetiva a la forma en cómo se stá desarrollando un proyecto de Ingeniería de Software. Es decir, una vigilancia permanente a todo el proceso de desarrollo y ciclo de vi a del software. Esta meta puede alcanzarse mediante frecuentes inspecciones a las meto ologías de trabajo y uso de herramientas, revisi ones de prototipos y evaluación exhaustiva d los productos finales. El Control de la Calida permite realizar las rectificaciones pertinent s al desarrollo en cuanto éste empieza a desviarse de sus objetivos, por lo tanto, de la caliidad del trabajo. Estas rectificaciones son po ibles gracias a una retroalimentación de las etapas superiores, creado así un aprendizaje al observar las salidas de cada etapa, hasta el roducto final, y mejorar los procesos que dan oriigen al sistema. En el Control de Calidad deben tenerse presentes los costos que esta in volucra. Si se piensa en las tareas que deben realizarse en este control, puede observase que es necesario llevar a cabo tareas de búsqued de problemas, evaluación, realimentación, rectificación, elaboración, modificación y estudio d la documentación; entre otras actividades. Pero debe existir un co promiso, ya que un excesivo costo en el control de la calidad puede hacer que este proceso se torne ineficiente. Pero, por otra parte, el mejoramiento de la calidad implica reducir l s costos ya que se tendría un cierto nivel de c alidad ya asegurado. Finalmente, y como consecuencia de la naturaleza del proceso de de arrollo de productos software, el asegurar la calidad en las primeras etapas de este involuc a que los costos del control en las etapas posteriores tenderá a disminuir al tener menos a pectos que controlar pues, nuevamente, la calidad estaría asegurada en sus bases. Control de Calidad del Softw re Para controlar la Calidad del Software es necesario, definir los pará etros, indicadores o criterios de medición. El software posee determinados índices mensurables que son las bases para la calidad, el contr l y el perfeccionamiento de la productividad. Una vez seleccionados los índices de calidad, debe establecerse el proceso de control, que requiere los siguientes pasos: ING. FELIPE OMAR ALIAGA CAVERO

10

CALIDAD DE SOFTWARE

1. Definir el softwa e que va a ser controlado: clasificación aplicación, compleji ad, etc., de acuerdo con los estándares desarrollo del software. 2. Seleccionar una edida que pueda ser aplicada al objeto d clase de software es necesario definir los indicadores y sus magnitud 3. Crear o determinar los métodos de valoración de los in manuales, como cuestionarios o encuestas estándares para la periciales y herramientas automatizadas para medir los criterios de c 4. Definir las regula iones organizativas para realizar el contr en el control de la calidad, cuándo se realiza, qué documentos d elaborados, etc.

por tipo, esfera de stablecidos para el control. Para cada s. icadores: métodos edición de criterios lculo. l: quiénes participan ben ser revisados y

Indicadores para diferen iar los productos de calidad de los que carecen e ella: • • •

El acercamiento a cero defectos. El cumplimiento de los requisitos intrínsecos y expresos. La satisfacción d l cliente

La Calidad del Software debe ser una disciplina más dentro de la Ingen iería del software. El principal instrumento para garantizar la calidad de las aplicaciones sig e siendo el Plan de Calidad. El plan se basa en unas normas o estándares genéricos y en unos procedimientos particulares. Las normas, directivas, odelos y estándares son básicamente las siguie tes: •

• • • • •

•

Familia de nor as ISO 9000 y en especial, la ISO 9001 y l ISO 9000-3.2:1996 Quality Manage ent and Quality Assurance Standards ISO 8402: 1994 IEEE 730/1984, tandard for Software Quality Assurance Plans IEEE Std 1028: 989, IEEE Standard for Software Reviews and A dits CMM. Capability Maturity Model ISO/IEC JTC1 15504. SPICE. Software Process Improve ent and Capability Determination. Modelo de EFQM . Modelo de la Fundación Europea de Gestión de Calidad

Los procedimientos pueden variar en cada organización, pero lo imp rtante es que estén escritos, personalizados, adaptados a los procesos de la organizació y, lo que es más importante, que se cum lan. La Calidad del Software debe implementar e a lo largo de todo el ciclo de vida, debe correr paralela desde la planificación del producto hasta la fase de producción del mismo. Capacidades del Soft are Las capacidades import ntes para un producto de software desde el punto de vista del usuario, así como los factores que determinan la calidad de cada una de l as capacidades son: • Capacidad de operación con los factores de corrección, facilidad, eficiencia, integridad y facilidad de us . • Capacidad para er modificado o de revisión con los factores de flexibilidad, facilidad de prueba y facilidad de mantenimiento. • Capacidad de t ansición o de adaptación a otros entornos con los factores de transportabilidad, capacidad de reutilización y de interoperación. Calidad Total en el Pr ceso de Desarrollo del Sistema Para alcanzar la "Calida Total", es necesaria la satisfacción por parte e los elementos que intervienen en el proces : ING. FELIPE OMAR ALIAGA CAVERO

11

CALIDAD DE SOFTWARE

• • •

La satisfacción d la alta dirección La satisfacción d l personal involucrado en el desarrollo del siste a La satisfacción d l usuario final

La aplicación del contr l de calidad de sistemas no es solamente al sistema en sí, ésta conforma la última parte de la evaluación. Elementos para el Proceso de Sistemas Son tres los elementos que integran el proceso de sistemas, los cuale por su importancia deben de considerarse ara el mejor control de calidad y realización d los sistemas, estos son: 1. Gente 2. Herramientas (S ftware y Hardware) 3. Tiempo disponible Debe contarse con la gente adecuada, que tenga la suficiente capaciidad para realizar el trabajo, las herramientas de trabajo deben ser confiables, no limitada y debe tomarse en cuenta cuanto tiempo se dispone para la elaboración del sistema. Componentes para la Calidad Total • • • • • • • • • •

Claridad Involucración Planeamiento Estándares Entrenamiento Experiencia Controles Documentación Soporte Finalización

Claridad La definición de lo que e tiene que hacer o lo que el usuario necesita, debe ser clara para todos los responsables d l proyecto, esto con el fin de establecer reglas a seguir. Involucración Es necesario revisar cad etapa del proyecto. Para cada una de ellas es importante dejar en claro si vale la pena continuar o no, si hay limitaciones o restricciones q e afecten o impidan el buen funcionamiento del proyecto y si se está dando el cubrimiento decuado a todos los requerimientos y funci nes, divisiones o departamentos que están involucrados en la realización del proyecto. Planeamiento En la planificación interviienen tanto los usuarios como el personal que desarrolle el proyecto. Debe planearse el gra o de integración que se requiere en las dif erentes áreas de la organización, para inter retar necesidades o requerimientos satisfactoriios con el objeto de llegar a acuerdos en cas de imprevistos en asuntos tan simples como el método mediante el cual vamos a poner a tra bajar alguna etapa o actividad en el proyecto. Estándares Tiene que tomarse en c enta la forma mediante la cual vamos a trabaj r desde el punto de vista tecnológico, ya qu es necesario tener presente la definición de iversos factores que afectarían la realización el proyecto, como son: ING. FELIPE OMAR ALIAGA CAVERO

12

CALIDAD DE SOFTWARE

• • • • • • • • •

Lenguaje de pro ramación Manejo de librerí as Código Instrucciones Comentarios Administración de backups Administración de archivos Periodicidad de revisiones Documentación

Debe quedar clara su definición, los elementos que los deben integrar, así como su estandarización. Sin una estandarización el proyecto se vendría abajo. Entrenamiento El entrenamiento es un factor determinante para la realización de n proyecto, ya que mediante él se obtienen los l conocimientos y habilidades que se aplicarán en el proyecto. Experiencia El contar con mucha o poca experiencia, determina el tiempo de desa rollo del sistema así como la calidad del traba jo que realice (oportunidad - calidad). Controles Los controles que se e tablezcan deben realizarse con alguna periodicidad. Primeramente debe verse el avance el proyecto; el cumplimiento de los requerimientos del cliente; el seguimiento y las normas de seguridad y de auditoríaa; la involucración e las personas clave para el proyecto; el funcionamiento de la aplicación; del desarrollo con l usuario y un punto importante es la mutua satisfacción entre de la gente que realiza el proyecto con el usuario. En este caso puede contarse con un Calendario de Entrega donde contenga los puntos anteriormente menciona os, así como contar con Bitácoras que respald n las reuniones que se tengan con los usuari s y los acuerdos a los que hayan llegado ambas partes. Documentación Es importante que la do umentación que se genere debe ser clara y útil n cuanto al sistema, ya sean los programas, l s tareas del usuario y sus procedimientos, el m nejo de la aplicación y producción y los cuida os con respecto a back-ups, ayudas y soporte equerido, la bitácora de historia respecto a f llas, mejoras, arreglos, etc., contribuyen a una mejor utilización del sistema, es decir, a una mayor calidad en su operación. Manuales de suario, técnico y de operación. Soporte Es indispensable tener claro quién nos puede apoyar en las áreas técnica, de análisis, en el área usuaria, ya sea en la instalación, en el área ejecutiva o en algún otro aspecto, ya que las aplicaciones en los proyectos de sistemas enfrentan siempre necesidades críticas de soporte. Finalización La finalización del proy cto de un sistema es una de las labores m s importantes en el desarrollo del mismo, d igual manera que en cada etapa. En la finaliz ción del proyecto es necesario considerar cinco puntos vitales: • • • •

•

La revisión de todos los pasos realizados y de las etapas incluidas en el proceso total; Elaboración del roceso en forma integral; Calidad hecha e cada uno de los pasos o etapas del proyecto; La atención a l s requerimientos del usuario en términos de acer todo lo que él quiera, o más; Y, por supuesto, la satisfacción de nuestro usuario o cliente q e, en últimas, es el reconocimiento la labor bien realizada y de alta calidad.


13

CALIDAD DE SOFTWARE

Cuando se desarrolle un sistema o aplicación y se instale, debe asegura rse de hacerlo de tal manera que lo que se e tregue esté completo, sea oportuno, no tenga errores, sea confiable, útil y estable. Administración de la Calidad La Administración de la alidad cuenta con dos niveles de trabajo: El nivel de entidad u organización. Donde se trata de cre r y gestionar una

infraestructura que fom nte la calidad de los productos software medi nte la adecuación y mejora de las activida es y procesos involucrados en su producción e, incluso, en su comercialización y en la interacción con los clientes. El nivel del proyecto. Donde las guías que la infraestructura organi ativa prevé para las

distintas actividades y antenimiento del software deben ser adaptada a las características concretas del proyecto de su entorno para ser aplicadas a la práctica. Dentro del primer nivel de acción, la gesti n de la calidad en organizaciones de software a seguido dos líneas que pueden ser comple entarias entre sí: Por una parte, se ha seguido la línea marcada por las entidades internacio ales de estandarización para todas las organizaciones de producción o servicios. Principalmente se han impuesto en la práctica las directric s marcadas por ISO (Organization for Intern tional Standardization) a través de unas normas ISO 9000 para la gestión de calidad. En el caso del software es principalmente aplicable l norma ISO 9001. El sector de software difiere por la naturaleza del producto tanto del resto de sectores productivos que ha sido necesario crear una guía específica para su aplicación a este sector: ISO 9000-3. El mundo d l software ha creado sus propias líneas de traba jo en la gestión de la calidad, trabaja sobre los procesos de producción como medio para as egurar la calidad del producto software. Por ejemplo, el SEI (Software Engineering Institute), proponiendo un modelo de clasificación y mejora de los procesos empleados por la s organizaciones de software denominado C M. La Calidad del Software se diseña conjunta ente con el sistema, nunca al final. A mayor alidad, mayores son los costos, pero mayores t mbién los beneficios obtenidos en la fase del mantenimiento del software. Este costo hay qu considerarlo dentro de todo el ciclo de vida el proyecto. El aseguramiento de la Calidad de Software engloba un enfoque de gestión de calidad, tecnología de ingeniería de software efectiva (métricas y herramientas), revisione técnicas formales que se aplican durante el roceso del software, una estrategia de prueb multiescalada, el control de la documentación del software y de los cambios realizados, un rocedimiento que asegure un ajuste a los está ndares de desarrollo del software (cuando se posible) y mecanismos de medición y de gener ción de informes. La Prueba del Softwa e Se pueden realizar ins ecciones para cada módulo o pequeño gru o de módulos que conformen un sistema. l limitar el centro de atención de la RTF la prob abilidad de descubrir errores es mayor. Calidad en el Diseño Aquí se plantean características definidas para la realización del pr ducto software que deberán cumplirse poste iormente. La calidad se basa en definir un listado de especificaciones a seguir. Involucra descripción de los procesos, tareas y responsabilidades de los equipos de desarrollo. En esta eta a la calidad aumenta en la medida en que se realiza una alta especificación de los p ocesos y se propone una estrecha toleranci a la modificación, estableciendo los métodos correctivos a las desviaciones ocurridas. Est es la medida de la calidad apreciada por l s usuarios finales del entendimiento del producto software. Estas apreciaciones de calidad hacia un determinado producto elevarán el nivel de confianza para la organización desarrollad ra, lo que puede elevar su posición en el merca o. ING. FELIPE OMAR ALIAGA CAVERO

14

CALIDAD DE SOFTWARE

NIDAD DIDÁCTICA N° 02 MODELOS Y ES ÁNDARES DE CALIDAD DE SO TWARE

LOS CINCO MODELOS MÁS ACREDITADOS EN CALIDAD D E SOFTWARE Introducción La estandarización es to de personas. Los están siempre de la misma for la productividad y la cali

a actividad documentada que norma el comportamiento de un grupo ares nos dan los medios para que todos los procesos se realicen a, mientras nos surjan ideas para mejorarlos. Son nuestra guía para ad.

Expectativas de los está dares: • Mejora de proce os de software acorde a los objetivos estratégic s • Mejora de los pr ductos • Protección del cliente o usuario • Protección de la organización (cultura de la organización y mejor continua) Existen varias organizaciones de estandarización internacional, alg nas son regionales mientras que otras son globales. Las últimas están relacionadas con la ONU o son independientes, como por ejemplo la International Telecommunication U ion (ITU). La International Electro echnical Commission (IEC) que fue fundada n el año 1906 para definir estándares en el ctrica y electrónica, mientras que la Internaci nal Organization for Standardization (ISO) f e creada en 1947 para abarcar otros temas. Ambas tienen por objetivo facilitar el intercambio de bienes y servicios a nivel internaci nal, entre otras. En 1987, ISO e IEC decidier on formar el Joint Technical Commit (JTC), cuy objetivo es elaborar estándares para la tecnología de información Information Technology (IT). Organizaciones como la ISO, BOOTSTR AP, entre otras se han dedicado a crear mod los para mejorar la Calidad del Software, en re ellos tenemos: • • • • •

ISO 9000 CMM (Estados U idos) Tick It (Inglaterra) Bootstrap (Europa) ISO/SPICE (Australia)

La Norma ISO 9000 La Organización Interna ional para la Estandarización (ISO) fue fundad el 23 de febrero de 1947 con el objetivo de crear una norma internacional de calidad. El Comité Técnico ISO/TC 176 para Aseguramiento de la Calidad fue el encargado de crear el están ar ISO 9000. El objetivo del estánd r es desarrollar un código mínimo que co tenga prácticas de administración para garantizar el Aseguramiento y Administración de la alidad, es decir, qué hacer para responder a llos requerimientos de un mercado cada vez má competitivo y cómo deben responder los p oveedores y compradores respecto a la calid ad de los bienes o servicios intercambiados. Para ello establece una serie de guías para l selección y uso del estándar deseado, así c mo aclara conceptos en cuanto a la calidad y l s interrelaciones que se establecen. ING. FELIPE OMAR ALIAGA CAVERO

15

CALIDAD DE SOFTWARE

Estructura General De forma general la nor a se divide en 4 guías o modelos fundamentale : •

•

•

•

ISO 9001 Siste as de Calidad. Modelo de Aseguramiento de la Calidad en el diseño, desarrollo, producción, instalación y servicio. ISO 9002 Siste as de Calidad. Modelo de Aseguramiento d la Calidad para la producción, inst lación y servicio. ISO 9003 Siste as de Calidad. Modelo de Aseguramiento d la Calidad para la inspección final pruebas. ISO 9004 Elem ntos para la Administración y el Sistema de alidad. Guía para el Sistema de Aseguramiento de la Calidad.

Además, existen otras n rmas y entre ellas las más relevantes son: • • •

ISO 9000-1 Guía para la selección de la norma a usar. ISO 8402 Recopilación de definiciones. Vocabulario. ISO 9000-3 Está dares de Administración y Aseguramiento de la Calidad.

De forma general los req uerimientos fundamentales de ISO 9000 son: • •

• •

• • • • •

Escribir un manual de calidad, describiendo el Sistema de Calidad en alto nivel. Escribir docume tos en forma de procedimientos que describan cómo debe hacerse el trabajo en la organización. Crear un sistema para controlar la distribución y reedición de doc mentos. Diseño e impla tación de un sistema de acciones preventiva y correctivas para prevenir la ocurr ncia de problemas. Identificar las necesidades en cuanto a entrenamiento en la orga ización. Determinar las edidas y equipos para realizar las pruebas. Capacitar al personal de la organización en la operación del Siste a de Calidad. Planificar y llevar a cabo auditorias de calidad internas. Tener en cuen a los requerimientos del estándar con los que no cumple la organización.

Los factores que determinan el modelo a elegir son: a) La complejidad del proceso de diseño. Se refiere a la dificultad para diseñar el producto o servicio cuando éste no ha sido diseñado. b) La madurez del dise ño. Se proyecta hacia el conocimiento y aprobación del diseño total, ya sea por las prueb s de desempeño o por la experiencia en el cam o. c) La complejidad del proceso de producción. Está relacionado con la capacidad del proceso de producción, las ecesidades de desarrollo del nuevo proceso, las variaciones que se requieren y el impac o en el desempeño del producto o servicio. d) Las características del producto o servicio. Depende de la comple idad del producto o servicio, del número de características interrelacionadas y de su influencia en el desempeño. e) La seguridad del pro ucto o servicio. Relacionado con el riesgo de oc rrencia de fallas y el impacto de éstas. El Modelo CMM A principios de los años 80’s el Departamento de Defensa de los Estad s Unidos enfocó sus tareas a la revisión de lo problemas del software y a su mejoramiento. S e creó el Instituto de Ingeniería de Software ( EI) a finales de 1984. Como parte de su trabajo , el Instituto se dio a la tarea de desarrollar el Modelo de Madurez del Proceso de Soft are y para 1986 se comenzó el Proyecto de Evaluación de la Capacidad del Software. Despu és de varios años de ING. FELIPE OMAR ALIAGA CAVERO

16

CALIDAD DE SOFTWARE

realizar cuestionarios, evaluaciones, consulta e investigación, junto a otr s organizaciones, en 1991 SEI produce el Modelo de Capacidad y Madurez del Software. El Modelo de Madurez y Capacidad del Proceso de Software (CM ) ayuda a que las organizaciones para pr ducir de manera consistente y predecible productos de calidad superior. La capacidad del proceso es la habilidad inherente para pr ducir los resultados planeados. El principal o jetivo de un proceso de software maduro es el e producir productos de calidad que cumplan los requerimientos del usuario. Cuando se habla de ma urez se entiende como el crecimiento alcanzad en la capacidad del proceso de software y que se considera como una actividad a l rgo plazo. En una organización de softwar inmadura, el proceso de software es generalmente improvisado, no existen planes rigurosos, se enfocan en resolver las crisis que se le pr esentan, carecen de bases objetivas para enj iciar la calidad de los productos o para resolver los problemas. Por lo contrario cuando la org nización alcanza cierto grado de madurez posee una gran habilidad para administrar el proc so de desarrollo y mantenimiento del software, se hacen pruebas y análisis de costo-beneficiio para mejorar el proceso, el administrador monitorea la calidad del producto y la satisfacción del cliente, se llevan registros y todos l s integrantes están involucrados. La madurez del proce o de software esta dada cuando un proce o en específico es explícitamente definido, administrado, medido, controlado y es efectivo. El ciclo Shewhart propone las bases para el trabajo de mejoramiento del proceso. Este c nsta de 4 pasos que se repiten en forma de ciclo hasta que la implantación produce los resultados esperados y los cambios pasan a ser per anentes. Los pasos son: 1. Pla ear a. Definir el problema b. Establecer los objetivos a mejorar 2. Ejecutar a. Identificar las posibles causas de problema b. Establecer las bases c. Probar los cambios 3. Revisar a. Recolectar los datos b. Evaluar los datos 4. Act ar a. Implementar los cambios b. Determinar la efectividad CMM es un modelo descriptivo en el sentido que describe los atribut s esenciales que se espera caractericen una organización dentro de un nivel de madurez en particular. Es un modelo normativo ya que las prácticas detalladas caracterizan el tipo normal de comportamiento que se spera de una organización que realiza proyectos a gran escala. No es prescriptivo ya qu no dice a la organización como mejorar. Estructura del modelo El modelo consta de 5 iveles, diseñados de forma que los inferiores roveen unos fuertes cimientos incrementado de manera progresiva sobre los que se construyen los niveles superiores. Estas 5 etapas de des rrollo son referidas como niveles de madure y en cada una la organización alcanza una capacidad en el proceso superior. Los 5 niveles del modelo son: ING. FELIPE OMAR ALIAGA CAVERO

17

CALIDAD DE SOFTWARE

1. Inicial : el proceso de software es un proceso improvisado y ca tico. Pocos procesos están definidos y el éxito que se pueda obtener depende de las habilidades, conocimientos y motivaciones del personal. No existen calendarios ni estimados de costos y las fun ionalidades y calidad del producto son impred cibles. No existe un ambiente establ para el desarrollo y mantenimiento del soft are. El proceso del software es impredecible por el continuo cambio o modificación medida que avanza el trabajo. 2. Repetible : se stablecen procedimientos de administración del proceso básico para determinar cost s, calendarios y funcionalidades. Se establecen las políticas para la administración del proceso y los procedimientos de implantació . El proceso se basa en repetir éxitos anteriores en proyectos de similares caracterí ticas, por lo que los mayores riesgos se presentan cuando se enfrentan a nuevos proyectos. Se exhiben problemas de calidad y carecen de una adecuada estructura para mejorarla. 3. Definido : el pr ceso de software para las actividades administr tivas y técnicas está documentado, omogeneizado e integrado en un proceso d software estándar dentro de la or anización, que ayudará a obtener un desemp ño más efectivo. El grupo que traba a en el proceso enfoca y guía sus esfuerzos al mejoramiento de su desarrollo, facilita la introducción de técnicas y métodos e infor a a la administración del estado del proceso. La capacidad del proceso está bas ada en una amplia comprensión c mún dentro de la organización de las ctividades, roles y responsabilidades definidas en el desarrollo de software. 4. Administrativo : se recolectan medidas detalladas del proceso de software y de la calidad del prod cto. Ambos son cuantitativamente entendidos controlados. El ciclo de Shewhart es constantemente utilizado para planear, imple entar y registrar las mejoras al proc so. Este nivel de capacidad permite a la orga nización predecir las tendencias en la calidad del producto dentro de los límites est blecidos y tomar las acciones necesa ias en caso que sean excedidos. Los producto s de dicha categoría son predeciblem nte de alta calidad. 5. Optimización : el mejoramiento continuo del proceso es garantizado por la retroalimentació cuantitativa y desde las pruebas de técniicas y herramientas innovadoras. La organización tiene los medios para identificar los puntos débiles y conocer como fortalecerlos. Su actividad clave es el análisis de l s causas de defectos y su prevención. El Modelo Tick IT El Departamento de Co ercio e Industria del Reino Unido (DTI: Department of Trade and Industry) creó el esquema Tick IT. Los objetivos primordiales de ést fueron, además de desarrollar un sistema de certificación aceptable en el mercad , estimular a los desarrolladores de software a implementar sistemas de calidad, dando la dirección y guías necesarias para tal ef cto. Aunque el proyecto original estuvo a cargo del DTI1, la responsabilidad actual p r el esquema Tick IT se pasó a DISC, que es un oficina dependiente de British Standards Institution (BSI) Standards Division, siendo esta últi a la única autoridad en el Reino Unido para publicar estándares. Ciclo de Vida del Soft are Un sistema de calidad típico Tick IT deberá contener los elemento que se enlistan a continuación: •

•

Elaboración de propuestas y revisión de contratos asegurando que todos los requerimientos stén bien especificados y de que la organizaci n tiene la capacidad para cumplirlos. Análisis y especificación de los requerimientos del sistema a egurando que sean revisados y acor ados con el cliente.


18

CALIDAD DE SOFTWARE

•

•

•

•

•

•

• •

•

• •

•

•

Planeación, control y monitoreo del avance del desarroll respecto al plan comunicando a odas las partes afectadas y que avise oportunamente de problemas potenciales. Planeación de l calidad del proyecto, especificando las inspe ciones, revisiones y pruebas requeridas durante el desarrollo. Inspecciones de los productos contra estándares y requerimientos aplicables y las acciones correctivas correspondientes. Diseño de primer nivel identificando los componentes principales y los requerimientos que satisfacen. Diseño detallado de todos los componentes e interfaces, construcción, y prueba de los mismos verificando que satisfagan la especificación. Integración, pr ebas e inspecciones del sistema, demostra do que el sistema integrado funcio a correctamente y satisface su especificación. Identificar, segr gar, investigar y corregir productos no conformes. Auditorias, prue as e inspecciones de aceptación del sistema d mostrando al cliente que el sistema s tisface los requerimientos. Almacenamiento, replicación, envío e instalación, asegurando la integridad y seguridad de los productos, así como el cumplimiento de los co promisos adquiridos con el cliente. Puesta en marcha y liberación del producto para disponibilidad d l cliente. Entrenamiento a usuarios en el uso del sistema de tal manera ue pueda operarlo y beneficiarse completamente del mismo con la mínima intervención del proveedor. Mantenimiento sustitución del sistema, asegurando que se c ntinúa operando en conformidad con los requerimientos del cliente o usuario. Soporte a clientes de acuerdo a lo especificado en el contrato.

Soporte y Aseguramiento de Calidad •

• •

•

•

•

•

•

•

•

•

•

Establecer políti as y objetivos de calidad generales de la organización que sirvan para alinearla en todas sus actividades, procedimientos y política específicas. Implantar y mantener un sistema de aseguramiento de calidad. Auditorias, revisiones y acciones correctivas al sistema de calidad que aseguren que el sistema cumple con los requerimientos, es utilizado y que es ef ectivo en el logro de resultados. Definir, recolect r y analizar datos de calidad para evaluar la ef ectividad del sistema de calidad e identificar mejoras potenciales. Administración e la organización y los proyectos de tal forma que facilite los resultados de calidad. Administración de la configuración que identifique y controle, de manera continua, las partes constituy ntes y sus versiones, de cada instancia de un sistema o subsistema. Respaldos, seguridad y almacenamiento que protejan contra cualquier pérdida o corrupción. Sistema de control de registros y documentación para toda las actividades de aseguramiento de calidad, de los proyectos y de soporte, incluye do procedimientos y registros. Especificación y control del proceso de desarrollo incluyendo técnicas, prácticas, convenciones, e tándares, mediciones y estadísticas. Proceso de com ras, incluyendo identificación, selección, adquisi ión y aceptación que asegure que los bienes y servicios adquiridos sean como se r quiere y de calidad aceptable. Control de pro uctos incluidos, equipo y herramientas utilizadas: Hardware o Software, adquiridos o suministrados por el cliente, in luyendo utilización, configuración, s guridad. Entrenamiento, reclutamiento y desarrollo de personal que aseg re su competencia y motivación, y disminuya su rotación.


19

CALIDAD DE SOFTWARE

El Modelo BOOTSTRAP El Instituto Bootstrap e una organización no lucrativa dedicada a la mejora continua del modelo de calidad de software llamado BOOTSTRAP, también tiene como propósito ayudar a la industria europea del software para mejorar su competitividad. Bootstrap es un método para analizar, rediseñar mejorar los procesos de negocio del desarrollo e software. Este se compone de: un modelo, un proceso de evaluación, una base de datos de soporte, un proceso de mejora y los instrumentos de evaluación. Su enfoque es evaluar el proceso, no el producto. Para eso se definen un conjunto de características para los procesos, provee un análisis cuantitativo, produce vistas analíticas, hace evidente fortalezas y debilidades, identifica áreas de mejo a, provee recomendaciones y sugiere un plan d e implementación. El modelo define el paradi ma Organización-Metodología- Tecnología que se usa en Bootstrap para los niveles de evaluación y agrupación de resultados.El modelo ootstrap se basa en evaluar las unidades de producción de software de la organización, a través de sus proyectos para hacer un cambio toda la organización. Dentro de este proces , hay cuatro etapas principales: reparación, ejecución de la evaluación, determinación de nivel de madurez y capacidades, y la presen tación de resultados de la evaluación . En la etapa de preparación se realizan las siguientes tareas: 1. un entrenamiento inicial para tener claros los objetivos 2. se seleccionan l s proyectos a ser evaluados para obtener la ejor cobertura de la UPS 3. se define el pers nal de evaluación para minimizar la subjetividad 4. se define el personal a ser evaluado para obtener la mejor c bertura de los roles involucrados en los proyectos seleccionados y 5. se hace el acuer o de confidencialidad. En la etapa de ejecuci n, las tareas son: 1. una breve reuni n de apertura, para obtener un enfoque colaborativo con el personal a ser entrevistado; 2. el llenado de los cuestionarios con características generales de la UPS; 3. el llenado de los cuestionarios del proyecto elegido, incluyendo l evaluación de cómo el proceso de pr ducción es aplicado; 4. revisión prelimin r de la evaluación, y 5. reunión final, co el enfoque de presentar los resultados de la evaluación y obtener el consenso para p der pasar a la fase de mejoras. En la etapa de determinar el nivel de madurez y capacidades, es onde se califica cada pregunta con uno de 5 alores posibles: nulo, débil, regular, extenso o no aplica. Para cada atributo clave se obtiene un nivel de madurez, aplicando un algoritmo n mérico, dando como resultado uno de estos niveles: 1-inicial, 2-repetible, 3-definido, -administrado o 5optimizado. Estos nivele de madurez están subdivididos en cuatro, de f rma que se obtenga una calificación más exa ta. Los procesos de organización y metodología se califican de 1 a 5, mientras que el de tecnología se califica sólo con dos niveles A o B. Como resultado de la valuación, la organización recibe 2 reportes, uno con los resultados de la evaluación de la U S y otro con los resultados del proyecto evaluado. El correspondiente a la UPS contiene información como: un resumen ejecutivo, los objetivos de la UPS, los puntos débiles y fuertes, un plan de acción recomendado, etc. El r eporte del proyecto contiene: comentarios del proyecto actual detallando lo referente a la organización, metodología y tecnología, los niveles de madurez para el proyecto , el plan de acción recomendado, etc. ING. FELIPE OMAR ALIAGA CAVERO

20

CALIDAD DE SOFTWARE

Uso de las Bases de Datos de Soporte. Una de las características pri cipales de Bootstrap es la base de datos con que cuenta para hacer análisis. Con esto se fundamenta el plan de mejoras, se pueden me ir las adaptaciones a la metodología, se pued comparar contra la industria y se pueden es ablecer objetivos basándose en la competencia. Proceso de Mejora Otra parte importante d la metodología de Bootstrap, es el plan de m ejora que sugiere. El proceso para obtener el lan de mejora es, Primero evaluar las necesidades de la organización tomando en cuenta las ejoras deseadas e indicadores sobre calidad de l producto y servicio, tiempo de desarrollo, c stos y riesgos del producto y del proyecto. nseguida hacer una revisión y análisis de esultados de la evaluación, tomando en cue nta las fortalezas y debilidades detectadas. espués definir las capacidades a mejorar, con iderando un período entre 18 y 24 meses. En seguida, definir las prioridades de acuerdo a un análisis de impactos. Finalmente sobre la ase de las actividades definidas, modificar la organización y responsabilidades para iniciar el cambio, estableciendo un marco e tiempos para su desarrollo y evaluación. El Modelo ISO/SPICE Software Process Impro vement and Capability D et ermination. La Orga ización Internacional para la Estandarización (ISO) creó el grupo de trabajo WG 10 y le encom ndó el desarrollo del estándar internacional de Valuación de Procesos de Software. El grupo de trabajo (Working Group) WG 10, empezó a trabajar en enero de 1993 bajo la dirección d Alec Dorling y Peter Simms, y decidieron crear el proyecto SPICE Software Process Improv ment and Capability Determination; la E de SPICE correspondía, originalmente, a "evaluation" y fue cambiado porque en algunos idiomas se traducía equivocadamente. Una d las características sobresalientes de este p oyecto de estandarización es que incluyó un pe riodo de pruebas del estándar de 2 años. Es d ecir, antes de ser publicado como estándar se h bía estado ajustando por la práctica. Arquitectura del Mod lo El modelo es tridimensi nal: la primera dimensión es funcional (procesos), la segunda de capacidades (niveles), la tercera de adecuación o efectividad (califica iones). La dimensión PROCESO: Está organizada jerárquiicamente de la siguiente manera: CATEGORÍA DE PROCESOS, que agrupan procesos co unes; PROCESOS, que logran propósitos t cnicos; PRÁCTICAS BÁSICAS, operaciones ue conforman un proceso. Las categorías definidas son: ClienteProveedor, Ingeniería, Proyecto, Organización y Soporte. La dimensión CAPACID D: Está organizada ordinal ente en niveles de capacidad y se han definid cinco niveles. En la versión 1.0 éstosestos niveles son: Desempeño informal, Planeación y seguimiento bien definido, Cuantitativamente controlado, Mejora continua. Está en etap de instrumentación una versión 2.0. La tercera dimensión es la CALIFICACIÓN: El juicio mismo: ¿qué c lificación le doy a este proceso en este atribut de capacidad?. Las escalas que se manejan son discretas de tipo: 0 = No adecuado, 1 = Pa cialmente adecuado, 2 = Muy Adecuado, 3 = otalmente Adecuado. Los Elementos de Evaluación Marco de Valor El Modelo ISO/SPICE tiene un marco de valor explícito. En la dime sión funcional o de proceso: las "mejores p ácticas". En la dimensión de capacidad: los at ibutos de proceso o ING. FELIPE OMAR ALIAGA CAVERO

21

CALIDAD DE SOFTWARE

prácticas genéricas qu incrementarán la capacidad del proceso. componentes más valios s del estándar internacional.

ste es uno de los

Evidencia La evidencia para la evaluación serán los productos producidos por las p ácticas base. Éste es un enfoque de efectividad… "por sus frutos los conoceréis…". Cada producto tipo ha sido catalogado y sus cara terísticas de calidad definidas. Este es otro elemento filosófico fundamental de ISO/SPI E: no es un modelo nominalista. Recurrencia Por último el elemento r currencia, para fundamentar un juicio o evalua ión vendrá dada por la selección de instancia de proyectos o productos representativas, a juicio del Evaluador, de las capacidades reales d l proceso de software. Conceptualmente el mo elo ISO/SPICE es un modelo inductivo en su arte funcional: de característica a producto, de roducto a práctica, y de práctica a proceso. E su parte de capacidades es un modelo evolutivo. Es, en general, un modelo realista: va a ver los productos, es decir, la efectividad de los pr cesos no lo que está escrito en algún manual de calidad o de procesos.

EL MODELO MC-CALL Introducción El modelo de McCall org aniza los factores en tres ejes o puntos de vist desde los cuales el usuario puede contempl r la calidad de un producto, basándose en onc e factores de calidad organizados en torno a l s tres ejes y a su vez cada factor se desglosa en otros criterios: Puntos De Vista o Ejes

Factor

Criterios •

O T C U D O R P L E D N Ó I C A R E P O

o s u e d d a d i l i c a F

•

•

•

•

d a d i r g e t n I

•

•

•

n ó i c c e r r o C

•

•

Faciilidad de operación: Atributos del software que determinan la facillidad de operación del software. Faciilidad de comunicación: Atributos del software q e proporcionan ent adas y salidas fácilmente asimilables. Faciilidad de aprendizaje: Atributos del software que facilitan la fa iliarización inicial del usuario con el software y la transición del modo act al de operación. Formación: El grado en que el software ayuda para ermitir que nuevos usuarios apliquen el sistema. Co trol de accesos. Atributos del software que prop rcionan control de acc so al software y los datos que maneja. Faciilidad de auditoría: Atributos del software que fa ilitan la auditoría de los accesos al software. Seguridad: La disponibilidad de mecanismos que co trolen o protejan los programas o los datos. Co pletitud: Atributos del software que proporcionan la implementación co pleta de todas las funciones requeridas. Co sistencia: Atributos del software que proporcion n uniformidad en las técnicas y notaciones de diseño e implementación. Tra abilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los requisitos a la implementación c on respecto a un ent rno operativo concreto.


22

CALIDAD DE SOFTWARE

•

O T C U D O R P L E D N Ó I C A R E P O

O T C U D O R P L E D N O I S I V E R

•

d a d i l i b a i F

•

•

•

•

a i c n e i c i f E

•

o e t d n e i d m a i d n i l e i t c n a F a m

•

e d a d b a e d u i l i r c p a F

d a d i l i b i x e l F

•

• • •

•

• • • •

• •

•

• •

O T C U D O R P L E D N O I C I S N A R T

d a d i l i b a s u e R

d a d i l i b a r e p o r e t n I d a d i l i b a t r o P

• • •

•

• •

•

•

• • • •

Pre isión: Atributos del software que proporcionan el grado de precisión req erido en los cálculos y los resultados. Co sistencia. Tol rancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales. Mo ularidad: Atributos del software que proporcion n una estructura de mó ulos altamente independientes. Simplicidad: Atributos del software que posibilitan la implementación de fun iones de la forma más comprensible posible. Ex ctitud: La precisión de los cálculos y del control. Eficiencia en ejecución: Atributos del software que inimizan el tiempo de rocesamiento. Eficiencia en almacenamiento: Atributos del softwar que minimizan el espacio de almacenamiento necesario. Mo ularidad. Simplicidad. Co sistencia. Co cisión: Atributos del software que posibilitan la i plementación de una función con la menor cantidad de códigos posiblle. Auto descripción: Atributos del software que propor ionan explicaciones sobre la implementación de las funciones. Mo ularidad. Simplicidad. Auto descripción. Ins rumentación: Atributos del software que posibili an la observación del comportamiento del software durante su ejecuci n para facilitar las me iciones del uso o la identificación de errores. Auto descripción. Capacidad de expansión: Atributos del software que posibilitan la expansión del software en cuanto a capacidades funcionales y datos. Ge eralidad: Atributos del software que proporcionan amplitud a las fun iones implementadas. Mo ularidad. Auto descripción. Ge eralidad. Mo ularidad. Independencia entre sistema y software: Atributos del software que det rminan su dependencia del entorno operativo. Independencia del hardware: Atributos del software que determinan su dependencia del hardware. Mo ularidad. Co patibilidad de comunicaciones: Atributos del sof tware que posibilitan el uso de protocolos de comunicación e interfaces e tándar. Co patibilidad de datos: Atributos del software que posibilitan el uso rep esentaciones de datos estándar. Est ndarización en los datos: El uso de estructuras e datos y de tipos est ndar a lo largo de todo el programa. Auto descripción. Mo ularidad. Independencia entre sistema y software. Independencia del hardware.


23

CALIDAD DE SOFTWARE

Cómo emplear el modelo de c-Call. Antes de comenzar a utiliizar el modelo de McCall hay que seguir las sigui ntes pautas: 1. Se aceptan los factores, criterios y métricas que propone el modelo. 2. Se aceptan las relaci nes entre factores y criterios, y entre criterios y métricas. 3. Se selecciona un subconjunto de factores de calidad sobre los que ap licar los requisitos de calidad establecidos ara el proyecto. Al comienzo del proyecto habrá que especificar los requisitos de calidad del producto software, para lo cual e seleccionarán los aspectos inherentes a la calidad deseada del producto, teniendo que considerarse para ello: ♦

♦

Las características pa ticulares del propio producto que se está diseñando: por ejemplo, su ciclo de vida que si s e espera que sea largo implicará un mayor énf sis en la facilidad de mantenimiento y la lexibilidad, o bien si el sistema en desarrollo está destinado a un entorno donde el hardware evoluciona rápidamente implicará como requisito su portabilidad. La relación calidad-pr cio, que puede evaluarse a través del coste de ada factor de calidad frente al beneficio q e proporciona. La siguiente tabla muestra la r lación calidad-precio para cada factor considerado: Factor Correc ión Fiabilidad Eficien ia Integri ad Facilid d de uso Facilid d de mantenimiento Facilid d de prueba Flexibilidad Portabilidad Reusabilidad Interoperabilidad

♦

♦

Beneficio/Coste alto alto bajo bajo medio alto alto medio medio medio bajo

La determinación de las etapas del ciclo de vida donde es necesario e valuar cada factor de calidad para conocer en cuales se dejan sentir más los efectos de u a calidad pobre con respecto a cada uno e los factores. Las propias interrelaciones entre los factores debido a que algunos fa ctores pueden entrar en conflicto entre sí: por ejemplo, la eficiencia plantea conflictos prá ticamente con todos los demás factores d calidad. La interacción entre los diversos fact res a evaluar queda reflejada en la tabla I que indica la dependencia entre los factores de cCall.

También habrá que esta lecer valores deseables para los criterios, para lo cual se emplearán datos históricos, el pro edio en la industria, y con ellos se concretarán los valores finales y otros intermedios o predictivos en cada período de medición durante el desarrollo, así como unos valores mínimos ac ptables. La explicación para cual uier selección o decisión deberá ser adecuadamente documentada. En la fase de desarrollo será necesario implementar las métricas elegidas, analizar sus resultados y tomar medi as correctivas cuando los valores obtenidos estén por debajo de los mínimos aceptables. Una vez finalizado el pr yecto será necesario contrastar las medidas pr edictivas utilizadas y ING. FELIPE OMAR ALIAGA CAVERO

24

CALIDAD DE SOFTWARE

comprobar si, en efecto, se pueden tomar como indicadores de los valore s finales. Descripción de los factores Mc-Call 1. Corrección: Hasta qué punto un programa cumple sus especifica iones y satisface los objetivos del usuario. Por ejemplo, si un programa debe ser capaz d sumar dos números y en lugar de suma los multiplica, es un programa incorrecto. Es quizás el factor más importante, aunque uede no servir de nada sin los demás factores. 2. Fiabilidad: Hasta ué punto se puede confiar en el funcionamiento sin errores del programa. Por ejem lo, si el programa anterior suma dos números, pero en un 25% de los casos el resultad que da no es correcto, es poco fiable. 3. Eficiencia: Cantida de código y de recursos informáticos (CPU, me oria) que precisa un programa para dese peñar su función. Un programa que suma dos úmeros y necesita 2 MB de memoria pa a funcionar, o que tarda 2 horas en dar una respuesta, es poco eficiente. 4. Integridad: Hasta ué punto se controlan los accesos ilegales a programas o datos. Un programa que per ite el acceso de personas no autorizadas a ci ertos datos es poco íntegro. 5. Facilidad de uso: l coste y esfuerzo de aprender a manejar un roducto, preparar la entrada de datos e i terpretar la salida del mismo. 6. Facilidad de mant nimiento: El coste de localizar y corregir defectos en un programa que aparecen durante su funcionamiento. 7. Facilidad de prueba: El coste de probar un programa para comprobar que satisface sus requisitos. Por ejem lo, si un programa requiere desarrollar una si ulación completa de un sistema para pod r probar que funciona bien, es un programa difí il de probar. 8. Flexibilidad: El cos e de modificación del producto cuando cambian sus especificaciones. 9. Portabilidad (o Transportabilidad): El coste de transportar o migra un producto de una configuración hardw re o entorno operativo a otro. 10. Facilidad de Reutilización: Hasta qué punto se puede transferir u módulo o programa del presente sistema a otra aplicación, y con qué esfuerzo. 11. Interoperabilidad: El coste y esfuerzo necesario para hacer qu el software pueda operar conjuntamen e con otros sistemas o aplicaciones software ext rnos. Cada uno de estos factor es se descompone, a su vez, en criterios. En el modelo de McCall se definen un total de 23 criterios, con el siguiente significado: 1. Facilidad de opera ión: Atributos del software que determinan la f acilidad de operación del software. 2. Facilidad de comunicación: Atributos del software que proporcionan al usuario entradas y salidas fá ilmente asimilables. 3. Facilidad de apre dizaje: Atributos del software que facilitan la familiarización inicial del usuario con el so tware y la transición desde el modo actual de operación. 4. Control de acces s: Atributos del software que proporcionan ontrol de acceso al software y los datos ue maneja. 5. Facilidad de audit ría: Atributos del software que facilitan el regi tro y la auditoría de los accesos al software. 6. Eficiencia en ejecución: Atributos del software que minimizan el tiempo de procesamiento. 7. Eficiencia en alm cenamiento: Atributos del software que minimizan el espacio de almacenamiento nec sario. 8. Precisión: Atributos del software que proporcionan el grado de precisión requerido en los cálculos y los resulta os. 9. Consistencia: Atributos del software que proporcionan uniformid d en las técnicas y notaciones de diseño e implementación utilizadas. 10. Tolerancia a fall s: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales. ING. FELIPE OMAR ALIAGA CAVERO

25

CALIDAD DE SOFTWARE

11. Modularidad: Atributos del software que proporcionan una estructura de módulos altamente independi ntes. 12. Simplicidad: Atribu os del software que posibilitan la implementaci n de funciones de la forma más comprensible posible. 13. Completitud: Atrib tos del software que proporcionan la implementación completa de todas las funciones r queridas. 14. Trazabilidad (Rastreabilidad): Atributos del software que proporcionan una traza desde los requisitos a la im lementación con respecto a un entorno operativo concreto. 15. Auto descripción: Atributos del software que proporcionan explicaciones sobre la implementación de las funciones. 16. Capacidad de ex ansión: Atributos del software que posibilit n la expansión del software en cuanto a capacidades funcionales y datos. 17. Generalidad: Atributos del software que proporcionan amplit d a las funciones implementadas. 18. Instrumentación: Atributos del software que posibilitan a l observación del comportamiento del oftware durante su ejecución (para facilitar las mediciones del uso o la identificación de errores). 19. Independencia en re sistema y software: Atributos del software que determinan su independencia del entorno operativo. 20. Independencia del hardware: Atributos del software que determi an su independencia del hardware. 21. Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso de protocolos de comunicación e interfaces estándar. 22. Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos estándar. 23. Concisión: Atributo del software que posibilitan la implementación e una función con la menor cantidad de c digo posible.


26

CALIDAD DE SOFTWARE

NIDAD DIDÁCTICA N° 03 MÉTRICAS DE CALIDAD DE SOFTWAR

ESTÁNDAR ISO 9126 Introducción El estándar ISO 9126 ha sid desarrollado en un intento de identificar los atributos de de calidad para el software. El estándar identifica seis atributos clave de calidad: •

•

•

•

•

•

Funcionalidad. El rado en que el software satisface las necesida es indicadas por los siguientes sub-atri utos: idoneidad, corrección, interoperavilid d, conformidad y seguridad. Confiabilidad. Cantidad de tiempo que el software está disponiblle para su uso. Está referido por los siguientes sub-atributos: madurez, tolerancia a f allos y facilidad de recuperación. Usabilidad. Grado n que el software es fácil de usar. Viene reflejado por los siguientes sub-atributos: facilid d de comprensión, facilidad de aprendizaje y op eratividad. Eficiencia. Grado e que el software hace óptimo el uso de los recursos del sistema. Está indicado por los siguiientes sub-atributos: tiempo de uso y recursos u ilizados. Facilidad de ma tenimiento. La facilidad con que una mo ificación puede ser realizada. Está indic da por los siguientes sub-atributos: facilidad de análisis, facilidad de cambio, estabilidad facilidad de prueba. Portabilidad. La facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes sub-atributos: facilidad de instalació , facilidad de ajuste, facilidad de adaptación al cambio.

Los factores ISO 9126 no ne cesariamente son utilizados para medidas directas. En cualquier caso facilitan una valiosa base pa a medidas indirectas y una excelente lista para determinar la calidad de un sistema. La transición a una visión cu ntitativa En las separatas prece entes se estudiaron un conjunto de factores cualitativos para la «medición» de la calida del software. Intentamos desarrollar medidas exactas de la calidad del software frustradas veces por la naturaleza subjetiva de la actividad. Cavano y McCall estudian esta situación: La determinación de la c alidad es un factor clave en los acontecimientos diarios: concursos de cata de vinos, aconteci ientos deportivos (por ejemplo, la gimnasia), oncursos de talento, etc. En estas situacion s, la calidad se juzga de la manera más fu damental y directa: comparación de objetos unos al lado de los otros bajo condiciones idén icas y con conceptos redeterminados. El vin o puede ser juzgado de acuerdo con su clari dad, color, bouquet, sabor, etc. Sin embargo este tipo de juicio es muy subjetivo; para que tenga algo de valor, debe hacerse por un exp erto.

La subjetividad y la especialización también influyen en la determinación de la calidad del software. Para resolver ste problema, se necesita una definición de cali ad del software más exacta, así como una ma nera de obtener medidas cuantitativas de la cali ad del software para ING. FELIPE OMAR ALIAGA CAVERO

27

CALIDAD DE SOFTWARE

hacer un análisis objetiv .... Como no existe el conocimiento absoluto, n deberíamos esperar poder medir la calidad del software exactamente, ya que cada medi ión es parcialmente imperfecta. En las siguientes seccio es examinamos un conjunto de métricas del oftware que pueden aplicarse a la valoració cuantitativa de la calidad del software. En todos los casos, las métricas representan m didas indirectas; es decir, realmente nunca me imos la calidad sino alguna manifestación de la calidad. El factor que lo complica es la rel ción exacta entre la variable que se mide y la calidad del software.

Métricas de calidad de softw re 1. Corrección: Hasta qué punto un programa cumple sus especifica iones y satisface los objetivos del usuario. Por ejemplo, si un programa debe ser capaz d sumar dos números y en lugar de suma los multiplica, es un programa incorrecto. Es quizás el factor más importante, aunque uede no servir de nada sin los demás factores. úmero de requerimientos implementados Corrección = -------------------------------------------------------------------- --Nú ero de requerimientos determinados en el análi is ING. FELIPE OMAR ALIAGA CAVERO

28

CALIDAD DE SOFTWARE

2. Fiabilidad: Hasta ué punto se puede confiar en el funcionamiento sin errores del programa. Por ejem lo, si el programa anterior suma dos números, pero en un 25% de los casos el resultad que da no es correcto, es poco fiable. Fiabili ad = 1 - (número de errores / número de intent s) 3. Eficiencia: Cantida de código y de recursos informáticos (CPU, me programa para desempeñar su función. Un programa que suma do 2MB de memoria p ra funcionar, o que tarda 2 horas en dar un eficiente. Para el c lculo de la eficiencia, se debe medir el valor módulo según los siguientes parámetros: (ISO 9126) •

oria) que precisa un números y necesita respuesta, es poco por cada función o

Uso de Pro esador (en porcentaje)  UP La cantidad e procesador que emplea el módulo durante su ejecución

•

Uso de Me oria (en megabytes)  UM

La cantidad e memoria que emplea el módulo durante su ej cución •

Tiempo (en segundos)  T

La cantidad e segundos que emplea el módulo para efectua cálculos

La eficiencia est dada por las fórmulas: UP-Promedio = UP-Disponible / Número de Módulos UM-Promedio = UM-Disponible / Número de Módulo T- romedio = T-Disponible / Número de Módulos Se calculará las ficiencias parciales por cada módulo: ficiencia-UP(i) = UP(i) / UP-Promedio ficiencia-UM(i) = UM(i) / UM-Promedio ficiencia-T(i) = T(i) / T-Promedio Se calculará la e iciencia final:

Eficiencia = 1 -

n Σ [Efi iencia-UP(i)+Eficencia-UM(i)+Eficencia-T(i)] / 3 i=1 Número de módulos (n)

4. Integridad: Hasta ué punto se controlan los accesos ilegales a programas o datos. Un programa que per ite el acceso de personas no autorizadas a ci ertos datos es poco íntegro. Integridad = 1-(número de accesos ilegales/número total de accesos) 5. Mantenimiento: El coste de localizar y corregir defectos en un programa que aparecen durante su funciona iento. Mantenimiento = 1 - 0.1 (número medio de días-hombre por corr ección) 6. Índice de madure del software: IMS = [ MT - ( FA + FC + FD ) ] / MT ING. FELIPE OMAR ALIAGA CAVERO

29

CALIDAD DE SOFTWARE

Donde: MT: Número de ódulos de la versión actual FC: Número de ódulos en la versión actual que han cambiado FA: Número de ódulos en la versión actual que se han añadido FD: Número de ódulos de la versión anterior que se ha borrado en la actual A medida que el IMS se aproxima a 1.0 el producto se empieza a estabilizar. EL IMS puede emplears también como métrica para la planificación e las actividades de mantenimiento el software. El tiempo medio para producir una versión de un producto softw re puede correlacionarse con el IMS desarrollándose modelos empíricos para el mantenimiento. 7. Flexibilidad: El cos e de modificación del producto cuando cambian sus especificaciones. Flexibilid d = 1 - 0.05 (número medio de días-hombre po r cambio) 8. Capacidad de Pru bas: El coste de probar un programa para co probar que satisface sus requisitos. Por e emplo, si un programa requiere desarrollar una simulación completa de un sistema para oder probar que funciona bien, es un programa difícil de probar. CP = 1-(número de funciones probadas/número total de fu ciones) 9. Portabilidad (o Tr nsportabilidad): El coste de transportar o m igrar un producto de una configuración hardware o entorno operativo a otro. Portabili ad = 1-(esfuerzo para portar/esfuerzo para impl ementar) 10. Reusabilidad: Hasta qué punto se puede transferir un módulo o pr ograma del presente sistema a otra aplicación, y con qué esfuerzo. Reusabilida = Σ portabilidad por módulo / número total de módulos 11. Interoperabilidad: El coste y esfuerzo necesario para hacer qu el software pueda operar conjuntamen e con otros sistemas o aplicaciones software ext rnos. Interoperabilidad = módulos integrados / módulos del so tware 12. Usabilidad: El cost y esfuerzo de aprender a manejar un producto, preparar la entrada de datos e interpretar la salida del mismo. Tiempo medio de aprendizaje por módulo Usabilidad = --- ----------------------------------------------------------Tiempo de aprendizaje total / Número de módul s


30

CALIDAD DE SOFTWARE

UNIDAD DIDÁCTICA N° 04 EJECUCIÓN D L CONTROL DE CALIDAD DE S FTWARE Introducción El objetivo de las actividades de Control de Calidad es comprobar si un producto posee o no posee una determinada característica de calidad en el grado requerido. Cuando un producto no posee una determin da característica de calidad se dice que tiene un DEFECTO. Por lo tanto, se puede decir ta bién que el objetivo del Control de Calidad es i entificar defectos en el producto y corregirlos. Se pueden clasificar la actividades de control de calidad en dos ategorías: controles estáticos y controles dinámicos. Los primeros analizan el objeto sin ne esidad de ejecutarlo mientras que los segund s requieren la ejecución del objeto que está sie do probado.


31

CALIDAD DE SOFTWARE

La barrera entre control s estáticos y dinámicos no es totalmente estrict . Cualquier forma de control dinámico requiere un cierto grado de análisis estático. Además ay algunas técnicas, como la verificación formal y la ejecución simbólica, consideradas omo estáticas, que "ejecutan" el código, aunque en un entorno no real.

CONTROLES ESTÁTICOS Controles Estáticos Manuale Controles estáticos m nuales informales Estas actividades las realizan los propios autores de los objetos a comp obar, o personas de su misma categoría y oc pación. Comprobación de escritorio (desk checking): Consiste en examinar a mano e individualmente el objeto que se acaba de desarrollar. Es el método más tradicionall para analizar un programa. Se debe aplicar a los requisitos, especificaciones de dis ño y código según se van desarrollando. D be ser cuidadoso y concienzudo para que sea efectivo. Es más efectivo si se hace interca mbiando el objeto a examinar con otro comp ñero. Revisión por pares o igu les (peer review): Consiste en la revisión d l código de un programador por otros programa ores (sus pares). Se puede poner en práctica creando un panel que se encarga de revisar periódicamente muestras de código. Controles estáticos m nuales disciplinados Las revisiones y auditorí s son la evolución natural de la Comprobación de Escritorio, pero a diferencia de aquélla pa an a ser técnicas de grupo. Su misión principal es conseguir que la responsabilidad del control de calidad no recaiga sólo sobre el propio des rrollador. Auditorias Una auditoría consiste e realizar una investigación para determinar: - El grado de c mplimiento y la adecuación de los procedimientos, instrucciones, especificaciones, ódigos, estándares u otros requisitos de tipo co tractual establecidos y aplicables. - La efectivida y adecuación de la implementación realizada. Se pueden consi erar tres tipos de auditorías: 1.- Auditoría d l producto: El objetivo es cuantificar el grad de conformidad del producto con las características requeridas. Las auditorías del producto software más comunes son la auditoría Funcional y la auditoría Física. 2.- Auditoría del proceso: El objetivo es evaluar el proces de desarrollo o de gestión, y eval ar su completitud y efectividad, determinan o dónde se puede mejorar. En el esarrollo de software se suelen realizar dos ti os de auditorías del proceso: - Auditorías de proyecto: cuyo objetivo es evaluar la productividad y ING. FELIPE OMAR ALIAGA CAVERO

32

CALIDAD DE SOFTWARE

eficacia el equipo que trabaja en un proyecto así como la efectividad de los métodos y herramientas utilizados. - Auditorías de gestión de proyecto: cuyo objetivo es evaluar la efectivid d de las prácticas de gestión realizadas y la organización del proyecto. 3.- Auditoría el sistema de calidad: El objetivo es eval ar la completitud y efectividad del p opio sistema de calidad establecido.

El procedimiento habitual para realizar una auditoría consta de los siguientes pasos: 1. Planificación: Consiste en definir los objetivos de la auditoría y su alca ce. En esta etapa se elabora un Plan de A ditoría, que debería dar respuesta a cuestiones del tipo de las siguientes: - ¿Por qué se reali a la auditoría? Puede ser una auditoría de ruti a o puede realizarse para resolver pr blemas concretos. - ¿Para qué se realiza? para mejorar, para conseguir una certificación,... ¿Cuál es el producto q e va a ser auditado? - ¿Qué resultados se esperan de la auditoría? En principio, u a auditoría debería identificar situaciiones problemáticas, tales como desviaciones del estado actual con respecto al esta o deseado, y sugerir posibles soluciones o mejoras. ¿Cómo y dónde s van a utilizar los resultados de la auditoría? - ¿Quiénes son los responsables de llevarla a cabo? ¿De qué forma s va a llevar a cabo? Incluyendo una especifica ión de los datos que se van a recoger de qué forma se van a recoger. ¿Cuándo se va a ealizar? 2. Llevar a cabo la inv stigación. Por lo general la auditoría se inicia con una reunión de apertura de la investigación, y se lleva a cabo mediante entrevistas y re isiones en las que se recopilan datos. 3. Analizar los datos re ogidos. Por lo general el equipo de auditores debe hacer frente a cantidades ingentes de datos, de entre los cuales resulta complicado eleccionar los datos relevantes, por lo que e suelen utilizar técnicas de análisis estadístic . A continuación se realiza una evaluación en paralelo de los resultados por un grupo de evaluadores, se comparan las conclusi nes obtenidas y se estudian las causas e las desviaciones significativas. 4. Sugerir soluciones a los problemas encontrados y posibles mejoras. 5. Elaborar y presentar u n informe de resultados.


33

CALIDAD DE SOFTWARE

Revisiones Se puede definir una revisión como una reunión formal en la que se presenta el estado actual de los resultados de un royecto a un usuario, cliente u otro tipo de per ona interesada, y se realiza un análisis estruc urado de los mismos. Uno de los objetivos f ndamentales de las revisiones técnicas es of ecer a los gestores información fiable acerca de los aspectos técnicos del proceso de desarrollo de software, de la misma forma que les ll ga información fiable acerca de los costes y la programación del trabajo, para que con e ta información puedan tomar decisiones adecuadas para dirigir con éxito el proyecto. Con las revisiones se c nsigue que el peso de la evaluación técnica o recaiga sobre las mismas personas involu radas en la producción del software, que por la posición que ocupan no pueden ser totalme te objetivas, sino en otras personas técnica ente competentes y objetivas. Las revisiones son, hoy en día, el único método de control de calida eficaz en las fases iniciales del desarrollo a la hora de identificar desviaciones con respecto las especificaciones de calidad. Las revisiones redundan en una mejora directa de la calidad del obje o que se examina y provocan, indirectament , una mejora de la calidad del proceso de de arrollo, al facilitar la comunicación entre los iembros del equipo de desarrollo. Al mismo tie po facilitan el control del coste y el tiempo. Las diferencias más imp rtantes entre las revisiones y las auditorías son l s siguientes: - Las revisiones se llevan a cabo desde las primeras fases del desarr llo, mientras que las auditorías se llevan a cabo en las fases finales. - El objetivo de las revisiones es detectar defectos, mientras qu el objetivo de las auditorías es certificar conformidad e identificar desviaciones. Tipos de revisiones

Hay dos tipos fundamentales de revisiones: las inspecciones y los walkt rough. La diferencia entre ellos está en la for a en que se desarrolla la reunión de revisión. - Inspecciones: En l s que los participantes van leyendo el docu ento, paso a paso, guiados por el autor del mismo, y comprobando en cada paso el cumplimiento de los criterios de una lista e comprobación. - Walkthrough (visita guiada): En las que se demuestra la funcionalidad del objeto revisado mediante la simulaciión de su funcionamiento con casos de pru ba y ejemplos. Se introducen al objeto l s casos de prueba y se van registrando los resultados intermedios.

Aunque estos son los ti os ideales, en la vida real hay otras muchas variantes intermedias, desde las revisiones sin disciplina alguna hasta cualquier tipo de mezcla entre inspecciones y walkthrough. Otras diferencias esenciales entre inspecciones y walkthrough son las sig ientes: ING. FELIPE OMAR ALIAGA CAVERO

34

CALIDAD DE SOFTWARE

- Los walkthrough están planteados como una medida de ay da al desarrollador, mientras que las inspecciones están planteadas como una medida de ayuda al gestor. En los walkthrough el objetivo fundamental es incrementar el entendimiento, comprender mejor el objeto, mientras que en las inspecciones el objetivo es detectar defectos. - En las inspecci nes el proceso está guiado por la lista de co probación, y en los walkthrough est guiado por la estructura del producto revisado. - Las inspeccion s se planifican y procesan de una manera mucho más formal que los walkthrough. S usan para asegurar la satisfacción de los criterios de salida establecidos entre diferentes etapas del desarrollo (revisiones de fase). La siguiente tabla resum algunas diferencias adicionales entre ellas: Propiedades

Inspecci n Walkthrough

1. Requiere entrenamiento formal del moderador

SI

NO

2. Hay unos roles defini os para los participantes

SI

NO

3. Quién guía la revisión

El modera or El propietario del producto revisado SI NO SI NO

4. Se usan listas de comprobación 5. Se usan distribucione por tipo de los errores a buscar

6. Hay un seguimiento para controlar que la corrección es SI correcta 7. Se puede mejorar la ficiencia de la revisión analizando los SI resultados

NO NO

Fases en una Inspección: 1. Planificación: La reparación comienza con la selección de los participantes. Debe designarse un coordinador o moderador; un secretario; un presentador, de entre los productores del objeto que se revisa; y otros revisores, que pueden ser desarrolladores, representantes de los us arios, revisores externos; y posiblemente otros. El coordinador es responsable de la planificación de la inspección, de moderar la reunión (mantener el orden, m ntener el foco de la revisión, asegurar que se cubren todos los aspectos necesarios), de preparar el informe final y de realizar el seguimi ento y evaluación de las acciones pendientes. El secretario es responsable de anotar los elementos de interés (defectos y anomalías descubiertas, acciones endientes) y ayudar al coordinador en la pre aración del informe final. En la planificación es ta bién necesario determinar: - Los objetivos de la inspección - Los criterios de finalización de la inspección - El lugar y la fe ha para la inspección - La disponibilidad de todos los participantes - La agenda de l reunión 2. Orientación inicial: Es recomendable realizar una reunión de ori ntación, previa a la inspección propiamente dicha, cuando se trata de examinar por primer vez un objeto, para dar a los participantes e la revisión una idea del objeto que van a revisa . ING. FELIPE OMAR ALIAGA CAVERO

35

CALIDAD DE SOFTWARE

3. Preparación individual: Con suficiente tiempo antes de la realizació de la inspección, se debe hacer llegar a cada revisor una copia de la documentación asociad al objeto que se va a revisar, junto con u a lista de comprobaciones o "checkiist" enu erando los posibles defectos que se deben i tentar localizar. Una lista de comprobaciones contiene una serie de preguntas, y se supone que al intentar dar respuesta a estas pregunta saldrán a la luz los problemas que puedan xistir. Cada revisor debe completar la lista y an tar cualquier tipo de pregunta o defecto dete tado. 4. Reunión de inspec ión: Durante la reunión, el presentador o autor del objeto revisado va guiando al resto a través del mismo para comprobar cada uno de los puntos de la lista de comprobación. Hay varias formas de guiar la reunión: - Punto por punt de la lista de comprobación, revisando todo ell producto para cada uno de ellos. - Componente a componente del producto, revisando todos los puntos de la lista de comprobación ara cada componente. - Por grupos de puntos dentro de la lista de comprobación, revisando todo el producto para cada grup . - Cualquier otra s lución intermedia Los defectos que se d tecten durante este proceso se añaden a u a lista de acciones pendientes. Hay que tener en cue ta que el objetivo de una inspección es descubrir defectos, no corregirlos. Por otro lado, los revisores deben restringirse a los hechos y ser constructivos. Es misión del moderador as gurarse de que esto se cumple. Al final de la reunión de inspección, los participantes valoran los resultados de la inspección y se completa un informe. Al finalizar la reunión se pueden producir las sig ientes situaciones: - Se cierra la ins ección sin que se hayan encontrado defectos. - Se cerrará la inspección después de que los defectos encontrados se hayan eliminado en l fase de seguimiento. - No se cierra lla inspección porque se encontraron defectos importantes, y será necesario realizar una nueva inspección. 5. Seguimiento: Durante esta fase, el autor del objeto revisado se encarga de corregir los defectos encontrados y enerar un informe en el que se especifican las acciones correctivas realizadas para eliminar los distintos defectos. 6. Evaluación: Es la últiima fase y en ella se trata de determinar si se han corregido todos los defectos y si han surgid nuevos problemas durante el proceso de corr cción. El moderador se encarga de realizar la evaluación y enviar un informe a la dirección un vez finalizada. Documentos generados en una inspección

Algunos de los inform s o documentos que pueden generarse como resultado de una inspección son los siguie tes: -

Informe re umen de la inspección: Conclusiones breves de la inspección (una página o dos) para la dirección: - Qué s ha revisado - Quién lo ha revisado - Cuál f e la conclusión


36

CALIDAD DE SOFTWARE

-

-

Lista de ac iones pendientes: Es un informe para los aut res del producto revisado e plicando qué es lo que está mal y, si puede ser, cómo corregirlo. Necesita ser claro, pero no muy elaborado. Es un documento técnico y transitorio. No debe llegar a la dirección, para no abur irlos con tantos datos y para que no puedan usar esta información en perj icio del proceso de inspecció . Informe de asuntos relacionados: Para registrar problemas que salen a la luz durant la inspección pero no están relacionados directamente con el objeto revisado, para que sean notificados a la persona res onsable. Informe del proceso de inspección: Cuando algo ha sali o mal en el proceso de inspec ión en sí mismo. Informe final: Para informar a la dirección del cierre de la i spección.

Fases en un Walkthroug : ING. FELIPE OMAR ALIAGA CAVERO

37

CALIDAD DE SOFTWARE

El proceso para realizar un walkthrough es mucho más sencillo y con sta de tan sólo tres fases: 1. Planificación: Similar a la planificación de una inspección, con la diferencia de que no es n cesario asignar roles específicos a los participantes, a excepción del presentador, que es quien organiza el walkthrough y guía la reunión. 2. Preparació individual: Cada revisor examina el objeto revisado, aunque en este caso no se lles entregará una lista de comprobación. 3. Reunión de walkthrough La siguiente tabla resu e las fases de inspecciones y walkthrough e in ica los objetivos que se persiguen en cada una de ellas: Inspección Etapas

bjetivo

Walkthrough Etapas

bjetivo

1. Orientación

Educación (grupo)

-

2. Preparación individual

Educación (individual)

1. Preparación individual

ducación (individual)

3. Reunión

Encontrar errores (grupo)

3. Reunión

ducación (grupo) iscusión de alternativas e diseño Encontrar rrores

4. Seguimiento 5. Evaluación

rreglar problemas

-

-

-

segurar que todos los problemas se han resuelto correctamente

-

Formalidad en las revisiones Se puede diferenciar también entre las revisiones formales e informal s. Se dice que una revisión es formal cuand : - Es un evento úblico - Se informa po escrito de los resultados - Todos los participantes son responsables de la calidad de la re isión. La ventaja de realizar revisiones formales es que los informes que se generan sirven como hitos para el pr yecto, y el hecho de ser algo público prom eve una mejor preparación por parte de los participantes. Por contra, la formalidad hace que este tipo de reuniones sean un tanto impersonales. Para evitar que los participantes se sientan intimidados por el ambie te impersonal y expresen libremente su opiniones se pueden utilizar técnicas como el ound-robin, que consiste en ir pasando ell tumo de uno a otro por todos los participantes n la revisión. Revisiones técnicas y de gestión

Por otro lado, según el bjeto que se revise, se suele diferenciar entre l s revisiones con orientación técnica y la revisiones orientadas a la gestión (también conocidas como revisiones de proyecto). ING. FELIPE OMAR ALIAGA CAVERO

38

CALIDAD DE SOFTWARE

Las revisiones técnicas ás comunes son: - Revisión de la especificación de requisitos - Revisión del di seño - Revisión del c digo - Revisión de la pruebas - Revisión del anual de usuario Los principales objetivos que se buscan con las revisiones de proyecto, or otro lado, son los siguientes: - Control de la progresión del proyecto - Evaluación de los riesgos asociados al proyecto, con relació n al coste, escala de tiempos, recursos utilizados y calidad del producto. - Evaluación general del producto. Para que esto sea posible es necesario: - Que exista un plan de desarrollo bien estructurado, con hitos bien definidos, que permita eval ar la progresión del proyecto. - Que los resultados del proyecto se encuentren bien docum ntados y hayan sido ya examinados en una revisión técnica. A continuación vamos a xaminar en más detalle las revisiones técnicas ás comunes. Revisión de la especif icación de requisitos Este tipo de revisión es uy útil para facilitar el descubrimiento de los errores introducidos en la especificación de requisitos en fases tempranas del desarrollo. El tipo de errores que se pueden encontrar en este objeto son: - Requisitos poc claros, contradictorios, erróneos o imposibles d probar - Requisitos incompletos o especificación incompleta (faltan requisitos). - Requisitos irrel vantes para el problema que se trata de resolve r. Algunas de las pregunt s que podrían encontrarse en una lista de co probaciones para la especificación de requisitos son las siguientes: - ¿Se han especi icado todos los recursos hardware necesarios? - ¿Se han especi icado las interfaces externas necesarias? - ¿Existen contradicciones en la especificación de los requisitos? - ¿Se han definido los criterios de aceptación para cada u a de las funciones especificadas? - ¿Resulta comprensible la especificación realizada? Revisión del diseño Se suele diferenciar ent e la revisión del diseño preliminar o de alto nivel y la revisión del diseño detallado. El objetivo de estas revisiones es determinar y evalua el estado en el que se encuentra el proceso de diseño, así como descubrir errores o contradicciones (entre la especificación de requisitos y el diseño o en las interfaces entre módulos) Algunas de las pregunt s que podrían encontrarse en una lista de co probaciones para el diseño son las siguientes: - ¿Hay uniformidad en el diseño? - ¿Se han definido correctamente las interfaces entre módulos? - ¿Se han definido correctamente las interfaces extemas? - ¿Cubre el diseño todas las funciones incluidas en la especificaci n de requisitos? - ¿Cumple el dis ño todos los requisitos no funcionales? ING. FELIPE OMAR ALIAGA CAVERO

39

CALIDAD DE SOFTWARE

- ¿Resulta ambigua la documentación del diseño? - ¿Se ha aplicad la notación de diseño correctamente? - ¿Es el diseño l suficientemente detallado como para que sea posible impí ementarlo en el lenguaje d programación elegido? Revisión del código Las revisiones del códig suelen tomar la forma de revisión por pares o inspección, y uno de sus objetivos es determi ar que el código se corresponde con el diseño d tallado realizado. Algunos de los aspectos ue se examinan en una revisión de código son los siguientes: - interfaces - estructura del rograma - utilización de v riables - fórmulas - entradas y sali as - comentarios - adherencia a los estándares de codificación Las revisiones de código se basan en la lectura del mismo, lo que exige e los programadores un esfuerzo para hacerlo legible. Los estudios realizados demuestran que, mediante las inspecciones d código, más de la mitad de los errores de rogramación se pueden detectar antes de pasar a la prueba modular y que los programas que han pasado por una inspección d código contienen considerablemente menos errores. Revisiones de las pru bas Se pueden efectuar dos ipos de revisiones de las pruebas: - Revisión del di eño de la prueba - Inspección de la prueba El objetivo de la revisión del diseño de la prueba es comprobar que el di eño realizado para la prueba está de acuerdo con los objetivos que se persiguen. Se deben comprobar aspectos como: - ¿Se han tenid en cuenta todos los objetivos a la hora de diseñar los casos de prueba? - ¿Se han elegid los casos de prueba más adecuados para com robar la consecución de dichos objeti os? Los objetivos de las insp cciones de las pruebas, por su parte, son: - Comprobar q e la prueba se ha ejecutado correctamente, de acuerdo con el procedimiento de prueba especificado. - Análisis de los esultados obtenidos con cada prueba. Controles Estáticos Automáti cos Dentro de esta categorí tenemos el análisis estático automático y la erificación formal de programas. La mayor parte del anál isis estático automático del código lo realizan l s compiladores, que pueden detectar desde expresiones sintácticamente incorrectas hasta incompatibilidades de tipo y otros errores d tipo semántico. Verificación formal ING. FELIPE OMAR ALIAGA CAVERO

40

CALIDAD DE SOFTWARE

Consiste en demostrar especificaciones.

atemáticamente la corrección de un program con respecto a sus

Para ello, se considera ell programa como un objeto formal, es decir, co o una cadena de un lenguaje formal, con u a sintaxis y una semántica formal. Es tambi én necesario que la especificación se haya e crito en algún lenguaje formal. Por eso no siem re es posible realizar este tipo de verificación. Por lo general, esta técni ca sólo se utiliza para sistemas críticos, debido al coste que conlleva. Los métodos de verificación formal de programas más conocidos son los basados en la lógica de Hoare [Hoare, 1969 , los basados en la aproximación de Dijkstra [Dijkstra, 1989] y la aproximación funcional de Milis [Milis, 1987].

CONTROLES DINÁMICOS Introducción Se llama controles diná icos a aquellos que requieren la ejecución del objeto que se está probando o de un model del mismo. Hasta la fecha no se h desarrollado ninguna teoría universalmente a eptada acerca de la prueba de software. Lo único que hay es un conjunto de aproximacion s metodológicas que facilitan y hacen más efi iente el proceso de prueba. Se llama PRUEBA del Software al proceso en el que se ejecuta un siste a con el objetivo de detectar fallos. Se llama DEPURACIÓN a l proceso en el que se localiza el defecto que es la causa de un fallo, se determina la forma de corregirlo, se evalúa el efecto de la correcció y se lleva a cabo la corrección. Por lo general, después del proceso de depuración será necesario repetir el proceso de prueba, para garantizar que el defecto quedó efectivamente orregido y que no se introdujeron nuevos def ctos. El coste de detección de los defectos suele ser mucho mayor que el cost de corrección de los mismos, y este es un pu nto en contra de las pruebas como técnica de ontrol de calidad, ya que siempre es necesari un paso de diagnóstico hasta que se localiza la causa de los fallos. En otras actividades de control de calidad, por el contrario, como pueden ser las revisiones, se localizan directamente los defectos, no sus síntomas, por lo que nos aho rramos el proceso de diagnóstico. En un proyecto grande l prueba se puede llevar hasta el 50 o 60% del esfuerzo dedicado al proyecto. Por eso es muy importante seleccionar bien las pruebas que se van a realizar, teniendo en cuenta que ólo las pruebas que revelan defectos son las que realmente merecen la pena. El objetivo del proceso está libre de defectos, especialmente aquellos complejas, en los valore

e prueba no es, como pudiera parecer, demo trar que el software ino precisamente descubrir defectos. Por ello, e deben seleccionar casos de prueba que incidan en las seccione del programa más límite de las variables, en la tolerancia a fallos del diseño.

Aunque la prueba es un parte importante del Control de Calidad, es imp ortante darse cuenta de que no es la única. A continuación veremos cuáles son las actividades que es necesario re lizar para probar un sistema software, y cuál s son los principales métodos de prueba que se pueden utilizar. ING. FELIPE OMAR ALIAGA CAVERO

41

CALIDAD DE SOFTWARE

Tipos de pruebas El proceso de prueba co nlleva la realización de un conjunto de tareas a lo largo del ciclo de vida del sistema. De acu erdo con el estándar IEEE 1012-1986 el conjunt mínimo de pruebas que se deben realizar so :



La prueba modular consiste en la prueba de cada módulo aislado del resto del sistema.



La prueba de integr ción se realiza a medida que los diferentes m dulos del sistema se

integran en el mis o. Ya se ha realizado la prueba modular, y s e supone que todos módulos son correc os. El objetivo fundamental de esta prueba e comprobar que las interfaces entre los istintos módulos son correctas. Algunas de las comprobaciones que es necesario realizar son: -

Corrección e la sintaxis en la invocación de procedimientos funciones. Compatibilid d de tipos entre los argumentos del procedimi ento o función y los parámetros e llamada. Corrección y completitud de las especificaciones de los m dulos. Se pueden utilizar tres posibles estrategias de integración: De arriba a bajo (top-down): Consiste en empezar la integr ción y la prueba por los módulos que están en los niveles superiores de ab tracción, e integrar ncrementalmente los niveles inferiores. De abajo a a rriba (bottom-up): Consiste en empezar la integración y la prueba por los módulos que están en los niveles inferiores de ab tracción, e integrar incrementalmente los niveles superiores. De big-bang: Consiste en integrar y probar todo al mismo tie po.



La rueba del siste a se realiza cuando se han integrado todos los ódulos, y su objetivo es comprobar que l sistema satisface los requisitos del usuario, anto los funcionales como los no funcion les.



La rueba de acepta ción se realiza una vez que el sistema se ha impl ntado en su entorno real de funcionamiento, y su objetivo es demostrar al usuario que el sistema satisface sus necesidades.


42

CALIDAD DE SOFTWARE

A continuación vamos a er los dos grupos en que se clasifican los métodos de prueba: - Métodos de caja negra - Métodos de caja blanca Métodos de caja negra En este tipo de métodos, el objeto que se desea probar se ve como na caja negra. Esto quiere decir que la elección de los casos de prueba no se va a basar en el conocimiento que se tenga acerca de la es ructura del objeto, sino en el conocimiento acer a de la funcionalidad deseada (descripción funcional). A la prueba de caja negra también se le llama prueba funcional o prueba orie tada al diseño. Una prueba de caja negra ex austiva requeriría la generación de un caso e prueba por cada combinación posible (válid o no válida) de los valores de entrada, lo cual resulta imposible en la mayor parte de los casos por producirse una explosión combinat ria. Por eso se utilizan diferentes criterios a la hora de restringir el conjunto de casos de pr eba. Los métodos de selección del conjunto de casos de prueba más usuales son: Método de clas s de equivalencia Consiste en dividiir las posibles entradas al sistema en clases d equivalencia, de tal forma que todo los miembros de una misma clase de equi alencia prueben las mismas propieda es en el sistema, por lo que sólo va a ser nec sario seleccionar un elemento de cada clase de equivalencia. Análisis de valores frontera o valores límite Consiste en seleccionar como casos de prueba aquellos valores e entrada que caen ING. FELIPE OMAR ALIAGA CAVERO

43

CALIDAD DE SOFTWARE

en la frontera de las clases de equivalencia (justo a un lado, just al otro y justo en la frontera). Grafos causa/e ecto y tablas de decisión Consiste en crear un grafo causa/efecto a partir de las especific ciones, y seleccionar suficientes casos de prueba como para asegurar la cobertura del grafo. Se llama causas a las características de los datos de entrada y efectos a las clases de salidas que puede propo cionar el programa. A partir del grafo causa/efecto se construye una tabla de decisión que refleje las dependencias entre causas y efectos. Lo que se hace entonces es reducir la tabla de decisión y seleccionar sólo un aso de prueba para todas las causas que producen el mismo efecto, o para cada col umna de la tabla de decisión. Adivinación de rrores Consiste en tratar de imaginar cuáles son los errores que se pu den haber cometido con mayor proba ilidad, y generar casos de prueba para comprob r dichos errores. Métodos de caja blanca En este tipo de método , el objeto que se desea probar se ve como u na caja blanca. Esto quiere decir que la elección de los casos de prueba se va a basar en el conocimiento que se tenga acerca de la estructura del objeto (diseño detallado, diagramas d flujo de datos y de control, código fuente). la prueba de caja blanca también se le llama prueba estructural. Los métodos de caja blanc se pueden clasificar, a su vez, en dos grupos: Los basados en métricas de cobertura y l os basados en métricas de complejidad 1. Métodos basados e métricas de cobertura: Todo programa se pued representar mediante un grafo de flujo de control, donde cada nodo es una sentencia o una secuencia de sentencias. Los arcos dirigidos en el grafo representan el flujo de control. Para ca a conjunto de datos de entrada el programa se ejecutará a través de un camino concreto dentro de este grafo. Cuando el programa incluye structuras iterativas, el número de posibles aminos en el grafo puede ser infinito. Una pr ueba de caja blanca exhaustiva requeriría la eneración de un caso de prueba por cada posibl e camino. Como esto no es posible, por lo ge eral, se utilizan métricas que dan una indicació de la calidad de un determinado conjunto d casos de prueba en función del grado de cobertura del grafo que consiguen. Las métricas más utilizadas son: - Cobertura de sentencias - Cobertura de segmentos entre decisiones. - Cobertura de decisiones de ramificación - Cobertura de condiciones - Cobertura de todas las combinaciones de condiciones - Cobertura de caminos 2. Métodos basados e métricas de complejidad: Las métricas de complejidad más utilizadas en la generación de casos e prueba son las de MacCabe: - Complejidad ciclomática (arcos - nodos + 2 * número de co ponentes conexos) - Complejidad esencial (complejidad ciclomática - número de subgrafos propios de entrada y salida única) - Complejidad real (número de caminos ejecutados) Metodología de prueba Cada uno de los difer ntes tipos de prueba implica la realización de un conjunto de actividades estándar, así como la producción de un conjunto de salidas e tándar. ING. FELIPE OMAR ALIAGA CAVERO

44

Calidad de Software - Material de Estudio

Recommend Documents