Sunteți pe pagina 1din 6

Calidad del Producto y Calidad del Proceso Enfoques de Calidad El Enfoque hacia el Producto El Enfoque hacia el Proceso

Enfoques de Calidad

La terminologa para las caractersticas de calidad del software difiere de una taxonoma (o modelo de calidad de software) a otra, cada modelo quizs tenga un nmero diferente de niveles jerrquicos y un nmero total diferente de caractersticas Varios autores han enunciado distintos modelos de caractersticas de calidad de software o atributos que pueden ser tiles para la negociacin, planificacin, y tasacin de la calidad de productos software (Boehm 78; McCall 77) 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 caractersticas de la calidad del software, el enfoque hacia el producto y el enfoque hacia el proceso La gestin de la calidad de software y la calidad de proceso en la ingeniera de software guardan relacin directa con la calidad del producto software Desde luego, no es posible distinguir completamente la calidad del proceso de la calidad del producto La calidad de proceso, afecta a las caractersticas 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 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 explcitos 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, construccin, pruebas, mejora de la calidad) sern diseados con estas exigencias en mente, y ello conlleva gastos adicionales La calidad de un producto no se limita a su confiabilidad o correccin, aunque sta debera estar en consonancia con el precio y el uso de la aplicacin de este software Atae a aspectos de similar importancia a la confiabilidad, como la seguridad del producto, de sus partes, cada vez ms importante en tanto y cuanto una parte del software actual se realiza mediante la composicin 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 utilizacin por los usuarios esperados, las prestaciones ofrecidas por las aplicaciones, la adaptacin a su mantenimiento y produccin de nuevas versiones la , flexibilidad y la transportabilidad a sistemas hardware/software diferentes, etc. Una de las acepciones ms utilizadas de la calidad es la relacionada con modelos de aseguramiento tipo ISO 9000 El concepto se orienta ms a predecir la calidad (sea la que sea) del producto final mediante el control de las tareas para su realizacin 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 estndar ISO/IEC 9126-01 define, para dos de sus tres modelos de calidad, caractersticas de calidad, Sub-caractersticas, y las medidas que son tiles para Evaluacin de calidad de producto de software El significado del trmino "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 carcter limitativo, una completa especificacin del sistema, una especificacin de requerimientos de software para un componente de software de un sistema, un mdulo de diseo, cdigo, documentacin de prueba, o los informes producidos como consecuencia de tareas de anlisis de calidad Mientras la mayor parte del tratamiento de la calidad es descrito en trminos del software final y funcionamiento del sistema, una ingeniera prctica responsable requiere que los productos intermedios relevantes para la calidad sean evaluados a lo largo de todo el proceso de ingeniera de software

ENFOQUE HACIA EL PROCESOS

Las metodologas 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 Fbrica de Software sin la asociacin con el concepto de tareas repetibles, planificables, organizadas, igual que no se entiende una fbrica como un conjunto de tareas anrquicas, sin control ni organizacin Dentro de la Ingeniera de Software existen multitud de metodologas para el desarrollo de productos de software Incluso, cada pas suele tener su versin de metodologa obligatoria (normalmente en lo relativo a los aspectos formales orientados a la documentacin) en los productos de administracin pblica La orientacin adecuada consiste en partir de una metodologa de desarrollo suficientemente contrastada y admitida, personalizada para la propia organizacin pero sin prdida de la generalidad de la misma (lo que consiguen muchas personalizaciones es la prdida de la eficiencia de la metodologa) Un proceso de desarrollo de software determina quin debe hacer qu, cundo y cmo 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 mtodos y tcnicas 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 difcilmente se inventan desde cero, ms bien recogen las mejores prcticas 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 ms 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 sustrados 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 tcnicos, sino tambin a los aspectos de gestin de un proyecto

Una organizacin que quiera medir la calidad, o usando los trminos 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 evaluacin de procesos (Process Assessment) Esencialmente el proceso est definido por un modelo de proceso junto con la definicin de artefactos, actividades y roles El modelo de proceso se base en uno o ms de los siguientes enfoques: codificar y reparar (code-and-fix), modelo en cascada, desarrollo evolutivo, desarrollo formal (paradigma de programacin automtica) y desarrollo basado en componentes Adems, 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 caracterstica de un proceso iterativo es que la especificacin 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 informacin 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 definicin del comportamiento y responsabilidades de un individuo o conjunto de individuos trabajando juntos como un equipo, dentro del contexto de la organizacin de ingeniera de software Una actividad es una unidad de trabajo que puede realizar un determinado rol Todo lo anterior se define de acuerdo a la terminologa utilizada en RUP (Rational Unfied Process) que es la versin 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 segn las caractersticas del proyecto En la actualidad, quiz dos de los exponentes ms representativos de procesos en cuanto a su inters industrial, son RUP y XP (Extreme Programming) (Beck 2000) Ambos representan una pugna entre lo que se ha clasificado por algunos autores com o procesos peso pesado (heavyweight) y procesos peso ligero (lightweight) o tambin llamados metodologas giles

XP se orienta fuertemente a la produccin de cdigo y sus pruebas, restando protagonismo al modelado y enfatizando aspectos tales como: la satisfaccin del cliente, el potenciar la capacidad individual y promover una estrec a colaboracin del equipo de desarrollo En R P se hace mayor hincapi en el modelado y hay una precisa definicin de cada uno de los roles, actividades y artefactos que deben formar el proceso de desarrollo R P 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 ms de 10 participantes, el equipo est distribuido geogrficamente, el tiempo de desarrollo es de aos, etc XP debido a sus principios, presenta inconvenientes para ser escalado a grandes proyectos en condiciones en las cuales, por ejemplo, como lo seala Smith (2001) hay ms de 10 participantes, el equipo est distribuido geogrficamente, el tiempo de desarrollo es de aos, etc Se puede resumir todo lo anterior de la forma siguiente:


Gente

Con las habilidades, entrenamiento y motivacin

La dife e cia ms c ara e re los procesos llamados pesados y los ligeros es e la e vergadura de los proyec os para los cuales es n orientados y el grado de ceremonia o mejor dic o, formalidad que el proceso establece

Tecnologa

Herramientas e Infraestructura

Proceso

Procedimientos y Mtodos definiendo las relaciones de las tareas

S-ar putea să vă placă și