Përdoruesi:Enis Dapko/Procesi i ndërtimit të softuerit

 

Njëra nga termat në fushën e inxhinierisë softuerike është edhe termi proces i zhvillimit të softuerit ("Software Development Process") ose cikli jetësor i zhvillimit softuerik ("Software Development Cycle ( SDLC )").Ky term si definicion përfshin gjithë procesin e planifikimit dhe të menaxhimit të zhvillimit softuerik . Natyrisht procesi i ndertimit softuerik mund te planifikohet në mënyra dhe metodologji të ndryshme.  Si disa nga mënyrat që përdoren zakonisht mund të përmendet ndarja e procesit në etapa më të vogla, në etapa paralele, në etapa te sekuencuara ose në nën-procese ku mund të përmirësohet dizajni ose menaxhimi i produktit.Ndërsa metodologjitë e ndryshme mund të përfshijne hapat si përcaktimi i produkteve përfundimtare(p.sh. raportet dhe dokumentacioni i nevojshëm ose vet softueri) dhe i artifakteve ne lidhje me produktin(p.sh data modeli ose prototipi), të gjitha këto të krijuara dhe të kompletuara nga grupi punues (project team) që ndërton dhe mirëmban produktet.

Shumica e proceseve moderne të ndërtimit mund të thuhet që i përket metodologjisë agile . Disa nga metodat e tjera më të njohura janë ujëvara(waterfall), prototipim(prototyping), zhvillimin përsëritës dhe në rritje(iterative and incremental development), zhvillimin spiral(spiral development), ndërtim i përshpejtuar i aplikacioneve(rapid application development) dhe programimin ekstrem (extreme programming).

"Model" i ciklit jetësor konsiderohet si një term i përgjithshëm për një kategori të metodologjive dhe "procesi" i ndërtimit të softuerit mund te konsiderohet si një rast specifik e adoptuar nga një organizatë e caktuar. Për shembull, shumë procese të ndërtimit softuerit mund te konsiderohen si modele të ciklit jetësor spiral.Pra, fusha e ndertimit softuerik konsiderohet si nën fushë e fushës së ciklit jetësor të ndërtimit të sistemeve .

Historia

Metodologjia e ndërtimit softuerik nuk u shfaq deri në vitet 1960. Sipas Elliott (2004), cikli jetësor i zhvillimit të sistemeve mund të konsiderohet si metodologjia më e vjetër dhe më e formalizuar për krijimin e sistemeve të informacionit . Parimi bazë i ciklit jetësor të ndërtimit të softuerit ka qenë " zhvillimi i sistemeve të informacionit në një mënyrë shumë të qëllimshme, të strukturuar dhe metodike, duke kërkuar çdo fazë të ciklit jetësor - që nga krijimi i idesë deri te dorëzimi i sistemit përfundimtar. ––të zbatohet në mënyrë rigoroze dhe në rend të caktuar” brenda kuadrit të kornizës përkatëse. Qëllimi kryesor i kësaj kuadri metodologjie në vitet 1960 ishte "zhvillimi i sistemeve të mëdha dhe funksionale të biznesit në shkallë të gjerë në një epokë të konglomerateve të biznesit në shkallë të gjerë, ku aktivitetet e sistemeve të informacionit ishin kryesisht të përqëndruara në përpunimet të mëdha të të dhënave dhe rutinave të grumbullimit të numrave ."

Mbledhja dhe vlerësimi e kërkesave: Hapi fillestar i procesit të ndërtimit softuerik me porosi përqendrohet në kuptimin e nevojave dhe objektivave të klientit. Kjo fazë përfshin zhvillimin e diskutimeve të hollësishme dhe intervistimin e palëve të interesuara për të përcaktuar veçoritë e dëshiruara, funksionalitetet dhe shtrirjen e përgjithshme të softuerit. Ekipi i zhvillimit bashkëpunon me klientin për të shqyrtuar sistemet dhe proceset ekzistuese të punës, për të përcaktuar fizibilitetin teknik dhe për të përcaktuar pikat kryesore të projektit.

