L'objectiu d'aquest document és poder oferir al públic CATALA d'Internet la possibilitat d'aprendre nocions bàsiques de metodologia de desenvolupament de software en la seva pròpia llengua, la catalana. En una xarxa on l’anglès és l’idioma de difusió del coneixement, algú pensarà que és absurd restringir-se a un públic tant reduït, però no és la intenció d’aquest document donar a conèixer cap nova teoria sinó només explicar el que altres ja han descobert. Aquest document és un repte personal com a informàtic i català que sóc, i espero, tot i que és una aportació molt petita, que algú o altre en pugui treure profit.

Jordi Puigneró

Sant Cugat del Vallès

18 de Setembre de 2001

El "Rational Objectory Process" (o simplement Objectory) és el resultat del treball d'unificació dels diversos processos de desenvolupament de ‘software’ dels tres metodologistes més importants dels últims temps: Booch, Rumbaugh i Jacobson.

A continuació podem veure les fases d’alt nivell de l’estructura de l’Objectory.

L’ ‘Objectory Process’ és bidimensional, ja que és incremental (Concepció,Elaboració,Construcció i Transició) i iteratiu (anàlisi, disseny, implementació i testeig) a la vegada.

Val la pena no confondre l’Objectory amb l'UML que també ha estat creat pels tres gurús abans mencionats. L’UML és un llenguatge de modelació, no pas una metodologia. L'UML no té cap noció del procés, sinó que juga un rol important dins del procés. Per la seva magnitud, l’UML mereix ser tractat profundament. És per això que per a més informació, i més exhaustiva, del llenguatge UML, podeu referir-vos als nombrosos llibres i documentació que trobareu a llibreries o a Internet mateix, ja que en aquest document, tot i fer-ne menció sovint, no tractarem el tema directament. Si que he de dir, però, que quan tingui temps, publicaré en aquesta mateixa web un tutorial en català de l’UML.

Tornant al tema que ens ocupa, la finalitat de tot procés de desenvolupament és acabar entregant un aplicatiu informàtic. En l’Objectory, el software produït no s'entrega d'un sol cop al final del projecte sinó que es desenvolupa i s'entrega per parts que es va fent en diverses entregues.

Tal i com es pot veure en el diagrama anterior, l’ ‘Objectory Process’ està estructurat en quatre fases :

A la fase de concepció s'estableixen les raons de negoci i l'abast del projecte. La conseqüència d'aquesta fase ha de ser un compromís garantit amb el ‘client/sponsor/jefe’ per continuar endavant.

A la fase d’elaboració es recullen més requeriments i més detallats, es fa una anàlisi i un disseny tècnic del model de negoci així com una anàlisi i un disseny d'alt nivell de l'arquitectura. En aquesta fase, a més a més, elaborarem una planificació per la fase de construcció.

La fase de construcció és iterativa, on cada iteració construeix software de qualitat per producció (testejat i integrat) que satisfà una part dels requeriments del projecte.

La fase de transició inclou tasques com ara : ‘beta-testing’, optimització del rendiment, empaquetament de l’entregable i instal·lació, i formació de l’usuari.

La utilització de la iteració en la fase de Construcció d'aquest procés és una pràctica necessària i suficient pels projectes petits , però insuficient pels projectes grans (on es recomana iterar també a la resta de fases). El motiu és ben senzill : la burocràcia varia segons projectes i empreses. La fase de concepció d'un projecte petit en una empresa tecnològica consistirà segurament d'una xerrada d'una hora i d'una planificació en una fulla de càlcul. En canvi el mateix projecte però aquest cop realitzat pel departament d'informàtica d'un banc comportaria piles de reunions i documents, o sigui més burocràcia. Normalment a projectes més grans més burocràcia i per tant més necessitat de revisar i controlar els processos, el que implica la necessitat d'introduir iteracions, també, a les fases de concepció i elaboració.

La concepció d'un projecte pot ésser de diverses maneres. Per alguns projectes, és una simple xerrada a la màquina de cafè : "Joan, mira com posar el catàleg de serveis a la web de l'empresa". Per projectes més grans, segurament serà un estudi de viabilitat de 3 o 4 mesos de feina.

