CMO SE DESARROLLA SOFTWARE?

PROCESOS DE GESTIN

Despus de abordar la discusin acerca de los procesos tcnicos de desarrollo

de software, y cmo stos son ms complejos que simplemente conocer
detalladamente el lenguaje escogido y la herramienta de desarrollo
correspondiente, en esta lectura obtendremos una visin ms general aun de
lo que significa desarrollar software en la actualidad. Si bien la lectura de la
semana anterior permiti tener una visin ms general de lo que usualmente se
concede al desarrollo de software, su enfoque sigui siendo tcnico. En esta
instancia de las lecturas del mdulo se pretende dar un vistazo al marco
general de procedimientos, estndares, conceptos y buenas prcticas que
hacen posible que un proceso de desarrollo de software llegue a buen
trmino, no solamente desde la perspectiva de lo tcnico, sino desde la
perspectiva ms general de la organizacin y gestin de procesos que, en
todos los sentidos, garantiza un ambiente productivo para que el desarrollo del
software pueda darse de manera idnea.

En primer lugar, y desde esta perspectiva no tcnica, un proceso de desarrollo

de software debe considerarse como un Proyecto, cuyo propsito es
desarrollar un producto de software. Este Proyecto est compuesto por un
conjunto de Actividades, cada una de las cuales a su vez est conformada
por un nmero de Tareas. Cada una de estas Tareas, consume Recursos y
genera un Producto de Trabajo, que puede ser un Sistema, un Modelo, o un
Documento. A su vez los Recursos pueden ser Participantes, Tiempo, o Equipos.

Desarrollar un producto de software requiere la participacin de un conjunto

de personas con diferentes intereses, profesiones y antecedentes. Por un lado
est el cliente, que ordena el producto y paga por l. Por otro lado estn los
desarrolladores que lo construyen, los usuarios finales que lo utilizan y el gerente
del proyecto que se encarga de coordinar a los dems participantes y de
mantener el proyecto dentro del presupuesto y el cronograma. Todas estas
personas son Participantes, y el conjunto de responsabilidades que tienen,
definen un Rol. Uno de estos Roles se asocia a un conjunto de Tareas y se
asigna a un Participante.

Definamos ahora los dems componentes:

Un Sistema define la realidad que es representada por un Modelo. Los modelos

en un proyecto de software no tienen por qu ser tcnicos. Existen modelos
tales como el presupuesto, el cronograma, el organigrama del proyecto que

describen realidades mucho ms complejas que tienen que ver con el

desarrollo del proyecto de software. Es importante tener esto en cuenta
porque en la mayor parte de los casos se enfoca el desarrollo de un proyecto
de software desde una perspectiva eminentemente tcnica y mientras este
punto de vista es tremendamente importante, no es el nico; adems, un
proyecto con unas muy slidas bases tcnicas puede ir al traste si no tiene el
apoyo de un adecuado proceso organizacional en los dems aspectos.

Un Producto de Trabajo es cualquier elemento que es generado durante el

desarrollo del proyecto, bien sea para consumo interno de otra parte del
proceso (Modelos tcnicos, o documentos internos de avance), o para
entregar al exterior de la compaa como resultado entregable parcial o final
del proceso (Bajo la forma de documentos de organizacin del proceso,
cdigo fuente, archivos ejecutables, reportes de avance, etc.).

Una Actividad es un conjunto de Tareas que se llevan a cabo con el objetivo

de cumplir un propsito especfico. Por otro lado, una Tarea es una unidad
indivisible de trabajo que puede ser controlada. Una tarea puede recibir como
insumo Productos de Trabajo provenientes de otras tareas, y mediante el
consumo de recursos, generar nuevos Productos de Trabajo. Los Recursos son
bienes de los que se dispone para cumplir un trabajo determinado.

Una Meta es un principio de alto nivel que dirige el desarrollo del proyecto. La
idea ltima del proyecto es alcanzar las metas propuestas el principio del
mismo. Un proyecto no siempre tiene una nica Meta, y cuando hay ms de
una, no es raro que las Metas tengan conflictos entre s. Uno de los ejemplos
ms clsicos es cuando se trata de reconciliar una meta relacionada con la
calidad del producto final con una que tiene que ver con los costos.
Usualmente se trata de elevar el nivel medido respecto a la primera, mientras
se baja el nivel respecto a la segunda. Sin embargo, esto no siempre es
posible, y se hace necesario llevar a cabo un proceso de negociacin en el
que se busque la mejor solucin teniendo en cuenta las circunstancias.

