Unidad 4, Calidad Enfocada Al Desarrollo de Software

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Software - Sexto Semestre - Licenciatura en Informática Informática

Unidad 4: Calidad enfocada al desarrollo de software Objetivo: Conocerá y aplicará los estándares de calidad para el desarrollo de software.

4.1. Qué es la calidad del software. Calidad Hasta los desarrolladores de software exhaustos están de acuerdo en que es importante crear software de alta calidad. Pero, ¿cómo se define la calidad? En el sentido más amplio, calidad del software es el cumplimiento de los requis requisito itoss de funcio funcional nalida idad d y desemp desempeño eño explíc explícitam itament entee estable establecid cidos, os, de los estánda estándares res de desarro desarrollo llo explícitamente documentados y de las características implícitas que se esperan de todo software desarrollado profesionalmente.

Es indudable indudable que esta definición definición podría modificarse modificarse o extenderse extenderse y debatirse debatirse interminabl interminablemente. emente. En cuanto cuanto a los objetivos de este libro, la definición sirve para destacar tres puntos importantes: 1. Los requisitos del software son la base de las medidas de calidad. La falta concordancia con estos requisitos es una falta de calidad. 2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la ingeniería del software. Si no se siguen los criterios, el resultado será, casi seguramente, la falta de calidad. 3. A menudo se soslaya un conjunto de requisitos implícitos (por ejemplo, el deseo de alcanzar la facilidad de uso). Si el software cumple con sus requisitos explícitos pero no con los implícitos, la calidad del software estará en duda. La calidad del software es una compleja combinación de factores que variarán entre diferentes aplicaciones y los distintos clientes que las solicitan. En las siguientes secciones se identifican los factores que afectan la calidad del software y se describe las actividades humanas que deben desarrollarse para alcanzarla. Calidad del software Es el grado con el que un sistema, componente o proceso cumple los requisitos especificados y las necesidades o expectativas del cliente o usuario.

Es la concor concordan dancia cia con los requis requisito itoss funcio funcional nales es y de rendim rendimien iento to explíci explícitam tament entee estable establecid cidos os con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente. La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existen existencia. cia. La calida calidad d es sinóni sinónimo mo de eficien eficiencia, cia, flexib flexibili ilidad dad,, correc correcció ción, n, confia confiabil bilida idad, d, manten mantenibil ibilida idad, d, portabilidad, usabilidad, seguridad e integridad. La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más), necesita ser confiable, mantenible y flexible fle xible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación. La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software. L.S.C.A. Raúl Monforte Monforte Chulín MORCH Systems Systems

1

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Software - Sexto Semestre - Licenciatura en Informática

Se puede decir que la calidad de software es el conjunto de características de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implícitas. Los requisitos del software son la base de las medidas de calidad. Y la falta de concordancia con los requisitos es una falta de calidad. Todos los estándares o metodologías definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se sigue ninguna metodología siempre habrá falta de Calidad. También existen algunos requisitos implícitos o expectativas que a menudo no se mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que también pueden implicar una falta de calidad. Calidad en la ingeniería del software: En una versión sucinta la calidad en la ingeniería del software es un grupo de características que representa la efectividad y la eficiencia de un sistema de información. Es importante enfatizar en dos puntos: Un software de calidad debe ser eficaz, es decir, que debe realizar las funciones establecidas, debe ser amigable. Un usuario debe utilizar el software porque produce resultados confiables, realiza todas las operaciones que se requieren, ejecuta las operaciones en un tiempo aceptado y es fácilmente usado por el grupo de usuarios a quien este dirigido. •

Un software de calidad debe ser eficiente, es decir el costo de su desarrollo tomando todos los recursos y el costo de su operación debe ser tal que las organizaciones involucradas en su desarrollo y uso obtengan el máximo beneficio o por lo menos un beneficio aceptable en un período de tiempo establecido. Para ilustrar el concepto de calidad de manera más profunda, es necesario considerar algunos aspectos fundamentales que caracterizan al software de calidad como son: solidez, exactitud, completitud, mantenibilidad, reutilizabilidad, claridad en la documentación, entre otros que serán descritos a continuación. •

Los factores de calidad de McCall Los factores que afectan la calidad del software se dividen en dos grandes grupos: 1) los que se miden directamente (por ejemplo, defectos descubiertos durante la prueba), y 2) los que sólo se miden indirectamente (por ejemplo, facilidad de uso o mantenimiento). En cada caso debe presentarse una medición. Se debe comparar el software (programa, datos, documentos) con algún conjunto de datos y obtener así algún indicio sobre la calidad. Figura: Factores de la calidad del software de McCall.

