Instituto Tecnolgico de Ciudad VictoriaModalidad a Distancia15Asignatura: Gestin de Proyectos de Software.Ing. Jess Omar Lpez.Estudiante: Roberto Carlos Lujn Brizuela.Actividad: 5, 2.1 Gestion de Proyectos usando Marco de Calidad.No. De control: 12380905

ContenidoContenido12.1. La gestin de proyectos usando un marco de calidad22.2 Estndares y Mtricas de calidad en la ingeniera de SW101.ISO 9000.-102.CMMI - CMM113.SPICE12MTRICAS13MTRICAS PARA LA CALIDAD DEL SOFTWARE13EFICACIA DE LA ELIMINACIN DE DEFECTOS142.2.1 PSP y TSP15PSP15TSP162.2.2 CMM18EL MODELO CMM182.2.3 MOPROSOFT20Bibliografa22

2.1. La gestin de proyectos usando un marco de calidadLa calidad es un concepto complejo y con diferentes facetas, y en consecuencia debe ser estudiado en diferentes perspectivas (D. Garvin, 1982). Tras analizar campos diferentes como la filosofa, la economa o el marketing, existen 5 perspectivas desde la cuales la calidad puede ser definida y entendida segn Garvin, estas son:1. Visin trascendental de la calidad. Tambin denominada calidad relativa. Hace referencia el hecho de que la calidad es fcil de percibir y reconocer, pero difcil de definir. Segn esta perspectiva, todos tenemos un concepto similar de lo que es la calidad del software, algo as como un ideal que habra de alcanzar. No obstante, que es difcil que el software, una vez construido, tenga la perfeccin de un software ideal que sirviese al mismo fin.2. Perspectiva del usuario. Segn esta perspectiva, la calidad se entiende como conformidad con aquello que el cliente espera recibir y que fue establecido en las especificaciones del software. A diferencia de la perspectiva anterior, la perspectiva del usuario permite medir la calidad en trminos concretos: cuanto mayor sea el grado de cercana entre las necesidades del usuario y las caractersticas proporcionadas por el software, mayor ser su calidad.3. Perspectiva de la produccin. Identifica la calidad del producto con la calidad de los procesos de produccin y post-venta. Segn esta perspectiva, todo producto fabricado de acuerdo con estndares regulados de calidad podr ser considerado un producto de calidad, posiblemente mejor que otros que no hayan sido fabricados segn este tipo de criterios. sta es la visi0n de la calidad del estndar ISO 9001 y del modelo de madurez CMM.4. Perspectiva del producto. Esta perspectiva, relaciona la calidad con ciertas caractersticas de este, tales como la facilidad de mantenimiento, la funcionalidad o su fiabilidad. A diferencia de las anteriores que observan la calidad del software y como es percibida exteriormente, esta perspectiva apunta a la calidad interna del software. Es la perspectiva que recoge, por ejemplo, el estndar IEEE 1061-1992, donde se enuncia un conjunto de atributos a estudiar en el software construido.5. La perspectiva del valor. Establece una relacin entre la calidad del dinero que el cliente est dispuesto a pagar y la calidad del producto. Se trata de una forma pragmtica de entender la calidad, pues llegando a un punto donde existe un conflicto entre lo que el cliente est dispuesto a pagar y el costo real de lo que solicita, los gestores del desarrollo tendrn que decidir qu nivel de calidad puede implementarse para satisfacer las necesidades del cliente, pero teniendo en cuenta que dicho cliente no est dispuesto a asumir los costos de la mejor de las implementaciones posibles.Los clientes o el departamento de marketing tienen una perspectiva de la calidad ms inclinada a la perspectiva del usuario la cual busca que el software abarque sus necesidades y expectativas, que no implique mucho esfuerzo para aprender a utilizarlo, fcil de usar y que en cuestin de fallos incurra en lo mnimo.Un desarrollador se inclina ms por la perspectiva del producto: cantidad y tipo de errores, bajo impacto de las modificaciones y facilidad para la comprensin de su cdigo, son algunos de los puntos ms importantes desde sta perspectiva.En cuanto a la visin de un comprador es centrada hacia la perspectiva de valor: ms relacionado hacia la calidad y precio bsicamente.Todo esto hace que en numerosas ocasiones surjan conflictos entre los diferentes actores por cuestiones relacionadas con la calidad, ya que cada uno tiene, como se ha visto, diferentes perspectivas de la misma.

