archivo

Archivo de la etiqueta: ANS

Un error muy frecuente es no prever un nivel de servicio en la garantía. Esto es muy problemático principalmente en los enfoques en cascada donde todo se juega a una carta, ya que por mucho testing que se haga, sabemos que habrá incidencias que lleguen a producción, muchas de las cuales no se detectarán hasta que el producto se esté utilizando de manera efectiva, algo que no ocurre necesariamente tras el paso a producción.

Al proveedor hay que entenderle ya que tras cerrarse el objeto de contrato necesita volver a asignar tareas facturables a los componentes del equipo de proyecto. También hay que entender al cliente que querrá que esas incidencias se corrijan en un tiempo razonable, ya que algunas de ellas podrían afectar a las funcionalidades más críticas del sistema.

Lo que suele pasar es que el proveedor se hará cargo de sus responsabilidades contractuales (no sin protestar o sin poner trabas en algún caso) pero los tiempos de respuesta no serán, generalmente, buenos, porque dedicará pocas personas a este trabajo, las cuales a su vez estarán asignadas a otro proyecto o proyectos.

La primera posibilidad que vamos a estudiar implica dejar muy claro a nivel contractual lo siguiente:

– Catálogo de objetivos y requisitos marco, debidamente priorizados por el cliente y con una valoración de esfuerzo realizada por el proveedor. Este catálogo de objetivos y requisitos, debe tener un nivel de detalle adecuado para poder ser evaluado de manera objetiva por el cliente y también para que pueda ser valorado por el proveedor.

Acertar con el nivel de detalle es importante, ya que no se pretende realizar un análisis en profundidad del sistema (de lo contrario estaríamos desarrollando en un híbrido entre la cascada y un enfoque iterativo incremental en la construcción), pero debe ser suficiente para que la valoración sea lo más acertada posible y para que no existan solapamientos entre requisitos o confusiones sobre su alcance real.

Es muy importante hacerle entender al cliente que resulta fundamental acertar con las prioridades, ya que permitirá obtener antes una versión del producto con sus aspectos más críticos ya implementados y tendrá margen de maniobra presupuestaria para poder hacer los ajustes que considere necesarios.

Lo anterior debe ser recordado al cliente durante todo el proceso de desarrollo.

Además se deberá presupuestar los costes de gestión por parte del proveedor al final de cada iteración: replanificación del proyecto en función de los cambios sobre el plan inicial o sobre el plan establecido hasta el momento, realización de un primer análisis y valoración de nuevos requisitos, revaloración de requisitos ya establecidos, etc…

Este catálogo de objetivos y requisitos, debe ser contratado aparte y antes de comenzar el proceso de desarrollo.

– Compromisos por parte del proveedor respecto a su participación en el proyecto: Esto podrá variar en función de la metodología utilizada, en algunos casos será suficiente su participación al principio de cada iteración (detallar los requisitos) y al final de la misma (evaluación de los resultados obtenidos y definición del alcance de la siguiente iteración), en otros casos requerirá que además de lo anterior, tengan participación dentro del propio equipo de desarrollo o tener un nivel de disponibilidad absoluto ante consultas o peticiones realizadas por los desarrolladores.

– Marco para el cambio del catálogo de objetivos y requisitos inicial y para la gestión de conflictos. Para reducir o evitar los conflictos es importante que quede claro y por escrito, cómo tratar las situaciones más comunes que se pueden producir en el proceso de desarrollo:

Cambio de prioridades. No tendría coste imputable al cliente.

Corrección de defectos. No tendría coste imputable al cliente.

Cambio de un requisito por otro nuevo, ampliación del alcance de un requisito ya existente y reajuste de un requisito ya implementado. Se tendría que evaluar el coste del cambio e intercambiarlo por requisitos todavía no implementados que tengan en suma un coste equivalente (sin pasarnos nunca del presupuesto restante para el proyecto).

Reducción del alcance de un requisito y eliminación de un requisito. Se generaría un “crédito” a favor del cliente que podría ser utilizado para los cambios indicados anteriormente.

