UNIVERSIDAD PRIVADA TELESUP

90

UNIVERSIDAD PRIVADA TELESUP

Introduccin

a) Presentacin y contextualizacin:
En esta unidad usted aprender la importancia de las tcnicas y tecnologas
eficientes de la ingeniera de software para resolver mltiples problemas que se
derivan de las aplicaciones en donde se desarrollan sistemas de software de gran
tamao. Tendr en cuenta que cada proyecto de software presenta distintos
problemas en su desarrollo los cuales involucran a personas, equipo, usuarios del
software y ambiente de la aplicacin. Por esas razones, cada proyecto debe
resolver el problema de la produccin del software.

b) Competencia:
Gestiona los entregables de un proyecto de TI en el desarrollo del software.

c) Capacidades:
1. Aplica las tcnicas eficientes de la ingeniera de software para resolver
mltiples problemas en el desarrollo del software.
2. Conoce los principios bsicos de calendarizacin en la ingeniera de software
para resolver mltiples problemas en el desarrollo del sistema.
3. Distribuye los esfuerzos dentro de la calendarizacin de un proyecto para
definir y realizar un conjunto de tareas para un proyecto.
4. Identifica las tareas principales mediante la calendarizacin y elaboracin de
una red de tareas.

d) Actitudes:
Muestra una actitud emprendedora ante la calendarizacin de proyectos de
software.
Posee habilidad creativa para realizar proyectos de software.

e) Presentacin de Ideas bsicas y contenidos esenciales de la Unidad:

La Unidad de Aprendizaje 04: Calendarizacin de Proyectos de Software,
comprende el desarrollo de los siguientes temas:
TEMA 01: Introduccin a la Calendarizacin de Proyectos de Software.
TEMA 02: La Calendarizacin de Proyectos.
TEMA 03: Distribucin del Esfuerzo.
TEMA 04: Refinamiento de las Tareas Principales.

91

UNIVERSIDAD PRIVADA TELESUP

Introduccin
a la

TEMA 1

Calendarizacin
de

Proyectos de
Software
Competencia:
Aplicar las tcnicas eficientes de la ingeniera
de software para resolver mltiples
problemas en el desarrollo del software.

92

Desarrollo de los Temas

UNIVERSIDAD PRIVADA TELESUP

Tema 01: Introduccin a la Calendarizacin de

Proyectos de Software
A finales de los aos 60, un joven y brillante ingeniero fue
elegido para escribir un programa de computadora para
una aplicacin industrial automatizada. La razn por la cual
se eligi fue simple: era la nica persona en el grupo tcnico
que haba asistido a un seminario de programacin de
computadoras. l conoca las entradas y salidas del lenguaje ensamblador y de
FORTRAN, pero nada acerca de la ingeniera del software, e incluso menos acerca de
la calendarizacin y seguimiento de proyectos.

Su jefe le dio manuales apropiados y una descripcin verbal de lo que tena que hacer.
Se le inform que el proyecto deba terminarse en dos meses. El ingeniero ley los
manuales, consider su enfoque y comenz a escribir el cdigo. Despus de dos
semanas, el jefe lo llam a su oficina y le pregunt cmo iban las cosas. Realmente
bien dijo el joven ingeniero con entusiasmo juvenil. Esto fue mucho ms simple de lo
que pens. Probablemente he terminado cerca del 75 por ciento. El jefe sonri y
alent al joven ingeniero a seguir trabajando bien. Planearon reunirse de nuevo en una
semana.

Una semana despus, el jefe llamo al ingeniero a su

oficina y le pregunt Dnde estamos?. Todo
marcha bien, dijo el joven, pero me he encontrado
con algunos pequeos obstculos. Los solucionar y
regresar Cmo ves la fecha lmite?, pregunt el
jefe. No hay problema, dijo el ingeniero. Estoy
cerca de terminar el 90 por ciento. Si se ha trabajado en el mundo del software
durante unos cuantos aos se es capaz de terminar la historia. No ser sorpresa que
el joven ingeniero haya permanecido en el 90 por ciento durante todo el proyecto y
terminado (con ayuda de otros) un mes despus.

93

UNIVERSIDAD PRIVADA TELESUP

Esta historia se ha repetido decena de miles de veces con los desarrolladores de

