Programaro

Ĉi tiu artikolo temas pri kolekta kaj vasta termino. Por unuopa kolekto da komandoj rigardu la paĝon Komputila programo.

Du programistoj laborante ĉe IBM Tipo 704 ĉe la National Advisory Committee for Aeronautics (NACA), 1954.

Programaro (aŭ softvaro) estas aro de iloj logikaj (ne fizikaj) de komputilaj sistemoj, kiuj regas kaj lasas regi ĝin por realigado de konkreta laboro. Programaro povas esti, ekzemple, programoj por skribi dosierojn, registri aŭ aŭskulti sondosierojn, esplori interreton, la operaciumon (Linukso, Vindozo) ktp...

Eble la difino plej ĝusta de programaro estas de Instituto de inĝenieroj elektronikaj kaj elektroteknikaj en sia normo 729: "La sumo de la programoj de komputado, procedoj, reguloj, dokumentoj kaj asociataj datumoj, kiuj estas parto de komputada sistemo". Laŭ ĉi tiu difino, la programaro konsistas ne nur el programoj sed ankaŭ el ĉiuj datumoj konserveblaj per komputika memoro aŭ datumportilo.

Kreado de programaro

Programara serĉilo en Ubuntu 13.10.

La kreado de programaro estas kompleksa procedo de analizo tra programado ĝis testo de la koncernaj programoj.

Programaro estas realigita antaŭe mense ellaborita verko. "Realigita" signifas, ke programaro disponeblas sur dvd, kd, diskedo aŭ alia komputila dosierujo.

Pli detalaj informoj troveblas en artikolo Programisto.

Programisto, disvolvigisto aŭ komputilprogramisto, aŭ ankaŭ softvara inĝeniero estas persono kiu kreas komputilan programaron. La termino komputilprogramisto povas referenci al specialisto en unu areo de komputiloj aŭ ĝeneralisto kiu verkas kodojn por multaj tipoj de programaro. La fakulo kiu praktikas aŭ profesias formalan alproksimigon al programado povas esti konata ankaŭ kiel program-analizisto.

Etapoj en la disvolvigo de la programaro

Elpreno, analizo kaj specifigo de postuloj

Komence de evoluo (ne de projekto), ĉi tiu estas la unua fazo kiu estas efektivigita, kaj, depende de la procezmodelo adoptita, ĝi preskaŭ povas finiĝi por transiri al la sekva etapo (kazo de Modelo de Renutrita Kaskado) aŭ ĝi povas esti farita parte kaj poste reveni al ĝi (kazo de Refoje Pliiĝanta Modelo aŭ aliaj de evolua naturo). Per simplaj vortoj kaj esence, dum ĉi tiu fazo, la funkciaj kaj nefunkciaj trajtoj, kiujn la estonta programo aŭ evoluota sistemo devas plenumi, estas akiritaj, kolektitaj kaj precizigitaj.

La avantaĝoj de la karakterizaĵoj, kaj de la sistemo aŭ programo evoluota, kaj de sia medio, ne-funkciaj parametroj kaj arkitekturo dependas ege de kiom bone atingita ĉi tiu etapo estas. Ĉi tio verŝajne estas la plej grava kaj unu el la plej malfacilaj fazoj atingeblaj precize, ĉar ĝi ne estas aŭtomatigebla, ĝi ne estas tre teknika kaj ĝi dependas plejparte de la lerteco kaj sperto de la analizisto kiu plenumas ĝin.

Ĝi forte implikas la uzanton aŭ klienton de la sistemo, tial ĝi havas tre subjektivajn nuancojn kaj estas malfacile modeli kun certeco aŭ apliki teknikon, kiu estas "plej proksima al la taŭga" (fakte ne ekzistas "strikte taŭga"). Kvankam pluraj metodaroj estis elpensitaj, inkluzive de subteno de programaro, por kapti, ellogi kaj registri postulojn, ne ekzistas neerara aŭ absolute fidinda maniero, kaj bonaj kriterioj kaj multe da komuna racio devas esti aplikitaj kune de la analizistoj respondecaj pri la tasko; ankaŭ estas esence atingi fluidan kaj taŭgan komunikadon kaj komprenon kun la fina uzanto aŭ kliento de la sistemo. La plej grava artefakto rezultiĝanta el la kompletigo de ĉi tiu etapo estas kio estas konata kiel la programarpostula specifigo aŭ simple la ERS-dokumento.

Kiel dirite, la kapablo de la analizisto interagi kun la kliento estas esenca; la komuna afero estas, ke la kliento havas ĝeneralan celon aŭ problemon solvandan, li tute ne konas la areon (komputiko), nek ĝian ĵargonon, li eĉ ne scias precize, kion la programaro devas fari (kio kaj kiom da funkcioj), multe malpli, kiel ĝi devus funkcii. En aliaj malpli oftaj kazoj, la kliento "pensas" ke li scias precize kion la programaro devas fari, kaj ĝenerale li nur parte pravas, sed lia obstino malhelpas la kaptan taskon. La analizisto devas havi la kapablon trakti ĉi tiujn specojn de problemoj, kiuj inkluzivas homajn rilatojn; oni devas scii kiel metiĝi je la nivelo de la uzanto por ebligi adekvatan komunikadon kaj komprenon. Estas malmultaj situacioj, en kiuj la kliento scias kun certeco kaj eĉ kompleteco, kion li postulas de sia estonta sistemo, tio estas la plej simpla kazo por la analizisto.

