martes, 19 de octubre de 2010

Entrada 9: Gestión de Configuración de Software (GCS):

Generalidades

A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción del mismo, y posteriormente desde el inicio del mantenimiento hasta su retiro, se van realizando una serie de cambios, tanto en el código como en la documentación asociada. La Gestión de Configuración del Software es una disciplina encargada del control de la evolución de los productos de software.
Como todo proceso, la Gestión de Configuración también puede ser sistematizada y automatizada, lo que se denomina un Sistema de Gestión de Configuración (SGC). Actualmente existen en el mercado diversas herramientas que permiten apoyar una o más actividades de la Gestión de Configuración.

Definiciones

Gestión de Configuración es el proceso de identificar y definir los elementos en el sistema, controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el estado de los elementos y las solicitudes de cambio, y verificando que los elementos estén completos y que sean los correctos.

El propósito de la Gestión de Configuración del Software es establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software.

La Gestión de Configuración del Software implica la identificación de la Configuración del software en puntos dados en el tiempo, el control sistemático de los cambios en la Configuración y el mantenimiento de la integridad y trazabilidad de la Configuración a través del ciclo de vida del software. Los productos incluidos son:

*Software distribuido al cliente.

*Documentos de requerimientos del software.

*Código.

*Elementos requeridos para crearlos (ejemplo: el compilador)

Aspectos Funcionales

1. Identificación: Se necesita definir un esquema de identificación para reflejar la estructura del producto, esto involucra identificar la estructura y clases de componentes, dando a cada uno un nombre, una identificación de versión y una identificación de Configuración.

2. Control: Se deben controlar los cambios que se le hacen a través del ciclo de vida, asegurando que el software sea consistente a través de la creación de una línea base del producto.

3. Estado: Se debe registrar y reportar el estado de los componentes y solicitudes de cambio.

4. Auditoria y revisión: Se debe validar que el producto este completo y se asi mantener la consistencia entre los componentes, asegurando que estén en un estado apropiado a través de todo el ciclo de vida del producto y que el mismo sea una colección bien definida de componentes.
Solución que le brindamos

Nuestra empresa reúne conocimientos específicos en la disciplina de Configuración del Software y experiencia implementando y aplicando estos conceptos en diferentes organizaciones.

Estos conocimientos se complementan y enriquecen utilizando las herramientas específicas y un framework metodológico adecuable al proyecto y al cliente.

La suma de estos aspectos posibilita la implementación de una solución de Gestión Automatizada de Configuración del Software, amalgamando funciones y disciplinas a herramientas y procesos automáticos.

Así, nuestra empresa lo puede ayudar en la decisión de: Cuáles productos adquirir y Cómo implementarlo eficientemente.

Las Suites de productos IBM Rational abarcan todo el ciclo de vida del desarrollo del software, pero quizá su empresa sólo requiera eficientizar una de las etapas del mismo. Nuestros profesionales le ayudarán a identificar la herramienta específica para esa decisión y el método preciso para su implementación eficiente.

Algunos conceptos presentes en la Disciplina

Configuración

Las características funcionales y físicas de una versión especifica de hardware y elementos de software que combinados de acuerdo a procedimientos de construcción específicos cumplen un propósito particular.

Elementos de configuración de software

Definimos como un elemento de Configuración a una unidad física y/o lógica parte de un conjunto mayor de elementos, producida o adquirida, que por sus características es distinguible de las demás y cuya evolución interesa administrar.

Son elementos de Configuración en un proyecto de software:
01. El plan de proyecto.
02. El plan de Gestión de Configuración.
03. El documento de definición de requerimientos.
04. Estándares de análisis, diseño, codificación, pruebas, y auditoria.
05. Documentos de análisis del sistema.
06. Documentos de diseño del sistema.
07. Prototipos.
08. Documentos de diseño de alto nivel.
09. Documentos de diseño de bajo nivel.
10. Especificaciones de prueba del sistema.
11. El plan de pruebas del sistema.
12. El Código fuente del programa.
13. Código objeto y ejecutable.
14. Especificaciones de pruebas de unidad.
15. Planes de pruebas de unidad.
16. Documentos de diseño de base de datos.
17. Datos de prueba.
18. Datos del proyecto.
19 .Manuales de usuario.

Versión

Una versión es una instancia de un elemento de Configuración. El término se usa para señalar a un elemento de Configuración del software que tiene un conjunto definido de características funcionales.

Revisión

Se define revisión como una versión que se construye sobre otra versión anterior. El término revisión generalmente se asocia a la noción de corrección de errores, esto es, hacer cambios a un programa que corrigen solo errores en el diseño lógico pero no afectan las capacidades funcionales documentadas, dado que ningún requerimiento ha cambiado.

