# Zhvillimi i softuerit

**Zhvillimi i softuerit** është procesi i projektimit dhe zbatimit të një zgjidhje softuerike për të përmbushur nevojat e një përdoruesi ose grupi përdoruesish. Procesi është më gjithëpërfshirës se programimi, shkrimi i kodit, duke përfshirë faza si konceptimi i qëllimit, vlerësimi i fizibilitetit, analiza e kërkesave, projektimi, testimi dhe lëshimi . Procesi është pjesë e inxhinierisë softuerike e cila përfshin gjithashtu menaxhimin organizativ, menaxhimin e projektit, menaxhimin e konfigurimit dhe aspekte të tjera.

Zhvillimi i softuerit përfshin një gamë të gjerë aftësi dhe specializimesh për punë duke përfshirë programimin, testimin, dokumentacionin, dizajnin grafik, mbështetjen e përdoruesit, marketingun dhe mbledhjen e fondeve.

Zhvillimi i softuerit përdor një sërë mjetesh, duke përfshirë: përpiluesin, mjedisin e integruar të zhvillimit (IDE), kontrollin e versionit, inxhinierinë e softuerit të ndihmuar nga kompjuteri (CASE) dhe përpunuesin e tekstit.

Detajet e procesit të përdorur për një përpjekje zhvillimi mund të ndryshojnë. Procesi mund të ndjekë një standard zyrtar, të dokumentuar, ose mund të personalizohet dhe të shfaqet për përpjekjet e zhvillimit. Procesi mund të jetë sekuencial, ku çdo fazë kryesore (si projektimi, zbatimi dhe testimi) përfundon përpara fillimit të fazës tjetër, por një qasje përsëritëse – ku aspekte të vogla projektohen, zbatohen dhe testohen veçmas – mund të ndihmojë në uljen e rrezikut dhe kostos dhe të rrisë cilësinë.

## Metodologjitë

Skema e rrjedhës së modelit të prototipit evolucionar, një model zhvillimi përsëritës
Secila prej metodologjive të disponueshme është më e përshtatshme për lloje të veçanta projektesh, bazuar në konsiderata të ndryshme teknike, organizative, projektesh dhe ekipore.

* Metodologjia më e thjeshtë është "kodi dhe rregullimi", i përdorur zakonisht nga një programues i vetëm që punon në një projekt të vogël. Pasi shqyrton shkurtimisht qëllimin e programit, programuesi e kodon atë dhe e ekzekuton për të parë nëse funksionon. Kur ato janë bërë, produkti lëshohet. Kjo metodologji është e dobishme për prototipet, por nuk mund të përdoret për programe më të përpunuara.
* Në modelin e ujëvarës nga lart-poshtë, fizibiliteti, analiza, projektimi, zhvillimi, sigurimi i cilësisë dhe zbatimi ndodhin në mënyrë sekuenciale në atë renditje. Ky model kërkon që një hap të përfundojë përpara se të fillojë tjetri, duke shkaktuar vonesa dhe e bën të pamundur rishikimin e hapave të mëparshëm nëse është e nevojshme.
* Me proceset përsëritëse, këta hapa ndërlidhen me njëri-tjetrin për një fleksibilitet të përmirësuar, efikasitet dhe planifikim më realist. Në vend që të përfundoni projektin menjëherë, mund të kaloni shumicën e hapave me një komponent në të njëjtën kohë. Zhvillimi i përsëritur gjithashtu i lejon zhvilluesit t'i japin përparësi veçorive më të rëndësishme, duke mundësuar që ato me prioritet më të ulët të hiqen më vonë nëse është e nevojshme. Agile është një metodë popullore, e destinuar fillimisht për projekte të vogla ose të mesme, që fokusohet në dhënien e zhvilluesve më shumë kontroll mbi veçoritë që ata punojnë për të zvogëluar rrezikun e tejkalimit të kohës ose kostos. Derivatet e agile përfshijnë programimin ekstrem dhe Scrum. Zhvillimi i softuerit me burim të hapur zakonisht përdor metodologji të shkathët me dizajn, kodim dhe testim të njëkohshëm, për shkak të mbështetjes në një rrjet të shpërndarë kontribuesish vullnetarë.
* Përtej shkathtësisë, disa kompani integrojnë operacionet e teknologjisë së informacionit (IT) me zhvillimin e softuerit, i cili quhet DevOps ose DevSecOps duke përfshirë sigurinë kompjuterike. DevOps përfshin zhvillimin e vazhdueshëm, testimin, integrimin e kodit të ri në sistemin e kontrollit të versionit, vendosjen e kodit të ri dhe ndonjëherë dërgimin e kodit te klientët. Qëllimi i këtij integrimi është të ofrojë shërbime IT më shpejt dhe me efikasitet.

