Sei sulla pagina 1di 29

GESTIN DE PROYECTOS DE

DESARROLLO DE SOFTWARE

UNIVERSIDAD DE
CARTAGENA
2013
PREGUNTAS INICIALES
Qu es el software?
Cules son los pasos para construirlo?
Qu se requiere para construirlo?
Quines participan en la construccin del
software?
Qu modelos de desarrollo de software
conoce?
Qu es la gestin de procesos de software?
GESTIN DE PROYECTOS DE
DESARROLLO DE SOFTWARE
La gestin y planificacin de proyectos es una
actividad que empieza antes de iniciar cualquier
actividad tcnica y contina a lo largo de la
definicin, del desarrollo y del mantenimiento del
software. La gestin del proyecto de software es el
primer nivel del proceso de ingeniera de software,
porque cubre todo el proceso de desarrollo. Para
conseguir un proyecto de software fructfero se
debe comprender el mbito del trabajo a realizar,
los riesgos en los que se puede incurrir, los recursos
requeridos, las tareas a llevar a cabo, el esfuerzo
(costo) a consumir y el plan a seguir.
1. EL SOFTWARE COMO PRODUCTO
El software de computadora es el producto que
disean y construyen los Ingenieros de Software
y virtualmente cualquier persona en el mundo
industrializado lo utiliza bien directa o
indirectamente. Esto abarca los programas que
se ejecutan dentro de una computadora de
cualquier tamao y arquitectura, documentos
que comprenden formularios virtuales e
impresos y datos que combinan nmeros y
texto y tambin incluyen representaciones de
informacin de audio, video e imgenes.
1.1 CULES SON LOS PASOS PARA
CONSTRUIRLO?
Construimos Software de computadora aplicando un proceso
que conduce a un resultado de alta calidad que satisface las
necesidades de la gente que usar el producto. Existen cuatro
actividades fundamentales que son comunes para todos los
procesos del software:
Especificacin, donde los clientes e ingenieros definen el
software a producir y las restricciones sobre su operacin.
Desarrollo, donde el software se disea y programa.
Validacin, donde el software se vlida para asegurar que es
lo que el cliente requiere.
Evolucin, donde el software se modifica para adaptarlo a los
cambios requeridos por el cliente y el mercado.

2. EL SOFTWARE COMO PROCESO
HOWARD Baetjer, Jr. [BAE98], comenta sobre el
proceso: Como el software, al igual que el capital,
es el conocimiento incorporado, y puesto que el
conocimiento est inicialmente disperso, el
desarrollo del software implcito, latente e
incompleto en gran medida, es un proceso social de
aprendizaje. El proceso es un dilogo en el que se
rene el conocimiento y se incluye en el software
para convertirse en software.
El proceso proporciona una interaccin entre los
usuarios y los diseadores, entre los usuarios y las
herramientas de desarrollo, y entre los diseadores y
las herramientas de desarrollo [tecnologa]. En este
proceso la herramienta de desarrollo se usa como
medio de comunicacin.

Realmente, construir software de computadora es un
proceso de aprendizaje iterativo, y el resultado, algo
que Baetjer podra llamar capital del software, es el
conjunto del software reunido, depurado y organizado
mientras se desarrolla el Proceso. Con cada iteracin
se obtiene mayor conocimiento de las personas
involucradas.



Qu es realmente el proceso de Software? Son una
serie de pasos predecibles -un mapa de carreteras que
ayuda a obtener el resultado oportuno de calidad-.

Cules son los pasos? A un nivel detallado, el
proceso que adoptemos depende del software que
estamos construyendo. Un proceso puede ser
apropiado para crear software de un sistema de
aviacin, mientras que un proceso diferente por
completo puede ser adecuado para la creacin de un
sitio web.

Cul es el producto obtenido? Desde el punto de
vista de un ingeniero de software, los productos
obtenidos son programas, documentos y datos que se
producen como consecuencia de las actividades de
ingeniera del software definidas por el proceso.
Cmo puedo estar seguro de que lo he hecho
correctamente? Hay una cantidad de mecanismos
de evaluacin del proceso del software que
permiten a las organizaciones determinar la madurez
del proceso del software. Sin embargo, la calidad,
oportunidad y viabilidad a largo plazo del producto
que est construyendo son los mejores indicadores
de la eficiencia del proceso que estamos utilizando.

Qu es exactamente el proceso del software desde
un punto de vista tcnico? Definimos un proceso de
software como un marco de trabajo de las tareas
que se requieren para construir software de alta
calidad.
3. GESTIN DE UN PROCESO DE SW
La Gestin de un Proyecto involucra la planificacin,
supervisin y control del personal, del proceso y los
eventos que ocurren mientras el Software evoluciona
desde una idea preliminar hasta una implementacin
operativa.

