Gestión de la Configuración del Software

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.

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.

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 ungrafo 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.

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.

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.

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.

Garantia de la Calidad de 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, yprueba 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.

Contenido 1 Ventajas de la SQA 2 Metodología de la SQA 3 Vea también 4 Referencias 5 Acoplamientos externos

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, testimonials 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 unprofessional, 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 otros 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é medios 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 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. 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.

Análisis y Gestión de Riesgo

Métricas del Software

Métricas de Software

-Modelo Cocomo

El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para estimación de costes¹ de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.

Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).

Características

Pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en líneas de código principalmente.

Inconvenientes

§  Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizarlas.

§  Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el código fuente.

§  Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser "vistos" de distinta manera por distintos analistas que usen el método.

§  Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la productividad.

§  La medición por líneas de código no es válida para orientación a objetos.

§  Utilizar este modelo puede resultar un poco complicado, en comparación con otros métodos (que también sólo estiman).

Modelos de estimación

La ecuaciones que se utilizan en los tres modelos son:²

§  E = a(Kl)^b * m(X), en persona-mes

§  Tdev = c(E)^d, en meses

§  P = E / Tdev, en personas

donde:

§  E es el esfuerzo requerido por el proyecto, en persona-mes

§  Tdev es el tiempo requerido por el proyecto, en meses

§  P es el número de personas requerido por el proyecto

§  a, b, c y d son constantes con valores definidos en una tabla, según cada submodelo

§  Kl es la cantidad de líneas de código, en miles.

§  m(X) Es un multiplicador que depende de 15 atributos.

A la vez, cada submodelo también se divide en modos que representan el tipo de proyecto, y puede ser:

§  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).

§  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.

§  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.

Modelo básico

Artículo principal: COCOMO 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:

MODO	a	b	c	d
Orgánico	2.40	1.05	2.50	0.38
Semilibre	3.00	1.12	2.50	0.35
Rígido	3.60	1.20	2.50	0.32

Estos valores son para las fórmulas:

§  Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Kl^b)

§  Tiempo de desarrollo del proyecto (TDEV) = c*(MM^d)

§  Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV

§  Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas.

Se puede observar que a medida que aumenta la complejidad del proyecto (modo), las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal. Hay que utilizar con mucho cuidado el modelo básico puesto que se obvian muchas características del entorno

Modelo intermedio

Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación.²

Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de aplicar los atributos que se decidan utilizar.

Los valores de las constantes a reemplazar en la fórmula son:

MODO	a	b
Orgánico	3.20	1.05
Semilibre	3.00	1.12
Rígido	2.80	1.20

Se puede observar que los exponentes son los mismos que los del modelo básico, confirmando el papel que representa el tamaño; mientras que los coeficientes de los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor del semilibre con respecto al efecto multiplicador de los atributos de coste.

Atributos

Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo - bajo - nominal - alto - muy alto - extremadamente alto. Dependiendo de la calificación de cada atributo, se asigna un valor para usar de multiplicador en la fórmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy alto, el resultado de la fórmula debe ser multiplicado por 1000).

El significado de los atributos es el siguiente, según su tipo:

§  De software

§  RELY: garantía de funcionamiento requerida al software. Indica las posibles consecuencias para el usuario en el caso que existan defectos en el producto. Va desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida de vidas humanas (extremadamente alto, software de alta criticidad).

§  DATA: tamaño de la base de datos en relación con el tamaño del programa. El valor del modificador se define por la relación: D / K, donde D corresponde al tamaño de la base de datos en bytes y K es el tamaño del programa en cantidad de líneas de código.

§  CPLX: representa la complejidad del producto.

§  De hardware

§  TIME: limitaciones en el porcentaje del uso de la CPU.

§  STOR: limitaciones en el porcentaje del uso de la memoria.

§  VIRT: volatilidad de la máquina virtual.

§  TURN: tiempo de respuesta requerido.

§  De personal

§  ACAP: calificación de los analistas.

§  AEXP: experiencia del personal en aplicaciones similares.

§  PCAP: calificación de los programadores.

§  VEXP: experiencia del personal en la máquina virtual.

§  LEXP: experiencia en el lenguaje de programación a usar.

§  De proyecto

§  MODP: uso de prácticas modernas de programación.

§  TOOL: uso de herramientas de desarrollo de software.

§  SCED: limitaciones en el cumplimiento de la planificación.

Modelo Detallado

Presenta principalmente dos mejoras respecto al anterior:²

§  Los factores correspondientes a los atributos son sensibles o dependientes de la fase sobre la que se realizan las estimaciones. Aspectos tales como la experiencia en la aplicación, utilización de herramientas de software, etc., tienen mayor influencia en unas fases que en otras, y además van variando de una etapa a otra.

