UNIVERSIDAD AUTONOMA DEL ESTADO DE MEXICO

PROGRAMA DE ESTUDIOS POR COMPETENCIAS:

MÉTRICAS DE SOFTWARE

ÁREA DE DOCENCIA: PROGRAMACIÓN E INGENIERÍA DE SOFTWARE

CRÉDITOS: 6

CICLO ESCOLAR: 2019 - A

AUTORES: Dra. ANA LUISA RAMÍREZ ROJA

CRISTOPHER JOSUE BAUTISTA VASQUEZ

Menú

ˇ Objetivo de la Asignatura

ˇ Datos de Identificación

ˇ Guion Explicativo

ˇ Introducción

ˇ Sección 1: Ingeniería de Software

ˇ Crisis del Software

ˇ Causas de la Crisis del Software

ˇ Objetivos de Ingeniería del Software

ˇ Cuatro P ́s

ˇ Persona

ˇ Producto

ˇ Proceso

ˇ Proyecto

ˇ Teoría de la medición del software

ˇ Historia de la medición en el software

ˇ Métricas de calidad de software

ˇ Beneficios y ejemplos del uso de métricas de calidad de software

ˇ Medidas, métricas e indicadores

ˇ Métricas del proceso y del proyecto

ˇ Ingeniería de requerimientos

ˇ Control de riesgos

ˇ Clasificación de métricas

ˇ Modelos de procesos

ˇ Modelo COCOMO

ˇ El modelo de McCall.

ˇ ISO/IEC 9126

ˇ Gráficos Vectoriales

ˇ Introducción

ˇ Calidad del producto

ˇ Adecuación Funcional

ˇ Atributos de Calidad de un Sw (Software)

ˇ Eficiencia de desempeńo

ˇ Compatibilidad

ˇ Fiabilidad

ˇ Seguridad

ˇ Mantenibilidad

ˇ Portabilidad

ˇ Vector de Calidad

ˇ Cálculo de Calidad

ˇ Métricas del producto

ˇ Fan-in/Fan-out

ˇ Longitud del código

ˇ Complejidad ciclomática

ˇ Longitud de los identificadores

ˇ Profundidad del anidamiento de las condiciones

ˇ Índice de Fog

ˇ Tamańo físico del software

ˇ Métricas de McCabe

ˇ Métricas de Halstead

ˇ Medidas de Complejidad ciclomática

ˇ Líneas de código

ˇ Puntos de función

ˇ Métricas de software orientada a objetos

ˇ Calidad del proceso de un Sw

ˇ Método de trabajo

ˇ Beneficios para los clientes

ˇ Componentes de desarrollo de un Sw, actividades y escala

ˇ RESULTADOS Y DISCUSIÓN

ˇ CONCLUSION

ˇ

OBJETIVO DE LA ASIGNATURA:

La calidad en el desarrollo y mantenimiento del software se ha convertido hoy en día en uno de los principales objetivos estratégicos de las organizaciones, debido a cada vez más, los procesos principales de las organizaciones dependen de los sistemas informáticos para su buen funcionamiento.

En la evolución experimentada por la calidad del software se ha pasado de un tratamiento centrado fundamentalmente en la inspección y detección de errores, a una aproximación más sistemática, dada la importancia que ha adquirido la calidad en la ingeniería del software. En los últimos ańos se han publicado diversos estudios y estándares en los que se exponen los principios que se deben seguir para la mejora tanto de productos como de procesos de software. Todo ello ha influido de forma significativa en el papel que actualmente tiene la calidad en las organizaciones, que pasa de convertirse en una filosofía y una cultura que afecta a toda la organización.

DATOS DE IDENTIFICACIÓN:

http://web.uaemex.mx/CUEcatepec/assets/mpc-ico.pdf

GUION EXPLICATIVO:

El siguiente trabajo se usa de manera similar a la de una página web, se tiene que abrir por medio de un buscador web, ya sea, Google Chrome, Internet Explorer, Mozilla, etc., por lo que se puede visualizar desde cualquier buscador.

El trabajo esta estructurado en forma de una Single Page Aplication (SPA), es decir que todo el contenido del mismo esta en la misma página y no es necesario acceder a diferentes páginas.

En el presente trabajo se cuenta con enlaces los cuales lo llevaran a páginas externas, las cuales contienen información para poder complementar la información que se presenta en este trabajo, los hipervínculos se encuentran subrayados por una línea azul, al dar clic sobre ellos se podrá acceder a la página con información adicional.

INTRODUCCIÓN

Se sabe (o conoce) que algunas de las actividades de desarrollo del proyecto de software comprenden medición y métricas, estimación, análisis de riesgo, planificación del programa, seguimiento y control.

El recopilar datos (investigación histórica), calcular métricas (LDC, PF, métricas de calidad, orientadas a objetos, etc.) y evaluar métricas, son algunos de los pasos que se deben realizarse al comenzar un producto. Hoy día es cada vez más frecuente la consideración de métricas de software, es por eso que sé están implantando en la actualidad, llevando consigo puntos débiles (aumento de esfuerzo...) y fuertes (alta calidad, reusabilidad, madurez...) que están experimentado los ingenieros y administradores de software.

El uso de éstas se ha adoptado con éxito en el amplio mercado de desarrollo de software introduciendo reconocimientos y consideraciones por parte de administradores y usuarios, y estableciendo la necesidad de un enfoque más disciplinado y de una alta calidad.

Así muchos particulares y compańías desarrolladoras de software, están reconociendo la importancia del uso de las métricas, aunque de igual modo siguen sin conocer el alcance de madurez y calidad del producto final y la disciplina de ingeniería madura que llega a alcanzar con la aplicación de los distintos métodos y técnicas y la interpretación de los resultados que proyecta el uso de las métricas.

Ingeniería de software

LA CRISIS DEL SOFTWARE

El término Crisis del Software fue acuńado a principios de los ańos 70, cuando la ingeniería de software era prácticamente inexistente. El término expresaba las dificultades del desarrollo de software frente al rápido crecimiento de la demanda por software, de la complexidad de los problemas a ser resueltos y de la inexistencia de técnicas establecidas para el desarrollo de sistemas que funcionaran adecuadamente o pudieran ser validados.

La percepción de que esta crisis existía empezó a mediados de los ańos 60. Una de las primeras referencias al término, y de las más notables, fue hecha por E.W.Dijkstra, en el discurso que pronunció durante la entrega del premio Turing en 1972.

CAUSAS DE LA CRISIS DEL SOFTWARE

Durante finales de los ańos 50 i principios de los 60, la potencia computacional de las maquinas era bastante limitada. Es por esto que los programas que se desarrollaban eran simples desde nuestro punto de vista actual. Seguían un proceso de desarrollo bastante artesanal, sin una metodología o un camino a seguir para su desarrollo. En esta época se solían usar los lenguajes de bajo nivel para el desarrollo de Software.

Pero a finales de los 60, la potencia de las maquinas empezó a aumentar de forma considerable. Empezaron a aparecer los lenguajes de programación de alto nivel, y las maquinas necesitaban programas mucho más complejos de los desarrollados hasta la época. En definitiva, fue un salto tremendo en cuanto a potencial de hardware, que no fue acompańado por un salto en el desarrollo de software.

En esta época, se empezó a concebir el Software como producto, y se empezaron a desarrollar algunos proyectos para que funcionaran en las máquinas de la época. Pero aparecieron importantes problemas: los productos excedían la estimación de costes, había retrasos en las entregas, las prestaciones no eran las solicitadas, el mantenimiento se hacía extremadamente complicado y a veces imposible, las modificaciones tenían un coste prohibitivoen resumen, se desarrollaba software de mala calidad, ya que la técnica utilizada para desarrollar pequeńos programas para maquinas con mucho menos potencial se quedaba desfasada, y muchas veces este software acababa en el olvido. Como ejemplo, podemos ver este gráfico del ańo 1979, en el que se recoge la inversión en desarrollo de sistemas software en ese ańo ($6.8 Millones), y como acabó ese software.

Una de las principales causas de todo esto, si no la principal, era el enfoque dado al proceso de desarrollo de software, el cual era malo e incluso a veces era inexistente. En este proceso, solo ź del tiempo de desarrollo se dedicaba a las fases de análisis, diseńo, codificación y pruebas, y más de ž del tiempo se dedicaba a correcciones y mantenimiento. Es evidente que dedicándole sol ź del tiempo a las primeras fases, se arrastran errores graves, sobre todo procedentes de las fases de análisis y diseńo, lo que dificultaba muchísimo la implementación, produciendo constantes paradas y retrocesos para revisar este análisis/diseńo.

Para que nos hagamos una idea, el conjunto de las fases de análisis y diseńo abarcaban el 8% del tiempo total de desarrollo de software. Además casi el 80% de los errores se producían en estas dos fases, con lo que se incrementaba el coste de corrección de errores conforme evolucionaban las fases de manera bestial. Con estos indicadores estaba claro que algo estaba fallando y que el proceso de desarrollo de software necesitaba un cambio radical.

Objetivos de Ingeniería del Software

Los principales objetivos de la ingeniería de software son:

v Diseńar programas informáticos que se adecúen a las exigencias de la sociedad. Objetivos de la Ingeniería en Software

v Liderar y acoplar el desarrollo de programaciones complicadas.

v Actuar en todas las fases del ciclo de vida de un producto.

v Computar los costos de un proyecto y evaluar los tiempos de desarrollo.

v Realizar el seguimiento de costes y plazos.

v Liderar equipos de trabajo de desarrollo software.

v Estructurar la elaboración de evidencias que comprueben el perfecto funcionamiento de los programas y que se adaptan a los requerimientos de análisis y diseńo.

v Diseńar, construir y administrar bases de datos.

v Liderar y orientar a los programadores durante el desarrollo de aplicaciones.

v Incluir procesos de calidad en los sistemas, calculando métricas e indicadores y chequeando la calidad del software producido.

v Liderar y orientar a los programadores durante el desarrollo de aplicaciones.

v Incluir procesos de calidad en los sistemas, calculando métricas e indicadores y chequeando la calidad del software producido.

v Estructurar e inspeccionar el trabajo de su equipo de los técnicos de mantenimiento y los ingenieros de sistemas y redes.

Cuatro P ́s

Cuatro P ́s. Cuando se desea realizar una gestión adecuada, eficaz y eficiente en la Gestión de Proyectos de Software, es necesario que se ponga en funcionamiento cuatro características muy importantes en esta gestión, las cuatro P: personal, producto, proceso y proyecto.

Persona

El factor humano siempre será el más importante en el desarrollo de soluciones de software, muchos empresarios famosos, líderes de empresas tecnológicas, coinciden que el éxito que han alcanzado sus empresas no se debe a las herramientas que utilizan, son las personas y el trabajo en equipo.

Por todos los medios posibles se debe atraer el personal talentoso e inteligente que desea superarse y sobre todo, desea trabajar en equipo para la realización del proyecto en que participe. El reclutamiento y selección es fundamental en la gestión del personal, aquí se ve realmente cuáles son las personas que están en la capacidad de aportar a la organización, y no sólo eso, también se ve si pueden trabajar bajo presiones y sobre todo en equipo.

El proceso de software está integrado por participantes, líderes de equipo, arquitectos, desarrolladores, ingenieros de prueba, personal de gestión, usuarios, clientes, etc. Los participantes se los puede clasificar en cinco categorías:

v Gestores ejecutivos: Definen los aspectos del negocio.

v Gestores del proyecto: Planifican, motivan, organizan y controlan a los profesionales que construyen el software.

v Profesionales: Proporcionan las habilidades técnicas necesarias.

v Clientes: Especifican los requerimientos.

v Usuarios finales: Interactúan con el software.

Los líderes de equipo juegan un importantísimo papel puesto que deben ser capaz de motivar al personal técnico para que produzca lo mejor sobre la base de su capacidad. El equipo de software debe ser uno solo, es decir, funcionar como conjunto, apoyarse mutuamente con el fin de lograr el cumplimiento de los objetivos planteados. Todos los miembros del equipo deben tenerse confianza y distribuir la carga de trabajo según el problema que se esté tratando. No todo equipo es eficiente, pero se puede lograr esto con la suficiente motivación y el apoyo de un buen gestor de proyectos.

Producto

Se denomina productos a todos aquellos artefactos que se creen durante la vida del proyecto, modelos, códigos, ejecutable, documentación, diagramas UML, bocetos de la interfaz de usuario, prototipos, componentes, planes de prueba, ingeniería y gestión, colección de modelos, modelos de casos de uso, análisis, diseńo, despliegue, implementación y prueba. Antes de planear un proyecto, se deben establecer los objetivos y el alcance que tendrá el proyecto, además de sus restricciones, herramientas, técnicas y planes de gestión. Con una buena planificación se puede estimar el tiempo que tomará desarrollar o construir el producto y redimensionar el valor cuantitativo del mismo.

Definidos los objetivos y el dominio del producto se determinan soluciones alternativas y viables. Para lograr rapidez en la construcción del producto, se debe dividir la carga de trabajo entre el equipo de desarrollo, es decir, dividir el problema. Esto, con el fin de desarrollar con mayor eficiencia y eficacia y en el tiempo acordado con el cliente, el producto.

Proceso

Se denomina proceso al conjunto de actividades que se realizan para crear el producto (Plantilla para crear el proyecto). El proceso se define en términos de flujos de trabajo (conjunto de actividades), se identifican trabajadores y artefactos, además de que se utilizan diagramas de actividad de UML para describir los flujos de trabajo. El equipo de desarrollo debe elegir el proceso adecuado y que le permita obtener una solución o producto que satisfaga las necesidades o requerimientos del cliente.

Seleccionado el modelo de procesos, se desarrolla una planeación preliminar del proyecto basado en las actividades del marco de trabajo. Esta planeación comienza con la combinación del producto y el proceso. Cuando el equipo de desarrollo de software ha definido correctamente el modelo de proceso, debe de asegurarse de que este sea flexible y adecuado para el proyecto

Proyecto

Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. Es un elemento organizativo de gestión que establece una secuencia de cambios, por el cual va evolucionando diariamente. El mismo establece una serie de iteraciones e hitos dentro de los cuales se desarrollan una serie de casos de usos o requisitos. Debemos tener en cuenta muchos parámetros para realizar un proyecto con la calidad requerida, y saber que existen factores que atentan con el buen desempeńo de un proyecto, estos son:

v El personal de software no entiende las necesidades de los clientes.

v El ámbito del producto está mal definido.

v Los cambios se gestionan mal.

v La tecnología elegida cambia.

v Las necesidades comerciales cambian.

v Los plazos de entrega no son realistas.

v Los usuarios se resisten a la utilización del software.

v Se pierde el patrocinio.

v El equipo del proyecto carece de personal con las habilidades apropiadas.

v Los gestores evitan las mejores prácticas y las lecciones aprendidas

Teoría de la medición del software

Historia de la medición en el software

La mayoría de las personas involucradas en el desarrollo de software ya sea de un área interna o una casa de software reconocen que medir en el software es fundamental, la frase Si no lo puedes medir no lo puedes controlar es dicha con mucha más frecuencia que lo que realmente se aplica.

Sin embargo, żqué es lo que se puede medir del software?, cada organización puede definir elementos a medir del software que realiza en función de sus prácticas y experiencias, sin embargo, esto no permite comparaciones con otras organizaciones o industrias, en virtud de que las unidades de medición son distintas.

En los ańos 70s (30 ańos aproximadamente) Allan J. Albrechts desarrolló una forma de medición funcional del software independiente de la plataforma de desarrollo y que consideraba el punto de vista del usuario, actualmente llamada Function Points (IFPUG Method), ésta técnica de medición considera conceptos vigentes para aquel tiempo cómo archivos lógicos, además tiene un alcance solo para aplicaciones de tipo MIS (Management Information System), en la actualidad existe una gran variedad de aplicaciones no solo las MIS, como lo son en tiempo real, ERP, DWH, etc.

Más tarde a finales de los ańos 80s (20 ańos aproximadamente) surgió un método llamado Mark II, este método estaba basado en transacciones lógicas y en el modelado de relaciones de entidades, populares en ese tiempo. Estos dos, y otros métodos como: 3D Function Points, Feature Points, FISMA, etc., son considerados de la primera generación de modelos de Medición de Tamańo Funcional (FSM: Functional Size Measurement).

Todos estos métodos se generan a partir de estudios estadísticos realizados en alguna empresa, el análisis de los proyectos expresa en sus resultados, la manera de operar de la empresa para los tipos de proyectos analizados, cuando se trata de utilizar en alguna otra empresa o con otro tipo de proyectos, usualmente los resultados no son buenos, la razón resulta obvia.

żPor qué tamańo funcional del software?, solo hay un estándar internacional (ISO 14143) que proporciona los meta-estándares que describen el concepto y prácticas de FSM. Dicho de otra forma, si queremos medir algo del software y poder compararlo o compararnos debe de ser el tamańo funcional, ya que es el único estándar para medir una característica del software, claro con alguna de las técnicas o estándares internacionalmente aceptados para esto.

La segunda generación de métodos de FSM está representada por COSMIC (Common Software Measurement International Consortium), este estándar se generó considerando como base el estándar ISO 14143 y la experiencia de los métodos de la primera generación, lo que implica que resuelve la mayoría de los problemas presentados dichos modelos como el manejo de conceptos actualmente no vigentes, el alcance de aplicación de los métodos y una escala de medición más práctica y homogénea, aunado a lo anterior tiene un dominio de aplicación mayor, por lo que se puede utilizar para todo tipo de software vigente al día de hoy, teniendo consideraciones para aquel software de gran complejidad algorítmica, pero esto es igual para cualquier estándar de medición, en virtud de que al día de hoy no existe un estándar para determinar cuantitativamente la complejidad del software.

Referencias:

https://sigcosmicmx.wordpress.com/2013/04/24/historia-breve-de-los-metodos-de-medicion-de-tamano-funcional-del-software/

Métricas de calidad de software

La generación de conocimiento necesita un poso de calidad que se extiende desde el dato mismo hasta el programa desarrollado para interactuar con la información. Las métricas de calidad de software permiten monitorizar un producto para determinar su nivel de calidad, aunque, el seguimiento que este tipo de medidas permiten llevar a cabo brinda la oportunidad de conocer muchas más cosas de una solución.

##

## Beneficios y ejemplos del uso de métricas de calidad de software

La mala calidad de la información y de software impacta negativamente en el negocio a diferentes niveles:

v Disminuye ingresos y aumenta el gasto.

v Incrementa el riesgo.

v Provoca una reducción de la confianza, tanto dentro como fuera de la organización.

Un enfoque proactivo tanto del gobierno de la información como del data quality permite la identificación temprana de errores o defectos que pueden ser corregidos a tiempo, eliminando de raíz problemas mayores. Los efectos positivos empiezan a notarse y sus beneficios aumentan en un ciclo de mejora continua propiciado por el control de las métricas de calidad de software.

Esta monitorización facilita el evaluar:

v La calidad del producto.

v El rendimiento del equipo de desarrollo.

v La justificación del uso de nuevas herramientas o soluciones.

v Los resultados obtenidos a partir de la incorporación del software a los procesos y operaciones.

Para conseguir llegar al nivel de evaluación, es preciso contar con datos relevantes, precisos y actualizados sobre diferentes áreas, que faciliten una perspectiva global de la solución. Así, las métricas de calidad de software pueden aplicarse a diferentes contextos, como:

1. El proyecto: son las que facilitan la gestión del riesgo permitiendo tomar el pulso a la iniciativa de desarrollo desde su inicio.

2. El producto: están enfocadas a medir las características del software y todos los entregables que lo acompańan, fruto del proyecto de desarrollo, como modelos, componentes adicionales y documentación.

3. El proceso: tienen por objeto identificar mejores prácticas para su exportación a futuros proyectos y, para conseguirlo, recopilan datos de distintas iniciativas a lo largo de un periodo de tiempo determinado.

