viernes, 22 de octubre de 2010

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. 

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.

GSC es un conjunto de actividades aplicadas a la Línea Base para gestionar los cambios del software a lo largo del ciclo de vida e implica una revisión técnica formal (RTF) de los Elementos de Configuración del Software (ECS).
 
Los ECS son objetos que poseen sus nombres, atributos y relaciones entre ellos. Una manera fácil de obtenerlos, es respondiendo las preguntas orientadoras:

1.¿Cómo identifico y gestiono las diferentes versiones existentes de un mismo software (y su documentación)?
2. ¿Cómo controlo los cambios, antes y después que he entregado software al cliente?
3. ¿Quién tiene la responsabilidad de aprobar y asignar prioridades en los cambios (la organización o mi equipo de Trabajo)?
4. ¿Cómo garantizo que los cambios realizados han sido los adecuados?
5. ¿Qué mecanismos se usan para avisar a otros, de los cambios realizados?

Los cambios se clasifican como completos y parciales:

Cambios Completos: Implica una modificación general en las diversas líneas base. 
Y para ello se usa <NOMBRE SOFTWARE> V 1.0, 1.1, 1.2, ….
Cambios Parciales: Implica una modificación dirigida en alguna línea base. 
Y para ello se usa <NOMBRE SOFTWARE> V 1.0, 1.0.1, 1.0.2, …. 

En el caso de obtener otro software similar al existente. Se utiliza <NOMBRE SOFTWARE> V 1.0, 2.0, 3.0


jueves, 21 de octubre de 2010

Garantía de la Calidad del Software SQA


*** 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 de SQA

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

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 de SQA

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.

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 ingenieros de software ocuparse de todo el trabajo técnico involucrado en actividades de aseguramiento y control de calidad.

Grupo SQA

1. Muchas organizaciones empiezan a crear grupos de SQA.

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

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

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

Actividades del SQA
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 SQA

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 del SQA

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.

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

Tareas del SQA

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

1. Definición de estándares y mejores prácticas de desarrollo.
2. Elección de herramientas para documentar y desarrollar.
3. 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. 

Análisis y Gestión del Riesgo

*** Tabla de Gestión de Riesgo ***
*** Aplicadas a los Casos de Estudio ***

** Fundación FES **

** Agencia de Viajes Sky Light Tour **

Métricas del Software

** Orientadas al Tamaño - Método COCOMO **

El modelo COCOMO se basa en la existencia de tres niveles que ha de aplicarse según el estado en que se encuentre el desarrollo del proyecto.


-Estos tres niveles son:
  1. Modelo básico
  2. Modelo intermedio
  3. Modelo detallado

La función básica que utilizan los tres modelos es: 
donde:
a y b:  Son constantes con valores definidos en cada sub-modelo
Kl o KLOC: Es la cantidad de líneas de código excluyendo comentarios, en miles.
m(X):  Es un multiplicador que depende de 15 atributos.
El resultado se da en unidades salario/mes y horas-hombre. 

Cada sub-modelo también se divide en modos de trabajo que representan el tipo de proyecto, y puede ser: 

1. Modo Orgánico: Un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio).


2. Modo Semilibre o Semiencajado: Corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas. 

3. Modo Rígido o Empotrado: El proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.


 -- Nivel Básico

Se utiliza para obtener una primera aproximación rápida del esfuerzo. Y  hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:

Estos valores son para las fórmulas:

1. Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)
2. Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)
3. Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV
4. Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas.

NOTA: El valor de m(x) en el caso del modelo básico tiene como valor fijo la unidad.

Para calcular el número de meses estimados para el desarrollo, utilizamos la siguiente fórmula:
Donde:
E: Es el valor del esfuerzo calculado en la anterior ecuación.
c y d:  Son valores constantes que dependen de la clase o “modo” de proyecto que estemos evaluando.

-- Nivel Intermedio 

En este caso la ecuación de esfuerzo que rige este modelo es: 

 
Donde E, KLOC, a y b tienen el mismo significado que en caso del modelo básico, aunque el valor de a y b es diferente. La tabla para los valores de las constantes de las ecuaciones de esfuerzo (E) para este “modo” de proyecto es:


El valor de m(x) es el peso del factor de coste  Xj, y cuya expresión matemática es:
 
Cada factor es valorado por separado en una escala ordinal de seis puntos (muy bajo / bajo/ nominal / alta / muy alta / extra alta)


A partir de las tablas hechas públicas por Boehm se asigna un valor numérico a cada factor y se aplica la ecuación; el resultado es el factor de ajuste del esfuerzo.

