Gestión de Configuración del Software GCS

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.

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.

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.

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

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

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.

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.

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.

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?

 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?

  

Garantia de Calidad de Software (SQA)

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.

La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. La calidad del software es medible y varía de un sistema a otro o de un programa a otro.

“La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”.

La SQA (Software Quality Assurance) engloba:

•          Un enfoque de gestión de calidad .
•          Tecnología de Ingeniería de Software efectiva (métodos y herramientas).
•          Revisiones técnicas formales que se aplican durante el proceso del   software.
•          Una estrategia de prueba multiescalada.
•          Un control de la documentación del software y de los cambios realizados
•          Un procedimiento que asegure un ajuste a los estándares de desarrollo de
            software.
•          Mecanismos de medición y de generación de informes.

El control de la calidad es una serie de revisiones, y pruebasutilizados a los largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados.

La garantía de calidad o aseguramiento de la calidad consiste en la auditoria y las funciones de información de la gestión. El objetivo de la garantía de la calidad es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más profunda y segura de que la calidad del producto está cumpliendo sus objetivos.

SQA es un conjunto de actividades sistemáticas y planeadas para asegurar que los procesos y productos de software cumplen con los requerimientos, estándares y procedimientos.

PROCESO                                                                                          PRODUCTOS
Diseño,                                                                                              Software
Codificación                                                                                      Documentación
Test                                                                                                   Soporte
Mantenimiento

PROPÓSITO DE SQA

 Proporcionar visibilidad sobre procesos utilizados por el proyecto de SW y sobre los productos que genera.

 Objetivos :

1. Planificar las actividades de aseguramiento de la calidad.
2.  Revisar y auditar objetivamente los productos y las actividades para verificar que estén conformes con los procedimientos y estándares.
3. Proporcionar los resultados de estas revisiones o auditorías informando a la dirección.

EL GRUPO ENCARGADO DE SQA.

• Trabaja con el equipo del proyecto desde el inicio.
• Debe ser objetivo e independiente.
• Ayuda al proyecto, más que controlar sus actividades.

La actividad de SQA es el proceso de verificación de que los estándares sean aplicados correctamente. En los proyectos pequeños esto se puede realizar por el equipo de desarrollo, pero en proyectos grandes, un grupo específico se debe dedicar a este rol.

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.

• Satisfacción de cliente mejorada: La satisfacción de cliente mejorada significa relaciones más de largo, más provechosas del cliente.
• 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.

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.Diversos usos del software requieren diversos acercamientos cuando viene a la prueba, pero algunas de las tareas mas 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. 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.
• 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. 

Niveles de Maduración

• Nivel 1. Inicial. En este nivel, los proyectos y métodos de ingeniería no se encuentran definidos. Por esta razón, los proyectos son adelantados de manera incoherente, incontrolada y poco profesional. El éxito es eventual. Según la entidad certificadora del CMM, el Instituto de Ingeniería de Software de los Estados Unidos (SEI), la mayoría de los grupos de desarrollo de software en el mundo operan a este nivel.
• Nivel 2.Repetible. Se establecen algunos procesos y métodos de ingeniería a nivel de proyectos.
• Nivel 3. Definido. Los procesos, actividades y métodos relacionados con la ingeniería y administración de proyectos se encuentran documentados, estandarizados y construidos alrededor de un marco integrado para toda la compañía.
• Nivel 4. Administrado. La compañía opera bajo control estadístico de procesos. Los resultados de los procesos y la calidad de los productos son predecibles.
• Nivel 5. Optimización. En este nivel, las organizaciones se encuentran en un proceso de mejora continua. Las organizaciones se enfocan en su mejora a través de técnicas de prevención de defectos, cambios en tecnología y en procesos. Según el SEI, menos del 0,1% de las organizaciones del mundo se encuentran en nivel de madurez.

 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.

Analisis y Gestión de Riesgo

El análisis de riesgos informáticos es un proceso que comprende la identificación de activos informáticos, sus vulnerabilidades y amenazas a los que se encuentran expuestos así como su probabilidad de ocurrencia y el impacto de las mismas, a fin de determinar los controles adecuados para aceptar, disminuir, transferir o evitar la ocurrencia del riesgo.

El proceso de análisis de riesgo genera habitualmente un documento al cual se le conoce como matriz de riesgo. En este documento se muestran los elementos identificados, la manera en que se relacionan y los cálculos realizados.

Este análisis de riesgo es indispensable para lograr una correcta administración del riesgo. La administración del riesgo hace referencia a la gestión de los recursos de la organización. Existen diferentes tipos de riesgos como el riesgo residual y riesgo total así como también el tratamiento del riesgo, evaluación del riesgo y gestión del riesgo entre otras.

La fórmula para determinar el riesgo total es: RT (Riesgo Total) = Probabilidad x Impacto Promedio

Después de efectuar el análisis debemos determinar las acciones a tomar respecto a los riesgos residuales que se identificaron. Las acciones pueden ser:

• Controlar el riesgo.- Fortalecer los controles existentes y/o agregar nuevos controles.
• Eliminar el riesgo.- Eliminar el activo relacionado y con ello se elimina el riesgo. Compartir el riesgo.- Mediante acuerdos contractuales parte del riesgo se traspasa a un tercero.
• Aceptar el riesgo.- Se determina que el nivel de exposición es adecuado y por lo tanto se acepta.

Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de probabilidad.

• Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos.

Los riesgos del proyecto amenazan al plan del proyecto. Es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificación temporal, personal (asignación y organización), recursos, cliente y requisitos y su impacto en un proyecto de software.

Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño, implementación, de interfaz. Verificación y de mantenimiento. Además. las ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las "tecnologías punta" son también factores de riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos.

Los riesgos del negocio amenazan la viabilidad del software a construir Los riesgos del negocio a menudo ponen en peligro el  proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son:

1. Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado),

2. Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico),

3. Construir un producto que el departamento de ventas no sabe cómo vender.

4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de dirección)

5. Perder presupuesto o personal asignado (riesgos de presupuesto).

                                        Tabla   de   Gestión de Riesgo

Riesgo	Probabilidad	Impacto	Estrategia de Recompensa.
Riesgo del Proyecto
Presupuesto	0.10	Ma	Sumar el 20% al costo real del software.
Planificación Temporal	0.08	Ma	Realizar un descuento del 5 % por cada mes de retraso.
Personal( Asignación y Organización)	0.02	De	Motivación, capacitación al personal.
Recursos	0.10	Ma	Optimizar los recursos.
Clientes y sus requisitos	0.18	Ma	Entablar una buena comunicación con el cliente.
Impacto	0.14	Ma	Crear una buena campaña publicitaria, promover en las diferentes empresas.
Riesgo Técnico.
Diseño	0.07	De	Crear un buen diseño llamativo y que cumpla con las necesidades del cliente.
Implementación	0.11	Ma	Brindar capacitación al usuario del software.
Interfaz	0.04	De	Atender las solicitudes del cliente.
Verificación	0.10	Ma	Establecer un periodo de prueba de un mes para realizar ciertas validaciones.
Mantenimiento	0.02	De	Fijar una fecha para dar mantenimiento al menos una vez al mes.
Riesgo del Negocio
Riesgo de Mercadeo.	0.24	Cr	Brindar un software de prueba para mostrar la funcionalidad y aceptación del mismo.
Riesgo Estratégico.	0.08	Ma	Realizar modificaciones requeridas por el cliente.
Riesgo de Mercadotecnia	0.19	Cr	Ofertar el software en los distintos medios de publicidad (Tv, radio, internet, etc.)
Riesgo de perder contacto con el personal del negocio.	0.20	Ma	Firmar contrato con representante jurídico del negocio.
Cierre del negocio.	0.34	Ca	Ofrecerlo a otras empresas y realizar modificaciones requeridas por el nuevo cliente.