Costes de gestión. Si los costes de gestión no superan el presupuesto establecido en cada iteración, pasarían a formar parte de ese “crédito” a favor del cliente. Si los superan y existe circunstancias motivadas para ello (cambios de enfoque en el proyecto, etc…) tendrá que compensarse el coste por créditos existentes o por requisitos.

Cumplimiento de plazos y de la calidad del producto. Siempre y cuando no existan circunstancias externas al proveedor, se debe garantizar por parte de éste un acuerdo de nivel de servicio que podría tener clausulas de penalización y también clausulas de excelencia.

En el anterior artículo sobre CMMI vimos el área de proceso de seguimiento y control del proyecto como consecuencia lógica del área de proceso de planificación del proyecto, ya que si se establece un plan es para realizar un seguimiento del mismo y de las variables que define, de manera que se pueda dar respuesta a posibles desviaciones lo antes posible.

Este área de proceso va más allá de ese seguimiento y control, ya que el mismo está orientado al día a día del proyecto, sino que está más dirigido a la definición de una serie de objetivos del proyecto y de la organización (en los que influye los resultados del proyecto), donde el grado de cumplimiento de los mismos se verifica a través del análisis de las métricas definidas para cada uno de ellos (una o más), para las cuales se tiene que definir la forma en que vamos a recopilar los datos y obtener los últimos.

El fin último de este área de proceso es comunicar los resultados obtenidos a través del análisis de los datos, es decir, medir para tomar decisiones que permitan mejorar.

¿Qué objetivos se pueden definir para el proyecto?

Por ejemplo, conseguir un 70% de cobertura en pruebas unitarias, mejorar la satisfacción del usuario en cada iteración del producto, entregar los hitos en fecha, conseguir que el número de vueltas a atrás tras la entrega de hitos sea menor o igual a uno en el 90% de los casos, que el número de incidencias tras el paso a producción de una versión sea inferior a un umbral determinado, cumplir con determinado tiempo de respuesta ante incidencias, mejorar progresivamente el velocity del equipo de trabajo, acertar un determinado porcentaje de las estimaciones de esfuerzo realizadas, etc…

Hay que tener en cuenta que lo mismo el proyecto se desarrolla bajo un ANS, en estos casos debe condicionar los objetivos del proyecto los cuales deberán tener en cuenta las métricas definidas y como mínimo cumplirlas.

¿Qué objetivos se pueden definir para la organización?

Por ejemplo, incrementar el número de proyectos que se presentan en plazo, mejorar la productividad, mejorar los márgenes de beneficio del proyecto, reducir el número de errores en las entregas, conseguir una satisfacción media de los clientes tras el cierre de cada contrato igual o superior a un 7, etc…

A veces no se tiene claro que objetivos plantear (sobre todo si no hay ANS), no importa, lo importante es empezar tal vez con pocos objetivos pero que sean medibles y nos puedan proporcionar información de interés para el proyecto y para la organización. Siempre habrá tiempo, cuando ya se vaya implantando esta cultura, de incrementar los mismos.

Siempre que sea posible los mantenimientos de los sistemas de información tienen que basarse en objetivos, es decir, en una serie de requisitos funcionales y no funcionales que el sistema tiene que verificar (también pueden incluirse incidencias relacionadas con mantenimiento correctivo una vez que se ha sobrepasado el período de garantía).

Existirán casos en los que pueda aplicarse una solución mixta y contratar un porcentaje del mantenimiento en bolsas de horas (la proporción dependerá del contexto del sistema: estabilidad del sistema, número de usuarios, tiempo de respuesta necesario, etc…).

Habrá otras circunstancias, como las que indiqué en el artículo de los mantenimientos basados en bolsas de horas que no permitirán o no aconsejarán un mantenimiento orientado a objetivos.

