Menaxhimi i projekteve softuerike

menaxhimi i projekteve softuerike ose Software project management është pjesë thelbësore e inxhinierisë softuerike, është arti dhe shkenca e planifikimit dhe udhëheqjes së projekteve softuerike ^[1]^[2]. Projektet kërkohet që të menaxhohen sepse inxhinieri profesionist për softuer është subjekti kryesor në organizimin e kufizimeve të buxhetit dhe organizimin e kohës ^[1]. Menaxhimi i projekteve softuerike është një nën-disiplinë e menaxhimit të projekteve "en:project management" në të cilën planifikohen, monitorohen dhe kontrollohen projektet softuerike.

Historia

Industria e softuerit u rrit shumë shpejt në vitet 1970 dhe 1980, pasi kompanitë kuptuan lehtësinë e përdorimit të programimit të softuerit mbi qarkun e harduerit. Për të menaxhuar përpjekje të reja për zhvillim, kompanitë aplikuan metoda të që ishin përdorur më parë për menaxhim të projektit, por menaxhimi i orarit të projektit dështoj gjatë testimit, sidomos kur ndodhte konfuzion mes specifikimeve të përdoruesit dhe dorëzimit të softuerit. Për të shmangur këto probleme, metodat e menaxhimit të projektit softuerik u fokusuan në përputhjen e kërkesave të përdoruesve me produktet e ofruara, në një metodë të njohur tani si modeli watefall. Që atëherë, në analizën e menaxhimit të projekteve kanë treguar se këto janë shkaqet më të shpeshta të dështimeve ^[3]:

Synime joreale ose të paartikuluara për projektin
Vlerësimet e pasakta të burimeve të nevojshme
Kërkesat e sistemit të definuara keq
Raportimi i dobët i statusit të projektit
Rreziqet e pamenaxhuar
Komunikimi i dobët në mes të konsumatorëve, zhvilluesve, dhe përdoruesve
Përdorimi i teknologjisë së papjekur
Paaftësia për të trajtuar kompleksitetin e projektit
Praktika dobët e zhvillimit
Menaxhimi i dobët i projektit
Politike e "stakeholder"
Presioni komercial

Që nga viti 1960, janë zhvilluar disa metoda të menaxhimit të projektit softuerik nga prodhuesit e softuerëve për përdorimin e tyre, ndërsa firma konsulente për kompjuterë gjithashtu kanë zhvilluar metoda të ngjashme për klientët e tyre. Sot metodat e menaxhimit të projekteve softuerike janë ende në zhvillim, por trendi i tanishëm çon larg nga "modeli waterfall" në një model me më shumë cikle për dorëzimin e projektit që është i njëjtë me "ciklin e lëshimit të softuerit".

Menaxhimi

Në një studim të publikuar nga IEEE, zëvendës presidentë të inxhinierisë së tre kompanive teknologjike janë pyetur për kontribuuesin më të rëndësishëm në një projekt softuerik:

Përgjigja e tyre ishte se janë njerëzit faktori kryesor, mënyra se si do i zgjedhësh, njohurit që kanë ato, dhe menaxhimi i mirë i tyre sjell deri te suksesi për të krijuar produkt të suksesshëm.

Burimi :IEEE^[4]

Menaxhimi efektiv i projektit softuerik fokusohet në katër pika: njerëzit, produkti, procesi dhe projekti. Rënditja nuk është arbitrare ^[5].