Sin embargo, a la hora de centrarse en la solución en sí, existen algunas métricas de calidad de software imprescindibles, como las que tienen que ver con los cinco siguientes criterios:

v A/ Métricas de exactitud: intentan aportar información sobre la validez y precisión del software y su estructura, incluyendo la etapa de despliegue, pero también la de pruebas y la función de mantenimiento.

v B/ Métricas de rendimiento: a través de ellas se consigue medir el desempeńo del software, tanto de cada uno de sus módulos, como del sistema al completo.

v C/ Métricas de usabilidad: hay que descartar la complejidad y buscar una solución intuitiva y user-friendly. este tipo de métricas de calidad de software ayudan a determinar si la solución cumple con dichos requisitos.

v D/ Métricas de configuración: las limitaciones, el estilo de código y todos los datos relativos al desarrollo y cualidades del producto se verán evaluados en base a estas métricas.

v E/ Métricas de eficiencia: minimización de latencias, velocidad de respuesta, capacidad, es un enfoque similar al de la productividad, pero con un matiz un poco distinto, que ańadido a aquél, aporta una visión mucho más completa de la solución.

v De esta forma, evaluando el software a través de diferentes ópticas y en base a continuas mediciones, se puede ganar en alineación con el objetivo de calidad que, poco a poco, se irá sofisticando y para lograr alcanzar cotas superiores.

Referencia:

https://blog.powerdata.es/el-valor-de-la-gestion-de-datos/metricas-de-calidad-de-software-una-solucion-excelente

Medidas, métricas e indicadores

#### Medidas

Las medidas constituyen un aspecto fundamental para todos los ingenieros y, por tanto, los ingenieros del software deben conocer algunos aspectos de la teoría de medidas aplicadas a la ingeniería del software. Se han publicado gran cantidad de medidas del software, que miden distintos aspectos del software, pero no siempre todas ellas resultan apropiadas. La calidad del software es un tema candente en la actualidad y es necesario saber definir adecuadamente la calidad de un sistema informático y cómo evaluar dicha calidad mediante la utilización correcta de medidas. La aplicación de un modelo de calidad completo permite así mismo mejorar el proceso software y la calidad del software obtenido.

#### Métricas

Las métricas de software proporcionan una forma cuantitativa para valorar la calidad de los atributos internos de producto y, por tanto, permiten valorar la calidad antes de construir el producto. Las métricas proporcionan la comprensión necesaria para crear modelos efectivos de requerimientos y diseńo, código sólido y pruebas amplias.

Las métricas para el modelo de requerimientos se enfocan en los tres componentes del mo- delo: la función, los datos y el comportamiento. Las métricas para diseńo consideran arquitectura, diseńo en el nivel de componentes y conflictos en el diseńo de interfaz. Las métricas de diseńo arquitectónico consideran los aspectos estructurales del modelo de diseńo. Las métricas de diseńo en el nivel de componente proporcionan un indicio de la calidad del módulo al establecer medidas indirectas para cohesión, acoplamiento y complejidad.

#### Indicadores

Si bien es cierto que la calidad de un software depende mucho de la concepción del requerimiento, es mucho más importante saber lo que no se sabe al inicio. Hablamos de la elasticidad de un producto y su adaptación al cambio constante de requerimientos durante su construcción, para que su calidad no se degenere con el transcurso del tiempo. Y es por esa calidad esperada que desde el diseńo y la construcción se debe mantener la misma calidad posterior a la implantación que es el objetivo de esta investigación, especificando algunos indicadores que contribuyen a lograr dicho objetivo.

Referencia:

https://calidaddesoftwareutp.wordpress.com/medidas-metricas-e-indicadores/

Métricas del proceso y del proyecto

Ingeniería de requerimientos

żQué son Requerimientos?
Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuación se presenta la definición que aparece en el glosario de la IEEE .

(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2).

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

Características de los requerimientos
Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

Dificultades para definir los requerimientos:

v Los requerimientos no son obvios y vienen de muchas fuentes.

v Son difíciles de expresar en palabras (el lenguaje es ambiguo).

v Existen muchos tipos de requerimientos y diferentes niveles de detalle.

v La cantidad de requerimientos en un proyecto puede ser difícil de manejar.

v Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.

v Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.

v Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.

v Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

v Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

A continuación se darán algunas definiciones para ingeniería de requerimientos.
"Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm 1979.

"Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987.

"Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987.

"Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software

Control de riesgos

La gestión de riesgos es una actividad de protección dentro de la gestión de proyectos, encargada de identificar, mitigar y monitorizar los riesgos que pudieran afectar a la ejecución y viabilidad del proyecto.

Un riesgo es cualquier acontecimiento futuro que pueda afectar de forma negativa o positiva a un proyecto. No todos los riesgos tienen la misma probabilidad de ocurrir, ni el mismo impacto, por lo que a la hora de tratarlos nos preocuparemos de solucionar primero los más problemáticos. Los riesgos conllevan cambios, elecciones y dudas. Podremos conocer o no los riesgos, o simplemente son impredecibles.

Tipos de riesgos

Existen varios tipos de riesgos:

v Riesgos del proyecto.

v Riesgos técnicos.

v Riesgos del negocio.

### Riesgos del proyecto

Ponen en peligro al plan. Si estos se cumplen, el proyecto requerirá mayor esfuerzo y dinero. Estos están relacionados con:

v Presupuesto: se necesita una mayor inversión.

v Planificación: se necesita más tiempo.

v Personal: se necesitan más o mejores cualificados.

v Recursos: se necesitan más o mejores instrumentos.

v Requisitos: se necesitan más condiciones.

### Riesgos técnicos

Ponen en peligro la calidad resultante. Si estos se cumplen, el proyecto es más complejo de lo estimado. Estos están relacionados con:

v Requisitos: se necesitan más condiciones.

v Diseńo: se necesita una mejor arquitectura.

v Implementación: se necesita más tiempo o personal para finalizarse.

v Interfaz: se necesita un mejor estudio de usabilidad e interacción.

v Verificación: se necesita realizar más pruebas.

v Mantenimiento: se necesita más dedicación después de la entrega final.

v Incertidumbre técnica: se necesita mayor conocimiento sobre el área.

v Tecnologías desconocidas: se necesita mayor conocimiento sobre cómo realizar el proyecto de forma óptima.

### Riesgos del negocio

Ponen en peligro la realización del proyecto. Si estos se cumplen, el proyecto se cancelará. Estos están relacionados con:

v Utilidad: no se necesita este servicio.

v Estrategia: no es compatible con la estrategia de la compańía.

v Dificultad de venta: no se consigue vender con mucha facilidad.

v Apoyo: no se mantiene el apoyo de los gestores superiores.

v Presupuesto: no se mantienen los recursos asignados.

## Gestión de riesgos

Intenta identificar riesgos y preparar el proyecto para afrontarlos debidamente. Existen dos estrategias:

v Estrategia reactiva (menos recomendado).

v Estrategia proactiva (más recomendado).

### Estrategias

### Estrategia reactiva

v Se buscan y analizan los riesgos.

v Se asignan recursos por si se cumplen los riesgos y se convierten en problemas reales.

v El personal no se preocupa del riesgo hasta que es real.

v El personal intenta resolver el problema.

v Como último recurso, comienza la gestión de crisis.

### Estrategia proactiva

v Antes de comenzar con el proyecto en sí, se realiza un estudio de los riesgos en potencia(conocidos y desconocidos).

v Se mide las posibilidades de que se conviertan en reales y se cuantían los problemas que puedan surgir.

v Se redacta una lista priorizada de los riesgos detectados.

v Se realiza el plan de gestión de riesgos, es decir, se planifica el proyecto para evitar los riesgos o minimizarlos.

v En caso de no dar resultado se dispondrá de planes de contingencia.

### Gestión del riesgo de Boehm

#### Desarrollo en Espiral

La implementación del modelo en espiral consiste en un análisis de riesgo en cada una de las fases de desarrollo software.

v Valoración del riesgo.

- Identificación del riesgo.
- Análisis del riesgo.
- Priorización del riesgo.

v Control del riesgo.

- Planificación de la gestión del riesgo.
- Resolución del riesgo.
- Monitorización del riesgo.

### Plan RSGR

v La información esencial sobre el proceso de gestión del riesgo puede incluirse en un Plan de Reducción, Supervisión y Gestión del Riesgo (RSGR).

v Éste puede ser un documento independiente o ser parte del plan del proyecto del software.

v Debe recoger toda la información relativa al proceso de gestión de riesgos, conforme a las etapas descritas.

Clasificación de métricas

MÉTRICA

Es una metodología de planificación, desarrollo y mantenimiento de sistemas de información.

CARACTERÍSTICAS

Simple y fácil de calcular: debería ser relativamente fácil de aprender a obtener la métrica y su cálculo no obligara a un esfuerzo o a una cantidad de tiempo inusuales.

Empírica e intuitivamente persuasiva: la métrica debería satisfacer las nociones intuitivas del ingeniero de software sobre el atributo del producto en cuestión.

Consistente en el empleo de unidades y tamańos: el cálculo matemático de la métrica debería utilizar medidas que no lleven a extrańas combinaciones de unidades.

Independiente del lenguaje de programación: las métricas deberían apoyarse en el modelo de análisis, modelo de diseńo o en la propia estructura del programa. No deberían depender de los caprichos de la sintaxis o semántica del lenguaje de programación.

Un mecanismo eficaz para la realimentación de calidad: la métrica debería suministrar al desarrollador de software información que le lleve a un producto final de superior calidad.

CLASIFICACIÓN DE LAS METRICAS

v Métricas técnicas: Se centran en las características de software, por ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo está hecho.

v Métricas de calidad: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir, cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.

v Métricas de productividad: Se centran en el rendimiento del proceso de la ingeniería del software. Es decir que tan productivo va a ser el software que voy a diseńar.

v Métricas orientadas a la persona: Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos

v Métricas orientadas al tamańo: Es para saber en qué tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos.

v Métricas orientadas a la función: Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa.

v Métricas de proceso: Se recopilan de todos los proyectos, y durante un largo periodo de tiempo, caracterizados por:

o Control y ejecución del proyecto.

o Medición de tiempos de las fases.

Modelos de procesos

LOS MODELOS DE PROCESOS DE SOFTWARE

Para resolver los problemas reales de una industria, un ingeniero del software debe incorporar una estrategia de desarrollo que acompańe al proceso, métodos y tenga herramientas. Esta estrategia se llama modelo de proceso o paradigma de ingeniería del software. Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, los controles y entregas que se requieren.

Los estándares establecen los diferentes procesos implicados a la hora de desarrollar y mantener un sistema desde que surge la idea o necesidad de desarrollar las aplicaciones hasta que éstas se retiran de explotación. Sin embargo, ninguno impone un modelo de procesos concreto (modelo de ciclo de vida) ni cómo realizar las diferentes actividades incluidas en cada proceso, por lo que cada empresa deberá utilizar los métodos, técnicas y herramientas que considere oportuno.

Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo de procesos del software es una simplificación o abstracción de un proceso real. Podemos definir un modelo de procesos del software como una representación abstracta de alto nivel de un proceso software.

Cada modelo es una descripción de un proceso software que se presenta desde una perspectiva particular. Alternativamente, a veces se usan los términos ciclo de vida y Modelo de ciclo de vida.

Cada modelo describe una sucesión de fases y un encadenamiento entre ellas, así como un bucle de resoluciones de problemas y estos se encuentran en distintas etapas. Según las fases y el modo en que se produzca este encadenamiento, tenemos diferentes modelos de proceso. Un modelo es más adecuado que otro para desarrollar un proyecto dependiendo de un conjunto de características de éste.

Modelo COCOMO

El Modelo Constructivo de Costes COCOMO -Constructive Cost Model es utilizado en proyectos de software para estimar los costes del mismo en función de tres submodelos: básico, intermedio y detallado.

El modelo básico estima el coste del proyecto pequeńo o mediano- en función de número de líneas de código estimadas. En este modelo, el algoritmo COCOMO establece varios criterios de desarrollo, dependiendo el nivel de dificultar no del nivel de experiencia de los desarrolladores que se supone- sino de posibles dificultades que se pueden encontrar en el desarrollo o limitaciones del hardware usado en el desarrollo del software.

El modelo intermedio se utiliza para estimaciones más complejas. Éste incluye 15 atributos dentro de 4 categorías- del software para determinar el coste del proyecto.

Atributos del producto: garantía de funcionamiento requerida para creación del software, tamańo de la BBDD, etc.

Atributos del ordenador usado: capacidad de almacenamiento, rapidez del ordenador, etc.

Atributos del personal: experiencia en el tipo de software a desarrollar, en el lenguaje usado, etc.

Atributos del proyecto: software usado para el desarrollo, lenguaje necesario para crear el software, etc.

Todos estos atributos son ponderados matemáticamente en atendiendo de su relevancia. De esta manera se intenta aproximar el coste estimado al real, lo máximo posible.

El modelo detallado, incorpora las características del modelo intermedio y lleva a cabo una evaluación del impacto de los motivantes del coste en cada caso -análisis, diseńo, etc.- del proceso de ingeniería del software.

En modelo COCOMO es uno de los sistemas de estimación de costes más utilizados en proyectos de desarrollo de software. La estandarización de su uso y la facilidad de la aplicación del mismo junto con la aproximación al coste real, han convertido a este modelo en uno de los referentes en este tipo de proyectos.

El modelo de McCall.

El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto, basándose en once factores de calidad organizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios:

Puntos De Vista O Ejes | Factor | Criterios

OPERACIÓN DEL PRODUCTO

Facilidad de uso

§ Facilidad de operación: Atributos del software que determinan la facilidad de operación del software.

§ Facilidad de comunicación: Atributos del software que proporcionan entradas y salidas fácilmente asimilables.

§ Facilidad de aprendizaje: Atributos del software que facilitan la familiarización inicial del usuario con el software y la transición del modo actual de operación.

v - Formación: El grado en que el software ayuda para permitir que nuevos usuarios apliquen el sistema.

Integridad | § Control de accesos. Atributos del software que proporcionan control de acceso al software y los datos que maneja. § Facilidad de auditoría: Atributos del software que facilitan la auditoría de los accesos al software. v - Seguridad: La disponibilidad de mecanismos que controlen o protejan los programas o los datos.
Corrección | § Completitud: Atributos del software que proporcionan la implementación completa de todas las funciones requeridas. § Consistencia: Atributos del software que proporcionan uniformidad en las técnicas y notaciones de diseńo e implementación. v - Trazabilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto.

OPERACIÓN DEL PRODUCTO

Fiabilidad

§ Precisión: Atributos del software que proporcionan el grado de precisión requerido en los cálculos y los resultados.

§ Consistencia.

§ Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales.

§ Modularidad: Atributos del software que proporcionan una estructura de módulos altamente independientes.

§ Simplicidad: Atributos del software que posibilitan la implementación de funciones de la forma más comprensible posible.

v - Exactitud: La precisión de los cálculos y del control.

Eficiencia | § Eficiencia en ejecución: Atributos del software que minimizan el tiempo de procesamiento. v - Eficiencia en almacenamiento: Atributos del software que minimizan el espacio de almacenamiento necesario.
REVISION DEL PRODUCTO | Facilidad de mantenimiento | § Modularidad. § Simplicidad. § Consistencia. § Concisión: Atributos del software que posibilitan la implementación de una función con la menor cantidad de códigos posible. v - Auto descripción: Atributos del software que proporcionan explicaciones sobre la implementación de las funciones.
Facilidad de prueba | § Modularidad. § Simplicidad. § Auto descripción. v - Instrumentación: Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución para facilitar las mediciones del uso o la identificación de errores.

Flexibilidad

§ Auto descripción.

§ Capacidad de expansión: Atributos del software que posibilitan la expansión del software en cuanto a capacidades funcionales y datos.

§ Generalidad: Atributos del software que proporcionan amplitud a las funciones implementadas.

v - Modularidad.

Reusabilidad | § Auto descripción. § Generalidad. § Modularidad. v - Independencia entre sistema y software: Atributos del software que determinan su dependencia del entorno operativo. v - Independencia del hardware: Atributos del software que determinan su dependencia del hardware.

Interoperabilidad

§ Modularidad.

§ Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso de protocolos de comunicación e interfaces estándar.

§ Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos estándar.

v - Estandarización en los datos: El uso de estructuras de datos y de tipos estándar a lo largo de todo el programa.

Portabilidad | § Auto descripción. § Modularidad. v -Independencia entre sistema y software. v - Independencia del hardware.

ISO/IEC 9126

ISO 9126 era un estándar internacional para la evaluación de la calidad del software. Fue reemplazado en 2005 por el conjunto de normas SQuaRE, ISO 25000:2014, la cual desarrolla los mismos conceptos.

## Fundamentos

Este estándar proviene desde el modelo establecido en 1977 por McCall y sus colegas, los cuales propusieron un modelo para especificar la calidad del software. El modelo de calidad McCall está organizado sobre tres tipos de Características de Calidad:

- Factores (especificar): Describen la visión externa del software, como es visto por los usuarios.
- Criterios (construir): Describen la visión interna del software, como es visto por el desarrollador.
- Métricas (controlar): Se definen y se usan para proveer una escala y método para la medida.

El estándar provee un entorno para que las organizaciones definan un modelo de calidad para el producto software. Haciendo esto así, sin embargo, se lleva a cada organización la tarea de especificar precisamente su propio modelo. Esto podría ser hecho, por ejemplo, especificando los objetivos para las métricas de calidad las cuales evalúan el grado de presencia de los atributos de calidad.

Un producto software está definido en un sentido amplio como: los ejecutables, código fuente, descripciones de arquitectura, y así. Como resultado, la noción de usuario se amplía tanto a operadores como a programadores, los cuales son usuarios de componentes como son bibliotecas software.

El modelo incluye métricas internas y externas. Métricas internas son aquellas que no dependen de la ejecución del software (medidas estáticas), mientras que las métricas externas son aquellas aplicables al software en ejecución. Las calidades en las métricas de uso están sólo disponibles cuando el producto final es usado en condiciones reales. Idealmente, la calidad interna no necesariamente implica calidad externa y esta a su vez la calidad en el uso.

## Características

El estándar está dividido en cuatro partes las cuales dirigen, realidad, métricas externas, métricas internas y calidad en las métricas de uso y expendido. El modelo de calidad establecido en la primera parte del estándar, ISO 9126-1, clasifica la calidad del software en un conjunto estructurado de características y subcaracterísticas. Cada subcaracterística (como adaptabilidad) está dividida en atributos. Un atributo es una entidad la cual puede ser verificada o medida en el producto software. Los atributos no están definidos en el estándar, ya que varían entre diferentes productos software. Las características se organizan de la siguiente manera:

- Funcionalidad - Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones son aquellas que satisfacen las necesidades implícitas o explícitas.

v Adecuación - Atributos del software relacionados con la presencia y aptitud de un conjunto de funciones para tareas especificadas.

v Exactitud - Atributos del software relacionados con la disposición de resultados o efectos correctos o acordados.

v Interoperabilidad - Atributos del software que se relacionan con su habilidad para la interacción con sistemas especificados.

v Seguridad - Atributos del software relacionados con su habilidad para prevenir acceso no autorizado ya sea accidental o deliberado, a programas y datos.

v Cumplimiento funcional.

ˇ Fiabilidad - Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestación bajo condiciones establecidas durante un período establecido.

v Madurez - Atributos del software que se relacionan con la frecuencia de falla por fallas en el software.

v Recuperabilidad - Atributos del software que se relacionan con la capacidad para restablecer su nivel de desempeńo y recuperar los datos directamente afectos en caso de falla y en el tiempo y esfuerzo relacionado para ello.

