You are on page 1of 20

Cul es el objetivo final de aplicar un estndar como CMMI en una empresa software?

El objetivo final es la evaluacin de la madurez de los procesos de la empresa. A partir de aqu se puede definir un plan de mejora y re-evaluar. CMMi no indica cmo se tienen que llevar a cabo los procesos si no que evala los objetivos y prcticas de la empresa, esto permite ver donde se tiene que mejorar. El origen de la aplicacin de CMM lo encontramos en la administracin de defensa de los EE.UU que peda un nivel de madurez determinado segn el tipo de proyecto que quera contratar. Crees que el estndar CMMI se puede aplicar a cualquier empresa de software? Por qu? El estndar est pensado por empresas que contienen los procesos de desarrollo, adquisicin y mantenimiento de productos o servicios. Por lo tanto, cualquier empresa que contenga algn de estos procesos puede aplicar CMMi. CMMi permite una aplicacin por etapas (staggered) y por procesos, el que quiere decir que una empresa puede tener algunos procesos en un nivel y otros en otro. Todas las empresas que quieran dar un servicio profesional y un mnimo de calidad tienen que definir y estandarizar sus procesos, la medida de la empresa no tiene que ser nunca un impedimento. El que no hace falta es que todas las empresas estn a nivel 5.

Mdulo 1 Gestin de la calidad del software


Qu es la calidad del software? O Qu significa que un software tiene calidad? El software desarrollado tendr que cumplir unos requisitos especficos pactados previamente con el cliente y que nos servirn para medir la calidad. Un producto es de calidad si tiene las caractersticas siguientes: Cubre sus necesidades funcionales Funciona correctamente y no tiene errores La entrega se hace en el tiempo previsto Es fcil de utilizar Dispone de un buen manual de usuario El trato por parte del proveedor ha sido correcto, ha entendido lo que se pretenda y se ha hecho un seguimiento adecuado. Tiene un buen servicio de mantenimiento y actualizaciones

Mejora de procesos
Las micromejoras son la base para la puesta en marcha de un proyecto de mejora de procesos. Las etapas bsicas en la mejora de procesos es: Empezar la mejora en un solo proyecto o en un solo equipo de trabajo. Escoger aquel con ms probabilidad de xito. Dentro de este proyecto, escoger un proceso cualquiera (captura de requisitos, una forma determinada de documentar el diseo). Normalmente se escoger aquel en el que hace tiempo queramos introducir una mejora. Ponemos en marcha de manera planificada y organizada esta mejora Nombramos a un responsable, un tiempo de implantacin y, sobre todo, aclaramos qu objetivos perseguimos. Una vez obtenido los resultados de esta primera micromejora en un proceso y un proyecto determinado obtendremos qu beneficios hemos obtenido y qu dificultades se nos han planteado. Con toda esta informacin y experiencia, podemos implantar la misma mejora en otro proyecto. En este segundo proyecto, la micromejora ser mucho ms sencilla ya que tendremos una experiencia previa. 1

El paso siguiente ser comparar los resultados entre los diferentes proyectos y recopilar una experiencia que nos ayudar a evaluar cmo lo estamos llevando a cabo. A continuacin podemos describir el procedimiento de trabajo en un documento, de manera que cualquier persona que lo desee lo puede leer y ponerlo en marcha en su proyecto.

La comunicacin es fundamental para llegar a buen puerto. Tenemos que explicar, clarificar y justificar por qu lo hacemos y cmo lo hacemos; y hemos de comunicrselo a los jefes, a los usuarios de la aplicacin, al equipo de desarrollo; y debemos comunicarnos de manera fluida, escueta, concisa y continuada. En general, las mejoras no darn un fruto palpable o medible enseguida y puede pasar que en un primer momento slo se aprecia un coste de tiempo adicional y que no se valore a largo plazo lo que esta inversin temporal inicial puede ahorrar en tiempo y dinero; ello hace que la comunicacin sea fundamental para intentar despejar estas dudas.

El estndar CMM
El objetivo del CMM es ayudar a las organizaciones de software a mejorar el nivel de madurez de sus procesos para que sigan un camino que evolucione desde el proceso catico al proceso organizado. CMM se basa en el conjunto de la organizacin de software, en cambio el estndar SPICE basa todo su anlisis en los procesos individuales. El estndar CMM clasifica los niveles de la manera siguiente: Nivel 1: inicial. El proceso de desarrollo de software es catico; hay pocos procesos definidos y el xito radica en la capacidad y esfuerzo individual. Nivel 2: repetible. Se establecen algunos procesos bsicos de gestin para hacer un seguimiento de costes, calendario y funcionalidad Nivel 3: definido. El proceso est documentado, estandarizado e integrados en los procesos globales de la compaa. Nivel 4: gestionado. Hay una recopilacin de medidas detallada sobre el proceso de desarrollo de software y la calidad del producto. Nivel 5: optimizado. Hay un proceso de puesta en marcha en marcha de mejoras de manera continuada basado en los resultados cuantitativos del proceso y en las pruebas piloto.

4. Puesta en marcha de la mejora de procesos


Hay tres aspectos, o tres fases, para poner en marcha la mejora de procesos. Estos sn: 1) el punto de partida 2) la definicin de una estrategia 3) el plan de accin

5. Plan de accin
El plan de accin se definir despus de haber hecho un buen anlisis del punto de partida y la estrategia.

5.1 El plan de calidad


El plan de calidad se tiene que empezar a pensar y escribir en el momento en el que se aprueba el lanzamiento de un proyecto.

Cada proyecto ser diferente dependiendo de los aspectos que hayamos resaltado en el anlisis del punto de partida, pero en general, el plan de calidad, tiene que incluir todo aquello que sea necesario para llevar a cabo el proyecto de manera correcta. Un plan de calidad puede incluir: Plan de proyecto Control de configuracin Control de cambios Anlisis y gestin de riesgos Plan de verificacin funcional Plan de calidad en la construccin Auditora externa Los tres primeros puntos (plan de proyecto, control de configuracin y control de cambios) corresponden a tareas especficas en la gestin de proyectos. Todo lo que se detalle en un plan de calidad tiene que estar en conocimiento de todo el equipo de desarrollo. Escribir un plan de calidad es definir una manera de trabajar que todo el mundo tendr que conocer, por lo tanto, tendremos que comunicarlo convenientemente y asegurarnos que todo el mundo lo entiende. Asimismo, puede ser interesante hacer auditoras internas para verificar que todo el mundo lo ha entendido, sabe lo que tiene que hacer y lo aplica en el da a da.