software durante las pasadas cuatro dcadas. La gran pregunta es por qu.

Conceptos Bsicos
Aunque existen muchas razones por las cuales el software se entrega con retraso, la
mayora se encuadra en una o ms de las siguientes causas:

Una fecha lmite irrealizable establecida por alguien externo al grupo de

ingeniera del software e impuesta a los gestores profesionales del grupo.

Cambio en los requisitos del cliente que no se reflejan en modificaciones a la

calendarizacin.

Una subestimacin razonable de la cantidad de esfuerzo o de recursos que se

requerirn para realizar el trabajo.

Riesgos predecibles o impredecibles que no se consideraron cuando comenz el

proyecto.

Dificultades tcnicas que no pudieron preverse.

Dificultades humanas imprevisibles.

Falta de comunicacin entre el personal del proyecto. lo

que genera demoras.

Una falla en la gestin del proyecto porque no reconoci el retraso ni emprendi

una accin para corregir el problema.

Las fechas lmite muy audaces son un hecho de la vida en el

negocio del software. En tales ocasiones las fechas lmite se
demandan por razones legtimas, desde el punto de vista de la
persona que las establece. Pero el sentido comn establece que la
legitimidad tambin la deben advertir las personas que hacen el
trabajo. Napolen dijo alguna vez: Cualquier comandante en jefe
que pretenda llevar a cabo un plan que considera defectuoso comete un error; debe
exponer sus razones, insistir en que el plan debe cambiarse y finalmente presentar su
renuncia en lugar de ser el instrumento de la destruccin de su ejrcito. Estas son las
palabras fuertes que muchos gestores de proyectos de software deben considerar.

94

UNIVERSIDAD PRIVADA TELESUP

Las actividades de estimacin con frecuencia se implementan atendiendo la restriccin

de una fecha lmite definida. Si las mejores estimaciones indican que la fecha lmite es
irrealizable, un gestor de proyecto competente debe proteger a su equipo de la
presin excesiva [de la calendarizacin] [y] devolver la presin a quienes la originan.

Para ilustrarlo, supngase que a un equipo de ingeniera del software se la ha pedido

construir con controlador en tiempo real para un instrumento de diagnstico que ser
introducido al mercado en nueve meses. Despus de una estimacin y un anlisis de
riesgo cuidadoso, el gestor del proyecto llega a la conclusin de que el software, como
se solicit, requerir 14 meses para crearlo con el personal disponible. Cmo
procede el gestor del proyecto? Es irreal presentarse en la oficina del cliente (en este
caso el probable cliente es mercadotecnia-ventas) y
demandarle que cambie la fecha de entrega. Las presiones
externas del mercado han dictado la fecha, y el producto
debe liberarse. Es igualmente torpe rechazar el trabajo
(desde el punto de vista profesional). As que qu hacer?

En esta situacin se recomiendan los siguientes pasos:

1. Realizar una estimacin detallada empleando datos histricos de proyectos
previos. Determinar el esfuerzo y la duracin estimados para el proyecto.
2. Aplicar un modelo de proceso incremental y desarrollar una estrategia de
ingeniera de software que entregar la funcionalidad crtica en la fecha lmite
impuesta, pero demorar otra. Documente el plan.
3. Reunirse con el cliente y, con la estimacin detallada,
explicarle por qu la fecha lmite impuesta es
irrealizable. Asegrese de sealar que todas las
estimaciones estn basadas sobre el desempeo en
proyectos previos. Tambin asegrese de indicar el
porcentaje de mejora que se requerira para lograr
la fecha lmite vigente.

95

UNIVERSIDAD PRIVADA TELESUP

Son apropiados los siguientes comentarios:

Creo que podemos tener un problema con la fecha de entrega para el software
controlador XYZ. Le he dado a cada uno de ustedes un anlisis abreviado de las
tasas de produccin en proyectos previos y una estimacin que mechos hecho en
algunas formas diferentes. Notarn que he supuesto un 20 por ciento de mejora
respecto de ritmos de produccin precedentes, pero todava tenemos una fecha de
entrega que est a 14 meses en lugar de 9.

4. Ofrezca la estrategia de desarrollo incremental como alternativa:

