2. Software-prozesua
2.1. SARRERA
Informatikaren bilakaeran, pitean-pitean, edukiontziak, aurrea hartu dio edukiari.
Adibidez, laurogeiko hamarkadan, CASE1 tresnek izugarrizko ezarpena izan zuten
softwarearen garapenean aplikazioen analisia eta diseinua garatzeko. Erakunde
gehienetan, CASE tresna bat erosten zen eta analista berehala hasten zen erabiltzen
emaitza oparoen bila. Askotan baina, emaitza oparo horiek ez ziren atzematen hain
azkar. Beste behin, edukiontzia, tresna, edukiaren aurretik jartzen zen. CASE
tresnak, jakina, lana errazten zuen aplikazioaren analisia eta diseinua mekanizatuz
eta proiektuen gisara kudeatuz, baina aplikazioa mekanizatzeko eta sistematizatze-
ko, analistak, CASE tresnak inplementatzen zuen metodologia --edukia-- ondo
ezagutu behar zuen metodologiaren ezaugarri nagusiak kontrolatzeko. Sarritan,
baldintza hori ez zen betetzen eta etsipena nagusitzen zen erakundean, emaitzak
kaskarrak izaten baitziren. Ondorioa: CASE tresnaren proposatzaileak deabruaren
ordezkari maltzurraren estatusa bereganatzen zuen eta, jakina, CASE tresna zoko-
ratu egiten zen in saecula saeculorum.
Gure egunetara etorrita, eta beharbada bizi dugun kultura nartzisistaren eragi-
nez, badirudi orain ere edukiontziak tokia hartzen jarraitzen diola edukiari hainbat
arlotan, eta informatika ez da, zoritxarrez, salbuespen bat testuinguru horretan.
Egun, lasai-lasai esango dizu batek, berak, RUP2 erabiltzen duela beti anali-
siak eta diseinuak gauzatzeko, eta Microsoft Project, proiektu informatikoak kudea-
tzeko. Jakina, inplementatzeko orduan, objektuetara zuzenduko du programazio-
paradigma eta horretarako, Java, C# edota C++ erabiliko ditu barra-barra. Kontu
egin berriro ere, edukiontzi mailan ari garela hitz egiten. Entzuleak, goiko paragra-
foaren informazioaren aurrean, nahitaez edukietara jo beharko luke eta galdetu,
garatzen ari den aplikazio informatikoan, nola, noiz eta zergatik erabiltzen diren
RUP eta Microsoft Project tresnak.
Tresna horien eraginkortasuna kaskarra izango da aplikatzen diren tokian
softwarearen prozesuak ez badu garrantzi handirik. Softwarearen prozesua erabat
lotuta dago softwarearen proiektu eta produktuarekin. Hala nola, softwarearen
1. Computer Aided Software Engineering
2. Rational Unified Process
proiektua, garapen-proiektu bat izango da software-prozesu bat aplikatuta kudea-
tzen dena. Softwarearen proiektuaren ebazpen nagusia softwarearen produktua
izango da. Gehienetan, iturburu-kodearekin soilik identifikatzen da produktu hori,
proiektuaren bizi-zikloaren beste produktuen kalterako. Azkenik, softwarea
garatzeko balio duen metodoari software-prozesua deitzen zaio. Software-
prozesuak adierazten du proiektuak jarraituko duen jardueren sekuentzia. Jarduera-
sekuentzia nahitaez abstrakzio mailan adierazi behar da erakundearen proiektu
kopuru handienera heltzeko. Hala, proiektu bakoitzak, bere instantziazio propioa
emango dio jarduera generiko bakoitzari proiektuaren bizi-zikloan.
2.1. irudia. Softwarearen Prozesua.
Beraz, orain arte esandakotik honako urrezko arau hau ondoriozta dezakegu:
softwarearen ingeniaritzan, software-prozesuak bideratzen du beti proiektua eta ez
aldrebes.
2.1. irudiak orain arte azaldutako terminologia zehazten lagunduko digu.
Argi dago softwarearen prozesuaren helburua produktuak lortzea dela, eta horreta-
rako, produktuaren ingeniaritzaren prozesu bat aplikatu behar da produktuaren kos-
tua eta kalitatea egokiak izan daitezen. Helburu horiek lortzeko, hiru azpiprozesu
desberdin baina osagarri, erabiltzen dira: garapen-prozesua, proiektuaren kudea-
ketaren prozesua eta konfigurazio-kontrolaren prozesua. Lehenengoak, gauzatu
behar diren garapen- eta kalitate-jarduerak aztertzen ditu. Bigarrenak, jardueren
planifikazioa eta kontrola kudeatzen ditu, eta hirugarrenak, aldaketen eta produk-
tuaren integritatearen kudeaketa kontrolatzen du, kostuen eta kalitatearen arabera.
Erakunde bakoitzak bere heldutasun mailaren arabera, hiru prozesuok barra-barra
erabiliko ditu eguneroko jardunean edo akaso, garapen-prozesu kaskar batekin
konformatu beharko du. Tokian tokiko eta unean uneko egoerak bideratuko du
aukera.
Softwarearen Prozesua
Produktuaren
Ingeniaritzaren
Prozesua
Garapen
Prozesua
Proiektuaren
Kudeaketaren
Prozesua
Konfigurazio
Kontrolaren
Prozesua
Prozesuaren
Kudeaketaren
Prozesua
- C M M
- SPICE
- P S P
18 Softwarearen ingeniaritza
Softwarearen prozesua hankamotz geldituko litzateke produktuaren ingenia-
ritzaren kalitatea ez balu kontuan hartuko. Softwarearen prozesuak beste prozesu
mota berri bat behar du, aiduru eta kuxkuxean egongo dena, produktuaren ingenia-
ritza arakatzen: prozesuaren kudeaketaren prozesua.
Azken hamarkadan kalitatearen inguruko berriak eta txostenak ugalduz joan
dira eta gizartearen arlo gehienetara hedatu dira. Hezkuntzan, kalitateak du lehen-
tasuna; ekonomian, beste hainbeste. Ingeniaritza estandarrean, kalitateak, garapen-
prozesu ezagun bati jarraitzen dio beti eta oso lotua egoten da ingeniaritza mota
horren heldutasun mailarekin. Hasiera batean, ingeniaritzak artisautza tankerako
ohiturak jartzen ditu praktikan produktua eraikitzeko, prozesu orokorrak ez dira
ondo ezagutzen eta kalitatea banakako atazen kontrolean oinarritzen da. Produk-
tuaren eta prozesuaren kalitatea hobetzeko, akatsak antzeman eta konpontzen
dituen sistema bat eraikitzen da. Kontu egin, prozesuak baino produktuak duela
lehentasuna lehenengo urrats honetan.
Bigarren urratsean, akatsei aurre egiteko neurriak hartzen dira eta horreta-
rako, kalitatearen kontrol estatistikoa gauzatuko duen sistema bat eraikitzen da.
Akatsen iragarpen egokiak egitea izaten da helburu nagusia.
Bukatzeko, azken urratsean, produktuaren merkatu mota aldatu egiten da eta
eskaera motako merkatu izatetik eskaintza motako merkatu izatera igarotzen da.
Merkatuak finkatzen du salneurria eta lehia nagusitzen da partaideen artean. Dura
lex, sed lex3.
Softwarearen ingeniaritzak, ingeniaritza den heinean, aipatutako hiru urrats
horien unibertsoan mugitu beharra du kalitatearen ezaugarriak bereganatu nahi
baditu. Kalitatea bermatzeko, kalitatearen hobekuntza prozesuetan oinarritu behar
da eta ez jendearengan. Bestalde, hobekuntza neurtu egin behar da eta hobekuntza-
prozesuak etengabea izan behar du erakundean. Ez legoke gaizki, halaber, hemen
eta orain, Watts Humphrey jakintsuaren hitzak errepikatzea berriz: erraza da
azaltzen kalitatea zer den baina zeharo zaila gauzatzen erakundean. Nork ez du
ezagun bat bertsolaritzari buruz orduak eta orduak egon daitekeena hitz egiten,
baina gero ez dena gauza kopla arrunt bat botatzeko bat-batean afari batean?
Kalitatearen inguruan ere, zakur goseak okela amets.
Softwarearen ingeniaritzaren egungo egoera erakunde gehienetan, aski eza-
guna da4: proiektu informatikoen % 23k porrot egiten du, % 28k arrakasta izaten
du eta % 49 bukatu egiten da, baina epez kanpo eta aurreikusitako kostuak zeharo
gaindituta. Ehuneko horiek ez dute inola ere islatzen ingeniaritza heldu baten pro-
fila eta, beraz, lan asko dago oraindik egiteko artisautza-ikuspegia utzi eta ingenia-
ritzari atxikitzeko. Hori lortzeko, ondoko orrietan, puri-purian dauden hainbat
Software-prozesua 19
3. Lege gogorra, baina lege, hala ere.
4. Standish Group International: www.standishgroup.com
eredu eta prozesuaren kudeaketa-prozesu mota aurkeztuko ditugu, produktuaren
ingeniaritzaren prozesua hobetzeko.
2.2. irudia. Softwarearen prozesuen estandarren bilakaera historikoa.
2.2. irudiak softwarearen prozesuaren inguruan garatu diren estandar
ezagunen bilakaera historikoa islatzen du. Bakoitzaren ezaugarriak zehatz-mehatz
azaltzeak luze joko ligukeenez, hautaketa pragmatiko bat egingo dugu eta eredu
paradigmatiko bi azalduko ditugu ondoko orrietan: CMM (Capability Maturity
Model) eta SPICE (Software Process Improvement and Capability dEtermination).
Bai batak eta bai besteak, softwarea garatzen duten erakundeen heldutasun maila
neurtu eta hobetzea dute jomuga.
2.2. CMM (CAPABILITY MATURITY MODEL)
Informatikaren buruhauste nagusietariko bat da softwareak kudeatu behar duen
domeinuaren konplexutasunaren aldaketa-abiadura askoz ere handiagoa dela gure
ahalmena baino softwarea garatu eta mantentzeko. Horrek, nahitaez, softwarearen
produktuaren kalitatea, hobekuntza-prozesu etengabean sartzea behartzen du
kostuak murrizteko eta epeak txukun betetzeko.
Aldez aurretik, behin eta berriz errepikatu dugu softwarearen produktuaren
kalitatea oso lotua dagoela prozesuaren kalitatearekin, erabat bideratuz eta baldin-
tzatuz haren eraginkortasuna. CMMk testuinguru horretan, azpiegitura bat eskain-
tzen du softwarea eraikitzen aritzen diren erakundeek kontrola ditzaten beren
garapena eta mantentze-prozesuak. Hala, erakundeak bere softwarearen prozesura
bideratuko du softwarearen ingeniaritzaren kultura, eta horrek, bat-bateko eragina
izango du haren kostu eta garapen-denboretan.
ISO 9000
group ISO 9000-3 IEEE ESA
TickIT Bootstrap
CMM
V 1.0
ISO SPICE'
Bootstrap'
CMM
V 2.0
SPICE
1995
1995
1998
1999
Industriako
estandar
orokorrak
Softwarearen Prozesua
kudeatzeko estandarrak
(Trials)
EFQM
2000
EFQM
V.99
CMM
1.1
ISO 9000
2000
20 Softwarearen ingeniaritza
CMMren sorkuntza 80ko hamarkadan kalitatearen inguruan sortu zen arre-
tarekin lotu behar da. Hamarkada horren hasieran, IBM erakundea, Watts
Humphrey-ren zuzendaritzapean, ingurune bat hasi zen garatzen softwarearen pro-
zesua kontrolatzeko. Hala, 1986ko azaroan, SEI (Software Engineering Institute)
erakundearen5 azpiegitura erabilita ingurune estandar baten lehen urratsak gauzatu
ziren eta, 1987ko irailean, SEIk, proposamen zehatz bat aurkeztu zuen softwarearen
prozesuaren heldutasuna neurtu eta garatzeko. Handik gutxira, Watts Humphrey-k
Managing the Software Process liburuan aurkeztu zuen proposamen hori.
CMMk kalitate totalaren kudeaketaren (TQM-Total Quality Management)
ezaugarriak aplikatzen ditu softwarearen ingeniaritzaren prozesuen kudeaketan,
batez ere, produktuaren kontrol kuantitatiboan. Emaitza desiragarriak lortzeko,
metodologia logiko eta zentzuzkoa erabiltzen du CMMk: lehenengo eta behin,
egungo egoera identifikatzen da egungo sistemaren heldutasun maila neurtuta.
Gero, egoera desiragarria identifikatzen da hurrengo mailaren ezaugarriak deskri-
batuz. Egungo egoeratik egoera desiragarrira dagoen distantzia laburtzeko, erakun-
deak planifikatu, inplementatu eta instituzionalizatu egiten ditu hurrengo mailaren
praktika nagusiak. Praktika horiek behin eta berriz errepikatzen dira beren erabi-
lera optimizatu arte.
CMM arloan, berdin da liburu sakonena kontsultatu edo dokumentazio oina-
rrizkoena irakurri, beti agertzen zaigu barra-barra eta bat-batean heldutasun hitza,
dela heldutasun maila adierazteko, dela erakundearen heldutasuna aztertzeko. Era-
kundeak heldutasun maila apala duela adierazten bada aztertzen ari garen testuin-
guruan, honako hau azpimarratu nahi da:
· Erakundearen kudeatzaileek ez dute softwarearen prozesua kudeatzen,
egunean eguneko kultura dago hedatua eguneroko jardunean.
· Produktuaren kalitatea eraikitzeko eta kudeatzeko behar den prozesua ez da
irizpide objektiboetan oinarritzen.
· Erakunde horietan, aurreikusitako kostuak eta denborak ez dira betetzen,
aurreikuspenak errealistak ez direlako. Proiektuaren arduradunak, halabe-
harrez, epeak aldatzen dituenean, produktuaren funtzionalitatearen eta
kalitatearen ordainetan izaten da.
Bestalde, erakundeak heldutasun maila handia duenean, gauza izaten da
softwarearen prozesu eta produktuak monitorizatzeko. Halaber, tresna egokiak
(prozedurak, teknologiak eta giza baliabideak) izaten ditu azterketa kuantitatiboak
eta objektiboak gauzatzeko, softwarearen garapenean arazoak sortzen direnean.
Erakundea prozesu diziplinatuari jarraitzeko gauza da eta erabat instituzionali-
zatuta dauzka mailaren praktika nagusiak eguneroko jardunean.
Software-prozesua 21
5. http://www.sei.cmu.edu/
CMMk bost heldutasun maila (2.3. irudia) definitzen ditu softwarearen pro-
zesuaren hobekuntza aurrera eramateko. Hala, prozesuaren heldutasuna, gaitasuna
eta eraginkortasuna nabari hobetuko dira eta, horrek, eragina izango du softwarea-
ren produktuan.
Hasieran [bigarren maila], iragarri gabeko eta gaizki kontrolatua den pro-
zesua diziplinatu bihurtzen saiatuko gara eta horretarako proiektuaren kudeaketa-
ren oinarrizko kontrolak sortuko ditugu. Hori egin ondoren, prozesua estandarizatu
eta instituzionalizatu egingo dugu [hirugarren maila] proiektu guztietan softwarea-
ren ingeniaritzaren eta kudeaketaren prozesuak aplikatuta. Laugarren mailan,
ezaguera kuantitatiboak hartzen du lehentasuna, softwarearen prozesuan eta
produktuan. Amaitzeko, bosgarren mailak irakurketa sinbolikoa du ez baita propio
maila bat. Hemen, sistematizatutako prozesuaren hobekuntzak hartzen du
lehentasuna eta, horretarako, etengabe eta era neurtuan aztertuko dira prozesuak;
hala, akatsak eta beharrezko aldaketak finkatuta eta gauzatuta gelditzen dira.
2.3. irudia. CMM ereduaren heldutasun mailak.
2.4. irudiak azaldu dugunaren irakurketa grafiko bat egiten du prozesuaren
ikusgaitasuna eta prozesuaren ahalmena kontuan izanda. Grafikoaren ezkerraldeak
adierazten du nola aldatzen den softwarearen prozesuaren ikusgaitasuna. Hasie-
rako mailan, softwarearen prozesua kutxa beltz bat da erakundearentzat, prozesuak
sarrera batzuk jasotzen ditu kanpotik eta irteera bat ematen du agerkunde magiko
bat izango balitz bezala. Maila horretan, analistak arazoak ditu proiektuaren
garapena kontrolatzeko eta jarduerak finkatzeko. Betekizunak, kontrolik gabe
iristen dira erakundera, eta zorionez, zergatik ondo jakin gabe, software-produktua
ateratzen da jarraian. Software-produktuaren bezeroak bukaeran bakarrik egiazta
dezake hasieran emandako betekizunak gauzatu diren ala ez produktuan.
2. Errepikakorra
1. Hasiera
3. Definitua
4. Kudeatua
Prozesu
Diziplinatua
Prozesu
Estandar
Trinkoa
Prozesu
Iragarria
Etengabeko
Hobekuntza
Prozesua
Iragarpen gabekoa eta
gaizki kontrolatua
Lehendik osatutako ataza
nagusiak errepika daitezke
Prozesuak karakterizatuta
daude, azaletik ulertzen dira
Prozesuak neurtuta eta
kontrolatuta daude
Prozesuen hobekuntza
da helburu nagusia
5.Optimizatua
Proiektu
Kudeaketa
Ingeniaritza
Integratuaren
Prozesua
Produktu eta
Prozesuen
Kalitatea
Aldaketaren
Kudeaketa
22 Softwarearen ingeniaritza
2.4. irudia. Prozesuaren ikusgaitasuna eta ahalmena neurtzen.
Bigarren mailan, hasierako kutxa beltz monolitikoa zatitu egiten da ikusgaita-
sunaren mesederako. Bezeroaren betekizunak eta jarduera desberdinen produktuak
kontrolatu egiten dira proiektuaren oinarrizko kudeaketa bat txertatuta eguneroko
jardunean. Softwarearen eraiketa mugarriz mugarri gauzatzen da eta mugarri
bakoitzean datuak eta informazioa jasotzen da, egiaztatzeko proiektuaren epeak
betetzen ari direla eta kontrolpean daudela. Horrela, proiektuaren arduradunak ez
daki zehatz-mehatz zer gertatzen ari den kutxa beltz bakoitzean baina emaitzak
aztertuz ondoriozta dezake aurreikuspenak betetzen ari direla. Bezeroak, sukalda-
riek bezala, produktuaren zaporea dasta dezake mugarrietan eta informazioa eman
erakundeari betekizunen funtzionalitatea hobetzeko. 2.5. irudian maila honetan
gauzatzen diren jarduerak eta lortzen diren gaitasun orokorrak adierazten dira.
Hirugarren mailan --maila interesgarriena eta erabakigarriena-- kutxa bel-
tzen barne-egitura azaleratu egiten da eta prozesuak karakterizatuta gelditzen dira.
Erakundeak prozesu estandar bat finkatzen du aurrerantzean proiektu guztietan
aplikatuko dena. Hemen esan dezakegu benetan hasten dela finkatzen produktuen
eta prozesuen kalitatea. Proiektuaren kudeaketa eraginkorra denez, desbideratutako
atazak berehala ekartzen dira beren onera proiektua mugarrietara heldu baino
lehen. Bezeroak, une oro, erabat monitorizatuta dauka bere produktua, garapenaren
bilakaeraren aztarnak zeharo ugaldu baitira maila honetan.
Prozesuaren Ikusgaitasuna Prozesuaren Ahalmena
OutIn1
2
3
4
5
Probabilitatea
Helburua
N
N+a
N-x
N-y
N-z
Mailak
Software-prozesua 23
2.5. irudia. CMM ereduaren bigarren mailaren ezaugarri nagusiak.
Laugarren mailan, aurreko mailan definitutako software-prozesua kuantitati-
boki kontrolatzen da. Aurreikuspen zehatzak egiten direnez, kostuen desbiderake-
tak txikiak izaten dira eta epeak zehatz-mehatz betetzen dira. Bezeroak hasieratik
daki proiektuaren arriskua norainokoa den eta bukaerako ezusteak6 baztertuta
gelditzen dira.
Bukatzeko, bosgarren mailan, prozesuaren hobekuntza etengabe lantzen da.
Prozesuaren edozein aldaketaren eragina aurreikusi egin daiteke eta kuantitatiboki
neurtu. Aldaketak, diziplinatuak izaten dira eta helburu nagusia, jarduera ez
eraginkorrak saihestea izaten da.
2.4. irudiak badu, halaber, bigarren zutabe bat prozesuaren ahalmenaren pro-
fila adierazten duena. Profil horietan, erakundearen heldutasun mailan igoz doan
heinean, erakundeak iragarpen hobeak eta zehatzagoak egiten ditu proiektuaren
desbideraketak txikiagoak izango direlako. Epeak eta kostuak jaitsi egiten direnez,
proiektua gauzatzeko baliabideen beharra txikiagotu egiten da.
CMMren azalpen orokorra burututa, joan gaitezen haren barne-egitura (2.6.
irudia) nola dagoen antolatuta aztertzera. CMMren heldutasun maila bakoitzaren
helburu nagusia softwarearen prozesuaren ahalmena islatzea izaten da eta hori lor-
tzeko, prozesuaren eremu nagusietan (Key Process Areas) antolatzen da helduta-
sun maila bakoitza. Maila bakoitzaren eremu nagusi bakoitzarentzat helburu zehatz
batzuk finkatzen dira. Helburu horiek adieraziz gero, eremu nagusi bakoitzarentzat
Erakundeak burututako
jarduerak:
Software-proiektuaren
kudeaketaren kontrol eta
prozedurak finkatzen dira
Instituzionalizatu
proiektuaren prozesuak.
Horrela, proiektu berriak
aurreko proiektuetan
sortutako praktika
eraginkorrak errepika
ditzake
Proiektuek burututako
jarduerak:
Aurreko proiektuen
emaitzak eta egungo
proiektuaren betekizunak
kontuan hartuz proiektuaren
planifikazio errealista
bat egin
Softwarearen kostuak,
denborak eta
funtzionalitateak jaso
arazoak identifikatzeko
proiektuaren planifikazioan
Betekizunak eta lan-
produktuak (work products)
kontrolatu. Ziurtatu
finkatutako proiektuaren
estandarrei jarraitzen
zaiela
Lortutako prozesuaren
gaitasuna:
Software-prozesuaren
gaitasuna diziplinatua
da. Proiektuaren
planifikazioa eta
jarraipena egonkorrak
dira eta hasierako
arrakastak errepika
daitezke
Proiektuaren prozesua,
proiektu kudeaketaren
sistemaren kontrolpean
dago plan errealei
jarraituz
24 Softwarearen ingeniaritza
6. Espero zen funtzionalitatea ez da lortu, kostuak handiagoak izan dira edota epeak ez dira bete.
haren ezaugarri komunak zehazten dira, nola geldituko diren gauzatuta finkatzeko.
Bukatzeko, ezaugarri komun bakoitzak bere praktika nagusiak edukiko ditu ziur-
tatzeko praktikan prozesuaren eremu nagusiaren helburuak ondo gauzatzen direla,
jarduera egokiak egikarituta. Azpimarratu behar da praktika nagusi horiek zer egin
behar den deskribatzen dutela eta ez nola inplementatu behar den jarduera bakoitza.
2.6. irudia. CMM ereduaren barne-egitura.
Aitzinean aipatu dugun legez, CMMren bigarren mailak proiektuaren kudea-
ketaren oinarrizko kontrolak finkatu nahi ditu eta horretarako honako prozesuaren
eremu nagusi hauek (2.7. irudia) landu eta antolatuko ditu:
· Betekizunen kudeaketa (BK). Eremu hau, erabiltzailearen betekizunak doku-
mentatu eta kontrolatzen saiatuko da. Kontuan hartu behar da erabiltzai-
learen betekizunak software-proiektuaren aurrebaldintza nahitaezkoak
direla proiektua planifikatu, iragarri eta gauzatzeko.
· Softwarearen proiektuaren planifikazioa (PP). Arlo honetan, iragarpen
errealak egingo dira baliabideak, arriskuak eta denborak identifikatu eta
zehazteko.
· Softwarearen proiektuaren jarraipena (PJ). Eremu nagusi honekin, proiek-
tuaren ikusgaitasuna handitu egiten da. Eremu hau txukun lantzen bada,
software-produktuaren eguneroko garapena kontrolatuta eta kudeatuta
egoten da erakundean. Proiektuaren desbideraketak lehenbailehen antze-
maten dira eta berehala jartzen dira martxan ekintza egokiak, arazoak
zuzentzeko.
Heldutasun mailak
Prozesuaren ahalmena
adierazi
Prozesuaren eremu nagusiak
eduki
Helburuak
lortu
Ezaugarri komunak
antolatuta
Inplementazioa/
Instituzionalizazioa
gauzatu
Praktika nagusiak
Azpiegitura eta jarduerak
deskribatu
eduki
Software-prozesua 25
2.7. irudia. CMM ereduaren bigarren mailaren prozesuaren eremu nagusiak.
· Azpikontratazioen kudeaketa (AK). Arlo hau ez da beti beharrezkoa.
Softwarearen konplexutasunak eskatzen duenean edo erakundearen lan
egiteko erak inposatzen duenean, software-produktua azpikontratatu egiten
da eta beharrezkoa zaigu azpikontratazioaren kudeaketa egoki bat eratzea.
· Softwarearen kalitatearen ziurtapena (KZ). Eremu honetan, software-
produktuak eta praktika-eginkizunak ikuskatu eta egiaztatu egiten dira
baieztatzeko finkatu diren estandarrak eta prozedurak aplikatzen ari direla.
· Softwarearen konfigurazioaren kudeaketa (KK). Hemen, proiektuaren bizi-
zikloan zehar, proiektuaren produktuen integritatea mantentzen eta finkatzen
saiatuko gara. Produktuen integritatea mantentzeko, proiektuaren planifika-
zioa denbora-mugarriz osatua egongo da. Horrela, proiektuaren arduradunak
proiektuaren aztarnak jasoko ditu proiektuaren bizi-zikloan zehar eta
konfigurazio-aldaketak sistematikoki kudeatuko ditu.
2.8. irudiak adierazten du eremu nagusien ezaugarri komunen heldutasuna-
ren maila norainokoa den, eta zehazten du nola dauden kudeatuta eta kontrolatuta
bigarren mailaren eremu nagusiak.
Heldutasun Maila
Prozesuaren
Eremu
Nagusiak BK PP
2
PJ AK KKKZ
3 4 5
Helburuak
Ezaugarri
Komunak
Praktika
Nagusiak
Burutzeko
Planifikazioa
Burutzeko
Trebetasuna
Burututako
Jarduerak
Neurtu eta
Analizatu
Inplementazioa
Egiaztatu
Betekizunen
Kudeaketa(BK)
Proiektuaren
Planifikazioa(PP)
Kalitatearen
Ziurtapena(KZ)
Azpikontratazioaren
Kudeaketa(AK)
Konfigurazio
Kudeaketa(KK)
Proiektuaren
Jarraipena(PJ)
Betekizunen
Kudeaketa (BK)
Proiektuaren
Planifikazioa (PP)
Kalitatearen
Ziurtapena(KZ)
Azpikontratazioaren
Kudeaketa (AK)
Konfigurazioaren
Kudeaketa (KK)
Proiektuaren
Jarraipena(PJ)
26 Softwarearen ingeniaritza
Heldutasun Maila
Helburuak
Ezaugarri
Komunak
Praktika
Nagusiak
Eremu
Nagusiak
Prozesuaren
2.8. irudia. Ezaugarri komunen heldutasun maila.
Jakin badakigu CMMren hirugarren mailak prozesua estandarizatu eta insti-
tuzionalizatu egiten duela. Hori gauzatzeko, bigarren mailak legez, maila honek
ere bere prozesuaren eremu nagusiak ditu:
· Erakundearen prozesuaren fokusa. Erakundea gauzatzen ari den prozesua
kontrolatu eta garatu nahi bada nahitaezkoa da ondo koordinatzea softwa-
rearen prozesuaren ekintzak erakundean zehar. Horrela, ardurak non ko-
katzen diren identifikatuak egongo dira eta posible izango da prozesuaren
garapena.
· Erakundearen prozesuaren definizioa. Prozesuaren kudeaketa kuantitatiboa
erabilita, prozesuaren definizio zehatza lortzen da, eta horrela, softwarearen
prozesu estandarra finkatuta geldituko da. Erakundeak, hortik aurrera,
prozesua garatu, neurtu eta kudeatu ahal izango du.
· Eguneratze-programa. Prozesuak, estandarizatzen den heinean, eragina
izango du erakundearen giza baliabideetan. Batzuetan, eguneratze-prozesu
hori erakundean bertan gauzatuko da inongo laguntzarik gabe; beste asko-
tan, ostera, kanpoko laguntza beharko da eta ikastaroak antolatu beharko
zaizkio erakundeko pertsonalari.
· Softwarearen kudeaketa integratua. Prozesua estandarizatuz gero, berma-
tuta gelditu behar da proiektuaren planifikazioa eta kudeaketa ondo inte-
gratuta gelditzen direla prozesu berrian.
CMM Ereduaren 2. mailaren
Prozesuaren Eremu Nagusiak
0
2
4
6
8
10
BK
PP
PJ
AK
KZ
KK
Software-prozesua 27
· Softwarearen produktuaren ingeniaritza. Goian planifikazioari buruz esan
dugunak berdin balio digu proiektuaren jarduera teknikoen arloak kudea-
tzeko, hau da, betekizunen analisia, diseinua, kodeketa eta probak.
· Taldeen arteko koordinazioa. Erakunde osoaren integrazioa eta koordina-
zioa bermatu nahi badugu era eraginkorrean, proiektuan parte hartzen duten
talde guztien elkarrekintzek eta interfazeek ondo planifikatuta eta kudeatuta
egon behar dute. Gardentasuna nagusitu egingo da erakundean, talde
guztiak jakitun egongo baitira besteen planifikazioez eta egoerez.
· Ikuskapen-politika. Softwarearen produktuen akatsak ezabatu nahi badira
azkar eta era eraginkorrean, ikuskapen-politika bat finkatu behar da erakun-
dean akatsak berehala aurreikusi eta jakinaren gainean jartzeko.
Horratx, beraz, bigarren eta hirugarren mailen eremu nagusien azalpena.
Kontuan izanda erakunde gehienen maila lehenengoa edo bigarrena izaten dela eta
laugarren eta bosgarren mailek ere antzeko ibilbideari jarraitzen diotela, ez zaitut
irakurle gehiago nekatuko eta hemen utziko dugu eremu nagusien azalpena.
Informazio egarriz gelditu bazara eta ur handiagoetan murgildu nahi baduzu, M. C.
Paulk, C.V. Weber, B. Curtis eta M. B. Chrissis-en The Capability Maturity Model:
Guidelines for Improving the Software Procces liburua kontsulta dezakezu egarri
hori asetzeko.
2.3. SPICE (SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY
DETERMINATION)
SPICE (Software Process Improvement and Capability dEtermination) erreferen-
tzia-eredua CMMren europar bertsio eguneratua dela esan dezakegu. Eredua,
ISO/IEC7 15504 estandarrarekin lerrokatzen da orpoz orpo eta ISO/IEC 12207
estandarraren ezaugarriak ere hartzen ditu kontuan. 1987an, ISO eta IEC erakun-
deek lan-talde bat (JTC - Joint Technical Committee) eratzea erabaki zuten infor-
mazioaren teknologien arloan estandarrak eraikitzen joateko. ISO/IEC 12207
estandarrak softwarearen bizi-zikloan gertatzen diren prozesu guztiak katalogatzen
dituenez, SPICE ereduak prozesu horiek hartu zituen kontuan bere prozesu-kate-
goriak antolatzeko.
80ko hamarkadan, bai Ameriketako Estatu Batuetako baita Europako armaden
arduradunak ere, berehala konturatu ziren softwarearen konplexutasuna izugarri
ugaldu zela aurreko urteetan eta, tamalez, gehiago handituko zela etorkizunean.
Hornitzaileekiko software-kontratuak arriskutsuagoak bihurtzen ari ziren kostuak
igo ahala. Egoera horretan, zerbait egin behar zen softwarearen kalitatea bermatze-
ko eta arriskuak ekiditeko edo gutxienez apaltzeko. Aurreko orrietan ikusi dugun
28 Softwarearen ingeniaritza
7. ISO: International Organization for Standardization
IEC: International Electrotechnical Commission
legez, Ameriketako Estatu Batuetan, CMM eredu estandarra proposatzea izan zen
erantzuna. Europako indarrak, bestalde, Erresuma Batuan kokatu ziren eta hango
gobernuak lan-talde berezi bat (CPCC - Computing Policy Consultative Committee)
antolatu zuen arazoari aurre egiteko. Arazoaren ikerketa Harry Barker-en esku
gelditu zen eta horrek bi ibilbide proposatu zituen: hornitzaileekin sortzen ziren
arazoak konpontzeko, defentsa arloan bakarrik aplikatuko zen eredu bat proposatu
edo beste eredu irekiago bat antolatu, softwarearen industriari, oro har, aplikatuko
zitzaiona. Deman, bigarren aukera atera zen garaile.
1992ko ekainean The Need and Requirements for a Software Process
Assessment Standard txostena argitaratu zuten. Txostenak azpimarratzen zuen
softwarearen prozesuaren kudeaketa gauzatzeko estandar bat behar zela. Urtearen
bukaeran, ISO erakundeak, txostenari bultzada bat emateko, WG10 (Working
Group 10) lan-taldea sortu zuen aipatutako estandarra garatu eta finkatzeko. WG10
lan-taldea 1993ko urtarrilean hasi zen lanean Peter Simms eta Alec Dorling-en
ardurapean.
2.9. irudia. SPICE erreferentzia-ereduaren egituraketa.
SPICE erreferentzia-ereduak bi helburu (2.9. irudia) nagusi ditu: softwarea-
ren prozesuaren hobekuntza planifikatu eta kudeatzea, eta prozesuaren ahalmena
neurtzea. Bestalde, ereduaren diseinatzaileek hainbat ezaugarri izan zituzten kon-
tuan erreferentzia-eredu estandarraren hedapena zabala izan zedin:
· Ereduak erakunde gehienetan aplikagarria izan behar zuen eta, beraz, gene-
rikoa izan behar zuen domeinu desberdinetan aplikatzeko, kontuan izan gabe
erakundearen neurria eta egitura.
Prozesua
Prozesuaren
ebaluazioa
Prozesua
hobetu
Prozesuaren
ahalmena
neurtu
aldaketak
identifikatzen
ditu
ebaluazioaren
bidea hartu
bideratuta bideratuta
joan daiteke
ahalmena
identifikatzen
du
Software-prozesua 29
· Ereduak independentea izan behar zuen erakundearen softwarearen bizi-
ziklotik, softwarearen teknologiatik eta softwarea garatzeko metodoetatik.
· Ereduak, irizpide kuantitatiboetan oinarrituta, erabilera objektiboa eduki
behar zuen nahitaez.
· Ereduaren irteera estandarrak prozesuen profiletan gauzatu behar zuen. Bai
prozesuaren ahalmena neurtzeko bai prozesuaren hobekuntza ikuskatzeko,
profilak erabili behar ziren. Horrela, prozesuaren arduradunak informazio
zehatzagoa zuen prozesuaren nondik norakoak aztertzeko.
Ezaugarri horiek guztiak ondo finkatzeko eta estandarizatuta uzteko, eredua-
ren diseinatzaileek bederatzi zatitan antolatu zuten eraikitzen ari ziren dokumen-
tazioa (2.10. irudia). Bederatzi zati horietatik bigarren, hirugarren eta bederatziga-
rren zatiak normatiboak ziren eta beste guztiak informazio-emaileak.
2.10. irudia. SPICE erreferentzia-ereduaren arkitektura orokorra.
Ondoko paragrafoetan, zati normatibo horiek aztertuko ditugu. SPICE erre-
ferentzia-ereduaren egiturak bi dimentsio mota (2.11. irudia) erabiltzen ditu
erakundearen softwarearen prozesuaren profila eraikitzeko. Dimentsio batek pro-
zesuaren kategoriak islatzen ditu eta besteak, ostera, prozesuaren ahalmena. Pro-
zesuaren ahalmenak bost maila dauzka hautatutako eta ebaluatutako prozesuen
ahalmena neurtzeko. Irudian ikusten den legez, bederatzi prozesu-atributu erabil-
tzen dira ahalmena neurtzeko.
Prozesuaren kategoriak (2.12. irudia) bost arlotan sailkatzen dira eta
bakoitzak softwarearen eremu bat aztertzen du. Grafikoak adierazten duen bezala
ingeniaritza kategoria dimentsio horren muina da eta beste kategoriak haren ingu-
ruan antolatzen dira. Ingeniaritzarekin batera badago beste kategoria garrantzitsu
Ereduaren
Arkitektura
5 Prozesu
Kategoria
40 Prozesu
Oinarrizko
Praktikak
6 Ahalmen
Maila
9 Prozesu
Atributu
Kudeaketa
Praktikak
Prozesu
Dimentsioa
Ahalmen
Dimentsioa
Adierazleak:
N (Not)
P (Partially)
L (Largely)
F (Fully)
ISO 12207-ren
ildotik
Bezero-Hornitzailea (10 prozesu)
Ingeniaritza (9 prozesu)
Euskarria (8 prozesu)
Kudeaketa (4 prozesu)
Antolaketa (9 prozesu)
30 Softwarearen ingeniaritza
bat: bezero-hornitzaile kategoria. Softwarearen ingeniaritzaren produktuaren
eraikitzailea erakundea bada, kategoria horrek adierazten du nolako harremanak
izan behar dituen; bestalde, softwarearen ingeniaritzaren produktuaren kontsumi-
tzaileak bagara, kategoria horrek adierazten du nolako baldintzak bete behar dituen
gurekin harremanetan jarri behar den hornitzaileak.
Beste kategoriak bi horien inguruan lerrokatzen dira. Batek, euskarria ematen
du adierazteko nola antolatu nahi ditugun prozesuaren dokumentazioa, kalitatea,
egiaztapenak eta konfigurazioaren kudeaketa. Beste bi kategoriek, ostera, softwa-
rearen bizi-zikloan antolaketa-arloak egituratzeko balio dute.
2.11. irudia. SPICE erreferentzia-ereduaren dimentsio motak.
2.12. irudia. SPICE erreferentzia-ereduaren prozesuaren kategoriak.
BEZERO-HORNITZAILEA
INGENIARITZA
KUDEAKETA
ANTOLAKETA
EUSKARRIA
Prozesu Dimentsioa
Ahalmen Dimentsioa
Prozesua Prozesua Prozesua ProzesuaProzesua Prozesua
Prozesu Kategoria Prozesu Kategoria...
Ahalmen
Maila1
Ahalmen
Maila2
Prozesu
Atributu
1.1
Prozesu
Atributu
2.1
Prozesu
Atributu
2.2
Ahalmen
Maila5
Prozesu
Atributu
5.1
Prozesu
Atributu
5.2
Software-prozesua 31
Erakundearen softwarearen prozesuaren ahalmena neurtzeko, erreferentzia-
eredua (2.10. irudia) erakunde horretan gauzatzen diren praktiketan oinarritzen da,
hori baita erakundeak eskain dezakeen informazio objektiboena. Hala, prozesuen
bilakaera kontrolatzeko, oinarrizko praktika batzuk proposatzen ditu erreferentzia-
ereduak. Praktika horiek prozesuaren adierazleekin (2.13. irudia) lotzen dira eta
baliagarriak dira ebaluatzailearentzat, jakiteko, prozesuaren helburuak betetzen ari
diren ala ez. Oinarrizko praktikak lan-produktuetan gauzatzen dira, horiek baitira
erreferentzia-ereduaren irteera estandarrak.
2.13. irudia. Prozesuaren ebaluazioaren adierazleak.
Prozesuaren dimentsioa alde batera utzita, azter dezagun ahalmenaren dimen-
tsioa. Dimentsio horrekin ebaluatzaileak prozesuaren heldutasun maila neurtzen du
jakiteko (a) prozesuaren hobekuntza zenbatekoa izan den erakundea hobekuntza-
prozesuan sartuta badago edo (b) zein den prozesuaren ahalmen maila ebaluazio-
prozesu batean ari bada. Prozesu desberdinen ahalmena kontrolatzeko, kudeaketa-
praktika batzuk proposatzen ditu erreferentzia-ereduak. Praktika horiek ahalmena-
ren adierazleekin lotzen dira eta baliagarriak dira ebaluatzailearentzat jakiteko no-
raino heltzen den prozesuaren ahalmena. Eskuratzen den informazioa objektiboa
izan dadin, erreferentzia-ereduak bederatzi prozesu-atribututan egituratzen du
ahalmen-dimentsioa:
· Atributu 1.1: Prozesua gauzatu. Atributu honek ziurtatzen du prozesuaren
oinarrizko praktikak burutu egiten direla. Sarrerako lan-produktu batzuk
ditugu prozesuaren sarreran eta prozesua egikaritzen denean irteerako beste
lan-produktu batzuk eskuratzen dira. Lan-produktuen kalitatea ez da
neurtzen bakarrik, ziurtatu egiten da prozesua burutu egiten dela.
· Atributu 2.1: Prozesua kudeatu. Atributu honekin prozesua planifikatzen
den ala ez adierazten da. Maila honetan lan-produktuen kudeaketa
Ebaluazioaren
adierazleak
Ahalmenaren
adierazleak
Prozesuaren
adierazleak
Oinarrizko
praktikak
Kudeaketa-
praktikak
Lan-produktuak eta
ezaugarriak
Praktikaren eta
azpiegituraren
ezaugarriak
32 Softwarearen ingeniaritza
gauzatzen da ziurtatuz epeak ondo betetzen direla eta lan-produktuak
eraikitzeko behar diren baliabideak kontrolpean daudela.
· Atributu 2.2: Lan-produktuak kudeatu. Atributu honek ziurtatzen du lan-
produktuak ondo dokumentatuak, kontrolatuak direla eta eskatzen zaien
funtzionalitatea lortzen dutela.
· Atributu 3.1: Prozesua definitu. Prozesuaren ahalmena maila honetaraino
heldu bada prozesua estandarizatuta dagoelako da.
· Atributu 3.2: Prozesuaren baliabideak kudeatu. Prozesua estandarizatuz
gero, nahitaezkoa da prozesuaren azpiegitura ondo finkatzea prozesua
erakundean instituzionalizatzeko.
· Atributu 4.1: Prozesua neurtu. Maila honetan bai produktuaren kalitatea
bai prozesuaren kalitatea, kuantitatiboki neurtzen da. Erakundeak
mekanismo formal bat instituzionalizatzen du datuak jaso, neurtu eta
aztertzeko.
· Atributu 4.2: Prozesuaren kontrola gauzatu. Atributu honek prozesuaren
eraginkortasuna neurtu eta kudeatu egiten du. Produktuaren eta prozesua-
ren kalitatea aurreikusi egiten da eta ziurtatu mugarrietan eta kontrolpean
dagoela. Prozesuaren ahalmena ahuldu egiten bada, erakundeak baliabi-
deak dauzka lehengo maila berreskuratzeko.
· Atributu 5.1: Prozesuaren aldaketak kudeatu. Erakundearen prozesuaren
definizioa, kudeaketa edota eraginkortasuna aldatu egiten badira erakun-
dearen helburuak aldatu egin direlako, atributu honetara heldu den proze-
suak ahalmena du aldaketaren eragina iragarri eta ebaluatzeko prozesuaren
aldaketa sistematikoa gauzatuta.
· Atributu 5.2: Prozesuaren hobekuntza etengabea osatu. Maila honetan
aldaketen beharrak identifikatu egiten dira eta prozesuaren hobekuntzak
aurreikusi. Prozesuaren aldaketak era eraginkorrean gauzatzen dira.
Bukatzeko, adibide (2.14. irudia) txiki bat aztertuko dugu azaldu ditugun
prozesuaren dimentsio biak elkarrekin ipintzen dituena. Grafikoaren lerro bakoi-
tzak hausnartzeko hautatu diren prozesuen egoera islatzen du eta eskuineko aldean,
ebaluatzaileak eman dion maila adierazten da. Kontu egin ingeniaritza dela irudia
egituratzeko aukeratu den prozesu-kategoria. Zutabe bakoitzak prozesuaren atribu-
tu baten egoera8 islatzen du. Gure adibidean argi ikusten da, erakundeak, nahiko
Software-prozesua 33
8. Bazterrak ez nahasteko, prozesuaren atributu bakoitzari emango diogun balioa erreferentzia-
ereduak proposatzen duen multzotik aukeratuko da. Hau da, atributuaren ahalmena txikia bada N
(No) bat jarriko da eta atributuaren ezaugarriak partzialki betetzen badira P (Partially) bat idatziko
da. Atributuaren kudeaketa-praktikak nahiko ondo betetzen badira baina ez erabat L (Largelly) bat
jarriko da eta bete-betean gauzatzen badira F (Fully) bat. Tresna aurreratu bat erabiltzen bada prozesu
guztia kudeatzeko, adierazle horiek balio kuantitatiboak har ditzakete eta azterketa estatistikoak egin
daitezke prozesuaren ahalmena neurtzeko eta hobetzeko.
ondo kudeatzen duela proben esparrua, produktuaren ingeniaritzaren arloan. Esan
dezakegu halaber, softwarearen diseinuak maila txukuna duela. Bestalde,
softwarearen analisiaren eta mantentze-lanen ahalmen maila ez da oso handia
baina arazoen jatorria zehaztuta dago. Bukatzeko, softwarearen produktuaren
kalitate maila handitu nahi bada, zalantzarik gabe, zeharo hobetu behar da
betekizunen azterketa.
2.14. irudia. Prozesuaren dimentsioak neurtzen.
2.4. PSP (PERSONAL SOFTWARE PROCESS) ETA TSP
(TEAM SOFTWARE PROCESS)
CMM eta SPICE erreferentzia-ereduak tresna aproposak dira erakundearen
heldutasun maila neurtu eta zer egin behar den zehazteko. Beren azterketa-
ingurunea erakundearen goi-mailara zuzentzen denez taxuz betetzen dute lan hori.
Prozesuaren hobekuntza-plan bat onartuta, erakundean nola gauzatu behar den
erabakitzean sortzen da arazoa, zeren erreferentzia-ereduak oso orokorrak baitira
eta ez baitute laguntza handirik eskaintzen arlo horretan. Watts Humphrey ere,
berehala konturatu zen hutsune horretaz eta arazoa bideratzeko, lehenengo PSP
(Personal Software Process) eta ondoren TSP (Team Software Process) ereduak
diseinatu eta egituratu zituen.
Softwarearen eraiketa lan konplexua eta neketsua da hainbat partaide motataz
baliatzen baita erakundea, softwarearen ezaugarri guztiak ondo egituratzeko.
Erakundearen software-prozesuaren heldutasun maila hobetu nahi bada aldaketak
gauzatu behar dira erakunde horretan. CMM eta SPICE erreferentzia-ereduak apli-
katzen direnean erakunde informatikoan, gauza jakina da erakundeak harresi bat
aurkitzen duela hirugarren heldutasun maila gainditzeko. Alde batetik, tresnak,
metodoak eta prozesuak egokitu behar dira, eta bestetik, giza baliabideak. Software-
erakundea eraginkorra izateko software-ingeniari eraginkorrak izan behar ditu lan-
talde ondo eratuetan txertatuta. PSP eta TSP ereduen zeregina, izan ere, giza eta
talde-eraginkortasun horien maila hobetzea izango da.
Betekizunen azterketa
Softwarearen analisia
Softwarearen diseinua
Probak
Mantentze-lanak
L
L L
L
F
F F F
F FFFF
PA1.1 PA2.1 PA2.2 PA3.1 PA3.2 PA4.1 PA4.2 PA5.1 PA5.2
Prozesuaren atributuakProzesuak
(Ingeniaritza)
Maila
NL P N N N N N
F F N N NP
F F N NP L
F P N
M 1
M 2
M 3
M 4
F F F N N NL P N M 2
34 Softwarearen ingeniaritza
CMM eta SPICE erreferentzia-ereduak aztertu ditugunean proiektuaren
planifikazioaren eta kudeaketaren berebiziko garrantzia azpimarratu dugu behin
eta berriro. PSP eta TSP ereduek ikuspegi berari jarraituko diote software-ingenia-
riaren eta lan-taldearen eraginkortasun maila hobetzeko.
Watts Humphrey-k PSP eredua egituratu zuenean, jakin bazekien software-
ingeniariaren eguneroko jardunean ohiturak sustraituta egoten direla erakundeetan
eta zaila izaten dela aldaketa sakon bat proposatzea atoan. Hori dela eta, software-
laborategi kontrolatu bat eratu zuen bere proposamena aurrera eramateko. Gauzak
errazteko, eta zergatik ez diru apur bat eskuratzeko, A Discipline for Software
Engineering liburua idatzi eta argitaratu zuen. Liburuak, aipatutako laborategi
kontrolatuaren nondik norakoak azaltzen ditu eta, aldi berean, PSP ereduaren
aurkezpen zabala eta zehatza gauzatzen du. Software-ingeniariaren ohiturak
hobetu nahi direnez, liburuak egundoko garrantzia ematen dio alde praktikoari.
Horretarako, hamar ariketa kontrolatu proposatzen dira azalpen teorikoa osatzeko.
Teorikoki, PSP ereduak, CMM erreferentzia-ereduaren heldutasun kontzeptua
berreskuratu eta kontzeptu horren inguruan antolatzen du bere arkitektura
orokorra. Hau da, CMM erreferentzia-ereduan bezala, PSP ereduak (2.15. irudia)
hiru heldutasun maila izango ditu software-ingeniariaren garapena neurtu eta
egituratzeko. Maila bakoitzak helburu jakin bat du eta osagarria da bere gainean
dagoen mailarentzat. Adibidez, hasierako mailak neurketaren garrantzia azpima-
rratu nahi du, eta horretarako, azpiegitura kontrolatu bat antolatzen du software-
ingeniariak, proiektuaren denbora eta akatsen neurketaren garrantziaz ohartaraz-
teko.
2.15. irudia. PSP ereduaren heldutasun mailak.
PSP 0
Gaur egungo prozesua
Denboren eta akatsen erregistroa
Akatsen tipologia
PSP 1
Neurrien eta denboraren
estimazioa
Frogen txostena
PSP 2
Iturburu kodearen berrikuspena
Diseinuaren berrikuspena
PSP 3
Garapen ziklikoa
PSP 0.1
Programaziorako estandarrak
Tamainen neurketa
Prozesua hobetzeko proposamena
PSP 1.1
Atazen planifikazioa
Denboren planifikazioa
PSP 2.1
Diseinurako txantiloiak
Prozesu
ziklikoa
Kalitate
pertsonala
Planifikazio
pertsonala
Neurketa
pertsonala
Software-prozesua 35
Maila horretan ingeniariak hasierako hiru ariketa9 kontrolatuak gauzatzen ditu.
Ariketa bakoitzarentzat, diseinu txiki bat eraikitzen du eta programatzen hasten da.
Hori egiten ari dela, eta prozesuaren gidoi txiki bati jarraituz, denborak eta akatsak
erregistratzen ditu propio diseinatutako agirietan. Horrela, ariketa bat bukatzen
denean eta postmortem10 egoerara heltzen denean, hainbat informazio izango du
proiektu txiki bakoitzaren nondik norakoak aztertzeko. Zenbat eta ariketa gehiago
gauzatu metodologia hori erabilita, orduan eta informazio gehiago izango du
ingeniariak, haren portaeraren alde ahul eta sendoak aztertzeko. Azkenean, gauzak
ondo joan badira, prozesua hobetzeko proposamen zehatz bat egingo da eta
programaziorako estandarrak finkatuko dira.
Behin neurketaren arloa menderatzen dela baieztatzen bada, ingeniariaren
ardurak kualitatiboki aldatuko dira. Ingeniariaren jarrera pasibo izatetik aktibo
izatera igaroko da. Hau da, proiektu bat planifikatzerakoan ez da nahikoa izango
proiektu horren informazioa pasiboki jasotzea proiektua garatuz doan heinean.
Proiektua hasi baino lehen, estimazioak egitea eskatuko zaio ingeniariari, proiek-
tuak gauzatzeko zein neurri eta zenbat denbora beharko duen aurreikusteko.
2.16. irudiak azaltzen du nola egituratzen diren maila honen ezaugarri nagu-
siak bizi-zikloan zehar. Proiektuaren betekizunak definituz gero, aplikazioaren
diseinu kontzeptuala gauzatzen da. Hortik aurrera, estimazioen unean sartzen da
ingeniaria, proiektuaren egutegia eraikitzeko. Une horretan, aipatutako liburuan,
PROBE (PROxy-Based Estimating) metodoa erabiltzea proposatzen du Watts
Humphrey-k, ingeniariari estimazioen lana errazteko eta egituratzeko.
PROBE metodoa, akronimoak dioen bezala, proxyetan oinarritzen da estima-
zioak gauzatzeko. Proxy hitzak beharbada beldurtu egin dezake baina atzean dagoen
esanahia, ez da batere beldurgarria. Diseinu kontzeptuala bukatu eta gero, aplika-
zioak izango dituen objektuak identifikatzeko eskatzen dio metodoak ingeniariari.
Objektuak identifikatu ondoren, bakoitzari kategoria bat itsasten zaio eta objektuak
zenbat metodo izango dituen zehazten da. Neurrien estimazioak eraikitzen joateko
metodoen batez besteko neurri kualitatiboa11 adierazten da eta informazio hori
guztia Humphrey-k berak proposatutako txantiloi (2.17. irudia) estandarizatu
batera iraultzen da.
36 Softwarearen ingeniaritza
9. Ariketen zailtasuna hasierako mailetan ez da handia, helburua ez baita ariketa azkar ebaztea.
Helburua da aztertzea ebazpenaren garapena nola joan den egituratuz eta gauzatuz denboran zehar.
10. Egoera horretan, agirietan jasotako informazioa biltegiratu egiten da, gehienetan, euskarri
informatiko bat erabilita.
11. Kualitatiboa diogu ez baita zenbakiz adierazten, hitzez baizik: Very Small, Small, Medium,
Large eta Very Large.
Geroago ikusiko dugu termino bakoitza zenbaki batez ordezkatzen dela kalkuluak gauzatzeko
estimazioetan.
2.16. irudia. Proiektuaren bizi-zikloa.
Informazio kualitatiboa kuantitatibo bihurtzeko aipatutako liburuan taula
(2.17. irudia) estandar batzuk agertzen dira bihurketa gauzatzeko. 2.17. irudiak
objektuaren kategoria zehaztu eta gero zein den bere batez besteko neurria adieraz-
ten du, aplikazioa C++ programazio-lengoaia erabilita garatzen bada. Jakina, taula
hori, bere beharretara egokitu beharko du ingeniariak haren programazio-inguru-
nean, kategoriak eta zenbakiak alda baitaitezke erabiltzen duen teknologian.
2.17. irudia. Informazio kualitatibotik informazio kuantitatibora.
Mota VS VLMS L
Calculation
Data
I/O
Logic
Set-up
Text
2.34 5.13 11.25 24.66 54.04
2.60 4.79 8.84 16.31 30.09
9.01 12.06 16.15 21.62 28.93
7.55 10.98 15.98 23.25 33.83
3.88 5.04 6.56 8.53 11.09
3.75 8.00 17.07 36.41 77.66
Lerro kopurua C++ programazio-lengoaian
PROBE metodoa
Betekizunak
definitu
Diseinu
kontzeptuala
Neurrien
estimazioa
Baliabideen
estimazioa
Egutegia
eraiki
Produktua
garatu
Datuak
jaso
Prozesuaren
analisia
Baliabideak
Produktibitate
datu-basea
Neurrien
datu-basea
Bezeroaren
beharrak
Produktua
Txostenak
atera
Bezeroa
Kudeaketa
Software-prozesua 37
2.18. irudia. Neurriak estimatzeko txantiloia.
Objektu berrien neurriak estimatu eta gero, gehitutako eta aldatutako iturbu-
ru-lerro kopurua kalkulatzen da 2.19. irudian ikusten den legez. Eragiketa hori
burututa, programaren neurri orokorra eta beharko den denbora estimatzen dira
erregresio lineala erabilita. Bukatzeko, iragarpen-tartea kalkulatzen da estimazioa-
ren fidagarritasuna zehazteko.
Table C39 Size Estimating Template
BBBBAAAASSSSEEEE PPPPRRRROOOOGGGGRRRRAAAAMMMM LLLLOOOOCCCC ESTIMATE ACTUAL
BASE SIZE (B) => => => => => => => =>
=> =>
0
LOC DELETED (D) => => => => => => =>
=> =>
0
LOC MODIFIED (M) => => => => => => =>
=> =>
0
OOOOBBBBJJJJEEEECCCCTTTT LLLLOOOOCCCC
BASE ADDITIONS TYPE METHODS REL. SIZE LOC LOC
TOTAL BASE ADDITIONS (BA) => => => => => => 0
NEW OBJECTS TYPE METHODS REL. SIZE LOC (New Reused*)
Sarrera I/O 1 large 22
Zerrenda Data 3 medium 27*
Kalkulatu BB Calc 1 medium 11
Kalkulatu DS Calc 1 medium 11
Idatzi emaitza I/O 1 large 22
TOTAL NEW OBJECTS (NO) => => => => => => => 93
REUSED OBJECTS
REUSED TOTAL (R) => => => => => => => =>
SIZE TIME
Estimated Object LOC (E): E = BA+NO+M 93
Regression Parameters: 0 Size and Time 38 110
Regression Parameters: 1 Size and Time .8 1.5
Estimated New and Changed LOC (N): N = 0 + 1 *E 112
Estimated Total LOC: T = N + B - D - M + R 112
Estimated Total New Reuse (sum of * LOC): 27
Estimated Total Development Time: Time = 0 + 1 *E 250
Prediction Range: Range N/A N/A
Upper Prediction Interval: UPI = N + Range N/A N/A
Lower Prediction Interval: LPI = N - Range N/A N/A
Prediction Interval Percent: N/A N/A
38 Softwarearen ingeniaritza
2.19. irudia. Estimazioen egituraketa.
Adibide txiki bat garatuko dugu azaldutako prozesu guztia urratsez urrats
aztertzeko. Garatuko dugun aplikazio informatikoak, betekizunen azterketa
burututa, bost objektu/metodo nagusi izango ditu eta 2.20. irudian agertzen diren
ezaugarriak izango ditu. Jakina, ezaugarri horiek zehazteko, ingeniariaren
eskarmentua erabili beharko da eta aitzinean (2.17. irudia) aipatu dugun taularen
informazioa. Informazio hori guztia eraikita eta aipatutako txantiloi estandarrera
(2.18. irudia) iraulita, historikoki biltegiratuz joan garen informazioa erabilita,
neurrien eta denboren estimazioa (2.21 eta 2.22. irudiak) gauzatzen da erregresio
lineala aplikatuta. Kalkulatutako informazio hori txantiloian biltegiratzen da eta,
hala nahi izanez gero, iragarpen-tartea kalkulatzen da. 0 eta 1 erregresio-parame-
troen balioak kalkulatzeko honako formula hauek aplikatzen dira:
1
1
2 2
1
0 1
=
-
-
= -
=
=
x y nx y
x n x
y x
i i bb bb
i
n
i bb
i
n
bb bb
( )
Identifikatu objektuak (proxy-ak)
Metodo
kopurua
Objektu
mota
Neurriak Berrerabilitako
kategoriak
Kalkulatu gehitu eta
aldatutako iturburu-lerro kopurua
Estimatu programaren neurria
eta
behar den denbora garatzeko
Kalkulatu
iragarpen-tartea
Estimazioa
Diseinu
kontzeptuala
Software-prozesua 39
2.20. irudia. Aplikazioaren objektu/metodoen ezaugarriak.
Datuen korrelazio estatistikoa handia edo txikia den jakiteko beste honako
formula honetaz baliatuko gara korrelazio-koefizientearen balioa eskuratzeko:
Hasieran aipatu dugu ingeniariaren ohiturak, gizakiaren ohitura gehienak le-
gez, trinko sustraituta egoten direla eta nahiko zaila izaten dela ingeniariaren por-
taera atoan aldatzea. Watts Humphrey-k gauza bera pentsatu zuen PSP metodoa
egiaztatzeko orduan, bazekien ez zela nahikoa bat edo bi ingeniarirekin baieztatzea
metodoa eta SEI (Software Engineering Institute) erakundeko 300 ingeniari auke-
ratu zituen aipatutako ariketa kontrolatuak diseinatu eta programatzeko.
r x y
n x y x y
n x x n y y
i i
i
n
i
i
n
i
i
n
i
i
n
i
i
n
i
i
n
i
i
n
( , ) =
- -
-
-
= = =
= = = =
1 1 1
2
1 1
2
2
1 1
2
Sarrera
Biltegiratu
Kalkulatu BB
Kalkulatu DS
Idatzi emaitza
Objektu/Metodoa Mota Metodo K. Neurria Iturburu L.K.
Sarrera I/O 1 Large 22
Zerrenda Data 3 Medium 27
Kalkulatu BB Cal. 1 Medium 11
Kalkulatu DS Cal. 1 Medium 11
Idatzi emaitza I/O 1 Large 22
93
40 Softwarearen ingeniaritza
2.21. irudia. Neurrien estimazioa.
2.22. irudia. Denboraren estimazioa.
2.23. iruditik 2.25. irudira doazen grafikoek burututako azterketaren
emaitzak jasotzen dituzte. Grafiko guztietan antzeko portaera antzematen da, batez
ere, laugarren ariketatik aurrera. Gogoratu laugarren ariketa horretatik aurrera,
ingeniaria, PROBE metodoa hasten dela erabiltzen estimazioak egiteko. Hala, ez
gara harrituko ingeniariaren errorea denbora estimatzeko nabarmen jaisten bada
Erregresio-parametroak
= 110 = 1.5 r2 = 0.7
Est Time = + * Est obj LOC
Est Time = 110 + 1.5 * 93
Est Time = 250 minutu
Erregresio lineala aplikatu
(Denboraren estimazioa)
y = 1.4507x + 109.8
R2 = 0.6869
0
50
100
150
200
250
300
350
400
450
500
0 50 100 150 200 250
Minutuak
Objektu/Metodoa Mota Lerro K.
Sarrera I/O 22
Zerrenda Data 27
Kalkulatu BB Calc 11
Kalkulatu DS Calc 11
Idatzi emaitza I/O 22
93
Denbora estimatua
y = 0.7953x + 37.694
R2
= 0.8147
0
50
100
150
200
250
0 50 100 150 200 250
Iturburu-lerro kopuru estimatua
Erregresio-parametroak
= 38 = 0.8 r2 = 0.8
Est N&C LOC = + * Est obj LOC
Est N&C LOC = 38 + 0.8 * 93
Est N&C LOC = 112 lerro
Objektu/Metodoa Mota Lerro K.
Sarrera I/O 22
Zerrenda Data 27
Kalkulatu BB Calc 11
Kalkulatu DS Calc 11
Idatzi emaitza I/O 22
93
Erregresio lineala aplikatu
(Neurrien estimazioa)
Iturburu-lerrokopurua
Software-prozesua 41
laugarren ariketatik aurrera, 2.23. irudian ikusten den legez. Batez beste, denbora-
ren estimazioaren errorea % 55etik % 27ra jaisten da. Gauza bera gertatzen da
konpilazioan eta frogetan sartu ditugun akatsak aztertzen badira (2.24. irudia).
Hasieran, batez beste 110 bat akats sartzen dira 1.000 lerrotan, eta amaierarako, 20
bat akatsetara jaisten da kopuru hori. 2.25. irudia ere nahiko deigarria da beste
informazio zeharo interesgarri bat ematen digulako, hau da, nahiz eta softwarearen
garapen-prozesuaren konplexutasuna handitu laugarren ariketatik aurrera, ingenia-
riari planifikazio zehatzak eskatuta, beraren produktibitatea ez da jaisten eta ez du
lerro gutxiago programatzen, aitzitik, orduko programatzen duen lerro kopurua
bertsua da esperimentuaren hasieran eta bukaeran.
Bukatzeko, 2.26. irudiak beste honako ezaugarri hau jasotzen du: bizi-
zikloaren atal bakoitzak hartzen duen garrantzia ariketa bakoitzaren garapenean.
Hasieran, deigarria egiten da diseinuaren garrantzi xumea eta nola ariketaz ariketa
handituz doan nabarmenki. Bestalde, azpimarragarria egiten da ere, kodeketaren,
konpilazioaren eta frogen bilakaerak ingeniarien denborak aztertzen direnean
nabarmenki jaisten direla diseinuaren kalitatea hobetuz doan heinean. Kontu egin,
bukaeran, ingeniariak denbora gehiena diseinatzen igarotzen duela horrek dakarren
guztiarekin: akats gutxiago iturburu-kodean eta estimazio hobeak proiektuaren
planifikazioan.
2.23. irudia. Denbora-estimazioaren errorea.
Batez besteko estimazio okerra
PSP mailaren batez bestekoa
11109876543210
0.2
0.3
0.4
0.5
0.6
0.7
Denbora-estimazioaren errorea
Ariketa-zenbakia
MinutuestimatuakÂEgungominutuak/Minutuestimatuak
42 Softwarearen ingeniaritza
2.24. irudia. Batez besteko akatsak.
2.25. irudia. Batez besteko lerro kopurua orduko.
11109876543210
0
10
20
30
40
50
60
70
80
90
100
110
120
Akats kopurua
Ariketa-zenbakia
Batezbestekoakatskopurua
Batez besteko akatsak
PSP mailaren batez bestekoa
11109876543210
0
10
20
30
40
50
60
70
80
90
100
110
120
Akats kopurua
Ariketa-zenbakia
Batezbestekoakatskopurua
Batez besteko akatsak
PSP mailaren batez bestekoa
Software-prozesua 43
2.26. irudia. Bizi-zikloaren arlo bakoitzaren batez besteko denborak
Aurreko orrietan azaldu dugu CMM eta SPICE erreferentzia-ereduek erakunde
osoa hartzen zutela jomugatzat softwarearen prozesuaren heldutasun maila ku-
deatzeko; bestalde, PSP metodoak ingeniariaren trebetasun pertsonalak hobetzen
zituen prozesu estandarizatu bat finkatuz haren eguneroko jardunean. Horretarako,
metodoak neurketaren arloa hobetzen zuen hasierako unean eta proiektuaren
planifikazioaren kalitate maila geroago, estimazio egokiak gauzatuz. Agerian
gelditzen da, jauzi handi xamarra burutu dugula erakundearen goi-mailatik behe-
mailako ingeniariarengana heltzeko. Erreferentzia-ereduetan antzeman egiten zen
eta PSP metodoan susmatu, ingeniariaren lana, salbuespenak salbuespen, ez dela
era isolatuan gauzatzen proiektuaren bilakaera aurrera doan heinean. Software-
ingeniariaren fruituak hutsalak lirateke lan-taldearen talde-lanean ez baleude ondo
txertatuta. Aztertzen ari garen software-prozesuaren arloan, TSP (Team Software
Process) metodoaren eskuetan gelditzen da betebehar hori. 2.27. irudiak PSP
metodoa eta TSP metodoa nola erlazionatzen diren islatzen du lan-taldearen ikus-
pegitik. Laburbilduz, PSP metodoa taldearen partaideen eraginkortasunaz ardura-
tzen da eta TSP metodoa, ostera, taldearen kudeaketaz.
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1 2 3 4 5 6 7 8 9 10
Ariketa-zenbakia
Diseinua
Konpilazioa
Kodeketa
Testa
44 Softwarearen ingeniaritza
2.27. irudia. PSP eta TSP metodoen lan-talde erlazioak.
Proiektu guztietan, hasiera batean, proiektua dimentsionatu ondoren eta siste-
maren betekizunak aztertuta, lan-taldea eraiki beharko da proiektua garatzeko.
Urrats horretan, argi utzi beharko da zein diren proiektuaren helburuak eta
arriskuak eta nola gauzatuko den proiektuaren planifikazioa. Orobat, rolak finkatu
beharko dira eta atazak banatu partaideen artean. Horretarako, organigrama
estandarizatu (2.28. irudia) bati jarraitzen zaio diseinu kontzeptualetik hasita
planak finkatu arte. Hori eginez gero, software-ingeniariak, atazak gauzatzen ditu
banaka edo azpitaldeka, PSP metodoaren teknikak erabilita.
PSPk
trebetasunak
lantzen ditu
TSP
lan-taldearen
eraiketa
TSP
lan-taldea
talde-lanean
Kontuan hartu:
Taldearen
partaideak
Kontuan hartu:
Taldearen
ohiturak
Kontuan hartu:
Taldearen
kudeaketa
Lan-taldeak integratuta daude
produktu egokia lortzeko
Neurketa pertsonalak
Prozesu bideratuak
Estimazioa eta planifikazioa
Kalitatearen kudeaketa
Proiektuaren helburuak
Rolak taldearen barruan
Taldearen prozesua
Proiektuaren planifikazioa
Planen orekatze-lana
Arriskuen analisia
Lan-taldearen komunikazio
maila
Lan-taldearen koordinazioa
Egoeraren erregistroa
Proiektuaren txostenak
Software-prozesua 45
2.28. irudia. TSP metodoaren organigrama kontzeptuala.
Atazak garatzen ari den aldi berean, PSP metodoa aplikatuta, kalitatezko soft-
warea eraikitzen saiatuko da ingeniaria proiektuaren kalitate-planaren gomendioei
jarraituz. Aholku horietan software-osagai bakoitzaren kalitate-profila zehazten da
eta ingeniariak, une oro, osagaiarekin lortzen ari den profila, parekatu egin beharko
du, jomuga gisa ipinita dagoenarekin. Profilak prozesuaren metrika batzuk zehazten
ditu ziurtatzeko eraikitzen den osagaiak eskatutako kalitatea daukala. Erabiltzen
diren metrikak nahiko ezagunak eta orokorrak dira softwarearen ingeniaritzan eta
erabat adostuta daude, ez baitira propio diseinatu TSP metodoan erabiltzeko.
Honako hiru arlo hauetan sailkatzen dira aipatutako metrikak:
1. Diseinuarekin lotuta daudenak. Diseinuak proiektu osoan duen garrantzia
neurtzen dute metrika hauek. Helburua ohartaraztea da zaila dela kalita-
tezko softwarea eraikitzea, software hori itsumustuan eraiki bada zuzenean
igarota betekizunetatik programaziora. Metrika hauek kontrolatu nahi dute,
ingeniariak diseinuari eman dion garrantzia egokia dela haren eguneroko
jardunean.
2. Berrikuste-ekintzekin kateatuta daudenak. Egindakoa egiaztatzea da metrika
hauen helburua, arazoak aurreikusi eta alboratzeko albait arinen. Berrikus-
katze-prozesua diseinuari eta iturburu-kodeari aplikatuko zaie bakoitzaren-
tzat metrika propioa zehaztuta. Horrela, aurreko puntuan diseinuarekin
legez, hemen ere, ingeniariak, egiaztatu ahal izango du berrikuskatzeari
eskaintzen dion denbora egokia den ala ez.
Neurriak
estimatu
Diseinu
kontzeptuala eraiki
Planifikazio
pertsonala burutu
Akatsen maila
estimatu
Prozesua eta
atazak definitu
Atazak
estimatu
Neurrien
txostena
Sistemaren
txostena
Atazen
txantiloia
Egutegiaren
txantiloia
Planifikatu atazak
eta
lan-taldearen
egutegia sortu
Planak finkatu
(taldea, egutegia
eta kalitatea)
Kalitate-txostena
Atazak eta
egutegi pertsonalak
Orekatu
Betekizunak
Diseinua
LOC
Kalitate-parametroak
Sartutako eta
konpondutako
akatsak
Atazen
denborak
Behin betiko plana
46 Softwarearen ingeniaritza
Osagaiak
eta
funtzioak
egituratu
3. Hirugarren arloko metrikek akatsen dentsitatea neurtzen dute konpilazioan
eta proba bateratzaileetan. Metrika hauekin, erakundeak edota lan-taldeak
akatsen dentsitate desiragarria finkatu behar dute eta kopuru horretara ger-
turatzen saiatu behar da ingeniaria edo lan-taldea. Konpilazioan aurkitzen
den akatsen dentsitateak kodeketaren eta iturburu-kodearen berrikuspe-
naren kalitatea neurtzen du. Egin kontu ez dela prozesu horien bukaerako
emaitzaren kalitatea neurtzen, prozesua bera baizik. Emaitzaren kalitatea,
hots, bukaerako softwarearen kalitatea, proba bateratzaileetan aurkitzen
den akatsen dentsitateak neurtzen du.
Horrenbestez, metrika guztiak azaleratzen baditugu, osagai bat eraikitzeko
aplikatuko den prozesuaren kalitate-profilak bost dimentsio izango ditu:
Dimentsio bakoitzaren irizpidearen balioa Humphrey-ren taldeak proposatu
zuen bere garaian eta osagai estandarraren kalitate-profil desiragarria finkatzeko
erabili ohi izan da harrezkero.
Bukatzeko, ingeniari batek osagai bat garatzerakoan bildu dituen balioak
aztertuko ditugu prozesuaren kalitate-profilaren ikuspegitik. 2.1. taulak ingenia-
riak biltegiratu dituen balioak jasotzen ditu eta balio bakoitzak kalitate-profilaren
dimentsio bat du jomuga. Balio denak batuta aztertzen baditugu, argazki orokorrak
2.29. irudiaren itxura hartuko luke. Irudiak irizpidearekiko dimentsioaren kalitatea
neurtzen du eta argazki azkar baina esanguratsua ematen digu, ingeniariak nola
Kalitate-profilaren dimentsioa Irizpidea
Diseinu/Kodeketa-denbora Diseinuari eskainitako denborak kodeketari
eskainitakoaren erdia izan behar du
gutxienez
Diseinuaren berrikuskatze-denbora Diseinuaren berrikuskatzeari eskainitako
denborak diseinuari eskainitakoaren erdia
izan behar du gutxienez
Kodeketaren berrikuskatze-denbora Kodeketaren berrikuskatzeari eskainitako
denborak kodeketari eskainitakoaren erdia
izan behar du gutxienez
Akatsen dentsitatea konpilazio-garaian Konpilazio-garaian akatsen dentsitateak
honako muga hauetan mugitu behar du: 10
akats baino gutxiago azaleratu behar dira
1.000 iturburu-kode lerroko
Akatsen dentsitatea proba bateratzaileetan Proba bateratzaileetan akatsen dentsitateak
honako muga hauetan mugitu behar du: 5
akats baino gutxiago azaleratu behar dira
1.000 iturburu-kode lerroko
Software-prozesua 47
bete duen ibilbidea diseinu kontzeptualetik proba bateratzaileetaraino. Gure adibi-
dean esan dezakegu ingeniaria txintxo samar portatu dela orokorki, dimentsio
gehienetan eskatutakoa bete baitu. Agian, ohartarazi beharko litzaioke osagai bat
eraikitzerakoan diseinuaren berrikuskatze-denbora zaindu egin beharko lukeela,
oso gutxi ematen baitu berrikuskatze-arlo hori betetzen.
2.1. taula. Kalitate-profilaren dimentsioen balioak.
2.29. irudia. Kalitate-profilaren dimentsioak.
Kalitate-profilaren dimentsioak Kalitate-profilaren dimentsioaren balioak
Neurria 160 iturburu-kode lerro
Diseinu-denbora 40 minutu
Diseinuaren berrikuskatze-denbora 8 minutu
Kodeketa-denbora 74 minutu
Kodeketaren berrikuskatze-denbora 31 minutu
Akats kopurua konpilazioan 0 akats
Akats kopurua proba bateratzaileetan 1 akats
Diseinu-denbora/ Kodeketa-denbora 0.54
2 x (Diseinuaren berrikuskatze-denbora /
Diseinu-denbora)
0.40
2 x (Kodeketaren berrikuskatze-denbora /
Kodeketa-denbora)
0.84
Akatsen dentsitatea konpilazio-garaian 0 akats / 1.000 iturburu-kode lerro
Akatsen dentsitatea proba bateratzaileetan 6.25 akats / 1.000 iturburu-kode lerro
48 Softwarearen ingeniaritza
Kodeketaren berrikuskatze-denbora
Diseinu / Kodeketa-denbora
Akatsen dentsitatea konpilazio-garaian
Diseinuaren berrikuskatze-denbora
Akatsen dentsitatea proba bateratzaileetan
2.5. MUTURREKO PROGRAMAZIOA
Txina zaharrak Taoa eratu zuen Naturaren ezaugarriak antolatzeko. Testuinguru
horretan, neguak uda dakar, iluna argian urtzen da eta gaztaroak aurretik dauzka
biltegiratuta zahartzaroko ajeak. Yin eta Yang indar osagarrien eragina, nonahi eta
noiznahi, azaleratzen da. Batak, bestea behar du une oro, ez baitira gauza isolatuta
agertzeko.
Parajeago etorrita eta asagoago joanda berriro, denboran, koka gaitezen
Vatikanoan, hain zuzen, XVI. mendearen hasieran. Vatikanoko Signatura gelan,
Rafael Sanzio (1483-1520), gerora entzute handiko Rafael, Atenasko Eskola fresko
handia margotzen ari da Julio II.a aita santuaren agindupean. Perspektiba maisuki
erabilita, ikuslearen arreta berak nahi duen tokira erakartzen du pintoreak. Eta zein
da toki hori? Freskoaren erdigunea.
Erdigunean, Platon eta Aristoteles daude bakoitza liburu batekin, Platonek
bere Timeoa eta Aristotelek bere Etika. Teoria eta ideien mundua alde batetik;
Naturaren formena eta behaketena bestetik. Batak, goi zerutiarrera zuzentzen du
hatz erakuslea; besteak, esku-ahurra, behegaineruntz. Milaka urte geroago eta
berriro ere, Yin eta Yang indarrak pil-pilean. Areago, Rafaelek, perspektibaz
baliatuta, bertikaltasunarekin bateratzen du sakontasuna, arreta bilatzeko. Baina
jakin badaki, perspektibaren sakonera orekatu egin behar duela lehen planoarekin
eta gainera horizontalki, indarrak parekatzeko. Horretarako, filosofoz betetzen du
eszena, poliki-poliki, hierarkikoki pilatuta, Platon eta Aristotelesen ingurumarian.
Freskoan, bai edukian baita edukiontzian ere, indar bi jartzen dira jokoan.
Indar bi edukiontzian, perspektiba orekatzeko; indar bi edukietan, munduaren
ikuspegi bi orekatzeko. Badirudi indar bat bestearen gehiegikeriak moteltzeko
eraiki dela aurea mediocritas baten mesederako. Informatikan ere, azken boladan,
erreferentzia-ereduen arloari bere Yang indarra sortu omen zaio. Indar berri hori
gehiegikeriak apaltzeko etorri omen da, erreferentzia-ereduaren burokrazia
astunari hegoak ipintzeko. Mugimendu iraultzaile postmoderno gehienak legez,
indar berri horren zaleek, Interneten (www.agilemanifesto.org) kokatu dute
beren manifestua garaiek hala agintzen baitute. Agiriak (2.30. irudia) aipatutako
Yin eta Yang indarren borroka irudikatzen du, hots, nirekin edo nire kontra, dena
edo ezer ez dinamika ezaguna. Metodo arinen, azkarren eta leunen zaleak, pertsona
eta elkarrekintzak maite ditu, ez prozesuak eta tresnak. Funtzionatzen duen
softwareak lehentasuna du dokumentazioaren aurrean. Bezeroaren laguntza
nahitaezkoa da proiektuaren bizi-ziklo osoan. Aldi berean, laguntza hori ondo
gauzatzen bada, ez dago zertan denbora gehiegirik galdu kontratuen hitzarmen
astunetan. Aldaketak gertatzen direnean erantzunak azkarra izan behar du eta
horretarako ez dugu ur handitan sartu behar proiektuaren planifikazioa antolatze-
rakoan. Emaitza azkarrak nahi baditugu zenbat eta planifikazio gutxiago hobe.
Software-prozesua 49
Gehienok ados egongo gara, agiriaren bultzatzaileek dioten bezala, agiriaren
ezkerreko ezaugarriak desiragarriak direla eta norbaitek esan lezake, gainera, beste
hiruzpalau gehiago jarriko lituzkeela. Arazoa eskuineko ezaugarriekin sortzen da:
norbaitek ezagutzen ote du proiektu-arduradun bat prozesuak eta tresnak
baztertuko lituzkeena elkarrekintzak bultzatuta horren ordez? Eta gauza bera beste
ezaugarri guztiekin. Nork zokoratuko lituzke erabat eskuineko ezaugarriak
eskerrekoez ordezkatuz? Kent Beck eta enparauek badirudi baietz. Ez naiz ni orain
hemen hasiko Beck jaunaren merezimenduak12 zalantzan jartzen, asko baitira.
Hemen ez gara informatikari lurtarraz arituko, harago joango gara eta haren izaera
mesianikoaz jardungo gara. Israelgo erreinua berreraikitzeko beste mesias batek
aurrea hartu zionez, gure salbatzaile berriak informatikara bideratu zituen bere
ahaleginak softwarearen erreinua berreraikitzeko.
Mesianiko guztiek legez, gure informatikari mesianikoak bere teofania
propioa izan zuen eta kontenplazio-egoera hartako estasiaren emaitza, liburu
batean jaso zuen: Extreme Programming Explained. Embrace Change.
Egoerak hala behartuta eta telepredikarien zantzuei jarraituta ideiak barreia-
tzeko, liburuak sekulako arrakasta izan zuen salmentetan. Laburbilduz, esan
dezagun liburuak muturreko programazioaren (Extreme Programming) dogma na-
gusiak jasotzen dituela. Saltzaile onen teknikak erabilita, hitz egoki eta zirraraga-
rria bilatu behar zen eta hor zegoen extreme hitza prest horretarako, kiroletan erruz
erabiltzen zena rafting, Softwarearen ingeniaritza: I. atala. Softwarearen garapenaren zenbait arlo