archivo

Archivos diarios: septiembre 12, 2011

El desarrollador hindú Moses Oliver refleja de manera clara en la siguiente reflexión cuáles deberían ser los objetivos de un programador y un tester: “Un programador trabaja para un resultado libre de errores; un tester, para encontrarlos”.

El problema de esto es que a los programadores se les enseña que lo importante es ejecutar y realmente no es solo eso lo que importa ya que avanzar para después tener otra vez que retroceder y rehacer módulos de la aplicación no es precisamente lo más adecuado.

También a los testers se les enseña que lo más importante es el seguimiento de la metodología, de los planes de pruebas o de las plantillas de aspectos a verificar en entregables y se encierran demasiado en eso, descuidando el objetivo final que es encontrar errores lo antes posible y cuanto más críticos mejor”.

La planificación del proyecto supone la base para la realización del mismo, por lo que es habitual que la mayor parte de las tareas que lo componen se realicen de una manera más o menos formal: Determinar un alcance inicial (aunque sea a alto nivel), hacer un análisis de riesgos, hacer una estimación del coste/esfuerzo, de los recursos en materia de personal (¿quiénes van a participar?, ¿cuándo?, ¿con qué dedicación?, ¿necesitan algún tipo de formación antes de enfrentarse al proyecto?) y materiales (software y hardware), definir el ciclo de vida/metodología a utilizar, proponer un cronograma, definir los hitos, las personas que los apruebas, etc…

Buena parte de la suerte del proyecto se juega al principio, una mala negociación, una mala estimación, en general, una mala planificación puede condicionar negativamente el proyecto, hasta tal punto de que si no hay posibilidad de enmendar la situación a tiempo puede afectar incluso a su viabilidad.

La incorporación de esta tarea y darle un grado de formalidad en los proyectos software, resulta por tanto, lógica en el nivel 2 de CMMI.

Es decir, a partir de ahora y en cada proyecto, es necesario que esas tareas preparatorias del proyecto se realicen, siguiendo un proceso, una estrategia, un plan. Se entiende que de esta manera las decisiones que se tomen se harán siguiendo una lógica que vendrá definida por las distintas soluciones y técnicas que se utilicen para realizar las diferentes actividades del mismo (estimación de proyecto, análisis de riesgos, etc…), si bien, la existencia de un proceso de guíe a la definición del plan de proyecto no asegura nada si la ejecución no es buena (ya sea por un incorrecto desempeño del que la realiza y/o porque la información que tiene para realizar la planificación no es adecuada o válida).

Se entiende que este área de proceso debería tomar como partida los requisitos del área de proceso “Gestión de requisitos”, sin embargo esto no va a ser siempre posible. Es cierto que es deseable conocer el mayor detalle posible antes de realizar por ejemplo una estimación de costes, pero también lo es que no siempre se van dar las condiciones para poder realizar esta tarea ya que la contratación del servicio de desarrollo de software se puede realizar en base a un pliego de condiciones técnicas o incluir dentro del mismo las tareas de análisis.

A lo anterior hay que sumar la volatilidad de los requisitos, ya que lo mismo la estimación se ha realizado teniendo en cuenta unos, pero después cambian las condiciones y se rompen los esquemas.

Dependerá de la organización tomar parte o no en un proyecto en función del grado de incertidumbre existente, de las características del cliente y de la propia cultura y experiencia de la misma.

Desde mi punto de vista la planificación inicial del proyecto es muy importante, independientemente del grado de incertidumbre y es importante que todas las partes entiendan que se trata de un plan inicial que se deberá ir ajustando a la evolución real del proyecto.