1 u2 calidad_productoproceso

Fundamentos de la Calidad del Software

Calidad del Producto y Calidad del Proceso

Enfoques de CalidadEl Enfoque hacia el ProductoEl Enfoque hacia el Proceso


Enfoques de Calidad

• La terminología para las características de calidad del software difiere de una taxonomía (o modelo de calidad de software) a otra, cada modelo quizás tenga un número diferente de niveles jerárquicos y un número total diferente de características


Enfoques de Calidad

• Varios autores han enunciado distintos modelos de características de calidad de software o atributos que pueden ser útiles para la negociación, planificación, y tasación de la calidad de productos software (Boehm 78; McCall 77)


Enfoques de Calidad

• ISO/IEC ha definido tres modelos relacionados de calidad de productos software (la calidad interna, la calidad externa, y la calidad en el empleo) (ISO9126-01) y un conjunto de partes relacionadas (ISO14598-98)

• Esto da por consecuencia dos enfoques principales para las características de la calidad del software, el enfoque hacia el producto y el enfoque hacia el proceso


Enfoques de Calidad

• La gestión de la calidad de software y la calidad de proceso en la ingeniería de software guardan relación directa con la calidad del producto software

• Desde luego, no es posible distinguir completamente la calidad del proceso de la calidad del producto


Enfoques de Calidad

• La calidad de proceso, afecta a las características de calidad de los productos software, que a su vez repercuten en la calidad en el uso tal y como es percibido por el cliente


El Enfoque hacia el Producto

• El ingeniero de software, ante todo, necesita determinar el Objetivo verdadero del software

• En cuanto a esto, es de capital importancia tener presente los requerimientos del cliente y aquellos que estos incluyen como requerimientos de calidad, no únicamente los requerimientos funcionales



• Así, el ingeniero de software tiene como responsabilidad obtener los requerimientos de calidad, que pueden no estar explícitos en un principio, tratar su importancia así como el nivel dificultad para alcanzarlos



• Todos los procesos asociados a la Calidad de software (como por ejemplo, construcción, pruebas, mejora de la calidad) serán diseñados con estas exigencias en mente, y ello conlleva gastos adicionales



• La calidad de un producto no se limita a su confiabilidad o corrección, aunque ésta debería estar en consonancia con el precio y el uso de la aplicación de este software



• Atañe a aspectos de similar importancia a la confiabilidad, como la seguridad del producto, de sus partes, cada vez más importante en tanto y cuanto una parte del software actual se realiza mediante la composición de componentes proporcionados bien por el programador, bien por el sistema de desarrollo, bien suministrado por terceros



• Otros aspectos fundamentales de la calidad de un producto de software son la facilidad de utilización por los usuarios esperados, las prestaciones ofrecidas por las aplicaciones, la adaptación a su mantenimiento y producción de nuevas versiones, la flexibilidad y la transportabilidad a sistemas hardware/software diferentes, etc.



• Una de las acepciones más utilizadas de la calidad es la relacionada con modelos de aseguramiento tipo ISO 9000

• El concepto se orienta más a predecir la calidad (sea la que sea) del producto final mediante el control de las tareas para su realización y, sobretodo su registro



• De esta forma, si el producto final no responde a nuestros criterios de calidad (lo esperado, no lo deseable), podemos saber en qué punto del proceso se produjo un error y subsanarlo



• El estándar ISO/IEC 9126-01 define, para dos de sus tres modelos de calidad, características de calidad, Sub-características, y las medidas que son útiles para Evaluación de calidad de producto de software

• El significado del término "producto" es ampliado para incluir cualquier artefacto que es la salida de cualquier proceso empleado para construir el producto de software final



• Como ejemplos de un producto cabe incluir, aunque no con carácter limitativo, una completa especificación del sistema, una especificación de requerimientos de software para un componente de software de un sistema, un módulo de diseño, código, documentación de prueba, o los informes producidos como consecuencia de tareas de análisis de calidad



• Mientras la mayor parte del tratamiento de la calidad es descrito en términos del software final y funcionamiento del sistema, una ingeniería práctica responsable requiere que los productos intermedios relevantes para la calidad sean evaluados a lo largo de todo el proceso de ingeniería de software


El Enfoque hacia el Proceso

• Las metodologías de desarrollo nos ayudan a realizar este proceso (el de desarrollo) reglado y prefijado para conseguir productos adecuados

• No se entiende un concepto como el de Fábrica de Software sin la asociación con el concepto de tareas repetibles, planificables, organizadas, igual que no se entiende una fábrica como un conjunto de tareas anárquicas, sin control ni organización



• Dentro de la Ingeniería de Software existen multitud de metodologías para el desarrollo de productos de software

• Incluso, cada país suele tener su versión de metodología obligatoria (normalmente en lo relativo a los aspectos formales orientados a la documentación) en los productos de administración pública



• La orientación adecuada consiste en partir de una metodología de desarrollo suficientemente contrastada y admitida, personalizada para la propia organización pero sin pérdida de la generalidad de la misma (lo que consiguen muchas personalizaciones es la pérdida de la eficiencia de la metodología)



