Está en la página 1de 17

CALIDAD DE SOFTWARE El objetivo general de la ingeniera de software es la produccin de software de calidad.

. La calidad del software puede ser considerada desde dos perspectivas diferentes; la ptica del desarrollador y la del cliente o usuario final. Los factores que afectan al desarrollador se denominan Internos y los del cliente Externos

FACTORES DE CALIDAD DE SOFTWARE Por una parte, se consideran cualidades tales como la velocidad o la facilidad de uso, cuya presencia o ausencia en un producto de software puede ser detectada por sus usuarios. Estas propiedades pueden ser denominadas factores de calidad externos. Otras cualidades aplicables a un producto de software, como la Modularidad o legibilidad son factores internos, perceptibles slo por profesionales de la informtica que tienen acceso al cdigo fuente. 1. Una revisin de los factores externos: 1.1 Correccin

La correccin es la cualidad principal. Si un sistema no hace lo que se supone que debe hacer, poco importan el resto de consideraciones que hagamos sobre l si es rpido, si tiene una bonita interfaz de usuario Pero esto es ms fcil de decir que de lograr. Incluso el primer paso hacia la correccin es ya difcil: debemos ser capaces de especificar los requisitos del sistema de una forma precisa, lo que es en s una ardua tarea. Los mtodos que aseguran la correccin son usualmente condicionales. Un sistema de software importante, incluso uno pequeo segn los estndares de hoy, implica a tantas reas que sera imposible garantizar su correccin manejando todas las componentes y propiedades en un solo nivel. En cambio, es necesaria una solucin multinivel, en la que cada nivel confa en la correccin de los inferiores: Hardware ----> Sistema Operativo----> Compilador ----> Sistema de Aplicacin En la solucin condicional de la correccin, slo hay que preocuparse en garantizar que cada nivel sea correcto bajo el supuesto de que los niveles inferiores son correctos. 1.2 Robustez

La robustez complementa la correccin. La correccin tiene que ver con el comportamiento de un sistema en los casos previstos por su especificacin; la robustez caracteriza lo que sucede fuera de tal especificacin. La robustez es por naturaleza una nocin ms difusa que la correccin. Puesto que tiene que ver aqu con casos no previstos por la especificacin, no es posible decir, como con la correccin, que el sistema debera realizar sus tareas en tal caso; donde las tareas son conocidas, el caso excepcional formara parte de la especificacin y regresaramos al terreno de la correccin. Siempre habr casos que la especificacin no contemple explcitamente. El papel del requisito de robustez es asegurar que si tal caso surgiese el sistema no causar eventos catastrficos; debera producir mensajes de error apropiados, terminar su ejecucin limpiamente en lo posible. 1.3 Extensibilidad

El software se supone que es soft (blando), y realmente lo es en un principio; nada es ms fcil de cambiar que un programa si se tiene acceso a su cdigo fuente. El problema de extensibilidad es un problema de escala. Para programas pequeos realizar cambios no es normalmente una tarea difcil; pero a medida que el software crece comienza a ser cada vez ms difcil de adaptar. La extensibilidad es necesaria porque en la base de todo software encontramos algn fenmeno humano y de ah su volatilidad. El cambio es omnipresente en el desarrollo del software: cambios en los requisitos, de nuestra comprensin de los requisitos, de los algoritmos, de la representacin de los datos, de las tcnicas de implementacin. Ofrecer soporte para los cambios es un objetivo bsico de la tecnologa de objetos. Aunque muchas de las tcnicas que mejoran la extensibilidad se pueden aplicar con pequeos ejemplos, su relevancia slo se ve con claridad en los grandes proyectos. Hay dos principios esenciales para mejorar la extensibilidad: Simplicidad del diseo: una arquitectura simple siempre ser ms fcil de adaptar a los cambios que una compleja. Descentralizacin: cuanto ms autnomos sean los mdulos, ms alta es la probabilidad de que un cambio afecte a un solo mdulo, o a un nmero pequeo de mdulos, en lugar de provocar una reaccin en cadena de cambios en el sistema completo.