Anlisis y gestin de riesgos


Como el tiempo y los recursos son limitados, no podemos verificar el 100% del funcionamiento y la calidad del software que desarrollamos, por lo que, por dnde empezamos, y qu dejamos de verificar? Tenemos que empezar por aquellas reas de desarrollo que tienen un riesgo ms elevado y, por lo tanto, son ms crticas. A continuacin, tenemos que ser capaces de llevar a cabo la gestin de estos riesgos de manera que los tengamos bien numerados, descritos y ordenados.

Verificacin funcional y verificacin en la construccin


Las diferencias de cada uno son: La verificacin funcional tambin se denomina black box y es todo lo que se verifica sin saber qu hay dentro del programa (cdigo, diseo, lenguaje utilizado). Es todo lo que podra verificar un usuario de la aplicacin sin ningn conocimiento de informtica. La verificacin en la construccin se suele llamar white box y es todo lo que se verifica desde un punto de vista tcnico. En general, es todo lo que el cliente o usuario no nos pide explcitamente, pero que todos sabemos que es tan importante, ya que son los fundamentos del programa. Esta verificacin la tiene que llevar a cabo un informtico experto.

Verificacin funcional
Los objetivos de la verificacin funcional son: Que el producto implementa la funcionalidad pedida Que el programa funciona correctamente sin errores Que la aplicacin es suficientemente rpida y fcil de utilizar Que el cliente se lleve una buena impresin. Las personas que lleven a cabo esta tarea tienen que ser buenas conocedoras del funcionamiento de la aplicacin y de las necesidades funcionales del cliente o usuario. Idealmente, podran ser un grupo de usuarios, como participantes en el equipo de desarrollo, 3

que aportaran al equipo un punto de vista diferente. Es decir, se podra escoger a un grupo de personas no muy numeroso, de entre el grupo de usuarios de la aplicacin, con mucha experiencia en su rea de trabajo y con buena capacidad de comunicacin para que se integraran como participantes en el equipo de desarrollo. Esta prctica representa un ventaja tan importante que resulta conveniente llevarla a cabo, ya que es la manera que los usuarios se sientan parte del desarrollo, entiendan las dificultades del proyecto y, en definitiva, hagan suyo el proyecto para dejar de ser la parte contraria. El equipo de verificacin funcional puede llevar a cabo las acciones siguientes: Revisin de los requisitos de usuario: ver que son completos (no falta nada importante), correctos (no haya errores de interpretacin), consistentes (sean coherentes y no haya contradicciones) y definidos (se puedan testear). En caso que sean prototipos, el equipo de verificacin funcional ser el encargado de valorar el prototipo y darle el visto bueno. Determinacin del plan de verificacin funcional: tiene que permitir transmitir informacin cuantitativa sobre el nivel de calidad, el estado de un proyecto y, por lo tanto, el nivel de riesgo que se asume. Este ejercicio todava nos dar ms informacin cuando se haya llevado a cabo varias veces, porque conoceremos los resultados de las experiencias anteriores y nos permitir compararlos. Casos de prueba y su gestin: Un test o caso de prueba es un listado de acciones que, de manera ordenada y organizada, permite ir probando todos y cada uno de los casos con los que el programa se podr encontrar cuando se ejecute en el entorno real. Algunos tipos de test serian los siguientes: o Test bsico funcional: prueba de unos requisitos determinados o Test de calificacin funcional general: asegurar el buen funcionamiento de la aplicacin. o Test de rendimiento o Test de carga: el software funciona correctamente en condiciones anormales (carga de trabajo extrema, recursos compartidos) o Test de usabilidad: asegurar la consistencia y la facilidad de la interfaz de usuario. o Test de seguridad en el acceso a datos o Test de instalacin o Test de volumen de datos Ejecucin de los casos de prueba: ejecutar los casos de prueba significa llevas a cabo las siguientes acciones: o Determinar la versin del programa sobre la cual se pasar el test o Preparar la plataforma necesaria para llevarlo a cabo: hardware, software y base de datos o Ejecutar la aplicacin siguiendo detalladamente los pasos que se definen en el caso de prueba o Anotar las incidencias. Gestin de errores: Los errores detectados en la ejecucin de los casos de prueba se listarn en una base de datos donde tambin se anotar la informacin ms relevante. Congelacin de cdigo: Una vez sepamos cul es la fecha de entrega de la aplicacin, tendremos que definir una fecha anterior (depender del tamao del programa, por ejemplo podra ser de un mes) como fecha de congelacin de cdigo. A partir de aquel momento ya no se pueden introducir funcionalidades nuevas, mejoras o cambios en el programa; slo estar permitido tocar el cdigo para arreglar errores. En caso de que durante este intervalo de tiempo sea imperativo modificar el cdigo, se tendr que

aprobar explcitamente, y todo el mundo tendr que aceptar que existe el riesgo de introducir errores. Aplicaciones de Internet: Todo lo dicho anteriormente es igualmente vlido para aplicaciones en Internet, pero hay que aadir adems pruebas especficas dado que hay menos herramientas para verificar este tipo de aplicaciones y la complejidad de las mismas. Habr que realizar test de compatibilidad (entre equipos, sistemas operativos y navegadores), test de navegacin, de interaccin, de carga.

Verificacin en la construccin
El objetivo principal de la verificacin en la construccin es asegurar la calidad de todo aquello que no se ve en el producto de software, pero que todos sabemos que es sumamente importante. Con la verificacin en la construccin queremos conseguir garantizar que la aplicacin en general estar bien construida por dentro, es decir, ser fcil de mantener, robusta y flexible ante cambios de requisitos. Las acciones que incluye esta verificacin son: 1) revisar la arquitectura y el diseo, para asegurarnos que son completos, correctos y consistentes. 2) Certificar un proceso en la construccin, asegurarse que se sigue uno definido y adecuado. 3) Constatar unos estndares de codificacin, asegurarse que se siguen unos concretos. 4) Revisar el cdigo, con el objetivo de encontrar errores. 5) Test de integracin peridico (diario, semanal) para asegurar que los diferentes componentes que configurar el software desarrollado encajan perfectamente. 6) Verificar el test, verificar que el test unitario sigue unas pautas en todo el equipo de desarrollo. 7) Incluir el uso de herramientas que permita conocer el porcentaje de lneas de cdigo testeadas por medio del test unitario: cobertura