Variante

Se define variante como una versión que es una alternativa a otra versión. Las variantes pueden permitir a un elemento de Configuración satisfacer requerimientos en conflicto. Una variante es una nueva versión de un elemento que será añadida a la Configuración sin reemplazar a la versión anterior.

Por ejemplo, si se desarrolla una aplicación para varios sistemas operativos, algunas librerías pueden requerir modificaciones para poder ser compiladas o ejecutadas en los diferentes sistemas; la versiones para Unix y para Windows NT de una librería serían variantes del mismo elemento.

La creación de variantes implica la creación de ramas en un grafo de evolución.

Línea base

Una línea base es una especificación o producto revisado y aprobado formalmente, que sirve como base para el desarrollo posterior, y puede ser modificado solo a través de procedimientos formales de control de cambios.

El término también se usa para referirse a una versión particular de un elemento de software que ha sido aprobado. En cualquier caso, la línea base solo se puede modificar a través de procedimientos formales de control de cambios. Una línea base, junto con todos los cambios aprobados a la línea base, representa la Configuración aprobada actual.

Procesos Asociados: El estándar ISO/IEC 12207 ([ISO 12207]) para Procesos del Ciclo de Vida del Software, establece el Proceso de Gestión de Configuración como uno de los Procesos de Soporte del Ciclo de Vida. Un Proceso de Soporte ”apoya” a otro proceso como una parte integral, con un propósito distinto, y contribuye al éxito y a la calidad del proyecto de software.

Este proceso consiste de las siguientes actividades:

1. Implementación del Proceso: Se desarrolla un Plan de Gestión de Configuración que describe las actividades de Gestión de Configuración, los procedimientos y el cronograma para su realización, y los responsables de dichas actividades. Dicho plan debe ser documentado e implementado.

2. Identificación de la Configuración: Se establece un esquema de identificación de los elementos de software y sus versiones a ser controlados por el proyecto.

3. Control de la Configuración: Se identifican y registran las solicitudes de cambio, se analiza y evalúa los cambios, se aprueba o rechaza la solicitud, se implementa, verifica y distribuye el elemento de software modificado.

4. Contabilidad de Estado de la Configuración: Se preparan registros de Gestión y reportes de estado que muestren el estado e historia de los elementos de software controlados, incluyendo líneas base.

5. Evaluación de la Configuración: Se determina y asegura que los elementos de software sean funcionalmente (versus sus requerimientos) y físicamente completos (es decir, si su diseño y Código reflejan una descripción técnica actualizada).

6. Gestión de actualización y distribución: Se controla formalmente la actualización y distribución de los productos de software.

En la figura 1 se presenta un modelo de este proceso elaborado utilizando el perfil de UML para modelamiento de procesos de software, propuesto por el Object Management Group (OMG)

Entrada 8: Garantía de Calidad del Software (SQA):

Garantía de la calidad: Consiste en un conjunto de funciones de auditoría e información que evalúan la efectividad y qué tan complejas son las actividades de control de Calidad.

El SQA se puede definir como la conformidad a las necesidades funcionales y de rendimiento, a los estándares de desarrollo y a las características implícitas requeridas de todo el software que se ha desarrollado profesionalmente.

Objetivos:

1. La implementación de una disciplina de SQA tiene como principal objetivo aumentar la calidad de los entregables durante todo el proceso de desarrollo.

2. Muchos requerimientos de calidad, sobre todo aquellos que tienen que ver con el rendimiento, la usabilidad, la carga, la disponibilidad, etc. pueden ser tratados como riesgos. Es decir que, el hecho de que uno de ellos no se cumpla, implica un riesgo. Entonces, al asegurar la calidad del software durante su proceso, se disminuyen los riesgos asociados, aumentando la predictibilidad del desarrollo de software. Esto trae aparejado una serie de beneficios de variada visibilidad.

Ventajas:

1. Reducción de los tiempos de desarrollo, principalmente el tiempo de trabajo generado en la fase de testing.

2. Optimización del uso de los recursos, que disminuye el costo de la infraestructura necesaria para soportar la aplicación.

3. Disminución del costo de mantenimiento, ya que se generan aplicaciones más seguras y estables.

4. Aumento de la permeabilidad al cambio y facilidad para medir el impacto del mismo.

5. Asegura el cumplimiento de los requerimientos, tanto los funcionales como los de calidad.

6. Promueve el seguimiento de los estándares definidos.

7. Provee información sobre la calidad del proyecto a los stakeholders con menor conocimiento técnico.

