martes, 19 de octubre de 2010

GESTION DE LA CONFIGURACION DEL SOFTWARE GCS


Configuración de software

INTRODUCCION
La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos de producción.
Durante el proceso de construcción de un software, los cambios son inevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniería.
“El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores.” Babich [BAB86].
1. GESTION DE LA CONFIGURACION DEL SOFTWARE (GCS)
Los cambios dentro del desarrollo del software pueden ocurrir en cualquier momento por lo tanto debemos estar preparados, las actividades de CGS sirven para:
  • Identificar el cambio de nuestro software.
  • Controlar ese cambio.
  • Garantizar que el cambio quede bien implantado.
  • Informar el cambio.
La gestión de configuración del software no es un mantenimiento del software, el mantenimiento es la etapa final de la ingeniería hasta que se retire el producto del equipo, la CGS es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo del software y termina sólo una vez que el software queda fuera de circulación.
Desgraciadamente, en el proceso de ingeniería del software existe una variable importantísima que entra en juego, el cambio.
La primera Ley de la ingeniería de sistemas establece: “Sin importar en que momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida”.
Entonces nos hacemos diferentes preguntas: ¿Por qué cambiar el sistema? ¿Que produce los en el sistema cambios? La respuesta a estas interrogantes se puede encontrar en cuatro aspectos fundamentales y a menudo muy tradicionales dentro del desarrollo del software:
  • Nuevos requisitos del negocio o condiciones que dictan los cambios en las condiciones del producto o en las normas comerciales.
  • Nuevas necesidades del los clientes que demandan la modificación de los datos producidos por un sistema basado en computadora.
  • Reorganización y/o reducción del volumen comercial que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software.
  • Restricciones presupuestarias o de planificaciones que provocan una redefinición del sistema o del producto.
La gestión de configuración del software realiza un conjunto de actividades desarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida del software de computadora.
La GCS es una actividad de garantía de calidad del software que se aplica en todas las fases del proceso de ingeniería del software.
1.1. LINEAS BASE
Una línea base es un concepto de gestión de configuración del software que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados. La IEEE define una línea base como:
Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.
Una forma de describir la línea base es mediante una analogía. Considere las puertas de la cocina de un gran restaurante. Para evitar colisiones una puerta esta marcada como SALIDA y la otra como ENTRADA las puertas tienen topes que hacen que solo se puedan abrir en la dirección apropiada. Si un camarero recoge un pedido en la cocina lo coloca en una bandeja y luego se da cuenta de que ha cogido un plato equivocado, puede cambiar el plato correcto rápidamente informalmente antes de salir de la cocina.
Sin embargo, si abandona la cocina le da el plato al cliente y luego se le informa de su error, debe seguir el siguiente proceso: 1) Mirar en la orden de pedido si ha cometido algún error. 2) Disculparse insistentemente. 3) Volver a la cocina por la puerta de entrada. 4) Explicar el problema etc.
Una línea base es análoga a un plato mientras pasa por las puertas de la cocina de un restaurante antes de que un elemento de configuración del software se convierta en línea base, el cambio se puede llevar a cabo rápida e informalmente. Sin embargo, una vez que se establece una línea base, pasamos, de forma figurada, por una puerta de un solo sentido. Sé pueden llevar a cabo los cambios, pero se debe aplicar un procedimiento formal para evaluar y verificar cada cambio.
En el contexto de la ingeniería del software definimos una línea base como un punto de referencia en el desarrollo del software y que queda marcado por el envío de uno o más elementos de configuración del software (ECS) y la aprobación de ECS obtenido mediante una revisión técnica formal. Por ejemplo, los elementos de una especificación de diseño se documentan y se revisan. Se encuentran errores y se corrigen cuando todas las partes de las especificaciones se han revisado corregido y aprobado, la especificación de diseño se convierte en línea base. Solo se pueden realizar cambios futuros en la arquitectura del software (contenidos en la especificación del diseño) tras haber sido evaluados y aprobados. Aunque se puedan definir las líneas base con cualquier nivel de detalle las líneas base más comunes son las que se muestran en la figura 1.0.


