py. ii int. u1. u4

UNIVERSIDAD PRIVADA TELESUP

90


91

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.


92

TEMA 1

Competencia:

Introduccin a la

Calendarizacin de Proyectos de

Software

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


93

Desarrollo de los Temas

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.


94

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.


95

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.


96

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.


97

TEMA 2

Competencia:

La

Calendarizacin

de Proyectos

Conocer los principios bsicos de calendarizacin en la ingeniera de software para resolver mltiples problemas en el desarrollo del sistema.


98

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).


99

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.


100

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 personas-

ao con una persona que trabaje durante 10 aos!).


101

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.


102

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.


103

TEMA 3

Competencia:

Distribucin del

Esfuerzo

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


104

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.


105

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 un sistema complejo y grande

probablemente se apreciara como 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.


106

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 mediante un modelo de proceso lineal,

secuencial, 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.


107

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.


108

TEMA 4

Competencia:

Refinamiento de las

Tareas

Principales

Identificar las tareas principales mediante la calendarizacin y elaboracin de una red de tareas.


109

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


110

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.


111

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.


112

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.

py. ii int. u1. u4

Documents