archivo

Archivo de la etiqueta: Procedimiento

Como concepto no, pero en la realidad tienen impacto en el sentido de que unas buenas normas pueden facilitar el proceso de desarrollo pero unas malas normas se pueden convertir en un obstáculo.

¿Cuáles son buenas?, ¿cuáles son malas? Depende de lo que realmente necesite la organización y de los beneficios reales que ofrezcan. Muchas veces se establecen normas y pese a que puedan tener ajustes puntuales para mejorarlas (o empeorarlas), en escasas ocasiones se hace un análisis objetivo de las ventajas que han proporcionado a la organización y a los proyectos, en su lugar se deja que siga siendo la marea la que continúe arrastrando el barco y se termina convirtiendo en una costumbre que lo mismo cuesta excesivo dinero, no solo por el coste de aplicación sino por los resultados que ofrece.

Cuando se establecen unas normas o unos procedimientos es importante tener en cuenta el contexto en el que se va a trabajar. No puedes exigir determinados procesos y/o entregables si tu economía no te lo permite o si la tipología de proyectos, clientes o proveedores requieren otro tipo de soluciones.

Por otro lado, resulta esencial contar con las personas que se van a encargar de seguir esas normas y procedimientos en el día a día porque son ellas las que están en las trincheras y si bien la organización puede necesitar determinado tipo de información o actuaciones para realizar tareas de gestión y de toma de decisiones, es importante contar con quienes conocen el contexto en que se llevan a cabo los proyectos porque ellos son los menos interesados en tirar ladrillos a su propio tejado.

Y siempre debe existir la posibilidad flexibilizar las normas o existir excepciones cuando el proyecto o la circunstancia lo aconseje, siempre y cuando esté debidamente justificado. Cuanto más excepciones se requieran sobre la norma, es lógico pensar que algo está fallando en la misma. Sin embargo, quienes velan por su cumplimiento tienden a pensar que el problema está en las personas.

Hay quiénes consideran que la gestión de la configuración es el área de proceso más compleja de conseguir en el nivel 2 de CMMI. Desde mi punto de vista no lo es (o al menos no está por encima de la complejidad de otras áreas de proceso), si bien, requiere de la existencia de un procedimiento, de las herramientas adecuadas y de disciplina, sobre todo, disciplina.

La existencia de este área de proceso es lógica, sobre todo si tenemos en cuenta que en este mismo nivel existe una gestión de requisitos en la que existe como objetivo además de su inventario y comprensión, una cierta trazabilidad de los mismos (digo cierta porque es necesario ajustarlo a las posibilidades del proyecto).

La gestión de la configuración consiste en definir y llevar a la práctica para cada uno de los artefactos de un proyecto de desarrollo de software una política que permita controlar sus versiones. Para un proyecto tiene importancia, la cual crece directamente proporcional con el tamaño del proyecto, pero todavía cobra más interés cuando nos encontramos dentro del ámbito de una organización que desarrolla diferentes productos software o para la que terceros realizan esta tarea.

Sin gestión de la configuración perderemos gran parte de control sobre el producto software que se desarrolla lo que te incrementa el riesgo de cautividad respecto al proveedor (o al equipo de desarrollo) que son los que disponen del conocimiento (y hasta cierto punto) del estado de los distintos artefactos generados en el proyecto, tanto software como documentales.

Por tanto, en este área de proceso es necesario identificar los elementos sobre los que se va a aplicar gestión de la configuración. Lo normal es que se aplique sobre cualquier entregable del proyecto, lo cual me hace insistir una vez más en la necesidad de seleccionar de manera adecuada los mismos antes de comenzar (ni más, ni menos, lo justo para las necesidades del proyecto y los recursos disponibles para su ejecución).

Una vez identificados hay que definir la política de versionado y seleccionar las herramientas que se van a utilizar como base para la gestión de la configuración (así como la organización que van a tener los artefactos en las mismas). Dentro de esa política se encuentra la definición de líneas base o lo que es lo mismo definir los momentos en que una versión de un artefacto se consolida (existirá previamente una recepción formal del mismo) y que tras su validación y aprobación, supone un punto de referencia para el desarrollo de una nueva versión del producto, la cual requerirá un nuevo capítulo de validación y aprobación formal.

Los requisitos funcionales y no funcionales de un sistema de información determinan el mapa inicial de lo que los usuarios esperan del sistema. Se trata de una predicción sobre lo que que quieren y que después tendrán que constrastar con el producto final.

Lo normal es que exista una diferencia entre una versión de un producto y lo que se esperaba de ella, por lo que después son necesarios mecanismos de ajustes que disminuyan esa distancia a unos umbrales razonables o que la eliminen. Lo ideal es que esa diferencia sea la menor posible y los analistas funcionales y orgánicos y los responsables de codificar el proyecto intenten que así sea, sin embargo los proyectos de desarrollo de software están sometidos a muchos factores que afectan negativamente a ese objetivo.

En cualquier caso, los requisitos representan necesidades y expectativas de los usuarios y es necesario, por tanto, conocerlos y tenerlos en cuenta como referencia en el desarrollo del producto software.

