6.1 Fundamentos de la planificación del software
Estimar el tamaño y el tiempo de desarrollo del software es una parte importante del plan del proyecto de desarrollo, pero no es lo único. En un plan es necesario incluir todos los costos relacionados con el desarrollo y por lo general suelen ser una carga más elevada para el proyecto que sólo el desarrollo. Piensa en las pruebas, la documentación y capacitación. Todas estas actividades deben ser incorporadas al plan desde un inicio.
“Pocas organizaciones tienen un proceso de planeación que asegure que el plan esté completo, sea revisado a conciencia y convenientemente aprobado” (Humphrey, 2005).
Según Humphrey (2005) existen tres razones de peso sobre la importancia de una adecuada planeación:
- Sin la planeación cualquier esfuerzo por desarrollar un software no podría ser gestionado de forma adecuada.
- Planear es una habilidad que el ingeniero de software puede aprender y mejorar con la práctica.
- Un plan permite realizar un mejor trabajo de software.
Planeación de proyectos de software
Los proyectos de software inician con una necesidad de una organización. Una idea general de los beneficios que tendrá el proyecto. Una vez que los directivos o dueños de la organización se deciden, lo que realmente desean es que el proyecto sea rápido y con el mínimo de costo, y si el costo es cero mejor; pero ningún proyecto cumple con estas dos condiciones iniciales. Todo proyecto requiere tiempo y genera costos. Los gerentes de sistemas deben establecer un plan basándose en estimaciones y considerando todos los posibles costos. Es un trabajo que no puede hacer una sola persona, se requiere de un análisis minucioso, en el que participan varias áreas, cada una estimará los posibles recursos necesarios para obtener los resultados que la organización espera.
Los problemas suelen surgir cuando el presupuesto (tiempo y costos) no es lo que espera la dirección. Ésta hará todo lo posible para que se recorte el tiempo y recalculen los costos hasta dejarlos al mínimo. Si el gerente del proyecto no demuestra con suficiente información y no defiende el plan, terminará por acceder a las demandas de la dirección, lo que implicará una carga fuerte de presión al equipo de desarrollo y seguramente terminarán entregando un producto sin calidad, que a la postre incurrirá en mayores costos por mantenimiento y soporte, algo distinto a haber seguido con el plan original.
En opinión de Humphrey (2005) realizar un plan deficiente provoca que todos pierdan. El cliente no recibe el producto esperado, el equipo de desarrollo se ve obligado a trabajar a marchas forzadas, perdiendo credibilidad y reputación con el cliente, lo que probablemente sea el peor escenario.
¿Qué es un plan?
Un plan define el trabajo que debe realizarse para obtener un resultado esperado.
Incluye la definición y secuencia de tareas, estima los recursos necesarios (tiempo, presupuesto y personas), y asigna sus respectivos responsables. Es una herramienta útil para monitorear y reportar los avances, detectar desvíos y establecer parámetros de estimación para otros proyectos.
Consideraciones a la hora de planear
Haz clic para conocer más detalles
El tipo del producto es una variable que impactará el proyecto de forma directa. Si la necesidad del cliente es utilizar un sistema integrador con el software heredado, significará un mayor esfuerzo que una aplicación aislada.
Es común que los proyectos no cuenten con los recursos (presupuesto y personas) para iniciar. Es importante considerar el tiempo que se requiere de reclutamiento, contratación y capacitación del personal que participará en el proyecto, así como el tiempo para conseguir fuentes de financiamiento del proyecto, herramientas y lugar de trabajo. Si se omiten estas consideraciones podrían impactar de manera considerable el plan del proyecto.
Algunos contratos establecen un periodo de estabilización en el que el grupo desarrollador se encuentra disponible para realizar posibles ajustes o solucionar bugs que no fueron detectados en las pruebas. Lo anterior implica que los recursos deberán seguir disponibles sin tener una nueva asignación en otro proyecto.
Todo proyecto debe considerar que las necesidades del cliente pueden cambiar, por lo que la administración del cambio es una actividad muy común. Cualquier solicitud de cambio debe ser analizada, se identifican los posibles riesgos y se negocian los impactos al plan original.
El diseño conceptual es de alto nivel y contiene una descripción general de los elementos del producto, y las funciones que realizará sin generar un diseño detallado. Este diseño ayuda a establecer un primer estimado del tamaño del software a realizar y establecer un plan de trabajo.
Humphrey (2005) advierte que el equipo del proyecto no debe sentirse obligado a continuar construyendo el diseño del software final sobre el diseño conceptual. El trabajo de diseño debe considerar los requerimientos detallados que aún no se tienen en este momento del plan.
La calidad del plan radica en el estimado del tamaño del software. Significa generar un plan de trabajo considerando las variables más importantes que pueden impactar el proyecto, y ofrecer un balance entre el tiempo y trabajo requerido.
No debe extrañarte que un primer plan no se cumpla a la perfección, algunas tareas serán sobreestimadas y otras subestimadas; lo más seguro es que requiera ajustes conforme avanza el proyecto.
SOW (Statement of Work)
Todo proyecto debe documentar una declaración del trabajo (SOW, por sus siglas en inglés), que contiene los acuerdos con el cliente, los principales supuestos del proyecto, personas involucradas y las principales dependencias. Al revisar este documento, el cliente puede darse cuenta si el equipo del proyecto entiende las características generales del producto que espera; al mismo tiempo el equipo de trabajo declara cuál será el alcance del proyecto.
6.2 Planificación del software
Para el proceso del PSP, un plan del software debe tener las siguientes características:
Haz clic en cada característica para conocer más detalles
Significa que la información del calendario y la secuencia de actividades deben estar al alcance de las personas que la necesiten.
El plan debe mantener un formato que pueda ser interpretado fácilmente. Un cronograma y un diagrama GANTT podrían servir para aclarar la secuencia, dependencias y la ruta crítica del proyecto. En caso de utilizar algún acrónimo o abreviatura es importante que su significado pueda ser encontrado fácilmente, ya sea en un anexo o al pie del plan de proyecto.
Todo plan debe contener las tareas necesarias, su responsable, duración y su costo.
La precisión en un plan se encuentra expresada en la unidad de medida utilizada. Es importante que esta unidad corresponda a la que el equipo se encuentre acostumbrado a utilizar. De poco serviría expresar un plan en segundos si los involucrados miden el tamaño de esfuerzo en días o semanas.
Proporcionar un plan exacto es una de las características que tienen mayor peso en el éxito de un proyecto. El objetivo será proporcionar un plan con actividades a las que se les asigne un tiempo imparcial, es decir, que la duración de sus actividades sea balanceada, no sobreestimada, ni subestimada.
Proceso de planeación de un proyecto de software
PSP propone que el ingeniero de software siga los siguientes pasos al participar en un proyecto de software como parte de su propio proceso de planeación:
- Comenzar por aclarar qué se espera obtener del proyecto.
El ingeniero de software debe redactar el resultado esperado y revisar con el cliente para evitar ambigüedades. También sirve para que el cliente aclare sus ideas sobre lo que realmente desea.
- Determinar las actividades necesarias del proyecto y estimar cada una de ellas por separado.
El ingeniero debe detallar cada actividad, eso le ayudará en el proceso de estimación, siempre utilizando los registros documentados en otros proyectos como base.
- Realizar una estimación inicial y compararla con actividades de otros proyectos.
- Documentar claramente la estimación del proyecto ya que servirá para realizar una comparación contra los resultados reales.
- Acordar con su jefe directo cualquier solicitud de cambio antes de aceptarlo.
En el siguiente diagrama puedes observar la secuencia de actividades para establecer un plan de proyecto de desarrollo de software. El proceso de planeación inicia con una necesidad del cliente, se aclaran los requerimientos que serán utilizados para elaborar un diseño conceptual.
Con este diseño se inicia el proceso de estimación del tamaño y recursos necesarios. Observa que para estimar se toman en cuenta datos históricos representados por la base de datos del tamaño del software y la base de datos de productividad. La estimación servirá para generar el calendario de actividades y se produce la fecha estimada de fin de proyecto.
Marco de trabajo de la planeación de un proyecto.
Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. USA: Pearson. Sólo para fines educativos.
6.3 Estimación y calendarización actividades
El primer paso para realizar el plan es enlistar las actividades que involucran el proyecto. Es importante determinar la dependencia que existe entre la secuencia de actividades. El siguiente paso es estimar el esfuerzo que requiere cada actividad. Una buena base para realizar esta estimación serán los registros de tiempo de tareas parecidas realizadas en trabajos anteriores. En el caso del primer proyecto es posible solicitarles una estimación a personas con experiencia en otros proyectos. Por ello es importante mantener el registro del trabajo diario a través de los formatos sugeridos por el PSP. En proyectos grandes, la secuencia de actividades suele ser numerosa, por lo que es muy útil realizar estimaciones a través de un método de estimación como PROBE.
Humphrey (2005) hace las siguientes recomendaciones al calendarizar las tareas de un plan:
Un año tiene 52 semanas. Considera 40 horas por semana, es decir, 2,080 horas.
- Al total de horas recorta entre el 10% y 15% del tiempo, debido a consideraciones: vacaciones, días festivos, ausencias por enfermedad o permisos extraordinarios.
- Las organizaciones enfocadas en el desarrollo de software dedican entre 20 y 25 horas a la semana en reuniones, administración de correo electrónico, consultoría para otros proyectos, asesorías a mercadotecnia, y otras tareas que son necesarias, pero que no convendría incluirlas en el plan. Esto equivale a dedicar entre 12 a 15 horas efectivas a las tareas del proyecto. Sin embargo, esto puede variar dependiendo de la posición del programador, incluso de semana a semana.
- Lo más conveniente es iniciar con una estimación de 12 a 15 horas las primeras semanas de trabajo, y conforme avanza el proyecto aumentar entre 15 y 17 horas.
- Asignar semanas de más de 20 horas de trabajo suele ser irreal en equipos de trabajo que no son autodirigidos y, por lo general, terminan retrasando el proyecto irremediablemente. Es recomendable ser conservadores a la hora de estimar las horas dedicadas al proyecto, sobre todo cuando no se tenga información de cómo se han hecho tareas similares en otros proyectos.
- Si el proyecto se retrasa es posible dedicarle más horas al desarrollo por un periodo de tiempo corto, sin embargo, eso significa dedicar menos tiempo a otras actividades como reuniones, contestar el correo electrónico, atender llamadas, etc., o bien hacer jornadas de trabajo diario más largas.
PSP hace énfasis en utilizar esta estrategia de forma temporal, ya que puede ser contraproducente en los índices de productividad del equipo de trabajo si se mantiene un ritmo de trabajo tan exigente por periodos de tiempo muy largos. Hacer uso de alguna herramienta, como MS-Project, puede ser muy útil ya que se pueden configurar los periodos de tiempo laborales, días de descanso y días de asueto de forma anticipada. Así asignará la duración estimada de cada tarea, tomando en consideración estas variables de forma automática.
Calendarizar las actividades del plan
El procedimiento para realizar una calendarización del plan de forma adecuada se muestra en la siguiente imagen:
Haz clic en cada paso para conocer más detalles
Proceso para construir el calendario de tareas.
Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. USA: Pearson Education. Sólo para fines educativos.
Tabla 6.1. Ejemplo de una plantilla de planificación de tareas
Fase |
Tarea |
Horas plan |
Acum.Horas plan |
Dependencias |
VP(%) |
Acum. VP (%) |
Plan Día |
Horas reales |
VG |
Cum. VG |
Planeación |
1 |
2 |
2 |
0 |
5.4 |
5.4 |
1 |
8 |
5.4 |
5.4 |
Planeación |
2 |
5 |
7 |
1 |
13.5 |
18.9 |
2 |
9 |
13.5 |
18.9 |
Planeación |
|
7 |
|
|
18.9 |
|
|
|
|
|
Desarrollo |
3 |
4 |
11 |
2 |
10.8 |
29.7 |
3 |
|
|
|
Desarrollo |
4 |
7 |
18 |
3 |
18.9 |
48.6 |
4 |
|
|
|
Desarrollo |
5 |
3 |
21 |
3 |
8.1 |
56.7 |
5 |
|
|
|
Desarrollo |
6 |
5 |
26 |
4 |
13.5 |
70.2 |
6 |
|
|
|
Desarrollo |
7 |
6 |
32 |
4 |
16.3 |
86.5 |
7 |
|
|
|
Desarrollo |
|
25 |
|
|
67.6 |
|
|
|
|
|
Post Mortem |
8 |
3 |
35 |
7 |
8.1 |
94.6 |
8 |
|
|
|
Post Mortem |
9 |
2 |
37 |
8 |
5.4 |
100 |
8 |
|
|
|
Post Mortem |
|
5 |
|
|
13.5 |
|
|
|
|
|
Totales |
|
5 |
|
|
|
|
8 |
|
|
|
Tabla 6.2 Plantilla para calendarizar el plan
Fecha |
Día |
Horas plan |
Horas acum. |
Horas reales |
Acum. Horas reales
| VP |
Acum VP
| VG |
Acum VG |
1 / 03 |
1 |
6 |
6 |
8 |
8 |
5.4 |
5.4 |
5.4 |
5.4 |
2 / 03 |
2 |
6 |
12 |
6 |
14 |
13.5 |
18.9 |
0 |
5.4 |
3 / 03 |
3 |
6 |
18 |
5 |
19 |
10.8 |
29.7 |
13.5 |
18.9 |
| |
4 |
5 |
23 |
|
|
18.9 |
48.6 |
|
|
| |
5 |
5 |
28 |
|
|
8.1 |
56.7 |
|
|
| |
6 |
4 |
32 |
|
|
13.5 |
70.2 |
|
|
| |
7 |
6 |
38 |
|
|
16.3 |
86.5 |
|
|
| |
8 |
6 |
44 |
|
|
8.1 |
94.6 |
|
|
| |
8 |
6 |
50 |
|
|
5.4 |
100 |
|
|
En este ejemplo, el programador llenó la plantilla del calendario de forma diaria. Observa que no todos los días planea dedicarle las 8 horas de la jornada laboral. Incluso en el día 6 del proyecto sólo planea tener 4 horas, porque ese día deberá atender a un cliente en sus instalaciones. El Valor Ganado VG (Earned Value) es el valor planeado que suma cada vez que una tarea la completa.
En este caso observa que, el día 2, el ingeniero dedica 6 horas para una tarea, sin embargo, no la completa, por lo que el VG es 0. Lo que expresa que existe un retraso al valor planeado de ese día. Para el día 3 del proyecto lleva un 18.9% de avance, en comparación con un 29.7% de avance planeado.
Tanto la plantilla de planificación de tareas como el calendario del plan son herramientas que el ingeniero de software puede llenar conforme avanza su trabajo en el proyecto. Es importante que tenga disciplina para registrar su progreso.
