Está en la página 1de 9

METODOLOGAS DE CALIDAD DE SOFTWARE

Alberto Carrillo Martnez

5 DE MARZO DE 2013
UNIVERSIDAD TECNOLGICA DE CHIHUAHUA ITI81V

Contenido

INTRODUCCION .......... - 2 DESARROLLO.............. - 3 PSP: ............................... - 3 TSP: ............................... - 4 CMMI: ............................ - 5 SPICE: ........................... - 7 CONCLUSION: ............. - 8 -

INTRODUCCION
La calidad del software es una preocupacin a la que se dedica muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.

La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y prueba del software que permitan uniformar la filosofa de trabajo, en aras de lograr una mayor confiabilidad, capacidad de mantenimiento 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.

Los estndares o metodologas definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. Si no se sigue ninguna metodologa siempre habr falta de calidad.

El objetivo principal de este documento es describir la experiencia a aplicar pruebas de verificacin y validacin del software. El propsito es extender la cultura de aseguramiento de calidad del software, facilitando y estimulando el uso de metodologas de alcance mundial en los futuros profesionales. Especficamente se describe el procedimiento en la ejecucin de estas pruebas, los formularios utilizados, las herramientas de software y los participantes del proceso.

En este documento se describirn solo algunas de las metodologas utilizadas para el desarrollo de software con calidad, los cuales son PSP. TSP, CMMI y SPICE

-2-

DESARROLLO
Primero comenzare con lo que es PSP y seguir con las siguientes metodologas

PSP:
Es un conjunto de prcticas disciplinadas para la gestin del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Est alineado y diseado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. Se puede considerar como la gua de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medicin cualitativa y mejora de procesos. Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesin por la toma de datos y elaboracin de tablas. El PSP se orienta el conjunto de reas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.

Esta metodologa se compone de niveles los cuales son:

Nivel 1 - Inicial: (PSP 0) Proceso actual: registro de tiempos y defectos Seguimiento y control de proyectos. Planeacin de los proyectos. Nivel 2 - Repetible: (PSP 1) estimacin de tiempos Revisin entre colegas. Ingeniera del producto de software. Manejo integrado del software.

-3-

Definicin del proceso de software. Foco del proceso de software. Nivel 3 - Definido: (PSP 2) plantillas Control de calidad. Administracin cuantitativa del proyecto. Nivel 4 - Controlado/Administrado: (PSP 3) desarrollo cclico Administracin de los cambios del proceso. Administracin del cambio tecnolgico. Prevencin de defectos.... Nivel 5 - Optimizado. Mejora del proceso de software. Para PSP es obligatorio el uso de formatos y scripts propuestos para el mismo, estos los puedes encontrar en internet fcilmente.

TSP:
Es una metodologa para dirigir el trabajo de mejora y desarrollo de software adems de establecer un entorno donde el trabajo efectivo de equipo sea normal y natural. Conjunto de procesos estructurados que indican qu hacer en cada fase del desarrollo del proyecto y muestra cmo conectar cada fase para construir un producto completo En combinacin con el Personal Software Process (PSP), el llamado Team Software Process (TSP) proporciona un marco de trabajo de procesos definidos que est diseado para ayudarle a equipos de gerentes e ingenieros a organizar y producir proyectos de software de gran escala, que tengan tamaos mayores a varios miles de lneas de cdigo. El objetivo del TSP es mejorar los niveles de calidad y

-4-

productividad de un proyecto de desarrollo de software de un equipo, con el fin de ayudarlos a alcanzar los acuerdos de costos y tiempos en dicho desarrollo. La versin inicial del TSP fue desarrollada por Watts Humphrey en 1996, y el primer Reporte Tcnico para TSP fue publicado en el ao 2000, patrocinado por el Departamento de Defensa de los Estados Unidos. El libro de Watts Humphrey llamado "Introduction to the Team Software Process" (Addison Wesley Professional, Massachusetts, 1999), presenta el TSP en detalle y se enfoca en el proceso de la construccin de un equipo productor de software, estableciendo objetivos del equipo, distribuyendo los roles, y otras actividades de trabajo en equipo. Antes que los ingenieros de software puedan participar en el TSP, se requiere que ya hayan aprendido sobre el PSP (Personal Software Process), de manera tal que el TSP pueda funcionar de manera adecuada. El TSP comienza con un proceso de cuatro das llamado despegue. El despegue est diseado para comenzar el proceso de construccin de los equipos y durante ste tiempo, los equipos y sus administradores establecen metas, definen roles, evalan riesgos y producen un plan de equipo. El despegue generalmente se hace con un coach especficamente entrenado, o con un lder que ya ha gerenciado varios proyectos que han usado TSP para su desarrollo. La idea principal de TSP es maximizar calidad Software, Minimizar costos. Integrar equipos independientes de alto rendimiento que planeen y registren su trabajo, establezcan metas, y sean dueos de sus procesos y planes.