Planifikimi dhe dizajni: Pasi të jenë kuptuar kërkesat, ekipi i zhvillimit të softuerit të personalizuar harton një plan të detajuar të projektit. Ky plan përfshin hartën e zhvillimit, duke specifikuar afatet kohore, ndarjen e burimeve dhe dorëzimet e tyre. Arkitektura dhe dizajni i softuerit vendosen gjithashtu gjatë kësaj faze. Elementet e dizajnit të ndërfaqes së përdoruesit (UI) dhe përvojës së përdoruesit (UX) konsiderohen për të siguruar përdorshmërinë, intuitivitetin dhe tërheqjen vizuale të softuerit.

Zhvillimi: Pasi planifikimi dhe dizajni janë përfunduar, ekipi i zhvillimit fillon procesin e kodimit. Kjo fazë përfshin shkrimin, testimin dhe korrigjimin e gabimeve në kodin e softuerit. Metodologjitë agile, si scrum ose kanban, shpesh përdoren për të siguruar fleksibilitet, bashkëpunim dhe zhvillim në faza të përsëritura. Komunikimi i rregullt midis ekipit të zhvillimit dhe klientit siguron transparencë dhe mundëson marrjen e komenteve dhe përshtatjen e shpejtë kur është e nevojshme.

Testimi dhe sigurimi i cilësisë: Për tu siguruar që softueri të jetë i besueshmë, performant dhe i sigurit , kryhen procese të kujdesshme testimi dhe sigurimi cilësor (QA). Zbatohen teknika të ndryshme testimi, si testimi i njësisë, integrimit, sistemit dhe sistemit dhe pranimit të përdoruesit, përdoren për të identifikuar dhe adresuar çdo problem ose defekt. Aktivitetet e sigurimit të cilësisë synojnë të vërtetojnë softuerin kundrejt kërkesave të paracaktuara, duke siguruar që ai të funksionojë siç është menduar.

Vendosja dhe implementimi: Pasi softueri kalon fazën e testimit, ai është gati për tu vendosur dhe implementuar. Ekipi i zhvillimit asiston klientin në krijimin e mjedisit të nevojshëm për softuerin, migrimin e të dhënave nëse është e nevojshme dhe konfigurimin e sistemit.Po ashtu, ofrohen trajnime për përdoruesit dhe udhëzime për të siguruar një kalim të përshtatshëm dhe për t’i mundësuar përdoruesve të shfrytëzojnë në mënyrë të plotë mundësitë e softuerit.

Mirëmbajtja dhe mbështetja: Pas vendosjes së softuerit, mirëmbajtja dhe mbështetja e vazhdueshme bëhen të rëndësishme për të adresuar problemet, për të përmirësuar performancën dhe për të shtuar përmirësimet e mundshme në të ardhmen.Përdorimi i përditësimeve të rregullta, rregullimin e gabimeve dhe arnimet e sigurisë lëshohen për ta mbajtur softuerin që të mbetet i përditësuar dhe i sigurt. Kjo fazë përfshin gjithashtu ofrimin e asistencës teknike për përdoruesit përfundimtarë dhe zgjidhjen e pyetjeve ose shqetësimeve të tyre. Metodologjitë, proceset dhe kornizat mund të jenë të ndryshme, duke filluar nga hapa të caktuar që mund të përdoren drejtpërdrejt nga një organizatë në punët e përditshme, deri te kornizat fleksibël që mund të krijojnë hapa të personalizuar për nevojat e një projekti ose grupi të caktuar. Në disa raste, një "sponsor" ose organizatë përgjegjëse për "mirëmbajtjen" mund të shpërndajë dokumente të detajuara që përshkruajnë këtë proces. Disa shembuj të tillë përfshijnë:

Vitet e 70-ta

Vitet e 80-ta

• Metoda e analizës dhe projektimit të sistemeve të strukturuara (SSADM) nga viti 1980 e në vazhdim
• Analiza e Kërkesave të Informacionit/Metodologjia e sistemeve të buta

Vitet 2000

• Agile Unified Process (AUP) i mbajtur që nga viti 2005 nga Scott Ambler
• Dorëzimi i shkathët i disiplinuar (DAD) zëvendëson AUP

Vitet e 2010

• Scaled Agile Framework (SAFe)
• Large-Scale Scrum (LeSS)
• DevOps