Tenemos unas cuantas opciones y me gustara que tomase una decisin con
base en ellas. Primero, podemos aumentar el presupuesto y conseguir recursos
adicionales de modo que tendremos mucho xito en lograr que este trabajo est
hecho en nueve meses. Pero comprenda que esto aumentar el riesgo de una
calidad deficiente debido a la apretada fecha lmite.

Segundo, podemos remover varias de las funciones y capacidades de software

que est solicitando. Esto har que la versin preliminar del producto sea un poco
menos funcional, pero podemos anunciar toda la funcionalidad y luego entregarla
en el periodo de 14 meses. Tercero, podemos prescindir de la realidad y esperar
que el proyecto se complete en nueve meses. Terminaremos con nada que se
pueda entregar a un cliente. La tercera opcin, espero que est de acuerdo, es
inaceptable. La historia y nuestras mejores estimaciones indican que es irreal y un
boleto hacia el desastre.

Habr algunos gruidos, pero si se presentan estimaciones

slidas basadas en buenos datos histricos es probable
que se elijan versiones negociadas a las opciones 1 o 2.
La fecha lmite irreal se evapora.

96

UNIVERSIDAD PRIVADA TELESUP

La
TEMA 2
Calendarizacin
de Proyectos
Competencia:
Conocer
los
principios
bsicos
de
calendarizacin en la ingeniera de software
para resolver mltiples problemas en el
desarrollo del sistema.

97

UNIVERSIDAD PRIVADA TELESUP

Tema 02: La Calendarizacin de Proyectos

A Fred Brooks, el bien conocido autor de The Mythical Man-Month,
se le pregunt una vez cmo se retrasaban los proyectos de
software en la calendarizacin. Su respuesta fue tan simple como
profunda: Un da a la vez. La realidad de un proyecto tcnico (ya
sea que involucre la construccin de una planta hidroelctrica o el
desarrollo de un sistema operativo) es que cientos de pequeas
tareas deben realizarse para lograr una meta mayor. Algunas de
tales tareas estn fuera de la corriente principal y se pueden completar sin
preocuparse acerca de su impacto sobre la fecha de terminacin del proyecto. Otras
tareas se encuentran en la trayectoria crtica. Si estas tareas crticas se retrasan en
la calendarizacin, la fecha de terminacin del proyecto se pone en riesgo.

El objetivo del gestor es definir todas las tareas del proyecto, construir una red que
bosqueje sus interdependencias, identificar las tareas cruciales dentro de la red y
luego seguir su progreso para garantizar que la demora se reconoce un da a la vez.
Para lograrlo el gestor debe tener una calendarizacin que se haya definido en un
grado de resolucin que permita supervisar el progreso y controlar el proyecto.

La calendarizacin del proyecto de software es una

actividad que distribuye estimaciones de esfuerzo a travs
de la duracin planificada del proyecto al asignar el
esfuerzo a tareas especficas de ingeniera del software.
Sin embargo, es importante sealar que la calendarizacin
evoluciona a lo largo del tiempo. Durante las primeras etapas de la planificacin del
proyecto,

se

desarrolla

una

calendarizacin

macroscpica.

Este

tipo

de

calendarizacin identifica las principales actividades del marco de trabajo del proceso
y las funciones de producto a las que se aplican. Conforme el proyecto transcurre,
cada entrada en la calendarizacin macroscpica se refina en una calendarizacin
detallada. Aqu se identifican y calendarizan tareas especficas del software
(requeridas para completar una actividad).

98

UNIVERSIDAD PRIVADA TELESUP

La calendarizacin para proyectos de ingeniera del

software se puede ver desde dos perspectivas bien
diferentes. En la primera ya se ha establecido
(irrevocablemente) una fecha final para la liberacin de
un sistema basado en computadora. La organizacin
de software est restringida a distribuir esfuerzo dentro del marco temporal prescrito.
La segunda visin de la calendarizacin de software supone que se han comentado
lmites cronolgicos aproximados, pero que la fecha final la establece la organizacin
de ingeniera del software. El esfuerzo se distribuye para utilizar mejor los recursos y la
fecha final se define despus de un anlisis cuidadoso del software. Por desgracia, la
primera situacin se encuentra con mucha ms frecuencia que la segunda.

