Garantía y mantenimiento de proyectos software

Al entregar un proyecto de software aunque tengamos muy presente las enseñanzas de Philip Crosby siempre existirán fallos, incidencias e incluso defectos que deberán ser tratados. Proyectos comerciales de desarrollo de software suelen llevar de 3 a 6 meses de garantía después de la entrega del proyecto. El cliente debe instalar el software y validarlo lo antes posible y siempre dentro de este periodo de tiempo. Aunque pueden existir periodos de garantía más amplios, son acuerdos comerciales puntuales entre cliente y proveedor.

Durante el periodo de garantía las incidencias encontradas deben ser reportadas formalmente y arregladas por parte del proveedor sin cargo alguno - mantenimiento correctivo del producto en garantía. Cualquier cambio - Change Request - introducido durante la garantía y aprobado por CCB debe ser facturado ya que se encuentra fuera del alcance inicial de los trabajos.

Al finalizar la garantía, a fin de mantener el proyecto vivo, es responsabilidad del proveedor de sugerir la formalización de un acuerdo de mantenimiento. Estos acuerdos suelen ser anuales, dónde para mantenimiento correctivo se establece una bolsa de horas mensual, que si no se llega a utilizar puede ser acumulada y usada durante la validez del contrato (un año). Al renovar el acuerdo las horas no consumidas se restablecen a favor del proveedor ya que éste reserva horas de recursos para ello. Para mantenimiento perfectivo igual que adaptivo - Change Requests - no se reserva una bolsa de horas dentro del acuerdo, sólo se define el precio hora.

lunes 6 de agosto de 2007

Técnicas de compresión de planes de proyecto (Crashing, Fastracking, etc.)

Para reducir la duración de un proyecto podemos usar diferentes técnicas como por ejemplo crashing y fast tracking. Actuaremos con éstas técnicas siempre sobre el plan de proyecto que hemos preparado, teniendo en cuenta que la duración de camino crítico es la duración del proyecto y que puede existir más de un camino crítico.

Crashing - Esta técnica permite reducir la duración del proyecto cuando hay exceso de trabajo y la duración debe ser reducida sea dedicando horas adicionales o involucrando nuevos recursos. Esta técnica aunque puede reducir la duración del proyecto pero implica aumento de costes. Tiene sus ventajas y desventajas.

• Soft crashing - Este tipo de crashing se hace dedicando horas extra. Es efectivo pero no es sostenible. Se puede utilizar durante periodos cortos de tiempo a fin de evitar quemar al equipo.
  
• Hard crashing - Consiste en involucrar a nuevos recursos al proyecto. Es una opción cara y si se introduce tarde en el proyecto inefectiva ya que existen las desventajas de que el equipo que se acaba de unir debe aprender lo que sabe el equipo actual y éste debe dejar de hacer su trabajo para enseñar. Pueden también existir circunstancias cuando no se debe añadir nuevo equipo ya que las tareas están suficientemente distribuidas, si ese es el caso se requerirá el uso de un recurso dedicado a la integración (configuration manager).
  

Fast tracking - Esta técnica de igual forma que crashing reduce la duración del proyecto pero incrementa el riesgo de tener que rehacer partes ya realizadas. Consiste en jugar con las dependencias fin - inicio. En circunstancias normales si existe esa dependencia una tarea debe terminar para que empiece la siguiente, pero con fast tracking la segunda tarea puede empezar lo antes posible e incluso correr en paralelo con la primera. Se realiza paralelización de trabajo pero teniendo en cuenta que los requerimientos que se conocerían al terminar la primera tarea no se conocen y que el otro desarrollador empieza con la segunda tarea sin esperar el fin de la primera, puede ser que se necesite realizar, reajustes en las dos tareas para que los componentes interoperen correctamente.