Les dues tasques fonamentals d'aquesta fase són:

a) Analitzar les raons/oportunitats de negoci (quant costarà, quins beneficis ens reportarà)

b) Definir l'abast i la mida del projecte.

De totes maneres el que realment hauria de ser la fase de concepció és "un parell de dies per reflexionar si val la pena dedicar els pròxims dos mesos, d'investigació exhaustiva, a la fase elaboració del projecte".

Si no volem perdre el temps i els diners que s’invertiran, abans d’iniciar aquesta fase del projecte, hauríem d’estar segurs que els nostres superiors/clients ens han donat el "tret de sortida", i molt millor si és de forma manuscrita.

Bé doncs, un cop aclarida aquesta premissa, els objectius d’aquesta fase passen per respondre exhaustivament les següents preguntes :

• Què és el que hem de construir exactament?
• Com ho construirem ?
• Quina tecnologia farem servir ?

Quan intentem respondre aquestes preguntes haurem de tenir en compte els "riscos" inherents del projecte i que ens podrien portar al fracàs. De riscos n’hi ha de moltes menes, però es podrien classificar en 4 grups :

• Riscos de Requeriments : el gran perill de tot projecte és acabar construint un sistema que no fa el que el client vol. És per això que és molt important que durant la fase d’elaboració fem una bona i exhaustiva feina de subtracció de requeriments.

• Riscos Tecnològics : tenim suficient experiència en OO i/o tecnologia Java ?

• Riscos de mà d’obra qualificada : tenim o podem trobar professionals experts en el tema ?

• Riscos polítics : hi ha poders fàctics dins de l’empresa que vulguin fer fracassar el projecte per motius aliens als del projecte en sí ?

Una bona manera per entendre’s amb el client en el moment de definir requeriments és utilitzar les tècniques de l’UML.

La tècnica de punt de partida és el useCase. Un useCase és una interacció típica que un usuari té amb un sistema amb l’objectiu d’assolir una fita. Per exemple, en l’àmbit d’un processador de text, un useCase seria "subratllar el text seleccionat d’un document" o "crea un índex al document", etc.

Els useCases són la base de comunicació entre el client i el desenvolupador en la planificació del projecte.

Una de les tasques més importants en la fase d’elaboració és la de definició de tots els useCases potencials del sistema que hem de construir. A la pràctica, però, no farà falta que els definim tots, amb els més importants en tindrem prou. És precisament en aquesta fase d’elaboració on anirem a parlar amb el client/usuari amb la intenció d’obtenir d’ell tots els possibles useCases.

Els useCases no fa falta que siguin gaire detallats, una frase d’un sol ha de ser suficient per descriure un escenari. A continuació podem veure l’escenari d’un sistema financer explicat en diversos diagrames useCase :

De totes maneres, només amb els useCases no n’hi ha prou per poder descriure tot el sistema. Una altra tasca important és la de definir un model conceptual del domini del sistema. Un model conceptual del domini ha de ser un "conjunt de descripcions breus de cadascun dels conceptes i processos inherents al sistema (en forma escrita i/o amb diagrames").

Hi ha dues tècniques d’UML molt útils alhora de crear models conceptuals:

• El diagrama de classes és collonut per representar els conceptes (i les relacions entre conceptes) del negoci d’una manera gràfica i sintètica. El diagrama de classes és l’abstracció del model d’objectes/dades tradicional, on mostrem l’estructura estàtica del sistema (conceptes + relacions), i que és molt útil alhora de definir/aclarir aspectes del sistema amb el client/usuari. A continuació podem veure un exemple de modelació del concepte "làmpada".

• El diagrama d’activitats complementa el diagrama de classes descrivint el procés del negoci. L’element clau d’aquest tipus de diagrama és que encoratja la recerca de processos paral·lels, eliminant sequències innecessàries en els processos de negoci. A continuació podem veure el diagrama d’activitats d’un sistema de comandes.