En este tipo de mantenimientos además de los objetivos es necesario establecer la política de entregas, es decir, si se van a ir tratando grupos de requisitos por paquetes o si por el contrario se va a realizar una única entrega (mi recomendación es que si las características del programa y los requisitos lo permiten, el número de entregas sea el mayor posible (siempre dentro del margen de lo razonable) ya que los usuarios y el proceso o procesos implicados tendrán antes los cambios (y se solucionarán antes determinadas carencias), el proceso de pruebas funcionales y de paso a producción será más sencillo y será más fácil detectar y solucionar posibles problemas en la entrega), habrá que priorizar las mismas, establecer los plazos tanto para la entrega de cada una de ellas, como de los diferentes hitos de revisión asociados, así como el acuerdo de nivel de servicio (siempre que sea posible es necesario que las partes tengan claras las reglas del juego y las consecuencias de incumplir en plazos, calidad, etc…).

Los mantenimientos por objetivos son a precio cerrado (o al menos, deberían serlo) por lo que los clientes nos centraríamos en el cumplimiento del nivel de servicio y no por la posible productividad o falta de la misma del equipo de desarrollo.

La experiencia me ha enseñado que no por tener muchos indicadores se va a tener mejor controlado el acuerdo de nivel de servicio que se pacte con un determinado proveedor, es más, lo más probable es que cuanto más indicadores se posea será más complicado hacer esta tarea y más árboles te impedirán ver adecuadamente el bosque, ya que se corre el riesgo de perder más tiempo mirando alertas que en darte cuenta que algo realmente está fallando y en ponerle el remedio necesario.

A todos nos encanta poner alertas, pero al final nos daremos cuenta que en lugar de simplificar, complican.

Lo importante es definir aquellos indicadores mínimos que permitan controlar el servicio. Lo más probable es que al principio te equivoques e incluyas indicadores que no van a servir para nada o que son muy complicados de medir objetivamente, también es muy probable que hayas olvidado de introducir alguno que permita medir carencias que estás descubriendo en el servicio. Por ese motivo, los indicadores deben ser algo vivo en el servicio y ajustarse a lo que se va necesitando y a la realidad (tampoco sirve de nada poner objetivos inalcanzables porque provocará desazón tanto en un lado como en otro). Es importante señalar que la realidad tiene que venir determinada por lo que resulta razonable, tanto para un lado como para el otro. La realidad también depende del presupuesto que exista.

En cualquier caso no hay que obsesionarse con acertar a la primera ya que por mucha voluntad que se ponga siempre existirá una solución mejor que la que teóricamente has pensado, ya que la realidad es algo bien distinto. Para llegar a un destino hay que dar un primer paso y ese está en la primera propuesta de indicadores, ¿se perderá tiempo por tener que retocar los indicadores y los métodos de cálculo? por supuesto que sí y eso hay que asumirlo, pero mejor así que conservarlos si éstos no cumplen con su propósito. Todo es mejorable, también lo será tu segunda, tu tercera, etc… propuesta de indicadores. Lo importante no es que haya que rectificar, sino entender que se rectifica con el objetivo de seguir mejorando.

Cuando los indicadores pueden cambiar requiere de un acuerdo entre cliente y proveedor (otra cosa bien distinta es que se lleve años trabajando en un tema y se tenga muy claro cuáles son los indicadores, pero eso no lo vamos a tener siempre tan claro, sobre todo conociendo lo variable que es el mundo del desarrollo de software y que no siempre vamos a contar con un mismo presupuesto, en unos casos porque no se pueda y en otros porque no sea necesario), como es lógico el cliente querrá apretar y el proveedor respirar un poco más, pero si se es razonable se terminará llegando a un acuerdo.

Nos centramos mucho en los requisitos funcionales y en cierto modo es lógico que así sea, ya que si una aplicación no cumple el propósito y expectativas que se tiene sobre la misma de nada vale que la calidad del producto y del desarrollo sea impecable.

Parto de la base de que no es nada fácil conseguir lo que el usuario o el cliente busca, entre otras cosas porque es complicado que ambos tengan del todo claro lo que quieren (sí lo pueden tener en la cabeza, pero una aplicación son muchos detalles y es difícil que tengan en cuenta todos) y también que los analistas entiendan e interpreten a la perfección lo que les están contando.