La taskoj rilataj al kaptado, eligo, modelado kaj registrado de postuloj, krom esti ekstreme gravaj, povas esti malfacile atingi ĝuste kaj daŭri longan tempon rilate al la tuta evoluprocezo; la procezo kaj metodaroj por efektivigi ĉi tiun aron de agadoj estas normale supozitaj de programara inĝenierarto, sed pro la menciita komplekseco, oni nuntempe parolas pri postula inĝenierarto, kvankam ĝi ankoraŭ ne ekzistas formale.

Estas stud- kaj esplor-grupoj tra la mondo, kiuj ekskluzive dediĉas sin al elpensado de modeloj, teknikoj kaj procezoj por provi atingi la ĝustan kapton, analizon kaj registradon de postuloj. Ĉi tiuj grupoj estas tiuj, kiuj kutime parolas pri postula inĝenierado; tio estas, oni konsideras ĝin kiel simpla areo aŭ fako sed ne kiel universitata diplomo en si mem.

Iuj postuloj ne bezonas la ĉeeston de la kliento por esti kaptitaj aŭ analizitaj; en kelkaj kazoj, la analizisto mem povas proponi ilin aŭ eĉ unuflanke alpreni decidojn, kiujn li opinias taŭgaj (kaj en funkciaj kaj nefunkciaj postuloj). Por citi verŝajnajn ekzemplojn: kelkaj postuloj pri la arkitekturo de la sistemo, ne-funkciaj postuloj kiel tiuj rilataj al efikeco, nivelo de subteno por operaciaj eraroj, evoluplatformoj, internaj rilatoj aŭ ligiloj inter informoj (inter rekordoj aŭ datumtabloj) por stoki en la kazo de datumbazoj aŭ datumbazoj, ktp. Iuj funkciaj kiel malĉefaj aŭ subtenaj ebloj necesaj por pli bona aŭ pli facila operacieco; ktp

Akiri specifojn de la kliento (aŭ de aliaj intervenantaj aktoroj) estas tre interaga kaj ripeta homa procezo; normale, kiam la informoj estas kaptitaj, ĝi estas analizitaj kaj redonataj al la kliento, rafinante, polurante kaj korektante ĝin se necese; kia ajn la ERS-metodo uzata. La analizisto devas ĉiam ekkoni la temon kaj la solvotan problemon, regi ĝin, ĝis certa punkto, ĝis la amplekso, ke la estonta evoluota sistemo kovras ĝin. Tial, la analizisto devas havi altan kapablon kompreni problemojn el tre diversaj areoj aŭ labordisciplinoj (kiuj ne estas specife liaj/ŝiaj); ekzemple, se la evoluota sistemo estos administri informojn de asekuristo kaj ĝiaj foraj branĉoj, la analizisto devas kompreni kiel ĝi funkcias kaj administras siajn informojn, de tre malaltaj niveloj kaj eĉ atingante administradnivelojn. Konsiderante la grandan diversecon de kampoj kovrendaj, analizistoj estas kutime helpataj de specialistoj, tio estas, homoj kiuj profunde konas la areon por kiu la programaro estos evoluigita; evidente ununura homo (la analizisto) ne povas kovri tian vastan nombron da scifakoj. En grandaj kompanioj pri evoluiga produkto de programaro, kutimas havi analizistojn specialigitajn pri certaj laborareoj.

Male, ne estas la problemo de la kliento, tio estas, ke li ne devas scii ion pri programaro, aŭ pri dezajnoj, aŭ pri aliaj rilataj aferoj; oni devas limigi nur al provizo de celoj, datumoj kaj informoj (ĉu propraj aŭ el propraj registroj, ekipaĵoj, dungitoj, ktp.) al la analizisto, kaj gvidataj de li, tiel ke, en la unua okazo, oni difinas la "Universon de Diskurso", kaj per plua laboro oni povis prepari la taŭgan ERS-dokumenton.

La premo, kiun suferas komputikaj sistemprogramistoj por kompreni kaj savi la bezonojn de klientoj/uzantoj, estas konata. Ju pli kompleksa estas la problema kunteksto, des pli malfacilas atingi ĝin, foje devigante programistojn iĝi preskaŭ spertuloj en la domajnoj, kiujn ili analizas.

Kiam tio ne okazas, estas tre verŝajne, ke estos generita aro da eraraj aŭ nekompletaj postuloj kaj do programaro kun alta grado de malaprobo de klientoj/uzantoj kaj tre alta kosto de reinĝenierado kaj prizorgado. Ĉio, kio ne estas detektita aŭ miskomprenita en la komenca etapo, kaŭzos fortan negativan efikon al la postuloj, disvastigante ĉi tiun degradan fluon tra la tuta evoluprocezo kaj pliigante ĝian damaĝon ju pli poste ĝi estas detektita .

Procezoj, modelado kaj formoj de specifigo de postuloj

Ĉar la kapto, eligo kaj specifo de postuloj estas decida parto de la programara evoluprocezo, ĉar la atingo de la planitaj finaj celoj dependas de ĉi tiu etapo, modeloj kaj diversaj labormetodaroj estis elpensitaj por ĉi tiuj celoj. Ekzistas ankaŭ programaraj iloj kiuj subtenas la relativajn taskojn faritajn de la postulinĝeniero.