v Tolerancia a fallos - Atributos del software que se relacionan con su habilidad para mantener un nivel especificado de desempeńo en casos de fallas de software o de una infracción a su interfaz especificada.

v Cumplimiento de Fiabilidad - La capacidad del producto software para adherirse a normas, convenciones o legislación relacionadas con la fiabilidad.

- Usabilidad - Un conjunto de atributos relacionados con el esfuerzo necesario para su uso, y en la valoración individual de tal uso, por un establecido o implicado conjunto de usuarios.

v Aprendizaje- Atributos del software que se relacionan al esfuerzo de los usuarios para reconocer el concepto lógico y sus aplicaciones.

v Comprensión - Atributos del software que se relacionan al esfuerzo de los usuarios para reconocer el concepto lógico y sus aplicaciones.

v Operatividad - Atributos del software que se relacionan con el esfuerzo de los usuarios para la operación y control del software.

v Atractividad

- Eficiencia - Conjunto de atributos relacionados con la relación entre el nivel de desempeńo del software y la cantidad de recursos necesitados bajo condiciones establecidas.

v Comportamiento en el tiempo - Atributos del software que se relacionan con los tiempos de respuesta y procesamiento y en las tasas de rendimientos en desempeńar su función.

v Comportamiento de recursos - Usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su función bajo condiciones determinadas.

- Mantenibilidad - Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software.

v Estabilidad - Atributos del software relacionados con el riesgo de efectos inesperados por modificaciones.

v Facilidad de análisis - Atributos del software relacionados con el esfuerzo necesario para el diagnóstico de deficiencias o causas de fallos, o identificaciones de partes a modificar.

v Facilidad de cambio - Atributos del software relacionados con el esfuerzo necesario para la modificación, corrección de falla, o cambio de ambiente.

v Facilidad de pruebas - Atributos del software relacionados con el esfuerzo necesario para validar el software modificado.

- Portabilidad - Conjunto de atributos relacionados con la capacidad de un sistema de software para ser transferido y adaptado desde una plataforma a otra.

v Capacidad de instalación - Atributos del software relacionados con el esfuerzo necesario para instalar el software en un ambiente especificado.

v Capacidad de reemplazamiento - Atributos del software relacionados con la oportunidad y esfuerzo de usar el software en lugar de otro software especificado en el ambiente de dicho software especificado.

- Calidad en uso - Conjunto de atributos relacionados con la aceptación por parte del usuario final y Seguridad.

v Eficacia - Atributos relacionados con la eficiencia del software cuando el usuario final realiza los procesos.

v Productividad - Atributos relacionados con el rendimiento en las tareas cotidiana realizadas por el usuario final.

v Seguridad - Atributos para medir los niveles de riesgo.

v Satisfacción - Atributos relacionados con la satisfacción de uso del software.

En los tiempos actuales el sello de calidad en la fabricación de cualquier producto cobra una importancia relevante para determinar si un producto es mejor o peor que otro. En el desarrollo de sistemas interactivos este factor no pasa desapercibido hasta el punto que actualmente la usabilidad es considerada como un atributo de calidad en el desarrollo del software que es recogido en diversas clasificaciones de atributos de calidad [ISO01][IEE98][BOH78]. La percepción cada vez mayor de la importancia de la usabilidad se afirma que éste es uno de los atributos de calidad que se consideran más críticos en el proceso de desarrollo de software. Y dadas las ventajas que puede proporcionar debería ocupar un lugar relevante como factor de calidad estratégico
Características de la calidad interna y externa del software descritas en el estándar ISO/IEC 9126-1.
Si bien los desarrolladores
Desearían conocer qué atributos incorporar en el código para reducir el Ťesfuerzo requerido para su usoť, o sea Ťpara proporcionar usabilidadť, la presencia o ausencia de atributos predefinidos no puede asegurar dicha característica, igual que no hay manera fiable para predecir el comportamiento de los usuarios con el producto final [BEV99].

Gráficos Vectoriales

También conocidos como modelados geométricos, son los que se conforman con primitivas geométricas tales como puntos, líneas, curvas o polígonos, de igual forma, son gráficos que se construyen por ordenador basándose en ecuaciones matemáticas. Se utiliza como antónimo de aquellas imágenes que están configuradas sobre un conjunto de píxeles, tales como los bitmaps, también llamados gráficos rasterizados

## Introducción

Todos los ordenadores actuales traducen los gráficos vectoriales a gráficos rasterizados para poderlos visualizar en pantalla. La imagen rasterizada posee un valor determinada para cada píxel que la conforma, esta información se guarda en la memoria ocupando un espacio específico.

Desde los inicios del computador en 1950 hasta la década de los ochenta se usaba un sistema de graficación vectorial, diferente al actual. En este sistema caligráfico el rayo eléctrico del tubo de rayo catódico de la pantalla era guiado directamente para dibujar las formas necesarias, segmento de línea por segmento de línea, dejando en negro el resto de la pantalla. Este proceso se repetía muchas veces en un segundo para alcanzar una imagen libre de destellos o muy cercana a estar libre de destellos. Este sistema permitía visualizar imágenes estáticas y con movimiento de buena resolución (para ese momento) sin usar la inimaginable cantidad de memoria que se hubiera necesitado para originar una resolución equivalente en un sistema de rasterización, permitiendo que dibujos completos pudieran ser movidos, rotados y hasta que titilaran modificando sólo algunas de las palabras del código de la gráfica en su respectivo display file. Estos monitores basados en vectores también eran conocidos como X-Y displays.

Calidad del producto

La calidad del producto software se puede interpretar como el grado en que dicho producto satisface los requisitos de sus usuarios aportando de esta manera un valor. Son precisamente estos requisitos (funcionalidad, rendimiento, seguridad, mantenibilidad, etc.) los que se encuentran representados en el modelo de calidad, el cual categoriza la calidad del producto en características y subcaracterísticas. Es el grado en el que un producto Sw incorpora un conjunto de características, definidas por la industria, de tal manera que se garantiza su eficiencia de uso, respecto a los requerimientos de los clientes.

En pocas palabras, es el cumplimiento de expectativas de los clientes.

El modelo de calidad del producto definido por la ISO/IEC 25010 se encuentra compuesto por las ocho características de calidad, mismo modelo de calidad representa la piedra angular en torno a la cual se establece el sistema para la evaluación de la calidad del producto. En este modelo se determinan las características de calidad que se van a tener en cuenta a la hora de evaluar las propiedades de un producto software determinado.

En el mercado tan competitivo de hoy en día, la calidad ha llegado a ser un factor crucial y cada vez más empresas insisten en este punto. Las organizaciones también se están dando cuenta de que sólo conseguirán atraer a nuevos clientes y mantener a los que ya tienen proporcionándoles productos y servicios de alta calidad. Aunque los responsables de los proyectos software se esfuerzan por cumplir los requisitos de los clientes y entregar productos de calidad, en muchas ocasiones fallan en este intento. Esto es debido a que su percepción de calidad es muy distinta a la de los clientes.

El éxito de un proyecto normalmente se mide sobre 3 ejes:

Agenda: żEl proyecto fue entregado a tiempo?

Coste: żEl proyecto se mantuvo dentro del presupuesto?

Calidad: żEl producto tuvo una buena calidad?

Un proyecto exitoso es aquel que se completa a tiempo, permanece dentro del presupuesto y tiene desarrolladas las funciones requeridas. Cumplir los requisitos de calidad es uno de los aspectos a considerar en un proyecto exitoso

Sí una empresa que desarrolla software debe preocuparse de la calidad del PROCESO y del PRODUCTO que desarrolla y entrega, una empresa que solo compra software (el típico cliente) debería, principalmente, preocuparse de la calidad del PRODUCTO que compra. Aunque vemos que, en la realidad, las empresas que compran software lo hacen al revés, se preocupan por el proceso que usa su proveedor (CMMI, ISO, etc.) y apenas del producto que les llega. Cosas de la industria.

Sin la calidad del Sw o la mala ejecución de este tendremos: programas que no hacen lo que se espera, proyectos que se abandonan debido a sobrecostos, programas muy difíciles de operar etc. Por ello se deben de acudir a métricas, inspecciones, pruebas y procesos para verificar su calidad y funcionamiento, ya que se evalúan el proceso y el producto final; es decir, estándares a los cuales se les llama Modelos de referencia.

Un Modelo de Referencia en ingeniería de sistemas y en ingeniería de software es un modelo de algo que contiene un objetivo o idea básica de algo, y que se puede establecer como una referencia para múltiples propósitos

Un Modelo de Referencia es un marco de referencia abstracto para entender el significado de las relaciones entre entidades de algún ambiente. Permite el desarrollo de referencias específicas o de arquitecturas por medio del uso de estándares o especificaciones que soportan el ambiente en cuestión. Un Modelo de Referencia consiste de un conjunto mínimo de conceptos, axiomas y relaciones propios de un dominio particular de problema, y es independiente de estándares específicos, tecnologías, implementaciones, o de cualquier otro detalle concreto.

Características

Abstracto: Un modelo de referencia es abstracto. Los elementos descritos por él no son las cosas en sí mismas, sino que son representaciones de ellas. Por consiguiente, cuando se describe la arquitectura de una casa plano-, las paredes tienen dimensiones y materiales, pero el concepto pared es parte del modelo de referencia. De este modo para construir las paredes de una casa es necesario entender los planos, y esto significa entender el modelo de referencia en cuestión.

Entidades y Relaciones: Un modelo de referencia contiene tanto entidades (las cosas que existen) como relaciones (como las cosas interactúan entre sí). La lista de entidades no es suficiente para describir completamente un modelo de relación.

Inserto en el ambiente: Un modelo de referencia no pretende describir todas las cosas. Se usa para clarificar las cosas en un ambiente o espacio de un determinado problema o tópico. Para que el modelo de referencia sea efectivamente útil debe incluir una descripción precisa del problema que pretende resolver, y de las preocupaciones de quienes necesitan resolver dicho problema.

Tecnológicamente agnóstico: Un modelo de referencia no es útil si incluye consideraciones tecnológicas o de alguna plataforma computacional en particular. Un modelo de referencia es un mecanismo para entender un determinado problema, no es su objetivo proveer la solución propiamente tal. Tiene que ser independiente de la solución, de modo de entregar valor a quien usa el modelo.

Razones de Uso

La utilización de los modelos de referencia está motivada por distintas necesidades, como ser:

Estandarización: Por medio de la creación de estándares, el trabajo de los ingenieros y de los desarrolladores que tienen la tarea de crear objetos, que tengan un comportamiento adecuado al requerimiento, se facilita mediante el uso de una base común de conocimiento y de reglas sobre el cómo hacer, este es el estándar. En particular, la implementación de proyectos, el desarrollo de software, el mantenimiento de las aplicaciones, etc. Esta labor se facilita mucho si sus respectivas definiciones están soportadas por modelos de referencia.

Educación: Por medio de los modelos de referencia los líderes de un determinado proyecto, sea de implementación, mejoramiento o desarrollo de software pueden organizarlo por partes o fases, descomponiendo el problema en partes más simples que puedan ser realizadas por distintos equipos profesionales. Esto lleva a que un grupo de profesionales aprenda a trabajar conforme a una regla general, y esto redunda en una mayor eficiencia a la hora de integrar los distintos componentes del proyecto como asimismo en disponer de la capacidad de realizar partes de un proyecto en paralelo. Un ejemplo es el uso de modelos EPC para describir un determinado proceso de negocios.

Comunicaciones interpersonales: Un Modelo de Referencia descompone un problema en entidades, o en cosas que existen por si mismas. Esto es a menudo un reconocimiento declarado de conceptos que ya mucha gente comparte, pero que son expresados de una manera explícita. Un Modelo de Referencia es útil cuando permite definir cuando los conceptos difieren y/o se relacionan. Estas cualidades del Modelo de Relación facilitan la comunicación entre las personas.

Roles y responsabilidades: Por medio de la creación de un modelo de entidades con sus correspondientes relaciones, una organización puede asignar personas específicas o equipos, dándoles la responsabilidad para resolver los problemas concernientes a un determinado conjunto de entidades. Por ejemplo, si un Modelo de Referencia describe un conjunto de indicadores para medir el negocio (KPI), cada uno de ellos pude ser asignado al ejecutivo que corresponda.

Comparación: Un Modelo de Referencia sirve para comparar cosas diferentes. Por medio de la descomposición del problema en conceptos básicos, puede utilizarse para examinar dos soluciones distintas para el mismo problema.

Modelos de Uso General

Corresponden a modelos propuestos por distintas organizaciones para atender un determinado tópico o área de trabajo, éstos son posibles de ubicar en la WEB, y muchos de ellos están a disposición del público. A continuación, incluyo los modelos TOGAF, SCORE y COBIT a modo de ejemplos, para mayor detalle sobre cada uno su título tiene un link a las páginas que los describren.

TOGAF [The Open Group Architecture Framework]

TOGAF es un modelo de referencia que puede ser utilizado libremente sin costo- por cualquier organización que desee desarrollar su arquitectura de sistema de información.

##

## Adecuación Funcional

Representa la capacidad del producto software para proporcionar funciones que satisfacen las necesidades declaradas e implícitas, cuando el producto se usa en las condiciones especificadas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

- Completitud funcional. Grado en el cual el conjunto de funcionalidades cubre todas las tareas y los objetivos del usuario especificados.
- Corrección funcional. Capacidad del producto o sistema para proveer resultados correctos con el nivel de precisión requerido.
- Pertinencia funcional. Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados.

Atributos de Calidad de un Sw (Software)

Son las cualidades o propiedades que la aplicación debe poseer o satisfacer, la calidad de una aplicación se mide en función de sus atributos de calidad. Para facilitar su medición durante la verificación deben expresarse cualitativa o cuantitativamente.

żCuáles son?

## Eficiencia de desempeńo

Esta característica representa el desempeńo relativo a la cantidad de recursos utilizados bajo determinadas condiciones. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

- Comportamiento temporal. Los tiempos de respuesta y procesamiento y las ratios de throughput de un sistema cuando lleva a cabo sus funciones bajo condiciones determinadas en relación con un banco de pruebas (benchmark) establecido.
- Utilización de recursos. Las cantidades y tipos de recursos utilizados cuando el software lleva a cabo su función bajo condiciones determinadas.
- Capacidad. Grado en que los límites máximos de un parámetro de un producto o sistema software cumplen con los requisitos.

## Compatibilidad

Capacidad de dos o más sistemas o componentes para intercambiar información y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno hardware o software. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

- Coexistencia. Capacidad del producto para coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes sin detrimento.
- Interoperabilidad. Capacidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada.

## Usabilidad

Capacidad del producto software para ser entendido, aprendido, usado y resultar atractivo para el usuario, cuando se usa bajo determinadas condiciones. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

ˇ Capacidad para reconocer su adecuación. Capacidad del producto que permite al usuario entender si el software es adecuado para sus necesidades.

ˇ Capacidad de aprendizaje. Capacidad del producto que permite al usuario aprender su aplicación.

ˇ Capacidad para ser usado. Capacidad del producto que permite al usuario operarlo y controlarlo con facilidad.

ˇ Protección contra errores de usuario. Capacidad del sistema para proteger a los usuarios de hacer errores.

ˇ Estética de la interfaz de usuario. Capacidad de la interfaz de usuario de agradar y satisfacer la interacción con el usuario.

ˇ Accesibilidad. Capacidad del producto que permite que sea utilizado por usuarios con determinadas características y discapacidades.

## Fiabilidad

Capacidad de un sistema o componente para desempeńar las funciones especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

- Madurez. Capacidad del sistema para satisfacer las necesidades de fiabilidad en condiciones normales.
- Disponibilidad. Capacidad del sistema o componente de estar operativo y accesible para su uso cuando se requiere.
- Tolerancia a fallos. Capacidad del sistema o componente para operar según lo previsto en presencia de fallos hardware o software.
- Capacidad de recuperación. Capacidad del producto software para recuperar los datos directamente afectados y reestablecer el estado deseado del sistema en caso de interrupción o fallo.

## Seguridad

Capacidad de protección de la información y los datos de manera que personas o sistemas no autorizados no puedan leerlos o modificarlos. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

- Confidencialidad. Capacidad de protección contra el acceso de datos e información no autorizados, ya sea accidental o deliberadamente.
- Integridad. Capacidad del sistema o componente para prevenir accesos o modificaciones no autorizados a datos o programas de ordenador.
- No repudio. Capacidad de demostrar las acciones o eventos que han tenido lugar, de manera que dichas acciones o eventos no puedan ser repudiados posteriormente.
- Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de una entidad.
- Autenticidad. Capacidad de demostrar la identidad de un sujeto o un recurso.

## Mantenibilidad

Esta característica representa la capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

- Modularidad. Capacidad de un sistema o programa de ordenador (compuesto de componentes discretos) que permite que un cambio en un componente tenga un impacto mínimo en los demás.
- Reusabilidad. Capacidad de un activo que permite que sea utilizado en más de un sistema software o en la construcción de otros activos.
- Analizabilidad. Facilidad con la que se puede evaluar el impacto de un determinado cambio sobre el resto del software, diagnosticar las deficiencias o causas de fallos en el software, o identificar las partes a modificar.
- Capacidad para ser modificado. Capacidad del producto que permite que sea modificado de forma efectiva y eficiente sin introducir defectos o degradar el desempeńo.
- Capacidad para ser probado. Facilidad con la que se pueden establecer criterios de prueba para un sistema o componente y con la que se pueden llevar a cabo las pruebas para determinar si se cumplen dichos criterios.

## Portabilidad

Capacidad del producto o componente de ser transferido de forma efectiva y eficiente de un entorno hardware, software, operacional o de utilización a otro. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

- Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma efectiva y eficiente a diferentes entornos determinados de hardware, software, operacionales o de uso.
- Capacidad para ser instalado. Facilidad con la que el producto se puede instalar y/o desinstalar de forma exitosa en un determinado entorno.
- Capacidad para ser reemplazado. Capacidad del producto para ser utilizado en lugar de otro producto software determinado con el mismo propósito y en el mismo entorno.

Vector de Calidad

Entre las medidas directas del proceso de la ingeniería del software se incluyen el coste y el esfuerzo aplicados. Entre las medidas directas del producto se incluyen las líneas de código (LDC) producidas, velocidad de ejecución, tamańo de memoria, y los defectos informados durante un período de tiempo establecido. Entre las medidas indirectas se incluyen la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento y muchas otras Ťcapacidadesť.

El dominio de las métricas del software se divide en: métricas de proceso, proyecto y producto.

También se acaba de destacar que las métricas de producto que son privadas para un individuo a menudo se combinan para desarrollar métricas del proyecto que sean públicas para un equipo de software.

Las métricas del proyecto se consolidan para crear métricas de proceso que sean públicas para toda la organización del software.

El concepto de calidad encuentra muchas definiciones posibles. La más tradicional se refiere al Ťconjunto de cualidades de una persona o cosať. Sin embargo, las definiciones vinculadas a las actividades industriales hablan de la medida en que un producto o servicio satisface los requerimientos de una función dada. De todas formas, el concepto es subjetivo. Por ejemplo, un producto que cumple con las expectativas de un usuario puede haber sido elaborado sin conformidad con ciertas normas de fabricación. Por eso, la calidad siempre depende del punto de vista, pero, en general, involucra el cumplimiento de un conjunto de exigencias. Otros aspectos a tener cuenta pueden ser la adecuación al uso y la ausencia de deficiencias.

Entonces, żqué es la calidad de un producto software?

Existen dos enfoques posibles:

- Calidad funcional. Refleja en qué medida el software cumple con o se ajusta a un determinado diseńo, basado en requerimientos funcionales. Éstos abarcan las actividades del software que involucran procesamiento de datos de entrada.
- Calidad estructural. Refleja en qué medida el software cumple con los requerimientos no funcionales, como rendimiento, capacidad de mantenimiento o escalabilidad.