Njerëzit: Modeli i menaxhimi të njerëzve përcakton fushat praktike kryesore për njerëzit rekrutimi, përzgjedhja, menaxhimit i performancës, trajnimet, kompensimin, zhvillimin e karrierës, organizimin dhe projektimin e punës, dhe zhvillimin e ekipit/kulturën.
Produkti: Para se një projekt të planifikohet, duhet të përcaktohen objektivat dhe qëllimi i produktit, duhet të shqyrtohen zgjidhje alternative, teknike dhe duhet të identifikohen kufizimet e menaxhimit. Pa këtë informacion, është e pamundur të përcaktohet arsyeshëm vlerësimi i kostos, vlerësimi i rrezikut, ndarja reale e detyrave të projektit, apo një orar të menaxhueshëm të projekt që ofron një tregues kuptimplotë të progresit.
Procesi: Një proces i softuerit ofron një strukturë nga e cila një plan i plotë për zhvillimin e softuerit mund të themelohet. Një numër i vogël i aktiviteteve të strukturës janë të zbatueshme për të gjitha projektet softuerike, pavarësisht nga madhësia e tyre apo kompleksiteti. Një numër i detyrave të ndryshme si "sets—tasks", "milestones", produktet e punës, dhe pikave të sigurimit të cilësisë mundësojnë aktivitete të strukturës të përshtaten me karakteristikat e projektit softuerik dhe kërkesat e ekipit të projektit.
Projekti: Qëllimi i kontrollimit dhe planifikimit të projekteve softuerike, si arsye primar është sepse është e vetmja rrugë për të menaxhuar komplikimet e mundshme. Edhe pse shkalla e suksesit për projektet e softuerike është përmirësuar disi, shkalla e dështimit të projektit mbetet më e lartë nga sa ajo duhet që të jetë. Për të shmangur dështimin e projektit, menaxheri i projektit të softuerit dhe inxhinierët e softuerit që ndërtojnë produktin duhet të shmangin një grup të shenjave paralajmëruese të përbashkëta, të kuptojnë faktorët kritik për sukses që çojnë në menaxhim të mirë të projektit, dhe të zhvillojnë një qasje gjithëpërfshirëse për planifikimin, monitorimin dhe kontrollin e projektit.

Procesi i klasifikimit të projekteve

Klasifikimi sipas karakteristikave të projektit softuerik

Në thelb janë dy tipe të ndryshme të të projekteve softuerike që dalin nga kërkesa të ndryshme ^[6].

Projekti bottom-up ("Projekti nga poshtë-lartë" i orientuar në kërkesat)

Projekti top-down ("Projekti nga lartë-poshtë" i orientuar në zgjidhje)

Lloji i projekteve bottom-up zakonisht është i nxitur nga kërkesat(nevojat shtesë). Dikush në organizatë sheh një problem ose një kërkesë, dhe projekti fillon të zgjidh problemin. Ndërsa lloji i projekteve top-down zakonisht janë të orientuar në zgjidhje.

Shumë organizata kanë zgjedhur ti klasifikojnë projektet sipas disa karakteristikave të projekteve në vijim^[6]:

Risk - ose rreziku, vendos nivelin e rrezikut (i lartë, mesatar, i ulët);
Bussines value - vlera e biznesit, vendos nivelin e biznesit (i lartë, mesatar, i ulët);
Length - gjatësia- vendos disa kategori të ndryshme(psh, 3 muaj, 3-6 muaj, 6-12 muaj, etj.);
Compexity- kompleksiteti vendos kategorinë (i lartë, mesatar, i ulët);
Technology used- Teknologjia e përdorur vendos disa kategori të ndryshme (i vendosur mirë, e panjohur, etj.);
Number of departments affekted- numri i departamenteve të përfshira vendos disa kategori( një, disa, më shumë, të gjitha);
Cost - Kostoja;

Klasifikimi sipas llojit të projektit

Janë disa situata ku një organizatë përsëritën projektet të cilat janë të llojit të njëjtë^[6]. Disa shembuj të llojeve të projekteve janë :

Instalimi i softuerit;
Rekrutimi dhe punësimi;
Vendosja e harduerit në zyra;
Nxitja, vlerësimi,dhe përzgjedhja shitësve
Përditësim i një procedure të korporatës
Zhvillimi (ndërtimi) e sistemit të aplikacionit

Këto projekte mund të përsëriten disa herë në secilin vit dhe ndoshta do të ndjek grupin e hapave të njëjtë në secilën herë. E rëndësishme është të theksohet se ne mund t'i klasifikojmë projektet sipas llojit. Vlera e kësaj është se secili lloj të projektit shfrytëzon një nëngrup specifik të metodologjive të menaxhimit të projektit^[6].

Planifikimi, monitorimi dhe kontrollimi i projektit

Qëllimi i planifikimit të projektit është të identifikojë qëllimin e projektit, vlerësimi i punës së përfshirë, dhe për të krijuar një orar të projektit. Planifikimi i projektit fillon me kërkesat që të përcaktojnë softuerin që duhet të ndërtohet. Plani i projektit është ndërtuar për të përshkruar detyrat që do të çojnë deri në përfundimin e projektit.

Qëllimi i monitorimit dhe kontrollit të projektit është që të mbajë ekipin dhe menaxhimin të përditësuar mbi progresin e projektit. Nëse projekti devijon nga plani, atëherë drejtuesi i projektit mund të marrë masa për të korrigjuar problemin. Monitorimi dhe kontrolli i projektit përfshin takimet e gjendjes për të mbledhur gjendjen nga ekipi ose grupet, se deri ku janë me punimet.