La normigo IEEE 830-1998 havigas regularon de la «Praktikoj rekomenditaj por la specifigo de postuloj de programaro».

Ju pli la postuloj estas akiritaj, des pli ili estas normale analizitaj; la rezulto de ĉi tiu analizo, kun aŭ sen la kliento, estas reflektita en dokumento, konata kiel SRS aŭ Software Requirements Specification, kies strukturo povas esti difinita per pluraj normoj, kiel ekzemple CMMI (Capability Maturity Model Integration).

Unua paŝo por efektivigi la informkolekton estas la sciaro kaj preciza difino de tio, kio estas konata kiel la "Universo de Diskurso" de la problemo, kiu estas difinita kaj komprenita jene:

Universo de Diskurso (UdeD): estas la ĝenerala kunteksto en kiu la programaro devas esti evoluigita kaj devas funkcii. La UdeD inkluzivas ĉiujn fontojn de informoj kaj ĉiujn homojn rilatajn al la programaro. Ĉi tiuj homoj ankaŭ estas konataj kiel aktoroj de tiu universo. La UdeD estas la realaĵo cirkonstancita de la aro de celoj difinitaj de tiuj, kiuj petis la programaron. De la eltiro kaj analizo de informoj en ĝia amplekso, ĉiuj necesaj specifoj kaj specoj de postuloj por la estonta programaro estas akirita.

La celo de postul-inĝenieristiko (PI) estas sistemigi la postuldifinan procezon, permesante la kapton de la problemo, ties modeligon kaj analizon, generante engaĝiĝon inter postul-inĝenieroj kaj klientoj/uzantoj, ĉar ambaŭ partoprenas la generacion kaj difinon de sistemaj postuloj. PI disponigas aron de metodoj, teknikoj kaj iloj kiuj helpas postul-inĝenierojn (analizistoj) akiri postulojn kiuj estas kiel eble plej sekuraj, veraj, kompletaj kaj ĝustatempaj, esence permesante:

• Kompreni la problemon
• Faciligi la plenumon de la necesoj de la klient/uzanto
• Validigi la sistemon ĉe la klient/uzanto
• Garantiigi la specifigojn de postuloj

Kvankam ekzistas diversaj manieroj, modeloj kaj metodaroj por ellogi, difini kaj dokumenti postulojn, oni ne povas diri, ke iu el ili estas pli bona aŭ pli malbona ol la alia; ili kutime havas multon komunan, kaj ili ĉiuj plenumas la saman celon. Tamen, kio povas esti dirita sendube, estas ke estas esence uzi kelkajn el ili por dokumenti la specifojn de la estonta programaro. Ekzemple, ekzistas argentina esplorgrupo, kiu de pluraj jaroj proponas kaj studas la uzon de la ELL (Etendita Lingva Leksikono) kaj Scenaroj kiel metodiko, kie unu el la multaj referencoj kaj bibliografio pri ĝi estas prezentita. Alia, pli ortodoksa, maniero kapti kaj dokumenti postulojn oni povas detale aringi, ekzemple, en la laboro de la Universitato de Sevilo pri "Metodologio por la Analizo de Postuloj de Programaro-Sistemoj".

Ebla ĝenerala kaj ordigita listo de rekomenditaj taskoj por akiri la difinon de tio, kio devas esti farita, la produktoj akireblaj kaj la teknikoj uzeblaj dum la postula agado, en la fazo de Programar-Kondiĉoj estas jena:

1. Akiri informon pri la domajno de la problemo kaj de la fakta sistemo (UdeD).
2. Prepari kaj realigi la kunsidojn por la kapto kaj negocado.
3. Identigi/revizii la celojn de la uzanto.
4. Identigi/revizii la celojn de la sistemo.
5. Identigi/revizii la informopostulojn.
6. Identigi/revizii la funkcipostulojn.
7. Identigi/revizii la nefunkciajn postulojn.
8. Prioritatigi celojn kaj postulojn.

Kelkaj bazaj principoj atentindaj estas jenaj:

• Prezenti kaj plene komprenu la probleminforman domajnon.
• Ĝuste difini la funkciojn, kiujn la programaro devas plenumi.
• Reprezenti la konduton de la programaro kiel sekvo de eksteraj, apartaj, eĉ neatenditaj okazaĵoj.
• Rekoni nekompletajn, ambiguajn aŭ kontraŭdirajn postulojn.
• Klare dividi modelojn, kiuj reprezentas informojn, funkciojn kaj konduton kaj nefunkciajn trajtojn.

Klasigo kaj identigo de postuloj

Oni povas identigi du manierojn de postuloj:

• Postuloj de uzanto: La postuloj de uzanto estas frazoj en natura lingvaĵo kun diagramoj kun la servoj kiujn la sistemo devas havigi, same kiel la restriktoj laŭ kiu oni devas operaciumi.
• Postuloj de sistemo: La postuloj de sistemo determinas la servojn de la sistemo, sed montrante la restriktojn detale. Ili utilas kiel kontrakto.

Tio estas, ambaŭ estas la samo, sed kun diferenca nivelo de detalo.

Ekzemplo de postulo de uzanto: la sistemo devas fari pruntojn. Ekzemplo de postulo de sistemo: prunto funkcio: plenumo de partnera kodo, kodo de ekzemplaro; eliro: dato de redono; ktp.