Mtricas
Tanto el plan de verificacin funcional como el de la construccin nos tienen que permitir obtener datos cuantitativos, objetivos y comparables que nos darn informacin sobre la evolucin de nuestra manera de trabajar y nos aportarn conclusiones que nos servirn para la mejora de procesos. Cualquier mtrica que queramos calcular tiene que ser fcil de obtener, objetiva y comparable en varios proyectos. Por lo tanto, es necesario que haya una uniformidad en la recogida de datos en toda la organizacin. Las mtricas no servirn para medir el rendimiento de las personas, sino para mejorar los procedimientos de trabajo.

Auditoras externas
La calidad de los elementos con los que hemos verificado la calidad en la construccin como la verificacin funcional, pueden condicionar la calidad final de nuestro producto. Por ello es importante comprobar la solidez de la empresa que ha desarrollado estas herramientas de verificacin, contactar con otras empresas que las utilicen para saber su grado de satisfaccin y contactar con la empresa fabricante para conocer sus planes de desarrollo futuros.

Mdulo 2 Gestin de la configuracin del software


1. Conceptos bsicos
Los elementos principales de la Gestin de la Configuracin del Software (GCS) son identificacin, control de cambios, control del estado y auditoras. Con una buena gestin de la configuracin del software se busca poder conocer en cualquier momento el estado de cada uno de los componentes de un sistema, cmo se ha llegado a stos, por qu han sido modificados y quin lo ha hecho. La gestin de configuracin es un elemento bsico para garantizar la calidad de los proyectos. Un elemento de configuracin (EC) es un producto generado durante el desarrollo de un proyecto o una pieza de cdigo que se trata como una nica entidad desde el punto de vista de la gestin de la configuracin. Podemos distinguir elementos de configuracin bsicos, que son atmicos y no se pueden dividir, y que tambin denominamos componentes (productos finales generados por el proyecto: programas, un fichero del manual de usuario) , y elementos de configuracin formados por un conjunto de elementos bsicos, que tambin denominamos agregados (todo el sistema, o un subsistema ms o menos independiente del mismo) La configuracin de un proyecto es el conjunto de caractersticas funcionales y fsicas del software, descritas en la documentacin e implementadas en los programas que se quieren controlar. Una versin identifica el estado de un elemento de configuracin en un momento definido en el tiempo. Distintas versiones de un mismo elemento se diferencian por la correccin de un error, un cambio de funcionalidad, etc. El control de versiones es el procedimiento para identificar y gestionar los elementos de configuracin a medida que cambian con el tiempo, normalmente con una herramienta especializada. La Lnea base es un conjunto de elementos de configuracin que han sido revisados y aprobados formalmente por la direccin y/o el cliente, y que sirve de base para el desarrollo posterior del proyecto. Los elementos que estn en la lnea base slo se pueden modificar si se ha seguido un procedimiento formal de gestin de cambio. No todas las versiones de un EC han de formar parte en algn momento de la lnea base. Puede haber distintas versiones de un documento de especificaciones antes de disponer de la versin definitiva aprobada por el cliente, que ser la que formar parte de la lnea base.

Una peticin de cambio es una solicitud formal para cambiar uno (o ms de uno) elementos de configuracin de la lnea base. Una peticin de cambio se puede iniciar por distintos motivos (deteccin de errores, cambios de requisitos en el proyecto, cambios en el diseo) y la puede originar tanto el cliente como un miembro del equipo de desarrollo. Las peticiones de cambio se deben tratar formalmente. Esto implica que hay que analizarlas, estudiar su impacto en el proyecto y aceptarlas, rechazarlas o aparcarlas hasta otro momento, documentando las razones de la decisin que se ha tomado. Una promocin es una versin que se pone a disposicin de los otros participantes del proyecto. Cuando un EC se encuentra en un estado estable, se distribuye para que el resto de involucrados en el proyecto lo puedan utilizar y revisar. Una distribucin es una versin que se pone a disposicin del cliente final. Hacer una distribucin de un EC implica que este elemento ha pasado las pruebas y controles de calidad y que los clientes o usuarios lo pueden probar y/o utilizar. Un caso tpico es la distribucin de versiones beta. Una librera es el espacio fsico en el que se almacenan los elementos de configuracin elementales con el conjunto de funcionalidades que permiten nombrar e identificar las distintas versiones de los elementos de configuracin y controlar el estado de los cambios en estos elementos. Como mnimo encontramos las libreras siguientes: Entorno de desarrollo: se utiliza para desarrollar el proyecto Librera pblica: donde se controlan las promociones. Cuando un EC est listo para ser promocionado, se pasa del entorno de desarrollo a la librera pblica. Repositorio: librera en la que se controlan las distribuciones. Cuando un EC est listo para ser distribuido, se pasa de la librera pblica al repositorio. Los cambios en el repositorio deben estar controlados. Es recomendable que haya un procedimiento definido de cmo se tiene que hacer la distribucin.

2. Actividades de la gestin de la configuracin


Tradicionalmente, se han identificado las actividades siguientes como bsicas para la gestin de la configuracin: Identificacin. Reflejo de la estructura del producto final que se quiere construir e identificacin de los elementos que lo componen y sus tipos. Control de cambios. Control de los cambios en las promociones, distribuciones y cualquier otra librera que se haya definido para el proyecto. Control del estado de la configuracin. Registro de todos los cambios producidos y su razn e informacin del estado de los elementos de configuracin en cualquier momento. Auditoras. Validacin de que los productos estn completos y de la consistencia entre todos los componentes que los forman. Manufactura. Creacin de un producto de manera ptima. 7

Gestin del proceso. Evaluacin de los procedimientos utilizados para llevar a cabo las actividades de la GCS, y estudio de cmo mejorarlos.