Cálculo de Calidad

Ante la necesidad de un consenso acerca de los elementos que definen la calidad del software, ISO desde hace tiempo creo estándares en este sentido. El primero es el ISO 9126, originalmente publicado en 1991 y posteriormente revisado en 2001. Posteriormente desarrolló el estándar ISO/IEC 25010: SQuaRE (Software Product Quality Requirements and Evaluation), que fue publicado en 2011 y viene a ser el reemplazo de ISO 9126.

Como ya se explicó en el artículo de la Dra. Hanna Oktaba SQuaRE: Modelo actualizado de las características de calidad publicado en SG #29, este modelo evalúa la calidad desde dos perspectivas: la calidad del producto como tal (calidad interna), y la calidad de el uso del software (externa). Cada perspectiva considera diversas características, y a su vez cada característica puede tener una o más subcaracterísticas.

Características y subcaracterísticas de calidad interna:

- Adecuación funcional: funcionalidad adecuada, funcionalidad correcta, funcionalidad completa.
- Confiabilidad: madurez, disponibilidad, tolerancia a fallos, recuperabilidad.
- Eficiencia de rendimiento: tiempo de respuesta, utilización de recursos, capacidad.
- Operabilidad: reconocimiento de funcionalidad adecuada, facilidad de uso, facilidad de aprendizaje, protección contra errores de usuario, accesibilidad, estética de la interfaz de usuario.
- Seguridad: confidencialidad, integridad, no rechazo, responsabilidad, autenticidad.
- Compatibilidad: interoperabilidad, capacidad de coexistencia.
- Mantenibilidad: modularidad, reusabilidad, capacidad de ser analizado, capacidad de ser modificado, capacidad de ser verificado/probado.
- Transmisibilidad/Portabilidad: instalabilidad, adaptabilidad, reemplazabilidad.

Características y subcaracterísticas de calidad externa:

- Satisfacción de uso: utilidad, confianza, placer, comodidad.
- Seguridad de uso: mitigación de riesgos económicos, mitigación de riesgos para el usuario, mitigación de riesgos ambientales.
- Flexibilidad de uso: cobertura del contexto, flexibilidad.
- Efectividad de uso.
- Eficiencia de uso.

Aunque algunas de estas características se pueden medir de manera objetiva, la mayor parte requieren una evaluación subjetiva. Esto hace que la manera más utilizada, más rápida, menos costosa y quizá la que más refleja la realidad, sea la utilización de la experiencia de los empleados de una organización. Sin embargo, esto no permite realizar comparaciones objetivas y presenta algunos otros problemas como que le pertenece al experto y no a la organización, no se puede replicar sistemáticamente y no contribuye a la madurez de la ingeniería de software.

Existe un modelo que puede ser utilizado para la evaluación de este tipo de variables, el modelo EPEI (EPCU por sus siglas en inglés) el cual permite en un entorno de información imperfecta (información vaga o ambigua), pasar de entornos cualitativos a entornos cuantitativos. En otras palabras, es un modelo que nos permite a partir de opiniones (juicio de experto) de una serie de variables subjetivas, determinar un valor cuantitativo suficientemente razonable, generado por la evaluación de reglas de inferencia definidas por expertos. (Valdés, 2012).

Caso de estudio para medir la calidad de productos de software
Se realizó un estudio para evaluar la calidad de 44 proyectos. Los proyectos considerados fueron realizados en 4 áreas distintas de una organización que trabaja en un esquema de outsourcing (cada una con un proveedor distinto) controlados por líderes de proyecto internos, estos fueron los encargados de evaluar la calidad interna de los proyectos realizados.

De los 44 proyectos solamente 24 se pusieron en producción, por esta razón sólo a estos últimos se les evaluó la calidad de uso (externa), los usuarios fueron los encargados de evaluar la calidad de uso de las aplicaciones.El procedimiento que se siguió para evaluar la calidad interna/externa de los productos de software fue solicitar a cada líder de proyecto la asignación de valores para las características definidas en el estándar para la calidad externa/interna en relación a su proyecto, las características fueron consideradas como variables de entrada en el modelo EPEI.

La asignación de los valores de las variables de entrada se realizó considerando el juicio de experto de los líderes de cada proyecto, determinándose un valor en un rango definido de 0 a 5 sobre el dominio de los número reales.

Por cada área de la organización se obtuvo el promedio de los valores asignados a cada una de las características de calidad considerando todos los proyectos evaluados.

Con los datos promedio de las categorías por área se calculó el índice de calidad por proyecto utilizando el modelo EPCU, de tal manera que se obtuvo un índice de calidad promedio que representa la calidad de los proyectos desarrollados en cada área de la organización.

A través del modelo EPCU es posible determinar un valor cuantitativo consistente, de manera formal y que nos permita hacer comparaciones acerca de la calidad de los productos de software de una manera práctica.

Este modelo permite evaluar a partir del juicio de experto, mediante mecanismos formales de manejo de información imperfecta y con base en el estándar de calidad ISO/IEC 25000, la calidad de los productos de software tanto desde el punto de vista de su construcción (calidad interna) como desde el punto de vista del usuario (calidad externa).

Debido a que el índice de calidad es consecuencia de los distintos valores de las categorías definidas por el estándar, es posible determinar estrategias relevantes y factibles para incrementar el índice de calidad a través de mejorar las categorías de calidad.

El poder tener un valor cuantitativo de calidad, sin duda, dará certeza al usuario, sobre todo si el también participa en la evaluación de la calidad externa del producto de software.

Métricas técnicas: Se centran en las características de software por ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo está hecho.

Métricas de calidad: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.

Métricas de productividad: Se centran en el rendimiento del proceso de la ingeniería del software. Es decir que tan productivo va a ser el software que voy a diseńar.

Métricas orientadas a la persona: Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos

Métricas orientadas al tamańo: Es para saber en qué tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos.

Métricas orientadas a la función: Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa.

Métricas de proceso: Se recopilan de todos los proyectos, y durante un largo periodo de tiempo, caracterizados por:

‣Control y ejecución del proyecto.

‣Medición de tiempos de las fases

Métricas del producto

Las Métricas de producto se refieren a las características del software mismo. Des afortunadamente, las características del software que se miden fácilmente, como el tamańo y la complejidad ciclomática, no tienen una relación clara y consistente con los atributos de calidad como la compresión y la mantenibilidad. Las relaciones varían dependiendo de los procesos, la tecnología y el tipo de sistemas a desarrollar. Las métricas del software permiten medir de forma cuantitativa la calidad de sus atributos internos del producto, esto permite al ingeniero evaluar la calidad antes de su construcción. Es importante establecer żqué es la calidad del software?, żquién lo hace?, żPor qué es importante?, żCuáles son los pasos? Para determinar la calidad, żCuál es el producto obtenido?, żCómo estar seguro de hacerlo correctamente? Todas estas interrogantes se determinarán a lo largo del desarrollo del presente informe. Aspectos a considerar tales como hacer una distinción entre medida, métrica e indicador, qué factores de calidad se toman en cuenta.

Las métricas del producto se dividen en dos clases:

1. Las métricas dinámicas, que son recogidas por las mediciones hechas en un programa en ejecución.

2. Las métricas estáticas, que son recogidas por las mediciones hechas en las representaciones del sistema como el diseńo, el programa o la documentación.

Estas diferentes métricas están relacionadas con diversos atributos de calidad. las métricas dinámicas ayudan a valorar la eficiencia y la fiabilidad de un programa. las métricas estáticas ayudan a valorar la complejidad, la comprensión y la mantenibilidad de un sistema de software.

Las métricas dinámicas por lo general están relacionadas de forma cercana con los atributos de calidad de software. Es relativamente fácil medir el tiempo requerido por las funciones articulares y estimar el tiempo requerido para iniciar un sistema. Esto se relaciona directamente con la eficiencia del sistema. De forma similar, se puede registrar el número y el tipo de caídas del sistema y relacionarlos directamente con la fiabilidad del software.

Las métricas estáticas, por otro lado, tienen una relación indirecta con los atributos de calidad. Se han propuesto muchas de estas métricas y se han llevado a cabo experimentos para tratar de derivar y validad las relaciones entre estás métricas y la complejidad, la comprensión y la mantenibilidad del sistema.

Fan-in/Fan-out

Fan-in es una medida del número de funciones o métodos que llaman a otra función o método. Fan-out es el número de funciones que son llamadas por una función X. Un valor alto de fan significa que X está fuertemente acoplada al resto del diseńo y que los cambios en X tendrán muchos efectos importantes. Un valor alto de fan-out sugiere que la complejidad de X podría ser alta debido a la complejidad de la lógica de control necesaria para coordinar los componentes llamados.

Longitud del código

Ésta es una medida del tamańo del programa. Generalmente, cuando más grande sea el tamańo del código de un componente, más complejo y susceptible de errores será el componente. La Longitud del código ha mostrado ser la métrica más fiable para predecir errores en los componentes.

Complejidad ciclomática

Ésta es una medida de la complejidad del control de un programa. Esta complejidad del control está relacionada con la comprensión del programa.

Longitud de los identificadores

Es una medida de la longitud promedio de los diferentes identificadores en un programa. Cuanto más grande sea la longitud de los identificadores, más probable será que tengan significado; por lo tanto, el programa será más comprensible.

Profundidad del anidamiento de las condiciones

Ésta es una medida de la profundidad de anidamiento de las instrucciones condicionales <if> en un programa. Muchas condiciones anidadas son difíciles de comprender y son potencialmente susceptibles a errores.

Índice de Fog

Ésta es una medida de la longitud promedio de las palabras y las frases en los documentos. Cuanto más grande sea el índice de Fog, el documento será más difícil de comprender.

Panorama de las métricas del producto

Métricas para el modelo de análisis

Incluyen aspectos como:

-Funcionalidad entregada

-Tamańo del sistema

-Calidad de la especi cación

Métricas para el modelo de diseńo

-Métricas arquitectónicas

-Métricas al nivel de componente

-Métricas de diseńo de la interfaz

-Métricas especializadas en diseńo orientado a objetos

Métricas para el código fuente

Se usan para evaluar su complejidad, además la facilidad con que se mantiene y prueba.

-Métricas de Halstead

-Métricas de complejidad

-Métricas de longitud

Métricas para pruebas

Ayudan a diseńar casos de prueba efectivos y evaluar la e cacia de las pruebas.

-Métricas de cobertura de instrucciones y ramas

-Métricas relacionadas con los defectos

-Efectividad de la prueba

-Métricas en el proceso

En muchos modelos las métricas de un modelo pueden aplicarse en actividades posteriores a la ingeniería del software.

Métricas para el modelo de análisis

Métricas basadas en la función

La métrica de punto de función (PF) es para medir la funcionalidad que entrega un sistema. Se usa para:

1. Estimar el costo o el esfuerzo requerido para diseńar, codificar y probar el software

2. predecir el número de errores que se encontrarán durante la prueba.

3. pronosticar el número de componentes, de líneas de código proyectadas, o ambas, en el sistema implementado.

Métricas para el modelo de diseńo

Métricas del diseńo arquitectónico

Consideradas métricas de caja negra ya que no requieren ningún conocimiento del funcionamiento interno de un componente de software en particular.

Card y Glass de_nen tres medidas de la complejidad del diseńo del software:

-Complejidad Estructural en el caso de arquitecturas jerárquicas

-Complejidad de datos indica complejidad de la interfaz interna de un módulo

-Complejidad del sistema es la suma de las complejidades estructural y de datos.

Métricas para el diseńo orientado a objetos

Whitmire describe nueve características distintivas y mensurables de un Diseńo OO:

_ Tamańo

_ Complejidad

_ Acoplamiento

_ Su ciencia

_ Grado de avance

_ Cohesión

_ Primitivismo

_ Similitud

_ Volatilidad

Métricas para el código fuente

Estás métricas asignadas como cuantitativas por Halstead, se derivan después de que se ha generado el código o se estima una vez que el diseńo esté completo.

Las medidas son:

n1 = el número de operadores distintos que aparecen en un programa.

n2 = el número de operándoos distintos que aparecen en un programa.

N1= el número total de veces que aparece el operador.

N2= el número total de veces que aparece en operando.

Tamańo físico del software

En la construcción de software, la unidad de medida habitual sigue siendo en esfuerzo: se paga por la cantidad de esfuerzo empleado en lugar de por lo efectivamente producido. Y aunque fabricar software no es lo mismo que construir casas, existen métricas que permiten mediar la cantidad de software producida.

La medición del tamańo del software es una actividad esencial para la estimación y planificación de un proyecto de desarrollo o las actividades de mantenimiento de software.

Las técnicas de medición de Puntos Función permiten determinar el tamańo funcional del software a partir de diversos documentos del desarrollo, en particular nos interesan los asociados con los requerimientos funcionales del usuario.

Para las etapas más tempranas del ciclo de vida, cuando los requerimientos funcionales no están completamente definidos o se requiere una estimación rápida, han sido propuestos múltiples enfoques de estimación de tamańo funcional. Sin embargo, se ha observado que algunas de estas técnicas requieren documentación con un nivel de detalle similar al usado para una medición con un método estándar, la que frecuentemente no está disponible en las fases iniciales de un proyecto de software.

Otras propuestas no especifican claramente el artefacto necesario para ejecutar la estimación, no se encontró información sobre la exactitud de las estimaciones o la evaluación realizada para comprobar los resultados de su aplicación. Por último, son escasos los enfoques que se aplican a los productos de la Elicitación de Requerimientos. Con el objetivo de ofrecer una alternativa para las fases más tempranas de un proyecto de software, en esta tesis se presenta el procedimiento Scenario Function Points (SFP) que permite estimar el tamańo funcional de un sistema de software a partir de un producto de la Elicitación de Requerimientos, específicamente, los escenarios generados de acuerdo al enfoque de Leite. SFP está basado en el método estándar IFPUG FPA y su definición está soportada por un conjunto de reglas que establecen la asociación entre los conceptos del Modelo de Escenarios y los propios de dicho método. Para guiar la aplicación de SFP se diseńó un proceso y se elaboró su especificación formal.

El objetivo de esta última es facilitar la capacitación y comunicación de los usuarios, favorecer la efectiva ejecución del proceso y propiciar la repetibilidad de los resultados. Además, el proceso es soportado por el software SFP Tool, que facilita y agiliza el proceso de estimación. La evaluación del procedimiento SFP se realizó mediante un Caso de Estudio múltiple basado en tres sistemas implementados. Los resultados obtenidos son alentadores en cuanto a su capacidad como herramienta de estimación y al esfuerzo requerido por el proceso. En lo referido al primer aspecto, la exactitud de las estimaciones está en el orden de ą30% (considerando a la medición con el método estándar IFPUG como el valor de referencia), que está dentro del rango aceptable para una estimación temprana.

Además, en comparación con otras propuestas de estimación, el resultado es similar y en algunos casos mejor. Con respecto al esfuerzo, los resultados demuestran que es significativamente menor que el reportado en la literatura para una medición estándar.

Hasta ahora no existía un método estandarizado de medir los requisitos No funcionales del software, esos requisitos del tipo: "quiero que esta consulta tarde 1 segundo en lugar de 10 minutos", "quiero que particiones una tabla de la base de datos", "quiero que cambies el color de las letras de la ventana principal de mi aplicación" o "quiero que ańadas una ayuda contextual a los campos del formulario de alta de empleado".

Para poder medirlos IFPUG ha desarrollado un método compatible con el método de Puntos Función que se denomina SNAP Software Non-functional Assessment Process o lo que es lo mismo proceso de medición no funcional del software. Este método nos permite medir requisitos relativos al rendimiento, a cambios estéticos, a reutilización de componentes, etc.

żQué beneficios aporta SNAP al director de proyectos Software?

Una valoración no funcional puede ayudar a las organizaciones de TI de múltiples formas. Ofrece información al desarrollo y mantenimiento de aplicaciones para ayudar en la estimación y en el análisis de la calidad y de la productividad. Utilizada de forma conjunta con la medida de los Puntos Función, la valoración no funcional ofrece información que puede identificar elementos, que impactan de forma positiva o negativa en la calidad y en la productividad.

Tener esta información, permite a los directores de proyectos software:

- Mejores y más precisos, planes y estimaciones de los proyectos.
- Identificar áreas de mejora de procesos.
- Ayudar a determinar estrategias no funcionales.
- Cuantificar los impactos de las estrategias actuales no funcionales.
- Ofrecer datos específicos para comunicar aspectos no funcionales a públicos diferentes.

Las organizaciones pueden utilizar SNAP como:

- Una metodología para medir el tamańo no funcional de un producto software para ayudar en los análisis de calidad y productividad.
- Una metodología para estimar costes y recursos necesarios para el desarrollo y mantenimiento del software.
- Una metodología para medir la reducción de costes para el desarrollo y mantenimiento del software, además de los Puntos Función.
- Un factor de normalización para la comparación del software.
- Una metodología para determinar el tamańo no funcional de un paquete software adquirido, mediante la valoración de todas las partes y categorías incluidas en el paquete.
- Una metodología para ayudar a los usuarios a determinar los beneficios de un paquete software para su organización, valorando las partes o categorías que específicamente concuerdan con sus requisitos.

żCómo modela SNAP los requisitos no funcionales del software?

Uno de los objetivos principales de SNAP es que la medición sea sencilla, por ello muchos de los requisitos no funcionales que solicite el usuario y que entregue nuestro proyecto serán asociados a una o varias subcategorías dentro de SNAP.
Cada subcategoría tiene asignada una unidad en la que se mide (normalmente coincide con el proceso elemental definido en el método de puntos función).
Dicha unidad se dimensiona asignándole un tamańo en función de la complejidad que tenga.
Esta complejidad es determinada por unos atributos contables fácilmente identificables a partir de los requisitos de usuario como son los DET, los FTR, los elementos estéticos cambiados, los registros de la base de datos alterados, etc.
El final sumando todas las unidades obtenidas para cada una de las subcategorías de SNAP que apliquen obtendremos un total de puntos SNAP.

A partir de ahora puedes comenzar un nuevo camino en la estimación del software aprovechando tus valoraciones en Puntos Función IFPUG que vienes realizando ańadiéndoles la parte no funcional con la medición SNAP y obteniendo así una Medición Total del Software.

Métricas de McCabe

# Complejidad ciclomática

La complejidad ciclomática es una métrica inicialmente propuesta por Thomas J.McCabe en un artículo suyo en 1976 en el que escribía sobre la complejidad en el desarrollo de software.

Esta métrica mide el número de flujos distintos de ejecución que puede tener el código de un artefacto de software, dicho llanamente, nos dice cuantos ifs-then-else, while, for, switchetc, tenemos en nuestro código.

Nos va a dar una medida cuantitativa de como de complejo va a ser comprender el código analizado. A más complejidad ciclomática, más complejo será el código, más complicado de leer, de entender, de modificar, de mantener y, por lo tanto, más caro.

Además, obteniendo su valor, determina el número máximo de pruebas que hay que realizar para asegurarnos que nuestra cobertura de test pasa al menos una vez por cada línea del código.

Otras valoraciones que están en el libro Code Complete 2 (pag.458) de Steve McConnell, a la hora de valorar la complejidad ciclomática en una rutina lo hace de la siguiente manera:

05 La rutina es probablemente buena

610 Comienza a pensar formas de simplificar a la rutina

10+ Extrae partes de las rutinas a otras y llámalas desde la primera

La medida de la complejidad ciclomática no es la única medida sobre la posible calidad del código. Hay otras medidas que se basan en la cantidad de datos usados, número de niveles anidados, número de líneas de código, cantidad de entradas y salidasetc, pero si es la única que nos va a ayudar a pensar en el control de flujo de un programa y en la dificultad de trabajar con él.

# Como calcular la complejidad ciclomática