Shumë metodologji programimi theksojnë rëndësinë e identifikimit të hershëm të çështjeve të tilla si dobësitë e sigurisë dhe defektet sa më shpejt të jetë e mundur (testimi me zhvendosje majtas) për të ulur koston e gjurmimit dhe rregullimit të tyre.

Në vitin 2009, u vlerësua se 32% e projekteve softuerike ishin dorëzuar në kohë dhe buxhet, dhe me funksionalitetin e plotë. Janë dorëzuar 44% shtesë, por mungonin të paktën një nga këto veçori. Pjesa e mbetur prej 24% u anulua para daljes.

## Hapat

Cikli jetësor i zhvillimit të softuerit i referohet procesit sistematik të zhvillimit të aplikacioneve.

### Fizibiliteti

Burimet e ideve për produktet softuerike janë të shumta. Këto ide mund të vijnë nga kërkimi i tregut duke përfshirë demografinë e klientëve të rinj potencialë, klientët ekzistues, perspektivat e shitjeve që refuzuan produktin, staf të tjerë të brendshëm të zhvillimit të softuerit ose një palë të tretë krijuese. Idetë për produktet softuerike zakonisht vlerësohen fillimisht nga personeli i marketingut për fizibilitetin ekonomik, përshtatjen me kanalet ekzistuese të shpërndarjes, efektet e mundshme në linjat ekzistuese të produkteve, veçoritë e kërkuara dhe përshtaten me objektivat e marketingut të kompanisë. Në fazën e vlerësimit të marketingut, vlerësohen supozimet e kostos dhe kohës. Analiza e fizibilitetit vlerëson kthimin e investimit të projektit, koston e zhvillimit të tij dhe kornizën kohore. Bazuar në këtë analizë, kompania mund të marrë një vendim biznesi për të investuar në zhvillim të mëtejshëm. Pasi vendos të zhvillojë softuerin, kompania është e fokusuar në ofrimin e produktit me ose nën koston dhe kohën e parashikuar, dhe me një standard të lartë cilësie (dmth. mungesa e gabimeve) dhe funksionalitetin e dëshiruar. Megjithatë, shumica e projekteve softuerike funksionojnë me vonesë dhe ndonjëherë bëhen kompromise në veçori ose cilësi për të përmbushur një afat.

### Analiza

Analiza e softuerit fillon me një analizë të kërkesave për të kapur nevojat e biznesit të softuerit. Sfidat për identifikimin e nevojave janë se përdoruesit aktualë ose potencialë mund të kenë nevoja të ndryshme dhe të papajtueshme, mund të mos i kuptojnë nevojat e tyre dhe të ndryshojnë nevojat e tyre gjatë procesit të zhvillimit të softuerit. Në fund të fundit, rezultati i analizës është një specifikim i detajuar për produktin nga i cili mund të punojnë zhvilluesit. Analistët e softuerit shpesh e zbërthejnë projektin në objekte më të vogla, komponentë që mund të ripërdoren për rritjen e efektivitetit të kostos, efikasitetit dhe besueshmërisë. Zbërthimi i projektit mund të mundësojë një zbatim me shumë fije që funksionon dukshëm më shpejt në kompjuterët me shumë procesorë.