2.1 Identificacin
La funcin bsica de un sistema de gestin de la configuracin es la identificacin de los elementos de configuracin. Se tienen que identificar los elementos siguientes: Los tipos de elementos bsicos que formarn parte del proyecto y el sistema de nomenclatura que se utilizar para identificar cada elemento. El tipo de versin que se utilizar. Las libreras en las que se almacenarn las diferentes versiones de los elementos de configuracin. Los elementos agregados sobre los cuales se quiere mantener un control de versiones y de inclusin en la lnea base. La nomenclatura de estos elementos y el sistema que se utilizar para mantener su composicin (saber qu elementos bsicos la integran). 2.1.1 Tipos elementos bsicos Normalmente, los elementos que han de estar bajo la gestin de la configuracin son, como mnimo, los documentos de requisitos del proyecto (son la base para el desarrollo del proyecto) y todo el cdigo fuente que se genera. 2.1.2 Elementos de configuracin Al inicio del proyecto hay que definir cules sern los elementos bsicos y agregados sobre los cuales se quiere tener control de cambios. Desde el inicio del proyecto tambin se identifica la estructura del sistema. Esta estructura proporciona la jerarqua de los elementos de software en la que el sistema se descompone y permite identificar sus elementos. Podemos representar la estructura del sistema como un rbol. Se empieza con el sistema objetivo que se quiere construir. Este sistema se divide en grandes subsistemas. Cada subsistema se divide en otros hasta llegar a los mdulos elementales, que implementan funciones bsicas. La nomenclatura utilizada para clasificar la descomposicin del sistema depende de su organizacin. Aqu utilizamos los trminos sistema, subsistema, aplicacin, componente y mdulo. El sistema es el resultado final del proyecto y est formado por subsistemas. Un subsistema se divide en aplicaciones. Esta descomposicin puede tener distintos niveles hasta llegar a los elementos bsicos. Al inicio del proyecto no se puede alcanzar un desglose completo, pero s que es necesario identificar los grandes subsistemas y las aplicaciones que formarn el sistema y decidir cules se identifican como elementos de configuracin agregados. La estructura del rbol define los elementos de configuracin agregados sobre los cuales se quiere mantener control. 2.1.3 Versiones y ramas 8

Los elementos de configuracin evolucionan con el tiempo y normalmente es importante mantener distintas versiones de un mismo elemento. Definir un sistema de versiones implica definir la manera de identificar cada versin de un elemento y adems el modo de asegurar que en cada momento se trabaja con la versin correcta y que no se modifica accidentalmente una versin inadecuada. Un sistema muy utilizado para esta identificacin consiste en dos nmeros separados por un punto; el primero indica la versin y slo se incrementa cuando se le hacen grandes modificaciones funcionales; y el segundo indica la revisin, que se incremente cuando se hacen pequeas mejoras o correcciones del sistema. Hay situaciones en las que es necesario hacer un desarrollo en paralelo, es decir, que dos personas o grupos diferentes modifiquen un mismo elemento al mismo tiempo; esta situacin puede causar problemas, ya que es fcil perder informacin si no se trata con precaucin. En el caso de un desarrollo en paralelo es necesario definir un procedimiento para fusionar las dos ramas de forma no traumtica. 2.1.4 Lneas Base Hay puntos durante el desarrollo del proyecto en los que ciertos EC se aprueban y se dan por finalizados. En este punto, hay que congelar estos elementos. Esto quiere decir que la versin aprobada no se puede modificar bajo ningn concepto, a no ser que haya una peticin de cambio formal. Cuando un elemento est en este estado, se dice que se incorpora a la lnea base del proyecto. Es importante saber en todo momento cmo est formada la lnea base. Qu elementos se le han incorporado, quin los ha incorporado, etc. Para mantener este conocimiento, es importante definir un procedimiento. Este procedimiento suele definir quin puede aprobar el elemento (darlo por acabado), cmo se registra la aprobacin (con un documento, un correo, est automatizada, etc.), quin puede incorporar el elemento a la lnea base, etc. Lo importante es seguir un buen procedimiento en lo que respecta a cmo y cundo se incorporan elementos a la lnea base, ya que su mantenimiento correcto asegura la coherencia entre todos los EC del proyecto. Hay que remarcar que no todas las versiones de un EC se colocan en la lnea base en algn momento de la vida del proyecto. La lnea base incluye la parte del proyecto desarrollada y aprobada. Todos los cambios que se hagan sobre EC que estn en la lnea base deben estar controlados y registrados.

2.2 Control de cambios


2.2.1 Gestin de cambios La gestin de cambios es el conjunto de tareas para controlar las modificaciones que se hacen sobre los elementos de configuracin que estn en la lnea base, de manera que siempre se garantice la integridad entre los productos desarrollados. La gestin de cambios permite mantener un conocimiento de la evolucin del sistema. Adems, ofrece la garanta de que todos los implicados en el proyecto estn informados de los cambios y de acuerdo con ellos 9

Los cambios no son exclusivos de la etapa de mantenimiento, tambin se producen durante el desarrollo, y es importante registrar y controlar unos y otros. El esquema de una peticin de cambios es el siguiente: Generar peticin: el proceso se inicia con una peticin de cambio. Una peticin se puede originar por diferentes causas: cambio de una funcionalidad, correccin de un mal funcionamiento detectado en el cdigo, etc. El originador de la peticin debe documentarla e introducirla en un sistema de gestin de cambios definido con este propsito. El sistema de gestin de cambios puede ser manual o mecanizado, pero en cualquier caso es necesario e importante que la peticin quede registrada. Analizar peticin: La peticin ha de ser analizada para evaluar su impacto en el proyecto. Como resultado de la evaluacin, hay que proporcionar informacin que permita tomar una decisin. El resultado del anlisis se puede incluir en el mismo documento que la peticin. Evaluar el impacto: El grupo responsable de controlar los cambios estudia el resultado del anlisis y decide si la peticin es aceptada o no. Registrar la resolucin: Tanto si la peticin ha sido aceptada como si no, hay que actualizarla y registrar la resolucin tomada. Introducir en el sistema de mantenimiento/desarrollo: En caso de aceptacin, la peticin puede seguir dos itinerarios: Si se trata de un mantenimiento, se introduce en el sistema de mantenimiento, desde donde se asignar su desarrollo. Al introducirla, se aadir informacin sobre a quin se asigna y la fecha de cierre estimada. Si se trata de una modificacin a un proyecto en curso, seguir el procedimiento definido para introducir cambios en el proyecto. En caso de no aceptacin, la peticin se archiva y se indica si se ha denegado definitivamente o si queda pendiente de una nueva evaluacin. Notificar la resolucin al originador de la peticin: El generador de la peticin debe recibir una notificacin de la resolucin que se ha tomado. Monitorizar: A partir del momento en que se acepta un cambio, su estado se debe monitorizar hasta que finaliza su desarrollo y se incorpora a la lnea base.

2.3 Estado de la configuracin


El objetivo de controlar el estado de la configuracin es proporcionar a la direccin del proyecto visibilidad del estado en el que se encuentran los EC y, por lo tanto, del estado del proyecto. Una parte importante de esta informacin son las mtricas, que hay que definir de manera que los resultados obtenidos proporcionen informacin sobre el estado del proyecto y permitan tomar las decisiones acertadas. Ejemplos de mtricas: - Medir cuntos EC se han terminado. Da informacin sobre el estado del proyecto. 10