Por tanto, este área de proceso requiere que los requisitos estén perfectamente identificados y, además, sean conocidos y entendidos por todos los implicados en el proyecto (equipo de proyecto, usuarios, responsable técnicos del cliente, etc…).

Otro de los requerimientos de este área es que se tenga control sobre el cambio en los requisitos, para ello es necesario que solo un grupo reducido de personas tengan la capacidad de decidir en ese sentido.

Esto no quiere decir que cualquier usuario no pueda proponer cambios, antes al contrario, cualquier aportación debe ser acogida de forma positiva, el matiz en este caso, es que esas propuestas deben ser analizadas por unos pocos (que se entienden que son designados como expertos del proceso o procesos que se informatizan) y que con el asesoramiento de los técnicos software (sería lo más recomendable) toman la decisión sobre qué cambios realizar, cuáles no y en definitiva, cuáles son las prioridades.

Ante una decisión de cambio en los requisitos, este área de proceso tiene el requerimiento de que el resto de artefactos/entregables del proyecto se mantengan consistentes.

Por este motivo hay que tener mucho cuidado a la hora de definir los entregables documentales de un proyecto, ya que cuántos más y más complejos sean, mayor será el esfuerzo necesario para ponerlos consistentes. Es importante apoyarse en herramientas CASE para facilitar la consecución de este objetivo.

Otro requerimiento es la trazabilidad bidireccional y sobre esto habría mucho que hablar. Si se toma al pie de la letra quiere decir que debería poder conocer todos los componentes de ingeniería del software y del producto software (a nivel de clase) asociados a un requisito y también en el sentido contrario, es decir, que partir de una clase se sepa a qué requisito o requisitos puede afectar un cambio en la misma. El objetivo de esto es poder realizar un análisis de impacto y servir también de soporte para la detección de inconsistencias entre los requisitos y los productos derivados del proyecto (incluido el propio sistema de información).

Sin embargo, esta trazabilidad bidireccional resulta costosa de conseguir y no resultaría aconsejable su aplicación en determinados tipos de proyectos (se estaría matando moscas a cañonazos) y en otros, llegar a nivel de clase en el código no aportaría mucho ya que la organización en capas, de las clases, etc… viene condicionada por el generador de código utilizado y el framework.

Para poder respectar en lo posible este objetivo, es importante definir un nivel de entregables documentales acordes a la naturaleza del proyecto (maś entregables, más complejidad, así que hay que tener cuidado con esto) y tener un conocimiento del framework de desarrollo y de la arquitectura de la aplicación, de manera que se sepa de manera rápida donde hay que mirar para conocer el impacto de la modificación de determinados requisitos (lo que se hace es mirar de más arriba la codificación de la aplicación y no entrar a un detalle a nivel de clase). También resulta fundamental un código lo más claro y limpio posible.

Sobre la trazabilidad lo importante, entiendo que debe ser quedarse con el espíritu de la misma y tener unos procedimientos en el proyecto que permitan hacer un análisis de impacto y análisis de consistencia en un tiempo razonable. Hay que recordar que CMMI establece un modelo de referencia, determina el qué pero no el cómo.

Mark A. Ardis es un profesor universitario americano especializado en el área de la ingeniería del software. Cuenta con una importante experiencia académica en diferentes instituciones universitarias americanas, además de haber trabajado en el pasado como contratista de determinados departamentos del gobierno americano y formar parte del área de investigación en Bell Laboratories.

Una cita de este autor, constituye el “One Page Principle” y viene a decir que: “Una {especificación, diseño, procedimiento, plan de pruebas} que no se ajuste a una página de de 8.5 por 11 pulgadas no puede ser comprendida”.

Para conseguir ese objetivo es necesario descomponer en unidades más simples cada uno de esos entregables y centrarse en describirlos de una manera clara y concisa.

Hace unos días un compañero me enseño un portal web que había sacado una organización y que desde el tiempo en que empezaron a realizar el desarrollo hasta que lo pusieron en producción tardaron menos de 72 horas.

Cierto es que el sitio web era muy sencillo (aunque profesional), pero no se trata de que sea más complejo o no, sino de si una organización es lo suficientemente ágil para hacer algo así si la circunstancia lo demanda, es decir, si los procedimientos (y la capacidad del personal) ofrecen esta posibilidad.

Es importante tener procedimientos y una cultura de organización, siempre los he defendido, pero habría que plantearse la calidad de los mismos si realmente en caso de que haga falta, no son lo suficientemente ágiles para permitir desarrollos e implantaciones en tan corto espacio de tiempo (no necesariamente menos de 72 horas, pero sí en un tiempo reducido).

A la mayoría de nosotros nos ha supuesto un fastidio todo el proceso metodológico de desarrollo de software en el que hay que generar y a ser posible, ser validados, diferentes entregables documentales y que suponen un obstáculo de lo que realmente nos gusta que no es otra cosa que ponernos a programar.

Sin embargo, cuando estamos en esa fase de análisis o diseño y tenemos que integrarnos con terceros productos o aplicaciones resulta que necesitamos información de las mismas: su modelo de datos, una explicación del mismo, sus interfaces de comunicación, etc… y que resulta muy complicado que alguien nos la facilite. En esos momentos nos preguntamos, ¿cómo que no está documentado esto? y se realizan quejas al cliente ya que se requiere un mayor esfuerzo en el proyecto para poder investigar esos terceros sistemas con los que hay que interoperar.