Gjatë fazave të analizës dhe projektimit të zhvillimit të softuerit, analiza e strukturuar shpesh përdoret për të zbërthyer kërkesat e klientit në pjesë që mund të zbatohen nga programuesit e softuerit. Logjika themelore e programit mund të përfaqësohet në diagramet e rrjedhës së të dhënave, fjalorët e të dhënave, pseudokodin, diagramet e tranzicionit të gjendjes dhe/ose diagramet e marrëdhënieve të entitetit. Nëse projekti përfshin një pjesë të softuerit të vjetër që nuk është modeluar, ky softuer mund të modelohet për të ndihmuar që të sigurohet se është inkorporuar saktë me softuerin më të ri.

### Dizajn

Dizajni përfshin zgjedhje në lidhje me zbatimin e softuerit, të tilla si gjuhët e programimit dhe softuerët e bazës së të dhënave për t'u përdorur, ose se si do të organizohen komunikimet e harduerit dhe rrjetit. Dizajni mund të jetë përsëritës me përdoruesit e konsultuar për nevojat e tyre në një proces prove dhe gabimi. Dizajni shpesh përfshin njerëz ekspertë në aspekte të tilla si dizajni i bazës së të dhënave, arkitektura e ekranit dhe performanca e serverëve dhe pajisjeve të tjera. Dizajnerët shpesh përpiqen të gjejnë modele në funksionalitetin e softuerit për të shkëputur module të veçanta që mund të ripërdoren me programim të orientuar nga objekti. Një shembull i kësaj është model-view-kontroller, një ndërfaqe ndërmjet një ndërfaqeje grafike të përdoruesit dhe backend-it.

### Programimi

Tipari qendror i zhvillimit të softuerit është krijimi dhe kuptimi i softuerit që zbaton funksionalitetin e dëshiruar. Ka strategji të ndryshme për të shkruar kodin. Softueri koheziv ka komponentë të ndryshëm që janë të pavarur nga njëri-tjetri. Lidhja është ndërlidhja e komponentëve të ndryshëm të softuerit, e cila shihet si e padëshirueshme sepse rrit vështirësinë e mirëmbajtjes. Shpesh, programuesit e programeve kompjuterike nuk ndjekin praktikat më të mira të industrisë, duke rezultuar në kod që është joefikas, i vështirë për t'u kuptuar ose i mungon dokumentacioni për funksionalitetin e tij. Këto standarde kanë veçanërisht gjasa të prishen në prani të afateve. Si rezultat, testimi, korrigjimi dhe rishikimi i kodit bëhet shumë më i vështirë. Rifaktorimi i kodit, për shembull shtimi i më shumë komenteve në kod, është një zgjidhje për të përmirësuar kuptueshmërinë e kodit.

### Testimi

Testimi është procesi për t'u siguruar që kodi ekzekutohet saktë dhe pa gabime. Korrigjimi kryhet nga secili zhvillues i softuerit në kodin e tij për të konfirmuar që kodi bën atë që synohet. Në veçanti, është thelbësore që softueri të ekzekutohet në të gjitha hyrjet, edhe nëse rezultati është i pasaktë. Rishikimet e kodit nga zhvillues të tjerë shpesh përdoren për të shqyrtuar kodin e ri të shtuar në projekt dhe sipas disa vlerësimeve zvogëlojnë në mënyrë dramatike numrin e gabimeve që vazhdojnë pas përfundimit të testimit. Pasi të jetë dorëzuar kodi, sigurimi i cilësisë - një departament i veçantë i joprogramuesve për shumicën e kompanive të mëdha - teston saktësinë e të gjithë produktit softuer. Testet e pranimit që rrjedhin nga kërkesat origjinale të softuerit janë një mjet popullor për këtë. Testimi i cilësisë gjithashtu përfshin shpesh kontrollin e stresit dhe ngarkesës (nëse softueri është i fortë ndaj niveleve të rënda të hyrjes ose përdorimit), testimin e integrimit (për të siguruar që softueri është i integruar në mënyrë adekuate me softuerët e tjerë) dhe testimin e përputhshmërisë (duke matur performancën e softuerit në të ndryshme sistemet operative ose shfletuesit). Kur testet shkruhen përpara kodit, kjo quhet zhvillim i drejtuar nga testi.