Medir cuntas peticiones de cambio hay para cada EC por una unidad de tiempo (mes, trimestre, etc.). Da informacin sobre la evolucin del proyecto: un nmero elevado de peticiones de cambios puede indicar que hay EC poco estables y que quiz su diseo no fue lo bastante bueno, o que las peticiones son para modificaciones muy pequeas.

2.4 Auditoras
Peridicamente se deben hacer auditoras para comprobar que se estn siguiendo rigurosamente todos los procedimientos definidos para controlar la configuracin y que los productos se estn desarrollando segn los requisitos y los estndares definidos. Las auditoras las pueden hacer tanto personas externas al equipo de desarrollo como personal interno con responsabilidades de gestin de la configuracin asignadas. Hay varios tipos de auditoras: Funcionales: Comprueban que los productos finales (el sistema que se entregar) cumplen todos los requisitos del proyecto. Fsicas: Comprueban que el diseo y los documentos, como por ejemplo los manuales de usuario, de mantenimiento o instalacin, son consistentes. Internas: Son ms informales y se hacen durante el desarrollo, antes de las auditoras funcionales o fsicas. Su objetivo es evitar que se propaguen errores e inconsistencias, dado que detectan los problemas durante el desarrollo. Se acostumbran a hacer sobre partes del proyecto y no hay que esperar a finalizar una fase para llevarlas a cabo. Trazabilidad: comprueban que para cualquier producto final, se puede encontrar el requisito o requisitos que lo han originado. Esto se hace para evitar la introduccin en el sistema de requisitos no documentados. Muchas veces, a causa de las prisas y las presiones, aunque haya un buen control de cambios, hay cambios que quedan indocumentados. Al acabar el proyecto y antes de entregar el sistema al cliente, se deben hacer una auditora funcional y otra fsica, para comprobar la calidad de los productos.

2.5 Manufactura
Se entiende por manufactura el proceso de crear el sistema que se debe entregar al cliente final, a partir de todos los componentes que lo integran. Dicho de otro modo, el proceso de manufactura consiste en generar una distribucin que se crear a partir de la lnea base que est en la librera de archivos de produccin.

3. Roles y responsabilidades en la gestin de la configuracin


Los roles ms importantes, son los siguientes: Gestor de la configuracin Junta de Control de Cambios (SCCB, del ingls software change control board) Miembro del equipo de desarrollo Auditor Administrador de herramientas Responsable de calidad A continuacin se explican ms detalladamente: Gestor de la configuracin

11

Tiene la responsabilidad de llevar a cabo las actividades relacionadas con la gestin de la configuracin del proyecto. Desarrolla, documenta y distribuye los procedimientos de la gestin, establece el sistema de lneas base y backup, asegura que en la lnea base estn incorporados los elementos necesarios y solo se hacen cambios autorizados. El rol de gestor de la configuracin es imprescindible. En los proyectos pequeos, puede ser asumido por el jefe de proyecto u otra persona del equipo. Lo importante es que todos los que estn involucrados en el proyecto sepan quin asume el rol, y que la persona que lo asume haga las tareas que le corresponden. Junta de Control de Cambios Grupo de personas que controlan la configuracin de un proyecto. Son los responsables de evaluar, aprobar o rechazar los cambios solicitados sobre los elementos clave.

La junta de control de cambios debe asegurar que todos los cambios solicitados se analizan y evalan antes de que se tome una decisin sobre su viabilidad, y que todos los afectados por un posible cambio reciben una notificacin de la decisin tomada antes de que se ejecute. Miembro del equipo de desarrollo Todos los miembros del equipo de desarrollo participan directamente en la gestin de la configuracin. Sus tareas son la de seguir los procedimientos definidos por la gestin de configuracin, solicitar la inclusin de los elementos que han creado o modificado en la lnea base cuando corresponda, coordinar correctamente el trabajo en paralelo sobre un mismo mdulo y utilizar siempre las versiones de lnea base como punto de partida para hacer las modificaciones. Auditor Cumple el calendario de auditoras establecido al principio del proyecto, sigue los procedimientos definidos para la realizacin de las auditoras, asegura que los productos cumplen los estndares definidos, as como que el sistema final cumple los requisitos definidos al principio del proyecto, genera los informes con los resultados de las auditoras y comprueba la consistencia entre los elementos de configuracin. Administrador de herramientas El administrador de herramientas es la persona responsable de la administracin y el mantenimiento de las herramientas utilizadas para la gestin de la configuracin, si las hay. Responsable de calidad El responsable de calidad es la persona o el grupo de personas que deben definir el plan de calidad de un proyecto y asegurar su cumplimiento durante el desarrollo de un proyecto y el mantenimiento posterior de los productos generados. Sus tareas incluyen: planificar, junto con el jefe de proyecto, las revisiones formales que se harn durante el proyecto; hacer revisiones formales respecto de la utilizacin de los procedimientos definidos en la gestin de la configuracin y registrar las no conformidades; hacer un seguimiento de las no conformidades hasta su resolucin y redactar los informes de calidad con respecto a la utilizacin de la gestin de la configuracin. La funcin del responsable de calidad es comprobar si se utilizan los procedimientos y transmitir la informacin necesaria para que los responsables de los procedimientos puedan evaluar las necesidades de mejora. 12

4. Gestin de la gestin de la configuracin


4.1 Plan de la gestin de la configuracin
Al inicio de un proyecto se escribe el plan de la gestin de la configuracin, en que se documenta la manera de llevar a cabo la GCS (gestin de la configuracin del software). Todos los implicados en el proyecto, mientras dura su desarrollo, pueden acudir a este documento para conocer el proceso que seguir la gestin de la configuracin.

4.2 Modelo de datos para la gestin de la configuracin


Junto con el plan de la gestin de la configuracin, es importante definir un esquema de base de datos para mantener actualizada la informacin referente a la configuracin. Entre las funciones de esta base de datos, destacamos las siguientes: - Proporcionar informacin que ayude a hacer un buen anlisis de impacto de una peticin de cambio. - Proporcionar informacin para conocer el estado de la configuracin.

5. Herramientas para la gestin de la configuracin


