El documento discute cómo las organizaciones pueden garantizar la calidad del software que producen. Señala que no son las normas y estándares en sí mismos los que brindan calidad, sino factores como tener un equipo comprometido que comparte objetivos y se siente apoyado. Sugiere que las organizaciones deben crear un ambiente propicio, definir procesos claros y contar con recursos para el aprendizaje, en lugar de depender de una única norma.

1. Desarrollo
¿Qué aplicar?
¿Cómo...? Planificar, diseñar,
desarrollar, implementar, dar
mantenimiento y que sea
funcional a través del tiempo.
Por: Byron Quisquinay

2. Dentro de las tareas que son propias de las áreas encargadas del
Mantenimiento, administración y desarrollo de Software, existe
una que resulta tenebrosa y es la de decidir qué estándares,
normas, reglas, estatutos o políticas de desarrollo aplicar; todo
ello con el único fin de garantizar “calidad” en el producto final.
Bien, al escribir el presente definir el problema parece sumamente sencillo. Pero cuando se vive la realidad que encierra el
reto de cumplir con los requisitos de una solicitud, es donde
empieza la dura agonía.
Y es que en el medio existe un sinfín de Buenas prácticas, normas, estándares, procedimientos, etc. Por ejemplo: ITIL, UML,
RUP, podría aplicarse ISO 9001:2000 (cláusula 7 en especifico) y
bueno muchas más.
¿Pero el empleo de cuál de ellas permitirá alcanzar la calidad
deseada del Software que producimos?
Me atrevo a decir que ninguna de ellas. Según me parece y dada
mi fascinación por las normas y estándares, además del tiempo
de vuelo que llevo en las áreas de Desarrollo de Software y de IT,
no son las normas, estándares, reglas, estatutos, políticas, restricciones, o cualquier artilugio los que brinden calidad al producto final.
No son las leyes, reglas o normas las que fomentan el respeto al
derecho ajeno. Por lo menos no cualquier ley, puesto que existen algunas que fomentan aquello que desean erradicar. ¿Basta
pues con un edicto (ley) para que deje de llover o que el árbol de
Olmo de Peras?
Bien, abordemos pues el tema con mayor detenimiento más que
con sarcasmo. Y es que los problemas vienen dados por una
sencilla razón: el equipo de trabajo no está convencido, no es
parte del reto y no cree o tiene certeza de los resultados de
aplicar tal o cual técnica. Y esto, cuando el equipo actual que se
desenvuelve en el área ha sido el que de forma continua a vivido
la transición o adoptó las reglas que rigen el proceso de Creación
de Software. ¿Qué otros elementos pueden estar involucrados
en la falta de éxito en alcanzar la calidad deseada en el Software
producido? Me parece que podríamos pues crear un listado de
factores, incluyendo el mencionado anteriormente, estos factores serían:
Falta de empatía.
Falta de motivación.
Falta de capacitación.
La inexistencia de un plan que tenga como
objetivo el mantener vivo el compromiso de
la calidad en el producto a producir.
Es pues menester de aquellos en quienes reside la responsabilidad de definir las reglas del juego contar con la mayor cantidad
de variables que circundan este tema. Y según me parece, los
elementos que se deben de tener en consideración son:
Que exista un equipo y no un grupo de trabajo.
Que compartan los objetivos, la visión y la
misión del área y de la empresa o corporación.
Que sientan como propias, eficientes y funcionales, las herramientas, reglas, estatus o
políticas internas para que no menoscaben el
ambiente laboral.
Que esas buenas prácticas, normas, sean
relativamente sencillas de aplicar o que los
instructivos o documentos que las referencian, sean claros y concisos sobre la aplicación
de las mismas.
Que existan medios y recursos que permitan
el auto— aprendizaje de estos métodos,
normas o procedimientos
Bien, en realidad el tema está siendo abordado de la forma más
objetiva que se puede y la prueba de ello será que estos temas
son importantes puesto que:
Un equipo de trabajo aunará esfuerzos para
que el resultado sea un resultado general y
claro está, particular. El beneficio y la satisfacción deberán ser globales e individuales.
Que compartan los objetivos, la visión y la
misión del área y de la empresa o corporación.
Que sientan como propias, eficientes y funcionales, las herramientas, reglas, estatus o
políticas internas para que no menoscaben el
ambiente laboral.
Que esas buenas prácticas, normas, sean
relativamente sencillas de aplicar o que los
instructivos o documentos que las referencian, sean claros y concisos sobre la aplicación
de las mismas.
Ahora bien, queda una duda en el ambiente que tratamos, pues:
¿Así de utópica es la solución? ¿Simplemente hacemos el paraíso