En aquest punt, i amb l’ajuda del client, el model conceptual ens serà molt útil per descobrir més useCases. De la mateixa manera els useCases ens serviran per modificar aspectes del model conceptual que potser no s’havien rumiat prou.

Arribat en aquest punt és també molt útil crear diferents perspectives de detall del model conceptual (de menys nivell de detall a més). No és el mateix haver de discutir aspectes del disseny conceptual amb un director general que amb un programador. En un model conceptual d’alt nivell, les classes estarien agrupades en "packages"(paquets), mentre que en un model conceptual de més detall, entre altres coses, el diagrama de classes aniria acompanyat per diagrames d’estat d’aquelles classes que tinguessin un cicle de vida interessant.

L’equip encarregat de crear el model conceptual hauria de ser petitet (entre 2 i 4 persones) i que inclogués almenys un programador sènior i un expert del domini del sistema del negoci. És imprescindible que tots els components d’aquest equipet tinguin nocions d’UML, ja que serà el llenguatge de principal de comunicació del projecte durant aquesta fase i posteriors. És per això que fora interessant dedicar un parell de dies a repassar els elements essencials de dit llenguatge de modelació, i si més no, per estandarditzar l’estructura i el nivell de profunditat de la documentació que es produirà en aquesta fase.

Com a complement del model conceptual, i sempre que el temps ho permeti, la construcció d’un prototip d’aquelles parts del sistema més importants ens ajudarà a entendre millor la dinàmica del sistema. Tenint en compte l’adversitat que tenen els ‘jefes’ envers els diagrames tècnics i els documents funcionals , crec que el millor avantatge de prototipar és la de copsar l’interès i satisfacció d’aquest ‘management’ pel nostre aplicatiu molt abans de la seva primera versió beta. Rectificar un disseny abans que cap programador hagi teclejat una sola línia de codi no té pràcticament cap cost. En canvi haver-ho de fer sobre un disseny ja implementat té un cost extraordinari.

La millor manera de minimitzar els possibles riscos tecnològics és la d’avaluar, quan més aviat millor, els diversos paquets de ‘software’ i tecnològics que pensem utilitzar.

Per exemple, diguem que pel nostre projecte volem utilitzar C++ com a llenguatge de programació i una base de dades relacional com a sistema d’emmagatzemament de dades. Doncs bé, aquests són els passos a seguir per minimitzar riscos :

1. Obtenir els compiladors de C++ i altres eines.
2. Construir una part senzilla del sistema a partir del model conceptual.
3. Construir la base de dades i connectar-la al codi C++.
4. Provar altres eines. Veure quina és la millor combinació de plataforma de Desenvolupament, compilador i base de dades.

No oblidem que la majoria de problemes tecnològics són inherents a com els diversos components d’un disseny encaixen entre si, no pas per algun problema intern d’algun d’ells. Podem ser experts en C++ i tenir molts bons coneixements de bases de dades relacionals, i tot i així, trobar-nos amb dificultats alhora de fer la integració. D’aquí la importància de fer una integració de prova i a petita escala quan més aviat millor.

També seria important, a aquestes alçades, començar a plantejar-se els temes d’arquitectura d’alt nivell, sobretot si el projecte consisteix en construir un sistema distribuït.

Per aquesta fase del projecte hi ha diverses tècniques UML que ens poden ser útils per organitzar i presentar les nostres idees i documents:

• El diagrama de classes i el diagrama d’interaccions són molt útils per entendre com els diferents components es comuniquen entre ells.
• El "package diagram" és molt útil per tenir una visió d’alt nivell dels components.
• El "deployment diagram" ens pot ajudar a tenir una visió general de com les diferents parts del sistema estan distribuïdes.

Tracto sovint amb gent que d’una manera o altre estan o han estat involucrats en projectes orientats a objectes. I gairebé sempre, quan els pregunto quins han estat els principals errors comesos durant el projecte , tots acabem arribant a la mateixa conclusió : "hauríem d’haver invertit més temps en formació".