Principios Bsicos
Al igual que otras reas de ingeniera del software, varios principios bsicos guan la
calendarizacin de los proyectos.
Compartimentacin. El proyecto debe dividirse en compartimientos en varias
actividades, acciones y tareas manejables. Lograrlo requiere descomponer tanto el
producto como el proceso.
Interdependencia. Se debe determinar la interdependencia de
cada actividad, accin o tarea compartimentada. Algunas
tareas deben ocurrir en secuencia mientras que otras
pueden ocurrir en paralelo. Algunas acciones o actividades no pueden comenzar
mientras no est disponible el producto de trabajo producido por otros.

Otras asignaciones o actividades pueden ocurrir de manera independiente.

Asignacin de tiempo. A cada tarea por calendarizar se le debe
asignar cierto nmero de unidades de trabajo (por ejemplo,
personas-da esfuerzo). Adems, a cada tarea se le debe
asignar una fecha de inicio y otra de terminacin que sean
funcin de las interdependencias, y ya sea que el trabajo sea
realizado con base en tiempo completo o parcial.

99

UNIVERSIDAD PRIVADA TELESUP

Validacin del esfuerzo. Todo proyecto tiene un nmero definido de las

personas en el equipo de software. Conforme ocurre la asignacin de
tiempo, el gestor de proyecto debe asegurarse de que, en un tiempo
dado, no se han asignado ms que el nmero de personas
calendarizadas. Por ejemplo, considere un proyecto que tiene tres
ingenieros de software asignados (por ejemplo, tres personas-da estn disponibles
por da de esfuerzo asignado). En un da dado se deben completar siete tareas al
mismo tiempo. Cada una requiere 0.50 personas-da de esfuerzo. Se ha asignado ms
esfuerzo que el nmero de personas para hacer el trabajo.

Definicin de responsabilidades. Toda tarea calendarizada se le debe asignar a un

miembro especfico del equipo.
Definicin de resultados. Toda tarea calendarizada debe tener un resultado definido.
En proyectos de software el resultado normalmente es un producto de trabajo (por
ejemplo, el diseo del mdulo) o una parte de l. Los productos de trabajo usualmente
se combinan en los entregables.

Definicin de hitos. Cualquier tarea o grupo de tareas debe estar asociado con un
hito del proyecto. Un hito se logra cuando se ha revisado la calidad de uno o ms
productos de trabajo y se han aprobado.
Cada uno de estos principios se aplica conforme evoluciona la calendarizacin del
proyecto.
Relacin entre el personal y el esfuerzo
En un pequeo proyecto de desarrollo de software una
sola persona puede analizar los requisitos, realizar el
diseo, generar el cdigo y dirigir las pruebas.
Conforme aumenta el tamao de un proyecto, ms
gente resulta involucrada. (Rara vez que se puede
dar el lujo de acometer un esfuerzo de 10 personasao con una persona que trabaje durante 10 aos!).

100

UNIVERSIDAD PRIVADA TELESUP

Existe un mito comn que todava creen muchos gestores responsables del esfuerzo
del desarrollo del software: Si nos retrasamos en la calendarizacin, siempre
podemos incorporar ms programadores y recuperarnos ms adelante en el proyecto.
Desgraciadamente, agregar ms personas en etapas tardas de un proyecto con
frecuencia tiene un efecto perturbador sobre ste, lo que provoca que la
calendarizacin se desfase an ms. Las personas que se agregan deben aprender el
sistema y la gente que se les ensea es la misma que estaba haciendo el trabajo.
Durante la enseanza no se realiza trabajo y el proyecto experimenta mayores
retrasos.

Adems el tiempo que tarda aprender el sistema, ms personal aumenta el nmero de

rutas de comunicacin y la complejidad de sta a lo largo de un proyecto. Aunque le
comunicacin es absolutamente esencial para el xito del desarrollo de software, cada
nueva ruta de comunicacin requiere un esfuerzo adicional y, por lo tanto, tiempo
suplementario. A lo largo de los aos, los datos empricos y el anlisis terico han
demostrado que las calendarizaciones de proyecto son elsticas. Es decir, es posible
comprimir en cierta medida la fecha de terminacin (al reducir el nmero de recursos).

La Curva Putnam-Norden-Rayleigh (PNR) proporciona un indicio de la relacin entre el