### Prodhimi

Prodhimi është faza në të cilën softueri shpërndahet tek përdoruesi përfundimtar. Gjatë prodhimit, zhvilluesi mund të krijojë burime mbështetëse teknike për përdoruesit ose një proces për rregullimin e gabimeve dhe gabimeve që nuk janë kapur më parë. Mund të ketë gjithashtu një kthim në fazat e mëparshme të zhvillimit nëse nevojat e përdoruesve ndryshojnë ose keqkuptohen.

## Punëtorët

Zhvillimi i softuerit kryhet nga **zhvilluesit e softuerit**, zakonisht duke punuar në një ekip. Komunikimi efikas ndërmjet anëtarëve të ekipit është thelbësor për suksesin. Kjo arrihet më lehtë nëse ekipi është i vogël, i mësuar të punojë së bashku dhe ndodhet pranë njëri-tjetrit. Komunikimet ndihmojnë gjithashtu në identifikimin e problemeve në një gjendje më të hershme zhvillimi dhe shmangin përpjekjet e dyfishta. Shumë projekte zhvillimi shmangin rrezikun e humbjes së njohurive thelbësore të mbajtura nga vetëm një punonjës, duke siguruar që shumë punëtorë janë të njohur me secilin komponent. Zhvillimi i softuerit përfshin profesionistë nga fusha të ndryshme, jo vetëm programues softuerësh, por edhe individë të specializuar në testim, shkrim dokumentacioni, dizajn grafik, mbështetje për përdoruesit, marketing dhe mbledhje fondesh. Megjithëse punëtorët për softuerin e pronarit paguhen, shumica e kontribuesve në softuerin me burim të hapur janë vullnetarë. Ndryshe, ato mund të paguhen nga kompani, modeli i biznesit të të cilave nuk përfshin shitjen e softuerit, por diçka tjetër – të tilla si shërbimet dhe modifikimet në softuerin me burim të hapur.

## Modelet dhe mjetet

### Inxhinieri softuerike me ndihmën e kompjuterit

Inxhinieria e softuerit me ndihmën e kompjuterit (CASE) është mjete për automatizimin e pjesshëm të zhvillimit të softuerit. CASE u mundëson dizajnerëve të skicojnë logjikën e një programi, qoftë ai që do të shkruhet, ose një ekzistues për të ndihmuar në integrimin e tij me kodin e ri ose për ta inxhinieruar atë (për shembull, për të ndryshuar gjuhën e programimit ).

### Dokumentacioni

Dokumentacioni vjen në dy forma që zakonisht mbahen të ndara—që synohet për zhvilluesit e softuerit dhe që vihet në dispozicion të përdoruesit përfundimtar për t'i ndihmuar ata të përdorin softuerin. Shumica e dokumentacionit të zhvilluesit janë në formën e komenteve të kodit për çdo skedar, klasë dhe metodë që mbulon ndërfaqen e programimit të aplikacionit (API) - si mund të aksesohet pjesa e softuerit nga një tjetër - dhe shpesh detaje të zbatimit. Ky dokumentacion është i dobishëm për zhvilluesit e rinj që të kuptojnë projektin kur të fillojnë të punojnë për të. Në zhvillimin e shkathët, dokumentacioni shpesh shkruhet në të njëjtën kohë me kodin. Dokumentacioni i përdoruesit shkruhet më shpesh nga shkrues teknikë .

### Vlerësimi i përpjekjes

Vlerësimi i saktë është thelbësor në fazën e fizibilitetit dhe në dorëzimin e produktit në kohë dhe brenda buxhetit. Procesi i gjenerimit të vlerësimeve shpesh delegohet nga menaxheri i projektit. Për shkak se vlerësimi i përpjekjes lidhet drejtpërdrejt me madhësinë e aplikacionit të plotë, ai ndikohet fuqishëm nga shtimi i veçorive në kërkesa - sa më shumë kërkesa, aq më i lartë është kostoja e zhvillimit. Aspekte që nuk lidhen me funksionalitetin, si përvoja e zhvilluesve të softuerit dhe ripërdorimi i kodit, janë gjithashtu thelbësore për t'u marrë parasysh në vlerësim. Që prej 2019, shumica e mjeteve për vlerësimin e sasisë së kohës dhe burimeve për zhvillimin e softuerit janë krijuar për aplikacione konvencionale dhe nuk janë të zbatueshme për aplikacionet në ueb ose aplikacionet celulare.