La tecnologia OO és una tecnologia de fa pocs anys i té encara grans mancances de professionals experts. Això, més les poques ganes dels ‘jefes’ de pagar cursos als empleats, fa que les empreses s’embarquin en grans projectes OO amb pocs o cap professional experimentat. És curiós que hi hagi sempre tantes reticències a pagar cursos, i en canvi cap recança a pagar les extensions de temps d’aquells projectes que es demoren, normalment, per culpa d’errors que no s’haurien comès si s’hagués fet un curs com Deu mana. L’experiència m’ha demostrat que al final acabes pagant el mateix en ambdós casos, però, en el cas del projecte sense formació, amb el greuge de patir una demora de temps en el projecte.

De totes maneres, he de dir que no sóc un gran entusiasta dels cursos que imparteixen moltes empreses de formació, si més no els referents a millorar els coneixements en OO. La majoria d’aquests cursos fan un repàs exhaustiu dels principis teòrics de l’OO, però obliden ensenyar les tècniques OO i la seva aplicació, amb la conseqüència que l’alumne no surt preparat per afrontar cap projecte de mitjana-alta dificultat.

La manera més barata i ràpida per aprendre OO és a través del que se’n diu el "mentoring". El ‘mentoring’ consisteix en tenir un expert en la matèria (el mentor) treballant en el projecte durant un cert temps. El mentor s’encarregarà de dedicar un parell d’hores diàries a la formació dels components del projecte, i la resta del dia a donar suport a aquestes mateixes persones en el desenvolupament del projecte. D’aquesta manera, matem dos pardals d’un sol tret, ja que el programador aprèn i és productiu a la vegada. És cert que aquest mètode pot fer alentir el desenvolupament inicial del projecte, però a canvi aconsegueix un aprenentatge molt eficient dels programadors, ja que tot el que aprenen pel matí, ho apliquen per la tarda en un entorn real de treball. Un altre avantatge és la de tenir un expert a l’equip durant un cert temps ajudant en el desenvolupament inicial del projecte, etapa que és precisament la més crítica ja que és on es dissenyen els fonaments del sistema, els quals marcaran tota la posterior construcció. La tècnica del ‘mentoring’ com a solució a la formació d’un equip per a un projecte té, però, un aspecte crític : l’elecció del mentor. No sempre el mentor més car és el millor, i a més a més sempre correrem el risc de fitxar un "venedor de fum". La meva recomanació és "busca i prova , i quan en trobis un que val la pena, mantén-lo a qualsevol preu ". Pensa que els diners de més que li vulguis deixar de pagar seran molts inferiors als que perdràs en temps i en "mentors rana" que vagis provant fins a trobar-ne un altre de vàlid.

La fiabilitat de les respostes que podria donar a aquesta pregunta són semblants a les que et podria donar un corredor de borsa del ‘perquè’ invertir en un valor o en un altre. Per tant, em limitaré a donar el següent consell : "a més bones relacions amb els teus jefes i amb els jefes dels teus jefes, menys risc".

El resultat de la fase d’elaboració ha de ser un seguit de documents que contemplin els següents aspectes :

• Una llista de useCases, que són els que em defineixen els requeriments.
• El model conceptual del domini, el qual em proporciona la comprensió i visió global del negoci i que m’ha de servir com punt de sortida en la creació de les classes bàsiques del sistema.
• La plataforma tecnològica, la qual em descriu les peces claus de la tecnologia de desenvolupament i com encaixen entre si.

L’experiència em diu que la fase d’elaboració té normalment una durada equivalent a una cinquena part del total del projecte.

L’essència de la planificació consisteix en quantificar el numero d’iteracions que farem a la fase de construcció i assignar-hi useCases.

El primer pas és classificar els useCases per nivells de :

• Prioritat : (s’ha de tenir),(s’ha de tenir quan més aviat millor),(s’hauria de tenir)
• Risc: (alt),(mitjà),(poc)
• Risc de durada : (Coneguda),(la puc estimar),(ni idea).