esfuerzo aplicado y el tiempo de entrega para un proyecto de software. En el siguiente
grfico se muestra una versin de la curva, que representa el esfuerzo del proyecto
como funcin del tiempo de entrega. La curva indica un valor mnimo, t0, que indica el
tiempo de entrega de menor costo (es decir, el tiempo de entrega que generar el
menor gasto de esfuerzo). Conforme se mueve a la izquierda de t0 (es decir, conforme
intenta acelerar la entrega), la curva se eleva en forma no lineal.

101

UNIVERSIDAD PRIVADA TELESUP

Como ejemplo, supngase que un equipo de proyecto ha estimado un nivel de

esfuerzo Ea que se requerir para lograr un tiempo de entrega nominal, td, que es
ptimo en trminos de calendarizacin y recursos disponibles. Aunque es posible
acelerar la entrega, la curva se eleva muy pronunciadamente hacia la izquierda de td.
De hecho, la curva PNR indica que el tiempo de entrega del proyecto no se puede
comprimir ms all de 0.75 td. Si se intenta una mayor compresin, el proyecto se
mueve hacia la regin imposible y el riesgo de fracaso se eleva mucho. La curva
PNR tambin indica que la opcin de entrega de menor costo, to = 2td. La implicacin
aqu es que la demora en la entrega del proyecto puede reducir los costos
significativamente. Desde luego, esto debe superarse frente al costo del negocio
asociado con la demora.

La ecuacin del software, se obtiene de la curva PNR y demuestra la relacin

enormemente lineal entre el tiempo cronolgico para completar un proyecto y el
esfuerzo humano aplicado a ste. El nmero de lneas de cdigo entregadas
(enunciados fuente), L, se relaciona con el esfuerzo y el tiempo de desarrollo mediante
la ecuacin: L = P x E1/3t4/3 donde E es el esfuerzo de desarollo en personas-mes; P,
un parmetro de productividad que refleja una diversidad de factores que conducen a
trabajo de ingeniera del software de alta calidad (los valores tpicos de P varan entre
2 000 y 12 000); y t , la duracin el proyecto en meses calendario. Al reordenar esta
ecuacin del software se puede llegar a una expresin para el esfuerzo de desarrollo
E: E = E3 / ( P3t4 ) donde E es el esfuerzo utilizado (en personas-ao) durante el ciclo
de vida para el desarrollo y mantenimiento de software, y t es el tiempo de desarrollo
en aos. La ecuacin para el esfuerzo de desarrollo se puede relacionar con el costo
del desarrollo al incluir un factor de escala salarial (costo/persona-ao).
Esto conduce a unos resultados interesantes. Considrese un complejo proyecto de
software de tiempo real estimado en 33 000 LDC, 12 personas-ao de esfuerzo. Si se
asignan ocho personas al equipo del proyecto, ste se puede completar en
aproximadamente 1.3 aos. Sin embargo si se extiende la fecha final a 1.75 aos, la
naturaleza enorme no lineal del modelo produce: E = L3 / ( P3t4 ) ~ 3.8 personas-ao
Esto implica que, al extender la fecha final seis meses, se puede reducir el nmero de
personas de ocho a cuatro! La validez de tales resultados est abierta al debate, pero
la implicacin es clara: se pueden obtener beneficios al emplear menos personal
durante un periodo un poco ms largo para lograr el mismo objetivo.

102

UNIVERSIDAD PRIVADA TELESUP

Distribucin

TEMA 3

del

Esfuerzo
Competencia:
Distribuir los esfuerzos dentro de la
calendarizacin de un proyecto para definir y
realizar un conjunto de tareas para un
proyecto.

103

UNIVERSIDAD PRIVADA TELESUP

Tema 03: Distribucin del Esfuerzo

Cada una de las tcnicas de estimacin de proyectos de
software estudiadas conduce a estimaciones de unidades de
trabajo (por ejemplo, las personas-mes) requeridas para
completar

el

desarrollo

del

software.

Una

distribucin

recomendada del esfuerzo a travs del proceso de software con

frecuencia se conoce como la regla 40-20-40. Cuarenta por ciento de todos los
esfuerzos se asignan al anlisis y el diseo de sistemas de entrada. Un porcentaje
similar se aplica en poner a prueba los sistemas de salida. Usted puede inferir
correctamente que la codificacin (20 por ciento del esfuerzo) no tiene tanto nfasis.