Calidad del producto.La calidad del producto apunta a los atributos internos del software como fuente de calidad, a diferencia de otras perspectivas que evalan la calidad desde un punto de vista externo, midiendo la calidad en funcin de cmo sta se percibe sin evaluar las interioridades del producto en s. Se denomina calidad del software el grado en que un software posee una combinacin de atributos deseables.Esta definicin de calidad, orientada a la cuantificacin y medida de la misma, coincide con la nocin de calidad de los modelos ms clsicos como el de McCall, el de Bohm o el que define el estndar de calidad ISO/IEC 9126. A continuacin se estudian estos modelos.

Modelo de calidad de McCallReconociendo la naturaleza intangible y hasta cierto punto abstracta de la calidad, muchos autores han publicado modelos que tratan de caracterizar el software de modo que resulte ms fcil evaluar y medir los costos y beneficios de la calidad del software. El modelo de McCall (1977) fue creado para las fuerzas areas norteamericanas con la intencin de acercar las visiones de calidad de los desarrolladores y usuarios. Es de especial importancia por ser histricamente el primero y la base de esfuerzos posteriores, y se organiza en torno a tres tipos de caractersticas de calidad:1. Factores de calidad, que permite especificar cmo ven el software sus usuarios desde el exterior.2. Criterios de calidad, que identifica cmo debe construirse internamente el software desde la perspectiva del desarrollador.3. Mtricas de calidad, que indican cmo controlar y medir la calidad.Tal y como se muestra en la siguiente figura, este modelo define tres perspectivas desde las que deben estudiarse los once factores que en total se computan en la medida de la calidad de un producto de software. Estas perspectivas son:

Revisin del producto. Esta perspectiva estudia la capacidad del producto para adaptarse a los cambios. Se tiene en cuenta aquellos factores que influyen en la capacidad de adaptacin del producto, tales como la facilidad de mantenimiento (disposicin para ser modificado para ser corregido, adaptado o ampliado), la flexibilidad (capacidad para introducir cambios en funcin de las necesidades de negocio) y la facilidad de evaluacin (capacidad para validar los requisitos establecidos para el software).Transicin del producto. Esta perspectiva identifica los factores de calidad que influye en la capacidad que tiene un cierto software para adaptarse a distintos contextos de operacin. As, tiene en cuenta factores tales como la reusabilidad, portabilidad o la interoperabilidad.Operacin del producto. Esta perspectiva identifica aquellos factores de calidad que tienen que ver con la forma en que el software lleva a cabo sus funcionalidades, y en la medida en que cumple con sus especificaciones. As, tiene en cuenta la correccin (que las funcionalidades solicitadas en su especificacin se encuentren disponibles), la fiabilidad (qu fallos tiene el sistema en operacin), la eficiencia en trminos de uso de recursos, la integridad (proteccin contra accesos no autorizados a la informacin) y la usabilidad.En suma, los once factores de calidad apuntados por McCall estn organizados en las tres perspectivas anteriores. Para evaluar la calidad de un software, ser necesario medir dichos factores, para lo cual el modelo establece el siguiente proceso:

1. Especificar los requisitos de calidad del producto software a desarrollar, seleccionando aquellos aspectos que tengan relacin con la calidad deseada.2. Establecer los factores de calidad (de entre los once descritos) sobre los que aplicar los requisitos de calidad establecidos para el proyecto.3. Evaluar los factores seleccionados mediante criterios que el mtodo proporciona para cada factor.As por ejemplo, si en la evaluacin de la calidad de un cierto software hemos seleccionado la facilidad de mantenimiento como factor de calidad, evaluaremos dicho factor mediante los criterios especficos para el mismo. En el caso de la facilidad de mantenimiento dichos criterios son la modularidad, la simplicidad, la concisin, y la auto descripcin.

