Como recordaran en una nota anterior publique un mapa mental acerca de la ingeniería de software y el software libre, resulta que luego de que elabore ese mapa estuve estudiando otros temas que se relacionaban y como resultado se nutrió ese primer mapa y quedo mucho más interesante, quizás este trabajo sea de utilidad para ustedes y puedan enriquecerlo aun mucho más, si lo hacen por favor recuerden compartirlo…

Elaborado por: Yenny Andrade

Leyendo acerca de lo que significa certificar la calidad de software, encontré varias cosas que vale la pena compartir en este espacio.
 
En principio tener claro que la calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de normas reconocidas (ISO 9000, CMMI,...).

Por tanto, un sistema de certificación de calidad permite una valoración independiente que debe demostrar que la organización es capaz de desarrollar productos y servicios de calidad.

Entre los pilares básicos de la certificación de calidad, se encuentran:

• Una metodología adecuada
• Un medio de valoración de la metodología
• La metodología utilizada y el medio de valoración de la metodología deben estar reconocidos ampliamente por la industria.

Dependiendo de la norma que se escoja para optar a la certificación de la misma, la organización deberá demostrar que cumple los requisitos específicos de la misma, las certificaciones no son eternas, serán revisadas con periodicidad para determinar si se mantiene la certificación.

Lo interesante de las certificaciones para las empresas que desarrollan software es que tienen un aval ante sus clientes de que sus procedimientos y métodos están reconocidos por contribuir a que la elaboración de los productos sea de calidad. Cuando una empresa está certificada con alguna norma de calidad, suele ser más costosos sus servicios.

Se clasifican en tres grupos:

1. Operaciones del producto: se refieren a las características operativas, considerando básicamente los siguientes aspectos: Corrección (¿Hace lo que se le pide?),  Fiabilidad (¿Lo hace de forma fiable todo el tiempo?), Eficiencia (¿Qué recursos hardware y software necesito?),  Integridad (¿Puedo controlar su uso?) y  Facilidad de uso (¿Es fácil y cómodo de manejar?).
2. Revisión del producto: capacidad para soportar cambios, considerando básicamente los siguientes aspectos: Facilidad de mantenimiento (¿Puedo localizar los fallos?),  Flexibilidad (¿Puedo añadir nuevas opciones?),  Facilidad de prueba (¿Puedo probar todas las opciones?).
3. Transición del producto: adaptabilidad a nuevos entornos, , considerando básicamente los siguientes aspectos: Portabilidad (¿Podré usarlo en otra máquina?),  Reusabilidad (¿Podré utilizar alguna parte del software en otra aplicación?), Interoperabilidad (¿Podrá comunicarse con otras aplicaciones o sistemas informáticos?)

Fuente: Conferencia de Calidad del Software de Juan Manuel Cueva Lovelle, Departamento de informática de la Universidad de Oviedo,  España.

Según  R. S. Pressman (1992), es la concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente.

A propósito de esto es importante tener en cuenta lo siguiente:

• Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad.
•  Los estándares o metodologías definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se sigue ninguna metodología siempre habrá falta de calidad.
• Existen algunos requisitos implícitos o expectativas que a menudo no se mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que también pueden implicar una falta de calidad.

No he tenido la oportunidad de participar de lleno en esta fase del desarrollo de software (Calidad), lo que me indica la experiencia es que su existencia y buen funcionamiento determinará el éxito de los proyectos y su vigencia en el tiempo.
En la medida que se hagan las verificaciones necesarias, en aspectos diversos como, la forma, técnica, funcionamiento y cumplimiento de requerimientos, es la medida en la que el software responderá efectivamente a su propósito original.

En mi opinión es una unidad crítica de éxito y que no debe ser omitida, ni puesta en un segundo plano bajo ninguna circunstancia.

Con información tomada de la Conferencia de Calidad del Software de Juan Manuel Cueva Lovelle, Departamento de informática de la Universidad de Oviedo,  España.

Quise compartir en este espacio las reflexiones de unas compañeras de mi comunidad de aprendizaje Dahyna Guzmán y nuestra profesora María Esther Remedios.

Se plantea el tema de XP y el software libre, en donde se comienza exponiendo que XP está centrada en 4 valores principales:

1. Comunicación: Los desarrolladores necesitan intercambiar información e ideas sobre el proyecto, a los directivos, y a los clientes de manera confiable. La información debe fluir continua y rápidamente.
2. Sencillez: Siempre que sea posible hay que elegir soluciones simples. Esto no significa estar equivocado o aplicar enfoques simplistas. Beck utiliza a menudo el siguiente aforismo " simple pero no demasiado simple".
3. Retroalimentación: En todos los niveles las personas deberían obtener una retroalimentación muy rápida sobre lo que hacen. Los clientes, los directivos y los desarrolladores tienen que alcanzar una comprensión común de la meta del proyecto, y también acerca del estado actual del proyecto, sobre qué necesitan realmente los clientes en primer lugar primero y sobre sus prioridades, y qué desarrolladores pueden hacerlo y en que tiempo.
4. Valor: Cada persona implicada en el proyecto debería de tener el valor (y el derecho) de expresar su valoración sobre el proyecto. Todos deberían ser abiertos y dejar que todos examinasen e incluso modificasen su trabajo.

Al respecto es importante tomar en cuenta lo siguiente, según la apreciación de la Prof. María E. y la cual comparto:

• La comunicación es un tema muy complejo, por algo existen ciencias, carreras, postgrados y doctorados en comunicación social.
• La sencillez es una percepción que la mayoría de las veces tiene que ver con el dominio que se tiene sobre el tema y la facilidad de presentación.
• La retroalimentación y la valoración son claves en la producción del SL, por lo tanto despertar y mantener el interés es otro de los grandes retos.

Resulta que llevar a cabo estos principios no es solo creer que se hace lo que dice una receta, o un conjunto de principios, es que se debe saber lo que significa e implica cada uno de estos, ser efectivos en la implementación y conocer las dificultades que implica llevarlo a cabo, para lograr la mayor efectividad posible.


La relación entre XP y el software libre, es planteada de esta forma en un trabajo publicado en  Monografias.com - Agilidad y desarrollo de Software Libre, que lo resume de la siguiente forma (ver imagén)

Desarrollar un software de calidad depende de muchas etapas y actividades, donde juega un papel fundamental para el éxito del producto, elegir la metodología que mejor se adapte a las particularidades del proyecto y del equipo que lo llevara a cabo. El rol fundamental de las metodologías es dar un patrón que permita guiar las etapas y actividades necesarias para encaminar de forma correcta cualquier proyecto de este tipo minimizando de alguna manera los factores que pueden llevar al fracaso los proyectos y por consecuencia los productos.

Existen dos grandes enfoques en lo que respecta a las metodologías de desarrollo, el tradicional y el ágil, el primero pensado en una serie de pasos y etapas que generan el uso exhaustivo de documentación durante todo el ciclo del proyecto mientras que el segundo ponen vital importancia en la capacidad de respuesta a los cambios, la confianza en las habilidades del equipo y al mantener una buena relación con el cliente.
Entre las principales metodologías tradicionales se tienen las conocidas RUP (RATIONAL UNIFIED PROCESS), MSF (MICROSOFT SOLUTION FRAMEWORK) entre otras, que centran su atención en llevar una documentación exhaustiva de todo el proyecto y en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto. Una de las características importantes dentro de este enfoque es el alto costo de implementar un cambio y la de no ofrecer una buena solución para proyectos donde el  entorno es volátil.

Ahora bien el enfoque ágil, nace como respuesta a los problemas que presenta el enfoque tradicional, basándose en dos aspectos puntuales, el retrasar las decisiones y la planificación adaptativa; permitiendo potenciar aún  más el desarrollo de software a gran escala.
Como resultado de esta nueva teoría se crea un Manifiesto Ágil  cuyas principales ideas son:

• Los individuos y las interacciones entre ellos son más importantes que las herramientas y los procesos empleados.
• Es más importante crear un producto software que funcione que escribir documentación exhaustiva. 
• La colaboración con el cliente debe prevalecer sobre la negociación de contratos.
• La capacidad de respuesta ante un cambio es más importante que el seguimiento estricto de un plan.

Entre los principales métodos ágiles tenemos el XP (eXtreme Programming), Scrum, Iconix, Cristal Methods, AUP entre otras.

Estas metodologías ponen de relevancia que la capacidad de respuesta a un cambio es más importante que el seguimiento estricto de un plan. Nos lo proponen porque para muchos clientes esta flexibilidad será una ventaja competitiva y porque estar preparados para el cambio significar reducir su costo. Estas metodologías son las que mejor se adaptan a los proyectos de software libre, donde lo dinámico prevalece durante todo el proceso. 

Más allá de lo diverso que puedan llegar a ser todos estos nuevos enfoques metodológicos, lo importante es entenderlos y conocer qué nos pueden aportar a nuestro proyecto, para aplicarlos en esas fases o procesos en los que nuestro equipo o nuestros usuarios estén más cómodos con ello, y no al revés. Las metodologías se deben adaptar a nuestras necesidades y no tratar de que nuestra situación encaje en una metodología establecida, es válido hacer las combinaciones necesarias, de forma congruente, para que sea un apoyo real al proyecto.