McCall, Richards y Walters [MCC77] propusieron una clasificación útil de los factores que afectan la calidad del software. Estos factores, que se muestran en la siguiente figura, se concentran en tres aspectos importantes de un producto de software: sus características operativas, su capacidad para experimentar cambios y su capacidad para adaptarse a nuevos entornos. Si se toman como referencia los factores indicados en la siguiente figura McCall y sus colegas proporcionan las siguientes descripciones:

L.S.C.A. Raúl Monforte Chulín MORCH Systems

2

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Software - Sexto Semestre - Licenciatura en Informática Operación del producto: Corrección: El grado en que el programa cumple con su especificación y satisface los objetivos que propuso el cliente. Este factor tiene una pregunta asociada: ¿Hace lo que quiero? Confiabilidad: El grado en que se esperaría que un programa desempeñe su función con la precisión requerida. La pregunta asociada a este factor sería: ¿Lo hace de forma fiable todo el tiempo? Eficiencia: La cantidad de código y de recursos de cómputo necesarios para que un programa realice su función. La pregunta asociada a este factor sería: ¿Se ejecutará en mi hardware lo mejor que pueda? Integridad: El grado de control sobre el acceso al software o los datos por parte de las personas no autorizadas. La pregunta asociada a este factor sería: ¿Es seguro el sistema? Facilidad de uso: El esfuerzo necesario para aprender, operar y preparar los datos de entrada de un programa e interpretar la salida. La pregunta asociada a este factor sería: ¿Está diseñado para ser usado? Revisión del producto: Facilidad de mantenimiento: El esfuerzo necesario para localizar y corregir un error en un programa. La pregunta asociada a este factor sería: ¿Puedo corregirlo? Flexibilidad: El esfuerzo necesario para modificar un programa en operación. La pregunta asociada a este factor sería: ¿Puedo cambiarlo? Facilidad de prueba: El esfuerzo que demanda probar un programa con el fin de asegurar que realiza su función. La pregunta asociada a este factor sería: ¿Puedo probarlo?. Transición del producto: Portabilidad: El esfuerzo necesario para transferir el programa de un entorno de hardware o software a otro. Este factor tiene una pregunta asociada: ¿Podré usarlo en otra máquina? Facilidad de reutilización: El grado en que un programa (o partes de él) puede reutilizarse en otras aplicaciones (en relación con el empaquetamiento y el alcance de las funciones que realiza el programa). Este factor tiene una pregunta asociada: ¿Podré reusar alguna parte del software? Interoperabilidad: El esfuerzo necesario para acoplar un sistema con otro. Este factor tiene una pregunta asociada: ¿Podré hacerlo interactuar con otro sistema?

“La calidad de un producto es una función del bien que hace al mundo.” Tom DeMarco Es importante indicar que la calidad se extiende a las características técnicas de los modelos de análisis y diseño, así como a la realización del código fuente de éstos. Modelos de alta calidad (en el sentido técnico) darán lugar a software de alta calidad, desde el punto de vista del cliente. Es difícil, y en algunos casos imposibles, desarrollar medidas directas de estos factores de la calidad. En realidad, muchas de las métricas que definen McCall sólo se miden subjetivamente. Es común que las métricas adquieran la forma de una lista de comprobación que se emplea para “asignar una graduación” a atributos específicos del software. L.S.C.A. Raúl Monforte Chulín MORCH Systems

3

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Software - Sexto Semestre - Licenciatura en Informática Factores de calidad del estándar ISO 9126 El estándar ISO 9126 se desarrolló como un intento por identificar los atributos de calidad para el software de computadora.