MODELO DE BOHMEl modelo de Bohm (1978) es otro modelo de calidad basado en la identificacin de un cierto nmero de caractersticas de calidad para el software. Posterior al modelo de McCall, su aportacin fundamental es la definicin de lo que Bohm denomina utilidades principales, un reconocimiento explcito de que para ser considerado de calidad, un sistema de software debe ser fundamentalmente til.A partir de este concepto de utilidad, Bohm plantea un modelo jerrquico en el que se definen tres utilidades de alto nivel, que seran los requisitos bsicos del software. Dichas utilidades son las siguientes: Utilidad tal y como est, que representa hasta qu punto el software (tal y como est en este momento) es fcil de usar, fiable y eficiente. Facilidad de mantenimiento, que se concreta en la facilidad para identificar qu es necesario modificar, as como la facilidad de modificacin o de ejecucin de las pruebas sobre el elemento modificado. Portabilidad, esto es, la facilidad para utilizar el software en un nuevo entorno, distinto a aquel en que se est utilizando en este momento.Estos tres usos principales representan el primer nivel de la jerarqua del modelo de Bohm. En el segundo nivel, se identifican siete factores de calidad que se asocian con los tres usos del primer nivel. Estos factores son los siguientes:1. Portabilidad, representa la facilidad para utilizar el software en nuevos entornos (sistemas operativos, bases de datos, etc.).2. Fiabilidad, que viene indicada como la ausencia de defectos.3. Eficiencia, es decir, mnimo uso de recursos mediante el correcto funcionamiento del sistema.4. Usabilidad, entendida desde el punto de vista de la ingeniera humana y la ergonoma, aunque comnmente se resume como la facilidad de uso del software.5. Facilidad de evaluacin, en concreto, la validacin de que el software cumple con los requisitos establecidos.6. Comprensibilidad, o facilidad para entender el propsito y estructura del software.7. Flexibilidad, esto es, facilidad para modificar el software ante cambios en los requisitos o aparicin de otros nuevos.

Estos factores de calidad se descomponen a su vez en elementos primitivos que pueden ser medidos. As por ejemplo, y tal y como se muestra en la figura anterior, la portabilidad puede medirse en funcin de dos elementos, su independencia con respecto al dispositivo y el grado en que dicho software est autocontenido. Al igual que en el modelo de McCall, el objetivo final es medir la calidad desde los elementos de ms bajo nivel del modelo, y utilizar estas medidas para mejorar los productos desarrollados.

El modelo de calidad ISO/IEC 9126El estndar ISO/IEC 9126, parcialmente basado en esfuerzos anteriores como el modelo de McCall y el de Bohm, es un estndar internacional para la evaluacin de la calidad del software. Su objetivo principal es proporcionar tanto una especificacin de la calidad de productos software y un modelo para su evaluacin. Define para ello un lenguaje comn que permite a los usuarios especificar sus requisitos de calidad y a los desarrolladores y evaluadores entender dichos requisitos, para posteriormente tratar de incorporarlos al software en desarrollo. ISO/IEC 9126 aspira a establecer medidas objetivas de calidad, huyendo deliberadamente de lo opinable y eliminando en lo posible toda subjetividad. Tambin pretende conseguir que la evaluacin de la calidad sea reproducible y sistemtica, de modo que evaluaciones de un mismo software realizadas por personas diferentes en momentos distintos deberan dar el mismo resultado si el software no ha sufrido modificacin alguna entre ambas evaluaciones como lo muestra la siguiente figura.

El estndar ISO/IEC 9126 se divide en cuatro partes:1. Modelo de calidad (ISO/IEC 9126-1:2001). Describe el marco del modelo de calidad y las relaciones entre los diferentes enfoques de la misma, e identifica las distintas caractersticas de calidad de los productos de software.2. Mtricas externas (ISO/IEC TR 9126-2:2003). Proporciona un conjunto de mtricas que permiten medir las caractersticas de calidad externas definidas en el modelo de calidad descrito en ISO/IEC 9126-1:2001.3. Mtricas internas (ISO/IEC TR 9126-3:2003). Describe mtricas para medir aquellas caractersticas internas de calidad definidas en el modelo descrito en ISO/IEC 9126-1.4. Calidad en las mtricas en uso (ISO/IEC TR 9126-4:2004). Identifica las mtricas que permitirn medir la calidad desde el punto de vista del usuario.

La primera parte ISO/IEC 9126-1:2001 establece el modelo de calidad. Similar a los modelos de McCall, Bohm, FURPS y otros que veremos ms adelante, se basa hasta cierto punto en las ideas aportadas por dichos modelos. As, define 6 caractersticas de calidad externas del software que son las siguientes: funcionalidad, fiabilidad, usabilidad, eficiencia, facilidad de mantenimiento y portabilidad. Cada una de estas caractersticas se divide a su vez en varias sub-caractersticas (atributos tanto externos como internos) que pueden ser medidos con mtricas especficas segn se muestra en la tabla siguiente:

Las mtricas externas de la segunda parte ISO/IEC TR 9126-2:2003 miden el comportamiento del sistema computacional en su conjunto, lo que incluye el software pero no se limita nicamente al mismo. Las mtricas internas de la tercera parte del modelo ISO/IEC TR 9126-3:2003, por el contrario, miden el propio software. Las mtricas de calidad en uso ISO/IEC TR 9126-4:2004, por ltimo, miden los efectos del software en un contexto especfico de utilizacin. Esta parte del estndar, la calidad en uso, especifica cuatro caractersticas que son efectividad, productividad, seguridad y satisfaccin, las cuales son tomadas como indicadores de la calidad tal y como se percibe en funcin del cumplimiento de las caractersticas de calidad de las otras tres partes.Teniendo en cuenta todo lo anterior, la calidad de un software puede evaluarse, en el modelo de calidad del estndar ISO/IEC 9126, bien midiendo los atributos de calidad internos mediante medidas estticas de productos intermedios, no del software en ejecucin, o bien midiendo los atributos de calidad externos a travs de medidas del cdigo cuando se ejecuta, o bien midiendo los atributos de la calidad en uso sobre el software cuando ste se ejecuta en el entorno final de usuario y trabaja en condiciones reales tal y como vemos en la figura siguiente:

En definitiva, el modelo definido por el estndar ISO/IEC 9126 presupone que una mayor calidad interna/externa del producto software incidir de manera positiva en la percepcin que el usuario tiene acerca de la calidad de la aplicacin, y reconoce que el modelo propuesto puede necesitar adaptarse a las caractersticas especficas de ciertas aplicaciones.

2.2 Estndares y Mtricas de calidad en la ingeniera de SW

ESTNDARESLos estndares de calidad de software son normas emitidas por organismos especficos, que sirven para sentar un marco con el que comparar si un proceso de desarrollo es o no de calidad. Las normas de calidad del software ms conocidas han sido desarrolladas por ISO, y son la serie ISO-9000.

1. ISO 9000.- Es una norma sobre calidad y gestin continua de calidad, se pueden aplicar a cualquier tipo de organizacin o actividad sistemtica orientada a la produccin de bienes o servicios. Se componen de estndares y guas relacionados con sistemas de gestin y de herramientas especficas, como los mtodos de auditora.Ventajas: Monitorear los principales procesos asegurando que sean efectivos. Mantener registros apropiados de la gestin, de los procesos y de los procedimientos. Mejorar la satisfaccin de los clientes o los usuarios. Mejorar continuamente los procesos, tanto operacionales como de calidad. Reducir los rechazos e incidencias en la produccin o prestacin del servicio mediante un monitoreo y la existencia de procedimientos para la correccin de los problemas.

2. CMMI - CMM (Capability Maturity Model) es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.Este modelo de procesos tiene dos representaciones: continua y por etapas, siendo la diferencia entre stas la evaluacin por niveles de la capacidad de procesos o de la madurez de la organizacin, respectivamente.

Nivel 1.- Las organizaciones en este nivel no disponen de un ambiente adecuado para el desarrollo de software. Aunque se utilicen tcnicas correctas de ingeniera, los esfuerzos se ven minados por falta de planificacin.

Nivel 2.- En este nivel se definen claramente puntos de control en cada etapa principal del proyecto, esto obviamente permite tener un mayor control del proyecto. Lo importante a resaltar es que cada etapa es an una caja negra es decir no podemos saber con precisin como se desenvuelve el proyecto dentro de cada etapa.Nivel 3.- Los procesos comunes para desarrollo y mantenimiento del software estn documentados de manera suficiente en una biblioteca accesible a los equipos de desarrollo. Las personas han recibido la formacin necesaria para comprender los procesos.Nivel 4.- Estas mtricas no son subjetivas si no que se establecen con criterios cuantitativos formalmente definidos. Con el tiempo estos controles nos brindarn mejor informacin sobre la calidad y estado del proyecto permitindonos compararlo con otros proyectos similares y notar cualquier desviacin tempranamente parar poder corregirlo.Nivel 5.- En este nivel cada proceso es analizado y controlado permanentemente con l intencin de que sea mejorado en todo momento, los controles permiten la mejora continua y se tienen implementadas todas las reas clave de proceso recomendadas por el modelo.

