Wikipedia

Software

Konputagailuen softwarea, edo software laburbilduz, konputagailuaren agindu edo datu multzo bat da. Softwareak konputagailuak zer egin behar duen adierazten du. Hardwarea, beste aldetik, lana burutzen duen atal fisikoa da. Konputagailuen softwareak konputagailuaren programak, liburutegiak eta datu exekuta ezinak (online dauden dokumentuak, adibidez) erabiltzen ditu. Konputagailuaren softwareak eta hardwareak batera lan egin behar dute.

LibreOffice, testu editore bat

Osagai logikoek, besteak beste, aplikazio informatikoak dituzte, hala nola testu-prozesadorea, erabiltzaileari testuen edizioari dagozkion zeregin guztiak egiteko aukera ematen diona; software-sistema deritzona (sistema eragilea, alegia) gainerako programei modu egokian funtzionatzeko aukera ematen diena; osagai fisikoen eta gainerako aplikazioen arteko interakzioa ere errazten duena, eta erabiltzailearekiko interfazea eskaintzen duena.[1]

Software gehiena goi-mailako programazio-lengoaietan idatzita dago, programatzaileek erabil ditzaten errazagoak eta eraginkorragoak baitira, makina-lengoaiatik hurbilago baitaude hizkuntza naturaletik baino.[2] Goi-mailako lengoaiak makinaren lengoaia bihurtzen dira konpiladore edo interpretea erabiliz edo bien konbinazioa erabiliz. Softwarea mihiztatze-lengoaian ere idatzita egon daiteke. Mihiztatze-lengoaia hori maila baxukoa da, eta lotura handia du makina-lengoaiaren jarraibideekin; mihiztatzaile bat erabiliz, makinaren lengoaiara itzultzen da.

Kontzeptu horri buruz hitz egitean, softwarea da anglizismorik zabalduena (batez ere terminologia teknikoan); frantsesezko logiciel hitzetik eratorritako «logicial» termino sinonimoa, berriz, gehienbat frantsesaren eraginpeko herrialde eta eremuetan erabiltzen da.

Etimologia

aldatu

Softwarea (NAF: [ˈsoft.wer]: [soft.wer]) ingelesetik datorren hitza da, eta euskaraz ez du testuingururako itzulpen egokirik; beraz, maiz erabiltzen da itzuli gabe, eta halaxe onartuta dago Euskaltzaindiaren Hiztegian[3]. Gauza bera ez bada ere, programa informatiko, aplikazio informatiko edo euskarri logikoen bidez ere ordeztu ohi da.

Softwareari software-ingeniaritzako produktua deitzen zaio.

«Logicial» terminoa frantsesezko logizel terminoaren kalko lexikoa da; neologismoa 1969an sortu zen, logique (logika) eta matériel (materiala) hitzetatik abiatuta, Calcul Planaren arduradunaren Informatika Ordezkaritzaren itzulpen gisa.[4]

Softwarearen definizioa

aldatu

Hainbat definizio daude softwarerako onartuta, baina, seguruenik, formalena honako hau izango da:

« Programa informatikoen, prozeduraren, arauen, dokumentazioaren eta lotutako datuen multzoa da, sistema informatiko baten eragiketen parte direnak »
IEEko 729 estandarretik aterea

Definizio hori kontuan hartuta, softwarearen kontzeptua konputazio-programetatik harago doa bere egoera guztietan: iturburu-kodea, kode bitarra edo exekutagarria; bere dokumentazioa, prozesatu beharreko datuak eta are erabiltzailearen informazioa ere softwarearen parte dira: hau da, ukiezin den guztia hartzen du, harekin zerikusia duen ez-fisiko guztia.

Zentzu horretan, John W. Tukeyk erabili zuen lehen aldiz software hitza, 1957an. Software-ingeniaritzan eta konputazio-zientzietan, sistema informatikoek (programak eta datuak) prozesatutako informazio guztia da softwarea.

Charles Babbagek bere makina diferentzialaren zati gisa sartu zuen kalkuluak kontrolatzeko gailu baten memoriatik jarraibide-sekuentziak (programa) irakurtzeko kontzeptua. Software modernoaren zatirik handienaren oinarria osatzen duen teoria Alan Turing-ek proposatu zuen 1936ko Zenbaki konputagarriak saiakeran, erabaki-arazoenganako aplikazio batekin.[5]

Software sailkapena

aldatu
 
Idazmahairako Linux sistema eragilea

Bereizketa hori arbitrario samarra eta batzuetan nahasia bada ere, helburu praktikoetarako, softwarea hiru mota nagusitan bana ditzakegu[6]:

  • Programazio-softwarea: Tresna multzo bat da, zeinak programatzaileei programa informatikoak eratzeko aukera ematen dien hainbat hautabide eta programazio-lengoaia bitartez. Barne hartzen ditu:
 