Actualmente podemos encontrar en el mercado muchas herramientas que ofrecen algn tipo de apoyo a la gestin de la configuracin. Frente a tanta oferta, es importante tener algunos criterios que ayuden a evaluarlas, segn las necesidades y el tipo de proyectos. Caractersticas Las caractersticas que este tipo de herramientas deben tener son varias: Robustez: Debe ser fiable (correcto funcionamiento del sistema), consistente (mantiene la informacin de manera coherente). Funcionalidad: Capacidad de definir una base de datos a medida para cada proyecto, con un buen control de versiones y de ramas y de las peticiones de cambio. Usabilidad: Buena interfaz de usuario, adaptable, con ayuda interactiva y documentacin escrita. Facilidad de administracin: fcil de instalar y actualizar. Facilidad de integracin: con distintas plataformas e incluso con otros programas que ayuden a la gestin de la configuracin. Disponibilidad comercial: calidad del servicio y penetracin de la empresa en el mercado. Capacidad para extraer mtricas. Si se quiere tener xito en la implementacin de una buena gestin de la configuracin, elegir una buena herramienta es necesario, pero no suficiente. Antes hay que estudiar las necesidades de la organizacin desde el punto de vista de su complejidad tcnica. Hay que considerar aspectos como, por ejemplo, la cantidad de software que la herramienta ha de manejar, las plataformas sobre las cuales se quiere mecanizar, las interfaces con otras herramientas que se necesitan, etc.

13

Mdulo 3 Mantenimiento del software


Definimos mantenimiento del software como el conjunto de actividades que gestiona los cambios que se producen en el software informtico cuando ya se ha entregado al usuario (o al cliente que ha originado la demanda) para garantizar su funcionamiento correcto y el alcance de los objetivos definidos desde el principio hasta el final de la utilizacin. Entre las razones que justifican el mantenimiento del software, destacamos las siguientes: Corregir los errores del sistema. Mejorar el diseo del sistema. Migrar el software de una plataforma a otra. Crear interfaces con otras aplicaciones o sistemas. Actualizar o ampliar la capacidad de la base de datos del sistema. Introducir cambios o mejoras en el sistema. Mejorar el rendimiento del sistema.

1. Tipos de mantenimiento del software


El mantenimiento del software se puede clasificar en los siguientes tipos: 1) Correctivo: modifica el software para corregir los errores. 2) Adaptativo: modifica el software para adaptarlo al entorno externo cambiante. 3) Perfectivo: modifica el software para mejorar su comportamiento y ampliar sus funcionalidades originales. 4) Preventivo: modifica el software para que se pueda corregir, adaptar y mejorar de una manera ms fcil.

1.1 Mantenimiento correctivo


El mantenimiento correctivo es un proceso de diagnosis y correccin, de accin y reaccin: ante un error (accin) se pone en marcha el proceso de intentar solucionarlo (reaccin). El mantenimiento correctivo lleva a cabo reparaciones (que pueden ser de emergencia) y modifica el cdigo necesario para dar solucin al problema. El mantenimiento correctivo asegura que el software funcione tal y como se describe en las especificaciones del sistema; por lo tanto, es necesario un mantenimiento correctivo en los casos siguientes: Cuando un programa da un error de funcionamiento (falla). Cuando un programa da resultados que no coinciden con los definidos en los requisitos. Cuando la documentacin del sistema no coincide con el software desarrollado. Cuando el manual de usuario es errneo y puede dar lugar a una utilizacin incorrecta del sistema, y dar errores o resultados inesperados. 1.1.1 Tipos de mantenimiento correctivo Se pueden definir dos tipos de mantenimiento correctivo, segn la gravedad del error y su importancia. Por lo tanto se puede plantear de dos maneras: - Reparacin de emergencia: Se hace en un periodo muy corto de tiempo. Normalmente afecta a muy pocos programas (muchas veces se reduce a un solo programa). 14

Reparacin planificada: Soluciona problemas no urgentes y tambin se plantea como revisin de las reparaciones de emergencia que se han llevado a cabo.

Criterios para identificar una reparacin de emergencia - Cuando el error puede afectar a la seguridad de las personas (programas informticos de los aviones, de centrales nucleares, etc.). - Cuando el error puede comportar que un conjunto de personas quede en una situacin no productiva dentro de la empresa, es decir, de brazos cruzados mientras se hace la reparacin. - Cuando el sistema no arranca o se inestabiliza con facilidad. - Cuando el error afecta a operaciones financieras (sistema de nminas, facturas). 1.1.2 Proceso del mantenimiento correctivo Elegir una estrategia para solucionar el problema, que puede ser una de las siguientes: o Top-Down (descendente): Cuando las causas de error no son evidente si no se sabe por dnde empezar, se sigue una estructura lgica y de navegacin del programa hasta llegar a los posibles orgenes del problema. o Bottom-up (ascendente): Cuando se conocen los sntomas del problema y, sobre todo, su origen, se empieza a repasar la lgica del programa a partir de este punto hasta detectar el problema. o Debugger: Cuando fallan las anteriores, se utiliza el lenguaje de programacin del sistema para analizar los cambios internos en el programa hasta encontrar el momento en que se produce el error. o Seguimiento de la traza: Cuando el sistema es tan complejo que no permite un seguimiento interno, se hace una traza del sistema y se analizan sus acciones y los cambios que introduce.

1.2 Mantenimiento adaptativo


Este tipo de mantenimiento es muy normal debido a la evolucin de los equipos informticos y a la aparicin de nuevas herramientas y de plataformas ms adecuadas para el antiguo software. Un ejemplo de mantenimiento adaptativo es la adaptacin de sistemas a nuevas versiones de los sistemas operativos que representan una mejora tecnolgica importante. Tres factores influyen en este tipo de mantenimiento: 1) Las necesidades internas de negocio. 2) La competencia externa 3) Cambios externos 1.2.1 Proceso del mantenimiento adaptativo Para este tipo de mantenimiento se siguen las etapas de un ciclo de vida clsico: Definicin de los requisitos, es decir, revisin de los nuevos requisitos o cambios que hay que hacer. Revisin del diseo del sistema, procesos y flujos de datos para detectar los cambios necesarios. Revisin del diseo de los datos para detectar los cambios necesarios en la estructura de la base de datos. Revisin de la documentacin para determinar dnde hay que hacer los cambios. Revisin del impacto para determinar las consecuencias de la integracin de los cambios.

15

El xito o el fracaso del mantenimiento adaptativo dependen de los factores siguientes: El control ordenado de los cambios introducidos en el software. El uso de una estructura y unas normas de codificacin. El uso de un modelo de pruebas preestablecido para comprobar la calidad del software final.