3. SPICE (Software Process Improvement and Capability Determination). Se conforma como el estndar emergente orientado a la mejora continua del proceso de desarrollo de software. Es un estndar internacional cuyo objetivo es simular circuitos electrnicos analgicos compuestos por resistencias, condensadores, diodos, transistores, etc. Para ello hay que describir los componentes, describir el circuito y luego elegir el tipo de simulacin.

Etapas: Preparacin.- En esta etapa se ve el alcance del estudio, metas del negocio, los procesos a evaluar y las instancias de los procesos. Recoleccin de datos.- Los expertos realizan entrevistas, discusiones, anlisis de documentos y uso de herramientas. En las entrevistas los evaluadores entrevistan o discuten con gente interesada en el proceso de acreditacin en SPICE. Recopilacin de anlisis de documentos relevantes.- En la recopilacin de los documentos se pueden utilizar herramientas automatizadas en lugar de un asesor y/o evaluador para recopilar los datos.

MTRICASLas Mtricas de Calidad proporcionan una indicacin de cmo se ajusta elsoftware, a los requerimientos implcitos y explcitos del cliente.El objetivo principal de la ingeniera delsoftwarees producir un producto de alta calidad. Para lograr este objetivo, los ingenieros del software deben utilizar mediciones que evalen la calidad del anlisis y los modelos de desafo, el cdigo fuente, y los casos de prueba que se han creado al aplicar la ingeniera del software. Para lograr esta evaluacin de la calidad en tiempo real, el ingeniero debe utilizar medidas tcnicas que evalan la calidad con objetividad, no con subjetividad.El primer objetivo del equipo deproyectoes medir errores y defectos. Las mtricas que provienen de estas medidas proporcionan una indicacin de la efectividad de las actividades de control y de la garanta de calidad.

MTRICAS PARA LA CALIDAD DEL SOFTWAREDesarrollando y analizando una lnea base de mtricas de calidad, una organizacin puede actuar con objeto de corregir esas reas de proceso del software que son la causa de los defectos delsoftware. Con la creacin de estas mtricas los ingenieros del software pueden obtener una visin ms profunda deltrabajoque realizan y delproducto que elaboran.

VISIN GENERAL DE LOS FACTORES QUE AFECTAN A LA CALIDADSe han definido un conjunto de factores de calidad, estos factores evalan el software desde tres puntos de vista distintos: Operacin del producto (utilizndolo). Revisin del producto (cambindolo). Transicin del producto (modificndolo para que funcione en un entorno diferente).Proporciona un mecanismo para que el gestor delproyectoidentifique lo que considera importante y un medio de evaluar cuantitativamente lo bien que va progresando el desarrollo en relacin con los objetivos de calidad establecidos.

MEDIDA DE LA CALIDADLa correccin, facilidad de mantenimiento, integridad, y facilidad de uso son medidas de calidad que proporcionan indicadores tiles para el equipo del proyecto. Correccin: La correccin es el grado en el que el software lleva a cabo su funcin requerida. Facilidad de mantenimiento: Es la facilidad con la que se puede corregir un programa si se encuentra un error, se puede adaptar si su entono cambia, o mejorar si el cliente desea un carnio de requisitos. Esta actividad cuenta con ms esfuerzo que cualquier otra actividad de ingeniera del software. Integridad: Mide la capacidad de un sistema para resistir ataques (tanto accidentales como intencionados) contra su seguridad. El ataque se puede realizar en cualquiera de los tres componentes delsoftware: programas,datosydocumentos.Para medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad. Amenaza es la probabilidad de que un ataque de un tipo determinado ocurra en un tiempo determinado. La seguridad es la probabilidad de que se pueda repeler el ataque de un tipo determinado. La integridad del sistema se puede definir corno: Integridad = C [(l - amenaza) x (1 - seguridad)] Donde se suman la amenaza y la seguridad para cada tipo de ataque. Facilidad de uso: La facilidad de uso es un intento de cuantificar lo amigable que puede ser el programa con el usuario. Se puede medir en funcin de cuatro caractersticas: Habilidad intelectual y/o fsica requerida para aprender el sistema. El tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema. Aumento neto en productividad, medida cuando alguien utiliza el sistema moderadamente y eficientemente. Valoracin subjetiva de la disposicin de 1os usuarios hacia el sistema, a veces obtenida mediante un cuestionario.