1.4 Reutilizacin

La necesidad de la reutilizacin surge de la observacin de que los sistemas software a menudo siguen patrones similares; debera ser posible explotar esta similitud y evitar reinventar soluciones a problemas que ya han sido encontradas con anterioridad. Capturando tal patrn, un elemento de software reutilizable se podr aplicar en muchos desarrollos diferentes. La reutilizacin tiene una influencia sobre todos los dems aspectos de la calidad del software, ya que al resolver el problema de la reutilizacin se tendr que escribir menos software y en consecuencia se podrn dedicar entonces mayores esfuerzos a mejorar los otros factores, tales como la correccin y la robustez. 1.5 Compatibilidad

La compatibilidad es importante debido a que los sistemas software no se desarrollan en el vaco: necesitan interactuar con otros. Pero con mucha frecuencia los sistemas tienen dificultades para interactuar porque hacen suposiciones contradictorias sobre el resto del mundo. Un ejemplo es la amplia variedad de formatos de archivos soportados por muchos sistemas operativos. Un programa puede usar directamente como entrada los resultados de otro slo si los formatos de archivos son compatibles.La clave de la compatibilidad recae en la homogeneidad del diseo y en acordar convenciones estndares para la comunicacin entre programas. Los enfoques incluyen: Formatos de archivos estndares, como en el sistema Unix, donde cualquier archivo de texto es simplemente una secuencia de caracteres. Estructuras de datos estndares como en los sistemas Lisp, donde tanto los datos como los programas, se representan mediante rboles binarios. Interfaces de usuario estndares, como en las diferentes versiones de Windows donde todas las herramientas utilizan un solo paradigma para la comunicacin con el usuario, basado en componentes estndares tales como ventanas, conos, mens, etc.

1.6 Eficiencia

Casi sinnimo de eficiencia es la palabra rendimiento. La comunidad del software muestra dos tipos de actitud con relacin a la eficiencia: Algunos desarrolladores tienen una obsesin con las cuestiones de rendimiento y le dedican gran cantidad de esfuerzos a presuntas optimizaciones. Por otro lado, existe la tendencia de soslayar las cuestiones de eficiencia, como se evidencia en las frases de la industria hgalo correcto antes de hacerlo rpido y de todos modos los modelos de computadoras del ao que viene van a ser un 50% ms rpidos.

De manera ms general, la preocupacin por la eficiencia debe sopesarse con otros objetivos tales como la extensibilidad y la reutilizacin; optimizaciones extremas

pueden hacer al software tan especializado que limite el cambio y la reutilizacin. Es ms, la potencia creciente del hardware de las computadoras nos permite tener una actitud ms relajada con respecto a tratar de ganar hasta el ltimo byte o microsegundo. 1.7 Portabilidad (transportabilidad)

La portabilidad tiene que ver con las variaciones no slo del hardware fsico sino ms generalmente de la mquina hardware-software, la que realmente programamos y que incluye el sistema operativo, el sistema de ventanas y otras herramientas fundamentales. Muchas de las incompatibilidades existentes entre las plataformas son injustificadas, y convierte a la portabilidad en un asunto primordial tanto para los que desarrollan como para los que usan el software. 1.8 Facilidad de uso

La definicin insiste en los diferentes niveles de experiencia de los posibles usuarios. Este requisito plantea uno de los mayores retos de los diseadores de software preocupados por la facilidad de uso: cmo proporcionar explicaciones y guas detalladas a los usuarios novatos sin fastidiar a los usuarios expertos que quieren ir directo al grano. Una de las claves de la facilidad de uso es la simplicidad estructural. Un sistema bien diseado, construido de acuerdo a una estructura clara y bien pensada, tiende a ser ms fcil de aprender y usar que uno confuso. Los buenos diseadores de interfaces siguen una poltica prudente. Hacen las menos suposiciones posibles sobre los usuarios. Cuando se disea un sistema interactivo, se debe esperar que los usuarios sean miembros de la raza humana y que sepan leer, mover un ratn, presionar un botn y teclear (lentamente); no mucho ms. Si el software est dirigido a un rea especializada de aplicacin, se puede dar por supuesto que los usuarios estn familiarizados con sus conceptos bsicos. Pero incluso esto es arriesgado. 1.9 Funcionalidad