Që nga DSDM në 1994, të gjitha metodologjitë e përmendura më lart përveç RUP-it kanë qenë metodologji të shkathëta - sidoqoftë shumë organizata, veçanërisht ato qeveritare, ende përdorin procese para-agile (shpesh në formën e modelit ujëvarë ose të ngjashme). Procesi i softuerit dhe cilësia e softuerit janë të lidhura ngushtë; dhe janë vërejtur disa aspekte dhe ndikime të papritura në praktikë.

Ndër këto, është krijuar një proces tjetër i ndërtimit të softuerit në burim të hapur ..Përdorimi i këtyre praktikave më të mira të proceseve të njohura dhe të krijuara brenda kufijve të një kompanie njihet si burim i brendshëm .

Prototipizimi

Prototipi i softuerit përfshin krijimin e prototipave, që janë versionev të papërfunduara të programit softuerit që është në zhvillim.

Parimet bazë janë:

• Prototipizimi nuk është metodologji e plotë e plotë dhe e pavarur zhvillimi, por një qasje për të eksperimentuar me veçori të caktuara brenda një metodologjie më të gjerë (si zhvillimi incremental, spirale, ose zhvillimi i aplikacioneve të shpejta - RAD).
• Qëllimi është të zvogëlohet rreziku i projektit duke e ndarë atë në segmente më të vogla dhe duke lehtësuar mundësinë për ndryshime gjatë zhvillimit. Klienti është i përfshirë në të gjitha fazat e zhvillimit, duke rritur mundësinë e pranimit të zbatimit përfundimtar.
• Disa prototipe krijohen me qëllimin që të hidhen, por në disa raste, prototipi mund të evoluojë në një sistem të funksional.

Një kuptim i thjeshtë i problematikës së biznesit është thelbësor për të shmangur zgjidhjen e problemeve të gabuara, por kjo vlen për të gjitha metodologjitë e softuerit.

Metodologjitë

Zhvillimi Agile

"Zhvillimi i softuerit i shkathët" i referohet një grupi kornizash të zhvillimit të softuerit të bazuar në zhvillimin iterativ, ku kërkesat dhe zgjidhjet përmirësohen përmes bashkëpunimit mes grupeve ndërfunksionale të vetë-organizuara.Ky term u krijua në vitin 2001 kur u formulua Manifesti i Agile .

Zhvillimi i softuerit i shkathët përdor zhvillimin përsëritës si bazë, por promovon një qasje më të lehtë dhe më të orientuar drejt njerëzve sesa metodat tradicionale. Proceset e shkathët përfshijnë në thelb përsëritjen dhe reagimin e vazhdueshëm që ai ofron për të rafinuar dhe dorëzuar një sistem softueri në menyrë të përsëritur.

Modeli Agile përfshin gjithashtu këto procese të zhvillimit të softuerit:

• Dynamic systems development method (DSDM)
• Kanban
• Scrum
• Lean software development

Continuous integration

Integrimi i vazhdueshëm quhet procesi i bashkimit të të gjitha kopjeve të cilat janë funksionale së zhvilluesit në një linjë kryesore të përbashkët disa herë gjatë ditës. Grady Booch e prezantoi dhe e propozoi CI në metodën e tij të vitit 1991, megjithëse ai nuk e rekomandoi integrimin disa herë në ditë. Programimi ekstrem (XP) e miratoi këtë koncept të CI dhe e mbështeti integrimin më shumë se një herë në ditë – ndoshta deri në disa dhjetëra herë në ditë.

Zhvillimi në rritje

Egzistojnë metoda të ndryshme që mund të përdoren dhe janë të pranueshme për kombinimin e metodologjive lineare dhe përsëritëse të zhvillimit të sistemeve, me objektivin kryesor të secilës të reduktojë rrezikun e qenësishëm të projektit duke e ndarë atë në pjesë më të vogla dhe duke mundësuar më shumë lehtësi ndryshimi gjatë procesit të zhvillimit.

Ekzistojnë tre variante kryesore të zhvillimit në rritje:

1. Kryhen një sërë mini-ujëvarash, ku të gjitha fazat e ujëvarës përfundojnë për një pjesë të vogël të një sistemi, përpara se të vazhdohet në rritjen e radhës, ose
2. Kërkesat e përgjithshme përcaktohen përpara se të vazhdohet me zhvillimin evolucionar, mini-ujëvarash të rritjeve individuale të një sistemi, ose
3. Koncepti fillestar i softuerit, analiza e kërkesave dhe dizajni i arkitekturës dhe bërthamës së sistemit përcaktohen përmes ujëvarës, pasuar nga zbatimi në rritje, i cili kulmon me instalimin e versionit përfundimtar, një sistem pune.

Zhvillimi i shpejtë i aplikacioneve

Modeli i zhvillimit të shpejtë të aplikacionit (RAD).

Zhvillimi i aplikacioneve të shpejta (RAD) është një metodologji e zhvillimit të softuerit, e cila favorizon zhvillimin përsëritës dhe ndërtimin e shpejtë të prototipeve në vend të një të planifikimi të gjerë paraprak. "Planifikimi" i softuerit që zhvillohet me RAD është i ndërthurur me shkrimin e vetë softuerit.Duke shmangur një planifikim të thelluar paraprak, RAD mundëson krijimin e software-it më shpejt dhe lehtëson ndryshimin e kërkesave gjatë procesit.

Procesi i zhvillimit të shpejtë të softuerit niset me zhvillimin e modeleve paraprake të modeleve të dhënave dhe modeleve të procesit të biznesit duke ofruar teknika të strukturuara . Në fazën tjetër, kërkesat verifikohen duke përdorur prototipimin, duke rafinuar më tej moedelet e të dhënave dhe proceseve. Këto faza përsëriten në mënyrë të vazhdueshme; zhvillimi i mëtejshëm çon në "një përshkrim të kombinuar të kërkesave të biznesit dhe dizajnit teknik që do të përdoret për të ndërtuar sisteme të reja".

Ky term u përdor për herë të parë për të përshkruar një proces të zhvillimit të softuerit të prezantuar nga James Martin në vitin 1991. Sipas Whitten (2003), ai përbën një bashkim i teknologjive të strukturuara, veçanërisht inxhinierisë së teknologjisë së informacionit të bazuar në të dhëna, me teknikat e prototipimit për të përshpejtuar zhvillimin e sistemeve softuerike.

Ndër parimet themelore të zhvillimit të aplikacioneve të shpejta janë:

• Objektivi kryesor është zhvillimi dhe ofrimi i shpejtë i një sistemi me cilësi të lartë me një kosto investimi relativisht të ulët.
• Përpjekjet për të reduktuar rrezikun e qenësishëm të projektit duke e ndarë një projekt në segmente më të vogla dhe duke ofruar më shumë lehtësi ndryshimi gjatë procesit të zhvillimit.
• Synon të prodhojë shpejt sisteme me cilësi të lartë, kryesisht nëpërmjet Prototipizimit përsëritës (në çdo fazë të zhvillimit), përfshirjes aktive të përdoruesve dhe mjeteve të kompjuterizuara të zhvillimit. Këto mjete mund të përfshijnë ndërtuesit e ndërfaqes grafike të përdoruesit (GUI), mjetet e inxhinierisë softuerike me ndihmën e kompjuterit (CASE), sistemet e menaxhimit të bazës së të dhënave (DBMS), gjuhët e programimit të gjeneratës së katërt, gjeneruesit e kodeve dhe teknikat e orientuara nga objekti.
• Theksi kryesor është në përmbushjen e nevojës së biznesit, ndërsa përsosmëria teknologjike ose inxhinierike ka një rëndësi më të vogël.
• Kontrolli i projektit përfshin prioritizimin e zhvillimit dhe përcaktimin e afateve të dorëzimit ose "kutive kohore". Nëse projekti fillon të rrëshqasë, theksi vihet në reduktimin e kërkesave për t'iu përshtatur kutisë kohore, jo në rritjen e afatit.
• Përgjithësisht përfshin dizajnin e përbashkët të aplikacionit (JAD), ku përdoruesit janë të përfshirë intensivisht në dizajnimin e sistemit, nëpërmjet ndërtimit të konsensusit ose në seminare të strukturuara, ose ndërveprimit të lehtësuar elektronikisht.
• Përfshirja aktive e përdoruesve është e domosdoshme.
• Prodhon në mënyrë të përsëritur softuer prodhimi, në krahasim me një prototip të hedhur.
• Prodhon dokumentacionin e nevojshëm për të lehtësuar zhvillimin dhe mirëmbajtjen në të ardhmen.
• Metodat standarde të analizës dhe projektimit të sistemeve mund të përshtaten në këtë kuadër.