Esta distribucin del esfuerzo se debe usar solamente como gua. Las caractersticas
de cada proyecto deben dictar la distribucin del esfuerzo. El trabajo realizado en la
planeacin del proyecto rara vez explica ms de 2-3 por ciento del esfuerzo a menos
que el plan comprometa a una organizacin a grandes gastos con alto riesgo. Los
anlisis de requisitos pueden comprometer 10-25 por ciento del esfuerzo del proyecto.
El esfuerzo empleado en el anlisis o elaboracin de prototipos debe aumentar en
proporcin directa con el tamao y la complejidad de un proyecto. Un intervalo del 20
al 25 por ciento de esfuerzo normalmente se aplica al diseo de software. Tambin se
debe considerar el tiempo utilizado en la revisin del diseo y la subsiguiente iteracin.

Debido al esfuerzo aplicado al diseo de software, el cdigo

debe seguir con relativamente poca dificultad. Se puede
lograr un rango de 15-20 por ciento del esfuerzo global. Las
pruebas y la subsiguiente depuracin explican el 30-40 por
ciento del esfuerzo de desarrollo del software. El carcter
crucial del software con frecuencia dicta la cantidad de
pruebas que se requieren. Si el software se clasifica desde el
punto de vista humano (es decir, la falla del software puede resultar en prdida de
vidas), son usuales porcentajes todava ms altos.

104

UNIVERSIDAD PRIVADA TELESUP

Definicin de un conjunto de tareas para el proyecto de software

Ningn conjunto de tareas es apropiado por s slo para
todos los proyectos. El conjunto de tareas que sera
apropiado

para

probablemente

un
se

sistema

complejo

apreciara

como

grande

demasiado

destructivo para un producto de software pequeo y

relativamente simple. En consecuencia, un proceso de
software eficaz debe definir una coleccin de conjunto de tareas, cada una diseada
para satisfacer las necesidades de diferentes tipos de proyectos.

Un conjunto de tareas es una coleccin de tareas de trabajo de ingeniera del

software, hitos y productos de trabajo que se deben terminar para completar un
proyecto particular. El conjunto de tareas debe proporcionar suficiente disciplina para
lograr alta calidad de software. Pero, al mismo tiempo, no debe abrumar al equipo de
proyecto con trabajo innecesario. En el desarrollo de una calendarizacin el proyecto
requiere distribuir un conjunto de tareas a lo largo de la lnea de tiempo del proyecto.
El conjunto de tareas variar segn el tipo de proyecto y el grado de rigor con el que
equipo de software decide realizar su trabajo.

Aunque es difcil desarrollar una taxonoma completa de tipos de proyecto de software,

en la mayora de las organizaciones del ramo se encuentran los siguientes proyectos:
1. Proyectos de desarrollo del concepto, los
cuales

se

inician

para

explorar

algunas

aplicaciones o conceptos de negocio de alguna

nueva tecnologa.
2. Proyectos

de

desarrollo

de

nuevas

aplicaciones, los cuales se llevan a cabo como consecuencia de una solicitud

especfica del cliente.
3. Proyectos de mejora de la aplicacin, stos ocurren cuando el software
existente experimenta grande modificaciones en la funcin, el desempeo o las
interfaces visibles para el usuario final.

105

UNIVERSIDAD PRIVADA TELESUP

4. Proyectos de mantenimiento de aplicacin, los cuales corrigen, adaptan o

extienden el software existente en formas que no sean obvias inmediatamente
para el usuario final.
5. Proyectos de reingeniera, stos se llevan a cabo con la finalidad de
reconstruir un sistema existente (heredado), en todo o en parte.

Incluso dentro de un solo tipo de proyecto, muchos factores

influyen en la eleccin del conjunto de tareas. Por ejemplo:
tamao del proyecto, nmero de usuarios potenciales, lo
crucial de la misin, duracin de la aplicacin estabilidad de
los requisitos, facilidad de comunicacin con el usuario o
desarrollador, madurez de la tecnologa aplicable, restricciones del desempeo,
caractersticas anidadas y no anidadas, el equipo del proyecto y factores de
reingeniera. Cuando se consideran en conjunto, estos factores ofrecen un indicio el
grado de rigor que se debe aplicar al proceso de software.