Uno de los problemas ms difciles a los que se enfrenta un jefe de proyecto es conocer cuanta funcionalidad es suficiente. La presin para ofrecer ms facilidades (conocida como featurism), est constantemente presente. Sus consecuencias son malas para los proyectos internos, donde las presiones vienen de los usuarios de la

misma compaa, y son peores para los productos comerciales, ya que la parte ms destacada de los anlisis comparativos suele ser una tabla donde se enumeran una por una las propiedades que ofrecen los distintos productos analizados. El featurism es realmente la combinacin de dos problemas, uno ms difcil que el otro. El problema ms fcil es la prdida de consistencia como consecuencia de estar aadiendo nuevas propiedades, lo que puede afectar a su facilidad de uso. Los usuarios se quejan con razn de que toda la parafernalia que acompaa a una nueva versin de un producto lo hace tremendamente complejo. Tales comentarios no deberan preocuparnos en exceso, puesto que las nuevas propiedades no surgen de la nada: la mayor parte de las veces han sido solicitadas por los usuarios otros usuarios. Lo que a unos les puede resultar algo superfluo puede ser una facilidad indispensable para otros. La solucin aqu es trabajar una y otra vez sobre la consistencia del producto global, tratando de que todo encaje en un molde general. Un buen producto software est basado en un nmero pequeo de potentes ideas; incluso si tiene muchas propiedades especializadas, stas deberan explicarse como consecuencia de los conceptos bsicos. El gran plan debe estar visible y todo debera ocupar su sitio dentro de l. 1.10 Oportunidad

La oportunidad es una de las mayores frustraciones de nuestra industria. Un gran producto software que aparece demasiado tarde puede no alcanzar su objetivo. Esto es cierto en otras industrias tambin, pero pocas evolucionan tan rpidamente como el software.La oportunidad es todava, para grandes proyectos, un fenmeno poco comn. Cuando Microsoft anunci que la ltima versin de su principal sistema operativo, que llevaba realizando varios aos, saldra al mercado un mes antes de lo previsto, el suceso fue lo suficientemente relevante como para encabezar los titulares de Computer World. 1.11 Otras cualidades: Adems de las cualidades analizadas, existen otras que afectan a los usuarios de sistemas software y a la gente que compra estos sistemas o encarga su desarrollo. En particular: Verificabilidad: es la facilidad para preparar procedimientos de aceptacin, especialmente datos de prueba y procedimientos para detectar fallos y localizar errores durante las fases de validacin y operacin. Integridad: es la capacidad de los sistemas software de proteger sus diversos componentes (programas, datos, etc.) contra modificaciones y accesos no autorizados. Reparabilidad: es la capacidad para facilitar la reparacin de los defectos. Economa: junto con la oportunidad, es la capacidad que un sistema tiene de completarse con el presupuesto asignado o por debajo del mismo.

2. Sobre la documentacin:

En una lista de factores de calidad del software, uno podra esperar encontrar la presencia de una buena documentacin como uno de los requisitos. Pero ste no es un factor de calidad separado; la necesidad de documentacin es una consecuencia de otros factores de calidad vistos en el acpite anterior. Se pueden distinguir tres tipos de documentacin: La necesidad de documentacin externa, que permite a los usuarios conocer la potencia de un sistema y usarlo convenientemente, es una consecuencia de la definicin de facilidad de uso. La necesidad de documentacin interna, que permite a los desarrolladores de software comprender la estructura e implementacin de un sistema, es una consecuencia del requisito de extensibilidad. La necesidad de documentacin de la interfaz de un mdulo, que permite a los desarrolladores de software comprender las funciones proporcionadas por un mdulo sin tener que comprender su implementacin, es una consecuencia del requisito de reutilizacin. Tambin se desprende de la extensibilidad, ya que una documentacin de la interfaz de un mdulo permite determinar cundo cierto cambio afecta a un determinado mdulo.