Elaborado con información del artículo, METODOLOGÍAS TRADICIONALES  VS. METODOLOGÍAS ÁGILES de Roberth G. Figueroa , Camilo J. Solís y Armando A. Cabrera.

Ya que estas disciplinas están muy vinculadas y que resulta importante estudiar sus relaciones he aquí un mapa mental que elaboré como parte de mi proceso de aprendizaje para mi comunidad académica y muestra de forma gráfica y precisa definiciones y elementos relevantes al respecto. Espero que les sea de utilidad.

Mapa mental elaborado por Yenny Andrade.

La ingeniería de software ha proporcionado al mundo de desarrollo de software, un modelo a seguir para obtener de forma disciplinada productos de software de calidad.
La necesidad de que existiese esta disciplina se presento porque el mundo de desarrollo de software creció rápidamente y los proyectos fracasaban, consumían mucho más tiempo del que se estimaba originalmente, rebasaban los presupuestos, al terminar no resolvían la situación o los requerimientos reales, entre otras cosas; al surgir la ingeniería de software y con ella diversos paradigmas o metodologías que de alguna manera proponen un orden en el proceso, para garantizar de una forma menos empírica el desarrollo y aumentar así las probabilidades de éxito.

Ahora bien en los proyectos de software libre el reto es aún mayor, se requiere de mucha más disciplina, de que todo este mucho más claro y engranado para asegurar el éxito de los proyectos, ya que el equipo de desarrollo trabaja distribuido alrededor del mundo y el trabajo es netamente colaborativo, nadie debe invertir mucho tiempo en comprender como es que funciona la cosa, sino que por el contrario se dedique a producir y colaborar, por lo que se requiere entonces de mecanismos dinámicos fáciles de aplicar y de entender.
Comparto la idea de que uno de los elementos distintivos en SL es la creación, desempeño y evolución de los equipos de trabajo que se conforman alrededor de estas comunidades, así como la forma cómo manejan el liderazgo, la motivación y el reconocimiento. Un fenómeno que va más allá de lo técnico, que como ya hemos conversado antes, tiene que ver con lo social y filosófico.

La ingeniería del software permite crear un orden dentro de un desarrollo de software libre, permite definir una metodología, herramientas y técnicas que se ajusten al proyecto. Va a lograr que se mida la calidad del desarrollo de forma ordenada, logra que las personas que colaboren dentro del proyecto puedan comprender cuál es su rol y como alcanzar el objetivo final.

Para gestionar cualquier proyecto incluso de software libre, entre los factores a tener en cuenta se encuentran:
1.- Cumplir con los plazos de entrega.
2.- Lograr la entrega completa según la definición inicial del proyecto.
3.- El proyecto debe servir para lo que se acordó y tiene la calidad esperada.
4.- Se cumplen las expectativas del proyecto se han cumplido.
5.- El beneficio establecido para el proyecto se ha alcanzado.

Al respecto de este tema en mi comunidad de aprendizaje se formulo un debate intenso, al plantearse una idea que sondeaba nuestra opinión acerca de si el movimiento del software libre (SL) pudiese ser enmarcado en contextos políticos como el capitalismo y el socialismo.

Para comenzar es importante tener claro que el SL es cuestión de libertad y de derechos: el derecho libre al uso, al conocimiento y a la libre distribución. Y por otro lado es cierto que algunos tratan de etiquetar o vincular el movimiento del SL con el socialismo o con el capitalismo, unos dicen que es apolítico y otros que no lo puede ser. En fin les voy a contar mi opinión al respecto, yo creo firmemente que
aunque los fundamentos del movimiento de software libre estén sostenidos en principios de índole social, que visto desde un punto de vista político pudiese tener alguna relación con tendencias socialistas, no me parece correcto enmarcarlo en contextos políticos, más allá de eso estamos hablando de tecnología y conocimiento que hoy día son de alcance global, sin importar los sistemas políticos, representando una ventaja competitiva y tecnológica.


A propósito de este tema, consultando en la web me encontré un artículo del señor Julián Coccia quien dice lo siguiente:

“El amplio crecimiento y adopción global de los principales proyectos de software libre, llevaron a que más allá de los ideales políticos, el software libre represente hoy interesantísimos motivos tecnológicos, estratégicos, y económicos que impulsan su evolución. Participar en la comunidad del software libre, ya no solo se trata de una acción altruista, sino que además representa grandes beneficios económicos, únicas oportunidades estratégicas, y amplias ventajas tecnológicas”

http://blog.julian.coccia.com/2008/07/no-la-dependencia-poltica-del-software.html