Oni klasigas en tri klasojn la tipojn de postuloj de sistemo:

• Funkciaj postuloj, estas tiuj kiuj priskribas jenon:

• La servojn kiuj havigas la sistemon (funkcioj).
• La reago de la sistemo fronte al difinitaj aferoj.
• La konduto de la sistemo en apartaj situacioj.

• Nefunkciaj postuloj, estas tiuj restriktoj de la servoj aŭ de la funkcioj kiujn havigas la sistemo (ekz. tempokvotoj, procezo de disvolvigo, rezulto, ktp.)

Ekzemplo 1a. La centra biblioteko devas esti kapabla zorgi samtempe ĉiujn bibliotekojn de la universitato

Ekzemplo 2a. La reagotempo al malproksima konsulto ne devas esti supera al 1/2 s

Siaflanke, estas tri tipoj de postuloj nefunkciaj:

• Postuloj de la produkto. Ili specifigas la konduton de la produkto (Ekz. servoj, memoro, erarproporcio ktp.)
• Organizaj postuloj. Ili deriviĝas de la politikoj kaj proceduroj de la organizaĵoj de klientoj kaj disvolvigistoj (ekz. proceznormigoj, lingvaĵoj de programado ktp.)
• Eksteraj postuloj. Ili deriviĝas de faktoroj eksteraj kaj al la sistemo kaj al la procezo de disvolvigo (ekz. juraj, etikaj postuloj, ktp.)

• Postuloj de la domajno.

La postuloj de la domajno deriviĝas de la domajno de la aplikaĵo kaj montras karakterojn de tiu domajno.

Ili povas esti funkciaj aŭ nefunkciaj.

Ekz. la sistemo de biblioteko de la universitato devas esti kapabla eksporti datenojjn pere de la Lingvaĵo de Interkomunikado de Bibliotekoj de la lando. Ekz. la sistemo de biblioteko ne povos aliri al bibliotekoj kiuj havas cenzuritan materialon.

Dezajno de la sistemo

En programarinĝenierado, la dezajno estas fazo de vivciklo de programaro. Ĝi baziĝas sur la specifigo de postuloj produktita de la analizo de la postuloj (fazo de analizo), kaj la dezajno difinas kiel tiuj postuloj plenumiĝos, nome la strukturo kiun devas havi la programarsistemo por atingi realigon. La dezajno plue estas fazo aparta de la programado aŭ kodigo, el kiuj tiu lasta korespondas al la traduko en difinita programlingvo de la premisoj adoptitaj en la dezajno.

La distingoj inter la agadoj menciitaj ĝis nun ne estas ĉiam klaraj kiel deziriĝus en klasikaj programarinĝenieraj teorioj. Dezajno, aparte, povas priskribi la internan funkciadon de sistemo sur malsamaj niveloj de detalo, ĉiu el kiuj estas metita ien inter analizo kaj kodigo.

"Arkitektura dezajno" estas kutime komprenita kiel "tre altnivela" dezajno, kiu nur difinas la strukturon de la sistemo laŭ la programarmoduloj el kiuj ĝi estas kunmetita kaj la makroskopajn rilatojn inter ili. Formuloj kiel "kliento-servilo" aŭ "tri niveloj" apartenas al ĉi tiu nivelo de dezajno, aŭ, pli ĝenerale, decidoj pri la uzado de la speciala aparatara arkitekturo uzata, la operaciumo, DBMS, ret-protokoloj, ktp.

Meza nivelo de detalo povas difini la malkomponiĝon de la sistemo en modulojn, sed ĉi-foje kun pli-malpli eksplicita referenco al la malkomponiga reĝimo havigita de la aparta programlingvo per kiu la evoluo estas efektivigota, ekzemple, en dezajno farita per objektoteknologio, la projekto povus priskribi la sistemon laŭ klasoj kaj iliaj interrilatoj.

La detala dezajno, finfine, estas priskribo de la sistemo tre proksima al kodigo (ekzemple, priskribante ne nur la klasojn abstrakte, sed ankaŭ iliajn atributojn kaj la metodojn kun iliaj specoj).

Pro la "netuŝebla" naturo de la programaro, kaj depende de la iloj uzitaj en la procezo, la limo inter dezajno kaj kodigo ankaŭ povas esti praktike maleble identigebla. Ekzemple, kelkaj CASE-iloj kapablas generi kodon de UML-diagramoj, kiuj grafike priskribas la strukturon de programarsistemo.

Kodigo de la programaro

Dum ĉi tiu etapo, estas efektivigitaj la taskoj kiuj estas komune konataj kiel programado; kiu esence konsistas en alporto al la fontkodo, en la elektita programlingvo, de ĉio desegnita en la antaŭa fazo. Ĉi tiun taskon faras la programisto, tute sekvante la gvidliniojn truditajn en la dezajno kaj ĉiam konsiderante la funkciajn kaj nefunkciajn postulojn (ERS) specifitajn en la unua etapo.

