Jump to content

Inxhinieria Softuerike

Nga Wikipedia, enciklopedia e lirë
(Përcjellë nga Inxhinieri Programesh)

Inxhinieria softuerike, (ang.: Software Engineering.), është një degë e shkencave kompjuterike që merret me prodhimin, mirëmbajtjen, testimin dhe përmirësimin e programeve të ndryshme informatike (Software Maintenance). Inxhinieria softuerike është term i shpikur në vitin 1968, në një konferencë shkencore ku shtroheshin pyetje "në lidhje me krizën softuerike" dhe u shpik si një përgjigje për gjendjen e palakmueshme të zhvillimit të programeve softuerike dhe cilësisë së tyre. Zhvilluesit softuerik në atë kohë nuk ishin në gjendje për të vendosur objektiva konkrete, kjo parashikohej nga burimet e nevojshme për të arritur këto objektiva, si dhe për të menaxhuar pritjet e konsumatorëve.

Definicioni për inxhinierinë softuerike

[Redakto | Redakto nëpërmjet kodit]

Inxhinieria softuerike është disiplinë e shkencave kompjuterike që ka të bëjë me zhvillimin e aplikacioneve me qasje të strukturuar. Inxhinieria softuerike mbulon jo vetëm aspektet teknike të sistemeve softuerike, por edhe modelimet vizuale, specifikimet formale, përkufizimet matematikore të sistemeve softuerike, çështjet e menaxhimit, sic janë udhëheqja e ekipeve programuese, planifikimi dhe buxhetimi, programimi, testimi, implementimi dhe mirëmbajtja për çështjet e zhvillimit të sistemeve softuerike.

Tradicionalisht, inxhinieria softuerike është përqëndruar kryesisht në programim kompjuterik me ‘ad hoc’ analizën dhe projektim të teknikave.

Këto ‘ad hoc’ metoda të inxhinierisë softuerike rezultuan në prodhimin e një sistemi softuerik që nuk u përputhën me kërkesat e shfrytëzuesit, zakonisht mbikalonin buxhetin dhe orarin, si dhe ishin jashtëzakonisht të vështirë për tu përmbajtur dhe përmirësuar.

Përpara vitit 1975, shumica e organizatave softuerike përdornin teknika të thjeshta; secila punonte sipas mënyrës së vet. Depërtimet më të mëdhaja u bën përafërsisht gjatë viteve 1975 dhe 1985, me zhvillimin e të ashtuquajturës paradigm klasike dhe e strukturuar.

Përpjekja për të arritur deri në zgjidhjen e të ashtuquajturës “kriza softuerike”, qeveritë dhe organizatat private motivuan zhvillimin e të ashtuquajturës metoda “ujëvarë”. Këto metoda definuan kërkesat formale dhe fazat analitike, të cilat duhet të jenë të përfunduara para fillimit të fazës së dizajnimit formal, që duhet të përfundohen para se të filloj faza e implementimit formal, etj. Megjithëse metoda ujëvarë zakonisht është më superiorja tek metodat e rastit, sistemet softuerike të mëdhaja dhe të ndërlikuara ende prodhoheshin pas orarit dhe duke kaluar buxhetin, çka nuk përputheshin me kërkesat e shfrytëzuesit. Kjo ndodhte për disa arsye.

Sëpari, metoda ujëvarë fokusohet më mirë në gjenerimin e produkteve të punës se sa në “inxhinieri”. Thënë më thjeshtë, të shkruash dokumentacionet nuk është e njëjtë se sa të bësh një inxhinieri të mirë. Së dyti, metodat ujëvarë nuk mbështesin evolucionin e kërkesave të sistemit gjatë gjithë zhvillimit të ciklit jetësor. Gjithashtu specifikimet në gjuhën angleze të prodhuara me metodat ujëvarë nuk janë të përshtatshme për përshkrimin e ndodhive të ndërlikuara në sistemet softuerike.

Theksi në inxhinierin softuerike është në të dy fjalët, softuer dhe inxhinieri. Një inxhinier është i aftë të ndërton një produkt me cilësi të lartë duke përdorur kretër (komponentë) që shiten dhe duke i integruar ato në kohën dhe detyrimeve buxhetore.

Inxhinieri shpesh përballohet me probleme që janë keq të definuara, zgjedhje të pjesërishme, dhe duhet t’u referohet metodave empirike për të përcaktuar zgjidhjet. Problemi për ndërtimin dhe dërgimin e sistemeve softuerike në kohë ka qenë nën hulumtim dhe kërkim.

Sistemet softuerike të dobishme janë të ndërlikuara. Për të qenë të dobishëm ato duhet të shtjellohen me kërkesat e shfrytëzuesit dhe mjedisin e synuar. Implikimet financiare të krizës softuerike janë të tmerrshme. Në një sondazh i bërë nga Cutter Consortium [2002], u raportua :

  • 75 % e teknologjisë së informacionit kanë qenë të përfshirë në kontestet që përfunduan në gjyq.
  • Në 67 % të këtyre rasteve, funksionimi ose ekzekutimi i produkteve softuerike të dorëzuara nuk përputheshin me pretendimet e zhvilluesve softuerik.