El estándar identifica seis atributos clave de la calidad: Funcionalidad: El grado en que el software satisface las necesidades que indican los siguientes subatributos: idoneidad, exactitud, interoperabilidad, cumplimiento y seguridad. Confiabilidad: La cantidad de tiempo en que el software está disponible para usarlo según los siguientes subatributos: madurez, tolerancia a fallas y facilidad de recuperación. Facilidad de uso: La facilidad con que se usa el software de acuerdo con los siguientes subatributos: facilidad de comprensión, facilidad de aprendizaje y operabilidad. Eficiencia: El grado en que el software emplea en forma óptima los recursos del sistema, como lo indican los siguientes subatributos: comportamiento en el tiempo, comportamiento de los recursos. Facilidad de mantenimiento: La facilidad con que se repara el software de acuerdo con los siguientes subatributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba. Portabilidad: La facilidad con que se lleva el soi’tware de un entorno a otro según los siguientes subatributos: adaptabilidad, facilidad para instalarse, cumplimiento, facilidad para reemplazarse. Al igual que otros factores de calidad del software los factores ISO 9126 no necesariamente se prestan a la medición directa. Sin embargo, proporcionan una base valiosa para las medidas indirectas y una lista de verificación excelente para evaluar la calidad de un sistema. Es importante indicar que la calidad se extiende a las características técnicas de los modelos de análisis y diseño, así como a la realización del código fuente de éstos. Modelos de alta calidad (en el sentido técnico) darán lugar a software de alta calidad, desde el punto de vista del cliente.

4.2 Cómo obtener calidad de software (métodos, metodologías, estándares). Uno de los problemas que se afrontan actualmente en la esfera de la computación es la calidad del software. Desde la década del 70, este tema ha sido motivo de preocupación para especialistas, ingenieros, investigadores y comercializadores de softwares, los cuales han realizado gran cantidad de investigaciones al respecto con dos objetivos fundamentales: ¿Cómo obtener un software con calidad? ¿Cómo evaluar la calidad del software? Ambas interrogantes conllevan amplias respuestas, pero están estrechamente ligadas con el concepto de la calidad del software, que es el resultado de la primera y la fuente de la segunda. La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico. El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software. L.S.C.A. Raúl Monforte Chulín MORCH Systems

4


El principio administrativo contempla las funciones de planificació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. La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación. Todas las metodologías y herramientas tienen un único fin “ producir software de gran calidad” Cómo asegurar la calidad del software? Establecimiento de un sistema de calidad o Gestión de la calidad o Planificación de la calidad o Definición de políticas de calidad Uso de técnicas de verificación y validación del software o Revisiones e inspección de los productos de software o Pruebas de programas Gestión de la Configuración del Software Uso de normas y estándares de calidad Evaluación y mejoramiento de los procesos de software •

•

• • •

4.3. Cómo controlar la calidad del software. Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, "usted no puede controlar lo que no se puede medir". Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categorías de métricas: de complejidad de programa o código, y de complejidad de sistema o estructura. Todos los autores coinciden en que el software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad. Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos: Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, • etc., de acuerdo con los estándares establecidos para el desarrollo del software. Seleccionar una medida que pueda ser aplicada al objeto de control: Para cada clase de software es • necesario definir los indicadores y sus magnitudes. Crear o determinar los métodos de valoración de los indicadores: métodos manuales como • cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo. Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la • calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc. L.S.C.A. Raúl Monforte Chulín MORCH Systems

5


A partir del análisis de todo lo anterior, nuestro centro se encuentra enfrascado en un proyecto para el Aseguramiento de la Calidad del Software (ACS), válido para cualquier entidad que se dedique a la investigación, producción y comercialización del software, el cual incluye la elaboración de un Sistema de Indicadores de la Calidad del Software, la confección de una Metodología para el Aseguramiento de la Calidad del Software y el desarrollo de herramientas manuales y automatizadas de apoyo para la aplicación de las técnicas y procedimientos del ACS, de forma tal que se conforme un Sistema de Aseguramiento de la Calidad del Software.

