Software

Aurreko itemean zerrendatutako fase edo etapa bakoitzerako, azpi-etapak (edo zereginak) daude. Garapenerako erabiltzen den prozesu-ereduak edo bizi-zikloaren ereduak inplikatutako zereginen edo jardueren ordena definitzen du, eta horien arteko koordinazioa, lotura eta berrelikadura ere definitzen ditu[9]. Ezagunenen artean, honako hauek aipa daitezke: mailakako eredua edo eredu sekuentziala; eredu espirala; gehikuntza iteratibo eredua. Era berean, aipatutako horien artean eta eskatutako aplikazioaren eta eskakizunen arabera, badira aldaera edo alternatiba erakargarri batzuk[10].

Eredu horri eredu klasiko, eredu tradizional edo eredu lineal sekuentzial ere esaten zaio, nahiz eta arruntago teilakatuta dagoen eredua esaten zaion.

Teilakatu-eredu purua nekez erabiltzen da bere horretan, horrek berekin ekarriko bailuke baldintzak aldez aurretik eta erabat ezagutzea, baldintzen ez hegakortasuna (edo zurruntasuna) eta akatsik gabeko ondorengo etapak; hori garatu beharreko sistema urri eta txikiei bakarrik aplika dakieke. Egoera horretan, aipatutako etapetako batetik bestera pasatzeak ez luke itzulerarik izango; adibidez, diseinutik kodifikaziora pasatzeak diseinu zehatza eta akatsik gabea eta aldaketa edo eboluzio posiblerik gabea ekarriko luke: «kodifikatu diseinatutakoa akatsik gabe, ez da inolaz ere etorkizuneko aldaerarik egongo». Hori utopikoa da; izan ere, berez, softwarea izaera ebolutibokoa da[12], aldakorra eta akatsik gabea, bai garapenean, bai bizitza operatiboan ere[9].

2. irudia: Softwarearen bizi-ziklorako teilakatu puru edo sekuentziala.

Eredu sekuentzial horretan etaparen bat gauzatzean aldaketaren bat gertatuz gero, hasieratik ziklo osoa berrabiarazi beharko litzateke, eta horrek denbora eta garapen kostu handiak ekarriko lituzke. 2. irudiak eredu horren eskema posible bat erakusten du[9].

Hala ere, teilakatu-eredua, zenbait aldaeratan, gehien erabiltzen denetako bat da gaur egun[13], bere eraginkortasun eta sinpletasunagatik, beste ezer baino gehiago neurri txikiko softwarean eta neurri ertaineko batzuetan, baina inoiz ez (edo oso gutxitan) da bere forma puruan erabiltzen, lehen esan bezala. Horren ordez, beti gertatzen da etapen arteko berrelikaduraren bat, guztiz iragartzeko modukoa eta zurruna ez dena; horrek aukera ematen du bizi-zikloan zehar ziurgabetasun, aldaketa edo bilakaera jakin batzuk dituzten software-produktuak garatzeko. Adibidez, baldintzak (lehen etapa) atzitu eta zehaztu ondoren, sistemaren diseinuari ekin dakioke, baina litekeena da, azken fase horretan, eskakizunetan doikuntzak egin behar izatea (nahiz eta gutxienekoak izan), bai detektatutako akatsengatik, bai anbiguotasunengatik, bai betekizunak berak aldatu edo eboluzionatu egin direlako; beraz, lehenengo etapara edo aurretiko etapara itzuli behar da, dagozkion berregokitzeak egin eta, ondoren, berriz ere diseinuarekin jarraituz; azken horri, berrelikadura esaten zaio. Teilakatu-ereduan, orduan, eredu hori modu batean edo bestean berrelikatutako etapekin aplikatzea normalena da, batetik, aurrekora egin ahal izateko, beharrezkoa bada (eta, are gehiago, aurrekoetara salto egin ahal izateko).

Horrela, Berrelikatutako teilakatu-eredua lortzen da, eta 3. irudiak erakusten duen moduan eskematizatu daiteke.

3. irudia: Bizi-ziklorako berrelikatutako teilakatuaren eredua.

Esandakoa da, azaletik, eredu horren forma eta erabilera, gehien erabiltzen denetako bat[9]. Berrelikatutako teilakatu-eredua oso erakargarria da, ideala ere bai; proiektuak zurruntasun handia badu (aldaketa gutxi, aurreikusi ez ebolutiboa), baldintzak oso argiak dira, eta behar bezala zehaztuta daude[13].