-- Nivel Avanzado

Es un modelo que incorpora todas las características del modelo anterior pero realiza una evaluación de las “guías de coste” para cada una de las etapas que considera Boehm (Análisis/Diseño, Codificación y Prueba) y, por tanto, se puede aplicar cuando se tiene un conocimiento específico sobre cada una de las etapas básicas del proyecto.



** Orientadas a la Función y Ampliadas de Punto de Función **

- Orientadas a la Función:

Hay que completar la siguiente tabla de valores del dominio de la información:

  donde: 

Entradas de usuario. Son entradas que proporcionan diferentes datos a la aplicación. No confundirlos con las peticiones de usuario. 

Salidas de usuario. Son reportes, pantallas o mensajes de error que proporcionan información. Los elementos de un reporte, no se cuentan de forma separada. 

Peticiones de usuario. Es una entrada interactiva que produce la generación de alguna respuesta del software en forma de salida interactiva. 

Archivos. Son los archivos que pueden ser parte de una base de datos o independientes. 

Interfaces externas. Son los archivos que se usan para transmitir información a otro sistema. 

El punto de función FP se calcula con la siguiente ecuación:
                                                                PF = T * (0.65 + 0.01 * F)

- Ampliadas de Punto de Función:


Los puntos de función fueron diseñados originalmente para sistemas de información y por eso le da más importancia a los datos y menos a los aspectos de control y funcionales. Para subsanar esto, se han propuesto los puntos de característica y los puntos de función 3D.

Puntos de característica: Se calcula igual que el punto de función y solo agrega la cuenta de algoritmos. Se define un algoritmo como un problema de cálculo limitado que se incluye dentro de un programa de computadora específico.

Puntos de función 3D: Los puntos de función 3D se calculan llenando la siguiente tabla: 


donde: 

Estructuras internas de datos. Son arreglos, listas ligadas, pilas, colas, etc. 

Datos externos. Equivale a la suma de los archivos y las interfaces externas tal y como están definidos para el punto de función. 

Entradas de usuario. Definidas igual que para el punto de función. 

Salidas de usuario. Definidas igual que para el punto de función. 

Peticiones de usuario. Definidas igual que para el punto de función. 

Transformaciones. Son las operaciones internas requeridas para transformar datos de entrada en datos de salida. Multiplicar dos matrices cuenta como una transformación. Leer datos de un archivo y guardarlos en memoria no. 

Transiciones. Ocurre cuando el software pasa de un estado a otro como resultado de algún suceso. En un sistema de altas, bajas y cambios, al tomar la opción de altas, pasa del estado "menú principal" al estado "procesa altas" y puede ser que en ese momento pida datos para dar la alta.

- Calidad:

Muchas de las medidas que maximizan la calidad producen como efecto colateral una disminución en el coste, y viceversa. Tradicionalmente se piensa que aumentar la calidad es aumentar el coste en tiempo. Pero muchas veces el tiempo invertido en aumentar la calidad repercute en el futuro en un menor coste de desarrollo o mantenimiento.

Valores abstractos del software:

Robusto. Libre de errores.

Flexible. Permite reutilización y adaptación a nuevos requisitos.

Mantenible. Permite entender el código tiempo después de haber sido escrito y/o por personas que no lo escribieron (estándares de sintaxis y documentación).

Escalabilidad y rendimiento. Al aumentar el número de usuarios, el rendimiento no disminuye exponencialmente. 

Integridad. Mide la habilidad de un sistema para resistir a ataques ya sean accidentales o intencionales a su seguridad. Se pueden dar en los programas, datos y documentos.

La medición de la integridad define dos atributos:

Amenaza: Puede estimarse o deducirse es la probabilidad de que un ataque suceda en un tiempo determinado.
           
Seguridad: Existen herramientas que enfrentan a tu código a una base de datos de vulnerabilidades conocidas. También es la probabilidad de que se repela la amenaza.

Integridad = 1 – (amenaza x (1 – seguridad ))
Calidad = Errores / PF

- Organizaciones Pequeñas:

1. Tiempo transcurrido desde el momento en que se hizo la solicitud hasta que la evaluación esta completa.

2. Esfuerzo para realizar la evaluación.

3. Tiempo transcurrido desde que se completa la evaluación hasta la asignación del pedido de cambio de personal.

4. Esfuerzo requerido para hacer el cambio.

5. Tiempo requerido para hacer el cambio.

6. Errores descubiertos durante el trabajo para hacer el cambio.

7. Defectos descubiertos después de que el cambio es liberado a la base de cliente.