Oftas pensi ke la programada aŭ kodiga stadioj (kelkaj nomas ĝin efektivigo) estas tiu kiu prenas la plej grandan parton de la programar-disvolva laboro; tamen, ĉi tio povas esti relativa (kaj ĝenerale aplikebla al malgrandaj sistemoj) ĉar la antaŭaj stadioj estas decidaj, kritikaj kaj povas daŭri multe pli longe. Taksoj estas kutime faritaj de 30% de la tuta tempo konsumita en programado, sed ĉi tiu kvanto ne estas memkonsista ĉar ĝi dependas plejparte de la karakterizaĵoj de la sistemo, ĝia kritikeco kaj la elektita programlingvo. Ju pli malalta estas la nivelo de la lingvo, des pli granda estos la programada tempo bezonata, do ekzemple necesus pli da tempo por kodi algoritmon en asembla lingvo ol la sama programita en C-lingvo.

Dum la aplikaĵo, sistemo, aŭ programaro ĝenerale estas programata, oni efektivigas ankaŭ sencimigajn taskojn, tio estas la tasko liberigi la kodon de eraroj troveblaj en ĉi tiu fazo (semantikaj, sintaksaj kaj logikaj). Estas ia interkovro kun la sekva fazo, ĉar por sencimigi la logikon necesas fari unutestojn, kutime kun testaj datumoj; kompreneble, ne ĉiuj eraroj troviĝos nur en la programada etapo, estos aliaj, kiuj estos trovataj dum postaj etapoj. La apero de iu funkcia eraro (malbona respondo al postuloj) pli aŭ malpli frue povas konduki al reveno al la dezajnofazo antaŭ daŭrigi kodigon.

Dum la programada fazo, la kodo povas adopti diversajn statojn, depende de la maniero kiel ĝi funkcias kaj la lingvo elektita, nome:

• Fontkodo: estas skribita rekte de programistoj en tekstredaktiloj, kiu generas la programon. Ĝi enhavas la aron da instrukcioj koditaj en iu altnivela lingvo. Ĝi povas esti distribuita en pakaĵoj, proceduroj, fontbibliotekoj ktp.

• Objektokodo: estas la duuma aŭ meza kodo rezultiĝanta el prilaborado de la fontkodo per kompililo aŭ tradukilo. Ĝi konsistas el kompleta, unufoja traduko de ĉi-lasta. La objektokodo ne estas komprenebla de homoj (normale ĝi estas duuma formato) sed ĝi ankaŭ ne estas rekte plenumebla de la komputilo. Ĝi estas meza reprezentado inter la fontkodo kaj la plenumebla kodo, por la celoj de fina ligo kun bibliotekrutinoj kaj inter proceduroj aŭ por uzo kun malgranda meza interpretisto [por malsamaj ekzemploj oni vidu EUPHORIA (meza interpretisto), FORTRAN (pura kompililo) MSIL (Microsoft Intermediate Language) (interpretisto) kaj BASIC (pura interpretisto, meza interpretisto, meza kompililo aŭ pura kompililo, dependas de la uzata versio)].
  • La objektokodo ne ekzistas, se la programisto laboras per lingvo kiel pura interpretisto, ĉi-kaze la sama interpretisto respondecas pri tradukado kaj plenumado de la fontkodo, laŭ linio post linio (laŭ la fluo de la programo), en la rultempo. En ĉi tiu kazo, la plenumebla kododosiero ankaŭ ne ekzistas. Malavantaĝo de ĉi tiu kategorio estas ke la plenumado de la programo aŭ sistemo estas iom pli malrapida ol se ĝi estus farita per meza interpretisto, kaj multe pli malrapida ol se la plenumeblaj koddosieroj ekzistas. Tio estas, ĝi ne favoras rezulton en plenumrapideco. Sed granda avantaĝo de la pura interpretista reĝimo estas, ke tiu ĉi labormaniero multe faciligas la taskon sencimigi la fontkodon (kompare kun la alternativo fari ĝin per pura kompililo). Ofte oni uzas miksan labormanieron (se la elektita programlingvo permesas tion), tio estas, komence funkciante kiel pura interpretisto, kaj post kiam la fontkodo estas sencimigita (liberigita de eraroj), kompililo de la sama lingvo estas uzata por akiri la kompletan plenumeblan kodon, kiu plirapidigas sencimigon kaj optimumigas plenumrapidecon.
• Plenumebla kodo: estas la binara kodo rezultanta el ligado de unu aŭ pluraj fragmentoj de objektokodo kun la necesaj rutinoj kaj bibliotekoj. Ĝi konsistigas unu aŭ plurajn binarajn dosierojn kun formato tia, ke la operaciumo kapablas ŝarĝi ĝin en RAM-memoron (eventuale ankaŭ parto de virtuala memoro), kaj proceduri al ĝia rekta plenumado. Tial, oni diras, ke la plenumebla kodo estas rekte "komprenebla de la komputilo". La plenumebla kodo, ankaŭ konata kiel maŝinkodo, ne ekzistas se ĝi estas programita en reĝimo de "pura interpretisto".

Provoj (unuigaj kaj integrigaj)

Inter la diversaj provoj faritaj sur la programaro, oni povas ĉefe distingi jenajn:

• Unuigaj provoj: konsistas el testado aŭ provado de malgrandaj pecoj de programaro; je la nivelo de sekcioj, proceduroj, funkcioj kaj moduloj; tiuj kiuj havas specifajn funkciojn. Ĉi tiuj provoj estas uzataj por certigi la ĝustan funkciadon de sekcioj de kodo, multe pli malgrandaj ol la tutaĵo, kaj kiuj havas specifajn funkciojn kun ia grado de sendependeco.
• Integrigaj provoj: oni faras ilin post kiam la unuigaj provoj estis sukcese finitaj; ĉi tiuj celas certigi, ke la tuta sistemo, inkluzive de la subsistemoj, kiuj konsistigas la grandajn individuajn programojn, funkcias ĝuste dum funkciado kaj interfunkciado kune kaj are.