Por tanto, nos quejamos de que haya que documentar e intentamos eludir esa tarea como sea y sin embargo también nos quejamos cuando necesitamos información de otro sistema y comprobamos que no hay nada o que lo que hay es de escasa calidad y además está desactualizado.

Como tantas veces he defendido en este blog, es absolutamente necesario que el proceso de desarrollo de software esté procedimentado y que dentro del mismo el proceso de documentación y revisión de la misma tenga la importancia que se merece y que por supuesto, salvo excepciones, no se escriba ninguna línea de código hasta que análisis y diseño estén finalizados y aprobados.

Debería ser algo habitual, aunque no lo es, que existiera en cada empresa de desarrollo de software unos procedimientos internos de control de calidad de todo el proceso (puede que en muchos casos existan, otra cosa bien distinta es que se apliquen) y por otro que el cliente tuviera otros controles más específicos y orientados tanto a las características de su negocio, como de su arquitectura y tecnología.

De esta manera se podría responder a la pregunta, ¿cuánto es suficiente? indicando que tanto como determine la unión de los procesos de control de calidad internos y del cliente que te ha encargado el proyecto.

Por tanto, resultaría de interés para las empresas proveedoras de desarrollo de software conocer las características en cuanto a los procesos de calidad del proceso de desarrollo de los posibles clientes con los que estuviera interesado en colaborar ya que permitirá tener en cuenta el coste adicional que tienen dichos procedimientos en el desarrollo y además los tendría en cuenta a la hora de realizar la posible oferta.

El problema nos lo encontramos cuando el proveedor, el cliente o ambos no tienen procedimientos de control de la calidad en el proceso de desarrollo. Analicemos algunas de las posibles consecuencias de estas carencias:

– Carencias en el proveedor y no en el cliente: Salvo que se lleve trabajando mucho tiempo con clientes con procedimientos de calidad establecidos, la ausencia de procesos de calidad internos en el proveedor provocará que no se dé la importancia que se merece a los procedimientos impuestos en el cliente ya que no existe costumbre en los procedimientos de trabajo de los equipos de proyecto en seguir una serie de pautas que les obliguen a hacer las tareas de una determinada manera.

Si los procesos del cliente son rígidos provocarán, en la mayor parte de los casos, devolución de entregables y la repetición de determinadas tareas por parte del proveedor que podrían haberse evitado con la existencia de una mayor conciencia en el trabajo orientado a procesos. Existen clientes que ya sea a través de acuerdos de nivel de servicio o a través de determinadas cláusulas contractuales penalizan estas vueltas a atrás, ya que les supone un esfuerzo en la realización de estas tareas que es responsabilidad del proveedor y por tanto repercutirá negativamente sobre su facturación.

Si los procesos del cliente son más suaves, el proveedor no acostumbrado a estos procesos se sentirá más cómodo, pero igualmente existirán siempre unos mínimos que deberá cumplir cuyo incumplimiento darán lugar a situaciones como las descritas en el párrafo anterior.

En ambos casos, el listón sobre la calidad del proceso de desarrollo lo coloca el cliente y en términos contractuales debería ser suficiente, no obstante, soy de la opinión de que toda empresa que se dedica a prestar este tipo de servicios debe tener (cumplirlos y ser verificados) unos procedimientos internos que rijan el proceso de desarrollo y que sean comunes, salvo circunstancias especiales, para los diferentes proyectos que se ejecuten, ya que eso permitirá dar a la calidad de los desarrollos unos mínimos comunes a todos los proyectos que podrían servir como seña de identidad.

– Carencias en el cliente y no en el proveedor: En este caso el cliente estará a expensas del nivel de calidad interno del proveedor en el proceso de desarrollo, lo cual conllevaría a un escenario de calidad no uniforme en los proyectos, ya que normalmente cada proveedor tendrá unos procesos diferentes.

Si se quiere dar uniformidad a los desarrollos que se realizan para una organización es necesario la existencia de unas normas de calidad, de lo contrario se llega a una situación de descontrol donde la realización de mantenimientos se hace más costosa, donde existe una mayor cautividad respecto a los proveedores y donde la variedad de frameworks, tecnologías y componentes pintan un paisaje tremendamente complicado de gestionar a todos los niveles (afectando no solo a los departamentos de desarrollo, sino a los de sistemas, explotación, etc…).

– Carencias en el cliente y el proveedor: El escenario es similar al anterior, con el agravante de que ni siquiera el proveedor tiene unos procesos para controlar la calidad de su proceso de desarrollo, lo que dará lugar, por regla general a resultados por debajo de las expectativas y a que no se pueda tener una completa confiabilidad en los trabajos del proveedor ya que la responsabilidad de la calidad de las entregas repercute sobre el interés que tenga el equipo de proyecto en la realización de determinadas actividades en ese sentido, lo que implica que en unos proyectos el resultado puede ser mejor y en otros peor.