El cálculo está definido en el artículo de McCabe enlazado anteriormente, pero no todas las herramientas las calculan de la misma forma. Por ejemplo, la aplicación NDepend calcula la complejidad ciclomática en base a las siguientes reglas:

ˇ Por defecto siempre comienza en 1

ˇ Se suma 1 por cada una de las siguientes expresiones encontradas en el cuerpo del método:

while | for | foreach | case | default | continue | goto | && | || | catch | ternary operator?: | ??

ˇ No se tendrán en cuenta a la hora de sumar las siguientes expresiones:

else | do | switch | try | using | throw | finally | return | object creation | method call | field access

ˇ El resultado de la anterior suma nos daría la complejidad ciclomática del método, por lo tanto, la complejidad ciclomática de la clase sería la suma de la de los métodos que tiene.

SonarQube, por ejemplo, tiene su propio cálculo de la complejidad ciclomática dependiendo del lenguaje utilizado. En este enlace se puede ver cuando va incrementando el contador de la complejidad.

# Reducir la complejidad ciclomática

No hay unas reglas escritas fijas que nos digan que hacer o que no hacer, pero si hay una serie de recomendaciones que podemos seguir para minimizar el riesgo de complicar nuestro código y aumentar la complejidad ciclomática de nuestros métodos y clases.

ˇ Principio de responsabilidad única

Nuestros métodos deberían hacer una sola cosa y hacerla bien. Parece una regla sencilla pero muchas veces no está muy claro que es una tarea y que no. Si un método mezcla responsabilidades aumenta la probabilidad de tener sentencias condicionales que separen los flujos de ejecución de cada una de esas responsabilidades y por lo tanto aumente nuestra complejidad ciclomática. Leer más sobre el Principio de Responsabilidad Única.

ˇ Métodos pequeńos

No hay un límite de líneas para considerar un método pequeńo o grande pero creo que todos cuando vemos un método podemos intuir si es pequeńo o grande. Si un método tiene menos de 5 líneas, mejor que uno de 10, mucho mejor que uno de 20 y muchísimo mejor que uno de 50y esperemos que no más :p . Es cierto que la podemos liar y complicar mucho en pocas líneas de código pero parece de sentido común que menos líneas escritas invitan a tener una menor complejidad del método.

ˇ Evitar retornar valores Null

Cuando retornamos valores nulos normalmente tenemos que protegernos de ellos para evitar el famoso NullPointerException. La forma de protegerse suele ser con expresiones condicionales. Si nuestros métodos retornan valores nulos seguramente tendremos muchas sentencias condicionales ifdespués de las llamadas a esos métodos para controlar si la respuesta es un valor nulo o un valor correcto. Todos estos condicionales if, aumentan la complejidad ciclomática. Para evitar el retorno de nulos existen varias técnicas como el patrón de objetos nulos o lanzar excepciones.

ˇ Evitar parámetros opcionales

Aunque ya escribí sobre los parámetros opcionales, conviene recordar la importancia de evitarlos a fin de simplificar la complejidad de un método y reducir la complejidad ciclomática del mismo. Los parámetros básicamente pueden ser de dos tipos: operandos u opciones. Los operandos son aquellos parámetros necesarios con cuyos valores el método opera. Las opciones son aquellos que indican modos de ejecución, żqué significa esto? pues que si un método tiene varios modos de ejecución seguramente tendremos sentencias condicionales en su interior que desvíen en flujo por un sitio u otro en función del valor que tengan esos parámetros.

Los parámetros opcionales rompen el Principio de Responsabilidad Única comentado en el primer punto de esta lista. Evitando los parámetros opcionales, evitamos tener que hacer uso de la lógica If-then-else para evaluar los parámetros opcionales, reduciremos la complejidad ciclomática de nuestros métodos. żY cómo lo evitamos? pues primero separando los distintos flujos que pudiera tener nuestro método en varios métodos y después que sea el cliente que llama a estos métodos el que decida a cual llamar, es decir, no tenemos un método con varios flujos de ejecución, el cliente llama y pasa un parámetro con un valor para seleccionar que se hace, sino que tenemos varios métodos cada uno con un flujo distinto y el cliente llama al que le interese.

ˇ Un solo nivel de indentación (sangrado) por método

También es una buena recomendación a seguir. Si nos obligamos a mantener un único nivel de indentación en un método conseguiremos evitar estructuras anidadas que hagan que nuestra complejidad ciclomática aumente. Si tenemos un bloque de código que va en un segundo, o mayor, nivel de indentación en un código deberíamos, por ejemplo, intentar extraerlo a otro método. Volvemos un poco a lo de siempre: conseguir métodos pequeńos, que hagan una sola cosaetc.

ˇ Evita las sentencias Switch case

Las sentencias switch case tienen bastantes argumentos en contra para su uso. Nuevamente, rompen el principio de responsabilidad única, rompen el principio abierto-cerrado, son complicadas de manejar y entender cuando el número de casos aumenta. Un switch case es en realidad un if-elseif-elseif-elseif-.

Para evitar su uso se puede resolver con polimorfismo de manera que el código de cada una de las opciones se lleva a una clase independiente. Martin Fowler habla de este tipo de refactorización. Aquí se puede ver otro ejemplo de código.

# Ejemplo Análisis de la complejidad ciclomática de un caso real con PHP

En el último proyecto en el que he estado trabajando en Sngular he tenido que implementar una librería para usar el API de Amazon para PHP. Voy a pasar el código por un analizador de código estático para comprobar la complejidad ciclomática del código que he implementado. El analizador ha sido PHPLOC, que es una herramienta para realizar análisis de estático de código, implementada por S ebastian Bergmann creador también de PHPUNIT.

Métricas de Halstead

Las métricas de Complejidad de Halstead fueron desarrolladas por Maurice Halstead como un medio de determinar la complejidad cuantitativa directamente de los operadores y operandos usados en el código fuente de un módulo.

Para esto, Halstead definió los siguientes números:

ˇ el número de operadores (únicos) distintos (n1) en el programa fuente

ˇ el número de operandos (únicos) distintos (n2) en el código fuente

ˇ el número total de operadores en un archivo de código fuente (N1)

ˇ el número total de operandos en un archivo de código fuente (N2)

Para calcular estos números tomamos todos los tokens distintos de un programa fuente, calculando la frecuencia de cada uno.

Para esto clasificaremos los tokens de un programa en:

ˇ Operandos: Pueden ser los identificadores que no sean palabras reservadas, las constantes numéricas, los identificadores de tipos (bool, string, char, int, long, etc), los caracteres y strings constantes.

ˇ Operadores: Que pueden ser todas las palabras reservadas (if, do, while, class, etc), los calificadores (como const, static) las palabras reservadas, y los operadores en expresiones (+, -, <>, ==, !=, <=, >>, etc).

En 1977, el Seńor Maurice Howard Halstead introdujo sistemas de medida para medir la complejidad del software. Las medidas de Halstead dependen de la implementación real del programa y de sus medidas, las cuales son computadas directamente desde los operadores y operandos del código de origen, de forma estática. Permite evaluar el 'testing time', el vocabulario, la medida, dificultad, errores, y esfuerzos para códigos de origen C/C++/Java.

Según Halstead, Un programa de ordenador es una implementación de un algoritmo considerado una colección de símbolos que se pueden clasificar como operadores o como operandos. Las medidas de Halstead toman al programa como una secuencia de operadores y sus operandos relacionados.

Define varios indicadores para evaluar la cmplejidad del módulo.

Parámetro | Significado
n1 | Número de un solo operador
n2 | Número de un solo operando
N1 | Número total de casos de operadores
N2 | Número total de casos de operandos

Cuando seleccionamos origen del archivo para ver sus detalles de complejidad en un Visor Métrico, se ven los siguientes resultados en él Informa Métrico:

Métrico | Significado | Representación matemática
n | Vocabulario | n1 + n2
N | medida | N1 + N2
V | Volumen | Longitud * Log2 Vocabulario
D | Dificultad | (n1/2) * (N1/n2)
E | Esfuerzos | Dificultad * Volumen
B | Errores | Volumen / 3000
T | 'Testing time' | Tiempo = esfuerzos / S, donde S=18 segundos.

## Medidas de Complejidad ciclomática

Cada programa incluye enunciados para ejecutar con tal de llevar a cabo una tarea y otros enunciados de toma de decisiones que deciden, qué órdenes son necesarias. Los enunciados de toma de decisiones cambian el flujo del programa.

Si comparamos dos programas del mismo tamańo, el que tiene más enunciados de toma de decisiones será más complejo ya que el control de programa salta con frecuencia.

McCabe, en 1976, propuso la medida de complejidad ciclomática para cuantificar la complejidad de un software. Es un modelo gráfico determinado que se basa en las órdenes de toma de decisiones del programa como el if-else, do-while, repeat-until, switch-case y goto statements.

Proceso para realizar un gráfico de flujo de control:

- Rompa el programa en pequeńos bloques, delimitados por las tomas de decisiones.
- Cree nódulos representando cada uno de estos nódulos.
- Conecte los nódulos de la siguiente forma:

o Si el control se puede ramificar del bloque i al bloque j

Dibuje un arco

o Desde el nódulo de salida hasta el nódulo de entrada

Dibuje un arco.

Para calcular la complejidad ciclomática del nódulo de un programa, usaremos la fórmula -

    V(G) = e  n + 2

    Where

    e is total number of edges

    n is total number of nodes

Es ampliamente usada para medir el tamańo del software. La Métrica de punto función, se centra en la funcionalidad que aporta el sistema. Las características y funcionalidades del sistema se usan para medir la complejidad del software.

La Métrica de punto función, cuenta con cinco parámetros, llamados Entrada externo, Salida externa, Archivos de lógica interna, Archivos de interfaz externa, y Consulta externa. Para considerar la complejidad del software cada parámetro se categorizará como simple, medio o complejo.

Líneas de código

La definición de línea de código fuente es esencialmente ambigua para la mayor parte del software. Su significado varía de un lenguaje de programación a otro, pero también dentro de un mismo lenguaje de programación.

Una línea de código fuente es cada una de las líneas de un archivo de código fuente de un programa informático. Habitualmente en cada línea se ejecuta una instrucción que tiene que ejecutar el programa. También es habitual tabular las estructuras de control del programa en cuestión para una lectura más fácil. Viene a ser como la oración en libros y textos escritos en general.

En ocasiones los programadores hablan del número de líneas de código que tiene cierto programa para hablar de la magnitud o complejidad de este.

En computación, el número de línea de una instrucción es un punto bastante útil a la hora de compilar el programa porque habitualmente los compiladores detectan errores de programación mostrando el número de línea donde se ha encontrado el error que el programador deberá corregir para una compilación satisfactoria.

Como curiosidad, algunos programadores se divierten complicando la forma de programar, bien por diversión, como reto entre programadores, o para que sea imposible de entender para un programador poco experimentado. A este pasatiempo se le denomina programación ofuscada y uno de los puntos más habituales para programar instrucciones por línea o a veces se corta una instrucción en varias líneas. Los más experimentados en este tipo de pasatiempos, se atreven incluso a realizar obras de Ascii art con las líneas de su código fuente.

Los programas se construyen con líneas de código, instrucciones que manejan la información que recibe el programa y devuelven el resultado esperado por el programador.
Cuantas más líneas de código tiene un programa, más grande y complejo es -al menos en teoría-. Programas con muchas líneas de código fuente son también mucho más difíciles de mantener al día, y son más propensos a tener puntos débiles.
Vamos a hacer un breve repaso de los programas más populares y el número de líneas de código que tienen, así como del lenguaje de programación con el que se crearon. Avisamos: vas a llevarte alguna que otra sorpresa...
Cómo saber cuántas líneas de código tiene un programa
Hemos buscado la cantidad de líneas de código fuente de los programas más famosos utilizando principalmente tres métodos: fuentes primarias (artículos), cálculo automático mediante la herramienta CLOC y consultas en la página OhLoh.
Para calcular el número de líneas de código fuente de un programa, el procedimiento es bastante sencillo:
Descarga el código fuente del programa y descomprímelo en una carpeta
Descarga CLOC (Count Lines of Code) y cópialo al directorio Windows
Desde la ruta en la que está la carpeta con el código, escribe el comando cloc <carpeta>
CLOC reconoce más de cien lenguajes de programación, y su informe separa el código de las líneas en blanco y las líneas de comentario, lo que permite efectuar un cálculo más preciso de la cantidad de líneas del programa.

En el contexto de la informática, el código fuente se define como el conjunto de líneas de textos, que son las directrices que debe seguir la computadora para realizar dicho programa; por lo que es en el código fuente, donde se encuentra escrito el funcionamiento de la computadora.

El código fuente de un programa está escrito en un lenguaje de programación determinado, sin embargo, este tipo de lenguaje no puede ser ejecutado directamente por el computador, sino que debe ser traducido a otro lenguaje que el ordenador pueda ejecutar más fácilmente. Para esta traducción se emplean los llamados compiladores, ensambladores, intérpretes, entre otros.

Acceder al código fuente de un programa, consiste en tener acceso a los algoritmos desarrollados por sus creadores. Es la única forma de transformar de manera eficiente un programa.

Cuando se habla de liberar un código fuente significa compartir ese escrito con cualquier sujeto que lo requiera, es decir que cualquier individuo, puede analizarlo, copiarlo y modificarlo. La liberación de un código de un programa conlleva cierta inseguridad, ya que su funcionamiento queda expuesto. De igual manera no suele liberarse para las aplicaciones comerciales.

El código fuente, a su vez, también es empleado para referirse al código fuente de otros componentes del software, como es el caso del código fuente de una página web, el cual está escrito en lenguaje HTML o en Javascript; y que luego es ejecutado por el navegador web, para que la pagina pueda ser vista al momento de visitarla.

La rama de la informática encargada de la creación de los códigos fuente es la ingeniería de software.

El código fuente es el archivo o conjunto de archivos que tienen un conjunto de instrucciones muy precisas, basadas en un lenguaje de programación, que se utiliza para poder compilar los diferentes programas informáticos que lo utilizan y se puedan ejecutar sin mayores problemas.

Puntos de función

La medida de punto de función se diseńó originalmente para aplicarse a aplicaciones de sistemas de información de gestión. Para acomodar estas aplicaciones, se enfatizó la dimensión de datos (los valores de dominios de información) para la exclusión de dimensiones (control) funcionales y de comportamiento.
Por esta razón, la medida del punto de función era inadecuada para muchos sistemas de ingeniería y sistemas empotrados (que enfatizan función y control). Para remediar esta situación se ha propuesto un número de extensiones a la métrica del punto de función básica. 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. Ya que la Ťfuncionalidad>> no se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas.
Las métricas orientadas a la función fueron propuestas por primera vez por Allan Albretch. Una extensión del punto de función es la llamada puntos de características; es una ampliación de la medida del punto de función que se puede aplicar a sistemas y aplicaciones de ingeniería del software. La medida de punto de característica acomoda a aplicaciones en donde la complejidad del algoritmo es alta. Las aplicaciones de software de tiempo real, de control de procesos, y empotradas tienden a tener alta complejidad de algoritmos y por lo tanto son adecuadas para el punto de característica. Los puntos de función se derivan con una relación empírica según las medidas contables (directas) del dominio de información del software y las evaluaciones de la complejidad del software.

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 forma siguiente:

ˇ Número de entradas de usuario. Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicación. Las entradas se deberían diferenciar de las peticiones, las cuales se cuentan de forma separada.

ˇ Número de salidas de usuario. Se cuenta cada salida que proporciona al usuario información orientada a la aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los elementos de datos particulares dentro de un informe no se cuentan de forma separada.

ˇ 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. Se cuenta cada petición por separado.

ˇ Número de archivos. Se cuenta cada archivo maestro lógico (esto es, un grupo lógico de datos que puede ser una parte de una gran base de datos o un archivo independiente).

ˇ Número de interfaces externas. Se cuentan todas las interfaces legibles por la máquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir información a otro sistema.

Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de complejidad. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada en particular es simple, media o compleja.

Las métricas orientadas a Puntos de Función se caracterizan por:

ˇ Tener un componente empírico, basado en la experiencia de muchos proyectos.

ˇ Tener en cuenta la complejidad, aunque es muy difícil de determinar en un proyecto

ˇ Ser independientes del entorno tecnológico y de las metodologías aplicadas.

ˇ Utilizar medidas indirectas, que se caracterizan por ser subjetivas y difíciles de calcular, sin embargo, el resultado obtenido es fácilmente comparable.

Todo proyecto de desarrollo de software comienza con una etapa de estimación y planificación, en la cual debemos determinar, a partir de los requerimientos del software, cuánto esfuerzo, personal, recursos materiales, tiempo y en última instancia dinero tomará construir el sistema o producto.
No solo los gerentes de proyectos estiman software, pues a cada desarrollador, analista de sistemas y software tester se le suele asignar un componente y se le pregunta cuánto tiempo le tomará elaborarlo.
Estas estimaciones suelen elaborarse de forma empírica, en base a la experiencia pasadas y conocimiento del trabajo a realizar, sin embargo, suelen ser imprecisas debido a que los requerimientos y sus implicaciones técnicas no se conocen en su totalidad y además ningún desarrollo de software es exactamente igual a uno anterior con el que se pueda comparar.
Frente a esto, se han desarrollado métodos como el de puntos de función, donde estimamos las funcionalidades usando fórmulas matemáticas basadas en parámetros como el tipo de componente, complejidad, factores del entorno, entre otros aspectos.
En este artículo presentamos una introducción a las estimaciones de proyectos de software usando los puntos de función, incluyendo que es, diferencias respecto a estimar en base a experiencia, un sencillo ejemplo y como puede ser de utilidad a distintos profesionales de ingeniería de software.

Es una técnica de estimación de software desarrollada originalmente por Allan Albrecht en 1979 mientras trabajaba para IBM, quien definió conceptos para medir el software a partir de valoraciones de funcionalidades entregadas al usuario y no a partir de aspectos técnicos, con la intención de producir valoraciones independientes de la tecnología y fases del ciclo de vida utilizado.
El trabajo de Albrecht fue continuado por el grupo internacional de usuarios de puntos de función, quienes plasmaron sus conceptos en el método IFPUG-FPA.
IFPUG-FPA realiza las valoraciones a partir de la funcionalidad del sistema, primero clasificándolas, luego asignando una complejidad y ponderación a cada una según unas tablas predefinidas, determinando así el valor de puntos de función.
Sumando los puntos de todas las funcionalidades se obtiene la valoración de todo el proyecto y finalmente se puede aplicar un factor de ajuste, que puede depender de características generales del sistema como por ejemplo requerimientos no funcionales como el rendimiento, reusabilidad, facilidad de instalación y operación entre otros aspectos.
Los puntos de función permiten traducir el tamańo de funcionalidades de software a un número, a través de la suma ponderadas de las características que este tiene.
Una vez que tenemos los puntos de función, podemos traducirlos en horas hombre o días de trabajo, según factor de conversión que dependería de mediciones históricas de nuestra productividad. Con las horas hombre, podemos determinar el costo y presupuesto de los proyectos.

## żExisten otros métodos de puntos de función distintos de IFPUG-FPA?

Si, desde que surgió el IFPUG-FPA, los métodos de puntos de función se han diversificado, produciendo las siguientes variantes:

ˇ NESMA: Método definido por la Netherlands Software Metrics Association.

ˇ MkII: Método definido por el United Kingdom Software Metrics Association.

ˇ COSMIC: Denominado Full Function Points o COSMIC-FFP, fue desarrollado por el Common Software Metrics Internacional Consortium.

ˇ FiSMA: De la asociación finlandesa de medición de software.

Sígue el siguiente enlace y te presentamos un ejemplo de estimación con COSMIC:
> Ejemplos de estimación de costos de un proyecto de software
Cada uno de estos métodos tiene aplicaciones en distintos tipos de proyectos de software. Además, cada uno cuenta con su estándar ISO.