BIBLIOGRAFIA


** Programa de Métricas y Planificación (Uso de MSPROJECT) **

Microsoft Project (o MSP) es un software de administración de proyectos diseñado, desarrollado y comercializado por Microsoft para asistir a administradores de proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo.



 Aplicación de las Métricas Orientadas al Tamaño y Orientadas a la Función a los Casos de Estudio



1. Objetivos del Negocio:

Mejorar la gestión de fondos Asignados a los diversos programas que ejecutan en Nicaragua.

2. Nuevos Saberes/Aprendizajes:

Actualmente la fundación Fredrick Ebet Stiffurd (FES), están aprendiendo automatizar sus actividades, lo prioritario es la agenda de eventos (lugar, fecha, cantidad de participantes, invitaciones, confirmaciones y llenado de datos, expositores, temas, documentos, materiales de apoyo, refrigerio o alimentos, entre otros recursos requeridos), posteriormente realizan informes, resumen de los temas, incorporan fotos y lo publican a fin de establecer comentarios al respecto y con ellos hacer encuestas y gráficos.  
  
3. Sub objetivos:

Prioridad: Eventos
                Lugar
                Fecha
                Medios Audiovisuales

Participantes: Invitaciones
                     Confirmaciones
                     Llenado de Datos
                     Expositores

 Exponencias: Documentos
                      Materiales
                      Refrigerio y Alimentos

Otros Recursos: Informes
                         Resumen
                         Fotos/Videos
                         Publicaciones
                         Comentarios
                         Encuestas/ Gráficos

 4. Entidades y Atributos de los Sub Objetivos: 

Caso de Uso

Diagrama de Dominio
Diagrama de Clase

5. Objetivos de Medición:

Si no se mide, no hay una forma real de determinar si se está mejorando. Y si no se está mejorando, se está perdiendo tiempo, dinero y esfuerzo. Además q el medir nos da una visión y nos ayuda o dirigir nuestras acciones.


6. Preguntas cuantitativas e Indicadores relacionados: 


7. Recolecta de datos y Cálculos: 


El modo de trabajo es Rígido y el modelo es Básico


Calcular el Punto de Fusión

Evaluación de 0 – 5

Fi = 45
Pf = 800*[0.65+0.01*45] = 880
Kl = 880/1000 = 0.88

Tabla de Constantes del Modelo Básico

P = 3.6*(0.88)1.2
P = 3.08 = 3 personas

T = 2.5*(3.08)0.32= 3.58 = 3 meses y medio

CT = [3.08/3.58]*350
CT = 301.12 ganancia


8. Medidas a usar (Definición Operativa de los Resultados): 


     En el cálculo de Pf se contabilizan en total 800 entradas de parámetros teniendo 4 de estos un factor de ponderación de grado complejo (#Entradas, #Salidas, #Peticiones, #Interfaces) y 1 de grado medio (#Archivos), un valor de ajuste de complejidad (Fi) de 45, el resultado de Pf se utiliza de forma análoga en las LDC como forma de normalizar las medidas de productividad, calidad y otros atributos del software.

     En el cálculo estimado de personal aplicado al desarrollo del software dio como resultado 3, estos según el cálculo seria el número de personas necesarias por mes para llevar adelante el proyecto en un tiempo aproximado de 3 meses y medio, con un salario medio de $ 301.12.


9. Acciones de Mejora:

 
     El cálculo de MM (personas necesarias por mes para llevar adelante el proyecto) nos muestra un resultado de 3, anexando una persona más agilizaríamos el trabajo aunque la ganancia disminuya, pero el esfuerzo disminuiría un poco y el tiempo de realización del software también. 

- Agencia de Viajes Sky Light Tours:


1. Objetivo:
Desea realizar una mercadotecnia defensiva de sus servicios de viajes y paquetes turísticos.

2. Prioridad:
          Servicios de Viajes
          Paquetes Turísticos

Diagrama de Caso de Uso

Diagrama de Dominio
Diagrama de Clase

3. Recolecta de Datos y Cálculos:



El modo de trabajo es Rígido y el modelo es Básico
Calcular el Punto de Fusión
Evaluación de 0 – 5
Fi = 47
Pf = 658*[0.65+0.01*47] = 736
Kl = 736/1000 = 0.736

Tabla de Constantes del Modelo Básico
 
P = 3.6*(0.88)1.2
P = 2.4 = 2 personas


T = 2.5*(2.4)0.32 = 3.30 = 3 meses

CT = [2.4/3.30]*350
CT = 255 ganancia


4. Interfaz