4.4 Costo de la calidad del software. El costo de la calidad incluye todos los costos que genera la búsqueda de la calidad o que demanda el desarrollo de las actividades relacionadas con la calidad. Los estudios de costo de la calidad se llevan a cabo para ofrecer una línea base para el costo de calidad y proporcionar una base normalizada de comparación. La base de la normalización casi siempre es monetaria. Una vez que se han normalizado los costos de la calidad sobre una base monetaria, se tienen los datos necesarios para evaluar dónde se encuentran las oportunidades para mejorar los procesos. Más todavía, se puede evaluar el efecto de los cambios en términos monetarios. Los costos de calidad se dividen en costos asociados con prevención, evaluación y fallas. Los costos de prevención incluyen planificación de la calidad, revisiones técnicas formales, equipos de prueba y entrenamiento. Los costos de evaluación incluyen actividades para comprender mejor la condición del producto la “primera vez a través de” cada proceso. Los ejemplos de costos de evaluación incluyen inspección en el proceso y entre procesos, calibración y mantenimiento de equipo y pruebas Los costos de fallas son aquellos que desaparecerían si no aparecieran defectos antes de enviar un producto a los clientes estos costos se subdividen en costos de fallas internas y externas. Se incurren en los costos de fallas internas cuando se detecta un defecto en el producto, antes del envío. Los costos de fallas internas incluyen reelaboración, reparación y análisis en modo de falla. Los costos de fallas externas se asocian con defectos que se detectan después de que el producto ha sido enviado al cliente. Los ejemplos de costos de fallas externas son la resolución de las quejas, devolución y reemplazo del producto, soporte de ayuda en línea y trabajo de garantía. Como se esperaba, los costos relativos para encontrar y repara un defecto aumentan sustancialmente conforme se pasa de la prevención a detención y de los de falla interna a falla externa.

4.5. Nomenclatura y certificación ISO 9001:2000. La familia de normas ISO 9000 (versión 1994) contiene más de 20 documentos. La revisión del año 2000 comprende cuatro normas principales apoyadas por varios reportes técnicos. La ISO 9001 es la única norma de requisitos de la serie; las normas ISO 9002 e ISO 9003 han sido retir adas. De acuerdo con el propósito de la norma ISO 9001, será permitido omitir requisitos que no apliquen a una determinada organización. Como ejemplo de adaptación, se incluye la omisión de diseño y desarrollo cuando estas actividades no se realizan en la organización. Las normas ISO 9001 e ISO 9004 son un "par consistente" de normas. La ISO 9001 contiene los requisitos y la ISO 9004 proporciona una guía para la mejora del desempeño del sistema de la calidad. La norma ISO 9004 revisada no es una guía para implementar la norma ISO 9001. La serie ISO 9000-2000 comprende cuatro normas principales: L.S.C.A. Raúl Monforte Chulín MORCH Systems

6


ISO 9000 - Sistemas de Gestión de la Calidad – Fundamentos y Vocabulario (reemplaza a la norma ISO 8402). ISO 9001 - Sistemas de Gestión de Calidad -- Requisitos. "Proporcionar confianza como resultado de demostración de la conformidad de los productos / servicios con los requisitos establecidos." ISO 9004 - Sistemas de Gestión de Calidad – Directrices para la mejora continua del desempeño. "Para que todos los interesados consigan beneficios a través de la satisfacción sostenida del cliente." ISO 10011 - Directrices para la auditoria de los sistemas de la calidad. Cambios en la norma ISO 9001 La revisión del año 2000 de la norma ISO 9001 introduce nuevos requisitos con enfoque en la mejora continua y en las necesidades del cliente. También modifica requisitos existentes y se desvía de la estructura actual de 20 elementos. Los requisitos de la norma ISO 9001 han sido reorganizados en cinco tópicos principales como está indicado a continuación: Sistema de gestión de la calidad . Requisitos generales del Sistema de gestión de calidad y requisitos de la documentación Responsabilidades de la dirección. Compromiso, enfoque al cliente, política, planificación, y comunicación Gestión de los recursos. Recursos humanos, infraestructura y ambiente de trabajo. Realización del producto. Planificación, procesos relacionados con el cliente, diseño, compras. Producción y prestación del servicio y control de los dispositivos de seguimiento y de medición. Medición, análisis y mejora. Seguimiento y medición, control del producto no conforme, análisis de datos y mejora

4.6 La norma ISO/IEC 9126. Este estándar está pensado para los desarrolladores, adquirentes, personal de aseguramiento de calidad y evaluadores independientes, responsables de especificar y evaluar la calidad del producto software. Por tanto, puede servir para validar la completitud de una definición de requisitos, identificar requisitos de calidad de software, objetivos de diseño y prueba, criterios de aseguramiento de la calidad, etc. La calidad de cualquier proceso del ciclo de vida del software (estándar ISO 12.207) influye en la calidad del producto software que, a su vez, contribuye a mejorar la calidad en el uso del producto. La calidad del software puede evaluarse midiendo los atributos internos (medidas estáticas o productos intermedios) o atributos externos (comportamiento del código cuando se ejecuta).


7