## żPara qué se utiliza el método de puntos de función?

Estimación de proyectos de software

Una de las principales aplicaciones del método es en la determinación de valoraciones (estimaciones) del producto de software a desarrollar, que es una parte fundamental de todo proceso de ingeniería de software y de la gerencia de estos proyectos.
Dentro del ciclo de ingeniería de software, lo normal es que la estimación del proyecto ocurra después que la ingeniería de requerimientos produzca una primera versión de la especificación de requisitos con suficiente información para elaborar la estimación.

Validar la calidad de las especificaciones funcionales

Si asignamos el mismo requisito a dos Analistas de sistemas y la estimación producida por los puntos de función difiere, esto nos puede servir para identificar ambigüedades en las especificaciones funcionales.

Seguimiento y control de proyectos
Otras aplicaciones de los puntos de función incluyen el seguimiento y control de proyectos, donde se puede usar para estimar el impacto de cambios en la funcionalidad solicitados durante el desarrollo y también para medir en puntos de función el avance del proyecto e inclusive la facturación en contratos de servicios.

Medir la productividad y calidad de nuestro proyecto o servicio de ingeniería de software
Por otra parte, los puntos de función tienen aplicaciones en mediciones de productividad, por ejemplo si dividimos las horas hombre empleadas para producir cierta cantidad de puntos de función, obtenemos un indicador de productividad de nuestro equipo y de cómo esta puede mejorar en el tiempo.
Con esto adicionalmente podemos calibrar el factor de conversión entre puntos función y horas hombre que utilicemos para nuestras estimaciones.

Métricas de software orientada a objetos

El Software Orientado a Objetos (OO) es fundamentalmente distinto del software que se desarrolla utilizando métodos convencionales. Las métricas para sistemas OO deben de ajustarse a las características que distinguen el software OO del software convencional.

Estas métricas hacen hincapié en el encapsulamiento, la herencia, complejidad de clases y polimorfismo. Por lo tanto las métricas OO se centran en métricas que se pueden aplicar a las características de encapsulamiento, ocultamiento de información, herencia y técnicas de abstracción de objetos que hagan única a esa clase. Como en todas las métricas los objetivos principales de las métricas OO se derivan del software convencional: comprender mejor la calidad del producto, estimar la efectividad del proceso y mejorar la calidad del trabajo realizado a nivel del proyecto.

Se conoce que las medidas y las métricas son componentes clave de cualquier disciplina de la ingeniería; la ingeniería de software orientada a objetos no es una excepción. Lamentablemente, la utilización de métricas para sistemas orientados a objetos ha progresado con mucha más lentitud que la utilización de los demás métodos OO [Luis A. Laranjeira 90]. Sin embargo, a medida que los sistemas OO van siendo más habituales, resulta fundamental que los ingenieros del software dispongan de mecanismos cuantitativos para estimar la calidad de los diseńos y la efectividad de los programas 00.

Los objetivos principales de las métricas orientadas a objetos son los mismos que los existentes para las métricas surgidas para el software estrucutrado: ˇ Comprender mejor la calidad del producto ˇ Estimar la efectividad del proceso ˇ .Mejorar la calidad del trabajo realizado en el nivel del proyecto. Cada uno de estos objetivos es importante en sí, pero para el ingeniero de software, la calidad del producto debe de ser lo esencial.

El software orientado a objetos es esencialmente distinto del software que se desarrolla utilizando métodos convencionales. Por esta razón, las métricas para sistemas 00 deben de concordarse a las características que distinguen el software 00 del software convencional. 115 Berard [Laranjeira 90] define cinco características que dan lugar a unas métricas especializadas: ˇ Localización, ˇ Encapsulamiento, ˇ Ocultamiento de información, ˇ Herencia y ˇ Técnicas de abstracción de objetos.

Localización

La localización es una característica del software que indica la forma que se concentra la información dentro de un programa. En el contexto OO, la información se concentra mediante el encapsulamiento tanto de datos como de procesos dentro de los límites de una clase u objeto. Dado que el software convencional hace hincapié en las funciones como mecanismos de localización, las métricas de software se han centrado en la estructura interna o complejidad de las funciones (p. ej.: longitud del módulo, cohesión, o complejidad ciclomática) o bien en la forma en que las funciones se conectan entre sí (p. ej.: acoplamiento de módulos). Dado que las clases constituyen la unidad básica de los sistemas 00, la localización está basada en los objetos. Por tanto, las métricas deberían de ser aplicables a la clase (objeto) como si se tratara de una entidad completa. Además, la relación entre operaciones (funciones) y clases no es precisamente uno-a-uno.

Por tanto, las métricas que reflejan la forma en que colaboran las clases deben de ser capaces de adaptarse a las relaciones uno-a-muchos y muchos-a-unoEncapsulamiento Berard [Pressman 98] define el encapsulamiento como el empaquetamiento (o enlazado) de una colección de elementos. Entre los ejemplos de encapsulamiento de bajo nivel (software convencional) se cuentan los registros y matrices, y los subprogramas (por ejemplo, procedimientos, funciones, subrutinas y párrafos) son mecanismos de nivel medio para el encapsulamiento. Para los sistemas 00, el encapsulamiento comprende las responsabilidades de una clase, incluyendo sus atributos (y otras clases para objetos agregados) y operaciones, y los estados de la clase, según se definen mediante valores específicos de atributos.

El encapsulamiento influye en las métricas cambiando el objetivo de la medida, que pasa de ser un único módulo a ser un paquete de datos (atributos) y de módulos de procesamiento (operaciones). Además, el encapsulamiento impulsa a la medida hasta un nivel de abstracción más elevado.

Ocultamiento de información

El ocultamiento de información suprime los detalles operativos de un componente de un programa. Tan sólo se proporciona la información necesaria 117 para acceder a ese componente o a aquellos otros componentes que deseen acceder a él. Un sistema 00 bien diseńado debería de impulsar al ocultamiento de información. Por tanto, aquellas métricas que proporcionen una indicación del grado en que se ha logrado el ocultamiento proporcionarán una indicación de la calidad del diseńo 00.

Herencia

La herencia es un mecanismo que hace posible que los compromisos de un objeto se difundan a otros objetos. La herencia se produce a lo largo de todos los niveles de la jerarquía de clases, bien es sabido que en general, el software convencional, no admite esta característica. Dado que la herencia es una característica fundamental de muchos sistemas 00, hay muchas métricas 00 que se centran en ella. Esto se conocerá entre los ejemplos que se tratarán más adelante: se cuentan el número de descendientes (número de instancias inmediatas de una clase), número de predecesores (número de generalizaciones inmediatas), y grado de anidamiento de la jerarquía de clases (profundidad de una clase dentro de una jerarquía de herencia) y otros.

Abstracción

La abstracción es un mecanismo que permite al diseńador centrarse en los detalles esenciales de algún componente de un programa (tanto si es un dato 118 como si es un proceso) sin preocuparse por los detalles de nivel inferior. Cuando los niveles de abstracción van elevándose, se ignoran más y más detalles, por lo tanto, se proporciona una visión más general de un concepto u objeto.

A medida que pasamos a niveles más reducidos de abstracción, se muestran más detalles, esto es, se proporciona una visión más específica de un concepto u objeto. Dado que una clase es una abstracción que se puede visualizar con muchos niveles distintos de detalles, y de muchas maneras diferentes, las métricas OO representan la abstracción en términos de medidas de una clase (p.ej.: número de instancias por clase por aplicación). Métricas para el modelo de diseńo Orientado a Objetos Gran parte del diseńo orientado a objetos es subjetivo un diseńador experimentado sabe como puede caracterizar un sistema 00 para que se implemente de forma efectiva los requisitos del cliente. Pero a medida que los modelos de diseńo 00 van creciendo de tamańo y complejidad, puede resultar beneficiosa una visión más objetiva de las características del diseńo, tanto para el diseńador experimentado como para el menos experimentado.

Una visión objetiva del diseńo debería de tener un componente cuantitativo y esto nos lleva a las métricas 00, en donde se pueden aplicar no solo al modelo de diseńo, sino también al modelo de análisis [Laranjeira.90]. 119 6.4 Métricas orientadas a Clases Se sabe que la clase es la unidad principal de todo sistema 00. Por consiguiente, las medidas y métricas para una clase individual, la jerarquía de clases, y las colaboraciones de clases resultarán sumamente valiosas para un ingeniero de software que tenga que estimar la calidad de un diseńo. Se ha visto que la clase encapsula a las operaciones (procesamiento) y a los atributos (datos).

La clase suele ser el predecesor de las subclases (que a veces se denominan descendientes) que heredan sus atributos de operaciones. La clase suele colaborar con otras clases. Todas estas características se pueden utilizar como bases de las métricas explicadas, enseguida: El conjunto de métricas CK Uno de los conjuntos de métricas de software 00 a los que se hace más ampliamente referencia es el propuesto por Chidamber y Kemener [Laranjeira 90]. Estas métricas propuestas de diseńo basadas en clases, a las cuales suele aludirse con el nombre de conjunto de métricas CK para sistemas 00. Los métodos ponderados por clase (MPC), son aquellos en donde se definen n métodos de complejidad C1, C2..., Cn, para una clase C. La métrica de complejidad específica que se selecciona debe de normalizarse de tal modo que la complejidad nominal para un método tome el valor 1.0. MPC = Ó Ci para i = 1 hasta n (6.1) 120 El número de métodos y su complejidad es un indicador razonable de la cantidad de esfuerzo necesaria para implementar y comprobar una clase. Además, cuanto mayor sea el número de métodos, más complejo será el árbol de herencia, (todas las subclases heredan el método de sus predecesores). Finalmente, a medida que el número de métodos crece para una clase dada; es más probable que se vuelva cada vez más específico de la aplicación, imitando por tanto su potencial de reutilización. Por todas estas razones, MPC debería de mantener un valor tan bajo como sea razonable. Aun cuando podría parecer relativamente sencillo desarrollar un contador del número de métodos de una clase, el problema es en realidad más complejo de lo que parece. Churcher y Shepperd [Laranjeira 90] examinan este problema precisamente cuando escriben: Para contar métodos, es preciso responder a una pregunta fundamental: żPertenece un método solamente a la clase que lo define, 0 bien pertenece también a todas aquellas clases que lo heredan de forma directa o indirecta?. Las preguntas como estas pueden parecer superficiales, por cuanto el sistema de ejecución acabará últimamente por resolverlas. Sin embargo, las implicaciones para las métricas pueden ser significativas.

Una posibilidad es restringir el recuento a la clase en curso, ignorando los miembros heredados. La motivación para esto sería que los miembros heredados ya habrán sido contados en las clases en que fueran definidos, así que el incremento de clase es la mejor medida de su funcionalidad. Con objeto de entenderlo que hace una clase, la fuente de información más importante son sus propias operaciones. Por otro lado, el recuento podría envolver a todos aquellos métodos definidos en la clase en curso, junto con todos los métodos heredados.

Este enfoque hace hincapié en la importancia del espacio de estados, en lugar de hacer hincapié en el incremento de la clase, para comprender la clase. Al igual que la mayoría de las convenciones de recuento en las métricas de software, cualquiera de los enfoques mencionados anteriormente es aceptable, siempre y cuando este enfoque de recuento se aplique de forma consistente siempre que se recoja una métrica. Árbol de Profundidad de Herencia (APH). Esta métrica se define como la longitud máxima desde el nodo], el valor de APH para la jerarquía de clases mostrada el valor resultante es 4. A medida que crece el APH, es más probable que las clases de niveles inferiores hereden muchos métodos. Esto da lugar a posibles dificultades cuando se intenta predecir el comportamiento de una clase. Una jerarquía de clases profunda (con un valor grande de APH) lleva también a una mayor complejidad de diseńo. Por el lado positivo, los valores grandes de APH implican que se pueden reutilizar muchos métodos.

Una Jerarquía de Clases [Pressma 98] Número de Descendientes (NDD). Las subclases que son inmediatamente subordinadas a una clase son denominan descendientes. la clase C2 tiene tres descendientes las subclases C21, C22 y C23. A medida que crece el número de descendientes, se incrementa la reutilización, pero también es cierto, que a medida que crece NDD, la abstracción representada por la clase predecesora puede verse diluida. Esto es, existe la posibilidad de que algunos de los descendientes no sean realmente miembros propios de la clase predecesora. A medida que NDD va creciendo, la cantidad de pruebas crecerá también. Respuesta Para una Clase (RPC). El conjunto de respuestas de una clase es un conjunto de métodos que pueden ser ejecutados potencialmente en respuesta a un mensaje recibido por un objeto de esa clase [Pressman98]

Calidad del proceso de un Sw

La calidad de los procesos de desarrollo software de una organización es uno de sus pilares más importantes, tanto por ser un elemento diferenciador para sus clientes, como por la importancia interna para su cultura empresarial. Para que una organización pueda asegurar la calidad de sus procesos es necesario llevar a cabo un proceso de evaluación y mejora de los mismos, que permita alinear el desarrollo de la empresa a las mejores prácticas de la Ingeniería del Software.

La evaluación y mejora de la calidad de los procesos de desarrollo software es una práctica ampliamente extendida, cuyo objetivo es controlar la calidad del software a través de la institucionalización y mejora continua de los procesos que se utilizan para su desarrollo. Para ello, a lo largo de los últimos ańos han ido surgiendo diferentes modelos para evaluar y mejorar la capacidad de los procesos de desarrollo software y la madurez de las fábricas de software, entre los que se puede destacar CMMI e ISO/IEC 15504

Actualmente AQC trabaja principalmente con dos modelos para apoyar a las empresas en la mejora de sus procesos de desarrollo software:

#### ISO/IEC 15504 (SPICE: SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION)

La norma ISO/IEC 15504 es una norma internacional, desarrollada por ISO, cuyo objetivo es evaluar y mejorar la capacidad y madurez de los procesos.

Para las empresas desarrolladoras de software, la norma ISO/IEC 15504 se utiliza junto con la norma ISO/IEC 12207 (el modelo de referencia de procesos) para evaluar y mejorar la capacidad y madurez de los procesos de desarrollo y mantenimiento software.

#### AUTOMOTIVE SPICE

Para las empresas desarrolladoras de software en el sector de la automoción, el Automotive SIG Special Interest Group, de la industria del automóvil (formado por AUDI, Fiat, Ford, BMW, Land Rover, Porsche, Volkswagen y Volvo entre otros) diseńó un esquema de evaluación específico que contemplaba las características específicas de la industria automotriz, el Automotive SPICE.

El Automotive SPICE sigue las reglas establecidas por la ISO 15504 y la ISO 12207, por lo que es muy similar al esquema utilizado normalmente en software, siendo la principal diferencia que se evalúa por capacidad (procesos individuales) y fija un subconjunto específico de entre todos los procesos de la ISO 12207.

Método de trabajo

El principal objetivo de Alarcos Quality Center en los proyectos de evaluación y mejora de la calidad de procesos es aportar valor a la organización, analizando los procesos existentes y reutilizando todo lo que esté alineado a la norma.

Las fases de este tipo de proyecto son:

ˇ Evaluación de la situación inicial de la compańía.

ˇ Adaptación y desarrollo de los procesos necesarios.

ˇ Instanciación de los procesos en proyectos de la compańía.

ˇ Evaluación final para garantizar el cumplimiento de la norma.

ˇ Apoyo durante el proceso de certificación.

Beneficios para los clientes

ˇ rabajar bajo un modelo internacionalmente reconocido, basado en una norma ISO, internacional y abierta, alineada a otros modelos ISO que pueda tener implantados la organización como ISO 9001, ISO 20000, o ISO 27000.

ˇ Utilizar un modelo de buenas prácticas actualizado y específico de desarrollo software (ISO 12207:2008).

ˇ Evaluación de la organización por niveles de madurez, la evaluación más extendida entre los modelos de mejora.

ˇ Menor coste de certificación que otros modelos similares.

ˇ Obtener la certificación para el Modelo de Madurez de la Ingeniería del Software ISO/IEC 15504-SPICE, emitida por AENOR (Asociación Espańola de Normalización y Certificación).

ˇ Conseguir reconocimiento frente a la competencia.

ˇ Crear una cultura de desarrollo software organizacional que le permitirá:

o Implantar una metodología de desarrollo.

o Controlar todas las fases y áreas de gestión de un proyecto software.

o Detectar y corregir posibles fallos en cada etapa de un proyecto.

o Aumentar de los beneficios del proyecto.

ˇ Aumentar la satisfacción de los clientes.

Algunos modelos de calidad especializados en prueba
Los MC que hemos utilizado en proyectos de mejora de capacidades de prueba (incluidas las nuestras) son: Test Process Improvement (TPI),

Aunque nosotros vemos con claridad que en el desarrollo de software la relación entre la calidad del proceso y la calidad de producto no es tan fuerte como en la manufactura, también lo estamos de que el trabajo en la mejora de los procesos de prueba es una labor que no debe dejar de hacerse. En nuestra experiencia, hemos visto que resulta útil iniciar con un modelo ligero como el TAM, que con costos moderados permite mejorar significativamente las capacidades y luego, si lo que se busca es una certificación internacional, brincar a un modelo como TPI, aprovechando los ahorros económicos obtenidos de la mejora anterior.

Componentes de desarrollo de un Sw, actividades y escala

La meta de la ingeniería de software es construir productos de software, o mejorar los existentes; en ingeniería de procesos, la meta es desarrollar o mejorar procesos.

Un proceso de desarrollo de software es un conjunto de personas, estructuras de organización, reglas, políticas, actividades y sus procedimientos, componentes de software, metodologías, y herramientas utilizadas o creadas específicamente para definir, desarrollar, ofrecer un servicio, innovar y extender un producto de software.

Un proceso de software efectivo habilita a la organización a incrementar su productividad al desarrollar software:

- Permite estandarizar esfuerzos, promover reusó, repetición y consistencia entre proyectos.
- Provee la oportunidad de introducir mejores prácticas de la industria.
- Permite entender que las herramientas deben ser utilizadas para soportar un proceso.
- Establece la base para una mayor consistencia y mejoras futuras.

Un proceso de software mejora los esfuerzos de mantenimiento y soporte:

- Define cómo manejar los cambios y liberaciones a sistemas de software existentes.
- Define cómo lograr la transición del software a la operación, y cómo ejecutar los esfuerzos de operación y soporte.

Necesitamos un proceso de software cuya funcionalidad esté probada en la práctica, y personalizado para que cumpla con nuestras necesidades específicas.

### ISO 9001-2000

ISO (International Standards Organization) en 1987 crea la norma ISO 9000, conjunto de estándares que establecen los requerimientos para la gestión de los sistemas de calidad. ISO 9000:2000 está formado por:

- ISO 9000 Fundamentos y Vocabulario.
- ISO 9001 Requisitos.
- ISO 9004 Recomendaciones.

La parte de Requisitos - ISO 9001:2000, está estructurado en 8 secciones:

1. Alcance.
2. Normas para la Consulta.
3. Términos y Definiciones.
4. Sistema de Gestión de la Calidad.
5. Responsabilidad de la Dirección.
6. Gestión de los Recursos.
7. Realización del Producto.
8. Medida, Análisis y Mejora.

Aunque ISO 9001:2000 no otorga un estándar específico para sistemas de desarrollo de software, es decir, no abarca todos los procesos relacionados con el desarrollo de software, muchas organizaciones de software han optado por gestionar su sistema de calidad en base a este estándar, y obtener una certificación reconocida de manera internacional.

### CMMI (Capability Maturity Model Integration) - Modelo de Madurez de Capacidades Integrado

El proyecto de CMMI fue concebido como una iniciativa para reunir los diferentes CMMs en un conjunto de modelos integrados, más consistentes entre ellos. Los modelos fuente que sirvieron como bases incluyen: CMM Software, CMM Ingeniería de Sistemas, y CMM Desarrollo Integrado de Producto.