Fig.1.0. Líneas base
1.2. ELEMENTO DE CONFIGURACIÓN DE SOFTWARE
Un elemento de la configuración del software es la información creada como parte del proceso de ingeniería un ECS (elemento de configuración de software) es un documento, un conjunto completo de casos de prueba o un componente de un programa 40
dado. Los siguientes ECS son el objetivo de las técnicas de gestión de configuración y forman un conjunto de líneas base:
1) Especificación del sistema
2) Plan de proyecto
3) a. Especificación de requisitos
b. Prototipo ejecutable o “en papel”
4) Manual de usuario preliminar
5) Especificación de diseños
a. Descripción del diseño de datos
b. Descripción del diseño arquitectónico
c. Descripciones del diseño de los módulos
d. Descripciones del diseño de interfaces
e. Descripciones de los objetos (si se utilizan técnicas de P.O.O)
6) Listados del código fuente
7) a. Plan y procedimiento de pruebas
b. Casos de prueba y resultados registrados
8) Manuales de operación de y de instalación
9) Programas ejecutables
a. Módulos, código ejecutable
b. Módulos enlazados
10) Descripción de la base de datos
a. Esquema y estructura de archivos
b. contenido inicial
11) Manual del usuario final
12) Documentos de mantenimiento
a. Informes de problemas del software
b. Peticiones de mantenimiento
c. Ordenes de cambios e ingeniería
13) Estándares y procedimientos de ingeniería del software
Es importante considerar poner las herramientas de desarrollo de software bajo control de configuración. Es decir congelar la versiones de editores, compiladores y otras herramientas CASE utilizadas durantes el desarrollo, un cambio en las versiones utilizadas puede que produzca resultados diferentes que la versión original.
Los ECS se organizan como objetos de configuración que deben ser catalogados por la base de datos del proyecto con un nombre único. Un ECS tiene un nombre y atributos, y está conectado a otros objetos mediante relaciones.



Fig.1.1 Objetos configuración
La figura 1.1 se muestra el modelo de datos de los elementos de al configuración, cada objeto esta relacionado con otro, si se lleva a cabo un cambio sobre un objeto la interrelaciones señalan a que otros objetos afectará.
2. EL PROCESO DE GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
La GCS es un elemento importante de garantía de calidad es responsable de controlar los cambios. Sin embargo también se debe identificar los ECS individuales. El proceso se puede definir en cinco tareas de CGS:
  • Identificación
  • Control de versiones
  • Control de cambios
  • Auditorias de configuración
  • Generación de informes
3. IDENTIFICACIÓN DE OBJETOS EN GCS
Se pueden identificar dos tipos de objetos los objetos básicos y los objetos compuestos.
Un objeto básico es una unidad de texto creada durante el análisis, diseño, codificación o prueba. Un objeto compuesto es una colección de objetos básicos u objetos compuestos. Cada objeto tiene un conjunto de características que los identifican como únicos. El nombre del objeto es una cadena de caracteres que identifica al objeto sin ambigüedad. La descripción del objeto es una lista de elementos de datos que identifican:
  • El tipo de ECS (documento, programa, datos) que está representado por el objeto.
  • Un identificador del proyecto; y la información de la versión y/o el cambio.
El esquema de identificación de los objetos de software debe tener en cuenta que los objetos evolucionan a lo largo del proceso de ingeniería, por lo que se puede crear un grafo de evolución (figura 1.3)



Fig.1.3 Grafo de evolución
En el grafo de evolución se describe la historia del objeto y sus cambios, las grandes modificaciones hacen que un objeto cambie, por lo que cambia el número de versión principal.
4. CONTROL DE VERSIONES
El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creadas durante el proceso de ingeniería del software.
"La gestión de configuración permite a un usuario especificar configuraciones alternativas del sistema de software mediante la selección de las versiones adecuadas. Esto se puede gestionar asociando atributos a cada versión del software y permitiendo luego especificar y construir una configuración describiendo el conjunto de atributos deseado."
Los atributos pueden ser tan sencillos como un número específico de versión asociado a cada objeto o tan complejos como una cadena de variables lógicas que especifiquen tipos de cambios funcionales aplicados al sistema.



Fig. 1.4 Versiones y variantes
Para construir la variante adecuada de una determinada versión de un programa, a cada componente se le asigna una tupla de atributos. A cada variante se le asigna uno o más atributos. Otra forma de establecer los conceptos de la relación entre componentes, variantes y versiones es representarlas como un fondo de objetos



.
Fig.1.5 Representación de objetos, componentes, variantes y versiones
La principal diferencia entre los distintos está en la sofisticación de los atributos que se usan para construir versiones y variantes específicas de un sistema y en la mecánica del proceso de construcción.
5. CONTROL DE CAMBIOS
En un gran proyecto de desarrollo de software, el cambio incontrolado lleva rápidamente al caos. El control de cambios combina los procedimientos humanos y las herramientas automáticas para proporcionar un mecanismo para el control de cambio.



Fig. 1.6 Proceso de control de cambios
Los resultados de la evaluación se presentan como un informe de cambios a la autoridad de control de cambios (ACC). Para cada cambio aprobado se genera una orden de cambio de ingeniería (OCI) La OCI describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisión y de auditoria. El objeto a cambiar es "dado de baja" de la base de datos del proyecto; se realiza el cambio y se aplican las adecuadas actividades de SQA. Luego, el objeto es "dado de alta" en la base de datos y se usan los mecanismos de de control de versiones apropiadas (sección 4) para crear la siguiente versión del software.
Los procedimientos de "alta" y "baja" implementan dos elementos importantes del control de cambios: control de acceso y control de sincronización. El control de acceso gobierna los derechos de los ingenieros de software a acceder y modificar objetos de configuración concretos. El control de sincronización asegura que los cambios en paralelo, realizados por personas diferentes, no se sobrescriben mutuamente.



Fig. .7 Control de acceso y de sincronización
Antes de que un ECS se convierta en una línea base, sólo es necesario aplicar un control de cambios informal. El que haya desarrollado el ECS en cuestión podrá hacer cualquier cambio justificado por el proyecto y por los requisitos técnicos. Una vez que el objeto ha pasado la revisión técnica formal y ha sido aprobada, se crea la línea base.
Una vez que el ECS se convierte en una línea base, aparece el control de cambios a nivel de proyecto. Para hacer un cambio, el encargado del desarrollo debe recibir la aprobación del gestor del proyecto (si el cambio es local), o de la ACC si el cambio impacta en otros ECS. En algunos casos, se dispensa de generar formalmente las peticiones de cambio, los informes de cambio y las OCI. Sin embargo, hay que hacer una evaluación de cada cambio así como un seguimiento y revisión de los mismos.
Cuando se distribuye el producto de software a los clientes, se instituye el control de cambios formal.
La autoridad de control de cambios (ACC) desempeña un papel activo en el segundo y tercer nivel de control. El papel de la ACC es el de tener una visión general, o sea, evaluar el impacto del cambio fuera del ECS en cuestión. ¿Cómo impactará el cambio en el hardware? ¿Cómo impactará en el rendimiento?¿Cómo alterará el cambio la percepción del cliente sobre el producto?
6. AUDITORIA DE LA CONFIGURACION
¿Cómo podemos asegurar que el cambio se ha implementado correctamente? La respuesta es doble: 1) revisiones técnicas formales y 2) auditorias de configuración del software.
Las revisiones técnicas formales se centran en la corrección técnica del elemento de configuración que ha sido modificado. Los revisores evalúan el ECS para determinar la consistencia con otros ECS, las omisiones o los posibles efectos secundarios.
Una auditoria de configuración del software complementa la revisión técnica formal al comprobar características que generalmente no tiene en cuenta la revisión. La auditoria se plantea y responde con las siguientes preguntas:
  • ¿Se ha hecho el cambio especificado en la OCI? ¿Se han incorporado modificaciones adicionales?
  • ¿Se ha llevado a cabo una revisión técnica formal para evaluar la corrección técnica?
  • ¿Se han seguido adecuadamente los estándares de ingeniería de software?
  • ¿Se han "recalcado" los cambios en el ECS?¿Se han especificado la fecha del cambio y el autor?¿Reflejan los cambios los atributos del objeto de configuración?
  • ¿Se han seguido procedimientos del GCS para señalar el cambio, registrarlo y divulgarlo?
  • ¿Se han actualizado adecuadamente todos los ECS relacionados?
7. INFORMES DE ESTADO
La generación de informes de estado de la configuración es una tarea de GCS que responde a las siguientes preguntas:
1) ¿Qué pasó?
2) ¿Quién lo hizo?
3) ¿Cuándo pasó?
4) ¿Que más se vio afectado?
La generación de informes de estado de la configuración desempeña un papel vital en el éxito del proyecto de desarrollo de software. Cuando aparece involucrada mucha gente es muy fácil que no exista una buena comunicación. Pueden darse errores entre las personas desarrolladoras del software. El IEC ayuda a eliminar esos problemas, mejorando la comunicación entre todas las personas involucradas.
8. ESTANDARES DE GCS
Durante las dos últimas décadas se han propuesto varios estándares de gestión de configuración del software.
9. RESUMEN
La gestión y configuración del software identifica, controla audita e informa de las modificaciones que invariablemente se dan al desarrollar el software una vez que ha sido distribuido a los clientes.
La con figuración se organiza de tal forma que sea posible un control organizado de los cambios.
La configuración del software está compuesta por un conjunto objetos interrelacionados, denominados elementos de configuración del software, que son provocados par la actividades del desarrollo, de la ingeniería del software.
Las líneas base nos permiten guiarnos para desarrollar los cambios, los objetos forman un asociación que refleja las variantes y relaciones creadas, el control de versiones son procedimientos y herramientas que ayudan a gestionar el uso de los objetos. El control de cambios es una actividad procedimental que asegura la calidad en los cambios del los ECS. La auditoria de configuración es una actividad de SQA (Aseguramiento de la calidad del software) para asegurar la calidad durante los cambios.
10. CONCLUSION
Durante el proceso de construcción de un software, los cambios son inevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. La finalidad de la Gestión y configuración del Software el conocer la estructura de procesos y herramientas para aplicar dentro de la construcción del software que nos ayudan a controlar los cambios. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniería para asegurar su control y calidad.

GARANTIA DE LA CALIDAD DEL SOFTWARE SQA

Garantía de calidad del software

Garantía de calidad del software (SQA) consiste en los medios de la supervisión tecnología de dotación lógica los procesos y los métodos aseguraban calidad. Hace esto por medio de intervenciones de sistema de gerencia de la calidad debajo de cuál se crea el sistema de software. Estas intervenciones son movidas hacia atrás por unos o más estándares, generalmente ISO 9000.
Es distinto de control de calidad del software cuál incluye el repaso requisitos documentos, y prueba del software. La SQA abarca el entero desarrollo del software proceso, tales como el cual incluye procesos diseño del software, codificación, control del código de fuente, revisiones de código, cambie a gerencia, gerencia de la configuración, y lance a gerencia. Mientras que el control de calidad del software es un control de productos, la garantía de calidad del software es un control de procesos.
La garantía de calidad del software se relaciona con la práctica de garantía de calidad en producto fabricación. Hay, sin embargo, algunas diferencias notables entre el software y un producto manufacturado. Estas diferencias provienen el hecho de que el producto manufacturado es físico y puede ser visto mientras que el producto de software no es visible. Por lo tanto su función, ventaja y costes no están según lo medido fácilmente. Cuál es más, cuando un producto manufacturado cae la planta de fabricación, es esencialmente un completo, producto final, mientras que el software nunca se acaba. El software vive, crece, se desarrolla, y transforma, desemejante de sus contrapartes tangibles. Por lo tanto, los procesos y los métodos para manejar, para supervisar, y para medir su calidad en curso son tan líquido y a veces evasivos como son los defectos que se significan para mantener cheque.
Ventajas de la SQA
Un plan de la SQA puede tomar un número de trayectorias, probando para diversas capacidades y la ejecución diferente analiza, dependiendo de las demandas del proyecto, los usuarios, y el software sí mismo. Pero cualquier plan riguroso de la SQA realizado escrupulosamente por los profesionales chevronn3es del QA conferirá ciertas ventajas:
Satisfacción de cliente mejorada La satisfacción de cliente mejorada significa relaciones más de largo, más provechosas del cliente, testimonios positivos del cliente, y las ondas del negocio de la remisión generadas de la palabra positiva de la boca.
Si descontentan a los clientes con un producto que han comprado de un vendedor particular del software, nunca son probables recomendar ese producto ni compra a ese vendedor del software otra vez. Los insectos y los defectos, además seriamente de obstaculizar la funcionalidad de un uso, miran descuidados y un profesional, y reflejan mal en la reputación de una compañía.
Cuál es más, sin la prueba apropiada, es virtualmente imposible saber los nuevos usuarios responderán a las funciones de un uso, a las opciones, y a las características de la utilidad. Los especialistas imparciales de la garantía de calidad del software vienen a un proyecto fresco, con una perspectiva clara, y así que servicio como la primera línea de defensa contra interfaces utilizador unintuitive y funcionalidad quebrada del uso. Un uso de la calidad está garantizado para dar lugar a la satisfacción de cliente realzada.
Coste reducido de desarrollo Porque el proceso de la garantía de calidad del software se diseña para prevenir defectos e ineficacias del software, los proyectos que incorporan riguroso, prueba del objetivo encontrarán que los costes del desarrollo están reducidos puesto que todas las fases más posteriores del ciclo vital del desarrollo llegan a ser aerodinámicas y simplificados perceptiblemente. Con la SQA, toda la otra prueba y desarrollo incluyendo despliegues de la prueba y del cliente del usuario irán más suavemente, y por supuesto más rápidamente -- qué medio su proyecto del desarrollo del software constantemente alcanzará la terminación el tiempo y dentro del presupuesto, lance después de lanzamiento.
Coste de mantenimiento reducido los usos Insecto-infestados son molestos apoyar. El coste combinado de memorias, de vueltas, y de remiendos innecesarios puede ser espantoso. Y eso no dice nada de qué tendrá que ser pasada en ayuda de cliente en curso, sea por el teléfono, email, o en persona. Todos estos costes y pueden ser reducidos más dramáticamente lanzando solamente productos riguroso calidad-asegurados. Los vendedores del software que ahora invierten en calidad pueden evitar pérdidas grandes en el futuro.
Metodología de la SQA
La prueba del software es tanto un arte como una ciencia. En grande, los usos complejos, tales como sistemas operativos, es prácticamente imposible planchar hacia fuera cada solo insecto antes de lanzarlo ambos de un punto de vista de la dificultad y debido a los apremios del tiempo. Diversos usos del software requieren diversos acercamientos cuando viene a la prueba, pero algunas de las tareas más comunes del QA del software incluyen:
Prueba de la validación
La prueba de la validación es el acto de los datos que entran que el probador sabe para ser erróneo en un uso. Por ejemplo, mecanografiando “hola” en una caja de corregir que está esperando recibir una entrada numérica.
Comparación de los datos
Comparando la salida de un uso con parámetros específicos a un sistema previamente creado de los datos con los mismos parámetros que se saben para ser exactos.
Prueba de la tensión
Una prueba de tensión es cuando el software se utiliza tan pesadamente como sea posible por un período de la hora de considerar si hace frente a los altos niveles de la carga. De uso frecuente para el software del servidor que tendrá múltiple los usuarios conectaron con él simultáneamente. También conocido como prueba de la destrucción.
Prueba de la utilidad
A veces consiguiendo a los usuarios que son desconocedores con el software intentarlo durante algún tiempo y ofrecer la regeneración a los reveladores sobre lo que encontraron difíciles de hacer es la mejor manera de llevar a cabo mejoras a un interfaz utilizador.