• Un proceso de desarrollo de software determina quién debe hacer qué, cuándo y cómo

• Un proceso de software define la forma en que se organiza el trabajo de un equipo de desarrollo y otros grupos de apoyo



• Son las actividades que se realizan siguiendo métodos y técnicas para desarrollar un producto de software

• El proceso de desarrollo recibe como entrada requisitos nuevos o modificados y genera un sistema nuevo o modificado



• Los procesos de software difícilmente se inventan desde cero, más bien recogen las mejores prácticas y experiencias de los que han tenido éxito en el desarrollo de software

• Actualmente, disponemos de una serie de modelos generados por consenso entre profesionistas, que podemos tomar como modelos de referencia



• Los ejemplos más destacados de estos modelos el CMM-SW, el CMMI, el ISO/IEC 12207 e ISO/IEC 15504

• La confianza en estos modelos se debe al hecho de que fueron sustraídos de las experiencias de varias empresas y de muchos proyectos exitosos desarrollados anteriormente



• Los modelos de referencia mencionados muestran, que para tener éxito en el proceso de desarrollo de software hay que darle la debida importancia no solamente a los aspectos técnicos, sino también a los aspectos de gestión de un proyecto



• Una organización que quiera medir la calidad, o usando los términos de los modelos, la capacidad y/o madurez de sus procesos, puede comparar su forma de trabajar con respecto a lo que sugieren estos modelos

• Esto se conoce como evaluación de procesos (Process Assessment)



• Esencialmente el proceso está definido por un modelo de proceso junto con la definición de artefactos, actividades y roles

• El modelo de proceso se base en uno o más de los siguientes enfoques: codificar y reparar (code-and-fix), modelo en cascada, desarrollo evolutivo, desarrollo formal (paradigma de programación automática) y desarrollo basado en componentes



• Además, existe consenso respecto a que el proceso de desarrollo debe ser iterativo

• En este sentido normalmente se combinan una estrategia de desarrollo incremental con una de desarrollo en espiral



• Una importante característica de un proceso iterativo es que la especificación del software es desarrollada a lo largo del proceso de desarrollo de software, es decir, no se establece de forma completa e inmutable al principio del desarrollo



• Un artefacto es cualquier información usada o producida por el proceso de desarrollo de software (OMG 2002)

• Ejemplos de artefactos son: documentos, modelos, archivos fuente y ejecutables



• Un rol es la definición del comportamiento y responsabilidades de un individuo o conjunto de individuos trabajando juntos como un equipo, dentro del contexto de la organización de ingeniería de software



• Una actividad es una unidad de trabajo que puede realizar un determinado rol

• Todo lo anterior se define de acuerdo a la terminología utilizada en RUP (Rational Unfied Process) que es la versión de la empresa Rational del proceso unificado



• No existe un proceso de desarrollo de software universal que sea adecuado para cualquier proyecto

• Debido a esto, un proceso de desarrollo debe ser entendido como un marco de trabajo configurable, capaz de ser adoptado y escalda según las características del proyecto



• En la actualidad, quizá dos de los exponentes más representativos de procesos en cuanto a su interés industrial, son RUP y XP (Extreme Programming) (Beck 2000)

• Ambos representan una pugna entre lo que se ha clasificado por algunos autores como procesos peso pesado (heavyweight) y procesos peso ligero (lightweight) o también llamados metodologías ágiles



• La diferencia más clara entre los procesos llamados pesados y los ligeros está en la envergadura de los proyectos para los cuales están orientados y el grado de “ceremonia” o mejor dicho, formalidad que el proceso establece



• XP se orienta fuertemente a la producción de código y sus pruebas, restando protagonismo al modelado y enfatizando aspectos tales como: la satisfacción del cliente, el potenciar la capacidad individual y promover una estrecha colaboración del equipo de desarrollo



• En RUP se hace mayor hincapié en el modelado y hay una precisa definición de cada uno de los roles, actividades y artefactos que deben formar el proceso de desarrollo

• RUP es un marco de trabajo que puede ser adaptado a las necesidades del proyecto, con lo cual puede configurarse para proyectos de distintas envergaduras



• XP debido a sus principios, presenta inconvenientes para ser escalado a grandes proyectos en condiciones en las cuales, por ejemplo, como lo señala Smith (2001) hay más de 10 participantes, el equipo está distribuido geográficamente, el tiempo de desarrollo es de años, etc.



• Se puede resumir todo lo anterior de la forma siguiente:Gente

Tecnología Proceso



• Gente– Con las habilidades, entrenamiento y

motivación

• Tecnología– Herramientas e Infraestructura

• Proceso– Procedimientos y Métodos definiendo las

relaciones de las tareas

Fin de la PresentaciónContinúe en la siguiente

actividad


Enfoques de CalidadEl Enfoque hacia el ProductoEl Enfoque hacia el Proceso

Documents

1 u2 calidad_productoproceso