Este estándar se desarrollo como un intento por identificar los atributos de calidad para el software de computadora. El estándar identifica seis atributos clave de la vida. 1. La funcionalidad se subdivide en cinco subcaracterísticas: Adecuación: La capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas específicas y objetivos de los usuarios. Exactitud: La capacidad del producto software para proporcionar los resultados o efectos correctos y con el grado de precisión acordado. Interoperabilidad: La capacidad del producto software para interactuar con uno o más sistemas especificados. Seguridad: Referido a la capacidad del producto software para proteger la información y los datos. Conformidad: la capacidad del producto software para adaptarse a los estándares, convenciones o regulaciones en leyes y prescripciones relativos a la funcionalidad. 2. La fiabilidad se subdivide en cuatro subcaracterísticas: Madurez: La capacidad del producto software para evitar fallos provocados por errores en el software. Tolerancia a fallos: La capacidad del producto software para mantener un nivel de rendimiento determinado en caso de defectos en el software o incumplimiento de su interfaz. Recuperabilidad: La capacidad del producto software para restablecer un determinado nivel de rendimiento y recuperar los datos afectados directamente en caso de ocurrir un fallo. Conformidad: La capacidad del producto software para adaptarse a estándares, convenciones y regulaciones referidas a la fiabilidad. 3. La usabilidad se subdivide en cinco subcaracterísticas: Comprensibilidad: La capacidad del producto software para permitir al usuario que entienda si el software es adecuado, y como debe utilizarse para determinadas tareas y bajo ciertas condiciones de uso. Facilidad de aprendizaje: La capacidad del producto software para permitir al usuario aprender su aplicación. Operabilidad: La capacidad del producto software para permitir que el usuario lo opere y lo controle. Atracción: La capacidad del producto software para atraer al usuario. Conformidad: La capacidad del producto software para adaptarse a estándares, convenciones, guías de estilo y regulaciones relacionadas con la usabilidad. 4. La eficiencia se subdivide en tres subcaracterísticas: Comportamiento temporal: La capacidad del producto software para proporcionar tiempos de respuesta y de procesamiento apropiados cuando realiza sus funciones bajo condiciones determinadas. Utilización de recursos: La capacidad del producto software para utilizar cantidades y tipos de recursos apropiados cuando el software realiza su función bajo determinadas condiciones. L.S.C.A. Raúl Monforte Chulín MORCH Systems

8

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Software - Sexto Semestre - Licenciatura en Informática Conformidad: La capacidad del producto software para adaptarse a estándares o convenciones relacionadas con la eficiencia. 5. La mantenibilidad se subdivide en cinco subcaracterísticas: Analizabilidad: Capacidad del producto software de diagnosticar sus deficiencias o causas de fallos, o de identificar las partes que deben ser modificadas. Cambiabilidad: Capacidad del producto software de permitir implementar una modificación especificada. La implementación incluye los cambios en el diseño, el código y la documentación. Estabilidad: Capacidad del producto software de evitar los efectos inesperados de las modificaciones. Facilidad de prueba: Capacidad del producto software de permitir validar las partes modificadas. Conformidad: Capacidad del producto software de cumplir los estándares o convenciones relativas a la mantenibilidad. 6. La portabilidad se subdivide en cinco subcaracterísticas: Adaptabilidad: La capacidad del producto software para ser adaptado para ambientes determinados sin realizar acciones o aplicar medios, más que los proporcionados para este propósito para el software considerado. Facilidad de instalación: La capacidad del producto software para ser instalado en un ambiente determinado. Coexistencia: La capacidad del producto software para coexistir con otro software independiente en un ambiente común compartiendo recursos. Reemplazabilidad: La capacidad del producto software para ser utilizado en lugar de otro producto de software para el mismo propósito en el mismo ambiente. Conformidad: La capacidad del producto software para adaptarse a estándares relacionados con la portabilidad.

4.7 Análisis de factores que determinan la calidad del software. Factores que determinan la calidad del software y se clasifican en tres grupos: Operaciones del producto: características operativas * Corrección (¿Hace lo que se le pide?): El grado en que una aplicación satisface sus especificaciones y consigue los objetivos encomendados por el cliente. * Fiabilidad (¿Lo hace de forma fiable todo el tiempo?): El grado que se puede esperar de una aplicación lleve a cabo las operaciones especificadas y con la precisión requerida. * Eficiencia (¿Qué recursos hardware y software necesito?): La cantidad de recursos hardware y software que necesita una aplicación para realizar las operaciones con los tiempos de respuesta adecuados. * Integridad (¿Puedo controlar su uso?): El grado con que puede controlarse el acceso al software o a los datos a personal no autorizado. * Facilidad de uso (¿Es fácil y cómodo de manejar?): El esfuerzo requerido para aprender el manejo de una aplicación, trabajar con ella, introducir datos y conseguir resultados. •