3. informático y eso basta? Quien administra una unidad de la
empresa, que desarrolla software, sabe perfectamente que la
administración del Recurso Humano, es uno de los temas más
difíciles.
Clima laboral.
Plan de compensación y sanción.
Definiciones de Visión y Misión del área y
sus dependencias.
¿Puede pues cambiarse la actitud y el comportamiento, así
como implantar el compromiso, la dedicación y la pro actividad
en las personas?
Instrucciones de trabajo o manual de
(según) puestos.
Mapa de Flujos según sea la actividad emprendida por el área de IT.
¿Esta el resto de la empresa dispuesto a aceptar el reto de
tener una unidad eficiente, sabiendo que esto tiene un costo
alto o mediano, dependiendo de que tan buenas sean las
estrategias emprendidas?
Y lo más complicado: ¿Cada integrante del área de Desarrollo
de Software, comprende, comparte y aplica las estrategias
definidas?
Esto nos lleva pues a una pregunta más global en sí del problema: ¿La solución es definida de una forma unilateral, bilateral
o multilateral? Para mí, la solución, la estrategia, es definida
unilateralmente por quien dirige y en quien recae esa tarea
dentro de la organización, y esto alineado a las políticas de la
empresa y con vistas a los objetivos de las mismas; más sin
embargo, son propuestas que deben ser consensuadas definitivamente a aquellos que impactan directamente, pero así
mismo, deben ser consensuadas a quienes impactan indirectamente.
¿Qué se gana con esto? Pues el definir ¿Qué hacer, con
qué recursos y porqué (recompensa o sanción)?
Ahora, se tiene que tener en mente que dependiendo del
plan estratégico que se aplique se podrá:
Fomentar el ambiente y las actuaciones de los integrantes que sean parte de la maquinaria que provea
un producto o servicio de calidad.
O bien, podrán ser las causantes del detrimento y la
ausencia de calidad en el producto o servicio final
entregado por el área. <Falta de compromiso y responsabilidad, etc.>
Entonces:
¿Cómo planifico, diseño, desarrollo, implemento y le doy
mantenimiento al software que entrego a la empresa?
Con lo anterior me refiero a que el establecimiento de instrucciones de trabajo, políticas de administración y desarrollo de
software, flujos de actividades que permiten el realizar las
actividades que se ejecutan para la puesta final en Producción
de la solución. Afectan no solo al Recurso Humano de Desarrollo de Software, también afectan al usuario que tendrá que
acatar las directrices que deriven de estas definiciones y así
pues a las otras áreas que coadyuvan a la tarea de IT en total.
Cabe pues ahora preguntar de qué se trata el presente artículo, puesto que dentro del título se describe: ¿Cómo...? Planificar, diseñar, desarrollar, implementar, dar mantenimiento y
que sea funcional a través del tiempo.
Entonces, en lo personal, la solución tiene estos componentes
que hay que crear, fomentar y mantener:
Infraestructura (mobiliario y equipo).
Teniendo los elementos que fomenten un ambiente propicio para dicho fin, se deberá tener una definición, clara y
concisa de las tareas de las áreas (o procesos) encargadas
(os) de realizar el: Desarrollo y Mantenimiento (o explotación) de los Sistemas de la empresa.
¿Si pero aún no se responde qué utilizar? Bien, se debe
de contar con:
Una fuente constante y actualizable de dichas definiciones, para que puedan ser consultadas y/o actualizadas,
en su defecto, eliminadas.
¿Qué definiciones? Las de cómo y en qué medio y forma se
dejarán plasmados los: Planes, diseños, pruebas y comunicados que permitieron el desarrollo e implementación de la

4. solución. Y esto pues es la prueba tácita del cumplimiento de la
definición del proceso que permite la creación del Software.
¿Y esa definición de qué, cómo, quién, cuando, etc. Empleando
qué técnica, buena práctica o norma? Pues si la empresa, corporación o estructura organizacional a la que se pertenece no tiene
definida una como estrategia del negocio y por ende el área de IT
debe de alinearse a ella, por ejemplo ISO 9001:xxxx, se deberá
optar por la qué más se adapte a las características que rigen el
área de Desarrollo y para ello habrá que sopesar:
¿Con qué recursos se cuentan?
¿Qué método de estilo de programación se emplea más?
¿Estructurada y Modular? ¿Orientada a objetos?
¿Cuál de esas técnicas, mejores prácticas, estándares, normas,
etc. Pueden ser cumplidas, definidas o articuladas de una
forma más natural o por medio del uso del sentido común?
¿Puede hacerse una mezcla de las que más se adapten según
los estilos me más rijan el desarrollo que se emplea en IT?
¿Bien, entonces al final se contestó la pregunta? Si, primero se
deberá tener el ambiente propicio y luego se definirán las técnicas
más aptas para la actividad de la Construcción y Mantenimiento
de Software.
¿Eso no es una respuesta o sí? En realidad sí, puesto que no hay
dos unidades, departamentos, sección o cualquier artilugio para
Desarrollo de Software que sean idénticos y que cuenten con
tecnologías y estilos iguales, por lo que no creo que se pueda
definir una receta igual para cada ámbito.
Hay unas preguntas que yo dejaría además de las que iniciaron el
presente artículo: ¿Si es usted el administrador o si es usted la
parte operativa del área, está dispuesto a entregar calidad en lo
que hace diariamente, fomenta usted el trabajo en equipo y está
dispuesto a dejar una honda huella en su empresa, departamento,
compañeros y en este medio, como un estratega, como un empleado de excelencia?