Estem dissenyant una classe Subjecte en la que s’executen operacions que empren serveis que:

• No es troben dins l'àmbit de la nostra aplicació, o
• Son costosos de crear, i no volem que la nostra aplicació assumeixi la responsabilitat de crear-los, o
• Estan subjectes a una política d'accessos o de permisos diferent, o
• Es vol incloure més seguretat o més control sobre un servei extern, (per ex: controlar l'ús que es fa de l'objecte, implementar una estadística, controlar bloqueigos d'altres parts quan es fa ús de l'objecte, etc.)

Estem dissenyant una classe que necessita d'un servei, que ja hem implementat anteriorment i que volem reutilitzar. Però la signatura dels mètodes que volem reutilitzar no s'adapten exactament als requeriments de la nova classe. En aquests casos podem:

1. Modificar la classe que proporciona el servei:
• Modificant els mètodes per adaptar-los a les noves necessitats, o
• Creant nous mètodes per proporcionar el servei que necessita la nova classe.
2.  O bé: Modificar la nova classe, de forma que s'adapti als requeriments del servei ja implementat.
3. O bé: Crear un adaptador, que faci de pont entre la funcionalitat esperada per la nova classe, i la que proporciona el servei ja implementat.

"Afegir mes personal a un projecte endarrerit només provoca encara més endarreriment". Fred Brooks, "The Mythical Man-month”.

L'estimació de costos dels projectes acostuma a fer creure que el progrés d'un projecte pot medir-se en les hores/home o dies/home que s'han executat i, por tant, en les que manquen. D'aquesta reflexió es pot extreure la conclusió errònia de que homes i mesos son intercambiables.

Això es veritat només quan una tasca pot ser adjudicada a moltes persones de forma que l'executen en paral·lel: pintar una façana, netejar un edifici, recollir una collita, atendre comandes per telèfon, etc. Per altra banda, quan la tasca implica comunicació seqüèncial entre les persones que participen, (una persona entrega parcialment una tasca que una altra persona continua/complementa, que al seu torn li passa a una altra, etc). Això dona a la tasca un caràcter seqüèncial que impedeix obtenir un benefici pel fet d'assignar més persones a la tasca. Como diu Brooks, "Per la concepció d'un nadó son necessaris 9 mesos, no importa quantes dones s'assignen a la tasca".

En projectes d'informàtica, algunes tasques necessiten de la finalització d'altres, i alhora aquestes son necessàries per a l'inici d'altres tasques posteriors. Altres tasques, per contra, poden executar-se en paral·lel. I per últim, altres tasques accepten cert grau de paral·lelisme amb punts de comunicació que obliguen a la sincronització. Per tant, l'esforç necessari per a mantenir les comunicacions i les sincronitzacions s'han de tenir presents a l'hora de calcular l'esforç.

Al incorporar nou personal al projecte, apareix un cost inicial corresponent al entrenament, que sovint no es te present: Les noves incorporacions han d'aprendre la terminologia de l'equip, les tècniques per la fabricació d'allò objecte de projecte, les variants particulars que s'apliquen a l'equip, l'estratègia amb la que l'equip porta la seva feina i la seva gestió i, també important, comprendre quines responsabilitats pertoquen a aquestes noves incorporacions, (com s'engranen amb la resta de l'equip). Veure: Corba d'aprenentatge

A més, aquestes noves incorporacions impliquen noves línies de comunicació entre tots els components de l'equip i aquestes incorporacions o, en el millor dels casos, amb cada grup d'especialitat de l'equip. Aquestes interaccions alenteixen el decurs del projecte fins a un punt que, a partir de cert nombre d'incorporacions, tant la corba d'aprenentatge com el cost de les comunicacions fan inviable l'execució de la tasca.

El presente documento es una introducción a las principales técnicas en la gestión del ciclo de vida del desarrollo de Sistemas de Información, documentación y metodologías de desarrollo.

Descarrega el document pdf