Precisamente porque el desarrollo de un producto tiene asociado inherentemente tareas de mantenimiento correctivo y evolutivo es necesario ir más allá de que el producto funcione, entendiendo que el diseño y codificación realizados deben hacerse pensando en que habrá que modificar la aplicación, para ello desde un primer momento hay que pensar también en la calidad de la aplicación desde el punto de vista de la arquitectura, diseño y construcción.

No tener en cuenta estos detalles provocarán en el sistema desarrollado una deuda técnica que se arrastrará en los mantenimientos y tenderá a empeorar salvo que se decida atajar, ya que el software tiende a deteriorarse con los mantenimientos, siendo este deterioro muy sensible en aquellos casos donde el producto no ha tenido una ejecución buena desde el punto de vista de la calidad del código.

Sonar permite ver de manera muy sencillo lo que esconden las aplicaciones debajo de la alfombra a través de las diferentes métricas que permite obtener. Es cierto que solo son un conjunto de métricas y que hay que saber interpretarlas de manera individual, colectiva y en el contexto de cada aplicación, pero permiten dar una visión objetiva y externa tanto a clientes como a proveedores, ya que no hay trampa ni cartón si ambas partes conocen el juego de métricas y reglas que se le van a pasar al código.

Desde mi punto de vista Sonar es una herramienta de implantación obligatoria en los departamentos de desarrollo y/o de calidad del software, ya que además de permitir detectar aspectos del desarrollo que generan deuda técnica, permiten determinar la complejidad (y por tanto tiempo y esfuerzo) de los mantenimientos y puede ser utilizada para establecer determinados acuerdos de niveles de servicio en cuanto al software que se entrega.

Si los proyectos no varían de proveedor de servicios de desarrollo de software o de responsable del proyecto, la importancia de las métricas y de la documentación pueden pasar a un segundo plano, ya que de una u otra forma el sistema de información seguirá adelante. Es cierto que las métricas y la documentación pueden resultar también de gran utilidad en estos casos, sobre todo si se quiere ver cómo evoluciona la calidad de la herramienta y las incidencias que están teniendo los usuarios en el uso cotidiano de la aplicación.

En cualquier caso el problema está en que generalmente nos solemos acordar de la documentación y de conocer métricas cuando las necesitamos y precisamente por eso, cuando tenemos que echar mano de ellas no las tenemos.

Como es lógico, esa no son las únicas circunstancias que aconsejan que se documenten los proyectos y se obtengan métricas, ya que por encima de eso está la persistencia del conocimiento de la aplicación lo que permite que la adaptación a cambios en la gestión y en los proveedores resulte menos traumática. También permitirá tener un punto de referencia para evaluar la evolución del producto en las nuevas condiciones de explotación o mantenimiento.

Por ejemplo, si se fueran a externalizar en bloque el mantenimiento de una serie de aplicaciones de una organización probablemente lo primero que querrían conocer los posibles proveedores de ese servicio sería información general de las aplicaciones: tecnologías, arquitecturas, fecha de puesta en producción, etc… y métricas: número de incidencias de relacionadas con correctivos, frecuencia de mantenimientos evolutivos, volumen, calidad y formato de la documentación, etc… Si eso se adobara con informes Sonar que indiquen la evolución del análisis estático de código de las mismas, les permitiría todavía más ser más precisos en la estimación del esfuerzo que se requeriría para realizar el servicio en función del número de aplicaciones a mantener, las características del servicio y del acuerdo de nivel de servicio. Además de todo lo anterior, les sería interesante conocer las reglas de desarrollo y de calidad del software de la organización, el ecosistema de desarrollo, las características del entorno de producción, preproducción y desarrollo: sistemas físicos, software de base y servidores de aplicaciones, la estructura organizativa del departamento de informática, el proceso de paso a producción, etc…