§  Establece una jerarquía de tres niveles de productos, de forma que los aspectos que representan gran variación a bajo nivel, se consideran a nivel módulo, los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel sistema.

Modelo Cocomo II

El nuevo modelo incorporado en el año 1990, tiene características de los modelos COCOMO 81 y Ada COCOMO. COCOMO II tiene también tres submodelos ; El modelo de composición de la aplicación es usada para estimar el esfuerzo y planificación de proyectos que usa las herramientas integradas CASE (Computer Aided Software Engineering) para un desarrollo rápido de la aplicación.

Realizando una comparación entre COCOMO 81 y COCOMO II; a este último se le añadió nuevos manejadores de costos para la aplicaciones precedentes, flexibilidad en el desarrollo, necesita documentación para el ciclo de vida, múltiples sitios de desarrollo y requiere software reusable.

Modelo COCOMO II post-arquitectura cubre el actual desarrollo y mantenimiento de un producto de software. Esta etapa del ciclo de vida procede mas a un costo efectivo, si el ciclo de vida de una arquitectura de software ha sido desarrollada, validada con respecto a la misión del sistema y establecida como un marco de trabajo para el producto.

El modelo de post-arquitectura predice el esfuerzo de desarrollo del software, personas-mes (PM), utiliza un conjunto de 17 multiplicadores de manejadores de costo (EM) y un conjunto de 5 escalas de manejadores de costo para determinar la escala del exponente del proyecto (SF). Esta escalas de los manejadores de costo remplazan los modos de aplicación (orgánico, sem.-acoplado y acoplado); el modelo tiene la siguiente forma:

PM = A * (Size) 1.01 + “j5= 1*

---

 I17= 1 Emil

Los manejadores de costo tiene para elegir una de las seis posibilidades que son: Very Low (VL), Low (L), Nominal (N), High (H), Very High (VH), y Extra High (XH); no todos los rangos son válidos para todos los manejadores de costo.

ADA COCOMO

Barrí Bohema & Walter Rocíe, 1987, 1988 definen el nuevo modelo COCOMO, llamado “Ada COCOMO”.

Este modelo al igual que el COCOMO estándar utiliza los manejadores de costo y ecuaciones anteriormente definidas.

COCOMO INCREMENTAL

Fue definido casi al mismo tiempo que Ada COCOMO. EL modelo COCOMO Incremental es una moderna alternativa para el tradicional modelo cascada de el desarrollo de procesos de software.

El modelo de desarrollo Incremental COCOMO permite una variedad de desarrollo de procesos. En vez de modelar el software como a esfuerzo simple para obtener un producto simple; el modelo incremental COCOMO permite desarrollar una serie de proyectos de software concurrente y producir un producto intermedio.

Esta estrategia reduce risk y permite entregar un producto inicial más fácilmente al cliente.

También existen algunas derivaciones de COCOMO como ser:

• Cocots, (Constructive Cost)
• Cossemo, (Constructive Staged Schedule & Effort Model).
• Copromo, (Constructive Productivity Improvement Model).
• Coqualmo
• Coradmo

• CONCLUSIONES

Al realizar el trabajo de investigación acerca de COCOMO llegamos a las siguientes conclusiones:

• COCOMO es una herramienta basada en la líneas de código la cual le hace muy poderoso para la estimación de costos y no como otros que solamente miden el esfuerzo en base al tamaño.
• Hoy en día es necesario para un administrador de proyectos posser una herramienta de estimación de costos; y esta herramienta puede ser COCOMO.
• COCOMO representa el más extenso modelo empírico para la estimación de software publicado hasta la fecha.
• Existen herramientas automáticas que estiman costos basados en COCOMO como ser: Costar, COCOMO 81.
• Con la realización de este trabajo ampliamos nuestro conocimientos acerca de la estimación de costos que es fundamental para un analista, administrador de proyecto.

Métrica Orientada a la Función

Las  métricas del Software orientadas a la función utilizan una medida de la funcionalidad entregada por la aplicación como un valor de normalización.
El  punto de función proviene de las medidas del dominio de información y de una evaluación subjetiva de la complejidad del problema.
Los puntos de función se calculan y se completan en una tabla diseñada para tal  fin. Se determinan cinco características de dominios de información y se proporcionan las cuentas en la posición apropiada de la tabla. Los valores de los dominios de información se definen de la siguiente manera:
Número de Entradas de Usuarios; se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicación. Se deben diferenciar las entradas de las peticiones, ya que se cuentan en forma separada.
Número de Salidas de Usuario: se cuenta cada salida que proporciona al usuario información orientada a la aplicación. Las salidas serán: informes, pantallas, mensajes de error.
Número de Peticiones de Usuario: una petición se  define como una entrada interactiva que produce la generación de alguna respuesta del Software inmediata en forma de salida interactiva.
Número de Archivos: se cuenta cada archivo maestro lógico, es decir, un  grupo lógico de datos que puede conformar una Base de datos o un archivo independiente.
Número de Interfaces Externas: se cuentan todas las interfaces legibles por la máquina que se utilizan para transmitir información a otro sistema.
Una vez calculados los puntos de función se utilizan de forma análoga a los LDC como forma de normalizar las medidas de productividad, calidad y otros atributos del Software.