Un Mtodo es una tcnica repetible para solucionar un problema particular.

Una Metodologa es una coleccin de Mtodos para resolver una clase de
problemas. La aplicacin de Metodologas brinda formalismo y control al
proceso general de un proyecto de software.

Adicionalmente a toda la terminologa expuesta hasta el momento, a sus

definiciones y a las relaciones que tienen entre s, existen un conjunto de
actividades relacionadas con la administracin de un proyecto de software
que van paralelas a las actividades de tipo tcnico definidas hasta ahora. El
conjunto de estas actividades ofrece un tinglado que organiza, soporta,
optimiza y controla las actividades tcnicas y de otro tipo. Cuando se
desarrollan de manera adecuada, las actividades de administracin

involucran a todas las personas dentro del proyecto, y no solamente al gerente

del mismo. Algunas de las ms importantes son:

Comunicacin. La necesidad de mantener el flujo de informacin dentro de

un proyecto de software resulta evidente a primera vista. No es aceptable que
la informacin necesaria no sea compartida por aquellos que la poseen con
aquellos que la necesitan, y sin embargo, este es el caso en muchas
ocasiones. Estos fallos en la comunicacin se deben a diferentes factores,
entre los que se encuentran la falta de mecanismos y estndares bien
definidos, la carencia de herramientas para garantizar la comunicacin, las
condiciones de falta de sincrona temporal
(En un proyecto con personas en diferentes zonas horarias por ejemplo) o la
distancia geogrfica de los participantes en el proyecto, etc. Es labor de la
gerencia del proyecto facilitar y mantener la comunicacin entre los miembros
del equipo, y hacia y desde la gerencia del mismo.

Administracin del Proyecto. La administracin del proyecto contempla el

conjunto de actividades que permiten, mediante su ejecucin, garantizar que
se entregue un producto de calidad, a tiempo, y con las condiciones
econmicas previstas. En su mayor parte se trata de actividades de
supervisin, planeacin y control, en aspectos tales como el cronograma, la
gestin de presupuesto, las negociaciones con el cliente, la distribucin de los
desarrolladores en equipos de trabajo, la distribucin del trabajo total en
mdulos que puedan ser asignados a los equipos de trabajo previamente
seleccionados, etc. Las labores de administracin usualmente comienzan
antes de que se empiece el desarrollo tcnico del proyecto y en la mayor
parte de los casos son las ltimas en finalizar, cuando ya se ha escrito la ltima
lnea de cdigo del programa.

A pesar de lo que pueda parecer, es necesario aclarar que no se pretende, en

ningn momento reducir o menospreciar nla labor tcnica de un proyecto, o
hacer parecer que no tiene la misma importancia que las labores de
administracin. No se trata de eso. Es clarsimo que sin un trabajo de tipo
tcnico que sea adecuado, no habra un producto terminado jams. Sin
embargo, si es muy importante rescatar las labores que no son tcnicas del
rincn en que se han olvidado. Estudios recientes sugieren que solo alrededor
del 15% de los proyectos de software que se comienzan terminan en xito. El
85% restante presenta algn tipo de inconveniente, que va desde la demora
en las entregas, o problemas de calidad con las mismas, hasta el fracaso total
del proyecto. Uno de los motivos ms importantes para que este nivel de
fracaso sea usual es que no se da la importancia requerida a los procesos que
no son tcnicos dentro del desarrollo de un proyecto de software. Piense
usted en una cosa: Se le ocurrira comenzar el proyecto de construir un
puente sin tener un presupuesto? Sin tener un plano? Un cronograma? Sin
saber si las personas encargadas de construir el puente tienen o no
experiencia en ese tipo de construcciones? Probablemente no. Sin embargo

eso es exactamente lo que sucede en muchos de los proyectos de software

que se inician hoy en da. Hay proyectos que rivalizan en complejidad con la
construccin de cualquier edificio o estructura fsica y que sin embargo son
iniciados sin tener siquiera claridad respecto a qu se va a desarrollar. Se
inician proyectos de software sin tener un cronograma acordado con el
cliente, sin tener un diseo al menos en progreso, sin saber si las personas a
cargo del desarrollo tienen la capacidad requerida para concluir el proyecto.
Este es el tipo de cosas que lamentablemente hace a la industria del software
un campo que inspira poca confianza cuando de confiabilidad y crdito en
las entregas y procesos se trata.