1.3 Mantenimiento perfectivo


El mantenimiento perfectivo es el tipo de mantenimiento al que las organizaciones destinan ms recursos en tiempo y dinero. Adems de introducir mejoras en el sistema a peticin del cliente, el mantenimiento perfectivo tambin corrige los errores de rendimiento y mejora los procesos de manera que sean ms eficientes y fciles de mantener. Cuando hay que incorporar nuevas funcionalidades, el proceso es el mismo que el descrito para el mantenimiento adaptativo, es decir, seguimos las etapas del ciclo de vida del software habitual.

1.4 Mantenimiento preventivo


Se hace para prevenir los errores antes de que se produzcan: se trata de acciones de anticipacin. Son susceptibles de este tipo de mantenimiento todos aquellos programas que hayan estado en uso durante un determinado nmero de aos, programas que se estn utilizando sin presentar errores y programas que necesitarn en un futuro prximo una serie de modificaciones o mejoras importantes.

2. Caractersticas del mantenimiento del software


2.1 La dificultad del mantenimiento del software
Los problemas ms usuales con los que nos encontramos a la hora de afrontar el mantenimiento de un sistema son los siguientes: La dificultad de comprender un cdigo implementado por otras personas que, normalmente, no estn disponibles para poder dar explicaciones. La documentacin del sistema no se ajusta a la realidad. El sistema no ha sido diseado teniendo en cuenta un mantenimiento posterior. No resulta en absoluto atractivo para los profesionales dedicarse al mantenimiento de sistemas antiguos, no es una tarea demasiado motivadora. Las caractersticas que determinan si un software es fcil de mantener son: Facilidad de prueba: Facilidad con la que se pue3de demostrar la correccin de un software. Inteligibilidad: Facilidad de entender un software a partir del cdigo y la documentacin. Portabilidad: Facilidad con la que un software puede ser trasladado a un nuevo entorno informtico. Eficacia: Capacidad del software para cubrir las necesidades de los usuarios. Eficiencia: Capacidad del software para hacer sus funciones sin cargar excesivamente los recursos del hardware. Facilidad de uso: Indica si el software elaborado es til, fcil de utilizar y de aprender para los usuarios. Adems hay que contar el esfuerzo que se dedica a cada una de las actividades necesarias en el proceso de mantenimiento, que podemos clasificar en las dos categoras siguientes: 16

Actividades productivas: anlisis, evaluacin, modificacin y test. Actividades no productivas pero necesarias, como por ejemplo entender el cdigo, las estructuras de datos, la estructura del sistema, etc.

Hay que intentar minimizar estos dos tipos de actividades. Es difcil minimizar las actividades productivas, porque vienen determinadas por la naturaleza de las nuevas necesidades. En cambio, es posible minimizar las no productivas, ya que dependen de la calidad del sistema informtico. 2.1.1 Nomenclatura del software El hecho de nombrar las variables y funciones con nombres significativos facilita un rpido entendimiento y seguimiento del programa. As si una variable se llama total_gastos da ms informacin sobre su funcin que si se denomina todo_g o tg. 2.1.2 Indentacin de los programas Una indentacin correcta facilita la lectura y el entendimiento de la lgica del programa. Un programa no indentado, o mal indentado, es poco claro y puede dar lugar a interpretaciones incorrectas del cdigo, con el peligro que esto comporta. Documentacin Cuando se habla de documentacin del sistema, nos referimos tanto a la documentacin general del programa como a la relativa a la organizacin del programa y a la ms tcnica, la referente a las instrucciones internas. Esta documentacin debe ser breve y muy general. No puede tener un aspecto demasiado tcnico, ya que est destinada tanto a personal tcnico como a no tcnico. Normalmente se escribe justo antes de escribir la primera lnea de cdigo. Hay que destacar la importancia de tener una buena documentacin actualizada del sistema, para entenderlo y poder modificarlo cuando sea necesario. Una buena documentacin facilita el trabajo y el mantenimiento del sistema informtico. No tener informacin, o tenerla incompleta, conlleva un trabajo adicional: entender el sistema. 2.1.3 El uso de prototipos La creacin de prototipos es muy importante durante el ciclo de vida de un sistema informtico, y en especial para la fase de mantenimiento. Un prototipo aporta una visin de cmo ser el sistema y cules sern sus funcionalidades y ayuda a asegurar la calidad del producto desde el inicio del desarrollo, lo cual facilita su mantenimiento posterior.

2.2 Herramientas para el mantenimiento


Si el software estuviese bien estructurado, bien documentado con diagramas de flujo de datos, diagramas de procesos y tuviese un buen diseo de base de datos y unos estilos de programacin correctos, las tareas de mantenimiento seran ms fciles y menos costosas. Puesto que estas condiciones no siempre se cumplen, el equipo de mantenimiento debe, entre otras tareas, entender: a) las estructuras de datos. b) el flujo de datos. 17

c) los procesos del sistema. d) las diferencias entre las posibles versiones del programa. Estas tareas son ms fciles de hacer con la ayuda de herramientas especializadas. Las herramientas de ayuda al mantenimiento del software van surgiendo inicialmente como herramientas de desarrollo, para mejorar su calidad y, de esta manera, reducir su mantenimiento posterior. Por lo tanto, estas herramientas se utilizan en las dos fases.

2.3 Los entornos de trabajo


Normalmente hay tres entornos de trabajo distintos para un sistema: - Un entorno de explotacin (el entorno real), en el que trabajan los usuarios con el sistema. - Un entorno de desarrollo, en el que los programadores efectan las tareas de creacin de nuevas funcionalidades de los programas y de mantenimiento de las antiguas. - Un entorno de pruebas, en el que se hacen las pruebas previas del sistema. Estas pruebas las pueden llevar a cabo tanto los desarrolladores como los usuarios finales del sistema. La manera de trabajar sera la siguiente: Se hace el nuevo software en el entorno de desarrollo; se traslada al entorno de pruebas, donde se llevan a cabo las pruebas unitarias y las globales y, una vez superados los tests, se pasa a explotacin, donde los usuarios lo pueden empezar a utilizar. En caso de detectarse un error o deficiencia en el sistema, el programa afectado se pasa al mdulo de desarrollo y se modifica. A continuacin, se pasa al entorno de pruebas, en el que se somete a prueba, y finalmente se traslada al entorno de explotacin para que los usuarios lo puedan utilizar. Si las dimensiones de la empresa lo permiten, se puede separar el mantenimiento del entorno de desarrollo para constituirse aparte. Mientras que en el entorno de desarrollo se crean programas nuevos, en el de mantenimiento se modifican los que estn en explotacin. En la misma lnea, tambin podra haber un entorno de formacin separado del entorno de pruebas.

