archivo

Archivo de la etiqueta: Métrica

El término ingeniería del software resulta muy controvertido debido a la existencia de muchos detractores que ven más adecuados otros términos como por ejemplo el término desarrollo de software.

De hecho pese a que creo en el concepto uso con más frecuencia el de desarrollo de software.

La ingeniería del software es una disciplina que tiene como objetivo que el software que se desarrolla seaa de calidad (en todos los sentidos, no solo que verifique los requisitos funcionales) a través de un proceso que sea productivo para el que lo implementa.

Hay muchas definiciones académicas o de autores conocidos de este término. Me gusta mucho la de Bauer (1972) “Ingeniería del software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales”.

Detrás de la ingeniería del software hay procesos, estrategias, tácticas, metodologías, actitudes, prácticas y herramientas que lleven desde la idea inicial de un programa a un producto instalable, que funcione y sea mantenible. La ingeniería del software es la suma de todo eso adaptada con intención al contexto real de un proyecto de desarrollo de software.

Tengas una visión ágil o no, al final aplicas un enfoque, un forma de trabajar, precisamente la ausencia de ese enfoque y la falta de disciplina a la hora de orientar los trabajos hacia el contexto concreto que rodea al desarrollo ha dado lugar a la crisis del software o lo que es lo mismo, productos de baja calidad, costosos y fuera de plazo. Estas características están presentes en gran parte de los sistemas con los que trabajamos, se puede mirar para otro lado, pero la realidad es esta por lo que la crisis del software no es un concepto del pasado sino algo muy presente y desgraciadamente y, si no cambian las cosas, con bastante futuro.

En muchas ocasiones el concepto de mantenimiento adaptativo se utiliza de forma incorrecta confundiéndose muy a menudo con el mantenimiento evolutivo, siendo dos tipos de mantenimiento que persiguen objetivos distintos.

Lo mejor es recordar las definiciones que Métrica V.3, hace de cada uno de estos mantenimientos:

– Mantenimiento evolutivo: “Incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambios en las necesidades del usuario.”

– Mantenimiento adaptativo: “Modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios en la configuración del hardware, software de base, gestores de bases de datos, comunicaciones, etc…”.

Con las definiciones por delante resulta bastante sencillo discernir un tipo de mantenimiento de otro, ya que el primero está centrado en un cambio en las necesidades del usuario o lo que es lo mismo, en una modificación de los requisitos funcionales de la aplicación (por muy pequeños o grandes que sean) y el segundo se basa en los cambios en cualquiera de los elementos que conforman el entorno sobre el que funciona el programa, a los ejemplos que indica Métrica V.3, yo añadiría los servidores de aplicaciones, servidores web e incluso las interfaces con terceros sistemas, es decir, si una aplicación se comunica con otra por servicios web y ésta modifica la interfaz el cambio a realizar en la aplicación es de carácter adaptativo ya que el requisito funcional (que es comunicarse con ese tercer sistema) no ha variado.

NOC es otra de las métricas de Chidamber y Kemerer. Como no podía ser de otra forma, mide la complejidad de una clase desde un punto de vista diferente al del resto de métricas propuestas por estos autores. En este caso su cálculo se basa en contar el número de subclases que directamente heredan de la clase para la cual se calcula esta métrica.

Las subclases están acopladas con la clase de la que heredan, esto quiere decir que cuanto más clases hijas tenga una clase más prudencia hay que tener con cambios relacionados con el comportamiento y especificación de los métodos, ya que podría tener trascendencia sobre sus subclases. Por ese motivo, es necesario ser más exhaustivo en las pruebas de clases con un NOC alto, ya que cualquier problema en las mismas tiene un impacto importante en el programa. Por tanto, se puede deducir de esto que clases con un número de hijos elevado son más complicadas de mantener que otras con un número más bajo.

En el árbol de jerarquía de clases de un determinado programa resulta razonable que las clases situadas en los niveles más alto de la jerarquía tengan un valor de NOC superior a las clases que se encuentren en niveles inferiores, por ese motivo, la existencia de clases con un NOC alto en comparación con otras que se encuentran en niveles superior de la jerarquía, puede ser un indicador de un mal diseño de la clase o una utilización no adecuada de la herencia.