CMMI proporciona una guía para desarrollar procesos, que además ayuda a evaluar la madurez de la organización o capacidad de un área de procesos. CMMI incluye los procesos de ingeniería de software e ingeniería de sistemas.

El modelo está representado de forma continua y escalonada. Contiene 22 áreas de procesos. Cada área de proceso está formada por: Objetivos específicos, Prácticas específicas, Objetivos genéricos, y Prácticas genéricas.

CMMI Modelo Continuo

Está formado por 5 niveles de capacidad del proceso:

0. Incompleto

1. Desempeńado

2. Administrado

3. Definido

4. Administrado cuantitativamente

5. Optimizado

Y por cuatro categorías de áreas de procesos: Administración de Procesos, Administración de Proyectos, Ingeniería, Soporte. Estas categorías agrupan a las diferentes áreas de proceso, dividiéndolos en procesos básicos y avanzados.

CMMI Modelo Escalonado

El modelo escalonado, al igual que CMM, describe un camino evolutivo en 5 niveles de madurez de procesos, además integra nuevas áreas de proceso.

La selección entre el modelo escalonado y el continuo depende del objetivo de la organización, además de tener que considerar la situación (si ya se tiene CMM, cultura en procesos, etc.). Por ejemplo, si el objetivo es llevar a la organización a cierto nivel de capacidad, deberá seleccionarse la forma escalonada; en cambio si el objetivo es mejorar cierto proceso, será mejor seguir la forma continua.

Algunos Beneficios de CMMI vs. CMM

Algunos de los beneficios que han experimentado las organizaciones que pasan de CMM a CMMI son los siguientes:

- Mejor alineación a objetivos de negocio.
- Mejor visibilidad hacia las actividades de ingeniería, con el objetivo de asegurar que el producto o servicio cumple las expectativas del cliente.
- Aprovechamiento de mejores prácticas adicionales (e.j., medición, riesgo, administración, y manejo de proveedores).
- Acoplamiento más estrecho con estándares de ISO.

La importante tarea a la hora de crear un producto de software es obtener los requisitos o el análisis de los requisitos. Los clientes suelen tener una idea más bien abstracta del resultado final, pero no sobre las funciones que debería cumplir el software.

Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo. Este documento se conoce como especificación funcional.

ˇ Planificación: es el paso previo al inicio de cualquier proyecto de desarrollo y sin dudas el más importante. En este se definen los requerimientos y funcionalidades que debe tener el software, mediante el trabajo en conjunto entre los desarrolladores, el departamento de ventas, los estudios de mercado y, fundamentalmente, el contacto con el cliente. En este punto se realizan asimismo los análisis de riesgo para el emprendimiento y se fijan los requisitos de aseguramiento de la calidad.

### Implementación, pruebas y documentación

La implementación es parte del proceso en el que los ingenieros de software programan el código para el proyecto de trabajo que está en relación de las demanda del software, en esta etapa se realizan las pruebas de caja blanca y caja negra.

Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del proceso tiene la función de detectar los errores de software lo antes posible.

La documentación del diseńo interno del software con el objetivo de facilitar su mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentación de un API, tanto interior como exterior. Prácticamente es como una receta de cocina

### Despliegue y mantenimiento

El despliegue comienza cuando el código ha sido suficientemente probado, ha sido aprobado para su liberación y ha sido distribuido en el entorno de producción.

Entrenamiento y soporte para el software es de suma importancia y algo que muchos desarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del software.

El mantenimiento o mejora de un software con problemas recientemente desplegado, puede requerir más tiempo que el desarrollo inicial del software. Es posible que haya que incorporar código que no se ajusta al diseńo original con el objetivo de solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que sea oportuno rediseńar el sistema para poder contener los costes de mantenimiento.

El trabajo a través de proyectos es la forma frecuente de actuación en el desarrollo de software. Diversas han sido las conceptualizaciones que se han hecho de un proyecto, manteniéndose como factor común en todas las presencias de un conjunto de etapas compuestas por actividades para alcanzar un objetivo en un tiempo determinado.

Los proyectos de desarrollo de software, al igual que el resto, deben iniciarse con un buen plan, pero lamentablemente, la planificación no es una tarea trivial. Uno de los aspectos que dificulta la labor de administradores y jefes de proyecto en torno a la planificación radica en la complejidad de realizar una estimación de costos y plazos realista. El proceso para crear una planificación de desarrollo exacta consta de tres pasos: estimar el tamańo del producto, estimar el esfuerzo necesario para su desarrollo y estimar la duración.

De la integración de estos tres pasos resulta la obtención de un intervalo de estimación que debe refinarse periódicamente, para aumentar la precisión a medida que avanza el proyecto. Para realizar dicha estimación se han desarrollado disímiles modelos. Los modelos matemáticos paramétricos que fueron de los primeros creados, están basados en un conjunto de variables de entrada significativas o parámetros [International Society of Parametric Analysts, 2008].

El funcionamiento de los modelos matemáticos de estimación para proyectos de software se fundamenta en la utilización de ecuaciones matemáticas mediante las cuales se obtiene el valor de un conjunto de variables dependientes de salida (esfuerzo, tiempo de desarrollo, entre otras) en función de los valores numéricos dados a otro conjunto de variables independientes de entrada (tamańo de la aplicación en líneas de código, fiabilidad requerida de la misma o complejidad). La mayor parte de esos modelos suelen operar mediante un proceso de dos pasos, en el primero se realiza una primera aproximación o estimación en función del valor de un conjunto reducido de variables independientes y en el segundo se precisa el resultado mediante la utilización de otro conjunto de variables que permite refinar los cálculos [Marbán, 2003].

Estimar consiste en determinar el valor de una variable desconocida a partir de otras conocidas, o de una pequeńa cantidad de valores conocidos de esa misma variable. Es importante pensar en una predicción como en un rango más que como un simple número. Una estimación o predicción no es un objetivo, sino una valoración probabilística. El valor que se obtiene de una estimación es el centro del rango [Cerrillo, 2000].

La estimación en proyectos de software es una tarea extremadamente compleja, que requiere, entre otras cosas, disponer de información detallada del proyecto o de los proyectos a estimar, realizar una primera planificación del proyecto y conocer los recursos disponibles. Aun disponiendo de todos los medios y de la información necesaria, las estimaciones de los proyectos de software suelen errar, normalmente, pronosticando resultados menores de los que finalmente se producen.

Hay cuatro factores que influyen significativamente en las estimaciones: la complejidad y el tamańo del proyecto, el grado de incertidumbre estructural y la disponibilidad de información histórica [Navarro, 2012]. Una mala planeación y/o ejecución de un proyecto causa pérdidas relacionadas principalmente con los factores tiempo y costo, razones por las cuales éstos deben planearse y ejecutarse tomando en cuenta la premisa de que los proyectos se desarrollan para obtener una mejora significativa en la empresa, cumpliendo con las expectativas de calidad, costo y tiempo. La correcta definición y gestión de proyectos, tomando en cuenta dicha premisa determina su éxito o fracaso.

MATERIALES Y MÉTODOS

Métodos de estimación

Los métodos de estimación de manera general, han sido diseńados para medir un determinado tipo de software. Por tanto, la aplicación de cada método depende particularmente del dominio del software o del tipo de desarrollo. Su evolución ha permitido obtener otros beneficios, tales como el perfeccionamiento del análisis de los riesgos de los proyectos o la posibilidad de realizar análisis cuantitativo sobre la eficacia de las disímiles propuestas de cambio de los procesos de desarrollo de software.

Los modelos de estimación que se han publicado desde los ańos 60 hasta la actualidad, fundamentan el progreso de los métodos de producción de software y el propio software en sí. Varios de ellos han quedado obsoletos, tales como el modelo Aaron (1969), el modelo de Wolverton (1974), el modelo de Walston-Feliz (1977), el modelo Doty (1977), el modelo Putnam (1978) y otros como el modelo SLIM (1979), el modelo COCOMO 81 (1981) y su actualización COCOMO II (1997) han ido evolucionando, siendo la base de las herramientas de estimación existentes en la actualidad [Gómez, 2008].

Jorgensen [Jorgensen, 2007] destaca que casi un tercio de los artículos de investigación escritos sobre estimación de costo en los ańos 90 tratan sobre Puntos de Función, registrándose en este período el pico más alto de interés en esta métrica. Por otra parte, hoy día los usuarios no están completamente satisfechos con los resultados obtenidos con los métodos de estimación; los errores en la estimación de esfuerzo son demasiado grandes, lo que lleva a reflexionar sobre si las métricas actuales son adecuadas a las necesidades de los líderes de proyectos o dueńos de las aplicaciones [Robiolo, 2010].

Paralelamente al desarrollo y evolución de los modelos y métodos de estimación se han propuesto distintas calificaciones para éstos basándose en múltiples criterios en la medida que se ha desarrollado en la ingeniería de software la disciplina de estimación. En 1981 Bohem [Bohem, 1981] pretendió ordenar el conjunto de modelos de estimación existentes hasta ese momento proponiendo una clasificación que atendiera la disparidad de rutas existentes y que cada modelo pudiera ser incluido en alguna de las categorías definidas, logrando tener 7: Modelos algorítmicos, Estimación basada en expertos, Analogía, Parkinson, Price to win, Estimación de arriba abajo y Estimación de abajo a arriba.

En 1998 Capers Jones propone otra clasificación de los métodos de estimación [Jones, 2007] en la que aparecen seis metodologías agrupadas en dos grandes grupos: metodologías manuales, que no tienen herramientas que automaticen el cálculo y los métodos automáticos, que sí las tienen.

Entre 1999 el 2000 se propone otra clasificación, esta vez en seis métodos: modelos estáticos, experiencia de expertos, orientada al aprendizaje, modelos dinámicos, modelos estadísticos y modelos compuestos [Jones, 2007].

En el 2001 se resumen en dos todas las clasificaciones anteriores: Metodologías de estimación basada en Modelos Operacionales (Operational models, OM) y las Metodologías de estimación basada en modelos experimentales (Experimental models, EM). Estas a su vez se derivan en varias subcategorías: modelos matemáticos, modelos basados en técnicas de Inteligencia Artificial, modelos comparativos, modelos dinámicos [Boehm, 2012].

En el 2012, P.K. Suri y Pallavi Ranjan [P.K., 2012] hacen un análisis de los métodos de estimación desde la década del 1970 concluyendo que en los últimos 5 ańos se han introducido diversos métodos que han tenido como objetivo incrementar la precisión de los resultados tras la identificación de algunos problemas teóricos [Kitchenham, 2009]. Para ello la tendencia ha sido combinar diferentes métodos de estimación y utilizar a su vez, técnicas de inteligencia artificial, entre las que se destacan lógica difusa, sistemas basados en conocimiento y redes neuronales.

Generalmente en la actualidad cuando se hace referencia a la estimación de un proyecto se puede hacer referencia a tres grandes áreas: estimación de tiempo, de recursos y de costo. A pesar de tratar de distinguirlas a cada una de ellas de manera individual, su relación es muy estrecha. La estimación de recursos, costo y tiempo es un esfuerzo que requiere experiencia, acceso a buena información histórica (métricas) y valor para comprometerse con predicciones cuantitativas cuando la información cualitativa es todo lo que existe [Pressman, 2010].

Dificultades en el uso de los métodos de estimación

Tanto los métodos o modelos que quedaron obsoletos como los que constituyen las bases de las estimaciones de estos tiempos, tienen asociados un conjunto de inconvenientes que han dado al traste con unos y establecen limitantes para otros.

El modelo SLIM, cuya denominación procede de Software LIfecycle Management (Gestión del ciclo de vida del software) se fundamenta en el análisis de Putnam del ciclo de vida del software. Este modelo de estimación tiene como objetivo encontrar las variables estratégicas del proceso de desarrollo de software y derivar, de su comportamiento, un sistema de ecuaciones para luego introducirlas en una computadora para su estudio y análisis.

A pesar de estar considerado como uno de los más utilizados por las organizaciones, su uso tiene algunos inconvenientes al ser un método propietario. Desde que el modelo fue patentado, las ecuaciones no han sido editadas para el dominio público, aunque los algoritmos de funcionamiento pueden deducirse a partir de las publicaciones que se han realizado del modelo [Marbán, 2003]. Específicamente los métodos de medición de tamańo tienen ciertas reticencias, debido a que muchos de los resultados no son lo necesariamente satisfactorios y adecuados para ciertos tipos de software. Algunos de los problemas más significativos están vinculados con la objetividad y la fiabilidad; la utilización del factor de ajuste; la precisión y la medición en distintas fases de desarrollo.

Para algunos desarrolladores de aplicaciones informáticas considerar que el tamańo de un sistema está relacionado con la funcionalidad es algo natural. En ese sentido, en los inicios de la década de los ańos 80, se extendió el uso del método puntos de función, presentado en 1979 (primera publicación) por Allan Albrecht, quien lo refinó en 1984, para medir la funcionalidad. Este método mide tamańo independiente de la tecnología. En él, una entrada de complejidad media tiene 4 puntos de función y a una consulta media también le corresponden 4 puntos de función. żQué equivalencia existe entre la entrada de datos y las consultas? Albretch estudió 24 proyectos de aplicaciones de negocios con un rango de tamańo desde 3000 a 318.000 líneas de código desarrolladas en DMS, PL/1 y COBOL. Hallando una relación entre entrada y consulta que le permitió decir que la cantidad de líneas de código utilizadas para una entrada de complejidad media es igual a la cantidad de líneas de código de una consulta media. Por otra parte, debe tenerse en cuenta además que esa igualdad de líneas de código se da para los lenguajes analizados y no necesariamente para cualquiera. En la actualidad queda demostrada la invalidez de esta relación para algunos lenguajes, con el uso de herramientas que automatizan las consultas y el acceso a los datos. De esta manera se considera que queda descartado el principio de que el tamańo, es "independiente de la tecnología". Por lo tanto, no sería tamańo según la definición clásica, sino esfuerzo normalizado para una o más tecnologías. Por otra parte, a los efectos de una estimación temprana, constituye otra debilidad de este método, asumir que se conocen los grupos de datos que utilizará el sistema. Asumiendo también que ese conocimiento es lo suficientemente amplio como para calificar esos grupos en complejidades baja, media y alta.

Tras la generalización del uso de metodologías orientadas a objeto, para el análisis, diseńo y desarrollo de sistemas, se extendió el uso de la técnica de los Casos de Uso, desarrollado por Gustav Karner en 1993, que, si bien no es privativa de la orientación a objetos, es claramente preponderante. Su utilización desde su surgimiento demostró que resulta más eficiente utilizar para la estimación, una técnica que tenga coincidencias con la metodología utilizada. Puntos por Casos de Uso clasifica, de manera similar a puntos de función, los casos de uso, en simple, medio y complejo según la cantidad de transacciones. Se define como transacción a un evento que ocurre entre un actor y el sistema a ser modelado. Boehm y otros [Boehm, 2000] consideran que esta clasificación es totalmente inadecuada a los efectos de realizar una estimación. El principal motivo es que un caso de uso no tiene un tamańo determinado, citando el ensayo realizado para Rational Software por John Smith en 1999 [Smith, 1999], quien considera como normal un promedio de 30 escenarios por caso de uso. Un caso de uso de este tipo podría llegar a tener 30 transacciones. Si a cada escenario le correspondiera una transacción, este caso de uso tendría igual factor de peso que uno de 8 transacciones. Es decir, el rango superior, 8 a infinito, da igual valor para 8 transacciones que para infinitas, lo cual es un inconveniente. Por otra parte, la agrupación de los requisitos del sistema en casos de uso puede ser totalmente arbitraria haciendo que el método dé valores muy distintos para la misma solución. En ese sentido un sistema en el que se desglosen las acciones vinculadas a gestionar (entiéndase la gestión definida por el patrón de casos de uso CRUD: insertar, mostrar, modificar y eliminar por sus siglas en inglés Create, Read, Update y Delete) cierta información puede considerarse uno, dos o cuatro casos de uso, teniendo en cuenta la complejidad del mismo, haciendo que la estimación llegue casi hasta cuadruplicarse según el desglose que se haga. Lo que indica que no debe tenerse en cuenta solo la cantidad de transacciones, sino además su complejidad.

Otra de las dificultades que se le imputan consiste en la dependencia que tiene este método de la persona encargada de efectuar la estimación, así como de las que realizan la descripción detallada de los casos de uso. Estas pueden tener más o menos experiencia en esta actividad, más o menos facilidad de expresión y redacción, lo que implica que las descripciones sean más o menos escuetas y en función de ello podría existir un caso de uso con marcada implicación en la arquitectura del software, que, tras clasificarlo, puede resultar menos importante que otro, solo por la cantidad de transacciones existentes. También puede ocurrir que se deba incluir algún caso de uso que en el primer instante no se consideraba como crítico y que después se decida modificar su clasificación o viceversa, es decir, que se decida eliminar tras dicha modificación.

Ha de tenerse en cuenta además, que si se estima con respecto a proyectos pasados, según se va evolucionando, esas estimaciones corren el riesgo de ser cada vez menos confiables mientras no se vayan adecuando paulatinamente los métodos utilizados. Asimismo, al no poder contar en la mayoría de las ocasiones con las condiciones idóneas, la productividad del nuevo grupo de trabajo no puede medirse en su totalidad por un trabajo previo.

Por otra parte, si se revisan las tendencias del desarrollo de software es evidente que su complejidad no disminuirá mientras tenga la posibilidad de progresar. Cada vez surgen nuevos y potentes lenguajes de programación, con aplicaciones que explotan las nuevas potencialidades de dichos lenguajes. La cantidad de líneas de código a desarrollar en el período en que se están estimando el tiempo y el esfuerzo, es una estimación en sí. Su implementación difiere en gran medida a la de hace algunos ańos tras el cambio en algunos de los paradigmas de programación y la utilización de nuevas herramientas (Frameworks, IDE de desarrollo) y las facilidades que brindan para programar.

Pero el lenguaje es solo uno de los elementos en el desarrollo de software. Actualmente pueden existir aplicaciones tan complejas que el documento con las especificaciones de los requisitos puede tener cientos de páginas, teniendo entre los riesgos fundamentales, la volatilidad de dichos requisitos, que pueden variar según cambie el problema, los implicados, la interpretación y comprensión que puedan tener ellos del problema, así como la comunicación existente entre dichas personas y el equipo de desarrollo.

Dada la poca experiencia en el uso de métodos de estimación de las personas encargadas de planificar, así como el tiempo disponible para realizar el análisis previo, en la mayoría de las organizaciones, empresas y equipos de desarrollo de software cubanos, es una generalidad el hecho de que normalmente se estime la duración de un proyecto en un único momento, y no solo esto, sino también empleando un solo método, quedando imposibilitada así la realización de comparaciones en la búsqueda de alguna concordancia razonable para asegurar que las estimaciones realizadas son confiables.

Además, se utiliza el mismo método para estimar proyectos con características totalmente distintas, en los que la presencia y el impacto de los indicadores definidos en cada método pueden tener comportamientos contradictorios y no estar en correspondencia con los resultados esperados. Esto influye también en que la recolección de datos para la confección de los históricos necesarios como base para futuras estimaciones no sea específica de un mismo tipo de proyecto informático.

Los riesgos a los que se exponen los que tienen en la estimación utilizando métodos cimentados exclusivamente en la experiencia, la única fuente de información para planificar, son innumerables. Por una parte pueden resultar útiles a pesar de la ausencia de datos históricos, se pueden aplicar en las fases tempranas del desarrollo brindando información necesaria al jefe de proyecto. Pero dependen de la experticia y requiere el involucramiento de múltiples expertos, exigiendo muchas horas de trabajo. En el caso de que se tenga solo una persona con estas características el riesgo es mayor, pues con ella se va todo el conocimiento adquirido.