9

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Software - Sexto Semestre - Licenciatura en Informática Revisión del producto: capacidad para soportar cambios * Facilidad de mantenimiento (¿Puedo localizar los fallos?) El esfuerzo requerido para localizar y reparar errores. * Flexibilidad (¿Puedo añadir nuevas opciones?) El esfuerzo requerido para modificar una aplicación en funcionamiento. * Facilidad de prueba (¿Puedo probar todas las opciones?) El esfuerzo requerido para probar una aplicación de forma que cumpla con lo especificado en los requisitos. •

Transición del producto: adaptabilidad a nuevos entornos * Portabilidad (¿Podré usarlo en otra máquina?) El esfuerzo requerido para transferir la aplicación a otro hardware o sistema operativo. * Rehusabilidad (¿Podré utilizar alguna parte del s oftware en otra aplicación?) Grado en que partes de una aplicación pueden utilizarse en otras aplicaciones * Interoperabilidad (¿Podrá comunicarse con otras aplicaciones o sistemas informáticos? El esfuerzo necesario para comunicar la aplicación con otras aplicaciones o sistemas informáticos. •

4.8 Análisis del proceso del ciclo de vida del software. Todo proyecto de ingeniería tiene unos fines ligados a la obtención de un producto, proceso o servicio que es necesario generar a través de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestión del proyecto. Al conjunto de las fases empleadas se le denomina “ciclo de vida”. Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologías empleadas. La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamaño, con lo que rápidamente se haría inabordable si no fuera por la vieja táctica de “divide y vencerás”. De esta forma la división de los proyectos en fases sucesivas es un primer paso para la reducción de su complejidad, tratándose de escoger las partes de manera que sus relaciones entre sí sean lo más simples posibles. La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos). Elementos del ciclo de vida Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).


10


Para un adecuado control de la progresión de las fases de un proyecto se hace necesario especificar con suficiente precisión los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases.

Figura: Elementos del ciclo de vida A continuación presentamos los distintos elementos que integran un ciclo de vida: Fases: Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales).

Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases. Otro motivo para descomponer una fase en subfases menores puede ser el interés de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestión. Figura: Esquema general de operación de una fase

Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de


11


salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase. Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. Cada una de estas evaluaciones puede servir, además, para la toma de decisiones a lo largo del desarrollo del proyecto. Tipos de modelo de ciclo de vida Las principales diferencias entre distintos modelos de ciclo de vida están en: El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.

Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo). La estructura de la sucesión de las fases que puede ser lineal, con prototipado, o en espiral. Veámoslo con más detalle: Ciclo de vida lineal: Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase).

Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no necesite resultados de las siguientes (realimentación), aunque pueden admitirse ciertos supuestos de realimentación correctiva. Desde el punto de vista de la gestión (para decisiones de planificación), requiere también que se sepa bien de antemano lo que va a ocurrir en cada fase antes de empezarla. Ciclo de vida con prototipado: A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prevé la utilización de tecnologías nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologías, impiden iniciar un proyecto lineal con especificaciones cerradas.

Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). Este tipo de procedimiento es muy utilizado en desarrollo avanzado. La experiencia del desarrollo del prototipo y su evaluación deben permitir la definición de las especificaciones más completas y seguras para el producto definitivo.


12


A diferencia del modelo lineal, puede decirse que el ciclo de vida con prototipado repite las fases de definición, diseño y construcción dos veces: para el prototipo y para el producto real.

Figura: Ciclo de vida prototipado Ciclo de vida en espiral El ciclo de vida en espiral puede considerarse como una generalización del anterior para los casos en que no basta con una sola evaluación de un prototipo para asegurar la desaparición de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede así considerarse como una sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente.

A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en términos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluación de los resultados por el cliente no puede esperar a la entrega final y puede ser necesaria repetidas veces.

Figura: Ciclo de vida en espiral

El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificación, diseño, realización y evaluación (o conceptos y términos análogos). En cada vuelta el producto gana en “madurez ” (aproximación al final deseado) hasta que en una vuelta la evaluación lo apruebe y el bucle pueda abandonarse. L.S.C.A. Raúl Monforte Chulín MORCH Systems