EFICACIA DE LA ELIMINACIN DE DEFECTOSProporciona beneficios tanto a nivel del proyecto como del proceso, es una medida para filtrar las actividades de la garanta de calidad y de control al aplicarse a todas las actividades del marco de trabajo del proceso.La Eficacia de la Eliminacin de Defectos (EED) se define de la forma siguiente: EED=E / (E+D) Donde E es el nmero de errores encontrados antes de la entrega del software al usuario final y D es el nmero de defectos encontrados despus de la entrega. Cuando el valor de EED es 1 significa que no se han encontrado defectos en el software, D ser mayor que cero. Cuando E aumenta (para un valor de D dado), el valor total de EED empieza a aproximarse a 1. De hecho, a medida que E aumenta, es probable que el valor final de D disminuya (los errores se filtran antes de que se conviertan en defectos). Si se utilizan como una mtrica que proporciona un indicador de la habilidad de filtrar las actividades de la garanta de la calidad y del control, EED anima a que el equipo delproyectode software instituya tcnicas para encontrar todos los errores posibles antes de su entrega.EED tambin se puede utilizar dentro delproyectopara evaluar la habilidad de un equipo en encontrar errores antes de que pasen a la siguiente tarea de ingeniera del software. Se vuelve a definir como:EEDi = Ei / (Ei + Ei +1)Donde Ei es el nmero de errores encontrado durante la actividad deingenieradel software i y Ei+1, es el nmero de errores encontrado durante la actividad de ingeniera del software i + 1 que se puede seguir para llegar a errores que no se detectaron en la actividad de la ingeniera del software i.

2.2.1 PSP y TSPPSPEs 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 procesosCMMIoISO 15504. Fue propuesto porWatts Humphreyen1995y estaba dirigido a estudiantes. A partir de1997con el lanzamiento del libro "An introduction to the Personal Software Process" se dirige ahora a ingenieros juniors.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.PSP, es uno de los 3 vrtices donde descansa un proceso de mejora que trabaja sobre 3 niveles de la organizacin, los otros 2 son CMM y TSP.El PSP amplia el proceso de mejora a la gente que realiza el trabajo de desarrollo de software, concentrndose en las practicas de trabajo de los ingenieros en una forma individual, enseando como manejar la calidad desde el principio de un producto. PSP son nuestras propias mtricas, que permiten estructurar y ordenar nuestro trabajo del da a da (no solo de desarrollo de software, esto lo voy a explicar ms adelante). El resultado de nuestro trabajo, adems puede ser llevado a un trabajo en equipo TSP (Team Process Software), el cual es comandado por un sistema de gestin de la configuracin y por supuesto, un Jefe de Proyecto quien evala los resultados y avances de los miembros del equipo.

TSPTeam Software Process (TSP) es un mtodo de establecimiento y mejora del trabajo en equipo para procesos software.TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organizacin pueda establecer prcticas de ingeniera avanzadas y as obtener productos eficientes, fiables y de calidad. Est formado por dos componentes primarios que abarcan distintos aspectos del trabajo en equipo: Formacin del equipo de trabajo. Gestin del equipo de trabajo.

Existen diferentes metodologas para la mejora de procesos, la mayora de ellas se basa en la mejora de los procesos que dan como resultado un servicio o producto. El TSP busca integrar un equipo que tenga como punto de partida la unificacin del mismo, para poder llevar a cabo todos aquellos procedimientos que puedan realizar mejora a los procesos que desarrollan.El Team Software Process (TSP) es un proceso de desarrollo para equipos de ingenieros basado en CMMI, ayuda a conformar equipos para el desarrollo de software de calidad. TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organizacin pueda establecer prcticas de ingeniera avanzadas y as obtener productos eficientes, fiables y de calidad.

TSP es una solucin basada en procesos para resolver problemas de negocio, tales como: Predictibilidad de costo y tiempo Mejora de productividad Ciclos de desarrollo y mejora de calidad de productos.

Caractersticas de los grupos eficaces: Miembros expertos en papeles de liderazgo y pertenencia. Relaciones tranquilas y establecidas entre los miembros. Los miembros se sienten atrados por el grupo y son fieles. Los valores y metas del grupo son los de sus integrantes Los miembros estn motivados por hacer lo que puedan por el grupo. La interaccin y toma de decisiones tiene lugar en el ambiente adecuado. El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea ayudar a cada miembro a adquirir su pleno potencial. Cada miembro acepta con gusto y sin resentimiento las metas y normas establecidas. Los miembros se prestan ayuda mutua cuando es necesaria o recomendable. Existe una atmsfera de creatividad. El grupo conoce el conformismo constructivo y se sirve de l. Existe gran motivacin para iniciar y recibir las comunicaciones. Los miembros son flexibles y adaptables en sus metas y actitudes. Los miembros se sienten seguros al tomar decisiones que les Los miembros se sienten seguros al tomar decisiones que les parecen apropiadas al entender la filosofa de la operacin.