Por otro lado, clases con un NOC alto favorecen su comprensibilidad y la capacidad de implementación de nuevas reutilizaciones, ya que existe un número de clases de ejemplo donde se puede estudiar cómo han aplicado la herencia y como se ha reutilizado la clase.

Dentro del ámbito del desarrollo de software en España, poco ha sido más denostado que las diferentes versiones de Métrica. En la actualidad (y desde hace bastante tiempo) se encuentra en vigor la número 3.

¿Qué es Métrica versión 3? Se autodefine como una metodología de planificación, desarrollo y mantenimiento de sistemas de información y pretende ser el marco de referencia para la realización de dichas actividades en el ámbito de las Administraciones Públicas en España, estando abierto para su utilización en cualquier otro sector público o privado, nacional o extranjero.

¿Qué cosas buenas tiene Métrica? Muchas, ya que se trata de una metodología treméndamente completa y basada en los principios de la ingeniería del software. No inventa nada nuevo (de hecho más bien es un recopilador de buenas prácticas), pero especifica y describe con bastante detalles cuáles deberían ser los procesos, actividades, tareas y entregas de un proyecto software, sugiriendo una ordenación temporal de las mismas. Por tanto puede resultar muy útil como guía, para utilizarla si tenemos algún tipo de duda sobre algún aspecto concreto del desarrollo de software y para entender determinadas técnicas y prácticas relacionadas con las actividades de ingeniería del software. Independientemente de que Métrica guste o no, de que se aplique o no, lo que sí es cierto es que es un material de apoyo al que se puede acudir en cualquier momento y que para mi resulta recomendable, aunque sea un tostón, ser estudiado, aunque simplemente sirva para permitir a los alumnos y/o futuros profesionales de la informática a entender que el desarrollo de software es un proceso de ingeniería y que si se trata como tal, independientemente de los otros infinitos factores que pueden intervenir, existirán más posibilidades de que el proyecto salga adecuadamente.

¿En qué falla Métrica? Pues en considerarse una metodología, ya que vista así, independientemente de que pueda resultar flexible (de hecho Métrica indica que se puede adaptar la misma a la naturaleza del proyecto), resulta de poca aplicabilidad, tal cual, en un gran número de situaciones. Esto es provocado porque una de sus principales virtudes que es su extensión y exhaustividad se convierte en uno de sus principales defectos cuando se le quiere dar una finalidad práctica como metodología. Métrica, desde mi punto de vista, se debió haber vendido más como un marco de referencia, es decir, como una guía que pueda servir de base o de apoyo para definir otras metodologías, que como una metodología en sí misma, de hecho muchas metodologías utilizadas en diferentes organizaciones públicas y privadas se han apoyado en Métrica, adaptándola a sus circunstancias y necesidades particulares, dotándola de esta manera de una finalidad más práctica.

¿Recomendaría el uso de Métrica? No como metodología, sí como posible guía de referencia o de apoyo y como comenté anteriormente como material didáctico. Independientemente de que piense eso, dado que Métrica al final se basa en principios generales de ingeniería del software, todos al final terminamos haciendo uso queriendo o sin querer de parte de la misma y aplicando muchas de sus buenas prácticas. No lo recomiendo como metodología, porque como dije antes no la veo como tal, para mi una metodología además de basarse en principios generales, debe particularizarse para el tipo de organización en el que se va a utilizar, imbrincándose con elementos que vayan más al detalle como pueden ser los libros blancos de desarrollo y siendo lo suficientemente flexible para poder ser aplicable a la mayor parte de los proyectos que se lleven a cabo y al conjunto de contingencias que se producen en su día a día, además de actualizarse ordenadamente en función de los diferentes cambios organizativos, tecnológicos, etc… que pueda haber en la institución.

Ya lo dice MÉTRICA v.3. Para que el Plan de sistemas de información tenga éxito es necesario contar con el apoyo de los niveles más altos de la organización.

Eso dice MÉTRICA v.3 y mi experiencia dice que si durante y después del proyecto no se prevé apoyo por parte de la alta dirección de la organización, ni se planteéis la realización del Plan de Sistemas de Información.

La alta dirección, además de ser entrevistada en el proyecto para obtener sus necesidades, debe proporcionar los medios oportunos para que todas las personas clave de la organización sean entrevistadas y se impliquen en el proyecto y, además, una vez finalizado el proyecto, proporcionar los recursos económicos y humanos necesarios para realizar el plan de acción.