CMMI:
Es un proceso de mejora enfoque que ayuda a las organizaciones a mejorar su desempeo. IMCM se puede utilizar para guiar la mejora de procesos a travs de un proyecto, una divisin o una organizacin entera. Integracin de modelos de madurez de capacidades o Capability maturity model integration (CMMI) es un modelo para la mejora y evaluacin de procesos para el desarrollo, mantenimiento y operacin de sistemas de software.

-5-

Muchas organizaciones valoran el medir su progreso llevando a cabo una evaluacin (appraisal) y ganando una clasificacin del nivel de madurez o de un nivel de capacidad de logro. Este tipo de evaluaciones son realizadas normalmente por una o ms de las siguientes razones: Para determinar que tan bien los procesos de la organizacin se comparan con las mejores prcticas CMMI y determinar qu mejoras se pueden hacer. Para informar a los clientes externos y proveedores acerca de que tan bien los procesos de la organizacin se comparan con las mejores prcticas CMMI. Para cumplir los requisitos contractuales de uno o ms clientes.

Las valoraciones de las organizaciones utilizando un modelo CMMI deben ajustarse a los requisitos definidos en el documento "Appraisal Requirements for CMMI" (ARC). La evaluacin se enfoca en identificar oportunidades de mejora, y comparar los procesos de la organizacin con las mejores prcticas CMMI. Los equipos de evaluacin usan el modelo CMMI y un mtodo conforme a ARC para guiar su evaluacin y reporte de conclusiones. Los resultados de la evaluacin son usados para planear mejoras en la organizacin. El Standard CMMI Appraisal Method for Process Improvement (SCAMPI) es un Mtodo de evaluacin que cumple todos los requerimientos ARC. Una evaluacin de clase A es ms formal y es la nica que puede resultar en una clasificacin de nivel. El Standard CMMI Appraisal Method for Process Improvement (SCAMPI) es el mtodo oficial SEI para proveer puntos de referencia de sistemas de calificacin en relacin con los modelos CMMI. SCAMPI se usa para identificar fortalezas y debilidades de los procesos, revelar riesgos de desarrollo/adquisicin, y determinar niveles de capacidad y madurez. Se utilizan ya sea como parte de un proceso o programa de mejoramiento, o para la calificacin de posibles proveedores. El mtodo define el proceso de evaluacin constando de preparacin; las actividades sobre el terreno; observaciones preliminares, conclusiones y valoraciones; presentacin de informes y actividades de seguimiento.

-6-

Y por ltimo tenemos la metodologa SPICE.

SPICE:
Este est basado en la norma ISO/IEC 15504 y nos dice que es un proyecto que por sus siglas SPICE (Software Process Improvement and Capability dEtermination) es una actividad del WG 10 del Subcomit 7 del ISO/IEC JTC1, un estndar internacional para procesos de desarrollo de software que provea de un marco de trabajo uniforme para gestin e ingeniera del software. SPICE es una norma que trata los procesos de ingeniera, gestin, relacin clienteproveedor, de la organizacin y del soporte. Fue creada por la alta competencia del mercado de desarrollo de software, a la difcil tarea de identificar los riesgos, cumplir con el calendario, controlar los costos y mejorar la eficiencia y calidad. Este engloba un modelo de referencia para los procesos y sus potencialidades sobre la base de la experiencia de compaas grandes, medianas y pequeas.

-7-

CONCLUSION:

La calidad del software puede verse como un problema econmico aunque es fundamental obtener un software de calidad, Cada medida, cada test, cada revisin consume tiempo y dinero Si se desea un software de alta calidad, hay que asegurarse de que cada una de sus partes tenga alta calidad. Adems de esto existen razones para la lentitud en la adopcin del uso de medidas para evaluar la calidad del software, algunas seran que no existen medidas de la calidad del software universales Existen algunas medidas tiles para ciertos entornos Existirn medidas de calidad ampliamente aceptadas, cuando madure la investigacin en medidas de calidad del software, Incluso sabiendo qu medidas usar, no es fcil obtener los datos, incluso con los datos, no es obvio cmo interpretar y usar los nmeros tambin la gente se resiste a que se mida la calidad de su trabajo Los estndares, por s solos, no son suficientes se necesita una disciplina para aplicarlos, si no se comprende el proceso del negocio, no resultar til aplicar ningn mtodo de evaluacin de la calidad ni de mejora del proceso. La medida de los atributos del software puede usarse para predecir o medir indirectamente la calidad del software pero no resolver todos los problemas que se presenten en la creacin de este.

-8-