Ereduaren antzeko aldaera gehiago daude: etapak fintzea (etapa gehiago, txikiagoak eta espezifikoagoak) edo adierazitako etapak baino gutxiago erakustea, nahiz eta, kasu horretan, falta den etapa beste etapa baten barruan egongo den. Aurreko itemean adierazitako fase horien ordena logikoa eta egokia da, baina, esan bezala, ohartarazi behar da normalean atzerantz elikatuko dela.

Eredu lineala edo teilakatua paradigmarik zaharrena eta zabalena da; hala ere, hari egindako kritikek (ikusi desabantailak) zalantzan jarri dute haren eraginkortasuna. Hala eta guztiz ere, oso leku garrantzitsua du software-ingeniaritzan, eta gehien erabiltzen dena izaten jarraitzen du, eta beti da ausazko ikuspegia baino hobea[13].

Teilakatu-ereduaren desabantailak:

• Garapenean egindako aldaketek talde profesionala nahastu dezakete proiektuaren hasierako etapetan. Aldaketak etapa aurreratu batean gertatzen badira (kodifikazioa edo proba) katastrofikoak izan daitezke proiektu handi baterako.
• Ez da ohikoa bezeroak edo azken erabiltzaileak baldintzak argi eta guztiz zehaztea (hasierako etapa); eta eredu linealak hala eskatzen du. Hasierako ziurgabetasun naturala zaila da gero egokitzen[13].
• Bezeroak pazientzia izan behar du, softwarea ez baita erabilgarri egongo proiektua oso aurreratuta egon arte. Bezeroak (eragiketa-fasean) antzemandako errore garrantzitsu bat desastrea izan daiteke, eta, proiektuari, berriro ekitea ekar dezake, kostu handiekin.

Softwareak denborarekin eboluzionatzen du[14][12]. Erabiltzailearen eta produktuaren baldintzak aldatu egiten dira garatu ahala. Merkatu-datak eta lehia direla eta, ezinezkoa da produktu oso bat merkatuan jarri arte itxarotea, eta, beraz, komeni da bertsio funtzional nolabait mugatu bat sartzea lehia-presioak arintzeko.

Egoera horietan edo antzekoetan, garatzaileek aurrerapen-ereduak behar dituzte, bilakaera tenporal edo progresibo batera egokitzeko diseinatuta daudenak, non betekizun nagusiak aldez aurretik ezagutzen diren, nahiz eta zehaztasunez ondo definituta ez egon.

Berrelikatutako teilakatu eta teilakatu-ereduan, ez da gehiegi kontuan hartzen softwarearen izaera ebolutiboa[14]; estatiko gisa planteatzen da hastapenetik oso ezagunak eta definituak diren betekizunekin[9].

Ebolutiboak eredu iteratiboak dira; bertsio gero eta osoagoak eta konplexuagoak garatzeko aukera ematen dute nahi den azken helburura iritsi arte eta are gehiago eboluzionatu ere eragiketa-fasean zehar.

Gehikuntza iteratiboa eta espirala (besteak beste) dira eboluzio motako bi ezagunenak eta erabilienak[13].

Oro har, 4. irudian, software-produktu bat garatzeko prozesuaren urrats orokorrak ikus daitezke. Hautatutako bizi-zikloaren ereduan, argi eta garbi identifikatzen dira urrats horiek. Sistemaren deskribapena funtsezkoa da produktu global eta azkenekora iritsi arteko igoerak zehazteko eta prestatzeko. Jarduera konkurrenteek (zehaztapena, garapena eta baliozkotzea) laburbiltzen dute gehikuntzen garapen xehatua, geroago egingo dena.

4. irudia: Garapen gehikuntza ebolutiboaren diagrama orokorra.

4. irudiaren diagramak oso modu eskematikoan erakusten du gehikuntza iteratibo ziklo baten funtzionamendua, azken produktua eraiki ahala bertsio partzialak entregatzeko aukera ematen duena[9]. Hau da, zehaztutako gehikuntza bakoitza, bere eragiketa- eta mantentze-etapara iritsi ahala. Jaulkitako bertsio bakoitzak beharrezkotzat jotako funtzionaltasunak eta baldintzak gehitzen dizkie aurreko gehikuntzei.