Teilakatu-eredu puru edo sekuentziala, softwarearen bizi-ziklorako.

Softwarea garatzeko prozesua

aldatu

Prozesu gisa definitzen da arazo bat konpontzeko edo produktu bat lortzeko jarraitu beharreko urratsen multzo ordenatua, kasu berezi honetan, arazo espezifiko bat konponduko duen software-produktu bat lortzeko.

Softwarearen garapena oso zaila gerta daiteke bere tamaina, ezaugarri eta kritikotasunaren arabera. Adibidez, sistema eragile bat sortzeko, proiektuaren kudeaketa eta baliabide ugari behar dira. Beste aldetik, programa erraz bati buruz ari bagara (adibidez, bigarren mailako ekuazio baten ebazpena) programatzaile bakar batek erraz egin dezake. Softwarea hiru kategorietan banatzen da proiektuak duen tamainaren arabera: txikia, ertaina eta handia. Estimazioa egiteko, badira metodologia pare bat; horien artean, ezagunenetako bat COCOMO da, zeinak produkzio kostuak software proiektu batean (ordu/pertsona, kostua, zenbateko kode lerro programazio-hizkuntzarekiko, etab.) kalkulatzeko metodoa eta softwarea ematen digun.

Software proiektu handietan hainbat lan konplexu egin behar dira, bai teknikaren aldetik, bai kudeaketaren aldetik ere. Konplexutasuna dela-eta, ingeniaritza jakin batek horren ikasketa eta ikerketa egiten du: Software Ingeniaritza.

Beste aldetik, software proiektu ertain eta txikietan, lanaren arduradunak lan talde txikiak dira, edo analista-programatzaile den pertsona bakarra. Zailtasunaren arabera, ertainak diren software proiektuetan, hainbat fase daukate softwarea burutzeko. Fase horiek moldagarriak izan behar dute metodologia edo prozesuen garapenarekiko. Gainera, lan taldeak edo analista-programatzaileak (banakako lana baldin bada) fase horien jarraipena egin behar ditu.

Software garapen prozesuak arau zehatz batzuk dituzte. Arau horiek software proiektu handi eta ertainetan aplikatu behar dira. Bestela, proiektua bukatu gabe geldi daiteke; proiektua zeukan helburuak lortu gabe edo hainbat errore edukitzea. Bete beharreko prozesu horien artean, prozesu arinak (adibidez, XP), pisutsuak eta motelak (adibidez, RUP), eta beste tarteko batzuk daude. Normalean, softwarearen arabera aplikatzen dira, nagusiki proiektuaren garatzaile buruaren arabera[8].

Edozein software garapenerako erabili eta aplikatutako prozesurako (RUP,FDD,XP honen adibideak dira), bizi zikloaren modelo bat egin behar da[9].

Gutxi gorabehera software proiektu handien % 28 ez dela amaitzen estimatzen da; beste % 46 aldaketa handiak jasaten dutela eta hori dela eta izugarrizko atzerapenak jasaten, eta falta den % 28a arazorik gabe amaitzen dela[10].

Proiektu batek porrot egiten duenean, gutxitan izaten da akats teknikoengatik; huts eta porroten kausa nagusia metodologia edo garapen-prozesu on bat ez aplikatzea da. Besteak beste, azken hamarkadetan, joera handia izan da garapen-metodologiak edo -prozesuak hobetzea, berriak sortzea eta informatikako profesionalak horiek behar bezala erabiltzera kontzientziatzea. Normalean, arlo horiek (metodologiak) eta antzekoak (hala nola ereduak eta proiektuen kudeaketa bera) aztertzen eta garatzen espezialistak, software-ingeniariak izaten dira, eta hori da haien orientazioa. Garapen informatikoko beste edozein arlotako espezialistek (analistak, programatzaileak, informatikako lizentziadunak, informatikako ingeniariak, sistemetako ingeniariak, etab.), normalean, beren ezagutza espezializatuak aplikatzen dituzte, baina dagoeneko landutako ereduak, paradigmak eta prozesuak erabiliz.

Ertain neurriko softwarea garatzeko, ohikoa da tartean lanean ari diren giza taldeek metodologia propioak aplikatzea, normalean aurreko prozesuen hibridoa eta batzuetan irizpide propioekin[11].