Sus orgenes se deben a las limitaciones que el PSP (Personal Software Process, su antecesor) tena en el mbito industrial. PSP result muy efectivo para que los ingenieros pudiesen tener el control de su proceso personal mediante la mejora de sus habilidades de estimacin y la reduccin de los defectos introducidos en los productos sin afectar a su productividad, pero PSP slo se enfocaba en las fases de desarrollo de software (diseo y pruebas unitarias); la aplicacin que lo ingenieros hicieron del PSP dentro de las empresas resulto en prcticas no satisfactorias.Por tal motivo, Watts Humphrey desarroll el TSP, el cual consideraba como parte importante, adems de lo previsto por el PSP, los requisitos, las pruebas de integracin, la documentacin y otras actividades tpicas en todo proyecto de desarrollo, de igual manera inclua actividades como los roles de equipo, interrelaciones dentro de la organizacin y la definicin de un proceso de equipo para ser utilizado dentro de los procesos existentes en la organizacin.Los objetivos que tiene el TSP son: Maximizar calidad software, minimizar costos. Integrar equipos independientes de alto rendimiento que planeen su trabajo, establezcan metas y san sueos de sus procesos y planes. Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a alcanzar su mxima productividad. Acelerar la mejora continua de monitoreo. Proveer de una gua para el mejoramiento en organizaciones maduras

2.2.2 CMMModelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluacin de los procesos de una organizacin. Fue desarrollado inicialmente para los procesos relativos al software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).El SEI es un centro de investigacin y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de Amrica y gestionado por la Universidad Carnegie-Mellon. "CMM" es una marca registrada del SEI.

EL MODELO CMMA partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de Amrica, desarroll una primera definicin de un modelo de madurez de procesos en el desarrollo de software, que se public en septiembre de 1987. Este trabajo evolucion al modelo CMM o SW-CMM (CMM for Software), cuya ltima versin (v1.1) se public en febrero de 1993.Este modelo establece un conjunto de prcticas o procesos clave agrupados en reas Clave de Proceso (KPA - Key Process Area). Para cada rea de proceso define un conjunto de buenas prcticas que habrn de ser: Definidas en un procedimiento documentado Provistas (la organizacin) de los medios y formacin necesarios Ejecutadas de un modo sistemtico, universal y uniforme (institucionalizadas) Medidas VerificadasA su vez estas reas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organizacin que tenga institucionalizadas todas las prcticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.Los niveles son:Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicentcnicas correctas de ingeniera, los esfuerzos se ven minados por falta de planificacin. El xito de los proyectos se basa la mayora de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible.Repetible. En este nivel las organizaciones disponen de unas prcticas institucionalizadas de gestin de proyectos, existen unas mtricas bsicas y un razonable seguimiento de la calidad. La relacin con subcontratistas y clientes est gestionada sistemticamente.Definido. Adems de una buena gestin de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinacin entre grupos, formacin del personal, tcnicas de ingeniera ms detallada y un nivel ms avanzado de mtricas en los procesos. Se implementan tcnicas de revisin por pares (peer reviews).Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de mtricas significativas de calidad y productividad, que se usan de modo sistemtico para la toma de decisiones y la gestin de riesgos. El software resultante es de alta calidad.Optimizado. La organizacin completa est volcada en la mejora continua de los procesos. Se hace uso intensivo de las mtricas y se gestiona el proceso de innovacin.

Las prcticas que deben ser realizadas por cada Area Clave de Proceso estn organizadas en 5 Caractersticas Comunes, las cuales constituyen propiedades que indican si la implementacin y la institucionalizacin de un proceso clave es efectivo, repetible y duradero.

Estas 5 caractersticas son: Compromiso de la realizacin La capacidad de realizacin Las actividades realizadas Las mediciones y el anlisis La verificacin de la implementacin.

