La
gestión eficaz de un proyecto de software se centra en las cuatro P’s:
personal, producto, proceso y proyecto. El orden no es arbitrario. El
gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo
humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no
fomenta una minuciosa comunicación con el cliente al principio de la evolución
del proyecto se arriesga a construir una elegante solución para un problema
equivocado. El administrador que presta poca atención al proceso corre el riesgo
de arrojar métodos técnicos y herramientas eficaces al vacío. El gestor que
emprende un proyecto sin un plan sólido arriesga el éxito del
producto.
Personal
La
necesidad de contar con personal para el desarrollo del software altamente
preparado y motivado se viene discutiendo desde los años 60 (por ejemplo, COUSO,
WíT94, DEM981). De hecho, el «factor humano» es tan importante que el Instituto
de Ingeniería del Software ha desarrollado un Modelo de madurez de la
capacidad de gestión de personal (MMCGP) «para aumentar la preparación de
organizaciones del software para llevar a cabo las cada vez más complicadas
aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el
talento necesario para mejorar su capacidad de desarrollo de software»
[CUR94].
El
modelo de madurez de gestión de personal define las siguientes áreas clave
prácticas para el personal que desarrolla software: reclutamiento, selección,
gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera,
diseño de la organización y del trabajo y desarrollo
cultural y de espíritu de equipo. El MMCGP es compañero del modelo de madurez de
la capacidad software, que guía a las organizaciones en la creación de un
proceso de software maduro.
Cargos
del Personal
- Operador de PC
- Técnico de Soporte y Mantenimiento
- Técnico de Reparación de PC, impresoras, monitores, celulares, etc.
- Técnico en Programación
- Técnico en Redes de PC, teléfonos y de comunicación
- Ingeniero en Computación
- Ingeniería en Sistemas de Información
- Ingeniería en Telecomunicaciones
- Administrados de Base de Datos
- Administrador de Redes
- Administrador de Servidores
- Administrador de Sistemas de Informáticos
- Analista Categorías: A, B, C.
- Diseñador de Web y de Interfaz
- Diseñador/a
- Auditor/a
- Evaluador/a
- Diseñador/a Informático/a
- Director/a de Centros
- Capacitadores
Producto
Antes
de poder planificar un proyecto, se deberían establecer los objetivos y el
ámbito del producto, se deberían considerar soluciones
alternativas e identificar las dificultades técnicas y de gestión. Sin esta
información, es imposible definir unas estimaciones razonables (y exactas) del
coste; una valoración efectiva del riesgo, una subdivisión realista de las
tareas del proyecto o una planificación del proyecto asequible que proporcione
una indicación fiable del progreso.
El
desarrollador de software y el cliente deben reunirse para
definir los objetivos del producto y su ámbito. En muchos casos, esta actividad
empieza como parte del proceso de ingeniería del sistema o del negocio y
continúa como el primer paso en el análisis de los requisitos del software.
Los objetivos identifican las metas generales del proyecto sin
considerar cómo se conseguirán (desde el punto de vista del
cliente).
El
ámbito identifica los datos primarios, funciones y comportamientos que
caracterizan al producto, y, más importante, intenta abordar estas
características de una manera cuantitativa. Una vez que se han entendido los
objetivos y el ámbito del producto, se consideran soluciones
alternativas.
Proceso
Un
proceso de software proporciona la estructura desde la que se puede establecer
un detallado plan para el desarrollo del software. Un pequeño número de
actividades estructurales se puede aplicar a todos los proyectos de software,
sin tener en cuenta su tamaño o complejidad. Diferentes conjuntos de tareas,
hitos, productos del trabajo y puntos de garantía de calidad permiten a las
actividades estructurales adaptarse a las características del proyecto de
software y a los requisitos del equipo del proyecto. Finalmente, las actividades
protectoras tales como garantía de calidad del software, gestión de la
configuración del software y medición cubren el modelo de proceso. Las
actividades protectoras son independientes de las estructurales y tienen lugar a
lo largo del proceso.
Proyecto
Dirigimos
los proyectos de software planificados y controlados por una razón principal es
la Única manera conocida de gestionar la complejidad. Y todavía
seguimos
esforzándonos. En 1998, los datos de la industria del software indicaron que el
26% de proyectos de software fallaron completamente y que el 46% experimentaron
un desbordamiento en la planificación y en el coste [REE99]. Aunque la
proporción de éxito para los proyectos de software ha mejorado un poco, nuestra
proporción de fracaso de proyecto permanece más alto del que debería ser. Para
evitar el fracaso del proyecto, un gestor de proyectos de software y los
ingenieros de software que construyeron el producto deben eludir un conjunto de
señales de peligro comunes; comprender los factores del éxito críticos que
conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido
común para planificar, supervisar y controlar el proyecto.
Practicas
Críticas
El
Concilio Airlie ha desarrollado una lista de «prácticas críticas de software
para la gestión basada en el rendimiento». Estas prácticas son «utilizadas de
un modo consistente por, y consideradas críticas por,
organizaciones y proyectos de software de mucho éxito cuyo rendimiento “final”
es más consistente que los promedios de la industria» [AIR99]. En un esfuerzo
por permitir a una organización de software determinar si un proyecto específico
ha implementado prácticas críticas, el Concilio Airlie ha desarrollado
un conjunto de preguntas de «Visión Rápida» [AIR99] para un
proyecto:
Gestión
formal del riesgo ¿Cuáles
son los diez riesgos principales para este proyecto? Para cada uno de los
riesgos ¿cuál es la oportunidad de que el riesgo se convierta en un problema
y cuál es el impacto si lo hace?
Coste
empírico y estimación de la planificación ¿Cuál
es el tamaño actual estimado de la aplicación de software (sin incluir el
software del sistema) que será entregada en la operación? ¿Cómo se
obtuvo?
Gestión
de proyectos basada en métricas ¿Dispone
de un programa de métricas para dar una primera indicación de los problemas del
desarrollo? Si es así, ¿cuál es la volatilidad de los requisitos
actualmente?
Seguimiento
del valor ganado ¿Informa
mensualmente de las métricas del valor ganado? Si es así, ¿están
calculadas estas métricas desde una red de actividades de tareas para el
esfuerzo total a la próxima entrega?
Seguimiento
de defectos frente a objetivos de calidad ¿Realiza
el seguimiento e informa periódicamente del número de defectos encontrados en
cada prueba de inspección [revisión técnica formal] y ejecución desde el
principio del programa y del número de defectos que se corrigen y se producen en
la actualidad?
Gestión
del programa del personal ¿Cuál
es la media de rotación de la plantilla en los tres Últimos meses por cada uno
de los distribuidores/desarrolladores involucrados en el desarrollo del software
para este sistema?
Si
un equipo de proyectos de software no puede responder a estas preguntas, o las
responde inadecuadamente, se debe realizar una revisión completa de las
prácticas del proyecto.
No hay comentarios:
Publicar un comentario