Zhvillimi i ujëvarës

Aktivitetet e procesit të ndërtimit të softuerit të paraqitura në modelin e ujëvarës . Ka disa modele të tjera për të përfaqësuar këtë proces.

Modeli i ujëvarës është një qasje sekuenciale të ndërtimit të softuerit, në të cilën zhvillimi kryhet si rrjedhë në mënyrë të qëndrueshme poshtë (si një ujëvarë) përmes disa fazave, zakonisht:

• Requirements analysis resulting in a software requirements specification
• Software design
• Implementation
• Testing
• Integration, if there are multiple subsystems
• Deployment (or Installation)
• Maintenance

Përshkrimi i parë formal i metodës citohet shpesh si një artikull i botuar nga Winston Walker. Royce (1929 - 1995) në vitin 1970, megjithëse Royce nuk e përdori termin "ujëvarë" në këtë artikull. Royce e paraqiti këtë model si një shembull të një modeli të gabuar, e clia nuk funksionon.

Parimet bazë janë:

• Projekti është i ndarë në faza të njëpasnjëshme, me disa mbivendosje dhe spërkatje të pranueshme ndërmjet fazave.
• Theksi është në planifikimin, oraret, datat e synuara, buxhetet dhe zbatimin e një sistemi të tërë në të njëjtën kohë.
• Kontrolli i rreptë mbahet gjatë gjithë jetës së projektit nëpërmjet dokumentacionit të gjerë me shkrim, rishikimeve formale dhe miratimit/nënshkrimit nga përdoruesi dhe menaxhimi i teknologjisë së informacionit që ndodh në fund të shumicës së fazave përpara fillimit të fazës tjetër. Dokumentacioni i shkruar është një dorëzues i qartë i çdo faze.

Modeli i ujëvarës është një qasje tradicionale inxhinierike që aplikohet në inxhinierinë e softuerit. Një një qasje të rreptë të ujëvarës ku nuk lejohet rishikimi ose ndryshimi i fazave të mëparshme pasi të përfundojë.. Kjo "mungesë fleksibiliteti" në modelin e pastër të ujëvarës shpesh ka qenë një objekt kritikash nga mbështetësit e modeleve të tjera më "fleksibile".Ky model është fajësuar për disa projekte të mëdha qeveritare në shkallë të gjerë që tejkalojnë buxhetin, dhe në disa raste kanë dështuar të përmbushin kërkesat për shkak të qasjes së madhe të projektimit fillestar .]Përveç rasteve kur kërkohet me kontratë, modeli i ujëvarës është zëvendësuar kryesisht nga metodologji më fleksibël dhe të gjithanshme të zhvilluara posaçërisht për zhvillimin e softuerit.] Shih Kritika e modelit të ujëvarës .

Zhvillimi me metodën spirale

Modeli spiral (Boehm, 1988)

Në vitin 1988, Barry Boehm publikoi një "model spiral" formal të ndërtimit të sistemit të softuerik, i cili kombinon disa aspekte kyçe të modelit të ujëvarës dhe metodologjive të prototipimit të shpejtë, me qëllimin për të bashkuar avantazhet e koncepteve nga lart-poshtë dhe nga poshtë-lartë . Ky model vuri theksin në një fushë kyçe që shumica mendonin se ishte neglizhuar nga metodologjitë e tjera: analiza e qëllimshme përsëritëse e rrezikut, veçanërisht të përshtatshme për sistemet komplekse në shkallë më të gjerë.

The basic principles are:

Dhënia e formës

Dhënia e formës është një qasje e zhvillimin e softuerit e prezantuar nga Basecamp në vitin 2018. Ajo përbën një grup parimesh dhe teknikash që Basecamp zhvilloi brenda për të kapërcyer problemin e projekteve që shtrihen pa fund të qartë. Publiku i saj kryesor janë ekipet të cilat punojnë në distancë. Dhënia e formës nuk përdor vlerësime dhe gjurmim të shpejtësisë, prapambetje ose sprint, ndryshe nga ujëvara, agile ose scrum . Në vend të kësaj, ato koncepte zëvendësohen me oreks, baste dhe cikle. Që nga viti 2022, përveç Basecamp, organizatat e shquara që kanë miratuar Dhënia e formës përfshin Zëri i përdoruesit dhe Bllokimi.