2.4.3. Métricas Ampliadas de Punto de Función

La medida de punto de función individualmente se diseño para aplicarse a sistemas de gestión, pero resultaba inadecuada para otros sistemas de Ingeniería y sistemas empotrados que enfatizan función y control, en consecuencia se propuso extender el punto de función básica.
Una extensión del punto de función es la llamada puntos de características, el cual constituye una ampliación de la medida del punto de función que se puede aplicar a sistemas y aplicaciones de ingeniería del Software en tiempo real, de control y de proceso por la complejidad de sus algoritmos.
Los algoritmos definen un problema de cálculo limitado que se incluye dentro de un programa de computadora específico.
Las características de las tres dimensiones del Software se cuentan, cuantifican y transforman en una medida que proporciona una indicación de la funcionalidad entregada por el Software, llamada punto de función.
La dimensión de datos se calcula tal cual se explico en el punto de función básico.
La dimensión funcional se mide considerando el número de operaciones internas requeridas para transformar datos de entrada en datos de salida.
La dimensión de control se mide contando el número de transiciones entre estados. Un estado representa algún modo de comportamiento externamente observable, y una transición ocurre como resultado de algún suceso que cambia el modo de comportamiento del Software.

Métricas Orientadas a la Calidad

La Ingeniería del Software tiene como objetivo principal producir un sistema o aplicación de alta calidad, para lograr esta evaluación de la calidad en tiempo real se deben utilizar medidas técnicas que evalúan la calidad con objetividad y no subjetivamente.
La  calidad de un sistema debe ser tan buena como los requerimientos que describen el problema, el diseño que modela la solución, el código que conduce el programa y las pruebas que se aplican al Software para detectar errores.
Los Ingenieros del Software utilizan para lograr el Software de alta calidad mediciones que evalúan la calidad del análisis, modelos de diseño, código fuente y los casos de prueba que se preparan para aplicar al sistema o  Software desarrollado con la finalidad de detectar fallas o errores a fin de mejorar y conseguir la máxima calidad del producto.

2.5.1 Visión General de los Factores que afectan a la Calidad

Los factores de calidad empleados para el desarrollo de métricas de calidad de Software, evalúan el Software desde tres puntos de vista:
Operación del producto 
Revisión del producto 
Transición del producto, cuando se modifica para que funcione en otro entorno.
La relación entre estos factores de calidad constituye un mecanismo para que el gestor del proyecto identifique lo que se considera realmente importante. Estas  cualidades son atributos  del Software, además de su corrección y rendimiento funcional, que tiene implicaciones en el ciclo de vida, se deben considerar otros factores como lo son la facilidad de mantenimiento y portabilidad.
El marco de trabajo proporciona además un medio de evaluar cuantitativamente el avance del desarrollo en relación con los objetivos de calidad establecidos, aunado  a  la interacción  del personal QA (garantía de calidad) en el esfuerzo desarrollo y la utilización de estándares e indicadores que puedan ser utilizados en proyectos futuros; por ejemplo una lista de verificación.

2.5.2. Medidas de la Calidad

Entre las medidas de la calidad del Software más utilizadas se tienen:
Corrección: el valor agregado de un programa depende de que  opere  o  funcione correctamente. La medida más común de corrección  es  defectos por KLDC,  en donde un defecto se  define como una falta  verificada  de  conformidad  con  los  requisitos. 
Facilidad  de  mantenimiento:  se   refiere  a   la  facilidad  con  la  que  se  puede   corregir un programa si se detecta un error, donde se puede adaptar sí su entorno  cambia, o  mejorar  si  el  cliente  desea  un cambio de requisitos. Se recomienda  utilizar medidas indirectas. Por otro lado, también  se  puede  utilizar  una  métrica  orientada al costo para la capacidad  de  mantenimiento  llamada  Desperdicios, la cual se refiere al coste   en  corregir  defectos  encontrados después de haber distribuido el Software a sus usuarios finales.  
Integridad: este  atributo mide la capacidad de un sistema  para  resistir   ataques  accidentales o intencionados contra su seguridad. El ataque se puede realizar en cualquiera de los tres componentes del Software: programas, datos y documentos.