En lugar de tratar la documentacin como un producto propio del software, es preferible producir software lo ms autodocumentado posible. Esto se aplica a los tres tipos de documentacin: Incluyendo facilidades de ayuda en lnea y siguiendo normas para interfaces claras y consistentes, se alivia la tarea de los autores de los manuales de usuario y de otras formas de documentacin externa. Un buen lenguaje de implementacin puede eliminar muchas de las necesidades de documentacin interna si favorece la claridad y la estructura. La notacin soportar la ocultacin de informacin y otras tcnicas para separar la interfaz de los mdulos de su implementacin. Ser posible entonces utilizar herramientas para producir automticamente documentacin de la interfaz del mdulo a partir del texto de los mdulos.

Metricas de calidad de software 1. METRICAS DE CALIDAD 2. ANTECEDENTES Para justificar la existencia de las mtrica, se argumenta que stas deben ser enunciadas y utilizadas para administrar el proceso de desarrollo y debe ser conforme al producto de software particular. Con la creacin de mtricas se pretende recopilar y actuar sobre las medidas cuantitativas de la calidad para la creacin del software. 3. OBJETIVO o Estas medidas deben ser utilizadas para los propsitos siguientes: Para recopilar informacin y reportar valores de mtricas sobre bases regulares., Para identificar el actual nivel de desempeo por cada mtrica. Para tomar la accin remedial si los niveles de las mtricas crecen peor o exceden los niveles objetivos establecidos. Para establecer metas de mejoras especificas en trminos de las mismas mtricas. 4. METRICAS: DEFINICION Son un conjunto de reglas generadas para la creacin de productos de software con calidad, que si se siguen correctamente pueden garantizar que el proyecto dar como resultado la satisfaccin del cliente.

Se usan para poder medir en trminos contables la calidad de los procesos en que se realiza dicho producto y evitar errores comunes. 5. Michael [99] define las mtricas de software como La aplicacin continua de mediciones basadas en tcnicas para el proceso de desarrollo del software y sus productos para suministrar informacin relevante a tiempo. Las mtricas de software proveen la informacin necesaria para la toma de decisiones tcnicas. 6. usos Las mtricas de software incluyen actividades, tales como: - Estimacin de costo y el esfuerzo - Medicin de la productividad - Acumulacin de datos - Realizacin de modelos y mediciones de la calidad - Elaboracin de modelos de seguridad - Evaluacin y modelos de desempeo - Valoracin de las capacidades y de la madurez - Administracin por mtricas - Evaluacin del mtodo y herramientas 7. CLASIFICACION La clasificacin de una mtrica de software refleja o describe la conducta del software. Variedad de mtricas: tales como portabilidad, facilidad de localizacin, consistencia. Existen pocas investigaciones dentro del rea. Las siguientes clasificaciones de mtricas fortalecen la idea, de que ms de una mtrica puede ser deseable para valorar la complejidad y la calidad del software. Mtricas de complejidad: Son todas las mtricas de software que definen de una u otra forma la medicin de la complejidad; Tales como volumen, tamao, anidaciones, costo (estimacin), agregacin, configuracin, y flujo. Estas son los puntos crticos de la concepcin, viabilidad, anlisis, y diseo de software. Mtricas de calidad: Son todas las mtricas de software que definen de una u otra forma la calidad del software; Tales como exactitud, estructuracin o modularidad, pruebas, mantenimiento, reusabilidad, cohesin del mdulo, acoplamiento del mdulo, etc. Estas son los puntos crticos en el diseo, codificacin, pruebas y mantenimiento.

Mtricas de competencia: Son todas las mtricas que intentan valorar o medir las actividades de productividad de los programadores o practicantes con respecto a su certeza, rapidez, eficiencia y competencia. No se ha alcanzado mucho en esta rea, a pesar de la intensa investigacin acadmica. Mtricas de desempeo: Corresponden a las mtricas que miden la conducta de mdulos y sistemas de un software, bajo la supervisin del sistema operativo o hardware. Generalmente tienen que ver con la eficiencia de ejecucin, tiempo, almacenamiento, complejidad de algoritmos computacionales, etc. Mtricas estilizadas: Son las mtricas de experimentacin y de preferencia; Por ejemplo: estilo de cdigo, identacin, las convenciones denominando de datos, las limitaciones, etc. Pero estas no se deben confundir con las mtricas de calidad o complejidad.

