Desarrollo

y gestión de proyectos informáticos steve mcconnell pdf

Embed Size (px) 344 x 292 429 x 357 514 x 422 599 x 487 McConnell, S. (1997). Errores clásicos. En Desarrollo y gestión de proyectos informáticos (pp.35-58). Madrid : McGraw Hill. (C21006) TOMADO DE: DESARROLLO Y GESTION DE PROYECTOS INFORMA TICOS. Por Steve McCONNELL; ed. McGraw Hill; España 1997. 3 8111 Errores clásicos
Contenido 3.1. Ejemplo de errores clásicos 3.2. Efecto de los errores en la programación de un desarrollo 3.3. Relación de errores clásicos 3.4. La fuga de La isla de Gilligan Temas relacionados Gestión de riesgos: Capítulo 5 Estrategia para el desarrollo rápido: Capítulo 2 EL DESARROLLO DE SOFTWARE ES UNA ACTIVIDAD COM​PLICADA. Un
proyecto software típico puede presentar más oportuni​dades para aprender de los errores que las planteadas a algunas perso​nas durante toda su vida. Este capítulo examina algunos de los errores clásicos que se cometen cuando se intenta desarrollar software rápida​mente. 3.1. Ejemplo de errores clásicos El siguiente ejemplo es un poco como los
pasatiempos de los niños, en los que intentamos encontrar todos los objetos cuyo nombre comienza con la letra «M». ¿Cuántos errores clásicos puede encontrar en el siguien​te ejemplo?

35 Material didactico reproducido en ESAN para su uso exclusivo en clase. 36 Desarrollo y gestión de proyectos informáticos Ejemplo 3.1. Errores clásicos Mike, un responsable técnico de Giga Safe, estaba comiendo en su oficina y mirando por la ventana una brillante mañan4 de abriL «¡Felicidades! ¡Mike, ya tienes los . .foJ!~\),S.J>ara el programa
Giga​Quote !>> Era Bill, el jefe de.Mike en Giga, :qJ:}a C,mnpañía de seguros médi​cos. «Al comité ejecutivo le ha gustado la id~ade automatizar nuestras cuotas de seguro médico. Y también la idea de volcar cada noche las cuo​tas del día en la oficina principal para que siempre tengamos al dia los últimos valores de ventas. Ahora tengo una reunión,
pero podemos discutir los detalles más adelante. ¡Buen trabajoh> Mike escribió la propuesta para el programa Giga-Quote meses antes, pero estaba pensada como un programa para un solo PC, sin ninguna capa​cidad de comunicación con la oficina principaL Perfecto, ésta era la opor​tunidad de dirigir un proyecto clíente-servidoren;un moderno
entorno GUI (interfaces gráficas de usuario), lo que siempre había querido hacer.

El proyecto le llevaría al menos un año, y lo ocupada a tiempo completo. Mike descolgó el teléfono y marcó el número de su esposa. <> · A la mañana siguiente, Mike quedó con Bill pafa discutir el proyecto. «Vamos a ver, Bill. ¿Qué pasa?
Esto no se parece a la propuesta en la que he trabajado.» · · · · · Bill se sintió inseguro. Mike no había participado en las revisiones de la propuesta, pero no hubo tiempo de avisarle'. Cuando el comité ejecutivo estudió el programa Giga-Quote, tomaron los mandos. «Al comité ejecuti​vo le gustó la idea de construir software para automatizar las cuotas
de seguros médicos. Pero querían que se pudieran.transferir automáticamente las cuotas locales al computador central.
Y querían tener hecho el sistema antes de que se hagan efectivas las nuevas cuotas el 1 de enero. Adelanta​ron la fecha de finalización del software que propusiste del 1 de marzo al 1 de noviembre, con lo que se acortó el plan propuesto en 6 meses.» Mike babia estimado que el trabajo llevarla 12 meses. No creyó que tuviese la suerte de acabar en
seis meses, y así se lo dijo a Bill. «Vamos a ver si me he enterado», dijo Mike. «Parece que estás diciéndome que el comité añadió requisitos de comunicaciones a gran escala y ha acortado el plan de 12 a 6 meses.» Bill se encogió de hombros. «Sé que será un reto, pero tú eres creativo y creo que puedes con todo. Han aprobado el presupuesto que
querías, y añadir el enlace de comunicaciones no debe ser difícil. Pediste 36 perso​nas-mes y las tienes. Puedes reclutar a quien quiera que necesites para el proyecto e incrementar el tamaño del equipo.» Bill le dijo que hablase con algún otro desarrollador y que buscasen la forma de entregar el soft​ware a tiempo. Mike se reunió con Carl, otro
responsable técnico, y buscaron la forma de acortar el plan. «¿Por qué no usas C++ y diseño orientado a objetos?>>, (continúa) Capítulo 3: Errores clásicos 37 .
comentó Carl. «Serás más productivo que con C, y el plan se acortará en uno o dos meseS.)) A Mike le pareció bien.

Carl también conocía una he​rramienta de elaboración de informes que supuestamente acortaba el tiem​po de desarrollo a la mitad. El proyecto tenía bastantes informes, y por tanto esos dos cambios Jos llevarían hastalos 9 meses. Consiguieron hard​ware nuevo y más rápido, y esto les ahorraba un par de semanas. Si real​mente podía reclutar a
desarrolladores de primerisima 9ategoría, podría bajar a 7 meses. Esto era suficientemente ajustado. Mike comentó sus progresos a Bill. .... «Mira», dijo Bill, «dejar el plan en 7 meses está bien, pero no es sufi​ciente. El comité dejó claro que el plazo de eQtrega eran seis meses. No me. dieron opción. Puedo daros el ha,r:dware que:Q.ecesitáis, pero tú
y tu equipo · tenéis que encontrar una fornu¡, de re~cir ~~ p~n~á ~eis ~e~e~, ·o .tendréis que hacer algunas horas extra p~a p.ali.arl.a.dtferencta>). ,: ::'J: •. ··. , .· . . · Mike se planteó el hecho de que su ;esti,ttu:lción inicial sólo fue una · aproximación y pensó que· quizás podria bajarla a 6 meses. «De acuerdo, Bill, buscaré un par de personas
externas espabiladas para el proyecto. Quizás pueda encontrar gente con experiencia en comunicaciones para que nps ayude en la descarga de datos desde el PC al mainframe.» El 1 de mayo, Mike babia formado el equipo. JiU, Sue y Tomas eran buenos desarrolladores de la casa, y fueron Uberacl.os. Completó el equipo con Keiko y Chip, dos
contratados extemos~:.Keiko tenia experiencia tanto · en PC como en los mainframe con los qut tenla que conectarse. Jíll y To-o mas habían entrevistado a Chip y no querían~contratarlo, pero Mike lo im​puso.
Tenía experiencia en comúnicaciones y estaba disponible; asique Mike Jo contrató.

· · En la primera reunión del equipo, Bill dijo que. el programa Giga,.Quote era estratégicamente importante para Giga Safe Corporation. Algunós de los magnates de la compañia estarlan pendientes ele ellos .. Si tenian.éJdto se​rian recompensados. Dijo que estaba seguro de que lo conseguirían.