Garapen-prozesuak zeregin ugari eta askotarikoak har ditzake barne[9], arlo administratibotik hasita, arlo teknikotik jarraituz eta kudeaketa eta gerentziaraino. Baina, ia zorrozki, beti betetzen dira gutxieneko etapa batzuk, honela laburbil daitezkeenak:

  • Atzematea, iradokitze, espezifikazioa eta eskakizunen analisia (ERS)
  • Diseinua
  • Kodifikazioa
  • Probak (unitarioak eta integraziokoak)
  • Instalazioa eta ekoizpenera igarotzea
  • Mantentzea

Aurreko etapetan, izenak apur bat alda daitezke, edo globalagoak izan daitezke, edo, bestela, finagoak; adibidez, analisi eta diseinuaren fase bakartzat (dokumentu- eta interpretazio-helburuetarako) adieraz daiteke; edo inplementazio gisa adieraz daiteke kodifikazio gisa esanda dagoena; baina, zorrotz esanda, guztiak daude, eta, funtsean, zeregin espezifiko berberak dituzte.

Artikulu honen 4. paragrafoan, aipatutako etapa bakoitzari buruzko xehetasun gehiago ematen dira.

Prozesu-ereduak edo bizi-zikloa

aldatu

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

Teilakatu-eredua
aldatu

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.

Eredu ebolutiboak

aldatu

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

Gehikuntza iteratibo eredua

aldatu

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

aldatu

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.

Win & Win eredu espirala

aldatu

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.

Softwarearen eboluzio izaera

aldatu

Software ingeniaritzaren arabera, softwarea garapen prozesuaren deribazioaren produktua da. Produktu hori ebolutiboa da bere bizi zikloan zehar. Softwarea, eboluzioa egiten duen bakoitzean, bertsio hobeago batera aldatzen da. Beraz, aldaketa bat jasan ondoren, bere aurrekaria zen bertsioa baino hobeagoa da hainbat arlotan, adibidez, optimizazioa eta itxuran.

Softwareak, eboluzioa egiteari uko egiten duenean, bere bizi zikloa amaitu dela esaten da. Hori gertatuz gero, zaharkituta geratuko da momentu batean, eta beste batek ordezkatuko du zaharkitutako software hori.

Softwareak eboluzioak egiten ditu ingurune aldaketei aurre egiteko. Aldaketa horiek funtzionalitatekoak, operatiboak, plataformakoak edo hardwarekoak izan daitezke.

Erreferentziak

aldatu
  1. ↑ SYSTEM SOFTWARE. 30 de mayo de 2001.
  2. ↑ «Onderwijs Informatica en Informatiekunde | Department of Information and Computing Sciences» www.cs.uu.nl.
  3. ↑ Software, Euskaltzaindiaren Hiztegia, Euskaltzaindia
  4. ↑ Pierre Mounier-Kuhn, L'informatique en France, de la seconde guerre mondiale au Plan Calcul. L'émergence d'une science, Paris, PUPS, 2010, ch. 4.
  5. ↑ Definición de Software. .
  6. ↑ (Ingelesez) «Componentes De Software» calameo.com (Noiz kontsultatua: 2023-07-01).
  7. ↑ (Gaztelaniaz) Global, Euro Mundo. «El uso de un software reduce considerablemente los errores en la gestión de nóminas» Euro Mundo Global (Noiz kontsultatua: 2023-07-01).
  8. ↑ Fernández del Busto De La Rosa, Gabriela. Las TIC en la Educación.
  9. ↑ a b c d e f g h i «Ciclo de Vida del Software». Grupo Alarcos - Escuela Superior de Informática de Ciudad Real. Archivado desde el original el 14 de junio de 2013.
  10. ↑ a b c d e f Pressman, Roger S. (2003). «El proceso». Ingeniería del Software, un enfoque Práctico, Quinta edición edición. México: Mc Graw Hill.
  11. ↑ a b Cárdenas, Patricia García. INGENIERÍA DE SOFTWARE AVANZADA. (Noiz kontsultatua: 2023-07-02).
  12. ↑ a b c (Ingelesez) «OpenStax | Free Textbooks Online with No Catch» openstax.org (Noiz kontsultatua: 2023-07-02).
  13. ↑ a b c d e f g h i «Ciclo de vida del Software y Modelos de desarrollo». Instituto de Formación Profesional - Libros Digitales. Archivado desde el original el 15 de febrero de 2010. Texto «lugar: Asunción del Paraguay» ignorado (ayuda)
  14. ↑ a b (Ingelesez) «OpenStax | Free Textbooks Online with No Catch» openstax.org (Noiz kontsultatua: 2023-07-02).

Ikus, gainera

aldatu

Kanpo estekak

aldatu
  • Software Zientzia eta Teknologia Hiztegia.
"https://eu.wikipedia.org/w/index.php?title=Software&oldid=9588714"(e)tik eskuratuta