Ahora bien, est claro que los gerentes de proyecto rara vez generan algn
tipo de producto de manera directa. Es por esto que en la cultura
tecnolgica, a menudo son blanco de las burlas de los desarrolladores y otros
miembros del equipo que s hacen trabajo. Este es un mito que es necesario
desterrar. Hay que tener claro que las labores de administracin son un
componente crucial dentro de cualquier proceso que espere generar
entregables de calidad de la manera y dentro del marco de tiempo en que
inicialmente se planeo hacerlo.

Si se desea definir una divisin del tiempo total de duracin de un proyecto en

tres grandes fases que definen diferentes estados de la actividad, es posible
hacerlo con la siguiente estructura:

Inicio del proyecto. Esta es la fase durante la cual son completadas las
definiciones iniciales del proyecto, comprendiendo su duracin, alcance,
objetivos generales, distribucin de personas en equipos, y en general las
labores que definen de manera inicial qu se debe hacer en el proyecto.
Durante esta fase, la labor de la gerencia del proyecto es claramente
fundamental, por cuanto de esta instancia dependen labores clave como la
planeacin inicial junto con la definicin de puntos de control y entregables
principales, la contratacin de personal, la estructuracin de equipos de
trabajo, la comunicacin de la estructura general y el plan de trabajo para el
proyecto, la asignacin de lderes de equipo, la reparticin inicial de labores y
otras muchas actividades de las que depende el poder dar inicio al proyecto.
Es necesario tener en cuenta que prcticamente todas estas labores se dan
antes de que se comience el proceso tcnico de desarrollo dentro del
proyecto. Y es vlido recalcar tambin que de no ser llevadas a cabo de una
manera correcta, centralizada y con una visin general de todos los aspectos
que involucra el desarrollo de un proyecto de software, no es factible
garantizar un arranque exitoso del mismo.

Desarrollo del proyecto. Es el periodo durante el cual son llevadas a cabo de

manera concreta las labores necesarias para completar las actividades
planteadas dentro del plan de trabajo del proyecto. Es durante este proceso
que es vital mantener un control estricto alrededor de las actividades

realizadas, su alcance esperado y su cumplimiento real. Es debido a este perfil

de control que es necesario asumir, que la comunicacin de la gerencia del
proyecto con los lderes de equipo y entre los lderes mismos adquieren una
dimensin e importancia muy grandes. Una de las actividades principales que
se llevan a cabo durante este periodo es la verificacin y control constantes
del estado de las diferentes actividades productivas del proyecto. Esto
involucra no solo el control y revisin de lo que est pasando, sino la previsin,
verificacin y medicin de lo que podra pasar, bajo la forma de los
potenciales riesgos a los que est expuesto el proyecto, as como la toma de
decisiones necesaria en caso de que alguno de los riesgos llegue a convertirse
en una realidad que amenace la integridad y el buen ritmo del proyecto de
software. Esta toma de decisiones puede generar como consecuencia ajustes
a los planes iniciales, a la estructura formal de los equipos, distribuciones de
trabajo, e incluso renegociaciones con el cliente en torno a lo que se va a
entregar. Es importante no perder de vista que un acuerdo renegociado no es
un acuerdo roto, y que es preferible ajustar el rumbo de un proyecto y llevarlo
al xito por un camino que inicialmente no estaba contemplado, que hacerlo
fracasar por tratar de mantenerlo ciegamente en un rumbo que ya no es el
adecuado.

Finalizacin del proyecto. Durante esta fase del proyecto se termina el proceso
de trabajo, y se hacen las entregas correspondientes, evaluando y registrando
el desempeo final del equipo en trminos de cumplimiento y satisfaccin de
lo pronosticado. Es posible que en este momento los procesos de produccin
hayan finalizado y las personas involucradas con dichos procesos estn fuera
del proyecto, y solamente un grupo parcial est encargado de las actividades
de cierre. Es en este momento que se entrega oficialmente el producto
resultado del proceso al cliente, se obtiene su aprobacin y se realiza un
proceso de evaluacin del proceso general y sus resultados con el fin de
integrar el aprendizaje obtenido en los procesos generales de la compaa
para futuros proyectos de desarrollo.

Resulta evidente que si no se tuvo un proceso de comunicacin constante a lo

largo de todo el proceso, la gerencia del proyecto no tendr en este punto
una visin lo suficientemente clara como para evaluar de manera real y
precisa el desempeo general del proyecto. Tambin es claro que si no se
tomaron a tiempo las medidas necesarias, y teniendo en cuenta lo dinmico
de los procesos de desarrollo de software, en la mayor parte de los casos el
proceso de revisin reportara un fracaso. Sin embargo, y en cualquiera de los
casos, de lo que se trata es de incorporar dentro de la estructura general de
los procesos futuros las lecciones aprendidas a lo largo del proceso que acaba
de terminar.