Kutime oni faras la provojn per tiel nomitaj testdatenoj, kio estas elektita aro de tipaj datenoj al kiuj la sistemo, moduloj aŭ kodblokoj povas esti submetitaj. Oni elektas ankaŭ jenon: datumoj, kiuj kondukas la programaron limigi kondiĉojn por testi ĝian toleremon kaj fortikecon; datumoj utilaj por agad-mezuradoj; datumoj, kiuj kaŭzas nekutimajn aŭ apartajn kondiĉojn, al kiuj la programaro kutime ne estos submetita sed ili povas okazi; ktp. La "testdatenoj" ne estas nepre fikciaj aŭ "kreitaj", sed ili estas tipe datumoj kun malalta probableco de okazo.

Ĝenerale, ekzistas fina kaj kompleta prova fazo de la programaro, nomita Beta Provilo, dum kiu la sistemo instalita sub normalaj funkciaj kaj laborkondiĉoj estas ĝisfunde provita por trovi erarojn, malstabilecojn, malĝustajn respondojn ktp., kiuj trapasis la antaŭajn kontrolojn. Tiuj estas normale efektivigitaj fare de kvalifikita personaro dungita aŭ specife asignita al ĝi. Ajnaj eraroj trovitaj estas transdonitaj al la programistoj por senerarigado. En la kazo de "laŭpeta" disvolva programaro, la finuzanto (kliento) estas tiu, kiu faras la Betan Provadon, havante provperiodon interkonsentitan kun la programisto.

Instalado kaj ekproduktado

Instalado de programaro estas la procezo per kiu la evoluintaj programoj estas taŭge translokigitaj al la cela komputilo, pravigitaj, kaj, finfine, agordita; ĉio ĉi kun la celo esti uzata de la fina uzanto. Ĝi konsistigas la finan etapon en la fakta evoluo de la programaro. Post ĉi tio, la produkto eniros la fazon de operaciumado kaj produktado, por kiu ĝi estis desegnita.

La instalado, depende de la evoluinta sistemo, povas konsisti el simpla kopio al la celloka malmola disko (nuntempe maloftaj kazoj); aŭ, pli ofte, kun unu el meza komplekseco en kiu la malsamaj komponentdosieroj de la programaro (ekzekuteblaj, bibliotekoj, propraj datumoj, ktp.) estas malkunpremitaj kaj kopiitaj al specifaj antaŭestablitaj lokoj sur la disko; oni kreas eĉ ligilojn kun aliaj produktoj, krom la operaciumon mem. Ĉi tiu lasta kazo estas kutime sufiĉe aŭtomata procezo, kiu estas kreita kaj gvidata per specifaj programaraj iloj (pakado kaj distribuado, instaliloj).

En pli kompleksaj produktoj, la dua alternativo estas tiu uzata, sed ĝi estas efektivigita aŭ gvidata de specialistoj; eĉ instalado sur pluraj komputiloj povas esti bezonata (distribuita instalado).

Ankaŭ, en programaro de meza kaj alta komplekseco, agordo kaj prova procezo estas normale postulata, per kiu taŭgaj operaciaj parametroj estas asignitaj kaj la funkcia operaco de la produkto estas provita.

En amasvendataj produktoj, kompletaj instalaĵoj, se ili estas relative simplaj, estas kutime efektivigitaj de la finaj uzantoj mem (kiel ekzemple operaciumoj, oficejaj pakaĵoj, utilecoj ktp.) per siaj propraj gviditaj instaliloj; eĉ la agordo estas kutime aŭtomata. En produktoj kun specifa aŭ "kutima" dezajno, instalado estas normale limigita al specialistoj implikitaj en la evoluo de la koncerna "programaro".

Post kiam la programaro instaliĝis sukcese, ĝi moviĝas al la produktadfazo (funkciebleco), dum kiu ĝi plenumas la funkciojn por kiuj ĝi estis evoluigita, tio estas, ĝi estas finfine uzata de la fina uzanto (aŭ uzantoj), produktante la esperitaj rezultoj.

Bontenado

Bontenado de programaro estas la procezo de kontrolado, plibonigo kaj optimumigado de la programaro jam evoluigita kaj instalita, kiu ankaŭ inkluzivas sencimigon de eraroj kaj difektoj, kiuj eble likis de la kontrola provado kaj betaprova fazo. Ĉi tiu fazo estas la lasta (antaŭ ripetado, depende de la modelo uzata) kiu estas aplikata al la programar-disvolva vivociklo. La bontena fazo estas kio venas post kiam la programaro estas funkcianta kaj produktanta.

Kia estos la bontena fazo dependos de bona dezajno kaj dokumentado de la evoluo, kaj laŭ tempo kaj laŭ mona kosto. Modifoj faritaj al la programaro, kiu estis evoluigita kun nedeca aŭ malbona dokumentado kaj malbona dezajno povas esti same multekostaj aŭ eĉ pli multekostaj ol evoluigado de la programaro de nulo. Tial, gravas ĝuste respekti ĉiujn taskojn de la evolufazoj kaj konservi taŭgan kaj kompletan dokumentadon.