8. Los desarrollos se vuelven más predecibles, facilitando las estimaciones


Operaciones:

El SQA se puede identificar como un patrón de acciones planeado y sistemático, que ayudan a asegurar alta calidad en el software de programas y aplicaciones.Hay diversas operaciones que vienen bajo SQA. Éstas se asocian generalmente a los siguientes dos conjuntos de personas:

Ingenieros de Software
Grupo SQA

Es responsabilidad de los ing. de software ocuparse de todo el trabajo técnico involucrado en actividades de aseguramiento y control de calidad.

Grupos SQA:

 Muchas organizaciones empiezan a crear grupos de SQA.

 Estas personas actúan como representantes internos del cliente.

 Es responsabilidad del grupo SQA ayudar a los Ing., a lograr una alta calidad en el programa o aplicación de software determinado.

 Este grupo tiene una serie de actividades que se presentan a continuación.

Actividades:




Para poder identificar estas actividades y el momento oportuno para realizarlas es necesario revisar el ciclo de vida de un proyecto.

Para identificar las actividades se basa en el análisis de fases/disciplinas/esfuerzo realizado en RUP por ser un proceso muy difundido en el mercado, aunque el mismo análisis puede aplicarse a otros procesos de desarrollo.

Analizando el diagrama, se aprecia que el esfuerzo de cada disciplina varía según la fase del proyecto. De aquí se deriva que el momento para controlar la calidad de cada disciplina es cuando mayor esfuerzo se le dedica.

El plan:

Esta es una herramienta que permite instituir la garantía de seguridad del software, desarrollado por el grupo de SQA este proporciona un plantilla de actividades, se debe tener en cuenta lo siguiente:

  1. El propósito y ámbito del plan
  2. Una descripción de todos los productos de software
  3. Estándares y prácticas aplicables a nuestro proceso.
  4. Las acciones y tareas del SQA.
  5. Las herramientas y métodos utilizados.
  6. Procedimientos de gestión de configuración.
  7. Métodos para salvaguardar, ensamblar y mantener los registros.
  8. Documentación, papeles y responsabilidades en la organización relativas a la calidad del producto elaborado.

Otras Actividades:

Verificación de requerimientos: esta actividad se concentra en validar la completitud, claridad y no ambigüedad de los requerimientos de un sistema.

Validación y verificación de documentación: esta actividad se encarga de controlar la corrección, completitud y no ambigüedad de la documentación. La documentación en UML es muy útil para esta práctica por el poder semántico que tiene y por la posibilidad de validar sintácticamente la documentación.

Validación de arquitectura: Esta actividad es muy importante para evaluar la factibilidad de cumplir con los requerimientos no funcionales y detectar de forma temprana los principales riesgos asociados al proyecto.

Control de código: Se subdivide en 2 actividades:

    1. Control estático del código: es la validación del código contra un conjunto de reglas, mejores prácticas y estándares predefinidos.

  1. Control dinámico del código: el control se focaliza en el uso de los recursos hace  la aplicación y la cobertura del código que hacen las pruebas unitarias


Tareas:

Es necesario tener en cuenta que para realizar algunas de estas actividades primero es necesario realizar otras actividades como ser:

Definición de estándares y mejores practicas de desarrollo
Elección de herramientas para documentar y desarrollar.

Estas tareas tienen que ver con el hecho que para poder validad la calidad de algo, es necesario contar, previamente, con la definición, requerimiento o estándar contra el cual validar. 

Historia:

Lo qué empezó en 1925 como un sitio imparcial utilizado para pruebas de una pequeña industria de llantas en vías de desarrollo en los alrededores de Akron, Ohio, se ha convertido en una familia multidisciplinaria de negocios de tecnología que dan servicio a un sin número de clientes a nivel internacional. Con el paso de los años, el nombre de Smithers ha llegado a ser sinónimo de calidad, integridad, profesionalismo y servicio.

Smithers Quality Assessments se incorporó en el Estado de Ohio en 1993. SQA obtuvo su primera acreditación por el Voor Raad Certificatae (RvC, ahora conocido como RvA) en noviembre 1993. En 1997, SQA fue acreditado también por la ANSI-ASQ Comité Nacional de la Acreditación (ANAB), cuerpo de acreditación con base en los Estados Unidos. SQA logró un reconocimiento internacional adicional en octubre 2000 cuando llegó a ser aprobado por el grupo de trabajo Automotor Internacional (IATF).

Hoy, SQA proporciona los servicios de certificación a una gran cantidad de industrias, negocios y compañías de servicio. Los sectores a los que serven incluyen también instituciones del gobierno de los EE.UU. y de su defensa nacional. Sus clientes son corporaciones grandes y multinacionales, industrias medianas y pequeñas organizaciones.