### Mjedisi i integruar i zhvillimit

 Anjuta, një C dhe C++ IDE për mjedisin GNOME
Një mjedis zhvillimi i integruar (IDE) mbështet zhvillimin e softuerit me veçori të përmirësuara në krahasim me një redaktues të thjeshtë teksti . IDE-të shpesh përfshijnë përpilim të automatizuar, theksim sintaksor të gabimeve, ndihmë për korrigjimin e gabimeve, integrim me kontrollin e versionit dhe gjysmë-automatizim të testeve.

### Kontrolli i versionit

Kontrolli i versionit është një mënyrë popullore për të menaxhuar ndryshimet e bëra në softuer. Sa herë që kontrollohet një version i ri, softueri ruan një kopje rezervë të të gjithë skedarëve të modifikuar. Nëse shumë programues janë duke punuar në softuer njëkohësisht, ai menaxhon bashkimin e ndryshimeve të kodit të tyre. Softueri thekson rastet kur ka një konflikt midis dy grupeve të ndryshimeve dhe lejon programuesit të rregullojnë konfliktin.

### Shiko modelin

 Matrica TEAF e pikëpamjeve dhe perspektivave.
Modeli i pamjes është një kornizë që ofron pikëpamjet mbi sistemin dhe mjedisin e tij, për t'u përdorur në procesin e zhvillimit të softuerit. Është një paraqitje grafike e semantikës themelore të një pamjeje.

Qëllimi i pikëpamjeve dhe pikëpamjeve është t'u mundësojë inxhinierëve njerëzorë të kuptojnë sisteme shumë komplekse dhe të organizojnë elementet e problemit rreth fushave të ekspertizës. Në inxhinierinë e sistemeve intensive fizike, pikëpamjet shpesh korrespondojnë me aftësitë dhe përgjegjësitë brenda organizatës inxhinierike.

### Funksionet e fitnesit

Funksionet e fitnesit janë teste të automatizuara dhe objektive për të siguruar që zhvillimet e reja të mos devijojnë nga kufizimet e vendosura, kontrollet dhe kontrollet e pajtueshmërisë.

## Pronësia intelektuale

Pronësia intelektuale mund të jetë një problem kur zhvilluesit integrojnë kodin me burim të hapur ose bibliotekat në një produkt të pronarit, sepse shumica e licencave me burim të hapur të përdorura për softuer kërkojnë që modifikimet të lëshohen nën të njëjtën licencë. Si një alternativë, zhvilluesit mund të zgjedhin një alternativë të pronarit ose të shkruajnë modulin e tyre të softuerit.

## Lidhje të jashtme

## Shiko edhe

* Procesi i zhvillimit të softuerit

## Burimi

## Lexime të tjera

Këto janë disa libra dhe materiale në gjuhën angleze.

* Jim McCarthy (1995). *Dynamics of Software Development*.
* Dan Conde (2002). *Software Product Management: Managing Software Development from Idea to Product to Marketing to Sales*.
* A.M. Davis (2005). *Just enough requirements management: where software development meets marketing*.
* Edward Hasted. (2005). *Software That Sells : A Practical Guide to Developing and Marketing Your Software Project*.
* Luke Hohmann (2003). *Beyond Software Architecture: Creating and Sustaining Winning Solutions*.
* John W. Horch (2005). "Two Orientations On How To Work With Objects." In: *IEEE Software*. vol. 12, no. 2, pp. 117–118, Mar., 1995.
* John Rittinghouse (2003). *Managing Software Deliverables: A Software Development Management Methodology*.
* Karl E. Wiegers (2005). *More About Software Requirements: Thorny Issues and Practical Advice*.
* Robert K. Wysocki (2006). *Effective Software Project Management*.