Professional Documents
Culture Documents
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.
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.
5. Plan de accin
El plan de accin se definir despus de haber hecho un buen anlisis del punto de partida y la estrategia.
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.
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.
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.
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.
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.
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.
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
13
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.
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.
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.
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.
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.
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.
20