13


Objetivos de cada fase Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan. Tabla: Objetivos de cada fase.

Fase de definición (¿qué hacer?) Estudio de viabilidad. Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto). Asegurar que los requisitos son alcanzables. Formalizar el acuerdo con los usuarios. Realizar una planificación detallada. Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad) Identificar soluciones tecnológicas para cada una de las funciones del sistema. Asignar recursos materiales para cada una de las funciones. Establecer métodos de validación del diseño. Ajustar las especificaciones del producto. Fase de construcción Generar el producto o servicio pretendido con el proyecto. Integrar los elementos subcontratados o adquiridos externamente. Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias. Fase de mantenimiento y operación Operación: asegurar que el uso del proyecto es el pretendido. Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste):

4.9 Funciones de evaluación del software. Las primeras propuestas de función de evaluación estaban orientadas a tener una evaluación estática de la posición basada fundamentalmente en el concepto de material. Rápidamente se captó que esta evaluación no era suficiente, considerando que en el software existen factores estructurales los cuales afectarán a largo plazo el curso de este, por lo cual es muy probable que el programa no encuentre las consecuencias de esta situación en su búsqueda en profundidad. Estos aspectos, denominados "Posiciónales" debieron incluirse en la función de evaluación. La construcción de un sistema software tiene como objetivo satisfacer una necesidad planteada por un cliente. Pero ¿cómo puede saber un desarrollador si el producto construido se corresponde exactamente con lo que el cliente les pidió? y ¿cómo puede un desarrollador estar seguro de que el producto que ha construido va a funcionar correctamente? Una de las posibles soluciones a este problema podría ser que el cliente evaluase el sistema que se ha construido una vez terminado. Sin embargo, esto tiene varias implicaciones: 1. Por una parte, puede que el cliente descubra que el producto desarrollado no cumple con sus expectativas, esto es, que el producto no hace lo que él esperaría que hiciera. Sin embargo, el producto ha sido terminado, por lo que ¿habría que comenzar de nuevo el desarrollo?


14


2. Por otra parte, la comprobación que el cliente podría realizar no sirve para comprobar que no hay errores en el software, puesto que ello depende de la porción del programa que se esté ejecutando en el momento de esta comprobación, pudiendo existir errores en otras partes del programa que no se ejecuten en ese momento. Por lo tanto, lo recomendable es que el producto software vaya siendo evaluado a medida que se va construyendo. Por lo tanto, como veremos posteriormente, se hace necesario llevar a cabo, en paralelo al proceso de desarrollo, un proceso de evaluación o comprobación de los distintos productos o modelos que se van generando, en el que participarán desarrolladores y clientes. Con el fin de entregar a los clientes productos satisfactorios, el software debe alcanzar ciertos niveles de calidad. Para alcanzar buenos niveles de calidad el número de defectos necesita mantenerse bajo mínimos. Independientemente de la descomposición de calidad que se elija, el nivel de propensión de faltas de un sistema software afecta siempre a varios de los atributos de calidad. En particular, fiabilidad y funcionalidad son siempre los más afectados. No obstante, no existe una relación bien establecida entre las faltas y la fiabilidad y funcionalidad. O dicho de otro modo, entre las faltas y los fallos. Todas las faltas de un producto software no se manifiestan como fallos. Las faltas se convierten en fallos cuando el usuario de un sistema software nota un comportamiento erróneo. Para que un sistema software alcance un nivel alto de calidad se requiere que el número de fallos sea bajo. Pero para mantener los fallos a niveles mínimos las faltas necesariamente deben también estar en niveles mínimos.

Eso es todo amigos!! ..........................y recuerden……

Lema: “La vida es bella”, única e irrepetible vívela hoy, como si fuera el último día de tu vida. MORCH Systems

Le doy gracias a Dios por hacer el cielo con todas sus estrellas, porque una estrella eres tú y el cielo es tu amistad…..Gracias a Dios eres mi amigo con todo y tu amistad. MORCH Systems. Dios te Bendiga hoy, mañana y siempre; a ti, a toda tu familia y a todos tu amigos. L.S.C.A. Raúl Monforte Chulín MORCH Systems

15

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Software - Sexto Semestre - Licenciatura en Informática MORCH Systems.


16

Unidad 4, Calidad Enfocada Al Desarrollo de Software

Recommend Documents