2.2.3 MOPROSOFTModelo de Procesos para la Industria del Software. Modelo para la mejora y evaluacin de los procesos de desarrollo y mantenimiento de sistemas y productos desoftware. Desarrollado por la Asociacin Mexicana para la Calidad en Ingeniera de Softwarea travs de la Facultad de Ciencias de la Universidad Nacional Autnoma de Mxico (UNAM) y a solicitud de la Secretara de Economa para obtener una norma mexicana que resulte apropiada a las caractersticas de tamao de la gran mayora de empresas mexicanas de desarrollo y mantenimiento de software. Moprosoft es el nombre del modelo en la comunidad universitaria y profesional, y la norma tcnica a la que da contenido es la NMX-059/01-NYCE-2005 que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicacin de su declaratoria en elDiario oficial de la Federacin.Moprosoft considera que los modelos de evaluacin y mejoraCMMIeISO/IEC 15504no resultan apropiados para empresas pequeas y medianas de desarrollo y mantenimiento de software. Sobre las reas de procesos de los niveles 2 y 3 del modeloSW-CMMe inspirndose en el marco deISO/IEC 15504 se ha desarrollado este modelo.Criterios empleadosSe han aplicado los siguientes criterios para la elaboracin de este modelo de procesos: La estructura de procesos resultante debe ser acorde a la estructura generalmente empleada por las organizaciones de la industria del software (alta direccin, gestin y operacin) La alta direccin tiene un papel importante a travs de la planificacin estratgica. Debe actuar como promotor del buen funcionamiento de la organizacin a travs de su implicacin en la revisin y mejora continua del modelo. El modelo considera a la gestin como proveedora de recursos, procesos y proyectos; as como responsable de la vigilancia del cumplimiento de los objetivos estratgicos de la organizacin. El modelo considera a la operacin como ejecutora de los proyectos de desarrollo y mantenimiento de software. El modelo integra con claridad y consistencia los elementos indispensables para la definicin de los procesos y las relaciones entre ellos. El modelo integra los elementos para realizar la administracin de proyectos desde un slo proceso. El modelo integra los elementos para realizar la ingeniera de productos de software en un nico marco que incluya los procesos precisos de soporte (verificacin, validacin, documentacin y control de la documentacin). El modelo destaca la importancia de la gestin de recursos, con especial relevancia en aquellos que componen el conocimiento de la organizacin: productos generados por proyectos, datos de los proyectos, mediciones, documentacin de procesos y datos cosechados a partir del uso y de las lecciones aprendidas. Moprosoft se basa en los modelos de procesosISO 9001:2000, en las reas de procesos de los niveles 2 y 3 deCMM-SW: CMM-SW v.1.1., en el marco general ISO/IEC15504 y en prcticas y conceptos dePMBOKY SWEBOK. PROSOFT representa un campo diferente de apoyo a los empresarios de las tecnologas de la informacin, es un sector diverso para hacer negocios y generar fuentes de empleo dignas

El Plan Nacional de Desarrollo 2001-2006 plantea el fomento a la industria y el mercado De Tecnologas de la Informacin (TI) como estrategia para aumentar la competitividad del Pas. Dado el gran potencial con que cuenta Mxico para desarrollar esta industria, la Secretara de Economa, en coordinacin con organismos empresariales y empresas del Sector, dise el PROSOFT.

El Moprosoft se estructura en 3 categoras: Categora de Alta Direccin (DIR):Se establecen los lineamientos para los procesos de la Categora de Gerenciay se retroalimenta con la informacin generada por ellos en apoyo a laestrategia de la organizacin. Categora de Gerencia (GER):Se denen los elementos para el funcionamiento de los procesos de laCategora de Operacin en funcin de la estrategia de Direccin, recibe yevala la informacin generada por stos y comunica los resultados a laCategora de Alta Direccin. Categora de Operacin (OPE):Se realizan las actividades de acuerdo a los elementos proporcionados por laCategora de Gerencia y entrega a sta la informacin y productosgenerados

BibliografaAnnimo. (01 Diciembre 2009). Estndares ISO, SPICE y CMM. 19 de Noviembre del 2015, de slideshare.com Sitio web: http://es.slideshare.net/guest8e0579/estandares-isospice-y-cmm-y-empresasS.Pressman, Rogger. (s.f.). Ingenieria de Softaware. Un enfoque prctico (5ta ed.).A/A. (S/A). MOPROSOFT. 19 de Noviembre del 2015, de sites.google Sitio web: https://sites.google.com/site/gestiondeproyectossoftware/unidad-2-calidad-de-software/2-2-3-moprosoft