Quin lo hace? Todos gestionamos de algn modo,
pero el mbito de las actividades de gestin vara en
funcin a la persona que las realiza. Un Ingeniero de
Software gestiona sus actividades diarias; planifica,
supervisa y controla labores tcnicas. Los Gestores del
Proyecto planifican, supervisan y controlan el trabajo
del equipo de Ingenieros de Software. Los gestores
expertos coordinan la relacin entre el negocio y los
profesionales del software.
La gestin eficaz de un proyecto de software se
centra en las cuatro Ps: personal, producto,
proceso y proyecto. El orden no es arbitrario. El
gestor que se olvida de que el trabajo de ingeniera
del software es un esfuerzo humano intenso nunca
tendr xito en la gestin de proyectos. Un gestor
que no fomenta una minuciosa comunicacin con
el cliente al principio de la evolucin del proyecto
se arriesga a construir una elegante solucin para
un problema equivocado. El administrador que
presta poca atencin al proceso corre el riesgo de
arrojar mtodos tcnicos y herramientas eficaces al
vaco. El gestor que emprende un
proyecto sin un plan slido arriesga el xito del
producto.
3.1 EL PERSONAL
El proceso del software lo componen participantes que
pueden clasificarse en una de estas cinco categoras:
Gestores superiores, que definen los aspectos de
negocios que a menudo tienen una significativa
influencia en el proyecto.
Gestores tcnicos, que deben planificar, motivar,
organizar y controlar a los profesionales que realizan el
trabajo de software.
Profesionales, que proporcionan las capacidades
tcnicas necesarias para la ingeniera de un producto
o aplicacin.
Clientes, que especifican los requisitos para la
ingeniera 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 produccin.
3.1.1 EL EQUIPO DE TRABAJO
Mantei [MAN81] sugiere tres organigramas de
equipo genricos:

Descentralizado democrtico (DD). Este equipo
de ingeniera del software no tiene un jefe
permanente. Ms bien, se nombran
coordinadores de tareas a corto plazo y se
sustituyen por otros para diferentes tareas. Las
decisiones sobre problemas y los enfoques se
hacen por consenso del grupo. La
comunicacin entre los miembros del equipo es
horizontal.
Descentralizado controlado (DC). Este equipo de
ingeniera del software tiene un jefe definido que
coordina tareas especficas y jefes secundarios
que tienen responsabilidades sobre subtareas. La
resolucin de problemas sigue siendo una
actividad del grupo, pero la implementacin de
soluciones se reparte entre subgrupos por el jefe
de equipo. La comunicacin entre subgrupos e
individuos es horizontal. Tambin hay
comunicacin vertical a lo largo de la jerarqua de
control.

Centralizado controlado (CC). El jefe del equipo se
encarga de la resolucin de problemas a alto nivel
y la coordinacin interna del equipo. La
comunicacin entre el jefe y los miembros del
equipo es vertical.
3.2 EL PRODUCTO
Antes de poder planificar un proyecto, se
deberan establecer los objetivos y el mbito
del producto, se deberan considerar soluciones
alternativas e identificar las dificultades tcnicas
y de gestin. Sin esta informacin, es imposible
definir unas estimaciones razonables y exactas
del coste; una valoracin efectiva del riesgo,
una subdivisin realista de las tareas del
proyecto o una planificacin del proyecto
asequible que proporcione una indicacin
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 ingeniera
del sistema o del negocio y contina como el
primer paso en el anlisis de los requisitos del
software. Los objetivos identifican las metas
generales del proyecto sin considerar cmo se
conseguirn (desde el punto de vista del
cliente). El mbito identifica los datos primarios,
funciones y comportamientos que caracterizan
al producto, y, ms importante, intenta abordar
estas caractersticas de una manera
cuantitativa. Una vez que se han entendido los
objetivos y el mbito del producto, se
consideran soluciones alternativas.
3.2.1 Determinar el mbito del SW
La primera actividad de gestin de un proyecto de
software es determinar el mbito del software. El
mbito se define respondiendo a las siguientes
cuestiones:
CONTEXTO. Cmo encaja el software a construir
en un sistema, producto o contexto de negocios
mayor y qu limitaciones se imponen como
resultado del contexto?

OBJETIVOS DE INFORMACIN. Qu objetos de
datos visibles al cliente se obtienen del software?
Qu objetos de datos son requeridos de
entrada?
FUNCIN Y RENDIMIENTO. Qu funcin realiza el
software para transformar la informacin de entrada
en una salida? Hay caractersticas de rendimiento
especiales que abordar?. El mbito de un proyecto
de software debe ser unvoco y entendible a niveles
de gestin y tcnico. Los enunciados del mbito del
software deben estar delimitados, es decir, los datos
cuantitativos (por ejemplo: nmero de usuarios
simultneos, tamao de la lista de correo, mximo
tiempo de respuesta permitido) se establecen
explcitamente; se anotan las limitaciones (por
ejemplo: el coste del producto limita el tamao de la
memoria) y se describen los factores de reduccin de
riesgos (por ejemplo: los algoritmos deseados se
entienden muy bien si estn disponibles en C++).
3.2.2 Descomposicin del problema
La descomposicin del problema es una actividad
que se asienta en el ncleo del anlisis de requisitos
del software. La descomposicin se aplica en dos
reas principales: (1) la funcionalidad que debe
entregarse y (2) el proceso que se emplear para
entregarlo.
Los seres humanos tienden a aplicar la estrategia de
divide y vencers cuando se enfrentan a problemas
complejos. Dicho de manera sencilla, un problema
complejo se parte en problemas ms pequeos que
resultan ms manejables. sta es la estrategia que
se aplica al inicio de la planificacin del proyecto.

