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.
3.1.1. 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 (Capítulo 2), que guía a las
organizaciones en la creación de un proceso de software
maduro. Más adelante en este capítulo se consideran
aspectos asociados a la gestión de personal y estructuras
para proyectos de software.
3.1.2. 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.
En d Capitulo 1 se tmto una taxonomía de las &reas
de aplicociiin que producen los aproductosx de software.
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 (Capítulo 10)
y continúa como el primer paso en el análisis de los requisitos
del software (Capítulo 11). 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.
3.1.3. Proceso
Un proceso de software (Capítulo 2) 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
-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.
3.1.4. 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 por 100 de proyectos
de software fallaron completamente y que el 46
por 100 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 ser2.
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. Cada
uno de estos aspectos se trata en la Sección 3.5 y en los
capítulos siguientes.
Personal
En un estudio publicado por el IEEE [CURSS] se les
preguntó a los vicepresidentes ingenieros de tres grandes
compañías tecnológicas sobre el factor más importante
que contribuye al éxito de un proyecto de software.
Respondieron de la siguiente manera:
VP 1: Supongo que si tuviera que elegir lo más importante
de nuestro entorno de trabajo, diría que no son las
herramientas que empleamos, es la gente.
VP 2: El ingrediente más importante que contribuyó al éxito
de este proyecto fue tener gente lista ... pocas cosas
más importan en mi opinión ... Lo más importante
que se puede hacer por un proyecto es seleccionar el
personal ... El éxito de la organización de desarrollo
del software está muy, muy asociado con la habilidad
de reclutar buenos profesionales.
VP 3: La única regla que tengo en cuanto a la gestión
es asegurarme de que tengo buenos profesionales
-gente realmente buena-, de que preparo buena
gente y de que proporciono el entorno en el
que los buenos profesionales puedan producir.
Ciertamente, éste es un testimonio convincente sobre
la importancia del personal en el proceso de ingeniería
del software. Y, sin embargo, todos nosotros, desde los
veteranos vicepresidentes al más modesto profesional
del software, damos este aspecto por descontado. Los
gestores argumentan (como el grupo anterior) que el
personal es algo primario, pero los hechos desmienten
a veces sus palabras.
En esta sección examinamos los participantes que colaboran
en el proceso del software y la manera en que se
organizan para realizar una ingeniería del Software eficaz.
3.2.1. Los participantes
El proceso del software (y todos los proyectos de software)
lo componen participantes que pueden clasificarse
en una de estas cinco categorías:
Gestores superiores, que definen los aspectos de
negocios que a menudo tienen una significativa
influencia en el proyecto.
Gestores (técnicos) del proyecto, que deben planificar,
motivar, organizar y controlar a los profesionales
que realizan el trabajo de software.
Profesionales, que proporcionan las capacidades técnicas
necesarias para la ingeniería de un producto o
aplicación.
Clientes, que especifican los requisitos para la ingeniería
del software y otros elementos que tienen
menor influencia en el resultado.
Usuarios finales, que interaccionan con el software
una vez que se ha entregado para la producción.
Para ser eficaz, el equipo del proyecto debe organizarse
de manera que maximice las habiiidades y capacidades
de cada persona. Y este es el trabajo del jefe del equipo.
3.2.2. Los jefes de equipo
La gestión de un proyecto es una actividad intensamente
humana, y por esta razón, los profesionales competentes
del software a menudo no son buenos jefes de equipo.
Simplemente no tienen la mezcla adecuada de
capacidades del personal. Y sin embargo, como dice
Edgemon: «Desafortunadamente y con demasiada frecuencia,
hay individuos que terminan en la gestión de
proyectos y se convierten en gestores de proyecto accidentales
» [EDG95].
¿En qué nos fijamos cuando
seleccionamos a alguien para
conducir un proyecto de software?
En un excelente libro sobre gestión técnica, Jerry
Weinberg [WEI86] sugiere el modelo de gestión MOI:
Motivación. La habilidad para motivar (con un «tira y afloja
») al personal técnico para que produzca conforme a sus mejores
capacidades.
Organización. La habilidad para amoldar procesos existentes
(o inventar unos nuevos) que permita al concepto inicial
transformarse en un producto hal.
Ideas o innovación. La habilidad para motivar al personal
para crear y sentirse creativos incluso cuando deban de trabajar
dentro de los límites establecidos para un producto o aplicación
de software particular.
Weinberg sugiere que el éxito de los gestores de proyecto
se basa en aplicar un estilo de gestión en la resolución
de problemas. Es decir, un gestor de proyectos de
software debería concentrarse en entender el problema
que hay que resolver, gestionando el flujo de ideas y, al
mismo tiempo, haciendo saber a todos los miembros del
equipo (mediante palabras y, mucho más importante,
con hechos) que la calidad es importante y que no debe
verse comprometida.
Otro punto de vista [EDG95] de las características
que definen a un gestor de proyectos eficiente resalta
cuatro apartados clave:
Resolución del problema. Un gestor eficiente de un proyecto
de software puede diagnosticar los aspectos técnicos y
de organización más relevantes, estructurar una solución sistemáticamente
o motivar apropiadamente a otros profesionales
para que desarrollen la solución, aplicar las lecciones aprendidas
de anteriores proyectos a las nuevas situaciones, mantenerse
lo suficientemente flexible para cambiar la gestión si los
intentos iniciales de resolver el problema no dan resultado.
Dotes de gestión. Un buen gestor de proyectos debe tomar
las riendas. Debe tener confianza para asumir el control cuando
sea necesario y la garantía para permitir que los buenos técnicos
sigan sus instintos.
Incentivos por logros. Para optimizar la productividad de
un equipo de proyecto, un gestor debe recompensar la iniciativa
y los logros, y demostrar a través de sus propias acciones
que no se penalizará si se corren riesgos controlados.
Influencia y construcción de espíritu de equipo. Un gestor
de proyecto eficiente debe ser capaz de «leer» a la gente;
debe ser capaz de entender señales verbales y no verbales y
reaccionar ante las necesidades de las personas que mandan
esas señales. El gestor debe mantener el control en situaciones
de gran estrés.
Un experto de sohore puede no tener temperomento o
deseo de ser jefe de equipo. No fuerce oí experto poro ser
uno de ellos.
3.2.3. El equipo de software
Existen casi tantas estructuras de organización de personal
para el desarrollo de software como organizaciones
que se dedican a ello. Para bien o para mal, el organigrama
no puede cambiarse fácilmente. Las consecuencias
prácticas y políticas de un cambio de organización
no están dentro del alcance de las responsabilidades del
gestor de un proyecto de software. Sin embargo, la organización
del personal directamente involucrado en un
nuevo proyecto de software está dentro del ámbito del
gestor del proyecto.
Las siguientes opciones pueden aplicarse a los recursos
humanos de un proyecto que requiere n personas
trabajando durante k años:
n individuos son asignados a m diferentes tareas funcionales,
tiene lugar relativamente poco trabajo conjunto;
la coordinación es responsabilidad del gestor
del software que puede que tenga otros seis proyectos
de los que preocuparse.
y1 individuos son asignados a m diferentes tareas funcionales
(m<n) de manera que se establecen «equip
o s ~in formales; se puede nombrar un líder al efecto;
la coordinación entre los equipos es responsabilidad
de un gestor del software.
n individuos se organizan en t equipos; a cada equipo
se le asignan una o más tareas funcionales; cada
equipo tiene una estructura específica que se define
para todos los equipos que trabajan en el proyecto;
la coordinación es controlada por el equipo y por el
gestor del proyecto de software.
Aunque es posible encontrar argumentos en pro y en
contra para cada uno de los enfoques anteriores, existe
Producto
El gestor de un proyecto de software se enfrenta a un dilema
al inicio de un proyecto de ingeniería del software.
Se requieren estimaciones cuantitativas y un plan organizado,
pero no se dispone de información sólida. Un
análisis detallado de los requisitos del software proporcionaría
la información necesaria para las estimaciones,
pero el análisis a menudo lleva semanas o meses.
Aún peor, los requisitos pueden ser fluidos, cambiando
regularmente a medida que progresa el proyecto. Y, aún
así, se necesita un plan «¡ya!».
3.3.1. Ámbito del software
La primera actividad de gestión de un proyecto de software
es determinar el ámbito del software. El ámbito se
define respondiendo a las siguientes 'cuestiones:
Si no puede delimitur uno corocterísrico de/ sohure
que intento construib considere /o característica como
un riesgo principo/ de/ proyecto.
Por tanto, debemos examinar el producto y el problema
a resolver justo al inicio del proyecto. Por lo
menos se debe establecer el ámbito del producto y
delimitarlo. do del contexto?
Contexto. ¿Cómo encaja el software a construir
en un sistema, producto o contexto de negocios
mayor y qué limitaciones se imponen como resulta-
Las fases genéricas que caracterizan el proceso de software
definición, desarrollo y soporte- son aplicables
a todo software. El problema es seleccionar el modelo de
proceso apropiado para la ingeniería del software que debe
aplicar el equipo del proyecto. En el Capítulo 2 se estudió
una gran gama de paradigmas de ingeniería del software:
el modelo secuencia1 lineal
* el modelo de prototipo
el modelo DRA .
.
.
el modelo incremental
el modelo en espiral
el modelo en espiral WINWIN
el modelo de desarrollo basado (ensamblaje) en componentes
el modelo de desarrollo concurrente
el modelo de métodos formales
el modelo de técnicas de cuarta generación
INGENIERiA DEL SOFTWARE. UN ENFOQUE PRACTICO
Uno vez eleyido el modelo de proceso, ocompóñelo con
el mínimo conjunto de toreos de trubojo y productos que
desembocaron en un producto de oltu colidud - e v i t e la
cupocidod de destrucción del procese.
El gestor del proyecto debe decidir qué modelo de
proceso es el más adecuado para (1) los clientes que han
solicitado el producto y la gente que realizará el trabajo;
(2) las características del producto en sí, y (3) el entorno
del proyecto en el que trabaja el equipo de software.
Cuando se selecciona un modelo de proceso, el equipo
define entonces un plan de proyecto preliminar basado
en un conjunto de actividades estructurales. Una vez
establecido el plan preliminar, empieza la descomposición
del proceso. Es decir, se debe crear un plan completo
reflejando las tareas requeridas a las personas para
cubrir las actividades estructurales. Exploramos estas
actividades brevemente en las secciones que siguen y
presentamos una visión más detallada .
3.4.1. Maduración del producto y del proceso
La planificación de un proyecto empieza con la maduración
del producto y del proceso. Todas las funciones
que se deben tratar dentro de un proceso de ingeniería
por el equipo de software deben pasar por el conjunto
de actividades estructurales que se han definido para
una organización de software. Asuma que la organización
ha adoptado el siguiente conjunto de actividades
estructurales (Capítulo 2):
Comunicación con el cliente- tareas requeridas para
establecer la obtención de requisitos eficiente entre
el desarrollador y el cliente.
Planificación- tareas requeridas para definir los
recursos, la planificación temporal del proyecto y
cualquier información relativa a él.
Recuerde .... las ocrividaáes estructurales se u p h n
en todos los proyectos- no hoy excepciones.
Análisis del riesgo- tareas requeridas para valorar
los riesgos técnicos y de gestión.
Zngenieriu- tareas requeridas para construir una o
más representaciones de la aplicación.
Construcción y entrega- tareas requeridas para construir,
probar, instalar y proporcionar asistencia al usuario
(por ejemplo: documentación y formación).
Evaluación del cliente- tareas requeridas para obtener
información de la opinión del cliente basadas en
la evaluación de las representaciones de software
creadas durante la fase de ingeniería e implementadas
durante la fase de instalación.
Los miembros del equipo que trabajan en cada función
aplicarán todas las actividades estructurales. En esencia,
se crea una matriz similar a la que se muestra en la Figura
3.2. Cada función principal del problema (la figura contiene
las funciones para el software procesador de textos
comentado anteriormente) se lista en la columna de la
izquierda. Las actividades estructurales se listan en la fila
Me fue de gran ayuda su trabajo.
ResponderEliminar