El segon pas és estimar la durada en temps (home/setmana) de cada useCase. L’estimació ha de tenir en compte que cada useCase requerirà "anàlisi-disseny-implementació-testing-documentació".

Tant les tasques del primer pas com les del segon han de ser realitzades pels desenvolupadors ( a poder ser els més experimentats).

El tercer pas consistirà en determinar la durada de les iteracions, les quals seran totes igual per així aconseguir un ritme de projecte constant. Una iteració hauria de ser suficientment llarga per poder fer uns quants useCases. Normalment en l’entorn SmallTalk les iteracions són de dues o tres setmanes, mentre que en un entorn C++ ens n’aniríem a xifres de 6-8 setmanes.

El quart pas consistirà en determinar l’esforç necessari per cada iteració. Un bon punt de sortida és suposar que els desenvolupadors treballaran amb una eficiència del 50%. Llavors multipliquem la durada de la iteració pel nombre de desenvolupadors i per 0.5 (l’eficiència). El resultat serà l’esforç necessari per iteració. A continuació sumem el temps de tots els UseCases, dividim per l’esforç d’iteració, i tindrem la primera estimació del número d’iteracions necessàries pel nostre projecte.

El següent pas és repartir els useCases entre les diverses iteracions. Aquí és recomanable col·locar els useCases més complicats o de més prioritat en les primeres iteracions, ja que així ens enfrontem amb el risc abans i per tant tindrem més temps per sol·lucionar les incidències resultants.

Pels temes de "optimització del rendiment" i "empaquetament per entrega" de l’etapa de Transició, afegeix entre un 10 i un 35% del temps de construcció. Finalment afegeix un factor de contingència depenent del risc que veus en el projecte (factor que no hauria de superar un 20% del total del temps de construcció).

Finalment tenim una planificació de durada del projecte , que tot i només ser una estimació, ens ha de servir, si més no, d’orientació.

La construcció basa el desenvolupament del sistema en una sèrie d’iteracions, on cada iteració és un mini-projecte. Per cada useCase assignat a cada iteració farem "anàlisi, disseny, implementació, testing i integració". La iteració l’acabarem amb una ‘demo’ que presentarem a l’usuari i que ens servirà per validar que els useCases eren correctes.

La finalitat d’aquest procés (anàlisi, disseny, implementació, testing i integració) és minimitzar riscos. Moltes vegades es deixen les coses difícils pel final del projecte i això és un error, ja que llavors ja no hi ha temps de reaccionar. És per això que no podem deixar el ‘testeig’ i la integració pel final sinó que s’ha d’anar fent a cada iteració.

Les iteracions en la fase de construcció són incrementals i iteratives :

• Les iteracions són incrementals en funcionalitat, on cada iteració es construeix en base als useCases desenvolupats en iteracions anteriors.

• Les iteracions són iteratives en codificació, on a cada iteració haurem de reescriure part del codi existent per tal de fer-lo més flexible. A aquesta tècnica de revisió de codi se l’anomena "refactoring", i es fa imprescindible a mesura que els programes es van engrandint, ja que és quan acostuma a aparèixer el principi d’entropia del software. Aquest principi ens diu que "els programes comencen en un estat inicial de disseny molt bo, però que a mesura que s’hi van afegint trossets de funcionalitat, els programes van perdent gradualment la seva estructura per acabar deformant-se del tot i acabar com un plat d’espaguetis". L’experiència ens diu que si en cada iteració no "refactorem" almenys un 10% del codi, llavors alguna cosa no va bé.

Segueix les següents recomancions:

• Utilitza el diagrama useCase per determinar l’abast.
• El diagrama de classes (conceptuals) et serà molt útil per veure a grans trets el sistema.
• Si el sistema conté molts processos, el diagrama d’activitats te’ls representarà molt bé.
• El diagrama de classes (d’especificació perspectiva) t’ajudarà a ‘mapejar’ les classes amb més detall.
• El diagrama d’interaccions t’ensenyarà com les interaccions entre classes ‘mapejen’ cadascun dels useCases.
• El diagrama de paquets ha de ser el teu mapa lògic del sistema, ja que és un diagrama que t’ajudarà a entendre les peces lògiques del sistema i les seves dependències.
• El diagrama d’estats et serà molt útil per descriure i entendre aquelles classes amb un comportament complex.
• En resum, el mínim indispensable de documentació hauria d’incloure els següents tres elements:

Una de les raons per les quals sorgeix el "Principi d’Entropia de Software" és perquè sovint sorgeixen noves funcionalitats no previstes en el disseny inicial de l’arquitectura i que normalment acaben sent integrades de mala manera per sobre de l’arquitectura existent del programa. L’opció alternativa, però més costosa en temps i diners, és la de redissenyar l’arquitectura del programa. Tot i que en teoria és millor redissenyar el programa, aquesta opció és més costosa en feina extra ja que segurament, al reescriure part del programa, introduiríem nous ‘bugs’ i problemes. Com diu la dita anglesa "redisigning causes short-term pain, for longer-term gain". El problema és que la pressió de les dates d’entregada fa que sovint la gent prefereixi posposar aquest dolor pel futur.

Les tècniques de ‘Refactoring’ precisament ens ajuden a reduir aquest "short-term pain" (dolor a curt termini). ‘Refactorar’ no consisteix en canviar la funcionalitat del programa, sinó en canviar l’estructura interna per fer-la més senzilla i fàcil de treballar-hi (més ‘manejable’).

Principis del ‘Refactoring’ :

• No ‘refactoris’ i afegeixis funcionalitat a un programa a la mateixa vegada.
• Fes córrer diversos tests abans i després de ‘refactorar’ i comprova que els resultats siguin els mateixos.
• Com més petites siguin les unitats de ‘refactorament’ millor.

Quan és necessari ‘Refactorar’ ?

• Quan a l’afegir noves funcionalitats al programa ens trobem que el codi antic ens estorba.
• Quan tinguem dificultats per entendre el codi.

L’UML ens diu com expressar un disseny orientat a objectes. Els ‘patterns’ (o ‘patrons’, en català) són exemples de dissenys que modelen els resultats d’un procés ja documentat.

Els ‘patterns’ descriuen maneres comunes de fer les coses i són fruit de l’experiència. Un ‘pattern’ és més que un model. Un ‘pattern’ ha d’incloure el motiu del ‘perquè’ és de la manera que és. Sovint es diu que un ‘pattern’ és una solució a un problema. Un ‘pattern’ ha de deixar clar quin és el problema, explicar perquè soluciona el problema, i també explicar en quins casos funciona i en quins no.

En l’actualitat el tema dels ‘patterns’ encara és força novell i encara no hi ha molta informació al respecte. Però per qui estigui interessat, un dels llibres més influents sobre ‘patterns’ és el "Gamma et al. (1994)". Si el que voleu són exemples de ‘patterns’ d’arquitectura doneu un cop d’ull al "Design Patterns (Buschmann, 1996). I si el que voleu són ‘patterns’ de programació, jo us recomano el llibre d’en Kent Beck "SmallTalk Patterns (1996)", un llibre que si tot programador és revisés a l’inici de cada projecte, no veuríem les barbaritats de codificacions a l’estil ‘spagueti-western’ que es veuen a molts programes.

L’etapa de transició compren el temps entre la versió-beta i la versió final del producte. En l’etapa de transició no hi ha desenvolupament sinó que tota la codificació es redueix a la resolució de ‘bugs’ ( que no és poca feina ! ) i a la millora del rendiment del producte.

Passa sovint que molts productes de software, un cop acabats, no acaben de ser prou ràpids des del punt de vista de l’usuari o client. És en aquesta fase on aplicarem tècniques d’optimització per millorar la velocitat d’execució del nostre producte, això si, a canvi de perdre en claredat i extensibilitat.

Aquests petits inconvenients en els podem permetre ara que el producte ja el tenim acabat, ja que optimitzar en etapes anteriors perjudicaria seriosament la salut dels nostres desenvolupadors.

Finalment una tasca pròpia d’aquesta fase del projecte és la formació dels usuaris.