Programaro

eta|Du programistoj laborantaj ĉe IBM Tipo 704 ĉe la *National Advisory Committee for Aeronautics* (NACA), 1954.
**Programaro** (aŭ **softvaro**) estas aro de logikaj (ne fizikaj) iloj de komputilaj sistemoj, kiuj regas fizikan aparataron por realigado de konkreta laboro. Programaro povas esti, ekzemple, programoj por skribi dosierojn, registri aŭ aŭskulti sondosierojn, esplori interreton, operaciumoj (Unikso, 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 
eta|desktre|230ra|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.

**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:

# Akiri informon pri la domajno de la problemo kaj de la fakta sistemo (UdeD).
# Prepari kaj realigi la kunsidojn por la kapto kaj negocado.
# Identigi/revizii la celojn de la uzanto.
# Identigi/revizii la celojn de la sistemo.
# Identigi/revizii la informopostulojn.
# Identigi/revizii la funkcipostulojn.
# Identigi/revizii la nefunkciajn postulojn.
# 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 datumojn 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. Ĉ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.
[eta|dekstra|300ra|[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 
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.

[eta|100ra|[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 elektronikaj 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:

# 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.
# 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.
# 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.
# Organiza stabileco: Dum la vivodaŭro de programo, ĝia evolurapideco estas proksimume konstanta kaj sendependa de la rimedoj dediĉitaj al la sistema evoluo.
# Konservado de la familiareco: Dum la vivodaŭro de sistemo, la pliiga ŝanĝo en ĉiu liveraĵo estas proksimume konstanta.
# Kontinua kresko: La funkcieco havigita de la sistemoj devas kontinue kreski por konservi la kontentigon en la uzantoj.
# 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.
# 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.

## Referencoj 
## Vidu ankaŭ 
* Apleto (apo)
* Komputila programo
* Libera programaro
* Programara inĝenierarto
* Esperantigitaj programoj
* Vivciklo de programareldono
* Biervaro
* Mallibera programaro (en: *proprietary software*)

## Eksteraj ligiloj 
*  Historio de programarkreado
*  Deveno de programaro
*  Deveno de la vorto "software"

* 
*