No puede decirse de manera general, que la joven industria de software cubana tenga una vasta experiencia en la realización de aplicaciones informáticas para todos y cada uno de los sectores en los que puede incursionar, a pesar del gran número de ellas que existen en algunas áreas de desarrollo. En estas últimas, a pesar de tener un trabajo más extenso en este sentido, no se aplica a cabalidad la teoría defendida por Humphrey para emplear, en el momento de la estimación, la experiencia en la que puede basarse el equipo de desarrollo en la realización de aplicaciones similares.

RESULTADOS Y DISCUSIÓN

Boehm y Humphrey. Sus puntos de vista

Dos de las teorías con más reconocimiento internacional en la estimación de proyectos de desarrollo de software son las definidas por los investigadores Barry Bohem y Watt Humphrey. Cada una de ellas se basa en técnicas diametralmente opuestas, pero muestran elementos mundialmente acertados y aceptados por las empresas desarrolladoras de software, que tienen en la calidad de sus productos y servicios, su meta fundamental.

El modelo original COCOMO se publicó por primera vez en 1981 por Barry Boehm y reflejaba las prácticas en el desarrollo de software de aquel momento. Durante los ańos 80, el modelo se continuó perfeccionando y consolidando, siendo actualmente el modelo de estimación de costos más ampliamente utilizado en el mundo, es el preferido para la estimación del esfuerzo cuando no se tiene información histórica a la cual recurrir. Además, es el más documentado de todos los modelos de estimación de esfuerzo de las actividades de diseńo, codificación, pruebas y mantenimiento. Este método ha tenido varias versiones: COCOMO 81, ADA COCOMO, COCOMO II. Este último que es el más actualizado y al que cada ańo se le agregan mejoras está formado por tres modelos: el modelo de Composición de Aplicación, el modelo de Diseńo Temprano y el modelo Post-Arquitectura, adaptándose al tipo y cantidad de información disponible en cada etapa del ciclo de vida de desarrollo.

Estos modelos utilizan:

- Puntos Función y/o Líneas de Código Fuente para estimar tamańo.
- Un conjunto de 17 atributos, denominados factores de costo, que permiten considerar características del proyecto referentes al personal, plataforma de desarrollo, entre otros, que tienen injerencia en los costos.
- Cinco factores que determinan un exponente, que incorpora al modelo el concepto de deseconomía y economía de escala. Reemplazando los modos Orgánico, Semiacoplado y Empotrado del modelo COCOMO 81.

Por su parte Watts S. Humphrey fundó el Proceso de Software Personal (PSP) ampliando el proceso de mejora a las personas que realizan el trabajo de desarrollo de software, pues PSP se concentra en las prácticas de trabajo de los ingenieros en una forma individual, teniendo como principio servir para producir software de calidad, basados en la utilización constante de prácticas sanas de ingeniería de software. De la misma forma que enseńa a cómo planear y darle un seguimiento al trabajo, utilizando un proceso bien definido y medido, estableciendo metas mesurables, y finalmente utilizando el rastreo constante para alcanzar dichas metas.

Como el objetivo es realizar mejores estimaciones, cada vez más eficientes, precisas y que sirvan para tener un modelo de comparación con datos reales para que al final se generen los mejores resultados finales, PSP comienza a estimar los tamańos de los productos que los ingenieros desarrollan personalmente basándose en el tamańo y en los datos de la productividad de cada ingeniero y con ellos estima el tiempo requerido para hacer el trabajo. Teniendo en cuenta que el tamańo del programa también será expresado en cantidad de Líneas de Código.

Para gestionar el tiempo empleando los principios de PSP, se deben hacer planes realistas, intentar seguir dichos planes, controlar el uso del tiempo y determinar los errores y cómo corregirlos. PSP realiza las estimaciones, tanto del tamańo del programa como de los recursos del mismo, con un método que se creó para estos fines que tiene por nombre PROBE (del inglés PROxy Based Estimating) y que se aplica a todos los objetos que se encuentran en el diseńo conceptual.

En aras de facilitar la recogida de estos datos, PSP provee varias plantillas con un formato específico para ir obteniendo todos y cada uno de los cambios en el sistema. De manera tal que se pueda llegar a entender cómo se aprovecha el tiempo.

Puntos de contacto entre las teorías de Boehm y Humphrey

Tras el estudio y análisis realizado al tratamiento que dan Barry Boehm y Watts Humphrey en sus teorías a la determinación de la duración de un proyecto de software, se puede concluir que sí existen varios puntos de contacto o posibles elementos que los integren. Cada uno de ellos da la posibilidad de establecer un nexo entre las dos teorías, lo que quizás tras su aplicación, puede conllevar a la obtención de mejores resultados en estos procesos de estimación.

Líneas de Código

El primero de los contactos está dado por el vínculo que tienen ambos puntos de vista para estimar tamańo en aplicaciones de software. En los dos casos se evidencia la plena dependencia del tiempo de duración con el tamańo de los proyectos. COCOMO II realiza la estimación de tamańo según el modelo que utilice: para Composición de Aplicaciones usa Puntos Objetos, para Diseńo Temprano y Post-Arquitectura usa Puntos de Función. Las ecuaciones formuladas para determinar el esfuerzo dependen del tamańo, por ende, para determinar el esfuerzo nominal en dichos modelos, los puntos de función no ajustados tienen que ser convertidos a líneas de código fuente, considerando el lenguaje de implementación (ensamblador, lenguajes de alto nivel, lenguajes de cuarta generación, entre otros). Al aplicar la teoría de Humphrey no se puede, a menos que se esté trabajando con una persona experta en la realización de una actividad determinada, hacer una estimación temprana del tiempo de duración, pues se basa en la experiencia acumulada y ésta se obtiene tras la contabilización de las líneas de código. La combinación de ambas teorías podría estar en que un experto en la realización de aplicaciones específicas (multimedia, de gestión, realidad virtual, drivers, entre otros), puede estimar teniendo en cuenta su vasta experiencia, la cantidad de líneas de código que tendría el sistema a implementar sin tener que aplicar ninguna otra técnica para estimar tamańo y tener de esta manera otro valor con el cual comparar el resultado. De la misma forma al analizar el comportamiento del método PROBE planteado por Humphrey, se le pueden introducir el cálculo de la cantidad de líneas de código estimadas tras la aplicación de algún otro método y comparar entonces los resultados.

Por otra parte, en el método COCOMO II se utilizan distintos factores de escala y multiplicadores de esfuerzo al ponderar los valores de las variables vinculadas en aras de lograr que en sus valores estén implícitos la incidencia de todos los factores que puedan tener alguna relación directa e indirecta con el proyecto. Dos de ellos están directamente vinculados a los procesos de calidad de software que de manera tan exhaustiva recoge Humphrey en su propuesta: factor de escala Madurez del Proceso (PMAT) y el multiplicador de esfuerzo Experiencia Personal (PREX).

Afiliación Madurez del Proceso (PMAT)

La determinación del PMAT está basada en el uso del Modelo de Madurez de Capacidad (CMM) del Instituto de Ingeniería del Software (SEI). El período de tiempo para medir la madurez del proceso es el momento en el que el proyecto comienza, hay dos formas de hacerlo. La primera toma el resultado de una evaluación organizada basada en el nivel alcanzado, según se muestra en la Tabla 1 en la que se asocia el valor del nivel de CMM obtenido con su clasificación correspondiente (desde Muy Bajo a Extra Alto) y este a su vez se vincula con el valor de factor de escala para PMAT. La segunda está en correspondencia con las 18 Áreas de Proceso Principales (KPA´s por sus siglas en inglés) en el CMM.

Teniendo en cuenta las 18 Áreas de Proceso Principales (Administración de requerimientos, Planificación del Proyecto de Software, Seguimiento y supervisión del Proyecto de Software, Administración de subcontratos, Aseguramiento de la calidad, Administración de la configuración, Objetivo del Proceso de Organización, Definición del Proceso de Organización, Programa de entrenamiento, Administración Integrada de Software, Ingeniería del Producto, Coordinación entre grupos, Revisión por Pares, Administración Cuantitativa, Administración de la calidad, Prevención de defectos, Administración de las Tecnologías de Cambio y Administración de los Procesos de Cambio) el procedimiento para determinar PMAT es establecer el porcentaje de cumplimiento de cada una de las áreas evaluando el grado de cumplimiento de las metas correspondientes. Para definir el nivel de conformidad se utiliza la escala porcentual propuesta por Likert.

Cuando se aplica el modelo evaluativo pueden ocurrir fundamentalmente dos situaciones que atenten contra las estimaciones y el proceso de desarrollo respectivamente, la primera de ellas es que la(s) persona(s) encargadas de determinar el porcentaje de conformidad para cada una de las KPA's no tengan precisión en la definición de los valores, debido principalmente al desconocimiento del estado de las mismas y la segunda es que se pueden obtener valores de la variable PMAT que demuestren un esfuerzo que se puede disminuir si se aumentan los porcentajes de cumplimiento en las diferentes KPA's.

La integración entre ambas teorías es natural teniendo en cuenta que PSP es el proceso de aplicación de los principios de CMM para ayudar y guiar a los ingenieros a realizar el trabajo con calidad acercando CMM al individuo. PSP cubre parcialmente 12 de las 18 KPA's que define CMM. Como puede apreciarse en la Figura, éstas son las que están orientadas a los procesos a los que puede dársele un enfoque personal. Se propone integrar las prácticas de PSP al trabajo de los miembros del equipo de desarrollo, en aras de lograr que exista precisión y seguridad en los valores ofrecidos de los porcentajes de conformidad para cada una de las KPA's, lo que representaría realmente el estado de madurez de la organización. Logrando aumentar luego los porcentajes de cumplimiento de cada una de las KPA's, tras el mejoramiento notable en el proceso de desarrollo, que pudiera significar una disminución sustancial del esfuerzo necesario para el desarrollo de proyectos y por consiguiente en el tiempo de duración de estos.

Experiencia Personal (PREX)

El multiplicador de esfuerzo PREX es uno de los parámetros de costo del Diseńo Temprano que combina los tres parámetros de costo del modelo Post-Arquitectura (experiencia en la aplicación (AEXP), experiencia en la plataforma (PEXP), y experiencia en las herramientas y lenguajes (LTEX)). Cada uno de estos indicadores recibe influencia directa de la aplicación de los puntos de vista defendidos por Humphrey pues de forma general capturan la experiencia del personal involucrado en el proceso de desarrollo.

PSP se concentra en las prácticas de trabajo de cada especialista de manera individual para desarrollar software de calidad, a través de la utilización de un proceso planeado, medido y bien definido, dándole mucho peso a la experiencia del individuo y el análisis de los datos históricos registrados de proyectos anteriores que sirven de guía y ayuda en el proceso de desarrollo. Se propone integrar las prácticas propuestas por PSP para controlar el trabajo, dominio y experiencia de los ingenieros sobre las herramientas, lenguaje, plataforma y aplicaciones específicas en que este trabaja o ha trabajado, teniendo así una medida de la madurez y las potencialidades que se pudieran aprovechar ante un proyecto con características específicas, pudiéndose distribuir las tareas y responsabilidades de manera eficiente, lo que podría aumentar la productividad y disminuir el esfuerzo en el proceso de desarrollo y a su vez el tiempo de terminación de los proyectos. Además a partir del control que proporciona PSP sobre el trabajo de los individuos, se tienen criterios y datos históricos para realizar estimaciones más fáciles y confiables.

Reutilización de código

La reutilización de código se refiere al comportamiento y a las técnicas que garantizan que una parte o la totalidad de un programa informático existente se puedan emplear en la construcción de otro programa. De esta forma se aprovecha el trabajo anterior, se economiza tiempo y se reduce la redundancia. Tanto COCOMO como PROBE dan tratamiento al código reutilizado y lo tienen en cuenta para estimar el tamańo del software en Líneas de Código (LOC por sus siglas en inglés).

El tratamiento que hace COCOMO del software reutilizado utiliza un modelo de estimación no lineal para calcular las LOC equivalentes al nuevo desarrollo (ESLOC) a través de las fórmulas (1) y (2):

donde:

ASLOC: es la cantidad de LOC que se va a adaptar,

AA (Assesment and Assimilation): es el grado de valoración y asimilación necesario para decidir cuándo un módulo de software reutilizado por completo es apropiado para la aplicación,

SU (Software Understanding): es el porciento de esfuerzo de reutilización debido a la comprensión del software,

UNFM (Programmer Unfamiliarity): es el indicador de la familiaridad del programador con el software y

AAF (Adaptation Adjustment Factor): es el factor de ajuste de la adaptación, cuyo valor se calcula por la fórmula (3) teniendo en cuenta tres parámetros del grado de modificación

donde:

DM: es el porcentaje de diseńo de software que es modificado para adaptarlo a los nuevos objetivos y al entorno,

CM: s el porcentaje de código software adaptado que es modificado para adaptarlo a los nuevos objetivos y al entorno e

IM: es el porcentaje de esfuerzo requerido para integrar el software adaptado dentro de la totalidad del producto y comprobar el producto resultante comparado con la cantidad de esfuerzo normal de integración y pruebas para software de un tamańo similar.

En las fórmulas (1) y (2) los valores obtenidos por PSP tendrían una incidencia directa sobre las variables ASLOC, AA y UNFM.

Según PROBE la categoría de reutilizado se utiliza sólo para partes del código sin modificaciones. Cuando se modifican los programas existentes, el programa sin modificar es la base (tamańo total del programa sin modificar antes el desarrollo), y se estiman las adiciones (tamańo del código ańadido para mejorar el programa base), modificaciones (LOC que se ańaden al código existente como parte de una modificación) y supresiones (tamańo del código que es eliminado del programa base por no ser necesario). Incluso si el programa no se modifica, no se considera reutilizado a menos que se destine específicamente para su reutilización.

En ambas teorías, tras aplicar el método particular de cada una para la reutilización del código, el valor obtenido de estimar la cantidad de LOC reutilizadas es usado directamente para estimar el tamańo total del software y este a su vez es usado en los cálculos necesarios para estimar el tiempo de duración de los proyectos. Se propone utilizar en COCOMO la forma en que PROBE estima el código reutilizado y viceversa.

Como elemento distintivo entre estas dos teorías está el hecho de que ambas tienen su base fundamental en la calibración de las variables que se utilizan para ajustar los valores obtenidos según los distintos factores que inciden en el resultado. Otras vías de integración pueden existir si se redefinen los parámetros a calibrar en función de los intereses de una organización específica, ya que ha de tenerse en cuenta que las medidas obtenidas, fundamentalmente al aplicar COCOMO II son el resultado de haber trabajado con factores inherentes al campo de acción de Boehm.

Validación de la propuesta

Como parte de la validación de la propuesta, se propone realizar, antes de aplicar el experimento, un diagnóstico como ejercicio inicial, con la aplicación de técnicas de recopilación de información. El objetivo es obtener, de los encuestados, la mayor cantidad de información posible sobre el nivel de conocimiento, experticia en el tema y pertinencia de la propuesta. Se propone realizar este diagnóstico base a 30 especialistas, entre los que estarían líderes de proyectos, planificadores, personas con experiencia en temas de gestión de proyectos y calidad de software. Lo que hará que la muestra sea seleccionada con carácter intencional. Este diagnóstico permitirá además identificar si los miembros de la población seleccionada tienen criterios similares.

Se tomará como población los proyectos informáticos de los dos centros de desarrollo de software de Facultad 2 de la Universidad de las Ciencias Informáticas: Telemática (TLM), dedicado al desarrollo de productos y servicios en el área de las telecomunicaciones y la seguridad informática e Informatización de la Seguridad Ciudadana (ISEC), dedicado a desarrollar aplicaciones que apoyen la gestión de información en los diversos órganos que brindan seguridad a los ciudadanos. Se tomará como muestra ocho de estos proyectos de software teniendo en cuenta los que han realizado estimaciones más precisas, teniendo poca desviación con respecto a los resultados reales y los que han tenido que realizar varias estimaciones y a su vez, continuos ajustes en los cronogramas. Esta selección se realizará utilizando la técnica de muestreo no probabilística, muestreo intencional y la muestra seleccionada corresponde a un 40% de la población, por lo que se considera que se logrará la representatividad de los elementos heterogéneos que se analizan, así como la significativa representación de los mismos, pues por las propias consideraciones de la técnica, se seleccionan elementos representativos con alta posibilidad de brindar mayor información [Hernández, 2002].

Aplicación del experimento a la muestra seleccionada

El proceso de aplicación de la propuesta se realizará a través de tres actividades: Preparación del personal, Implantación y Recopilación de Resultados. Como parte de la preparación del personal se iniciará mediante la presentación de la visión de la propuesta a los Directores de los Centros de Desarrollo TLM e ISEC exponiendo las ideas generales y los presuntos resultados esperados. De este encuentro se recogerán y analizarán las opiniones emitidas. Luego se realizará un taller con los líderes, planificadores, gestores de la calidad y de control y configuración de cambios de los proyectos seleccionados, para explicar detalladamente la propuesta. Los criterios expresados también serán sometidos a revisión. Una vez realizados los dos primeros momentos de la preparación del personal se propondrá un cronograma de ejecución para la aplicación de los elementos contenidos en la propuesta como parte de la Implantación. Para la Recopilación de Resultados se propone aplicar a la muestra antes seleccionada un instrumento, cuyas características aparecen detalladas en la Tabla 2 y que tendrá como objetivo obtener información sobre los resultados de la implantación de la propuesta.

Las preguntas de tipo A tienen por objetivo comprobar la factibilidad de aplicación de la propuesta, así como la pertinencia de la misma. Las preguntas de tipo B tienen por objetivo evaluar el nivel en que se encuentra un indicador específico de los que forman parte de la propuesta. Las preguntas de tipo B serán cuantificadas en una escala de valores de uno a cinco, siendo este último el máximo valor posible, que estará en correspondencia con los elementos de cada indicador que lo lleven a ser el indicador con impacto más positivo en la estimación de la duración de proyectos de desarrollo de software. Las preguntas de tipo C tienen por objetivo identificar determinados factores con incidencia directa en los proyectos o algún criterio específico que pueda ser tenido en cuenta como parte del proceso de estimación del proyecto. Esta descripción de las categorías es tomada de referencia de un diagnóstico de este tipo [Pińero, 2007]. Luego se hará un análisis comparativo de la aplicación del último instrumento con el diagnóstico inicial y se valorarán los resultados.

Página web

Para ver la página web: https://crisvibritannia81.wixsite.com/misitio

Imágenes:

CONCLUSION

Las métricas de software proveen mediciones para ver el progreso y la retroalimentación necesaria para el ajuste de planes. Desde el inicio, las métricas de software han sido consideradas como parte de la ingeniería de software.

Desde luego nunca se tendría "ingeniería" sin mediciones como parte importante de los métodos. La visión en el futuro no es la de las métricas de software aisladas. Más bien es una visión de ingeniería de software donde las métricas ayudan a los ingenieros "a medir, ayudar a la administración del cambio y complejidad del software".

Esta es una visión que es una promesa del CASE (ingeniería de software asistida por computadora). La automatización de las métricas entregará los datos al administrador del proyecto donde las métricas actuarán, con anticipación como previsones de situaciones complicadas durante el desarrollo y proveerá de significado mostrando el progreso. Hay varios usos prácticos de las métricas de software. Cuatro de los que considero más importantes:

ˇ Estimación de proyectos y monitoreo del progreso

ˇ Evaluación del trabajo de los productos

ˇ Proceso de mejoramiento a través del análisis de defectos

ˇ Validación experimental de mejores prácticas (prototipos, reducción de acoplamiento, incrementar cohesión, limitar complejidad, técnicas de inspección y pruebas, modelos de fiabilidad).