Visto entonces un proyecto de software desde la perspectiva de todo lo que

se ha planteado, se espera que sea claro que los factores de xito estn
presentes no solo en aquellas actividades con un alto componente tcnico,

sino en aquellas actividades de soporte que permiten que las actividades

tcnicas se lleven a cabo de una manera adecuada. Dentro de los factores
no tcnicos que son ms relevantes para el xito de un proyecto de software
se encuentran:

UNA REPARTICIN CLARA DE ROLES. Es necesario que cada persona dentro del
equipo de trabajo, sin importar su perfil, nivel o grado de responsabilidad
tenga claro el rol que tiene asignado, y las responsabilidades del mismo. Esta
informacin debe ser permeada al resto del equipo, para que todos sean
conscientes no solo de su propio rol, sino del de sus compaeros.

UNA JERARQUA CLARA DE DEPENDENCIA. Entre los roles, en trminos de

autoridad, y en relacin con los productos de trabajo que deben ser
generados por unos y consumidos por otros. Esto garantiza un flujo claro y
limpio de delegacin de trabajo y de entregables generados.

UNA JERARQUA CLARA DE COMUNICACIN. Al interior de la compaa y hacia

el exterior, con el cliente; en lnea con el punto anterior, los canales de
comunicacin deben estar establecidos de manera que cada persona tenga
claridad respecto a con quin debe comunicarse alrededor de sus
responsabilidades. Debe as mismo existir un canal y un responsable de la
comunicacin hacia el exterior de la compaa, en trminos de entrega y
recoleccin de informacin a y desde el cliente.

UNA REPARTICIN CLARA DE LAS TAREAS A REALIZAR. Los roles deben tener
asignadas las tareas que deben realizar, con definiciones de alcance y
precedencia.

UNA ESTRUCTURA CLARA Y UNA DEFINICIN CONCRETA DE LOS ENTREGABLES.

Adicionalmente al conocimiento de a quin debe pasarse cada entregable
una vez sea terminado, es necesario tener claridad completa respecto a la
estructura y el contenido que dicho entregable debe tener.

UNA DEFINICIN TOTAL DE LOS MARCOS DE TIEMPO DENTRO DE LOS QUE SE

TRABAJAR. Esto incluye no solamente una visin general del tiempo del que
se dispone para finalizar el proyecto, sino la distribucin dentro de ese tiempo
de las fases, las actividades y los entregables a terminar en cada una de ellas.

UNA VISIN COMPARTIDA DEL PROYECTO, DEL PROCESO Y DEL PRODUCTO. Si

dentro del marco de un proyecto existen divergencias respecto a lo que el
proyecto significa para la compaa, si existen reservas respecto a la manera
como el proceso planteado va a permitir llevar a buen trmino dicho
proyecto, y si no hay consenso alrededor del producto que ser la
encarnacin final de la aplicacin del proceso en el maro del proyecto, no
hay oportunidad de tener xito. Una visin catalizada y comn es un requisito
fundamental para que los proyectos en general y los proyectos de software en
particular tengan xito.

Esta no pretende ser una lista exhaustiva de los requisitos y labores que deben
darse de manera paralela con las actividades de tipo tcnico dentro del
marco de un proyecto de software. Sin embargo, si se pretende dar una
imagen bastante clara de los aspectos adicionales que deben tenerse en
cuenta al abordar un proceso de ese estilo. En mdulos posteriores del proceso
de formacin se abordar de manera ms completa lo que se toc de
manera muy somera en esta lectura.

Para cerrar este documento, se desea hacer nfasis una vez ms en que solo
la completa y correcta interaccin entre los participantes de un proyecto de
software, mediada por la consciencia de que es necesario contemplar un
proceso de desarrollo como algo ms que un simple conjunto de labores
tcnicas interconectadas mediante un lenguaje formal comn, permite que se
lleven a cabo procesos serios, escalables, fciles de mantener, medibles y
exitosos de desarrollo. Desarrollar software no es una labor meramente tcnica,
sino que es un trabajo mediado, concertado y dirigido desde una perspectiva
organizacional mayor. Se requiere tener esta claridad si se espera aprovechar
todo el potencial que las iniciativas de desarrollo presentan en la actualidad.

BIBLIOGRAFA
BRUEGGE B., DUTOIT, A.(2003), Object-Oriented Software Engineering,
Prentice Hall,