2.4 Externalizacin del mantenimiento


Una de las prcticas cada vez ms habituales en las empresas es externalizar el servicio informtico. Es muy importante que haya un contrato escrito que delimite los servicios que se contratan y las responsabilidades exigibles en caso de incumplimiento. Las modalidades de los contratos pueden ser muchas y cada organizacin elige la suya segn sus necesidades, por ejemplo: Por jornadas completas: un servicio de veinticuatro horas al da o de ocho horas al da, por ejemplo. Por horas contratadas: se contrata un nmero de horas (o jornadas) que se va consumiendo con los servicios sucesivos. 18

Por gravedad del mantenimiento: se contratan n reparaciones urgentes y m reparaciones no urgentes. En este caso, hay que especificar el criterio de urgencia.

3. El proceso de mantenimiento
3.1 El equipo de trabajo
La estructura de un equipo de mantenimiento acostumbra a ser la siguiente: 1) Responsable o lder del equipo. Es el mximo responsable del buen funcionamiento de las tareas de mantenimiento y el interlocutor entre el equipo de mantenimiento y el usuario que ha originado la demanda. Adems, tiene conocimientos de todos los sistemas de la empresa y experiencia en liderazgo de grupos de grupos de trabajo y en anlisis y diseo de programas informticos. 2) Grupo encargado del mantenimiento. Equipo de programadores que se encargan de la modificacin de los programas. En este grupo de trabajo es necesario que haya perfiles especializados similares a los que hay en el grupo de desarrolladores. El nmero de personas dedicadas al mantenimiento del software no es fijo: la etapa inmediatamente posterior a la entrega del software y las demandas de versiones nuevas marcan los mximos en la actividad de mantenimiento, que va menguando a medida que se da solucin a estas peticiones.

3.2 Flujo del proceso


El proceso ms usual para llevar a cabo el mantenimiento es el siguiente: Llega una peticin de correccin de errores del sistema, de modificaciones o de nuevos comportamientos. Esta peticin entra en el registro de entrada de peticiones de mantenimiento que hacen los usuarios. Normalmente, de esta tarea, que muchas veces se limita a recoger las incidencias por telfono o correo electrnico, se encarga personal no necesariamente tcnico. Estas personas remiten las peticiones hacia una persona que supervisa y aprueba o deniega las peticiones de mantenimiento. Para cada peticin que llega, se valora el esfuerzo, el tipo de modificacin necesaria, la gravedad y la prioridad de la peticin. En caso de tratarse de una correccin crtica para el sistema, se asigna un equipo de trabajo para resolver el problema. Si la incidencia no es crtica para el sistema, se evala y se clasifica la peticin para planificarla correctamente con el resto de las peticiones. Si la peticin se aprueba, se le asigna una prioridad y se pone en la cola de las pendientes. Se designa a una persona o un grupo tcnico para solucionarla. La persona a la que se ha asignado la tarea revisa la peticin de mantenimiento y determina su coste y fecha de inicio. El equipo de trabajo estudia la documentacin del sistema, la modificacin del diseo, la revisin y las modificaciones oportunas en el cdigo, las pruebas unitarias y globales y, finalmente, la modificacin de la documentacin asociada.

3.3 Efectos colaterales


El mismo proceso de mantenimiento, al intentar resolver ciertos problemas, puede generar nuevos errores, los denominados efectos colaterales, que pueden afectar al cdigo, a los datos e incluso a la documentacin.

19

Un mantenimiento defectuoso genera una espiral en la que el mantenimiento es cada vez ms costoso y peligroso, esta espiral puede generar una situacin grave que slo se puede solucionar por un proceso de reingeniera iniciado en alguna parte del sistema para poder asegurar su mantenibilidad y calidad hasta el final de su vida til.

4. El coste del mantenimiento


4.1 El coste del mantenimiento del software
El mantenimiento del software representa la parte ms desconocida y olvidada del ciclo de vida de un sistema informtico. Las nuevas tecnologas de la informtica han intentado acortar las primeras etapas del ciclo de vida con la creacin de lenguajes y herramientas de ayuda de alto nivel. Sin embargo, la mayor parte de las mejoras han ido a parar a las etapas de anlisis, diseo e implementacin, y el mantenimiento es la parte ms abandonada. El coste de llevar a cabo una modificacin vara segn la etapa del ciclo de vida en la que se encuentre el sistema informtico: es mucho ms caro (en dinero, tiempo y esfuerzo) efectuar un cambio en la etapa de mantenimiento que en las etapas anteriores del ciclo de vida: cuanto ms tarde se pide un cambio o se detecta una deficiencia del sistema, ms coste asociado comporta.

4.2 Mtricas del mantenimiento del software


El coste del mantenimiento se puede calcular a partir de la expresin siguiente: M = p + K(c f) M = Esfuerzo total del mantenimiento p = Esfuerzo productivo K = Constante emprica c = Medida de complejidad de mantenimiento, atribuible a un diseo errneo o una pobre documentacin f = Medida del grado de conocimiento del software De esta frmula se puede desprender que el esfuerzo total de mantenimiento (y su coste) puede crecer exponencialmente si no se utiliza un buen diseo o no se dispone de una buena documentacin, o bien si las personas encargadas del mantenimiento desconocen el sistema. Hay otra mtrica, basada en el estndar IEEE 982.1-1988, que sugiere un ndice de madurez del software (IMS). Este ndice, que indica la estabilidad de un software a partir de los cambios presentes en cada versin, se calcula de la manera siguiente: IMS = [ Mt - (Fa + Fm + Fe)] / Mt Mt = Nmero de mdulos de la versin actual Fa = Nmero de mdulos de la versin actual aadidos Fm = Nmero de mdulos de la versin actual modificados Fe = Nmero de mdulos borrados de la versin anterior El producto se empieza a estabilizar cuando el IMS se aproxima a 1,0; entonces, el sistema no necesitar tantos esfuerzos para su mantenimiento. El IMS relaciona el concepto de calidad del software con el de mantenimiento del software: cuanta ms calidad en un producto informtico, menos esfuerzo es necesario para mantenerlo.

20

You might also like