Gehikuntza eredu ebolutibo bat da, behin eta berriz aplikatutako eta filosofia iteratibo bat duten hainbat teilakatu-ziklotan oinarritua dagoena[13]. 5. irudian, aurretiazko diagrama fintzen da denbora-eskema baten pean, eta, azkenik, bizi-ziklo gehikuntza iteratiboaren ereduaren eskema lortzen da lotutako jarduera generikoekin. Hemen argi eta garbi ikusten da hazkunde bat lortzeko aplikatzen den teilakatu-ziklo bakoitza; azken horiek integratuz doaz azken produktu osoa lortzeko. Hazkunde bakoitza berriz elikatutako teilakatu-ziklo bat da, nahiz eta, sinpletasunagatik, 5. irudian sekuentzial puru gisa agertzen den.

5. irudia: softwarearen bizi-ziklorako gehikuntza iteratibo eredua.

Ikusten denez, badira paralelo edo konkurrenteki egiten diren garapen-jarduerak (gehikuntza bakoitzerako), hala nola irudian, lehen igoeraren diseinu zehatza egiten ari dira; bigarrenean, berriz, aztertzen ari dira. 5. irudia eskematikoa baino ez da, igoera ez da zertan aurrekoaren diseinu-fasean hasi, geroagokoa izan daiteke (baita lehenagokoa ere), aurreko etapako edozein unetan. Gehikuntza bakoitza eragiketa eta mantentze jarduerarekin amaitzen da (irudian Operación gisa adierazita), orduan ematen baitzaio produktu partziala bezeroari. Igoera bakoitza hasteko unea hainbat faktoreren mende dago: sistema mota; igoeren arteko independentzia edo mendekotasuna (horietako bi, guztiz independenteak, aldi berean has daitezke, behar adina langile izanez gero); garapenean parte hartzen duten profesionalen gaitasuna eta kopurua; eta abar[10].

Eredu horren bidez, softwarea zati funtzional txikiagotan ematen da, baina berrerabilgarriak, gehikuntzak deiturikoak. Oro har, gehikuntza bakoitza lehendik entregatu zenaren gainean eraikitzen da[9].

5. irudian ikus daitekeen moduan, teilakatu-sekuentziak modu mailakatuan aplikatzen dira, egutegiko denborak aurrera egiten duen bitartean. Sekuentzia lineal edo teilakatu bakoitzak gehikuntza bat eragiten du, eta, askotan, lehen gehikuntza oinarrizko sistema bat da, entregatu gabeko funtzio osagarri asko dituena (ezagunak edo ez).

Bezeroak, hasieran, oinarrizko sistema hori erabiltzen du, bitartean, eta haren erabileraren eta ebaluazioaren emaitzak honako gehikuntza (edo bertsio) horiek garatzeko ekarpena egin diezaioke planari. Gainera, plan horri, beste faktore batzuk ere gehitzen dizkiote, hala nola lehenespena (premia handiagoa edo txikiagoa hazkunde bakoitzaren premian) eta igoeren (edo independentziaren) arteko mendekotasuna.

Integrazio bakoitzaren ondoren, produktu bat ematen da, aurrekoa baino funtzionaltasun handiagoarekin. Prozesua errepikatu egiten da azken software osoa lortu arte.

Iteratiboa izanik, gehikuntza ereduarekin produktu partzial bat ematen da, baina guztiz operazionala, hazkunde bakoitzean, eta ez baldintzak egokitzeko erabiltzen den zati bat (prototipoak eraikitzeko ereduan gertatzen den moduan)[13].

Gehikuntza ikuspegia oso erabilgarria da garapenerako langile-kopuru txikia dagoenean; baita proiektua eskuratzeko epemugarik ez dagoenean ere; beraz, bertsio osatugabeak ematen dira, baina, erabiltzaileari, oinarrizko funtzionaltasuna ematen diote (eta gero eta handiagoa). Ebaluazio-bertsioen helburuetarako ere, eredu erabilgarria da.

Oharra: Eskema eta garapen orokorra hobetzen duten ereduen nahasketa bat izanik, MCP paradigma osagarri gisa sar daiteke aldi baterako edozein unetan edo gehikuntzan.

Adibidea:

Gehikuntza paradigmaren pean garatzen den testu-prozesadore batek, printzipioz, fitxategiak editatzeko eta dokumentuak sortzeko oinarrizko funtzioak ekar litzake (editore sinple bat moduko zerbait). Bigarren hazkunde batean, edizio sofistikatuagoa gehi dakioke, baita dokumentuak sortu eta nahastekoa ere. Hirugarren gehikuntza batean, ortografia-zuzenketako funtzioak, orrialde-eskemak eta txantiloiak eranstea izan daiteke; laugarren hazkunde batean, marrazketa-gaitasun propioak eta ekuazio matematikoak. Horrela, hurrenez hurren, eskatutako azken prozesadorera iritsi arte. Hala, produktua haziz doa bere azken helmugara hurbilduz, baina, lehen gehikuntza eman zitzaionez geroztik, jada erabilgarria eta funtzionala da bezeroarentzat, eta hark erantzun azkarra ikusten du entrega goiztiarrari dagokionez, ohartu gabe proiektuaren epemuga, agian, ez dagoela mugatuta edo hain zehaztuta, eta horrek eragiketa-marjina ematen dio, eta presioak arintzen garapen-taldeari[10].

Esan bezala, gehikuntza iteratiboa eboluzio-motako eredu bat da; hau da, garapen-denboran, eskakizunetan aldaketak egiteko aukera ematen, eta espero dira; softwareak eboluzionatu ahal izateko, tarte bat onartzen da[12]. Aplikagarria da baldintzak nahiko ezagunak direnean, baina ez dira erabat estatikoak eta definituak, eta hori ezinbestekoa da teilakatu-eredu bat erabili ahal izateko.

Eredua gomendagarria da softwarea garatzeko. Software horretan, analisiaren hasierako etapan, ondo definitutako eremuak bete behar dira, segidako etapetan garatzeko bezain independenteak. Estali beharreko eremu horiek premiamendu-maila desberdinak izaten dituzte, eta, beraz, lehenetsi egin behar dira aldez aurreko azterketa batean; hau da, definitu egin behar da zein izango den lehenengoa, bigarrena, eta horrela gainerakoak; horri, lehenespenean oinarrituta, gehikuntzen definizioa esaten zaio. Baliteke bezeroak ez izatea lehentasun funtzionalik, baina garatzaileak, edonola ere, finkatu egin behar ditu, eta irizpideren batekin, horietan oinarrituta garatu eta emango baitira gehikuntzak.

Softwarearen gehikuntza funtzionalak egoteak garapen modularreko eskema bat pentsatzera garamatza berehala, eta, beraz, eredu horrek diseinuaren paradigma hori errazten du.

Laburbilduz, gehikuntza-eredu batek garapen modular batean pentsatzera garamatza, sistemaren gehikuntza izeneko software-produktuaren entrega zatikatuekin, zeinak aldez aurretik definitutako lehentasunen arabera aukeratzen baitira, nolabait. Ereduak aukera ematen du elkarren segidako fintzeekin inplementatzeko (handitzea edo hobetzea). Gehikuntza bakoitzarekin, funtzionaltasun berria gehitzen da, edo baldintza berriak betetzen dira, edo software-produktuaren aldez aurreko bertsioa hobetzen da.

Eredu horrek nolabaiteko malgutasuna ematen du erabiltzaileak eskakizunetan aldaketak egin ditzan garapenak irauten duen bitartean. Proposatutako eta onartutako eskakizunen aldaketa beste gehikuntza bat gisa aztertu eta inplementatu daiteke, edo, hala badagokio, planifikatutako baten hobekuntza/egokitzapena izan daiteke. Hala ere, bezeroak baldintzak aldatzen baditu eta horrek lehendik amaitutako gehikuntzetan eragiten badu (berandu detektatzea/sartzea), egingarritasuna ebaluatu eta bezeroarekin akordio bat egin behar da, eragin handia izan baitezake kostuetan[10].

Eredu horren aukeraketa bezeroari entrega funtzional goiztiarrak egitea ahalbide dezake (eta hori onuragarria da, bai bezeroarentzat, bai garapen-taldearentzat). Lehentasuna emango zaie hori egiteko premia operatiboa sortzen duten moduluei edo gehikuntzei, adibidez, hurrengo gehikuntzetarako ezinbestekoa den aurretiazko informazio-kargei[13].