3.3 EL PROCESO
Un proceso de software proporciona la
estructura desde la que se puede establecer un
detallado plan para el desarrollo del software.
Un pequeo nmero de actividades
estructurales se puede aplicar a todos los
proyectos de software, sin tener en cuenta su
tamao o complejidad. Diferentes conjuntos de
tareas, hitos, productos del trabajo y puntos de
garanta de calidad permiten a las actividades
estructurales adaptarse a las caractersticas del
proyecto de software y a los requisitos del
equipo del proyecto. Finalmente, las
actividades protectoras -tales como garanta de
calidad del software, gestin de la
configuracin del software y medicin- cubren
el modelo de proceso.
Las fases genricas que caracterizan el proceso
de software definicin, desarrollo y soporte- son
aplicables a todo software. El problema es
seleccionar el modelo de proceso apropiado
para la ingeniera del software que debe aplicar
el equipo del proyecto.

Existe una gran gama de paradigmas de
ingeniera del software entorno a esto: el modelo
secuencial lineal, por prototipos, modelo DRA,
incremental, en espiral, basado en componentes,
el modelo de desarrollo concurrente, el modelo
de mtodos formales, el modelo de tcnicas de
cuarta generacin, etc.
El gestor del proyecto debe decidir qu modelo de
proceso es el ms adecuado para (1) los clientes
que han solicitado el producto y la gente que
realizar el trabajo; (2) las caractersticas 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 descomposicin del proceso. Es decir,
se debe crear un plan completo reflejando las
tareas requeridas a las personas para cubrir las
actividades estructurales.
3.4 EL PROYECTO
Para evitar el fracaso del proyecto, el gestor de
proyectos y los ingenieros de software que lo
construyeron deben eludir un conjunto de seales de
peligro comunes; comprender los factores del xito
crticos que conducen a la gestin correcta del
proyecto y desarrollar un enfoque de sentido comn
para planificar, supervisar y controlar el proyecto.

Para gestionar un proyecto de software con xito,
debemos comprender qu puede ir mal (para evitar
esos problemas) y cmo hacerlo bien.
John Reel [REE99] define diez seales que indican
que un proyecto de sistemas de informacin est
en peligro:

1. La gente del software no comprende las
necesidades de los clientes.
2. El mbito del producto est definido
pobremente.
3. Los cambios estn mal realizados.
4. La tecnologa elegida cambia.
5. Las necesidades del negocio cambian [o
estn mal definidas].

6. Las fechas de entrega no son realistas.
7. Los usuarios se resisten.
8. Se pierden los patrocinadores [o nunca se
obtuvieron adecuadamente].
9. El equipo del proyecto carece del personal
con las habilidades apropiadas.
10.Los gestores [y los desarrolladores] evitan
buenas prcticas y sabias lecciones.
CMO ACTUAR PARA EVITAR PROBLEMAS?
Reel [REE99] sugiere una aproximacin de sentido
comn a los proyectos de software dividida en
cinco partes:
Empezar con el pie derecho. Esto se realiza
trabajando duro para comprender el problema
a solucionar y estableciendo entonces objetivos
y expectativas realistas para cualquiera que
vaya a estar involucrado en el proyecto. Se
refuerza construyendo el equipo adecuado y
dando al equipo la autonoma, autoridad y
tecnologa necesaria para realizar el trabajo.

Mantenerse. Muchos proyectos no realizan un
buen comienzo y entonces se desintegran
lentamente. Para mantenerse, el gestor del
proyecto debe proporcionar incentivos para
conseguir una rotacin del personal mnima,
el equipo debera destacar la calidad en
todas las tareas que desarrolle y los gestores
veteranos deberan hacer todo lo posible por
permanecer fuera de la forma de trabajo del
equipo.
Seguimiento del Progreso. Para un proyecto de
software, el progreso se sigue mientras se realizan los
productos del trabajo (por ejemplo, especificaciones,
cdigo fuente, conjuntos de casos de prueba) y se
aprueban (utilizando revisiones tcnicas formales)
como parte de una actividad de garanta de calidad.

Tomar Decisiones Inteligentes. Las decisiones del gestor
del proyecto y del equipo de software deberan seguir
siendo sencillas. Siempre que sea posible, utilice
software del mismo comercial o componentes de
software existentes; evite personalizar interfaces cuando
estn disponibles aproximaciones estndar; identifique
y elimine entonces riesgos obvios; asigne ms tiempo
del que pensaba necesitar para tareas arriesgadas o
complejas.


Realizar un Anlisis Postmortem (despus de
finalizar el proyecto). Establecer un mecanismo
consistente para extraer sabias lecciones de
cada proyecto. Evaluar la planificacin real y
la prevista, reunir y analizar mtricas del
proyecto de software y realimentar con datos
de los miembros del equipo y de los clientes, y
guardar los datos obtenidos en formato escrito.

Potrebbero piacerti anche