Después de los ánimos infundidos por el discurso de Bill, Mike se sen,. tó con el equipo y mostró el plan. El comité ejecutivo les babia proporcio​nado una especificación aproximada, y emplearon las siguientes dos sema​nas en completar las lagunas. Después se emplearían 6 semanas en el diseño, lo que dejaba 4 meses para la construcción y la prueba.
Su estimación aproxi​mada fue que el producto final tendria unas 30.000.Hneas en C++.
Todos los asistentes asintieron, dando su conformidad. Era ambicioso, pero lo sabían cuando se comprometieron con el proyecto. A la semana siguiente, Míke se reunió con Stacy, la responsable de la prueba.
Indicó que debería tener partes del producto terminadas para pro​barlas no después del 1 de septiembre, con el propósito de tener un produc​to con todas las funciones el 1 de octubre. Mike estaba de acuerdo. El equipo acabó la especificación de los requerimientos rápidamente, y se metió en el diseño. Obtuvieron un diseño que parecia hacer buen
uso de las prestaciones de C++. (continúa) 38 Desarrollo y gestión de proyectos informáticos Acabaron el diseño el 15 de junio, adelal}tánajo~ti;,etproy~<;~p.np:era una balsa de aceite. Ni a Jill ni a Tomas les g1l~tab~~.~hil:l;y,Súe se quejabade· que no quería que nadie se acercase a su códÍgoJMike atribuyó}os cho​ques de personalidades a las
muchas horas de trabajo. No obstante, a pri​meros de agosto, le indicaron que estaba hecho entre el85yel90 por 100; A mitad de agosto, el departamento actuarial dio las tasas para el año. siguiente, el equipo descubrió que tenía que modificar completan;í.ente la estructura para las nuevas tasas. El nuevo método 'de tasación•necesitaba realizar
preguntas sobre hábitos de ejercicio, en la bebida, 'en la comida, actividades de ocio y otros factores que no se habíanincluído antes en las fórmulas de tasación. Pensaron que C++ debía protegerlos de los efectos de esos cambios. Calcularon que sólo tendrlan que incluir nuevos valores en las tablas de tasas. Pero tendrían que cambiar el diálogo de
entrada, el diseño de la base de datos, el acceso a la base de datos y los objetos de comunicaciones para adaptarlos a la nueva .estructura. Como el equipo es​taba revuelto porque tenía que reajustar su diseño, Mike dijo a Stacy que se retrasarían unos días en la entrega de la primera versión para la prueba. El equipo no había terminado el 1 de.
septiembre, y Mike aseguró a Stacy que acabarían en sólo uno o dos días. Los días se volvieron semanas. El límite dell de octubre para entregar el producto completo para su prueba llegó y fue rebasado. Desarrollo aún no había acabado el primer producto para prueba. Stacy llamó a Bill a una reunión para tratar el plan. «Aún no tenemos nada de
desarrollo», dijo, «suponíamos que tendríamos la primera versión el 1 de septiembre, y puesto que aún no tenemos nada, por lo menos nos retrasaremos un mes respecto al plan original. Creo que tenemos un problema». «Es cierto, tenemos un problema», dijo Bill. <Usa ese truco.>> Chip comentó que su código de comunicaciones .estaba hecho al 95
por 100 y que funcionaba, pero que aún tenia que hacer algunas prue​bas de ejecución. Mike vio que Jill y Tomas se miraban, pero decidió igno​rarlo. El equipo trabajó duro hasta el 15 de noviembre, incluyendo las no​ches del 14 y el 15 de noviembre, pero no pudieron hacer que la fecha de entrega fuese el15 de noviembre. El equipo estaba exhausto,
pero la maña​na del dieciseisavo día, fue Bill quien se sintió deprimido. Stacy le había avisado de que desarrollo no había entregado la versión completa el día anterior. La última semana había dicho al comité ejecutivo que el proyecto estaba encarrilado. Otra gestora de proyectos, Claire, había investigado en los progresos del equipo, diciendo que
había oído que no estaban cum​pliendo las entregas planificadas con el equipo de prueba.
Bill pensó que Claire estaba tensa y no le gustaba su informe. Le había asegurado a ella que su equipo estaba en buen camino para cumplir las entregas planeadas. Bill dijo a Mike que reuniese al equipo, y cuando Jo hizo, parecían derrotados.
Un mes y medio a 60 horas semanales hablan sido la puntilla. Mike preguntó cuánto tiempo les llevaría acabar, pero su única respuesta fue el silencio. «¿Qué me estáis diciendo?», dijo. <;. «No he puesto el logotipo de la~em​presa en cada página, ni que el nombre y el teléfono del agente aparezca al pie de la página. Son pequeñas cosas como ésa.
Todo lo importante funcio​na bien. He acabado al 99 por 100.» «Yo tampoco he hecho exactamente el lOO por 100», admitió Jill. «Mi antiguo grupo me ha llamado para que les diese apoyo técnico, y he tenido que emplear un par de horas diarias con ellos. Además, había olvidado hasta ahora mismo que los agentes pedían poner su nombre y su teléfono
en los informes. Aún no he implementado los diálogos de entrada para esos (continúa) 40 Desarrollo y gestión de proyectos informáticos datos, y también tengo que hacer algunos di4logos .de mantenimiento. No , crefa que fuesen necesarios para el hito dela~utilidad completa",» Ahora Mike también empezaba a s~.ntir~~:wa,t. ~jaría duro, y que
pensaba que podía hacerlo. ';';;¡ :,· · · , · Al final de ese día, después de una dis~usiq~:latga e incómoda, Mike y. Bill acordaron retrasar el plan 3 semanas, hasta el S de diciembre, siempre que el equipo prometiera trabajar 12 horas ;8.1 dia en vez de 1 O. Bill dijo que tenía que demostrar a su jefe que. estaba a:ruzan4o~aJ equipo de desarrollo., La
revisión del plan implicaba que tendrían qúe probar el código y prepa​rar al personal al mismo tiempo, pero era.la,:úni~a posibilidad deent,regar el código el 1 de enero. Stacy se quejó de .que elcontrol de calidad del software no tenia asignado el tiempo suficiente para probarlo, pero Bill no . le hizo caso. El 5 de diciembre el equipo Giga-
Quote·ent:regó elprograma Giga​Quote completo al grupo de pruebas antes dellll~.io,día, y saH~on pronto del trabajo para tener su largamente esperado descanso. Habúln trabajado casi constantemente desde el 1 de septiembre¡;·. · .. ·· .· · . . .. Dos días más tarde, Stacy dio la primeraJista.de errores, y s~~de,sató el ; · infierno. En dos días el grupo
de pruebas identific~ máS de 200defetf~s en .
el programa Giga-Quote, incluyendo 23 clasificados como.de severidad 1 · («Tienen que corregirse>>). «No veo la forma de que el software esté.listo · para entregarlo a los agentes locales antes del Lde enero», dijo. «Probable​mente el grupo de pruebas necesite ese tiempo para escribir los casos de prueba de los defectos que ya ha descubierto, y
.está descubrie11do. defectos cada hora.>> · · Mike convocó una reunión de personal a las 8 en punto de la mañana siguiente. Los desarrolladores estaban quisquillosos.
Decían que había unos cuantos errores serios, pero la mayoría de los errores indicados no eran realmente errores, sino malas interpretaciones de cómo se suponía que te​nía que funcionar el programa. Tomas indicó que el error# 143 era un ejemplo de eso. «El informe del error #143 dice que en la página resumen de la cuota, el gráfico de barras
tiene que estar en la derecha de la página en vez de en la izquierda. Esto no es un error de severidad 1. Es la típica forma en que los comprobadores sobreestiman un problema.>> Mike distribuyó copias de los informes de errores. Encargó a los desa​rrolladores que revisasen los errores que el grupo de pruebas les había asig​nado y estimasen cuánto
tiempo les llevaría corregir cada uno de ellos. Cuando el equipo se reunió de nuevo por la tarde, las noticias no eran buenas. «Siendo realista, estimo que necesito· dos semanas completas de trabajo para corregir los errores que ya nos han pasadm>, dijo Sue.
«Además, (continúa) Capítulo 3: Errores clásicos 41 tengo que acabar las comprobacion!!S de integrida~ referencial de la base ; de datos. En total, necesito cuatro seman~s ~ p~irA~· hoy.» L ,,, . ·. .
. · Tomas había devuelto elerror #143a)osicomp~:obadores,:cambiando:' su severidad de 1 a 3 («Cambio estético»). El grupo· de pruebas respondió que los informes resumen de Giga~Quote tenían que coincidir con infor​mes similares generados por el programa instalado· en el mainframe para políticas de renovación, que era similar a los formatos de
marketing preim· presos que la compañia había usado durante muchos.años. Los 600 agentes . de la compañía estaban acostumb~:ados a. ver sus valores de ~entas en grá· ficos de barras a la derecha, y teníanque quedarse ~Ja derec~~; ;,1 error ;Se quedó con un nivell, y supuso unproblema. · · · .. ···• ~·;: , . .· «¿Recuerdas la trampa que utilicé para
que se pudiesen ·itnpri,mir en la misma página el gráfico de ballJls y el informe?»;pr.egunt6Tomas. «Para poner el gráfico a la ,derecha, tengo que •rees~ri~ir.,e~e infoím~.~.CoJ1cret() . desde el principio,Jo que. sígnifica,;.que •tengo:,que' esctibit¡ mi'propí() código a bajo nivel para dar fo~to .• al infot;rn~1y algráfic;:,o~R Mi].(e t~m.,.. . . bló~ :,y
pidió tina estimación·~.!Jpro~illladí!:'•d~!;c:ti,áilto)iempo.· necesitaba .. · :. ¡omas dijo que porJl()imenqs)o: •'pero;CJ.] ' gpa.,,que V".rlo más des~ . · .. F'~~io;.:~tes de,estar·:seguro.ii.. · ~i~j~ . . .
. ':;;;• • ,:/;i:';,):< .• ":. ,: · ·. ·>' ~ntes de volver;,a casa..l\1t~~i:., c¡>.~:$~~yJ~.~ill¡que ~fe,quipoBill. dijo que'se lo ésP,eraba'yque habia aprobado un retraso en el plan de 4 semanªs antesdeirsé,iru,tl'Crucero deunmes por el Caribe que tenia planeado des.c:le !i!l pasado:veran()~ .. · · El mes siguiente Mik~ estu;v() ?Cup~dll~~~eltj~tld() a,:t~pó
.ll,llid~ ..
Durante cuatro meses habtan. tr~b,aja~BJodo·~o. ?~ro que .se.PP¡~ia .. tíaba• • jarj y no creía que pudiesen, pacer J»ás. Es!ab~~~p~J~ .. ofi(iUltfU })pras · al día, pero empleaban mucho> tiempo leyendo 'revistas, pagandó factUras' · y hablando por teléfono. Parecía que se irritaban, sie~pre que lc:s. pregun" taba cuánto les quedaba para
redu~r•la · cuetlta de errores. Pót cada errór . que se corregía,. el grupo de Pl'll~bas d,escubtia.E:do,.núevos¡ Brrotes·.cuya . corrección debia haber llevado 2 minutos tenían ünplicaciones en el pro· yecto completo y podían llevar dias: Pronto calcularon que no habia forma de que pudieran corregir todos los defectos par¡¡ el 7 de enero. El 7 de enero
Bill volvió de sus vacaciones, y Mike le dijo que el equi​po de desarrollo aún necesitaba. 4 semanas más. <{Esto es serio>>, dijo Bill. , «tengo 600 agentes locales que están hartos de dar vueltas alrededor de un puñado de aprendices de informáticos. El comité ejecutivo está hablando de cancelar el proyecto. Tienes que encontrar una forma de
entregar el soft​ware en las próximas dos semanas, sea como sea». Mike convocó una reunión del equipo para estudiar sus opciones. Les comunicó el ultimátum de Bill y les pidió una estimación aproximada de cuándo entregarían el producto,. primero en semanas, luego ett meses. El equipo se calló. Ninguno searriesgaba acerca dC:cuándopodrí~
entregar finalmente el producto. Mib 9~sabia qué decirle.a}3iU.· · ·. (continúa) 42 Desarrollo y gestión de proyectos informáticos V __ ,,;o';~- ~;:}!:-'/-:~,:: ~7;~,i~;~:~·- ,: :: ,::~ '¡~!t~~,~T~fi~:~~-I-~~~r¿i,:F~,-~'~ :ir::< Tras la reuni?n;:(;hip dijo,·~··~ik~:quei~~~ia:;~sería un alivio que secancelaÍ'a~l.proyecto '~/.;,;;:; "' ·.·. ,:, ·:~: · •. · · Mike
buscó. a Kip,.el programadorque~~~~iq~.r~s~&?,J~A~(ap~:i~E:} d(), de. comuni~aci~n~s entre e~·pg:y.e,~¡~~~~~r~ig~g~$!.~¡~PP~Pi~H·t;~ proyecto, y lo dedicó a corregu.los errores en~~~ ~9qtgó,:qe,· ,nt~a~J.J~Qes;(: , del PC. Despuós de .\~har un~. se111ana'pon, ~t.có~~go,~~i~ :,;~ i~9~ºJ.uT'·:;•,'1 .. yó que ten fa algunos,
defeclQS conceptuale~·pro>fundos \qp,e; ~~"(l;'obJigadque. ya hab.fa oído, .suficien~e. y mandó un «stop» alprograma Giga-Quote:Se reunió conMike.elviemesi . «Este proyecto está fuera de controb>, dijo. «Oesde hace meses, Billno me · ha dado una estimación fiable. Es un proyecto de'6 meses,'y'·ya llevá más. de 3 meses de retraso sin un final
claro. Estáis trabajando tantas' horas que no hacéis progresos. Quiero que descanséis todos.unfin de semllna;quiero que desarrolles un informe detallado, paso a paso, que incluya t9d01 y digo todo, lo que queda por hacer. del proyecto. N9 quiero qlJ,eforcéis el proyec​to para encajarlo en un' plan artí.ficial: :Si se necesitan otros'9 ~eses;quiero · ·
saberlo. Quieroel informe del.tr~bajo pendiente P'P:'~ .. el Wi.~;:~~!e$: !i~ t,ie~ ne. que ser bonito, pero tiene que estarcompleto:>> > . . ; • t< . ·· · ·· . · El equipo de desarrollo se alegró de tener un ·fin de'semana libre~·.y: · durante la semana siguiente atacaron el informe detallado conenérgias're~ novadas. Estuvo en la mesa de Claire para el
miércoles.
Revisó el informe con Charles, un asesor en ingeniería del software que también había revi​sado las estadísticas de errores del proyecto. Charles recomendó que el equipo centrase sus esfuerzos en un puñado de n;lódtilos'propens<,>s a erro7 . . res, que se iniciasen inmediatamente· revisicmes d~!' diseno y la'codifica-. · · ción para corregir todos los
errores y.queel equipo comenzase trabajando horas fijas, para que se pudiesen hacer métricas precisas del esfuerzo em.:. pleado en el proyecto y cuánto se necesitaría para terminarlo. : ' · Tres semanas más tarde, ·en la primera semana de marzo, .la lista de errores pendientes bajó un poco por primera vez. La moral del equipo su​bió un poco, y
basándose en los progresos regulares que se iban haciendo, el asesor estimó que el software podría entregarse, completamente probado y fiable, el 15 de mayo. Puesto que el incremento semestralde latasade Giga Safe tendría efecto a partir de l de julio, Claire fijóla''fe~ha .oficial, de lanzamiento el 1 de junio.
· ' · · · ··· · ·· · Epílogo El programa Giga Quote se entregó a los agentes locales de acuerdo con el plan el 1 de junio. Los agentes locales de Giga Safe lo acogieron con entu;. siasmo y algo de escepticismo. (continúa) REFERENCIA CRUZADA En la Sección 8.6, «Estimaciones simples de planificación», se incluye una tabla con las estimaciones
aproximadas para proyectos de distintos tamaños. Capítulo 3: Errores clásicos 43 . La corporación Giga Safe mostró su apre~io al tr~baj9.9~roJeal~ado por el equipo de desarrollo dando a cada d,esarroJlaqor una l:Jql\iñ.é.~i6n de 250 dólares. Unas cuantas sem11nas ro~ tatde,}l'omaspidiópna.larga,baJ~tt y lill se fue a trabajar a otra. coropañja. ;,<
; ': · ·•.· ·· .• ;;i•·:~'·.c·· ' ' • '• ;,,,) · El producto final Giga•Quot~ se entr~g9 en 13 meses eri\r~z. de·eri 6, · pasándose del limite más de. un 100 pot lOO. E1· ésfuetz(f· de ·dt'!$aJ:!:ollo, · incluyendo las horas extras, fue de 98 personas•roes, lo que·supuso un ex- · ceso del.l70 por 100 respecto a las 36 personas• mes planificadas. ;:~l producto final
tenía entomoa40.000 llneas de c6digoC++ no va ... ciaiy sin comentario~, superior en más de un 33 por 100 a las estimaciones aproximadas de M,ik,~~ Puesto que fue un producto distribuido .. en más de 600 puestos internos·, Giga-,Quote es un híbridq entre un producto de ges.: tión y un producto <>. Un producto de este tamafio y este tipo
normalmente se debería haber acabado en 11 meses y medio con un esfuer​zo de 71 personas-mes. El proyecto sobrepasó ambas cantidades. 3.2. Efectos de los errores en la programación de un desarrollo Michael Jackson (el cantante, no el informático) cantaba que «Üne bad apple don't spoil the whole bunch, baby» (una manzana podrida no estropea
el barril completo, pequeña). Esto puede ser cierto para las manzanas, pero no lo es para el software. Una manzana podrida puede estropear el proyecto completo. Un grupo de investigadores de ITT revisó 44 proyectos de 9 países para examinar el impacto de 13 factores de productividad en la producti​vidad (Vosburgh et al., 1984 ). Los factores
incluían el uso de técnicas de programación modernas, dificultad del código, requisitos de eficiencia, nivel de participación del cliente en la especificación de los requerimien​tos, experiencia personal y alguno más. Asignaron a cada factor distintas categorías que esperaban asociar con una eficiencia baja, media o alta. Por ejemplo, asignaron al factor
«uso de técnicas modernas de programa​ción» valores de bajo uso, uso medio o alto. La Figura 3.1 de la página siguiente muestra lo que descubrieron los investigadores acerca del factor «uso de técnicas modernas de programación». Cuanto más estudiamos la Figura 3.1, más interesante resulta. Mues​tra un patrón general que es representativo de los
descubrimientos de cada uno de los factores de productividad estudiados. Los investigadores de ITT vieron que los proyectos de las categorías que tuvieran poca produc​tividad realmente tenían una productividad pobre, como muestra la estre​cha franja de la categoría Baja en la figura 3.1. Pero la productividad en 44 Desarrollo y gestión de proyectos
informáticos REFERENCIA CRUZADA Para un análisis más detallado de este gráfico concreto, consulte la Sección 4.2, «Bases técnicas». REFERENCIA CRUZADA Para más información acerca del papel que juegan los errores en el desarrollo rápido, véase la Sección 2.1, «Estrategia general para el desarrollo rápido ... Uso de técnicas modernas de
programación (porcentaje del sistema total) Porcentaje de la planificación nominal Baja (0-25%) Media (26-75%) Alta (76-100%) +200 ---------- +100 ------, O (media) --------------- Leyenda I Máximo Percentil del 75% Media 1 Percentil del 25% Mfnimo Figura 3.1. Estudio sobre el factor <Es como preguntarse: ¿cuál es la causa principal de que no sea
capaz de correr una milla en cuatro minutos? Bueno, soy demasiado viejo. Peso mucho. No estoy en forma. No me atrevo a intentarlo. No tengo un buen entrena​dor o capacidades atléticas. No podría ir tan deprisa aunque fuese más joven. La lista crece y crece. Cuando hablamos de proezas excepcionales, las razones de que la gente no las alcance son
simplemente demasiado numerosas como para contar- Capítulo 3: Errores clásicos 45 las. El equipo de Giga-Quote del Ejemplo 3.1 cometió muchos de los errores que han plagado el desarrollo de software desde los tiempos más remotos de la informática. El camino del desarrollo de software está lleno de ba​ches, y los baches en que caigamos
determinan la rapidez o la lentitud con que desarrollamos el software. En el software, una manzana podrida puede estropear todo el barril, pequeña. Para caer en el desarrollo lento, todo lo que hay que hacer es cometer realmente un gran error; para conseguir el desarrollo rápido te​nemos que evitar cometer algún gran error. La siguiente sección
enumera los grandes errores más habituales.
3.3. Relación de errores clásicos Algunas técnicas de desarrollo inefectivas han sido elegidas con tanta frecuencia, por tanta gente, con resultados tan malos y predecibles que son dignas de ser llamadas «errores clásicos».
Muchos de los errores tienen una apariencia seductora. ¿Necesitamos salvar un proyecto re​trasado? ¡Metamos a más gente! ¿Tenemos que reducir el plan? ¡Plani​ ERROR CLÁSICO fiquemos de forma más agresiva! ¿Alguno de los miembros clave in- Figura 3.2. El proyecto software estaba repleto de errores, y todos /os directivos de mayor categoría y
/os responsables técnicos juntos no lo pueden salvar a ningún precio. 46 Desarrollo y gestión de proyectos informáticos REFERENCIA CRUZADA Para más información sobre los buenos y malos usos de la motivación, consulte el Capítulo 11, "Motivación". comoda al resto del equipo? ¡Esperaremos hasta que acabe el proyecto para despedirlo! ¿Hay
que acelerar el proyecto para acabar? ¡Cogeremos cuantos desarrolladores estén ya disponibles, y que comiencen lo antes posible! Los desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman, y la apariencia seductora de los errores clásicos es una de las razones de que esos errores se cometan
tan a menudo. Pero debido a que se han cometido muchas veces, sus con​secuencias se han hecho fáciles de predecir. Y los errores clásicos rara vez producen los resultados que la gente espera. Esta sección enumera alrededor de dos docenas de errores clásicos. Personalmente he visto cometer cada uno de esos errores al menos una vez, y yo mismo
he cometido bastantes. Muchos de ellos aparecen en el Ejemplo 3.1. El común denominador de esos errores es que el desarrollo rápido no se consigue necesariamente si se evitan, pero si no se evitan, seguro que se consigue el desarrollo lento. Si alguno de estos errores nos resulta familiar, hay que animarse; muchos otros los han cometido antes.
Una vez que comprendamos sus efectos en la velocidad de desarrollo, podremos utilizar esta lista para ayudarnos en la planificación de nuestro proyecto y en la gestión de riesgos. Algunos de los errores más significativos tienen sus propias secciones en otras partes de este libro. Otros no se tratarán más. Para facilitar la consulta, la lista se ha
dividido empleando las dimensiones de la veloci​dad de desarrollo: personas, proceso, producto y tecnología.
Personas A continuación aparecen algunos de los errores clásicos relacionados con las personas.
1: Motivación débil. Estudio tras estudio se ha mostrado que la motiva​ción probablemente tiene mayor efecto sobre la productividad y la calidad que ningún otro factor (Boehm, 1981 ).
En el Ejemplo 3 .l, los directivos tomaron a lo largo de todo el proyecto medidas que minaban la moral: como dar ánimos a diario al principio para pedir horas extras en la mitad, y como irse de vacaciones mientras el equipo estaba trabajando incluso los días de fiesta, para dar recompensas al final del proyecto que resultaron ser de menos de un dólar
por cada hora extra. 2: Personal mediocre. Después de la motivación, la capacidad in​dividual de los miembros del equipo, así como sus relaciones como equipo, probablemente tienen la mayor influencia en la productividad (Boehm, 1981; Lakhanpal, 1993). Contratar apurando el fondo del barril REFERENCIA CRUZADA Para más información sobre la
creación de equipos efectivos, véase el Capítulo 12, «Equipo de trabajo". REFERENCIAS CRUZADAS Para más información sobre proyectos heroicos y basados en compromiso, consulte la Sección 2.5, «Una estrategia alternativa para el desarrollo rápido»; la Sección 8.5, «Planificación basada en compromiso», o el Capítulo 34, «Compromiso".
REFERENCIA CRUZADA Para ver alternativas a la hora de salvar un proyecto retrasado, consulte el Capítulo 16, «Recuperación de proyectos". Capítulo 3: Errores clásicos 47 supondrá una amenaza al esfuerzo del desarrollo rápido. En el ejemplo, la selección del personal se hizo buscando quién podría contratarse más rá​pido, en vez de quién
realizaría la mayoría del trabajo durante la vida del proyecto. Esta técnica consigue un inicio rápido del proyecto, pero no determina un final rápido. 3: Empleados problemáticos incontrolados. Un fallo al tratar con personal problemático también amenaza la velocidad de desarrollo. Es un problema habitual, y se ha comprendido bien, al menos desde
que Gerald Weinberg publicó Psychology of Computer Programming en 1971. Un fallo al tomar una decisión cuando se trata con un empleado problemático es una de las quejas más comunes que tienen Jos miembros del equipo respecto de sus responsables (Larson y LaFasto, 1989).
En el Ejemplo 3.1, el equi​po sabía que Chip era una manzana podrida, pero el jefe del equipo no hizo nada. El resultado era predecible: rehacer el trabajo de Chip. 4: Hazañas. Algunos desarrolladores de software ponen un gran énfa​sis en la realización de hazañas en los proyectos (Bach, 1995). Pero lo que hacen tiene más de malo que de bueno. En el
ejemplo, los directivos de nivel medio dieron mayores aplausos a actitudes del tipo «ser capaz de» que a los progresos firmes y consistentes y a los informes significativos de progreso. El resultado fue un modelo de planificación al límite en el que las amenazas de desajuste del plan no se detectaban, ni se conocían o ni se informaban a la cadena de
directivos hasta el último minuto. Un pequeño equipo de desarrollo y sus jefes inmediatos toman como rehenes a una compañía entera por no admitir que tienen problemas para cumplir su plan. El énfasis en los comportamientos heroicos fomenta correr un riesgo extremo, e impide la cooperación entre los múltiples elementos que contribuyen al
proceso de desarrollo del software. Algunos directivos fomentan el comportamiento heroico cuando se concentran con demasiada firmeza en actitudes «ser capaz de». Elevando estas actitudes por encima de informes del estado exactos y a veces pesi​mistas, los directivos de estos proyectos coartan su capacidad de tomar medidas correctivas.
Ni siquiera saben que tienen que emprender accio​nes correctoras hasta que el daño ya está hecho. Como dijo Toro DeMar​co, las actitudes «ser capaz de» convierten pequeños contratiempos en auténticos desastres (DeMarco, 1995). 5: Añadir más personal a un proyecto retrasado. Éste es quizás el más clásico de los errores clásicos.
Cuando un proyecto se alarga, aña​dir más gente puede quitar más productividad a los miembros del equipo existente de la que añaden los nuevos miembros. Fred Brooks com​para añadir gente a un proyecto retrasado con echar gasolina en un fuego (Brooks, 1975).
48 Desarrollo y gestión de proyectos informáticos REFERENCIA CRUZADA Para más información sobre los efectos del entorno psicológico en la productividad, consulte el Capítulo 30, «Entornos productivos». REFERENCIA CRUZADA Para más información sobre las relaciones efectivas con los clientes, consulte el Capítulo 1 O, «Desarrollo orientado
al cliente». REFERENCIA CRUZADA Para más información sobre fijar expectativas, consulte la Sección 10.3, «Gestión de las expectativas del cliente». 6: Oficinas repletas y ruidosas. La mayoría de los desarrolladores consideran sus condiciones de trabajo como insatisfactorias. Alrededor del 60 por 100 indican que no tienen suficiente silencio ni
privacidad (De​Marco y Lister, 1987). Los trabajadores que están en oficinas silenciosas y privadas tienden a funcionar significativamente mejor que aquellos que ocupan cubículos en salas ruidosas y repletas. Los entornos repletos y ruidosos alargan los planes de desarrollo. 7: Fricciones entre los clientes y los desarrolladores.
Las friccio​nes entre los clientes y los desarrolladores pueden presentarse de distintas formas. A los clientes puede parecerles que los desarrolladores no coope​ran cuando rehúsan comprometerse con el plan de desarrollo que desean los clientes o cuando fallan al entregar lo prometido. A los desarrollado​res puede parecerles que los clientes no son
razonables porque insisten en planes irreales o cambios en los requerimientos después de que éstos ha​yan sido fijados.
Pueden ser simplemente conflictos de personalidad en​tre dos grupos. El principal efecto de esta fricción es la mala comunicación, y los efectos secundarios de la mala comunicación incluyen el pobre enten​dimiento de los requerimientos, pobre diseño de la interfaz de usuario y, en el peor caso, el rechazo del cliente a aceptar el producto acabado. En
el caso medio, las fricciones entre clientes y desarrolladores de software lle​gan a ser tan severas que ambas partes consideran la cancelación del pro​yecto (Jones, 1994 ). Para remediar estas fricciones se consume tiempo, y distraen tanto a desarrolladores como a clientes del trabajo real en el pro​yecto. 8: Expectativas poco realistas. Una de las causas
más comunes de fricciones entre los desarrolladores y sus clientes o los directivos son las expectativas poco realistas. En el Ejemplo 3.1, Bill no tenía razones para pensar que el programa Giga-Quote se podría desarrollar en 6 meses, pero ése era el plazo en que lo quería el comité ejecutivo de la compañía. La incapacidad de Mike de corregir esta
expectativa irreal fue la principal fuente de problemas. En otros casos, los directivos o los desarrolladores de un proyecto se buscan problemas al pedir fondos basándose en estimaciones de planifi​cación demasiado optimistas. A veces prometen un conjunto de funcio​nes tan altas como la Luna.
Aunque por sí mismas las expectativas irreales no alargaran el plan, contribuyen a la percepción de que el plan de desarrollo es demasiado largo, y de que puede ser malo. Una inspección de Standish Group marcó las expectativas realistas como uno de los cinco factores principales ne​cesarios para asegurar el éxito de los proyectos internos de
software de gestión (Standish Group, 1994).
REFERENCIA CRUZADA Para más información sobre las políticas de seguridad, consulte la Sección 10.3, «Gestión de las expectativas del cliente". Capítulo 3: Errores clásicos 49 9: Falta de un promotor efectivo del proyecto. Para soportar mu​chos de los aspectos del desarrollo rápido es necesario un promotor del proyecto de alto nivel, incluyendo
una planificación realista, el control de cambios y la introducción de nuevos métodos de desarrollo.
Sin un pro​motor ejecutivo efectivo, el resto del personal de alto nivel de la empresa puede forzar a que se acepten fechas de entrega irreales o hacer cambios que debiliten el proyecto. El consultor australiano Rob Thomsett afirma que la falta de un promotor efectivo garantiza virtualmente el fracaso del proyecto (Thomsett, 1995). 10: Falta de
participación de los implicados. Todos los principales participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto. Incluyendo a los promotores, ejecutivos, responsables del equi​po, miembros del equipo, personal de ventas, usuarios finales, clientes y cualquiera que se juegue algo con el proyecto. La cooperación estrecha sólo
se produce si se han implicado todos los participantes, permitiendo una coordinación precisa del esfuerzo para el desarrollo rápido, que es imposible conseguir sin una buena participación. 11: Falta de participación del usuario. La inspección de Standish Group descubrió que la razón número uno de que los proyectos de Siste​mas de Información
tuviesen éxito es la implicación del usuario (Standish Group, 1994). Los proyectos que no implican al usuario desde el princi​pio corren el riesgo de que no se comprendan los requerimientos del pro​yecto, y son vulnerables a que se consuma tiempo en prestaciones que más tarde retrasarán el proyecto. 12: Política antes que desarrollo. Larry
Constantine indicó que si hay cuatro equipos hay cuatro tipos diferentes de orientaciones políticas (Constantine, 1995a). Los «políticos» están especializados en la «gestión», centrándose en las relaciones con sus directivos. Los «investigadores>> se centran en explorar y reunir información. Los «aislacionistas» están so​los, creando fronteras para el
proyecto que mantienen cerradas a los que no son miembros del equipo. Los «generalistas» hacen un poco de todo: establecen relaciones con sus directivos, realizan investigaciones y ex​ploran actividades, y se coordinan con otros equipos como parte de su modo de trabajo.
Constantine indicó que inicialmente los equipos políti​cos y generalistas están bien vistos por Jos directivos de alto nivel. Pero después de un año y medio, los equipos políticos llegan a la muerte súbi​ta. Primar la política en vez de los resultados es fatal para el desarrollo orientado a la velocidad. 13: Ilusiones. Estoy impresionado de ver cuántos
problemas del desa​rrollo del software se deben a la ilusión. Cuántas veces hemos escuchado cosas como éstas a distintas personas: 50 Desarrollo y gestión de proyectos informáticos REFERENCIA CRUZADA Para más información sobre los planes irreales, consulte la Sección 9.1, "Planificación excesivamente optimista». «Ninguno de los miembros del
proyecto cree realmente que pueda com​pletarse el proyecto de acuerdo con el plan que tienen, pero piensan que quizás si trabajan duro, y nada va mal, y tienen un poco de suerte, serán capaces de concluir con éxito.» «Nuestro equipo no hace mucho trabajo para la coordinación de las interfaces entre las distintas partes del producto, pero tenemos
una buena comunicación para otras cosas, y las interfaces son relativamente simples, así que probablemente sólo necesitaremos un día o dos para eliminar los errores.» «Sabemos que contamos con un desarrollador externo de poco talento para el subsistema de la base de datos, y que es dificil ver cómo va a acabar el trabajo con los niveles de
personal que ha especificado en su propuesta. No tienen tanta experiencia como algunos de los demás desarrolladores externos, pero puede que compensen con energía lo que les falta en expe​riencia. Probablemente acaben a tiempo.» «No necesitamos reflejar la última lista de cambios en el prototipo para el cliente. Estoy seguro de que por ahora
sabemos lo que quiere.» «El equipo está diciendo que realizará un esfuerzo extraordinario para cumplir con la fecha de entrega, y que no han llegado a su primer hito por pocos días, pero creo que alcanzarán éste a tiempo.» Las ilusiones no son sólo optimismo. Realmente consisten en cerrar los ojos y esperar que todo funcione cuando no se tienen
las bases razona​bles para pensar que será así. Las ilusiones al comienzo del proyecto lle​van a grandes explosiones al final.
Impiden llevar a cabo una planifica​ción coherente y pueden ser la raíz de más problemas en el software que todas las otras causas combinadas. Proceso Los errores relacionados con el proceso ralentizan los proyectos porque malgastan el talento y el esfuerzo del personal. A continuación se mues​tran algunos de los peores errores relacionados con el
proceso. 14: Planificación excesivamente optimista. Los retos a los que se enfrenta alguien que desarrolla una aplicación en tres meses son muy diferentes de aquellos a los que se enfrenta alguien que desarrolla una aplicación que necesita un año. Fijar un plan excesivamente optimista pre​dispone a que el proyecto falle por infravalorar el alcance del
proyecto, minando la planificación efectiva, y reduciendo las actividades críticas para el desarrollo, como el análisis de requerimientos o el diseño. Tam​bién supone una excesiva presión para los desarrolladores, quienes a largo plazo se ven afectados en su moral y su productividad. Ésta es la mayor fuente de problemas del Ejemplo 3.1. REFERENCIA
CRUZADA Para más información sobre la gestión de los riesgos, consulte el Capítulo 5, «Gestión de riesgos". REFERENCIA CRUZADA Para más información sobre contratados, consulte el Capítulo 28, «Desarrollo externo". REFERENCIA CRUZADA Para más información sobre la planificación, consulte «Planificación", en la Sección 4.1.
REFERENCIAS CRUZADAS Para más información sobre planificación bajo presión, consulte la Sección 9.2, «Disminución de la presión de la planificación", y el Capítulo 16, «Recuperación de proyectos". REFERENCIA CRUZADA Para más información sobre escatimar en las actividades iniciales, consulte "Electos de la planificación excesivamente
optimista", en la Sección 9.1. Capítulo 3: Errores clásicos 51 15: Gestión de riesgos insuficiente. Algunos errores no son lo sufi​cientemente habituales como para considerarlos clásicos. Son los llamados «riesgos». Como con los errores clásicos, si no ejercemos una gestión activa de los riesgos, con que sólo vaya mal una cosa se pasará de tener un pro​-
yecto con un desarrollo rápido a uno con un desarrollo lento. El fallo de no gestionar uno solo de estos riesgos es un error clásico. 16: Fallos de los contratados. Las compañías a veces contratan la realización de partes de un proyecto cuando tienen demasiada prisa para hacer el trabajo en casa. Pero los contratados frecuentemente entregan su
trabajo tarde, con una calidad inaceptable o que falla al no coincidir con la especificación (Boehm, 1989). Riesgos como requerimientos inesta​bles o interfaces mal definidas pueden ser enormes cuando un contratado entra en escena. Si las relaciones con los contratados no se gestionan cui​dadosamente, la utilización de desarrolladores externos puede
ralentizar el proyecto en vez de acelerarlo. 17: Planificación insuficiente. Si no planificamos para conseguir un desarrollo rápido, no podemos esperar obtenerlo. 18: Abandono de la planificación bajo presión. Los equipos de desa​rrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en la planificación (Humphrey,
1989).
El problema no está en el abandono del plan, sino más bien en fallar al no crear un plan alter​nativo, y caer entonces en el modo de trabajo de codificar y corregir. En el Ejemplo 3.1, el equipo abandonó su plan después de fallar en la primera entrega, y esto es lo habitual. A partir de este punto, el trabajo no tuvo coordinación ni elegancia, hasta el
punto de que Jill empezó a trabajar parte del tiempo para un proyecto de su viejo grupo y nadie lo supo. 19: Pérdida de tiempo en el inicio difuso. El «inicio difuso>> es el tiempo que transcurre antes de que comience el proyecto; este tiempo normalmente se pierde en el proceso de aprobar y hacer el presupuesto. No es poco común que un proyecto
desperdicie meses o años en un inicio difu​so, y entonces se está a las puertas de un plan agresivo. Es mucho más fácil y barato y menos arriesgado suprimir unas pocas semanas o meses del inicio difuso en vez de comprimir el plan de desarrollo en ese mismo tiempo. 20: Escatimar en las actividades iniciales. Los proyectos que se aceleran intentando
acortar las actividades no esenciales, y puesto que el análisis de requerimientos, la arquitectura y el diseño no producen código directamente, son los candidatos fáciles. En un proyecto desastroso en el que participé, pedí que me enseñasen el diseño. El responsable del equipo me dijo: «No hemos tenido tiempo de hacer el diseño.» 52 Desarrollo y
gestión de proyectos informáticos DATOS REALES REFERENCIA CRUZADA Para más información sobre control de calidad, consulte la Sección 4.3, «Bases del control de calidad". DATOS REALES REFERENCIAS CRUZADAS Para más información sobre controles de la directiva, consulte «Seguimiento", en la Sección 4.1, y el Capftulo 27, «Hitos
miniatura".
Los resultados de este error, también conocido como «saltar a la codificación», son todos demasiado predecibles. En el ejemplo, un truco de diseño en el informe del gráfico de barras fue sustituido por un trabajo de diseño de calidad. Antes de poder entregar el producto, el trabajo con truco tuvo que tirarse, y hubo que hacer de todos modos el
trabajo bien hecho. Los proyectos que normalmente escatiman en sus actividades iniciales tendrán que hacer ese trabajo en otro momento, con un coste de lO a 100 veces superior a haberlo hecho bien inicialmente (Fagan, 1976; Boehm y Papaccio, 1988). Si no podemos encontrar cinco horas para hacer el trabajo correctamente la primera vez, ¿cómo
vamos a encontrar 50 para hacerlo correctamente más tarde? 21: Diseño inadecuado. Un caso especial de escatimar en las activi​dades iniciales es el diseño inadecuado. Proyectos acelerados generan un diseño indeterminado, no asignando suficiente tiempo para él y originan​do un entorno de alta presión que hace dificil la posibilidad de considerar
alternativas en el diseño. El énfasis en el diseño está más orientado a la conveniencia que a la calidad, por lo que necesitará varios ciclos de dise​ño antes de poder finalizar completamente el sistema.
22: Escatimar en el control de calidad. En los proyectos que se ha​cen con prisa se suele cortar por lo sano, eliminando las revisiones del diseño y del código, eliminando la planificación de las pruebas y reali​zando sólo pruebas superficiales.
En el ejemplo, las revisiones del diseño y del código se eliminaron limpiamente para conseguir una ganancia con​siderable en el plan. Al final, cuando el proyecto alcanzó su hito de plena funcionalidad, aún tenía demasiados errores y se retrasó más de 5 meses. Este resultado es típico. Acortar en un día las actividades de control de calidad al comienzo
del proyecto probablemente supondrá de 3 a 1 O días de actividades finales (Jones, 1994 ). Esta reducción va contra la velo​cidad de desarrollo.
23: Control insuficiente de la directiva. En el ejemplo hay poco con​trol de la directiva para detectar a tiempo los signos de posibles retrasos en el plan, y los pocos controles definidos al comienzo se abandonaron cuando el proyecto comenzó a tener problemas. Antes de encarrilar un proyecto, en primer lugar debemos ser capaces de decir si va por
buen camino. 24: Convergencia prematura o excesivamente frecuente. Bastante antes de que se haya programado entregar un producto, hay un impulso para preparar el producto para la entrega, mejorar el rendimiento del pro​ducto, imprimir la documentación final, incorporar entradas en el sistema final de ayuda, pulir el programa de instalación,
eliminar las funciones que no van a estar listas a tiempo y demás. En proyectos hechos con prisa, REFERENCIA CRUZADA Para más información sobre la convergencia prematura, consulte «Convergencia prematura,., en la Sección 9.1. REFERENCIA CRUZADA Para más información sobre las tareas habituales omitidas, consulte «No omita tareas
comunes", en la Sección 8.3. REFERENCIA CRUZADA Para más información sobre la reestimación, consulte «Recalibración .. , en la Sección 8. 7. REFERENCIA CRUZADA Para más información sobre el enfoque de codificar y corregir, consulte la Sección 7.2, «Codificar y corregir". Capítulo 3: Errores clásicos 53 hay una tendencia a forzar
prematuramente la convergencia. Puesto que no es posible forzar la convergencia del producto cuando se desea, algunos proyectos de desarrollo rápido intentan forzar la convergencia media do​cena de veces o más antes de que finalmente se produzca. Los intentos adicionales de convergencia no benefician al producto. Sólo son una pér​dida de
tiempo y prolongan el plan. 25: Omitir tareas necesarias en la estimación. Si la gente no guar​da cuidadosamente datos de proyectos anteriores, olvida las tareas me​nos visibles, pero son tareas que se han de añadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 o 30 por 100 (Van Genuch​ten, 1991 ). 26: Planificar ponerse al día más
adelante. Un tipo de reestimación es responder inapropiadamente al retraso del plan. Si hemos trabajado en un proyecto durante 6 meses, y hemos empleado tres meses en llegar al hito correspondiente a los dos meses, ¿qué hacer? En muchos proyectos simplemente se plantea recuperar el retraso más tarde, pero nunca se hace. Aprenderemos más
del producto conforme lo estamos construyendo, in​cluyendo más sobre lo que nos llevará construirlo. Estos conocimientos necesitan reflejarse en la reestimación del plan. Otro tipo de error en la reestimación se debe a cambios en el produc​to.
Si el producto que estamos construyendo cambia, la cantidad de tiempo necesaria para construirlo cambiará también.
En el Ejemplo 3.1, los reque​rimientos principales cambiaron entre la propuesta original y el comienzo del proyecto sin la correspondiente reestimación del plan o de los recursos. El crecimiento de las nuevas prestaciones sin ajustar el plan garantiza que no se alcanzará la fecha de entrega. 27: Programación a destajo. Algunas organizaciones creen
que la co​dificación rápida, libre, tal como salga, es el camino hacia el desarrollo rápido. Piensan que si los desarrolladores están lo suficientemente moti​vados, pueden solventar cualquier obstáculo. Debido a las razones que se verán claramente a lo largo de todo este libro, esto está lejos de la verdad. Este enfoque muchas veces se presenta como un
enfoque «empresariab) al desarrollo de software, pero realmente es sólo la envoltura del viejo paradigma a destajo combinado con una planificación ambiciosa, y esta combinación raras veces funciona. Es un ejemplo de que dos negaciones no constituyen una verdad. Producto A continuación se muestran los errores clásicos relacionados con la for​ma
en la que se define el producto. 54 Desarrollo y gestión de proyectos informáticos REFERENCIA CRUZADA Para más información sobre el cambio de prestaciones, consulte el Capítulo 14, «Control del conjunto de prestaciones». REFERENCIA CRUZADA Para consultar un ejemplo sobre cómo, incluso accidentalmente, un desarrollador puede caer en
requerimientos excesivos o superfluos, véase «Objetivos poco claros o imposibles», en la Sección 14.2. 28: Exceso de requerimientos. Algunos proyectos tienen más reque​rimientos de los que necesitan, desde el mismo inicio. La eficiencia se fija como requisito más a menudo de lo que es necesario, y puede generar una planificación del software
innecesariamente larga. Los usuarios tien​den a interesarse menos en las prestaciones complejas que en las de las secciones de marketing o de desarrollo, y las prestaciones complejas alar​gan desproporcionadamente el plan de desarrollo. 29: Cambio de las prestaciones. Incluso si hemos evitado con éxito los requerimientos excesivos, los proyectos
sufren como media sobre un 25 por 100 de cambios en los requerimientos a lo largo de su vida (Jo​nes, 1994). Un cambio de este calibre puede producir un aumento en el plan de al menos un 25 por 100, lo que puede ser fatal para los proyectos de desarrollo rápido. 30: Desarrolladores meticulosos. Los desarrolladores encuentran fascinante la nueva
tecnología, y a veces están ansiosos por probar nuevas prestaciones de su lenguaje o entorno, o por crear su propia implementa​ción de una utilidad bonita que han visto en otro producto, la nece​site o no su producto. El esfuerzo requerido para diseñar, implementar, probar, documentar o mantener estas prestaciones innecesarias alarga el plan. 31:
Tiras y aflojas en la negociación. Cuando un directivo aprueba un retraso en el plan de un proyecto que progresa más lento de lo espera​do, y entonces añade tareas completamente nuevas después de un cambio en el plan, se produce una situación curiosa. La razón subyacente de esto es dificil de localizar, puesto que el directivo que aprueba el
retraso en el plan lo hace sabiendo implícitamente que el plan estaba equivocado. Pero una vez que se corrige, la misma persona realiza acciones explícitas para volver a equivocarse. Esto sólo puede ir en contra del plan. 32: Desarrollo orientado a la investigación. Seymour Cray, el di​señador de los supercomputadores Cray, dijo que no intentaba
sobrepasar los límites de la ingeniería en más de dos áreas a la vez, porque el riesgo de un fallo es demasiado alto (Gilb, 1988). Muchos proyectos software debe​rían aprender la lección de Cray. Si el proyecto fuerza los límites de la informática porque necesita la creación de nuevos algoritmos o de nuevas técnicas de computación, no estamos
desarrollando software; estamos investigando en software. Los planes de desarrollo de software son razona​blemente predecibles; los planes en la investigación sobre software ni siquiera son predecibles teóricamente. Si el producto tiene objetivos que pretenden aumentar los conocimientos REFERENCIA CRUZADA Para más información sobre el
síndrome de la panacea, consulte la Sección 15.5, «El síndrome de la panacea ... REFERENCIA CRUZADA Para más información sobre cómo salvar las estimaciones usando herramientas de mejora de productividad, consulte "Reducción realista del plan .. , en la Sección 15.4. REFERENCIA CRUZADA Para más información sobre la reutilización,
consulte el Capitulo 33, "Reutilización ... Capítulo 3: Errores clásicos 55 existentes, como algoritmos, velocidad, utilización de la memoria y de​más, debemos asumir que la planificación es altamente especulativa. Si queremos mejorar el estado del arte y tenemos algún otro punto débil en el proyecto, recortes de personal, debilidades en el personal,
requerimientos vagos, interfaces inestables con contratados externos, etc., podemos tirar por la ventana la planificación prevista.
Si queremos superar el estado del arte por todos los medios, hagámoslo. ¡Pero no debemos esperar hacerlo rápidamente! Tecnología El resto de los errores clásicos están relacionados con el uso correcto o incorrecto de la tecnología moderna. 33: Síndrome de la panacea. En el ejemplo, se confió demasiado en las ventajas proclamadas de tecnologías
que no se habían usado antes (generadores de informes, diseño orientado a objetos y C++) y demasiada poca información sobre lo buenas que serían en este entorno de desarrollo concreto. Cuando el equipo del proyecto se aferra sólo a una nueva téc​nica, una nueva tecnología o un proceso rígido, y espera resolver con ello sus problemas de
planificación, está inevitablemente equivocado (Jo​nes, 1994). 34: Sobreestimación de las ventajas del empleo de nuevas herra​mientas o métodos. Las organizaciones mejoran raramente su produc​tividad a grandes saltos, sin importar cuántas nuevas herramientas o mé​todos empleen o lo buenos que sean. Los beneficios de las nuevas técnicas son
parcialmente desplazados por las curvas de aprendizaje que llevan asociadas, y aprender a utilizar nuevas técnicas para aprovecharlas al máximo lleva su tiempo. Las nuevas técnicas también suponen nuevos riesgos, que sólo descubriremos usándolas. Más bien experimentaremos mejoras lentas y continuas en un pequeño porcentaje por proyecto en
lu​gar de grandes saltos. El equipo del Ejemplo 3.1 debería haber previsto como mucho un 10 por 100 de ganancia en productividad por la utiliza​ción de las nuevas tecnologías en vez de asumir que estarían cerca de duplicar su productividad. Un caso especial de sobreestimaciones de las mejoras se produce cuan​do se reutiliza código de proyectos
anteriores. Este tipo de reutilización puede ser una técnica muy efectiva, pero el tiempo que se gana no es tan grande como se espera.
35: Cambiar de herramientas a mitad del proyecto.
Es un viejo recurso que funciona raramente. A veces puede tener sentido actualizar 56 Desarrollo y gestión de proyectos informáticos REFERENCIA CRUZADA Para más información sobre el control del código fuente, consulte «Gestión de la configuración del software», en la Sección 4.2. incrementalmente dentro de la misma línea de productos, de la
versión 3 a la 3.1, o incluso a la 4. Pero cuando estamos a la mitad de un proyecto, la curva de aprendizaje, rehacer el trabajo y los inevitables errores cometi​dos con una herramienta totalmente nueva, normalmente anulan cualquier posible beneficio. 36: Falta de control automático del código fuente. Un fallo en la utilización del control automático
del código fuente expone a los proyectos a riesgos innecesarios. Sin él, si dos desarrolladores están trabajando en la misma parte del programa, deben coordinar su trabajo manualmente. De​berían ponerse de acuerdo para poner la última versión de cada archivo en el directorio maestro y verificarlos con los demás antes de copiarlas en este directorio.
Pero invariablemente alguno sobreescribirá el trabajo del otro. Se desarrolla nuevo código con interfaces desfasadas, y después se tiene que rediseñar el código al descubrir que se ha utilizado una versión equivocada de la interfaz. Los usuarios avisan de errores que no podemos reproducir porque no hay forma de volver a crear los elementos que han
utilizado. Como media, los cambios en el código fuente suelen ser de un 1 O por 100 al mes, y con un control manual del código fuente no deberían crecer (Jones, 1994). La Tabla 3.1, de la página siguiente, contiene una lista completa de los errores clásicos. 3.4. La fuga de La isla de Gilligan Una lista completa de los errores clásicos ocuparía muchas
más páginas, pero los que se indican son los más comunes y los más serios. Como indicó David Umpress, de la Universidad de Seattle, la vigilancia que la mayoría de las organizaciones realiza para evitar estos errores es como ver una y otra vez La isla de Gilligan. Al principio de cada episodio, Gilligan, el Capitán o el Profesor llegaban con un plan
tonto para salir de la isla. El plan parecía funcionar inicialmente, pero, como revelaba el episodio, algo iba mal, y al final del episodio los náufragos volvían donde habían empeza​do, perdidos en la isla. De igual forma, la mayoría de las compañías descubre al final de cada proyecto que han cometido otro error clásico y que han entregado otro proyecto
fuera de plazo, con mayor coste, o ambas cosas. Su propia lista de malos hábitos Debe ser cuidadoso con los errores clásicos. Puede crear listas de «malos hábitos» para evitarlos en futuros proyectos.
Comience por la lista que apa- Tabla 3.1. Resumen de los errores clásicos Errores relacionados con las personas l.
Motivación débil 2. Personal mediocre 3. Empleados problemáticos incontrolados 4. Hazañas 5. Añadir más personal a un proyecto retrasado 6.
Oficinas repletas y ruidosas 7. Fricciones entre los clientes y los desarrolladores 8. Expectativas poco realistas 9. Falta de un promotor efectivo del proyecto 10. Falta de participación de los implicados 11. Falta de participación del usuario 12. Política antes que desarrollo 13. Ilusiones Errores relacionados con el proceso 14. Planificación
excesivamente optimista 15. Gestión de riesgos insuficiente 16. Fallos de los contratados 17. Planificación insuficiente 18. Abandono de la planificación bajo presión 19. Pérdida de tiempo en el inicio difuso 20. Escatimar en las actividades iniciales 21.
Diseño inadecuado 22. Escatimar en el control de calidad 23. Control insuficiente de la directiva 24. Convergencia prematura o excesivamente frecuente 25. Omitir tareas necesarias en la estimación 26. Planificar ponerse al día más adelante 27. Programación a destajo Capítulo 3: Errores clásicos 57 Errores relacionados con el producto 28. Exceso
de requerimientos 29. Cambio de las prestaciones 30. Desarrolladores meticulosos 31. Tiras y aflojas en la negociación 32. Desarrollo orientado a la investigación Errores relacionados con la tecnología 33. Síndrome de la panacea 34. Sobreestimación de las ventajas del empleo de nuevas herramientas o métodos 35. Cambiar de herramientas a mitad
del proyecto 36.
Falta de control automático del código fuente rece en este capítulo.
Vaya incrementando la lista según se vayan acabando proyectos para aprender de los errores cometidos por su equipo. Estimule este comportamiento para otros proyectos dentro de la empresa, para 58 Desarrollo y gestión de proyectos informáticos aprender de sus errores. Intercambie experiencias con los colegas de otras organizaciones y aprenda
de su experiencia. Exhiba en lugar visible la lista de errores, y así la gente la verá y aprenderá sin cometer de nuevo los mismos errores. Bibliografía adicional Aunque algunos libros tratan sobre errores de código, no conozco libros que describan los errores clásicos relacionados con los planes de desarrollo. En el resto de este libro se incluyen
referencias sobre temas relacionados.Page 2 8/17/2019 1. PLC1-SESION1 1/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza AOMAIACION LGICA CABLEADA LGICA OGAMADACONOLADOE LGICO OGAMABLE E:I. E E.
M 8/17/2019 1. PLC1-SESION1 2/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza E : PulsadorMarcha Pulsador Paro Interruptor de posición Contactorde Fuerza Lámparas Display 8/17/2019 1. PLC1-SESION1 3/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza ABLEO ELECICO: AOMAIACION BAADA EN
LA LGICA CABLEADA. 8/17/2019 1. PLC1-SESION1 4/21 8/17/2019 1. PLC1-SESION1 5/21 8/17/2019 1. PLC1-SESION1 6/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza ?
Definición IEC 61131 (A) (), , ,, , , , . AP = PLC Autómata programable = Programmable Logic Controller 8/17/2019 1. PLC1-SESION1 7/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza ? 1969 . Justificación de los AP Aportaciones de los AP . ( ). . . . . () . + Competencia => Nuevos Modelos en - Tiempo, + Baratos y + Calidad
8/17/2019 1. PLC1-SESION1 8/21 8/17/2019 1. PLC1-SESION1 9/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza E : M .
. M .M .M . .M . .F C (M) : A .C. 8/17/2019 1.
PLC1-SESION1 10/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza F MED MD ME/ MC 220230 AC 24 DC 5 DC (, .) A( , .) (, )A ( ) ME(,,ID ... C E/ C E/ B 8/17/2019 1. PLC1-SESION1 11/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza B 7300 C AB M340 B 7400 8/17/2019 1. PLC1-SESION1 12/21
8/17/2019 1. PLC1-SESION1 13/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza () LC COMACO MODLA 71200 DEIEMEN LC COMACO MODLA MICOLLOGI 1100 DE OCKELL LC COMACO MODLA M241 DECHNEIDE 8/17/2019 1. PLC1-SESION1 14/21 8/17/2019 1. PLC1-SESION1 15/21 AUTOMATIZACIÓN INDUSTRIAL
FIEE UNACIng. Elmer Mendoza ( ) , , , ; , LC .
L AM , LC , . ( ) ; . N . E LC; BIO LC . G BIO LC (N) (OGAM), , AM , , . 8/17/2019 1. PLC1-SESION1 16/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza . L EOM ( EOM); EEOM , LC .
C AM LC , AM . E LC, BIO EOM. 8/17/2019 1. PLC1-SESION1 17/21 8/17/2019 1. PLC1-SESION1 18/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng.
Elmer Mendoza D C 1756L7 A B D C M340 BM342020 8/17/2019 1. PLC1-SESION1 19/21 8/17/2019 1. PLC1-SESION1 20/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza L , , , IN ENADA; LED.
E , . 8/17/2019 1. PLC1-SESION1 21/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza L , O ALIDA. E , LED . :A , A , A . M CC., AC E , , 0,5 2 A. A , , .
E (D/A) . Page 3 8/17/2019 1. PLC1-SESION1 1/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza AOMAIACION LGICA CABLEADA LGICA OGAMADACONOLADOE LGICO OGAMABLE E:I. E E. M 8/17/2019 1. PLC1-SESION1 2/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza E : PulsadorMarcha Pulsador
Paro Interruptor de posición Contactorde Fuerza Lámparas Display 8/17/2019 1. PLC1-SESION1 3/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza ABLEO ELECICO: AOMAIACION BAADA EN LA LGICA CABLEADA. 8/17/2019 1. PLC1-SESION1 4/21 8/17/2019 1. PLC1-SESION1 5/21 8/17/2019 1. PLC1-SESION1 6/21
AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza ? Definición IEC 61131 (A) (), , ,, , , , . AP = PLC Autómata programable = Programmable Logic Controller 8/17/2019 1. PLC1-SESION1 7/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza ? 1969 . Justificación de los AP Aportaciones de los AP . ( ). . . . . () . +
Competencia => Nuevos Modelos en - Tiempo, + Baratos y + Calidad 8/17/2019 1. PLC1-SESION1 8/21 8/17/2019 1. PLC1-SESION1 9/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza E : M . . M .M .M . .M .
.F C (M) : A .C. 8/17/2019 1. PLC1-SESION1 10/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza F MED MD ME/ MC 220230 AC 24 DC 5 DC (, .) A( , .) (, )A ( ) ME(,,ID ... C E/ C E/ B 8/17/2019 1. PLC1-SESION1 11/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza B 7300 C AB M340 B 7400 8/17/2019 1.
PLC1-SESION1 12/21 8/17/2019 1. PLC1-SESION1 13/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza () LC COMACO MODLA 71200 DEIEMEN LC COMACO MODLA MICOLLOGI 1100 DE OCKELL LC COMACO MODLA M241 DECHNEIDE 8/17/2019 1. PLC1-SESION1 14/21 8/17/2019 1. PLC1-SESION1 15/21
AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng.
Elmer Mendoza ( ) , , , ; , LC . L AM , LC , . ( ) ; . N . E LC; BIO LC . G BIO LC (N) (OGAM), , AM , , . 8/17/2019 1. PLC1-SESION1 16/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza . L EOM ( EOM); EEOM , LC . C AM LC , AM . E LC, BIO EOM. 8/17/2019 1. PLC1-SESION1 17/21 8/17/2019 1. PLC1-SESION1 18/21
AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza D C 1756L7 A B D C M340 BM342020 8/17/2019 1.
PLC1-SESION1 19/21 8/17/2019 1. PLC1-SESION1 20/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza L , , , IN ENADA; LED. E , . 8/17/2019 1. PLC1-SESION1 21/21 AUTOMATIZACIÓN INDUSTRIAL FIEE UNACIng. Elmer Mendoza L , O ALIDA. E , LED . :A , A , A . M CC., AC E , , 0,5 2 A. A , , . E (D/A) . Academia.edu uses
cookies to personalize content, tailor ads and improve the user experience. By using our site, you agree to our collection of information through the use of cookies. To learn more, view our Privacy Policy.