Gehikuntza iteratibo ereduak ez du behartzen zehatz-mehatz eta xehetasunez zehaztera sistemak egin behar duen guztia (eta nola), eraiki aurretik (teilakatu kasuaren moduan, baldintza izoztuekin). Garatzen ari den gehikuntzan baino ez da egiten. Horrek prozesua maneiagarriagoa bihurtzen du, eta, kostuetan, inpaktua murrizten du. Hori horrela da, zeren baldintzak aldatzen edo berregiten badira sistemaren zati bati bakarrik eragiten baitio. Hala ere, logikoa denez, egoera hori larriagotu egiten da garapena egoera aurreratuan agertzen bada, hau da, azken gehikuntzetan. Azken batean, ereduak erraztu egiten du garapenean eskakizun berriak sartzea.

Gehikuntza-paradigma batekin, hasierako garapen-denbora murriztu egiten da, funtzionaltasun partziala ezartzen baita. Era berean, eragin onuragarria du bezeroaren aurrean, softwarearen zati operatiboak goiz entregatuko baititu.

Ereduak berrelikatutako teilakatu-ereduaren abantaila guztiak ematen ditu, bere desabantailak gehikuntza bakoitzaren eremura soilik murriztuz.

Gehikuntza-eredua ez da gomendagarria denbora errealeko sistemen, segurtasun-maila handiko sistemen, prozesamendu banatuaren edo arrisku-indize handiko sistemen kasuetarako.

Eredu espirala Barry Boehmek proposatu zuen hasiera batean. Prototipoen ereduaren izaera iteratiboa eta teilakatu-ereduaren alderdi kontrolatu eta sistematikoak uztartzen dituen eredu ebolutiboa da. Gehikuntza bertsioak azkar garatzeko potentziala ematen du. Eredu espiralean, softwarea gehikuntza bertsio batzuetan eraikitzen da. Lehen iterazioetan, gehikuntza bertsioa paperezko eredu bat edo prototipo bat izan liteke. Azken iterazioetan, diseinatutako sistemaren bertsio gero eta osoagoak garatzen dira[11][13].

Eredua lan-esparruko jarduera kopuru batean banatzen da, zereginen eskualdeak izenekoetan. Oro har, hiru eta sei eskualde arteko zereginak daude (ereduaren aldaerak daude). 6. irudian, sei eskualde dituen eredu espiral baten eskema agertzen da. Kasu horretan, 1988ko tratatuan azaldutako Boehmen jatorrizko ereduaren aldaera bat azaltzen da; 1998an, tratatu berriago bat azaldu zuen.

6. irudia: softwarearen bizi-ziklorako eredu espirala.

Hauek dira irudiaren ereduan definitutako eskualdeak:

• 1. eskualdea: Bezeroaren eta garatzailearen arteko komunikazioa ezartzeko beharrezkoak diren zereginak.
• 2. eskualdea: Baliabideak eta denbora eta proiektuarekin lotutako bestelako informazioa zehazteari lotutako zereginak.
• 3. eskualdea: Proiektuaren arrisku teknikoak eta kudeaketa-arriskuak ebaluatzeko beharrezko zereginak.
• 4. eskualdea: Software-aplikazioaren irudikapen bat edo gehiago eraikitzeko zereginak.
• 5. eskualdea: Aplikazioa eraikitzeko, instalatzeko, probatzeko eta erabiltzaileari edo bezeroari euskarria emateko zereginak (adibidez, dokumentazioa eta praktika).
• 6. eskualdea: Bezeroaren erreakzioa lortzeko zereginak, aurreko zikloetan sortu eta instalatutakoaren ebaluazioaren arabera.

Aurrez ikusitako eredu espiralaren aldaera interesgarri bat (6. irudia) Win-Win eredu espirala da[10] (Barry Boehm). Aurretiko eredu espiralak (klasikoa) bezeroarekin komunikatzea iradokitzen du, baldintzak finkatzeko. Bezeroari, zer behar duen galdetzen zaio, eta hark jarraitzeko informazioa ematen du; baina hori oso gutxitan gertatzen den testuinguru ideal batean gertatzen da. Normalean, bezeroa eta garatzailea negoziazio batean sartzen dira; kostua negoziatzen da funtzionaltasunaren, errendimenduaren, kalitatearen eta abarren aurrean.