La daŭro de la bontenada periodo estas normale la plej longa en la tuta vivociklo. Ĉi tiu fazo ankaŭ implikas ĝisdatigojn kaj evoluojn de la programaro; ĝi ne nepre implicas, ke la sistemo havis erarojn. Unu aŭ pluraj ŝanĝoj en la programaro, ekzemple adapta aŭ evolua, povas eĉ konduki al revizio kaj adaptado de parto de la unuaj fazoj de la komenca evoluo, ŝanĝante ĉiujn aliajn; depende de kiom profundaj estas la ŝanĝoj. La komuna kaskadmodelo estas precipe multekosta en bntenado, ĉar ĝia rigideco implicas ke ĉiu ŝanĝo kaŭzas revenon al la komenca fazo kaj fortajn ŝanĝojn en la aliaj fazoj de la vivociklo.

Dum la bontenada periodo, ofte aperas novaj revizioj kaj versioj de la produkto, kiuj liberigas ĝin pli rafinita, kun pli granda kaj pli bona funkcieco, pli bona rezulto, ktp. Estas pluraj aspektoj, kiuj povas esti ŝanĝitaj por kaŭzi dezirindajn, evoluajn ŝanĝojn, adaptojn aŭ etendaĵojn kaj plibonigojn.

Esence estas la jenaj specoj de ŝanĝoj:

• Perfektigaj: Tiuj, kiuj kondukas al plibonigo de la interna kvalito de la programaro en ajna aspekto: restrukturado de la kodo, pli klara difino de la sistemo kaj ĝia dokumentado; optimumigo de rezulto kaj efikeco.
• Evoluigaj: Aldonoj, modifoj, eĉ forigoj, necesaj en la programaro por kovri ĝian vastiĝon aŭ ŝanĝon, laŭ la bezonoj de la uzanto.
• Adaptigaj: Modifoj kiuj influas la mediojn en kiuj la sistemo funkcias, kiel ekzemple: Aparataj agordaj ŝanĝoj (pro ĝisdatigo aŭ plibonigo de elektronikaj komponantoj), ŝanĝoj en la baza programaro, en datumbazoj, en komunikadoj, ktp.
• Korektigaj: Ŝanĝoj necesaj por korekti erarojn de ajna tipo en la evoluinta programaro.

Specoj de programaro

Estas malfacile klasigi la diversajn specojn de programaro, sed eblas fari tion jene:

Sistema programaro

Sistema programaro regas la aparataron.

Tekstoredaktilo Esperantilo.

Tekstredaktilo

Operaciumo

Firmvaro

Peliloj

Helpiloj

...

Ellabora programaro

Ellabora programaro helpas al programistoj skribi programojn kaj uzi malsamajn programlingvojn.

Tekstredaktilo Interpretilo Erarserĉilo Bindilo Kompilumilo ...

Uzanta (labor)programaro

Uzanto-laborprogramoj ebligas al uzantoj fari unu aŭ plurajn konkretajn laborojn, en ia ajn kampo de aktiveco kiun eblas aŭtomatigi aŭ apogi per komputiko.

Bildumilo Datumbazo Dokumentoredaktilo Retpoŝtilo Sterntabelo Tradukilo TTT-legilo Videoludo ...

Libera programaro

Pli detalaj informoj troveblas en artikolo Libera programaro.

Libera programaro estas programaro kiu estas libere uzebla, distribuebla kaj ŝanĝebla laŭ la sekvaj specoj:

• La libereco por uzi la programon, por iu ajn celo (libereco 0).
• La libereco por studi kiel la programo funkcias, kaj ŝanĝi ĝin por viaj bezonoj (libereco 1). Dispono pri la fontkodo de la programo estas antaŭkondiĉo por tio ĉi.
• La libereco por disdoni kopiojn, do vi povas helpi vian najbaron (libereco 2).
• La libereco por plibonigi la programon, kaj disdoni viajn plibonigojn al la publiko, por helpi ĉiujn (libereco 3). Atingo al la fontkodo estas antaŭkondiĉo por tio ĉi.

Liberan programaron subtenas kaj stimulas la libera programaro-movado. La iniciatinto de tiu movado estas Richard Stallman, kiu fondis organizon Fondaĵo por Libera Programaro (Free Software Foundation) por antaŭenigi ĝin. Ili promesas al ni ke Libera Programaro konservas la kvar suprajn specojn de libereco, por la uzantoj de la programaro.

Google Chrome estas ekzemplaĵo de mallibera programo, male al Mozilla Firefox

Mallibera programaro

Mallibera programaro, ankaŭ nomata "ne-libera", "proprieta" aŭ "fermit-fonta" estas programaro kiu ne estas sub la kriterioj por libera programaro. Senpaga programaro (angle freeware) estas speco de mallibera programaro, kiu disponeblas por uzado senpage. Malgraŭ tio, oni ne rajtas modifi, redistribui aŭ studi (inversa inĝenierarto) ĝin sen la permeso de la kreinto.

• Mikroprogramaro (ankaŭ nomata integrita programaro aŭ firmprogramo aŭ firmvaro, el la angla firmware) estas speco de programaro kiu ebligas kontrolon, monitoradon kaj datummanipuladon de eletronikaj produktoj kaj sistemoj.
• Viruso estas programaro, kies celo estas mem-kopiiĝi en aliajn programojn aŭ al aliajn komputilojn, ofte ne informante la uzanton kiu ĝin lanĉas, kaj fojfoje difektante aŭ kopiante dosierojn.