Ejemplo de conjunto de tareas

Cada uno de los tipos de proyecto descritos puede
abordarse
secuencial,

mediante un modelo de proceso lineal,

iterativo

(por

ejemplo,

los

modelos

de

elaboracin de prototipo o incrementales) o evolutivo (por

ejemplo, el modelo espiral). En algunos casos un tipo de
proyecto fluye suavemente hacia el siguiente. Por ejemplo,
los proyectos de desarrollo de las nuevas aplicaciones.
Cuando termina un proyecto de desarrollo de nuevas aplicaciones, en ocasiones
comienza un proyecto de mejora de la aplicacin. Esta progresin es tanto natural
como predecible y ocurrir sin importar el modelo de proceso que adopte la
organizacin. En consecuencia, las principales tareas de ingeniera del software son
aplicables a todos los flujos de modelo de proceso.

106

UNIVERSIDAD PRIVADA TELESUP

Como, ejemplo, considrese las tareas de ingeniera del software para un proyecto de
desarrollo del concepto. Los proyectos de desarrollo del concepto se inician cuando se
debe explotar el potencial para alguna nueva tecnologa. No existe certeza de que la
tecnologa ser aplicable, pero un cliente (por ejemplo, marketing) cree que existen
beneficios potenciales.

Los proyectos de desarrollo del concepto se enfocan en aplicar las siguientes tareas
principales:
1.1 La determinacin del mbito del concepto precisa el mbito global del
proyecto.
1.2 La planeacin preliminar del concepto establece la
habilidad de la organizacin para acometer el
trabajo que entraa el mbito del proyecto.
1.3 La valoracin del riesgo de la tecnologa
evala el riesgo asociado con la tecnologa que se
implementar como parte del mbito del proyecto.
1.4 La prueba del concepto demuestra la vialidad de
una nueva tecnologa en el contexto del software.

1.5 La implementacin del concepto pone en prctica la representacin del

concepto en una forma que pueda revisarla un cliente y se utiliza para
propsitos de mercadotecnia cuando se deben vender un concepto a otros
clientes o gestores.
1.6 La reaccin del cliente al concepto solicita realimentacin acerca de un
concepto de nueva tecnologa y se dirige a aplicaciones especficas de los
clientes.

Una rpida exploracin de estas tareas debe producir pocas sorpresas. De hecho, el
flujo de ingeniera de software para los proyectos de desarrollo del concepto (y
tambin para que todos los otros tipos de proyectos) es poco ms que sentido comn.

107

UNIVERSIDAD PRIVADA TELESUP

Refinamiento
de las

TEMA 4

Tareas
Principales
Competencia:
Identificar las tareas principales mediante la
calendarizacin y elaboracin de una red de
tareas.

108

UNIVERSIDAD PRIVADA TELESUP

Tema 04: Refinamiento de las Tareas

Principales
Las tareas principales se pueden utilizar para definir la
calendarizacin macroscpica de un proyecto. Sin
embargo, esta calendarizacin se debe refinar para
crear una calendarizacin detallada del proyecto. El
refinamiento comienza al tomar cada tarea principal y
descomponerla en un conjunto de subtareas (con
productos de bajo trabajo e hitos relacionados).

Como ejemplo de descomposicin de tarea,

consideremos el siguiente la siguiente tarea,
determinacin del mbito del concepto. El
refinamiento de una tarea se puede lograr
empleando un bosquejo de formato, pero en este
libro se aplica un enfoque de lenguaje en el
diseo del proceso para ilustrar el flujo de la
actividad de determinacin del mbito del concepto.

Definicin tarea: Tarea 1.1 Determinacin del mbito del concepto

1.1.1

Identificar necesidades, beneficios y clientes potenciales;

1.1.2

Definir eventos de salida/control y entrada deseados que impulsen la

aplicacin;

Comienza Tarea 1.1.2

1.1.2.1 RTF: Revisar la descripcin escrita de la necesidad;
1.1.2.2 Derivar una lista de salidas/entradas visibles al cliente;
1.1.2.3 RTF: Revisar salidas/entradas con el cliente y modificar conforme se
requiera;
Fin de tarea 1.1.2

109