Mjete

Grafiku i Modelit Grantt Chart përdoret për menaxhimin e projekteve softuerike. Është bazë e planifikimeve të kohëzgjatjes të projekteve, sepse zbërthen projektin me të gjitha detyrat e nevojshme dhe lejon ekipet punuese të caktojnë kohën e zgjatjes për cilën detyrë. Përdorimin e modelit Grantt Chart sot gjendet në shumë softuerë kompjuterikë ^[6]. Disa do i përmendim në vijim ^[7]:

Microsoft Project është një program për menaxhimin e projektit softuerik, zhvilluar dhe shitur nga Microsoft, program i projektuar të ndihmoj menaxherin e një projekti për zhvillimin e një plani, caktimin e resurseve të detyrave, ndjekjen e progresit, menaxhimin e buxhetit, dhe analizën e ngarkesës së punës ^[8].

Primavera është softuer për menaxhim të projekteve, në kuadër të Primavera Systems.

Celoxis është një softuer për menaxhimin e projekteve i bazuar Web.

Të tjera :BrightWork, IBM Current

Shih edhe

Burime të jashtme

Gabim i përfshirjes: {{En}} është vetëm për emërhapësirën e Skeda. Përdorni më mirë {{lang-en}} ose {{in lang|en}}. Burime në Software Project Management nga Steve McConnell: https://web.archive.org/web/20110915130320/http://www.construx.com/Page.aspx?nid=22
Gabim i përfshirjes: {{En}} është vetëm për emërhapësirën e Skeda. Përdorni më mirë {{lang-en}} ose {{in lang|en}}. Burime në Software Project Management nga Dan Galorath: https://web.archive.org/web/20110903031334/http://www.galorath.com/wp/category/project-management

Referime

^ ^a ^b Ian, Sommerville (2011). Software engineering 9th Edition. Addison Wesley. ISBN 978-0-13-703515-1. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
^ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. ISBN 978-0-596-00948-9. Arkivuar nga origjinali më 9 shkurt 2015. Marrë më 26 prill 2012. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
^ IEEE Arkivuar 21 dhjetor 2011 tek Wayback Machine magazine article "Why Software Fails"
^ Smith, Curtis, B.; etj. (1988). ""A Field Study of the Software Design Process for Large Systems," Software Engineering". IEEE Trans. SE-31 no. 11: 1268–1287. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Emra të shumëfishtë: lista e autorëve (lidhja)
^ Roger S. Pressman, Ph.D. (2001). Software engineering: a practitioner’s approach / Roger S. Pressman.—5th ed. New York: McGraw-Hill Higher Education. ISBN 0-07-365578-3. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
^ ^a ^b ^c ^d ^e Fetaji, Bekim (2012). Software engineering (Manuscript). {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!),UEJL- Teotvë, Maqedoni
^ "Project Management Software Tools". Arkivuar nga origjinali më 24 prill 2012. Marrë më 6 maj 2012. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
^ Project Management | Project Collaboration Software | Microsoft Project 2010

[Sommerville22-1] Ian, Sommerville (2011). Software engineering 9th Edition. Addison Wesley. ISBN 978-0-13-703515-1. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)

[Stellman05-2] Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. ISBN 978-0-596-00948-9. Arkivuar nga origjinali më 9 shkurt 2015. Marrë më 26 prill 2012. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)

[3] IEEE Arkivuar 21 dhjetor 2011 tek Wayback Machine magazine article "Why Software Fails"

[4] Smith, Curtis, B.; etj. (1988). ""A Field Study of the Software Design Process for Large Systems," Software Engineering". IEEE Trans. SE-31 no. 11: 1268–1287. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Emra të shumëfishtë: lista e autorëve (lidhja)

[McGraw-H-3-5] Roger S. Pressman, Ph.D. (2001). Software engineering: a practitioner’s approach / Roger S. Pressman.—5th ed. New York: McGraw-Hill Higher Education. ISBN 0-07-365578-3. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)

[BFetaji-6] Fetaji, Bekim (2012). Software engineering (Manuscript). {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!),UEJL- Teotvë, Maqedoni

[7] "Project Management Software Tools". Arkivuar nga origjinali më 24 prill 2012. Marrë më 6 maj 2012. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)

[8] Project Management | Project Collaboration Software | Microsoft Project 2010

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]