Gjatë viteve 1950, shumica e programeve janë shkruar në gjuhën e kuvendit. Këto programe ishin të kufizuara me disa qindra rreshta të kodit të kuvendit, pra ishin në madhësi të vogël. Çdo programer zhvillonte programe në stilin e vet duke u bazuar në intuitën e tij. Ky lloj programimi u quante Programim Kërkimor.

Zhvillimi i ardhshëm i rëndësishëm që ka ndodhur gjatë viteve 1960 në fushën e programimit ishte programimi me nivel të lartë gjuhësor. Përdorimi i nivelit të lartë gjuhësor në programim reduktoi arritjet e zhvillimit dhe kohën e konsiderueshme. Në atë kohë u paraqitën gjuhët si FORTRAN, ALGOL, dhe COBOL.

Duke u zmadhuar madhësia dhe kompleksiteti i programeve, stili i programimit kërkimor filloi të jetë i pamjaftueshëm. Programeret e kishin të vështirë jo vetëm që të shkruajnë dhe përmirësojnë programet, por edhe të kuptojn dhe mbajn programe të shkruar nga programer të tjerë.

Për tu përballuar me këtë problem, programuesit me përvojë këshilluan programuesit tjerë që t’i kushtojnë vëmendje të veçantë dizajnit të strukturës së programit. Në vitet e ’60, u konstatua se “GOTO” deklarata ishte fajtori kryesorë që e bën strukturën e kontrollit të një programi të komplikuar dhe të çrregullt. Në atë kohë shumica e programuesve shfrytëzuan gjuhën e kuvendit gjerësisht.

Ata duke konsideruar deklaratat e “GOTO” në gjuhët e niveleve të larta ishin më të natyrshme sepse gjenin afërsi me deklaratat e JUMP që shpesh përdoren në gjuhët programuese të kuvendit.

Në këtë periudhë, Dijkstra [1968] publikoi artikullin e tij të famshëm “GOTO Statments Considered Harmful”. Me shpalljen e këtij artikulli shumë programues u zemëruan. Ata botuan disa artikuj duke kundërshtuar dhe duke theksuar avantazhet e deklaratave GOTO. Por, shumë shpejt u dëshmua se vetëm tre konstrukte programimi ishin të mjaftueshëm për të shprehur logjikën e ndonjë programi, ato janë: sekuenca, përzgjedhja dhe përsëritja. Kjo formoi bazën e metodologjisë së programimit të strukturuar.

Pas programimit të strukturuar, zhvillimi tjetër i rëndësishëm ishte struktura e të dhënave-dizajni orientuar. Programuesit argumentuan se për të shkruar një program të mirë, është e rëndësishme ti kushtohet më shumë vëmendje dizajnit të strukturës të të dhënave të programit, sesa dizajnit të strukturës kontrolluese.

Teknika e strukturës së të dhënave-dizajni orientuar ndihmon për të derivuar strukturën e programit prej strukturës së të dhënave të programit. Shembull është teknika e strukturës së të dhënave-dizajni orientuar Jackson’s Structured Programming (JSP), e krijuar nga Michael Jackson në vitin 1970.

Zhvillim tjetër i rëndësishëm në vitet e ’70 ishte zhvillimi i teknikës së të dhënave rrjedhëse-dizajni orientuar. Programuesit me përvojë deklaruan se për të pasur një strukturë programi të mirë, duhet studiuar se si të dhënat rrjedhin nga hyrja deri në dalje të programit. Çdo program lexon të dhëna, i përpunon për të arritur një dalje. Kur rrjedhja e të dhënave është e identifikuar, atëherë prej atje mund të derivohet struktura e programit.

Dizajni objekt-orientuar (1980) është teknika e fundit dhe më e aplikuara.

Ajo ka një dizajn me qasje intuitive ku objektet natyrale (siç janë të punësuarit, pay-roll regjistri, etj) në një problem janë të parat që identifikohen. Lidhjet mes objekteve (siç janë kompozimi, referimi dhe trashëgimia) janë të determinuara. Çdo objekt në fakt vepron si njësi të dhënash të fshehura.

  • Roger S Pressman (2007), Software Engineering: (5rd ed.), Prentice Hall; botimi i 3të (21 dhjetor, 2007), ISBN-10: 0136006639
  • Ian Somerville (2009), Software Engineering, Prentice Hall, botimi i 6të (19 prill 2008), ISBN-10: 0136006329
  • William S. Davis, T.M. Rajkumar (2005), Operating Systems: A Systematic View (botimi i 6të), Publisher AdisonWesley, Inc.2005 (2005), ASIN: B0047T9K8S
  • COMER, D.: Operating System Design. The Xinu Approach, Upper Saddle River, NJ: Prentice Hall, 1984.