UNIVERSIDAD PRIVADA TELESUP

1.1.3 Definir la funcionalidad/comportamiento para cada funcin principal;

Co
1.1.3.1 RTF: Revisar los objetos de datos de salida y entrada derivados en la
tarea 1.1.2;
1.1.3.2 Derivar un modelo funciones/comportamientos;
1.1.3.3 RTF: Revisar funciones/comportamientos con el cliente y modificar
conforme se requiera;
Fin de tarea 1.1.3

1.1.4 Aislar aquellos elementos de la tecnologa que se implementar en el software;

1.1.5 Disponibilidad de investigacin del software existente;
1.1.6 Definir factibilidad tcnica;
1.1.7 Realizar estimacin rpida del tamao;
1.1.8 Crear una Definicin del mbito;
Fin de tarea 1.1
Las tareas y subtareas anotadas en el proceso de
refinamiento el lenguaje de diseo forman la base de una planeacin detallada de la
actividad de determinar el mbito del concepto.

Definicin de Una Red de Tareas

Las tareas y subtareas individuales tienen
interdependencias basadas en su secuencia.
Adems, cuando ms de una persona est
involucrada en un proyecto de ingeniera del
software, es probable que las actividades y
tareas de desarrollo se realicen en paralelo.
Cuando esto ocurre, las tareas concurrentes deben estar coordinadas de modo que se
completarn cuando las tareas posteriores requieran sus productos de trabajo.

110

UNIVERSIDAD PRIVADA TELESUP

Una red de tareas, tambin denominada red de actividad, es una representacin

grfica del flujo de tareas en un proyecto. En ocasiones se utiliza como el mecanismo
mediante el cual la secuencia y dependencias de tareas son la entrada de una
herramienta automatizada de calendarizacin del proyecto. En su forma ms simple
(empleada cuando se crea una calendarizacin macroscpica), la red de tareas
muestra las principales tareas de la ingeniera del software. La siguiente figura
muestra una red de tareas esquemtica para un proyecto e desarrollo del concepto.

La

naturaleza

concurrente

de

las

actividades

de

ingeniera de software conduce a varios requisitos

importantes de la calendarizacin. Puesto que las tareas
paralelas ocurren de manera asncrona, el planificador
debe determinar dependencias intertareas para asegurar
el progreso continuo hacia la finalizacin.

Adems, el gestor del proyecto debe estar atento a las tareas que se encuentran en la
ruta crtica. Esto es, las tareas se deben completar en la calendarizacin si el
proyecto como un todo se debe completar a tiempo. Es importante notar que la red de
tareas mostrada es macroscpica. En la red de tareas detallada (un precursor de la
calendarizacin detallada) cada actividad que muestra la figura se debe expandir.

111

UNIVERSIDAD PRIVADA TELESUP

Calendarizacin
La calendarizacin de un proyecto de software no difiere enormemente de la de
cualquier esfuerzo de ingeniera multitarea. En consecuencia, las tcnicas y
herramientas generalizadas de calendarizacin de proyecto se pueden aplicar, poco
modificadas, en proyectos de software. La tcnica de evaluacin y revisin de
programa (PERT, por sus siglas en ingls) y el mtodo de ruta crtica (CPM, por sus
siglas en ingls) son dos mtodos de calendarizacin de proyecto que se pueden
aplicar al desarrollo de software.

Ambas tcnicas reciben impulso de la informacin ya desarrollada en actividades

tempranas de la planeacin del proyecto:

Estimacin del esfuerzo.

Descomposicin de la funcin del producto.

Seleccin del modelo de proceso y conjunto de tareas apropiadas.

Descomposicin de tareas.

Las interdependencias entre las tareas se pueden definir empleando una red de
tareas. Las tareas, en ocasiones llamadas la estructura del trabajo (EAT, por sus
siglas en ingls), se definen para el producto como un todo o para funciones
individuales.

Tanto PERT como CPM ofrecen herramientas cuantitativas

que permiten al planificador de software 1) determinar
la trayectoria crtica: La cadena de tareas que
determinan la duracin del proyecto; 2) establecer las
estimaciones de tiempo ms probables para tareas
individuales al aplicar modelos estadsticos; y 3)
calcular los tiempo lmite que definen una ventana de
tiempo para una tarea particular.

112