Metodologjitë e avancuara

Metodologjitë e tjera të projektit të softuerit të nivelit të avancuar përfshijnë:

• Zhvillimi i drejtuar nga sjellja dhe menaxhimi i procesit të biznesit.
• Modeli i kaosit - Rregulli kryesor gjithmonë zgjidh çështjen më të rëndësishme fillimisht.
• Metodologjia e financimit në rritje - një qasje përsëritëse
• Metodologjia e lehtë - një term i përgjithshëm për metodat që kanë vetëm disa rregulla dhe praktika
• Metoda e analizës dhe projektimit të sistemeve të strukturuara - një version specifik i ujëvarës
• Programimi i ngadaltë, si pjesë e Lëvizjes më të madhe Slow, thekson punën e kujdesshme dhe graduale pa presione (ose minimale) të kohës. Programimi i ngadaltë synon të shmangë gabimet dhe oraret e lëshimit tepër të shpejtë.
• V-Model (zhvillimi i softuerit) - një zgjerim i modelit të ujëvarës
• Procesi i Unifikuar (UP) është një kornizë metodologjike e zhvillimit të softuerit përsëritës, e bazuar në gjuhën e unifikuar të modelimit (UML). UP organizon zhvillimin e softuerit në katër faza, secila e përbërë nga një ose më shumë përsëritje të ekzekutueshme të softuerit në atë fazë të zhvillimit: fillimi, përpunimi, ndërtimi dhe udhëzimet.

Process meta-models

Disa " modele të procesit " janë përshkrime abstrakte për të vlerësuar, krahasuar dhe përmirësuar proceset specifike të miratuar nga një organizatë.

• ISO/IEC 12207 is the international standard describing the method to select, implement, and monitor the life cycle for software.
• The Capability Maturity Model Integration (CMMI) is one of the leading models and is based on best practices. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced. CMMI has replaced CMM.
• ISO 9000 describes standards for a formally organized process to manufacture a product and the methods of managing and monitoring progress. Although the standard was originally created for the manufacturing sector, ISO 9000 standards have been applied to software development as well. Like CMMI, certification with ISO 9000 does not guarantee the quality of the end result, only that formalized business processes have been followed.
• ISO/IEC 15504 Information technology—Process assessment is also known as Software Process Improvement Capability Determination (SPICE), is a "framework for the assessment of software processes". This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide, and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.
• ISO/IEC 24744 Software Engineering—Metamodel for Development Methodologies, is a power type-based metamodel for software development methodologies.
• Soft systems methodology - a general method for improving management processes.
• Method engineering - a general method for improving information system processes.

Në praktikë

Tre qasjet bazë të aplikuara për kornizat e metodologjisë së zhvillimit të softuerit

Një shumëllojshmëri e këtyre kornizave janë zhvilluar gjatë viteve, secila me përparësite dhe mangësitë e saj të njohura. Një kornizë metodologjie e zhvillimit të softuerit nuk është patjetër e përshtatshme për t'u përdorur në të gjitha projektet. Secila prej kornizave metodologjike të disponueshme është më e përshtatshme për lloje të veçanta projektesh, bazuar në konsiderata të ndryshme teknike, organizative, projektesh dhe ekipore.

Shihni gjithashtu

• Systems development life cycle
• Computer-aided software engineering (some of these tools support specific methodologies)
• List of software development philosophies
• Outline of software engineering
• Software Project Management
• Software development
• Software development effort estimation
• Software release life cycle
• Top-down and bottom-up design#Computer science

Lidhje të jashtme

• Zgjedhja e një qasjeje zhvillimi në cms.hhs.gov.
• Gerhard Fischer, "Teknologjia e softuerit të shekullit të 21-të: Nga ripërdorimi i softuerit në dizajnin bashkëpunues të softuerit", 2001

[[Kategoria:Metodologji]] [[Kategoria:Inxhinieria softuerike]]