Neologismo "softvaro"

Kelkaj esperantistoj uzas la vorton softvaro en Esperanto ĉar la angla vorto software estas uzata kiel neologismo en multaj lingvoj tutmonde.

Laŭ ili tiu vorto estas unuradika (softvar + o ), do ili opinias ke nova radiko aldoniĝis al Esperanto laŭ la 15-a regulo de la Fundamento. Aliaj interpretas ĝin kiel kunmetaĵon de la radikoj soft kaj var, sed tio ne estas tre logika, ĉar en Esperanto softa signifas milde mallaŭta, do neniel rilatas al komputikaĵo.

La malvorto de softvaro estas la neologismo hardvaro, nome aparataro. Kiel malvorto de hardvaro, softvaro estas uzata por pli vasta signifo: ekz. datumoj ludataj per aparataro kiel datumoj en registradaj medioj aŭ elektra signo.

La plej ofta esprimo en Esperanto por tiu koncepto estas la kunmetaĵo programaro, kiu bone kaptas la intencitan signifon sen neceso de nova radiko.

Evolua karaktero de la programaro

La programaro estas la produkto generita de la procezo de disvolvigo, laŭ la inĝenierado de programaro. Tiu produkto estas esence alte evolua kaj evoluema dum sia vivociklo: ĝenerale, ĝi evoluas generante versiojn pli kaj pli kompletajn, kompleksajn, plibonigitajn laŭ iu konsidero, plo taŭgajn al novaj platformoj (ĉu de aparataro ĉu de operaciaj sistemoj), ktp.

Kiam sistemo ĉesos evolui, ĝi fine atingos sian vivociklon, malnoviĝos kaj neeviteble, baldaŭ aŭ malfrue, estos anstataŭigita per nova produkto.

Programaro evoluas simple ĉar ĝi devas adaptiĝi al ŝanĝoj en la medio, ĉu funkciaj (uzantpostuloj), funkciantaj, platformaj aŭ de aparatara arkitekturo.

La dinamiko de evoluo de la programaro estas la studo de la ŝanĝoj de la sistemo. La plej grava kontribuo en tiu areo estis realigita de Meir M. Lehman]] kaj Belady, ekde la 1970-aj kaj 1980-aj jaroj. Ilia laboro pluis en la 1990-aj jaroj, kiam Lehman kaj aliaj esploristoj elstaris en la renutrado de la procezoj de evoluo . Ekde tiuj studoj oni proponis aron de reguloj (konataj kiel Leĝoj de Lehman) rilate al la ŝanĝoj okazintaj en la sistemoj. Tiuj leĝoj (reale temas pri hipotezoj) estas nevarieblaj kaj amplekse aplikebloj.

Lehman kaj Belady analizis la kreskon kaj evoluon de pluraj grandaj programaraj sistemoj; finfine derivante, laŭ ĝiaj mezuradoj, al la jenaj ok leĝoj:

1. Kontinua ŝanĝo: Programaro uzata en reala medio nepre devas ŝanĝiĝi aŭ male iĝos iom post iom malpli utila en tiu medio.
2. Kreskanta komplekseco: Ju pli evoluanta programo ŝanĝiĝas, des pli ĝia strukturo tendencas iĝi ĉiam pli kompleksa. Kromaj rimedoj devas esti dediĉitaj al konservado kaj simpligo de la strukturo.
3. Plilongigita evoluo de la programaro: La evoluo de programoj estas memreguliga procezo. Sistemaj atributoj kiel grandeco, tempo inter eldonoj, kaj la nombro da dokumentitaj eraroj estas proksimume senvariaj por ĉiu eldono de la sistemo.
4. Organiza stabileco: Dum la vivodaŭro de programo, ĝia evolurapideco estas proksimume konstanta kaj sendependa de la rimedoj dediĉitaj al la sistema evoluo.
5. Konservado de la familiareco: Dum la vivodaŭro de sistemo, la pliiga ŝanĝo en ĉiu liveraĵo estas proksimume konstanta.
6. Kontinua kresko: La funkcieco havigita de la sistemoj devas kontinue kreski por konservi la kontentigon en la uzantoj.
7. Malpliigo de la kvalito: La kvalito de la sistemoj de la programaro ekmalpliiĝos se tiuj sistemoj ne adaptiĝas al la ŝanĝoj de sia funkcianta medio.
8. Renutrado de la sistemo: La procezoj de evoluo asimilas pluragentajn kaj plurbuklajn renutrajn sistemojn kaj tiuj devas esti traktitaj kiel renutraj sistemoj por atingi signifan plibonigon de la produkto.

Vidu ankaŭ

• Apleto (apo)
• Komputila programo
• Libera programaro
• Programara inĝenierarto
• Esperantigitaj programoj
• Vivciklo de programareldono
• Biervaro
• Mallibera programaro (en: proprietary software)

Eksteraj ligiloj

• germane Historio de programarkreado
• angle Deveno de programaro
• angle Deveno de la vorto "software"

• En tiu ĉi artikolo estas uzita traduko de teksto el la artikolo Software en la itala Vikipedio.
• En tiu ĉi artikolo estas uzita traduko de teksto el la artikolo Software en la hispana Vikipedio.