Wikipedia

Procesi i zhvillimit të softuerit

(Përcjellë nga Procesi i zhvillimit të programit)

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. [1]

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

Redakto

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” [2] 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 . [2]

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
  • Programimi i strukturuar që nga viti 1969
  • Cap Gemini SDM, me origjinë nga PANDATA, përkthimi i parë në anglisht u botua në 1974. SDM do të thotë Metodologjia e Zhvillimit të Sistemit
Vitet e 80-ta
Vitet e 90-ta
  • Programimi i orientuar në objekte (OOP) u zhvillua në fillim të viteve 1960 dhe u bë një qasje dominuese e programimit gjatë mesit të viteve 1990
  • Zhvillimi i shpejtë i aplikacioneve (RAD), që nga viti 1991
  • Metoda e zhvillimit të sistemeve dinamike (DSDM), që nga viti 1994
  • Scrum, që nga viti 1995
  • Procesi i softuerit të ekipit, që nga viti 1998
  • Procesi i Unifikuar Racional (RUP), i mbajtur nga IBM që nga viti 1998
  • Programim ekstrem, që nga viti 1999
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

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ë.[3]

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

Redakto

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

Parimet bazë janë: [1]

  • 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ë

Redakto

Zhvillimi Agile

Redakto

"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

Integrim i vazhdueshëm

Redakto

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. [4] Grady Booch e prezantoi dhe e propozoi CI në metodën e tij të vitit 1991,[5] 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

Redakto

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]

  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

Redakto
 
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ë: [1]

  • 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

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

Përshkrimi i parë formal i metodës citohet shpesh si një artikull i botuar nga Winston Walker. Royce (1929–1995) [6] 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. [7]

Parimet bazë janë: [1]

  • 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ë.[sipas kujt?]. 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 .[sipas kujt?]]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.[sipas kujt?] Shih Kritika e modelit të ujëvarës .

Zhvillimi me metodën spirale

Redakto
 
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ë.

Parimet bazë janë: [1]

  • Fokusi është në vlerësimin e rrezikut dhe në minimizimin e rrezikut të projektit duke e ndarë një projekt në segmente më të vogla dhe duke ofruar më shumë lehtësi në ndryshim gjatë procesit të zhvillimit, si dhe duke ofruar mundësinë për të vlerësuar rreziqet dhe për të peshuar konsideratën e vazhdimit të projektit gjatë gjithë ciklit jetësor.
  • "Çdo cikël përfshin një përparim përmes së njëjtës sekuencë hapash, për secilën pjesë të produktit dhe për secilin prej niveleve të tij të përpunimit, nga një dokument i përgjithshëm koncepti i funksionimit deri në kodimin e çdo programi individual. [8]
  • Çdo udhëtim rreth spirales përshkon katër kuadrate bazë: (1) përcakton objektivat, alternativat dhe kufizimet e përsëritjes dhe (2) vlerëson alternativat; Identifikoni dhe zgjidhni rreziqet; (3) të zhvillojë dhe verifikojë dorëzimet nga përsëritja; dhe (4) planifikoni përsëritjen e radhës. [9]
  • Filloni çdo cikël me një identifikim të palëve të interesuara dhe "kushtet e tyre të fitimit" dhe përfundoni çdo cikël me rishikim dhe përkushtim. [10]

Dhënia e formës

Redakto

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. [11][12]

Metodologjitë e avancuara

Redakto

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

  • Zhvillimi i drejtuar nga sjellja dhe menaxhimi i procesit të biznesit. [13]
  • 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.

Meta-modelet e procesit