8. tipos Mtricas cuantitativas de la calidad del proceso de desarrollo y de liberacin. Estas mtricas deben de reflejar: Qu tan bien el proceso de desarrollo est siendo llevado a cabo en trminos de puntos de revisin y en objetivos de calidad en el proceso, siendo cumplidos en tiempo de calendario. Qu tan efectivo es el proceso de desarrollo, al reducir la probabilidad que se introduzcan fallas o que cualquier falla introducida sea detectada.

Mtricas del producto: Lo importante es que los niveles sean conocidos y utilizados para el control del proceso y de las mejoras y no sean utilizadas mtricas fijas. Las mtricas seleccionadas deben de ajustarse al proceso utilizado y si es posible, tener un impacto directo sobre la calidad de software liberado. Una medicin de prediccin es normalmente una mtrica de producto que puede ser utilizada para predecir el valor de otra mtrica. La mtrica es predicha, una mtrica de proceso, es conocida como una mtrica de resultado. Las mtricas tambin pueden ser categorizadas como mtricas de resultado o mtricas de prediccin. 9. Las mtricas de proceso de software: Se emplean para fines estratgicos, y mtricas del proyecto de software son tcticas, stas ltimas van a permitir proporcionar al desarrollador de proyectos del software una evaluacin al proyecto que sigue en continuo desarrollo, equivalentemente podr ver los defectos que logren provocar riesgos a largo plazo (reas problema); y observar si el rea de trabajo (equipo) y las distintas tareas se ajustarn. EL ASEGURAMIENTO DE LA CALIDAD Ante todo se debe conocer: Aseguramiento de la calidad: "Conjunto de acciones planificadas y sistemticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfar los requerimientos dados sobre calidad". Aseguramiento de la calidad de software: Conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto (software) satisfar los requisitos dados de calidad.

El aseguramiento de calidad del software se disea para cada aplicacin antes de comenzar a desarrollarla. Hay quienes prefieren decir garanta de calidad en vez de aseguramiento. La garanta, puede confundir con garanta de productos, mientras que el aseguramiento pretende dar confianza en que el producto tiene calidad. El aseguramiento de calidad del software est presente en: Mtodos y herramientas de anlisis, diseo, programacin y prueba.

Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo del software. Estrategias de prueba multiescala. Control de la documentacin del software y de los cambios realizados. Procedimientos para ajustarse a los estndares (y dejar claro cuando se est fuera de ellos). Mecanismos de medida (mtricas). Registro de auditoras y realizacin de informes.

Las actividades para el aseguramiento de calidad del software se detallan en: Mtricas de software para el control del proyecto. Verificacin y validacin del software a lo largo del ciclo de vida (Incluye las pruebas y los procesos de revisin e inspeccin). La gestin de la configuracin del software.

Algunos mtodos del aseguramiento: Revisiones tcnicas y de gestin (su objetivo es la evaluacin). Inspeccin (su objetivo es la verificacin). Estamos construyendo el producto correcto?. Pruebas (su objetivo es la validacin). Estamos construyendo el producto correctamente?. Auditorias (su objetivo es la confirmacin del cumplimiento).

Documentacin de programas.

LA DOCUMENTACIN DE
En la ejecucin de un proyecto informtico o un programa software se deben de seguir una serie de pasos desde que se plantea el problema hasta que se dispone del programa o

del a aplicacin funcionando en el ordenador.


Los pasos son los siguientes: Anlisis de factibilidad Anlisis de requerimientos Diseo del sistema

Validacin y

pruebas