Niveles de Maduración:

Nivel 1: 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 proceso. Según el SEI, menos del 0,1% de las organizaciones del mundo se encuentran en nivel de madurez.

Entrada 7: Análisis y Gestión de Riesgo:





Agencia de Viajes Ski Light:

Tabla de Riesgo


Riesgo
Probabilidad
Impacto
Estrategia de recompensa





Riesgos del Proyecto

Presupuesto


0.40

critico
Utilizar métodos de medición para determinar el presupuesto de forma más acertada.

Planificación


0.25

Critico

Realizar un cronograma de actividades
Personal (asignación y Organización)

0.27

Critico
Asignar a cada quien la tarea que le corresponde con tiempo de trabajo establecido.

Recursos


0.37

Critico
Conseguir las herramientas necesarias para desarrollar el software

Clientes y sus Requisitos


0.24

critico
Determinar bien lo que el cliente requiere que realice el software (sus necesidades)

Impacto


0.4
Critico




Riesgos Técnicos

Diseño


0.32

Critico
Realizar un análisis previo para determinar  esta fase.

Implementación


0.22

critico

Asesorar a la empresa acerca de los requerimientos mínimos del sistema.

Interfaz


0.22

Critico
Centrarse especialmente en un diseño atractivo y de gran interés al usuario final.

Verificación


0.34

Critico
Revisar y verificar cada etapa del proceso de software.

Mantenimiento


0.34

Critico
Realizar pruebas periódicas al software según cuando el cliente lo requiera.








Riesgos del negocio

Riesgo de no encontrar demanda del software


0.25

critico

Realizar un previo estudio de mercado para determinar la demanda


Riesgo de no cumplir con los requerimientos reales



0.25


critico
Determinar las características funcionales y no funcionales que debe cumplir el software.

Riesgo de no venderlo por falta de estrategias



0.6


catastrófico

Promover el software por el medio más utilizados.

Riesgo de perder  el contacto c/ personal del negocio



0.5


Critico

Buscar como establecer una buena comunicación con el personal.

Riesgo de cierre de negocio


0.34

marginal
Establecer un contrato en el cual se pronuncien clausulas para el cumplimiento del mismo.

Probabilidad: 0- 1
Impacto:
§  Ca: Catrastrofica
§  Cr: Critico
§  Ma: Marginal
§  De: Despreciable


Fundación Fes:

Tabla de Riesgo


Riesgo
Probabilidad
Impacto
Estrategia de recompensa





Riesgos del Proyecto

Presupuesto


0.20

catastrófico
Utilizar métodos de medición para determinar el presupuesto de forma más acertada.

Planificación


0.30

Critico

Realizar un cronograma de actividades
Personal (asignación y Organización)

0.20

Critico
Asignar a cada quien la tarea que le corresponde con tiempo de trabajo establecido.

Recursos


0.50

catastrófico
Conseguir las herramientas necesarias para desarrollar el software

Clientes y sus Requisitos


0.35

critico
Determinar bien lo que el cliente requiere que realice el software (sus necesidades)

Impacto


0.6
Marginal




Riesgos Técnicos

Diseño


0.32

Critico
Realizar un análisis previo para determinar  esta fase.

Implementación


0.30

Despreciable

Asesorar a la empresa acerca de los requerimientos mínimos del sistema.

Interfaz


0.22

Critico
Centrarse especialmente en un diseño atractivo y de gran interés al usuario final.

Verificación


0.50

Marginal
Revisar y verificar cada etapa del proceso de software.

Mantenimiento


0.50

Marginal
Realizar pruebas periódicas al software según cuando el cliente lo requiera.








Riesgos del negocio

Riesgo de no encontrar demanda del software


0.25

critico

Realizar un previo estudio de mercado para determinar la demanda


Riesgo de no cumplir con los requerimientos reales



0.25


Catastrófico
Determinar las características funcionales y no funcionales que debe cumplir el software.

Riesgo de no venderlo por falta de estrategias



0.6


catastrófico

Promover el software por el medio más utilizados.

Riesgo de perder  el contacto c/ personal del negocio



0.25


Marginal

Buscar como establecer una buena comunicación con el personal.

Riesgo de cierre de negocio


0.34

marginal
Establecer un contrato en el cual se pronuncien clausulas para el cumplimiento del mismo.

Probabilidad: 0- 1
Impacto:
§  Ca: Catrastrofica
§  Cr: Critico
§  Ma: Marginal
§  De: Despreciable