Redakto

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 është standardi ndërkombëtar që përshkruan metodën për të zgjedhur, implementuar dhe monitoruar ciklin jetësor të softuerit.
  • Integrimi i Modelit të Maturitetit të Kapacitetit (CMMI) është një nga modelet kryesore dhe bazohet në praktikat më të mira. Vlerësimet e pavarura vlerësojnë organizatat se sa mirë ndjekin proceset e tyre të përcaktuara, jo për cilësinë e atyre proceseve ose softuerit të prodhuar. CMMI ka zëvendësuar CMM .
  • ISO 9000 përshkruan standardet për një proces të organizuar zyrtarisht për prodhimin e një produkti dhe metodat e menaxhimit dhe monitorimit të progresit. Megjithëse standardi u krijua fillimisht për sektorin e prodhimit, standardet ISO 9000 janë aplikuar edhe në zhvillimin e softuerit. Ashtu si CMMI, certifikimi me ISO 9000 nuk garanton cilësinë e rezultatit përfundimtar, vetëm se janë ndjekur proceset e zyrtarizuara të biznesit.
  • ISO/IEC 15504 Teknologjia e informacionit — Vlerësimi i procesit njihet edhe si Përcaktimi i Kapacitetit të Përmirësimit të Procesit të Softuerit (SPICE), është një "kornizë për vlerësimin e proceseve të softuerit". Ky standard synon të përcaktojë një model të qartë për krahasimin e proceseve. SPICE përdoret njësoj si CMMI. Ai modelon procese për të menaxhuar, kontrolluar, udhëhequr dhe monitoruar zhvillimin e softuerit. Ky model përdoret më pas për të matur atë që një organizatë zhvillimore ose ekip projekti bën në të vërtetë gjatë zhvillimit të softuerit. Ky informacion analizohet për të identifikuar dobësitë dhe për të nxitur përmirësimin. Ai gjithashtu identifikon pikat e forta që mund të vazhdohen ose integrohen në praktikën e zakonshme për atë organizatë ose ekip.
  • ISO/IEC 24744 Inxhinieri Softuerësh—Metamodel për Metodologjitë e Zhvillimit, është një metamodel i bazuar në llojin e fuqisë për metodologjitë e zhvillimit të softuerit.
  • Metodologjia e sistemeve të buta – një metodë e përgjithshme për përmirësimin e proceseve të menaxhimit.
  • Inxhinieria e metodave – një metodë e përgjithshme për përmirësimin e proceseve të sistemit të informacionit.

Në praktikë

Redakto
 
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.[1]

Shihni gjithashtu

Redakto

Referencat

Redakto
  1. ^ a b c d e f g "Selecting a development approach" (PDF). Centers for Medicare & Medicaid Services (CMS) Office of Information Service (në anglisht). United States Department of Health and Human Services (HHS). mars 27, 2008 [Original Issuance: February 17, 2005]. Arkivuar nga origjinali (PDF) më qershor 20, 2012. Marrë më tetor 27, 2008.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja) Gabim referencash: Invalid <ref> tag; name "CMS08" defined multiple times with different content
  2. ^ a b Geoffrey Elliott (2004). Global Business Information Technology: an integrated systems approach (në anglisht). Pearson Education. fq. 87.
  3. ^ Suryanarayana, Girish (2015). "Software Process versus Design Quality: Tug of War?". IEEE Software (në anglisht). 32 (4): 7–11. doi:10.1109/MS.2015.87.
  4. ^ Paul M. Duvall; Steve Matyas; Andrew Glover (2007). Continuous Integration: Improving Software Quality and Reducing Risk (në anglisht). Addison-Wesley Professional. ISBN 978-0-321-33638-5.
  5. ^ Booch, Grady (1991). Object Oriented Design: With Applications (në anglisht). Benjamin Cummings. fq. 209. ISBN 978-0-8053-0091-8. Marrë më gusht 18, 2014.{{cite book}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  6. ^ Markus Rerych. "Wasserfallmodell > Entstehungskontext". Institut für Gestaltungs- und Wirkungsforschung, TU-Wien (në gjermanisht). Marrë më nëntor 28, 2007.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  7. ^ Conrad Weisert. "Waterfall methodology: there's no such thing!" (në anglisht). Arkivuar nga origjinali më gusht 2, 2022.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  8. ^ Barry Boehm (gusht 1986). "A Spiral Model of Software Development and Enhancement". ACM SIGSOFT Software Engineering Notes (në anglisht). Association for Computing Machinery. 11 (4): 14–24. doi:10.1145/12944.12948.{{cite journal}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  9. ^ Richard H. Thayer; Barry W. Boehm (1986). Tutorial: software engineering project management (në anglisht). Computer Society Press of the IEEE. fq. 130.
  10. ^ Barry W. Boehm (2000). Software cost estimation with Cocomo II: Volume 1 (në anglisht).
  11. ^ "Foreword by Jason Fried | Shape Up". basecamp.com (në anglisht). Marrë më shtator 11, 2022.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  12. ^ "Is Shape Up just a nice theory?". Curious Lab (në anglishte australiane). Marrë më shtator 12, 2022.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  13. ^ Lübke, Daniel; van Lessen, Tammo (2016). "Modeling Test Cases in BPMN for Behavior-Driven Development". IEEE Software (në anglisht). 33 (5): 15–21. doi:10.1109/MS.2016.117.

Lidhje të jashtme

Redakto

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

Marrë nga "https://sq.wikipedia.org/w/index.php?title=Procesi_i_zhvillimit_të_softuerit&oldid=2731506"