Cada uno de estos pasos debe de llevar asociado un documento. Estos documentos son muy importantes ya que van a regir las fases del ciclo de vida del software y se recogen los pasos seguidos en cada fase para su ejecucin. No es viable la solucin mostrada por algunos programadores de ir directamente a la implementacin sin antes pararse en la fases 1, 2 y 3. Un trabajo deficiente en estas

fases supone una mala definicin del problema y por tanto el sistema no cumplir
seguramente con todos los requisitos. El diseo del sistema no ser efectivo y los errores sern de difcil solucin. Por lo tanto en la realizacin de las prcticas ser obligado cumplimentar un formulario que guiar al alumno en la fase de anlisis de requisitos y de diseo.

EL DOCUMENTO DE

Este documento tiene como objeto asegurar que tanto el desarrollador como el cliente tienen la misma idea sobre las funcionalidades del sistema. Es muy importante que esto quede claro ya que si no el desarrollo software no ser aceptable. En el caso de este curso, es importante que el alumno y el profesor tengan la misma idea de que hay que desarrollar en la prctica, si un alumno no desarrolla lo que el profesor espera no obtendr una nota adecuada con su expectativa. Por lo tanto es muy

importante que las especificaciones del problema estn claras por ambos.
Existe una normativa referente a este tipo de documento, en Ingeniera del Software I se os dar con ms detalle, aqu slo se intenta que se entienda el alcance e importancia de este documento. Segn la norma IEEE 830, un ERS debe contener los siguientes puntos: I. Introduccin (Se definen los fines y los objetivos del software)
Referencia del Descripcin Restricciones del

II. Descripcin de la informacin (Descripcin detallada del problema, incluyendo el HW y SW necesario)


Representacin del flujo de la Flujo de Flujo de Representacin del contenido de la Descripcin de la interfaz del

Descripcin funcional (Descripcin de cada funcin requerida, incluyendo diagramas)


Particin Descripcin Narrativa de Requisitos de Restricciones de Diagramas de Descripcin del 1. Especificacin del 2. Restricciones de IV. Descripcin

del comportamiento (comportamiento del SW ante sucesos externos y controles internos)


A. Estados del B. Sucesos y

V.

Criterios de validacin.
Lmites de Clases de Respuesta esperada del D. Consideraciones

Bibliografa VII. Apndice.


VI.

EL DOCUMENTO DE
En la fase de diseo se toman aquellas decisiones relativas a la futura implementacin,
se decide la estructura de datos a utilizar, la forma en que se van a implementar las distintas estructuras, el contenido de las clases (sus mtodos, los atributos, ...), los objetos. Tambin se definen las funciones, sus datos de entrada y salida, que tarea realizan, para alguna de especial inters el algoritmo que soluciona el problema. El flujo del programa se define mediante una serie de grficos que permiten visualizar cual es la evolucin del sistema software, en caso de orientacin de objetos existen el diagrama de clases, el diagrama de importante tenerlo claro para ello existen una serie de diagramas que permitan clarificar este asunto.

LA DOCUMENTACIN DEL CDIGO


Durante la fase de implementacin, cuando se est programando, es necesario comentar convenientemente cada una de las partes que tiene el programa. Estos comentarios se incluyen en el cdigo fuente con el objeto de clarificar y explicar cada elemento del programa, se deben de comentar las clases, las variables, los mdulos y en definitiva todo elemento que se considere importante. Esta documentacin tiene como objeto hacer ms comprensible el cdigo fuente a otros programadores que tengan que trabajar con l, ya sea porque forman parte del grupo de desarrollo, el programa va a ser mantenido o modificado por otra persona distinta al programador inicial. Tambin resulta muy til durante la depuracin y el mantenimiento del programa por el propio programador, al paso del tiempo las decisiones se olvidan y surgen dudas hasta en el propio programador de porqu se hicieron las cosas de una determinada manera y no de otra.

FORMULARIO DE

Antes del comienzo de cada prctica es necesario haber realizado un primer estudio del problema a resolver durante la sesin, para ello es obligatorio el cumplimentar este formulario. El objetivo del documento es asegurar que el alumno ha analizado la prctica y ha m adurado suficientemente el problema como para estar capacitado para afrontar la codificacin del programa. El documento a entregar es el siguiente: Descripcin del problema:

Restricciones del problema

Definicin de las clases Nombre de la Clase: Mtodos Pblicos Salida (Valor devuelto) Nombre del mtodo Entrada (argumentos)

Descripcin (Responsabiblidad):

Salida (Valor devuelto)

Nombre del mtodo

Entrada (argumentos)

Descripcin (Responsabiblidad):

Salida (Valor devuelto)

Nombre del mtodo

Entrada (argumentos)

Descripcin (Responsabiblidad):

Dependencias con otras clases(Colaboracin):

Atributos Nombre Descripcin

Organigrama del main

Funciones Descripcin:

Prototipo Entrada Descripcin: Salida

Prototipo
Entrada Descripcin: Salida

Prototipo Entrada Salida

Modelos de calidad de software


Existen varios modelos de calidad de software alguno de los cuales se detallan a continuacin:

El CMM - CMMI (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.

Los niveles CMM - CMMI son 5: Inicial o Nivel 1 CMM - CMMI. Este es el nivel en donde estn todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en l. Es el tpico proyecto en el que se da la siguiente situacin: Cmo va el proyecto? Bien, bien. Dos semanas despus Cmo va el proyecto? Bien, bien.

Tres semanas despus - El lunes hay que entregar el proyecto.- No se por qu pero los proyectos se entregan los lunes. El lunes !!?. Todava falta mucho!! Cmo? Me dijiste que el proyecto iba bien!! Arrglatelas como quieras, pero el proyecto tiene que estar terminado para el lunes.

Si no sabes el tamao del proyecto y no sabes cuanto llevas hecho, nunca sabrs cuando vas a terminar. . Quiere decir que el xito de los resultados obtenidos se puede repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento. Los procesos que hay que implantar para alcanzar este nivel son: Gestin de requisitos Planificacin de proyectos Seguimiento y control de proyectos Gestin de proveedores Aseguramiento de la calidad Gestin de la configuracin

Definido o Nivel 3 CMM - CMMI. Resumindolo mucho, alcanzar este nivel significa que la forma de desarrollar proyectos (gestin e ingeniera) esta definida, por definida quiere decir que esta establecida, documentada y que existen mtricas (obtencin de datos objetivos) para la consecucin de objetivos concretos. Los procesos que hay que implantar para alcanzar este nivel son: Desarrollo de requisitos Solucin Tcnica Integracin del producto Verificacin Validacin Desarrollo y mejora de los procesos de la organizacin Definicin de los procesos de la organizacin Planificacin de la formacin Gestin de riesgos Anlisis y resolucin de toma de decisiones

La mayora de las empresas que llegan al nivel 3 paran aqu, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir ms all porque tienen cubiertas la mayora de sus necesidades. Cuantitativamente Gestionado o Nivel 4 CMM - CMMI. Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organizacin. Se usan mtricas para gestionar la organizacin. Los procesos que hay que implantar para alcanzar este nivel son:

Gestin cuantitativa de proyectos Mejora de los procesos de la organizacin

Optimizado o Nivel 5 CMM - CMMI. Los procesos de los proyectos y de la organizacin estn orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante mtricas son identificadas, evaluadas y puestas en prctica. Los procesos que hay que implantar para alcanzar este nivel son: Innovacin organizacional Anlisis y resolucin de las causas

Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultneamente ya que estn muy relacionados. A grandes rasgos se ha intentado introducir el modelo de calidad del software CMM CMMI para aquella gente que se encuentra por primera vez con l. La implantacin de un modelo de estas caractersticas es un proceso largo y costoso que puede costar varios aos de esfuerzo. Aun as el beneficio obtenido para la empresa es mucho mayor que lo invertido. CMM (Capability Maturity Model) Desarrollado por SEI (Software Engineering Institute), org. creado por el DoD de USA. Fuerte impacto en mejora del proceso. Estipula un Camino para la mejora. Areas Clave que se deben atacar. Estructura del modelo CMM: