menaxhimin e softuerit
Procesi i zhvillimit të softuerit është shumë aktivitete, metoda, teknika dhe hapa të ndryshëm të përdorur për zhvillimin dhe zhvillimin e softuerit dhe produkteve të ngjashme (planet e projektit, dokumentacioni, kodi, testet, dokumentacioni i përdoruesit).
Sidoqoftë, sot nuk ka asnjë proces universal të zhvillimit të softuerit - një grup metodash, rregullash dhe rregulloresh të përshtatshme për softuer të çdo lloji, për çdo kompani, për ekipe të çdo kombësie. Çdo proces zhvillimi aktual i kryer nga një ekip i caktuar brenda një projekti të caktuar ka një numër të madh karakteristikash dhe individualitetesh. Megjithatë, këshillohet që të planifikohet procesi i punës përpara fillimit të projektit, duke përcaktuar rolet dhe përgjegjësitë në ekip, produktet e punës (të ndërmjetme dhe përfundimtare), radhën e pjesëmarrjes në zhvillimin e tyre të anëtarëve të ekipit etj.
Procesi i zhvillimit të softuerit nuk është homogjen. Një ose një metodë tjetër e zhvillimit të softuerit, si rregull, përcakton disa dinamika të vendosjes së llojeve të caktuara të aktiviteteve, domethënë përcakton modelin e procesit.
Modeli është një abstraksion i mirë i metodave të ndryshme të zhvillimit të softuerit, duke i lejuar ato të paraqiten në mënyrë koncize, koncize dhe informative. Megjithatë, vetë ideja e një modeli procesi është një nga më të hershmet në inxhinierinë e softuerit, kur besohej se një model i suksesshëm është gjëja më e rëndësishme që kontribuon në suksesin e zhvillimit. Më vonë u kuptua se ka shumë aspekte të tjera (p.sh. parimet e menaxhimit dhe zhvillimit, struktura e ekipit) që duhet të përcaktohen në përputhje me njëri-tjetrin. Dhe metodologjitë e zhvillimit të integruar filluan të zhvillohen. Megjithatë, ekzistojnë disa modele klasike të procesit të zhvillimit të softuerit.
Modeli i parë që është bërë i njohur gjerësisht dhe strukturon realisht procesin e zhvillimit është kaskada ose ujëvara. Ai u krijua pas konferencës së NATO-s për shkencën dhe teknologjinë e vitit 1968, e cila trajtoi çështje të tilla, dhe e ndan procesin e krijimit të një produkti softuer në faza të njëpasnjëshme (duhet theksuar se ai ishte përdorur tashmë nga zhvillues të ndryshëm, por as numri dhe as përmbajtja e fazave të unifikuar).
Figura 1 - Modeli i modifikuar i zhvillimit të softuerit Waterfall
Modeli i modifikuar i kaskadës parashikonte mundësinë e kthimit në fazat e mëparshme.
Pak kohë pas shfaqjes së saj, modeli i ujëvarës u finalizua nga Winst Royce, duke marrë parasysh ndërvarësinë e fazave dhe nevojën për t'u rikthyer në fazat e mëparshme, e cila mund të shkaktohet, për shembull, nga kërkesa jo të plota ose gabime në formim. të detyrës. Në këtë formë "të kthyeshme", modeli i ujëvarës ekzistonte për një kohë të gjatë dhe ishte baza për shumë projekte (Figura 1).
Sidoqoftë, përdorimi praktik i këtij modeli zbuloi shumë nga mangësitë e tij, kryesore prej të cilave ishte se ai është më i përshtatshëm për llojet tradicionale të aktiviteteve inxhinierike sesa për zhvillimin e softuerit. Në veçanti, një nga problemet më të mëdha ishte "predispozicioni" i tij ndaj mospërputhjeve të mundshme midis produktit që rezulton dhe kërkesave që i vendoseshin atij. Arsyeja kryesore për këtë është se një produkt i formuar plotësisht shfaqet vetëm në fazat e mëvonshme të zhvillimit, por meqenëse puna në faza të ndryshme zakonisht kryhej nga specialistë të ndryshëm dhe projekti u transferua nga një grup në tjetrin, atëherë, sipas parimi i një telefoni të dëmtuar, doli që prodhimi nuk ishte aq i synuar fillimisht.
Për të eliminuar mangësitë e modelit të ujëvarës, u propozua një model i zhvillimit të softuerit në formë V ose me varëse (Figura 2).
Figura 2 - Modeli në formë V i zhvillimit të softuerit
Modeli në formë V lejon shumë më tepër kontroll mbi rezultatin për sa i përket përputhshmërisë së tij me pritjet, pasi është i fokusuar në testim.
Modeli në formë V bëri të mundur përmirësimin e ndjeshëm të cilësisë së softuerit për shkak të përqendrimit të tij në testim, dhe gjithashtu zgjidhi kryesisht problemin e përputhshmërisë së produktit të krijuar me kërkesat e paraqitura për shkak të procedurave të verifikimit dhe certifikimit në fazat e hershme të zhvillimi (vijat me pika në figurë tregojnë varësinë e detyrave të planifikimit/caktimit të fazave dhe testimit/pranimit).
Sidoqoftë, në përgjithësi, modeli në formë V është vetëm një modifikim i modelit të kaskadës dhe ka shumë nga mangësitë e tij. Në veçanti, të dyja janë përshtatur dobët ndaj ndryshimeve të mundshme në kërkesat e klientëve. Nëse procesi i zhvillimit zgjat shumë (nganjëherë deri në disa vjet), atëherë produkti që rezulton mund të jetë në të vërtetë i panevojshëm për klientin, pasi nevojat e tij kanë ndryshuar ndjeshëm.
Softueri, ndryshe nga, për shembull, një mikroçip, mund të vihet në funksion në pjesë, që do të thotë se ai gjithashtu mund të zhvillohet dhe t'i dorëzohet klientit gradualisht. Kjo është baza e modelit rritës, i cili parashikon copëzimin e produktit në komponentë relativisht të pavarur që zhvillohen dhe vihen në funksion veçmas.
Ky model është i dobishëm si për klientin ashtu edhe për krijuesin e sistemit, sepse ju lejon të ecni përpara, duke respektuar interesat e të dyja palëve.
Megjithatë, ajo ka të metat e saj. Ndarja në blloqe funksionale në tërësi ngadalëson procesin, pasi bëhet e nevojshme të sigurohet ndërveprimi i tyre. Për shumë zgjidhje, kjo metodë është e pazbatueshme, pasi është e pamundur të izolohen komponentë individualë prej tyre, të cilët mund të dorëzohen dhe funksionojnë në mënyrë të pavarur. Ngarkesa e punës për personelin drejtues gjithashtu rritet ndjeshëm për shkak të kompleksitetit të detyrave të koordinimit të punës në komponentët individualë të sistemit, rritet kostoja e ndryshimeve në komponentët e gatshëm që tashmë janë instaluar dhe punojnë tek klienti.
Modeli spirale i propozuar nga Barry Boehm në 1988 ishte një përparim i rëndësishëm në të kuptuarit e natyrës së zhvillimit të softuerit, megjithëse ai kombinon një qasje ujëvarë dhe një proces projektimi përsëritës të bazuar në prototipizimin (Figura 3).
Oriz. 3.
Modeli spirale i Boehm-it është i përqendruar te dizajni, zhvillimi i softuerit është vetëm kthesa e fundit e spirales përgjatë modelit të zakonshëm të ujëvarës, por kjo paraprihet nga disa përsëritje të dizajnit të bazuar në prototipizimin - me çdo përsëritje që përfshin fazën e identifikimit dhe analizimit të rreziqeve dhe detyrat më të vështira.
Meqenëse modeli spirale mbulon kryesisht dizajnin, në formën e tij origjinale nuk u përdor gjerësisht si një metodë për menaxhimin e të gjithë ciklit jetësor të zhvillimit të softuerit. Megjithatë, ideja e saj kryesore, që është se procesi i punës në një projekt mund të përbëhet nga cikle që kalojnë nëpër të njëjtat faza, shërbeu si pikënisje për kërkime të mëtejshme dhe u bë baza e modeleve më moderne të procesit të zhvillimit të softuerit.
I propozuar për herë të parë nga Philip Krachten në 1995, modeli përsëritës kombinon avantazhet kryesore të modeleve spirale, inkrementale, ujëvarë, si dhe metodat e zhvillimit të bazuara në prototipizimin dhe qasjen e orientuar nga objekti (Figura 4). Ka fituar popullaritet të madh dhe përdoret në një formë ose në një tjetër në shumë projekte moderne.
Figura 4 - Modeli i zhvillimit iterativ i softuerit
Sipas modelit iterativ, ekzistojnë katër faza kryesore të ciklit jetësor të zhvillimit të softuerit (fillimi, kërkimi, ndërtimi dhe vendosja). Në çdo fazë, projekti kalon nëpër shumë përsëritje, duke çuar në krijimin e versioneve të zbatueshme: në fazat fillestare krijohen prototipe, specifikohen kërkesat dhe përpunohen problemet më komplekse; finalja çon në krijimin e një produkti, përmirësimin e tij dhe zgjerimin e funksionalitetit.
Modeli përsëritës, përveç fazave kryesore, dallon dy grupe të tjera procesesh: punë (menaxhimi i kërkesave, analiza dhe dizajni, zbatimi, testimi, vendosja) dhe ndihmës (menaxhimi i konfigurimit dhe ndryshimit, projekti dhe procesi). Numri dhe natyra e proceseve ndryshojnë në varësi të nevojave të zhvilluesit, ato gjithashtu mund të kenë ciklet e tyre, të cilat as domosdoshmërisht nuk korrespondojnë me fazat kryesore. Megjithatë, flukset e punës rezultojnë gjithmonë në krijimin e versioneve të produktit.
Një model përsëritës, si një model spirale, bën të mundur menaxhimin me sukses të rreziqeve. Nëse gjatë punës për versionin tjetër përcaktohet se kostot e punës për zbatimin e funksionalitetit të kërkuar janë shumë të larta, atëherë tejkalimet dhe afatet buxhetore mund të shmangen duke ndërlidhur prioritetet e zhvillimit dhe kostot e punës në fillim të çdo përsëritjeje. Kështu, ky model është i përshtatshëm për shumicën e llojeve të projekteve softuerike, por avantazhet e tij janë veçanërisht të dukshme kur punoni në produkte të destinuara për hyrje në tregun e lirë, për shkak të fokusit fillestar në lëshimin e versioneve të njëpasnjëshme.
Standardi më i famshëm dhe më autoritar i cilësisë duhet të konsiderohet Modeli i Maturitetit të Kapacitetit (CMM) - një model për vlerësimin e nivelit të pjekurisë së proceseve të zhvillimit së bashku me derivatet e tij. Ai u krijua nga SEI (Instituti i Inxhinierisë së Softuerit), i cili financohet nga Departamenti i Mbrojtjes i SHBA dhe është një njësi strukturore e Universitetit Carnegie Mellon. Versioni i parë zyrtar i standardit u lëshua në 1993, megjithëse puna për të filloi shumë më herët - dispozitat e tij kryesore u botuan që në vitin 1986. Suksesi i CMM ishte i paracaktuar nga disa faktorë. Ky standard ishte një nga të parët, fillimisht duke marrë parasysh specifikat e zhvillimit të softuerit. Doli të ishte mjaft e thjeshtë dhe transparente si për të kuptuar ashtu edhe për përdorim, dhe rregullonte "çfarë", dhe jo "si" të bëni, dhe për këtë arsye ishte i përshtatshëm për modele të ndryshme të ciklit jetësor, metodologjitë e zhvillimit dhe nuk vendosi asnjë kufizim në dokumentacion. standardet, mjetet, mjedisi dhe gjuhët e përdorura në projekte. Dhe, ndoshta, faktori kryesor që paracaktoi popullaritetin e CMM ishte bashkëpunimi i SEI me Departamentin e Mbrojtjes së SHBA, që de facto nënkuptonte përdorimin e standardit në zbatimin e projekteve të porositura nga ky departament.
Modeli CMM (tabela 1) parashikon pesë nivele maturimi, secila prej të cilave korrespondon me disa fusha kyçe të procesit (Zonat kryesore të procesit, KPA).
Tabela 1 - Modeli HMM
|
Emri i nivelit |
Fushat kryesore të procesit |
|
1 - Fillestar |
Nëse organizata është në këtë nivel, atëherë nuk ka fusha kyçe të procesit për të |
|
2 - Të përsëritura |
Menaxhimi i konfigurimit të softuerit. Sigurimi i cilësisë së produkteve softuerike. Menaxhimi i kontratave të kontraktorëve. Kontrolli i progresit të projektit. Planifikimi i projekteve softuerike. Menaxhimi i Kërkesave |
|
3 - Përcaktuar |
Vlerësimet e ekspertëve. Koordinimi i ndërveprimeve ndërmjet ekipeve të projektit. Inxhinieria e produkteve softuerike. Menaxhimi i integruar i softuerit. Programi i trajnimit të stafit. Përkufizimi i procesit organizativ. Fusha e procesit organizativ |
|
4 - Menaxhuar |
Menaxhimi i cilësisë së softuerit. Kontrolli i procesit bazuar në metoda sasiore |
|
5 - Optimizuar |
Menaxhimi i ndryshimit të procesit. Menaxhimi i ndryshimeve teknologjike. Parandalimi i defekteve |
Ndarja në nivele dhe përcaktimi i AKP-së për secilën prej tyre mundëson zbatimin konsistent të MKM-së, duke përdorur standardin si udhëzues, i cili mund të sigurojë përmirësim të vazhdueshëm në procesin e zhvillimit.
Standardi CMM doli të ishte shumë i suksesshëm, dhe më pas një seri e tërë standardesh u krijuan mbi bazën e tij, dhe mori një emër të ri - SW-CMM (Modeli i maturimit të aftësisë për softuer), duke pasqyruar më saktë pozicionin e tij në një pozicion mjaft të madh. familja e standardeve.
Megjithatë, zbatimi praktik i standardeve të serisë CMM ka treguar se ato nuk ofrojnë sukses të pakushtëzuar në zhvillimin e softuerit. Këto standarde nuk ishin të koordinuara mirë me njëra-tjetrën - zbatimi i njëkohshëm i modifikimeve të ndryshme të CMM mund të ishte mjaft sfidë dhe çoi në hutim të specialistëve të organizatave që u përballën me të.
Gjithashtu, një problem i rëndësishëm i CMM është nevoja për të "lidhur" të gjitha proceset. Nëse një organizatë po përpiqet të certifikojë në një nivel të caktuar, atëherë ajo duhet të sigurojë që niveli i duhur të zbatohet në të gjitha proceset e saj. Edhe nëse specifikat, metodologjia ose veçoritë e zhvillimit nuk kanë procese të caktuara për t'u kryer, certifikimi e kërkon këtë.
Një problem tjetër është shkaktuar nga pozicioni që kanë marrë standardet CMM në industrinë moderne të softuerit. Meqenëse një organizatë me një nivel të lartë në përputhje me CMM duhet të sigurojë performancë më të lartë të produktit softuerik sesa ato të certifikuara në nivele më të ulëta, standardi ka filluar të përdoret si një kriter përzgjedhjeje për pjesëmarrjen në tenderat e zhvillimit të softuerit ose projektet e kontraktimit.
Kjo situatë është bërë e mundur për shkak të mangësive të procesit të certifikimit. Jo e gjithë organizata në tërësi i nënshtrohet certifikimit, por vetëm një projekt specifik. Asgjë nuk e pengon një organizatë që të krijojë një projekt "demonstrimi" që plotëson të gjitha kërkesat e niveleve të larta të standardit CMM, të marrë nivelin e duhur të certifikimit dhe të deklarojë se të gjitha produktet përmbushin një nivel të tillë të standardit.
Standardi i ri SEI - Capability Maturity Model Integrated (CMMI) - është një model i integruar për vlerësimin e nivelit të pjekurisë së proceseve të zhvillimit. Standardi CMMI u krijua fillimisht në atë mënyrë që të kombinojë opsionet ekzistuese CMM dhe të eliminojë çdo kontradiktë në zbatimin e tij praktik në fusha të ndryshme të veprimtarisë së kompanive të teknologjisë së lartë.
Për të eliminuar nevojën për të "përafruar" proceset e organizatës dhe për t'u përshtatur më shumë me nevojat e saj të biznesit, dhe jo anasjelltas, standardi CMMI ka dy forma prezantimi - klasike, shumë nivele, që korrespondon me CMM, dhe e reja, e vazhdueshme. Forma e vazhdueshme e prezantimit nuk merr në konsideratë nivelet e pjekurisë (Nivelet e Maturitetit), por Nivelet e Aftësisë, të cilat vlerësohen për zona të veçanta të procesit (Zonat e procesit, PA).
Tabela 2 jep një hartë të niveleve të pjekurisë së standardit CMM, si dhe nivelet e pjekurisë së prezantimit të shtresëzuar CMMI dhe nivelet e aftësisë së prezantimit të vazhdueshëm CMMI.
Tabela 2 - Pajtueshmëria me nivelet e maturimit të standardeve CMM, CMMI
SEI po largohet nga CMM dhe po promovon në mënyrë aktive CMMI në këmbim, duke premtuar se do të forcojë kontrollin mbi procesin e certifikimit, do të ulë kostot dhe do ta bëjë atë më tërheqës për organizatat e vogla; sigurimi i përputhshmërisë me standardet ISO.
Në kushtet moderne, prania e një certifikate të një niveli të caktuar CMM / CMMI nuk është një faktor aq i rëndësishëm sa ishte disa vite më parë, dhe pranohet pa pyetje shtesë, përveç ndoshta në projektet e kryera me urdhër të qeverisë.
Standardi ISO/IEC 15504 synon të vlerësojë procesin e zhvillimit të sistemeve të informacionit, në veçanti të softuerit. Fillimisht u krijua për të qenë kryesisht në përputhje me standardet e industrisë për vlerësimin e procesit të zhvillimit të softuerit. Është kjo kërkesë që përcaktoi ngjashmërinë e standardit me parimet themelore të CMM / CMMI.
Modeli i pjekurisë së procesit të zhvillimit të softuerit (CMM) i zhvilluar nga Instituti i Inxhinierisë së Softuerit në Universitetin Carnegie Mellon sugjeron pesë nivele pjekurie (Tabela 3). Ai i ndihmon organizatat të rrisin pjekurinë e proceseve të tyre të zhvillimit të softuerit dhe organizatat mund të vlerësohen dhe akreditohen në këto nivele.
Tabela 3 - Nivelet e pjekurisë së zhvillimit të softuerit
|
Niveli 1 - niveli i hyrjes |
Procesi i zhvillimit të softuerit është spontan dhe vetëm disa procese janë të rregulluara. Suksesi i zhvillimit mund të varet nga punonjësit individualë. |
|
Niveli 2 - niveli i përsëritshmërisë |
Krijoi proceset kryesore të menaxhimit të projektit për të gjurmuar kostot, orarin dhe funksionalitetin. |
|
Niveli 3 - niveli i rregullimit |
Procesi i zhvillimit të softuerit është i dokumentuar, i standardizuar dhe i integruar me procesin standard të zhvillimit të softuerit të organizatës për operacionet e menaxhimit dhe zhvillimit. Të gjitha projektet përdorin një proces të standardizuar. |
|
Niveli 4 - niveli i menaxhimit |
Metrikat e detajuara të procesit të zhvillimit të softuerit dhe cilësisë së produktit janë mbledhur për të ndihmuar në kuptimin dhe menaxhimin e procesit dhe produkteve. |
|
Niveli 5 - niveli i optimizimit |
Optimizimi i vazhdueshëm i procesit sigurohet nga reagimet sasiore nga procesi dhe nga idetë dhe teknologjitë inovative pilot. |
Kështu, modelet dhe metodat moderne të përdorura në projektet reale të zhvillimit të softuerit janë shumë të ndryshme. Secila prej tyre ka avantazhet e veta, të cilat manifestohen në kushtet e duhura. Edhe modeli i vjetëruar i ujëvarës është krejtësisht i përshtatshëm për disa projekte. Çdo proces ka gjithashtu një numër karakteristikash që kufizojnë fushën e përdorimit efektiv të tij. Kjo situatë është mjaft tipike për zhvillimin e softuerit, ku tashmë janë grumbulluar shumë teknologji dhe teknika, por nuk ka asnjë metodë universale që është optimale për çdo detyrë.
Përpara se të jap një pasqyrë të procesit të zhvillimit që është zhvilluar si rezultat i akumulimit të përvojës gjatë viteve të fundit, do të doja të bëja disa shpjegime të përgjithshme që më duken thelbësore.Unë kam punuar në IT për 15 vitet e fundit, megjithëse programimin e kam filluar shumë më herët. Fokusi im kryesor si arkitekt sistemesh ka qenë organizimi i zhvillimit të softuerit, zhvillimi i koncepteve dhe arkitekturës së nivelit të lartë dhe mbikëqyrja e zbatimit të konceptit gjatë gjithë projektit. Përveç menaxhimit të zhvillimit të softuerit dhe krijimit të arkitekturës, herë pas here merrem me zgjidhjen e problemeve komplekse teknike dhe me shkrimin e disa seksioneve kritike të kodit që kërkojnë jo vetëm njohuri të gjuhës dhe mjedisit të zhvillimit, por edhe organizimin e tyre të brendshëm, ndonjëherë duke sjellë të pakëndshme. surpriza.
Projektet me të cilat punoj janë më shpesh të lidhura me zhvillimin e softuerit me porosi ose investimi. Më është dashur të punoj edhe me softuer të integruar dhe programe të përqendruara në lëshimin e "hiteve" (të cilat, me dorën e lehtë të Joel Spolsky, më tej i quaj softuer lojrash, megjithëse në fakt disa projekte lojrash janë më afër projekteve investuese).
Softueri i personalizuar mund të jetë për një klient të brendshëm ose të jashtëm. Klienti merr të drejta ekskluzive për sistemin e zhvilluar dhe puna për zhvillimin e sistemit mund t'i transferohet një kontraktori tjetër në të ardhmen.
Ndryshe nga programet me porosi, puna në softuerin e investimeve kryhet nga vetë kontraktori me paratë e një investitori të brendshëm ose të jashtëm. Si rregull, të drejtat për kodin e sistemit i mbeten zhvilluesit, gjë që stimulon punën e vazhdueshme për të përmirësuar produktin e tyre dhe lëshimin e vazhdueshëm të versioneve me funksionalitet më të avancuar.
Firmware vjen me harduerin dhe është, përafërsisht, i papërmbajtshëm, pasi tërheqja e një grupi pajisjesh nga prodhuesi është një biznes shumë i kushtueshëm dhe për këtë arsye i jashtëzakonshëm.
Zhvillimi i hiteve të lojës gjithashtu praktikisht nuk përmban një fazë shoqëruese. Për më tepër, përdoruesit e programeve të lojërave, edhe kur përballen me një gabim në lojë, shumë rrallë shkarkojnë një version të përditësuar. Prandaj, zhvillimi i lojës, si rregull, ka ekonominë e vet dhe procesin e vet të zhvillimit.
Klientët tanë janë autoritetet, organizatat e mëdha shtetërore dhe tregtare dhe, natyrisht, ne vetë. Prandaj, për sa i përket softuerit të personalizuar, shpesh ka një ndryshim në procesin tonë midis zhvillimit të produkteve për klientët e brendshëm dhe të jashtëm. Unë do të theksoj disa nga nuancat në këtë artikull. Niveli i formalizimit të marrëdhënieve me klientin ndryshon shumë nga projekti në projekt. Në përgjithësi, sa më i madh të jetë buxheti i projektit, aq më i lartë është formaliteti. Konsumatori shtetëror ose ndërmarrjet e mëdha tregtare (veçanërisht me pjesëmarrje shtetërore) zakonisht kanë kufizime legjislative në formimin, vendosjen e një porosie dhe pranimin e rezultateve të punës. Një kufizim tjetër i organizatave të mëdha është fakti se stafi i tyre, i cili është burimi i kërkesave dhe përdoruesi kryesor i sistemeve tona, ka disponueshmëri shumë të kufizuar për performuesit, qoftë edhe për shkak të zënërisë së tyre. Megjithatë, për organizatat e vogla, niveli i formalizimit bie dhe ndonjëherë shkon në ekstremin e kundërt, ku ekziston një nivel i pamjaftueshëm i përgjegjësisë së klientit brenda projektit.
Ana tjetër e projekteve tona me porosi janë kërkesat e larta për funksionalitet. Kjo është një ngarkesë e lartë në të gjitha sistemet, një shpërndarje e madhe gjeografike dhe kërkesa të larta për saktësinë e llogaritjeve me një afat kohor shumë të kufizuar. Shpesh në projektet tona ka elemente të punës kërkimore dhe kërkimit krijues që synojnë zgjidhjen e problemeve jo të parëndësishme të projektimit. Ndonjëherë ne duhet të kombinojmë metodologji të ndryshme brenda të njëjtit proces zhvillimi, për shembull, duke futur një ose më shumë faza të scrum pothuajse të pastër në një proces të përbashkët afër RUP, duke gjeneruar diçka si një projekt brenda një projekti. Kjo na lejon të mbajmë të ulët angazhimin e përdoruesve për shkak të natyrës së projektit, me fleksibilitet zhvillimi përballë pasigurisë së kërkesave të larta. Në këtë drejtim, është faza përgatitore ajo që është e rëndësishme për mua, gjatë së cilës ju mund të zgjidhni metodologjinë e nevojshme dhe të ndërtoni një proces zhvillimi optimal. Përshkrova një nga shembujt e përdorimit të një metodologjie të shkathët në artikullin "Aplikimi i shkathtësisë kur zhvillon një projekt për një klient qeveritar".
Si shembull i punës në një projekt investimi, mund të citoj zhvillimin e një sistemi të integruar sigurie, të cilin e krijuam si një produkt "të kuti". Nën udhëheqjen time, katër versione të këtij sistemi u lëshuan me radhë, përdoruesit e të cilëve ishin një sërë organizatash tregtare dhe qeveritare, duke përfshirë Bashkinë e Moskës, AFK Sistema, bankat, qendrat e biznesit dhe, natyrisht, zyrën tonë. Versioni i parë nuk ishte shumë i suksesshëm, por ne kishim një strategji zhvillimi që na lejoi të kapnim me sukses tregun dhe t'i mbijetonim kohërave të vështira të krizës. Përvoja e punës në këtë dhe disa projekte të tjera investimi është marrë gjithashtu parasysh gjatë formësimit të procesit të zhvillimit që përdor.
Procesi ynë është një sekuencë e fazave të caktuara. Klasifikimi i softuerit të dhënë nga unë është bërë vetëm për të treguar ndryshimin e mundshëm në organizimin e zhvillimit të mjeteve të ndryshme softuerike. Duke bërë një pasqyrë të procesit të zhvillimit, unë do të fokusohem vetëm në ndryshimet në vetë procesin në lidhje me llojet e ndryshme të softuerit. Sidoqoftë, duhet të kujtojmë se ndryshimet midis proceseve të zhvillimit të llojeve të ndryshme të softuerit janë shumë më të thella, kështu që kur planifikoni secilën fazë, këto nuanca duhet të merren parasysh.
Është e rëndësishme të kuptohet se kalimi i procesit nga një fazë në tjetrën nuk ka një kufi të qartë. Si rregull, puna e fazës së ardhshme fillon pasi përfundon 80-90% e punës në fazën e mëparshme. Kjo është veçanërisht e vërtetë për zhvillimin e kërkesave, kur në disa raste heqja e pasigurisë ndodh vetëm në fund të projektit. Natyrisht, prania e një pasigurie të tillë në projekt është një rrezik i konsiderueshëm dhe duhet të jetë nën kontroll të vazhdueshëm.
Procesi i personalizuar i zhvillimit të softuerit
Le të fillojmë rishikimin e procesit të zhvillimit me rastin më të zakonshëm - zhvillimin e softuerit me porosi. Diagrami i procesit është paraqitur në Figurën 1.Figura 1. Procesi i zhvillimit të softuerit personal.
Puna për projektin fillon me fazën përgatitore. Qëllimi i fazës është të krijojë një koncept të sistemit të ardhshëm bazuar në propozimet e klientit dhe, bazuar në këtë koncept, të vlerësojë rëndësinë dhe fizibilitetin e projektit. Nëse vendimi për tërheqjen e kontraktorit merret nga klienti mbi baza konkurruese, atëherë faza paraprake është në fakt faza e përgatitjes së një kontraktori të mundshëm për tenderin, duke përfshirë formimin e dokumentacionit të nevojshëm.
Nuk ka nevojë të humbni kohë dhe burime për një projekt, koncepti i të cilit njihet si i padeklaruar ose i parealizueshëm. Ky projekt duhet të përfundojë. Në disa raste, kërkohet një punë përsëritëse me klientin për të korrigjuar konceptin e projektit, derisa të arrihet ose një ekuilibër i pranueshëm i kërkesave të klientit dhe kostove të kontraktorit, ose derisa të merret një vendim për të kufizuar punën.
Një projekt, koncepti i të cilit duket i pranueshëm për zbatim, hyn në fazën e zhvillimit të kërkesave. Në këtë fazë, kontraktori duhet të formojë një listë të të gjitha nevojave të qarta dhe të fshehura të klientit. Shpesh rezulton se klienti ose nuk ka vendosur për nevojat e tij, ose nevojat e tij janë në konflikt me njëra-tjetrën, me aftësitë e klientit ose me aftësitë e kontraktorit. Objektivat e skenës janë të identifikojë të gjitha nevojat e fshehura, të zgjidhë konfliktet e kërkesave, të formojë një zgjidhje teknike gjithëpërfshirëse dhe të analizojë fizibilitetin e zgjidhjes së përgatitur.
Ndonjëherë sqarimi i kërkesave çon në një rishikim të konceptit të projektit. Nëse, pas sqarimit të të gjitha kërkesave, nuk është e mundur të gjendet një zgjidhje teknike e pranueshme, projekti duhet të kufizohet ose të shtyhet për ca kohë në pritje të rrethanave më të pranueshme.
Nëse gjendet një zgjidhje teknike, interpretuesi vazhdon të zhvillojë arkitekturën e sistemit të ardhshëm. Qëllimi i skenës është të përcaktojë arkitekturën logjike dhe fizike të nivelit të lartë që mbulon plotësisht të gjitha kërkesat e klientit. Gjatë zhvillimit të arkitekturës, koncepti, kërkesat dhe zgjidhja teknike paraprake rishikohen dhe rafinohen, gjë që bën të mundur parandalimin e rreziqeve më të rrezikshme.
Pas përfundimit të dizajnit të arkitekturës, është e nevojshme të rishikohen përsëri parametrat kryesorë të projektit dhe të vendoset nëse kontraktori është në gjendje të përfundojë projektin. Është e dobishme në fazën e zhvillimit të arkitekturës të braktisësh funksionet e panevojshme dhe shumë të rënda. Optimizimi i zgjidhjes arkitekturore shpesh ndihmon për t'u përshtatur në parametrat e pranueshëm të projektit. Në raste të tjera, kërkohet një reduktim më radikal i funksionalitetit të sistemit që po zhvillohet. Sidoqoftë, edhe ndalimi i projektit në këtë fazë, nëse ndodh për arsye të mira, duhet të perceptohet si një fitore: vazhdimi i punës në këtë rast mund të çojë vetëm në humbje edhe më të mëdha.
Nëse është gjetur një ekuilibër dhe është krijuar një arkitekturë e pranueshme e sistemit, kontraktori mund të kalojë në zbatimin dhe dorëzimin e sistemit. Zbatimi mund të bëhet në një ose më shumë faza. Për projekte të vogla, shpërndarja në një fazë e të gjithë funksionalitetit të sistemit mund të jetë mjaft e pranueshme. Megjithatë, sa më i madh të jetë projekti, aq më të larta janë varësitë e nënsistemeve brenda sistemit që krijohet. Në këto kushte, zbatimi duhet të ndahet në disa faza në mënyrë që në fund të çdo faze ekipi i zhvillimit të ketë një produkt gati për dorëzim. Në të njëjtën kohë, funksionaliteti më i rëndësishëm, themelor duhet të zhvillohet në një fazë të hershme dhe shtesat që funksionojnë në krye të këtyre komponentëve bazë duhet të zbatohen më vonë. Në këtë rast, gabimet më të rrezikshme për sistemin do të korrigjohen në fazat e para dhe rreziku që funksionaliteti i aplikimit të sistemit të bazohet në një bazë të paqëndrueshme do të reduktohet ndjeshëm.
Pas dorëzimit të një sistemi plotësisht të kompletuar, një projekt softueri i personalizuar zakonisht kalon në fazën beta. Qëllimi i kësaj faze është të kontrollojë cilësinë e sistemit të zhvilluar në kushte reale operimi. Si rregull, në këtë fazë, interpretuesi, së bashku me klientin, mat metrikat sasiore që bëjnë të mundur përcaktimin e cilësisë së sistemit të krijuar. Fillimisht kontrollohen karakteristikat funksionale të cilësisë, më pas ato jofunksionale. Nëse ka mospërputhje, interpretuesi korrigjon kodin e sistemit.
Një sistem plotësisht i korrigjuar dhe i akorduar është vënë në funksionim komercial. Si rregull, kontraktori duhet të shoqërojë sistemin, të paktën gjatë periudhës së garancisë. Mospërputhjet e identifikuara duhet të korrigjohen. Përdoruesit dhe personeli i shërbimit ndaj klientit duhet të marrin mbështetje të menjëhershme këshilluese.
Më në fund, vjen momenti kur sistemi nuk i përshtatet klientit për çfarëdo arsye. Sistemi tani është në proces dekomisionimi. Sidoqoftë, për softuerin me porosi, kjo fazë nuk është gjithmonë e rëndësishme, pasi klienti mund të përdorë të drejtat e tij ekskluzive për sistemin dhe ta largojë kontraktorin nga mirëmbajtja dhe zhvillimi i mëtejshëm i sistemit edhe para se të bëhet i parëndësishëm.
Çdo projekt përfundimisht përfundon. Faza e përfundimit të projektit synon të analizojë rezultatet, të bëjë ndryshime në procesin e zhvillimit bazuar në përvojën e fituar dhe të plotësojë bazën e njohurive të zhvilluesve me zgjidhje të reja efektive dhe paralajmërime, si dhe me komponentë të rinj jashtë raftit që mund të përdoren në projektet e ardhshme.
Mbetet të theksohen dy faza të tjera të procesit të zhvillimit. Ndodh që rrethanat të mos lejojnë vazhdimin e zbatimit të projektit, por rezultatet e punës së bërë tregojnë se projekti mund të ketë një të ardhme. Është e parakohshme të mbyllet një projekt i tillë. Prandaj, në vend të ndalimit të plotë të punës, kontraktori mund të pezullojë përkohësisht aktivitetet e projektit, duke rregulluar rezultatet e arritura. Sapo të lejojnë rrethanat, projekti mund të rifillojë duke ripërtërirë infrastrukturën, duke i kthyer zhvilluesit në projekt dhe duke rivendosur gjendjen e projektit. Megjithatë, është e rëndësishme që të rifillohet puna nga pika në të cilën projekti u ndërpre duke ri-audituar rezultatet e arritura.
Procesi i zhvillimit të softuerit investues
Procesi i zhvillimit të softuerit të investimeve është i ndryshëm në atë që puna mund të vazhdojë njëkohësisht në disa versione të produktit në të njëjtën kohë: ndërsa versioni i parë po mirëmbahet, i dyti tashmë është duke u zbatuar dhe kërkesat janë duke u formuluar për të tretën. Procesi është paraqitur në Figurën 2.
Figura 2. Procesi i zhvillimit të softuerit investues.
Siç shihet lehtë, në zhvillimin e softuerit investues ndodhin të njëjtat faza që u diskutuan më lart për procesin e zhvillimit të softuerit me porosi. Por ndryshimi është se fazat nuk zbatohen për të gjithë produktin, por për një version të veçantë të produktit. Përjashtim është faza e përfundimit të projektit: projekti nuk mund të përfundojë ndërsa të paktën një version i produktit është duke u punuar.
Kushtojini vëmendje fillimit të punës në versionin tjetër të produktit. Ky moment vjen sapo ka përfunduar faza e krijimit të arkitekturës së versionit aktual të zhvillimit. Para kësaj, kërkesat dhe fazat e arkitekturës zakonisht diskutojnë se cilat veçori duhet të zbatohen në versionin aktual dhe cilat duhet të zhvendosen në të ardhmen. Dhe vetëm kur kërkesat për versionin aktual formulohen, rishikohen dhe konfirmohen nga arkitektura e sistemit, ka kuptim të mendosh për versionin tjetër.
Përveç kësaj, pas zhvillimit të arkitekturës, si rregull, analistët dhe arkitektët e projektit kanë njëfarë lirie veprimi, pasi barra kryesore bie mbi programuesit gjatë fazave të dorëzimit. Kjo liri mund të përdoret për të përpunuar konceptin dhe kërkesat për versionin e ardhshëm.
Në parim, ju mund të shtyni fillimin e punës në versionin tjetër për një datë të mëvonshme. Për shembull, është mjaft e pranueshme që fillimisht të futni versionin aktual në funksionimin eksperimental apo edhe komercial, dhe vetëm pas kësaj të filloni punën në versionin tjetër. Por duhet të mbani mend se një zgjidhje e tillë nuk është e zbatueshme në rastin e konkurrencës së lartë: ata thjesht do t'ju kalojnë përpara dhe do t'ju shtrydhin jashtë tregut. Vendimi duhet të merret bazuar në gamën e plotë të rrethanave që ndikojnë në biznesin tuaj.
Duke folur për procesin e zhvillimit të softuerit të investimeve, duhet të kuptoni se puna në disa versione ka një sërë ndërvarësish të qarta dhe të fshehura midis degëve paralele të procesit.
Së pari, korrigjimet për mospërputhjet e identifikuara në një version të mëparshëm duhet t'i bëhen versionit ku ato u zbuluan dhe të gjitha versionet e mëvonshme, duke përfshirë ato në zhvillim. Kjo vlen jo vetëm për kodin e programit, por edhe për të gjitha objektet e tjera të projektit: dokumentacionin teknik dhe të përdoruesit, sistemin e ndihmës, vlerësimet dhe planet e punës, etj. Për më tepër, korrigjimet duhet të bëhen menjëherë, pasi nuk do të jeni në gjendje të ulni koston e korrigjimeve, por nëse korrigjimet nuk bëhen menjëherë, kostoja e tyre në fazat e mëvonshme mund të rritet me dhjetëra dhe madje qindra herë.
Së dyti, për punë paralele në disa versione, nevojitet një infrastrukturë e veçantë projekti, duke përfshirë organizimin e kontrollit të versionit të kodit dhe dokumentacionit, kontrollin e punës dhe mospërputhjes, shërbimet automatike të ndërtimit dhe testimit, etj. Puna në një version të një produkti nuk duhet të lejohet të bllokojë ekzekutimin e detyrave në versionet e tjera vetëm sepse infrastruktura e projektit nuk lejon ekzekutimin e dy proceseve të ndërtimit në të njëjtën kohë për versione të ndryshme të produktit.
Vëmendje e veçantë duhet t'i kushtohet grupeve të testimit: ato duhet të vendosin të gjitha versionet e produktit që janë lëshuar më herët (të paktën ato versione që mbështeten) dhe të gjitha versionet që janë duke u zhvilluar aktualisht.
Së treti, të njëjtët pjesëmarrës mund të përfshihen në punën në disa versione në të njëjtën kohë. Ekziston një rrezik i lartë që një person kyç mund të ngecë në punën në një version të programit dhe të lejojë tejkalime të konsiderueshme kohore në detyrat që lidhen me një version tjetër.
Së katërti, është situata e kundërt, kur stafi që punon në një version nuk di asgjë se çfarë vendimesh merren si pjesë e punës për versionin tjetër. Një pjesë e problemit hiqet nëse korrigjimet në të gjithë dokumentacionin dhe kodin shpërndahen menjëherë në të gjitha versionet e mëvonshme, siç e përmenda më lart. Por çështja nuk duhet të kufizohet vetëm në korrigjime. Është e nevojshme që ekipi që punon në një version të kuptojë pse janë marrë vendime të caktuara kur punohet në një version tjetër. Kjo kërkon një bazë njohurish për zhvilluesit - një sistem informacioni të veçantë që duhet të përshkruajë të gjitha problemet që kanë hasur zhvilluesit kur punojnë në një version të veçantë të produktit dhe si t'i zgjidhin këto probleme. Baza e njohurive duhet të dërgojë njoftime për të gjithë pjesëmarrësit e projektit kur të mbërrijnë të dhënat e reja. Është e pamundur të lejosh që ndërveprimi i dy ekipeve që punojnë në versione të ndryshme të të njëjtit produkt të marrë rrjedhën e tij.
Procesi i zhvillimit të softuerit të integruar
Siç u përmend më lart, softueri i integruar ndryshon nga softueri i personalizuar në atë që është jashtëzakonisht i vështirë për t'u mirëmbajtur.Le të themi se keni lëshuar softuer për frigoriferë. Pasi softueri i dorëzohet prodhuesit, dhjetëra mijëra pajisje fillojnë të shpërndahen në mbarë botën dhe nuk e keni idenë se ku do të përfundojnë. Dhe nëse njëri nga frigoriferët dështon për shkak të fajit të softuerit tuaj, atëherë është më e lehtë të paguash një gjobë sesa ta kthesh frigoriferin në fabrikë dhe të kryesh diagnostifikimin. Sigurisht, është e mundur të trajnohen inxhinierë për shitësit që mund të kryejnë diagnostikime në vend dhe të zëvendësojnë firmware-in e sistemit tuaj, por gjithsesi është shumë e shtrenjtë.
Kështu, gjatë zhvillimit të softuerit të integruar, lindin disa kufizime të rëndësishme menjëherë.
Së pari, dorëzimi kryhet brenda kornizës së vetëm një faze: askush nuk do të ndërtojë një program gjysmë pune në pajisje.
Së dyti, pas dorëzimit, duhet t'i kushtoni vëmendje të veçantë cilësisë së programit, pasi që nga momenti kur futet në kutinë e hekurit, do të jetë shumë e vështirë ta ndryshoni atë. Vëmendje e veçantë duhet t'i kushtohet fazës së funksionimit pilot, kur programi zbatohet në një grup të kufizuar pajisjesh dhe këto pajisje i nënshtrohen testeve gjithëpërfshirëse në mënyra të ndryshme funksionimi. Ju duhet të mbledhni sa më shumë informacion që të jetë e mundur në lidhje me sjelljen e sistemit tuaj, të analizoni këtë informacion dhe të rafinoni softuerin.
Së treti, kur një pajisje me softuerin tuaj ka hyrë në seri, ju keni shumë pak mundësi për të korrigjuar gabimet. Në fakt, rregullime të tilla janë të mundshme vetëm në rast të softuerit me defekt që çon në mosfunksionimin e të gjithë grupit të pajisjeve, për shkak të së cilës prodhuesi do të detyrohet të tërheqë këtë grumbull dhe ju do të merrni një pikë të zezë të madhe në reputacionin tuaj .
Së fundi, së katërti, nuk ka asnjë fazë dekomisionimi për softuerin e integruar. Programi thjesht hidhet larg me pajisjen. Prandaj, sapo të skadojë periudha e garancisë për një grup pajisjesh në të cilat funksionon softueri juaj, mund të vazhdoni të mbyllni projektin.
Procesi i zhvillimit të firmuerit është paraqitur në Figurën 3.
Figura 3 Procesi i zhvillimit të softuerit të integruar.
Procesi i zhvillimit të lojës
Softueri i lojrave u veçua nga unë për shkak të specifikave të prodhimit dhe funksionimit të tyre. Biznesi i softuerit të lojrave bazohet në lëshimin e hiteve. Një goditje e suksesshme paguan koston e krijimit të disa lojërave që kalojnë pa u vënë re nga përdoruesit. Prandaj, procesi i zhvillimit të një loje është i ndërlidhur me proceset e zhvillimit të lojërave të tjera.Një faktor tjetër që e bën prodhimin e lojës të dallohet është fakti që loja është interesante për përdoruesin ose derisa të ketë kaluar nivelin e fundit ose derisa të ketë një gabim fatal. Kjo do të thotë që ai nuk do të blejë versionin e dytë të lojës dhe as ta shkarkojë atë falas vetëm për të rregulluar disa gabime.
Këta faktorë ndikojnë në procesin e zhvillimit të softuerit të lojrave. Procesi është paraqitur në Figurën 4.
Figura 4. Procesi i zhvillimit të softuerit të lojës.
Duhet të theksohen veçoritë e mëposhtme të procesit të zhvillimit të softuerit të lojrave.
Para së gjithash, në prodhimin e lojërave, cilësia e konceptit është jashtëzakonisht e rëndësishme. Nëse koncepti i lojës nuk ju lejon të krijoni një goditje, atëherë puna e mëtejshme është e kotë. Situata kur shumica e projekteve përfundojnë në fazën përgatitore është tipike për zhvillimin e softuerit të lojës.
Kërkesat dhe zhvillimi i arkitekturës për softuerin e lojërave shpesh ripërdor mësimet e nxjerra nga projektet e mëparshme. Në këtë drejtim, edhe faza e përfundimit të projektit merr peshë shtesë, kur të gjitha zhvillimet e dobishme duhet të regjistrohen në bazën e njohurive të zhvilluesve.
Dorëzimi i softuerit të lojrave bëhet brenda një faze të vetme. Edhe nëse fillimisht krijohet një bërthamë e caktuar, "motori" i sistemit të lojës, funksionimi i tij nuk mund të verifikohet pa zbatimin e të gjithë funksionalitetit të sistemit.
Nuk ka faza beta ose çaktivizimi për programet e lojërave. Lojërat menjëherë dalin në shitje dhe pas përdorimit, ato thjesht fshihen nga përdoruesi pasi humbasin interesin për to.
konkluzioni
Si pjesë e artikullit, u përpoqa të jap një pasqyrë të "nivelit të lartë" të procesit të zhvillimit të softuerit të aplikacionit. Secila fazë e procesit, natyrisht, ka nevojë për një diskutim të veçantë me shqyrtimin e detyrueshëm të veçorive të softuerit të zhvilluar.Vërej se diagrami i procesit i konsideruar këtu është rezultat i një përgjithësimi të përvojës sime personale në zhvillimin e mjeteve të ndryshme softuerike. Si çdo përgjithësim, skema ime është një abstraksion. Dhe, si çdo abstraksion, ai ka kufijtë e tij të zbatueshmërisë. Ju nuk mund ta aplikoni pa menduar këtë skemë në një projekt specifik. Është e rëndësishme të kuptohet se çdo projekt ka nuancat e veta që ndikojnë në organizimin e procesit të zhvillimit. Dhe për këtë arsye, për secilin projekt, skema e paraqitur këtu duhet të përshtatet, dhe në disa raste do të jetë e nevojshme të zhvillohet një qasje thelbësisht e ndryshme.
Fazat e zhvillimit të softuerit
Procesi i zhvillimit të softuerit mund të ndahet në faza (faza):
– zhvillimi i një modeli dhe zgjedhja e një metode zgjidhjeje;
– zhvillimi i një algoritmi për zgjidhjen e problemit;
– kodimi i algoritmit;
– përpilimi i programit;
– testimi i programit;
– krijimi i dokumentacionit;
- Mirëmbajtja dhe funksionimi.
Si rezultat i kësaj faze të punës, hartohet një dokument i quajtur "Detyra për zhvillimin e softuerit (kushtet e referencës)". Në të thuhet sa vijon:
- emri i detyrës. Jepet një përkufizim i shkurtër i problemit që do të zgjidhet, tregohet emri i paketës softuerike, një sistem programimi për zbatimin e tij dhe kërkesat e harduerit;
- përshkrim. Deklarata e problemit, qëllimi dhe qëllimi i problemit, vendi i tij dhe lidhjet me probleme të tjera, përmbajtja e funksioneve të përpunimit të informacionit hyrës gjatë zgjidhjes së problemit, kërkesat për shpeshtësinë e zgjidhjes së problemit përshkruhen në detaje.
– menaxhimi i mënyrave të funksionimit të programit. Janë formuluar kërkesat themelore për metodën e ndërveprimit të përdoruesit me programin (ndërfaqja përdorues-kompjuter).
- fut te dhenat. Përshkruhen të dhënat hyrëse, kufijtë në të cilët mund të ndryshojë, vlerat që nuk mund të marrë, etj., si dhe burimi i të dhënave, d.m.th. pajisjen me të cilën duhet të transferohen në program.
- prodhimi. Të dhënat e daljes përshkruhen, tregohet se në çfarë forme duhet të paraqiten - në formë numerike, grafike ose tekstuale, kufizime në kohën dhe saktësinë e informacionit të daljes, si dhe tregohet edhe pajisja për shfaqjen e këtyre të dhënave.
- gabime. Gabimet e mundshme të përdoruesit renditen kur punoni me programin (për shembull, gabimet e futjes së të dhënave, etj.). Tregohen metodat e diagnostikimit (në këtë rast, diagnostifikimi nënkupton zbulimin e gabimeve gjatë funksionimit të paketës softuerike) dhe mbrojtjen nga këto gabime në fazën e projektimit, si dhe reagimin e mundshëm të përdoruesit kur ai kryen veprime të gabuara dhe reagimi i kompleksit softuerik (kompjuterit) ndaj këtyre veprimeve.
- një shembull i funksionimit të paketës softuerike. Jepen një ose disa shembuj të funksionimit të paketës softuerike, mbi të cilat, në rastet më të thjeshta, kryhet korrigjimi dhe testimi i tij.
Zhvillimi i modelit dhe zgjedhja e metodës së zgjidhjes. Në këtë fazë, krijohet një model matematikor ose logjik i fenomenit të studiuar të botës reale. Në të njëjtën kohë, duhet të jetë në gjendje të formulojë në gjuhën e matematikës probleme specifike të fizikës, ekonomisë, teknologjisë etj. Pasi të përcaktohet modeli matematikor i problemit, është e nevojshme të zgjidhet një metodë për zgjidhjen e saj. Nëse detyra e programueshme është e natyrës llogaritëse, atëherë nxjerrja e të gjitha formulave të përdorura jepet me komente të hollësishme. Nëse detyra nuk është llogaritëse, atëherë jepet një përshkrim verbal i modelit logjik, për shembull, në formën e një plani veprimi.
Zhvillimi i një algoritmi për zgjidhjen e problemit. Në këtë fazë, formohet struktura e përgjithshme e paketës softuerike. Algoritmi – është një sistem rregullash të formuluara saktësisht që përcakton procesin e transformimit të të dhënave të vlefshme hyrëse (inputet e informacionit) në një rezultat të dëshiruar (informacion dalës) në një numër të kufizuar hapash.
Në procesin e zhvillimit të një algoritmi, mund të përdoren mënyra të ndryshme për përshkrimin e tij: shënime verbale, diagrame blloku, pseudokod, strukturograme, etj.
Një fjali që nuk është një fjali në një gjuhë programimi, megjithëse është shumë e ngjashme me atë që shkruajmë në këtë gjuhë programimi, quhet pseudokod . Pseudokodi shumë efektive në zhvillimin e logjikës së programit. Pasi logjika ju duket e drejtë, mund t'i kushtoni vëmendje të veçantë detajeve të përkthimit. pseudokod në një gjuhë të vërtetë programimi. Përdorni avantazhin pseudokodështë se ju lejon të përqendroheni në logjikën dhe strukturën e programit pa u shqetësuar për momentin se si këto ide përkthehen në gjuhën e makinës. Nëse duam të përmirësojmë programin, së pari duhet të përmirësohemi algoritmi!
Kodimi i algoritmit. Faza e kodimit (programimit) të algoritmeve konsiston në përkthimin e algoritmeve të zhvilluara për secilin modul programi në programe në një gjuhë programimi specifike. Rezultati i kësaj faze janë skedarët me tekstet burimore të programeve. Këta skedarë kanë natyrë tekstuale, vetëm ato përmbajnë tekste të shkruara në gjuhën e programimit (në rastin tonë, këto janë tekste të shkruara në gjuhën C).
Përpilimi i programit. Pasi të përfundojë kodimi (shkrimi i një programi në një gjuhë programimi) dhe kodi burimor i programit të futet në memorien e kompjuterit, programi kompilohet, d.m.th. përkthimi i tekstit burim në kodin e makinës. Ky proces kryhet nga një program i veçantë - një përpilues. Figura 1 tregon skemën për përgatitjen e programit të ekzekutueshëm.
Së pari, programi transferohet paraprocesor, e cila kryen direktivat të përfshira në tekstin e tij (për shembull, #include - përfshirja e një skedari në tekstin e programit).
Teksti që rezulton kalon në hyrje përpilues (Përpilues) , i cili nxjerr shenja (fjalë individuale), dhe më pas, bazuar në gramatikën e gjuhës, njeh shprehjet dhe operatorët e ndërtuar nga këto shenja. Në këtë rast, përpiluesi zbulon gabimet sintaksore dhe, në rast të mungesës së tyre, ndërton moduli i objektit.
lidhës, ose redaktori i lidhjes (Lidhës) , forma modul i ekzekutueshëm programet duke lidhur module të tjera objektesh me modulin e objektit, duke përfshirë ato që përmbajnë funksione të bibliotekës, të cilat aksesohen në çdo program. Pas përfundimit të suksesshëm të procesit, krijohet një skedar programi i ekzekutueshëm (një skedar me shtesën EXE).
Testimi i programit. Ekzistojnë dy lloje të testimit: autonome dhe komplekse. Gjatë testimit autonom, i nënshtrohen modulet individuale të softuerit që përbëjnë paketën e softuerit. Testimi gjithëpërfshirës konsiston në kontrollimin e të gjithë paketës së softuerit. Për testim, zgjidhen të dhëna të tilla fillestare për të cilat rezultati i ekzekutimit të programit dihet paraprakisht.
Krijimi i dokumentacionit. Dokumentacioni klasifikohet sipas qëllimit të tij dhe mund të ndahet në disa grupe: përshkrimi i aplikacionit, manuali i përdoruesit, manuali i programuesit.
Përshkrimi i aplikacionit- karakteristikat e përgjithshme të produktit softuer dhe fushëveprimi i tij, kërkesat për softuerin bazë, një grup pajisjesh përpunuese.
Udhëzues Përdorues– një përshkrim i detajuar i funksionalitetit dhe teknologjisë së punës me produktin softuerik për përdoruesin përfundimtar. Dokumentet e këtij lloji mund të lëshohen në formë të shtypur dhe (ose) "të ngulitura" në paketën e softuerit (në rastin e fundit, ndihma në formën e një aluzion thirret nga vetë përdoruesi gjatë funksionimit të paketës së softuerit).
Udhëzues për programuesështë menduar për zhvilluesit e softuerit dhe specialistët që do ta shoqërojnë atë. Ky udhëzues përfshin si dokumente kryesore:
Detyrë për zhvillimin e softuerit (kushtet e referencës);
Specifikim;
Tekstet burimore të komentuara (lista) të moduleve të programit dhe modulit të kontrollit;
Skema e ndarjes së kompleksit softuerik në module softuerike;
Skema e fluksit të të dhënave të paketës softuerike;
Skema e ndërveprimit të moduleve softuerike;
Planet dhe të dhënat për testimin e paketës softuerike;
Materiale të tjera që ilustrojnë projektin, për shembull: bllok diagramet e paketës së softuerit dhe modulet e softuerit.
Mirëmbajtja dhe funksionimi. Pas përfundimit të testimit të paketës softuerike, softueri vihet në funksion. Gjatë funksionimit, mund të jetë e nevojshme të shtoni funksione të reja në paketën e softuerit, të eliminoni gabimet e gjetura gjatë funksionimit, etj. Kjo lloj pune me paketën softuerike gjatë funksionimit të saj quhet mirëmbajtje.
Ekziston një standard shtetëror që përcakton fazat e zhvillimit të programeve dhe dokumentacionit të softuerit për kompjuterë, komplekse dhe sisteme, pavarësisht nga qëllimi dhe qëllimi i tyre.
Procesi i zhvillimit të softuerit mund të ndahet në faza (faza) të paraqitura në Fig. 15.
Oriz. 15. Fazat e zhvillimit të softuerit
Puna në softuer fillon me përgatitjen e një dokumenti të quajtur "Detyra për zhvillimin e softuerit (termi i referencës)".
Vetëm kur zgjidhni problemet më të thjeshta të treguara në Fig. 15 hapa kryhen njëri pas tjetrit në rendin në të cilin shfaqen. Në përgjithësi, procesi i zhvillimit të softuerit kërkon një kthim të vazhdueshëm në fazat dhe ndryshimet e mëparshme. Në këtë drejtim, në Fig. 15, drejtkëndëshat me emrat e fazave lidhen jo vetëm me vija vertikale, por edhe me linja që sigurojnë një kthim nga çdo skenë në skenën e vendosur sipër saj. Kjo do të thotë që çdo hap mund të kryhet përsëri.
Detyrë teknike
Termat e referencës përfshijnë tre faza: 1) vërtetimin e nevojës për zhvillimin e një programi; 2) kryerja e punës kërkimore-shkencore; 3) zhvillimi dhe miratimi i termave të referencës.
Përpara se të vazhdojë me zhvillimin e specifikimeve teknike, klienti duhet të vendosë saktë detyrën. Deklarimi i problemit konsiston në krijimin e një modeli matematikor ose logjik të procesit ose fenomenit në studim. Këtu është e nevojshme të përcaktohet nëse zgjidhja e softuerit do të jetë e saktë. Mund të jetë më mirë të përdorni softuer të mirënjohur aplikimi (sistemet e menaxhimit të bazës së të dhënave, tabelat, etj.) ose thjesht ta zgjidhni problemin me disa copa letre dhe një laps. Nëse bëhet një zgjedhje në favor të zhvillimit të një programi të ri, atëherë është e nevojshme të përzgjidhen dhe të arsyetohen kriteret për efektivitetin dhe cilësinë e programit që po zhvillohet. Në rastin e zhvillimit të një pakete të madhe softuerike, nevoja për punë kërkimore është e vërtetuar.
Si rezultat i punës kërkimore, përcaktohen strukturat e të dhënave hyrëse dhe dalëse, bëhet një zgjedhje paraprake e metodave për zgjidhjen e problemit dhe vërtetohet mundësia themelore e zgjidhjes së problemit.
Zhvillimi dhe miratimi i termave të referencës përfshin:
Përcaktimi i kërkesave për programin;
Zhvillimi i një studimi fizibiliteti për zhvillimin e programit;
Përcaktimi i fazave, fazave dhe afateve të zhvillimit të programit dhe dokumentacionit për të;
Zgjedhja e gjuhëve të programimit;
Përcaktimi i nevojës për punë kërkimore në fazat vijuese;
Koordinimi dhe miratimi i termave të referencës.
Në firmat serioze, rezultati i kësaj faze është një përshkrim i përgjithshëm i sistemit, duke përfshirë kërkesat për programin dhe kërkesat për besueshmërinë e programit. Kërkesat për një program ose produkt softuerësh japin përgjigje për pyetjet e mëposhtme:
Cilat duhet të jenë të dhënat hyrëse?
Cilat të dhëna janë të sakta dhe cilat janë të gabuara?
Kush do të përdorë softuerin dhe cila duhet të jetë ndërfaqja (mjetet e komunikimit me përdoruesin)?
Çfarë thjeshtimesh, supozimesh dhe supozimesh mund të bëhen në lidhje me programet?
Cili duhet të jetë rezultati?
Kërkesat e besueshmërisë rregullojnë sigurimin e funksionimit të besueshëm të programit. Përcaktohen gabimet që duhet të zbulohen dhe mesazhet që është e dëshirueshme t'i jepen përdoruesit në prani të gabimeve. Të gjitha situatat e veçanta që kërkojnë kontabilitet shtesë dhe konsideratë të veçantë janë renditur.
Termat e referencës përcaktojnë kushtet e funksionimit (temperatura e ajrit të ambientit, lagështia relative, etj. për llojet e zgjedhura të bartësve të të dhënave), sipas të cilave duhet të sigurohen karakteristikat e specifikuara, si dhe lloji i shërbimit, numri i kërkuar dhe kualifikimet e personelit.
Dizajn
Dizajni përfshin dy faza: një projekt paraprak dhe një projekt teknik. Drafti i projektit konsiston në zhvillimin paraprak të strukturës së të dhënave hyrëse dhe dalëse dhe një përshkrim të përgjithshëm të algoritmit për zgjidhjen e problemit. Gjatë zhvillimit të një projekti teknik, specifikohen strukturat e të dhënave hyrëse dhe dalëse dhe përcaktohen format e tyre të paraqitjes. Përcaktohet algoritmi për zgjidhjen e problemit, përcaktohet semantika dhe sintaksa e gjuhës së programimit dhe zhvillohet struktura e programit. Të dyja fazat shoqërohen nga një shënim shpjegues dhe një studim fizibiliteti.
Procesi i projektimit është një pjesë thelbësore e çdo zhvillimi të softuerit. Në përputhje me teknologjinë e programimit të strukturuar nga lart-poshtë, paketa e softuerit është e ndarë në pjesë të vogla - module programi. Çdo nëndetyrë individuale duhet të jetë relativisht e pavarur dhe të përfaqësojë një modul të plotë programi. Modulariteti i programit është veti e rëndësishme e tij. Në procesin e projektimit, është e rëndësishme që të përshkruhen në detaje jo vetëm qëllimi i secilit modul, por edhe rrjedha e të dhënave ndërmjet moduleve. Çdo modul karakterizohet nga dy veti të rëndësishme:
1) ka mjete ndërveprimi me mjedisin e jashtëm;
2) është një njësi e pavarur softuerike që kryen funksione të caktuara.
Pjesë e ndërfaqes janë rrjedhat e të dhënave. Kur i përshkruani ato për secilin modul, është e nevojshme t'i përgjigjeni pyetjeve të mëposhtme:
Cilat të dhëna mund t'i kalohen një moduli përpara se të fillojë ekzekutimi?
Cilat thjeshtime, supozime dhe supozime bëhen në lidhje me modulin?
Çfarë do të ndodhë me të dhënat pasi moduli të përfundojë punën e tij?
Në fig. 16 është një shembull i një përshkrimi të një moduli të përdorur për të renditur numrat e plotë.
Oriz. 16. Shembull i specifikimit të modulit
Pas zhvillimit të strukturës së përgjithshme të programit, është e nevojshme të përcaktohet se cilat objekte bibliotekare mund të përdoren dhe cilat procedura të reja duhet të zhvillohen. Më pas, zhvillohen algoritme për modulet e reja të krijuara.
Përcaktohet skema e ndërveprimit të moduleve të programit, e quajtur skema e rrjedhave të të dhënave të kompleksit softuerik. Një plan dhe të dhëna fillestare po zhvillohen për testimin e moduleve të programit dhe të gjithë paketës së softuerit.
draft pune
Drafti i punës përfshin zhvillimin e dokumentacionit programor dhe programor, si dhe testimin e programit.
Faza e kodimit të algoritmit konsiston në përkthimin e algoritmeve të zhvilluara për çdo modul programi në programe në një gjuhë programimi specifike. Kjo fazë nuk është ajo kryesore në programim, megjithëse vazhdon gjatë gjithë pjesës tjetër të ciklit jetësor të produktit. Nëse faza e projektimit është bërë me mirëbesim, ndërfaqet e modulit përcaktohen saktë, atëherë kodimi kryhet mjaft shpejt.
Kodimi duhet të jetë i thjeshtë. Duhet respektuar i ashtuquajturi KISS-parim: Keep It Simple, Stupid (keep it simple, budalla!). Programimi i sofistikuar mund të jetë shumë i kushtueshëm për të korrigjuar dhe modifikuar një program. Kodimi i pazakontë (siç është shfrytëzimi i veçorive të fshehura të makinës) shpesh parandalon që programi të korrigjohet dhe, natyrisht, e bën të vështirë për programuesit e tjerë përdorimin e tij.
Programuesit me përvojë krijojnë programe universale. Universaliteti i referohet pavarësisë së programit nga një grup specifik të dhënash. Për shembull, një program gjenerik përdor variabla dhe jo konstante si parametra, trajton rastet e degjeneruara, etj. Universaliteti i programit kursen kohë për punë të mëtejshme në të dhe ofron mundësi të shumta për përdorim. Duke zhvilluar programe të tilla, ju mund të parashikoni ndryshime të ardhshme në specifikimet e atij programi.
Formatet e hyrjes duhet të dizajnohen me lehtësinë maksimale të përdoruesit dhe potencialin minimal për gabime. Rendi i ndryshueshëm dhe formatet e të dhënave të njohura për përdoruesin do të ndihmojnë në shmangien e gabimeve dhe do t'i bëjnë programet më të lehta për t'u përdorur. Formatet e daljes mund të ndryshojnë shumë. Ndonjëherë jepen udhëzime të qarta dhe rezultati përshtatet në një standard të caktuar. Rezultatet e llogaritjes duhet të jenë të lexueshme dhe të kuptueshme për një joprogramues.
Pasi modulet ose programi të jenë koduar, është koha për ta ekzekutuar atë për ekzekutim. Rezultati më i mundshëm i kësaj do të jetë një mesazh gabimi. Gabimi gjendet, korrigjohet dhe gjithçka përsëritet nga fillimi. Ky proces quhet korrigjimi. Korrigjimi konsiston në përcaktimin se ku ndodhin gabimet, zbulimin e shkakut të shfaqjes së tyre dhe eliminimin e këtyre shkaqeve.
Testimi zakonisht bëhet në dy faza. E para është testimi i njësisë. Kontrollohet sjellja dhe besueshmëria e secilit modul. Hapi i dytë është testimi i integrimit. Modulet grumbullohen në një program të përbashkët dhe zhvilluesi është i bindur se modulet ndërveprojnë në mënyrë korrekte. Programi që kontrollon funksionimin e moduleve testohet veçmas nga modulet. Vetë modulet në të zëvendësohen nga të ashtuquajturat "cungë". "Moduli cung" ka një hyrje, një dalje dhe mesazhin e kërkuar. Mesazhi mund të përmbajë një listë të të dhënave të dërguara në modul.
Testimi është një test i programit për funksionueshmërinë. Korrigjimi ndodh kur një program padyshim nuk po funksionon siç duhet. Korrigjimi gjithmonë fillon në pritje të një dështimi të programit. Nëse rezulton se programi funksionon si duhet, atëherë ai testohet. Ndodh shpesh që pasi të jenë ekzekutuar testet, programi duhet të debugohet përsëri. Kështu, testimi përcakton praninë e një gabimi dhe korrigjimi zbulon shkakun e tij.
Për një aplikim të thjeshtë, testimi mund të jetë i thjeshtë. Programet e mëdha janë të vështira për t'u testuar. Është e mundur të eliminohen gabimet gjatë fazës së funksionimit.
Ju mund të jepni shembuj të gabimeve në sistemet softuerike të bëra gjatë zhvillimit dhe që nuk u zbuluan gjatë testimit.
Në "Microsoft Works Reference" në ndihmën online të Works Integrated Information Processing Suite 2.0, funksioni IF përshkruhet si
IF (Kushti, Vlera e gabuar, Vlera e vërtetë).
Megjithatë, në realitet, puna e këtij funksioni duhet të jetë si më poshtë: IF (Kushti, Vlera e vërtetë, Vlera e gabuar). Udhëzuesi i përdorimit të Microsoft Works for Windows për Works 3.0 korrigjon këtë gabim.
Dështimi për të nisur satelitin e parë amerikan në Venus ndodhi, ka shumë të ngjarë, për shkak të një gabimi në program - në vend të pikës së kërkuar në operator, programuesi vendosi një presje. Operatori Fortran ishte shkruar
Bëni 50 i = 12,525
Në fakt, duhet të dukej kështu:
Bëni 50 i = 12,525
Shkaku i ndërlikimeve që u shfaqën gjatë kthimit në Tokë të ekuipazheve Sovjeto-Afgane dhe Sovjeto-Franceze ishin gabimet e bëra në softuerin e kompjuterëve në bord.
Në vitin 1983 pati një përmbytje në pjesën jugperëndimore të Shteteve të Bashkuara. Arsyeja ishte se në kompjuter u futën të dhëna të pasakta të motit, si rezultat i të cilave u dha një sinjal i gabuar bravave që bllokonin lumin Kolorado.
Për të parandaluar që përdoruesit të futen në një situatë ku programi funksionon, por nuk bën atë që duhet të bëjë, kryhet testimi për të identifikuar gabimet "të fshehura". Testimi përdor plane dhe të dhëna të zhvilluara tashmë në fazën e projektimit. Është e nevojshme të mendohet për testimin gjatë gjithë periudhës së zhvillimit të programit (Tabela 2).
tabela 2
Llojet dhe shkaqet e gabimeve
| Lloji i gabimit | Shkaku i gabimit |
| Deklaratë e gabuar e problemit | Detyrë e formuluar gabimisht |
| Algoritmi i pavlefshëm | Është zgjedhur një algoritëm që çon në një zgjidhje të pasaktë ose joefikase të problemit |
| gabim semantik | Një gabim semantik në program, që nuk lidhet me një shkelje të sintaksës. Për shembull, variablat janë përcaktuar gabimisht, të dhënat hyrëse nuk janë në përputhje me vlerat kufitare të dhëna në algoritëm, një operator i gjuhës programuese i shkruar saktë është përdorur gabimisht, etj. Gabimet e këtij lloji zbulohen në fazën e testimit dhe korrigjimit. |
| Gabime sintaksore (gabime në kohën e përpilimit) | Gabime programimi, të cilat konsistojnë në shkeljen e strukturave gramatikore të gjuhës. Gabimet e këtij lloji zbulohen nga përpiluesi |
| Gabimet në kohën e ekzekutimit | Gabimet që ndodhin gjatë ekzekutimit të programit. Ka gabime hyrëse/dalëse (për shembull, skedari nuk u gjet, memoria e pamjaftueshme për ekzekutimin e programit, etj.) dhe gabime fatale që çojnë në përfundimin e menjëhershëm të programit (për shembull, ndarja me zero, gabime gjatë kontrollit të kufijve , tejmbushja gjatë operacioneve me pikë lundruese) dhe etj.) |
| Gabimet në të dhëna | Përcaktimi i pasuksesshëm i gamës së mundshme të ndryshimeve në të dhënat hyrëse |
| Gabimet në dokumente | Dokumentacioni i përdoruesit nuk përputhet me versionin aktual të programit |
Në procesin e kryerjes së të gjitha fazave të mësipërme, grumbullohet një përvojë e caktuar, e cila do të sigurojë bazën për përmirësimin e programit.
Faza e "Projektimit të Punës" përfundon me teste paraprake të gjendjes, ndër-departamentale, pranuese dhe lloje të tjera. Dokumentacioni i programit rregullohet në përputhje me rezultatet e testit.
Zbatimi
Zbatimi është faza e ciklit jetësor të programit, në të cilën kryhet transferimi i programit dhe dokumentacionit të programit te klienti. Gjatë funksionimit, mund të jetë e nevojshme të shtoni funksione të reja në paketën e softuerit, të eliminoni gabimet e gjetura gjatë funksionimit, etj. Kjo lloj pune quhet vazhdim.
Një shembull i shtimit të funksioneve të reja në paketën e softuerit është redaktori i tekstit Lexicon 1.3. Ky version rrjedh nga Word Processor 1.2 duke përfshirë funksionet e importimit të skedarëve grafikë në formatin PCX në skedarët e tekstit.
Dokumentacioni
Në fig. 15, një drejtkëndësh që pasqyron çdo fazë të zhvillimit të programit është i lidhur me drejtkëndëshin "Dokument". Shigjetat tregojnë në të dy drejtimet. Idetë dhe vendimet e përdorura në çdo hap ndikojnë në dokumentacionin që shoqëron hapin, ashtu si dokumentacioni ndikon në idetë dhe vendimet.
Zhvillimi i dokumentacionit fillon sapo të fillojë zhvillimi i softuerit. Dokumentacioni klasifikohet sipas qëllimit të tij dhe mund të ndahet në disa grupe, të paktën në dy grupe. Grupi i parë i dokumenteve është i destinuar për zhvilluesit dhe specialistët e softuerit që do ta mirëmbajnë atë, dhe grupi i dytë është për përdoruesit e softuerit.
Grupi i parë si dokumente kryesore përfshin një detyrë për zhvillimin e softuerit (kushtet e referencës), specifikimin dhe përshkrimin e programit.
Termat e referencës duhet të përmbajnë seksionet e mëposhtme:
Prezantimi;
Bazat për zhvillim;
Qëllimi i zhvillimit;
Kërkesat për programin dhe produktin softuer;
Kërkesat për dokumentacionin e softuerit;
Treguesit teknikë dhe ekonomikë;
Fazat dhe fazat e zhvillimit;
Procedura për kontroll dhe pranim.
Lejohet përfshirja e aplikacioneve në termat e referencës, ku, nëse është e nevojshme, ato ofrojnë një listë kërkimesh dhe punime të tjera që justifikojnë zhvillimin, skemat e algoritmeve dhe dokumente të tjera që mund të përdoren në zhvillim.
Specifikimi është dokumenti kryesor i programit dhe është përpiluar në përputhje me GOST. Specifikimi është një tabelë e përbërë nga kolonat: "Përcaktimi", "Emri", "Shënim". Në kolonën "Përcaktimi" shënoni emërtimet e dokumenteve dhe programeve të numëruara. Në kolonën "Dokumentacioni" tregoni emrat dhe llojin e dokumentit ose programit. Në kolonën "Shënim" - informacion shtesë në lidhje me programet e regjistruara në specifikim.
Përshkrimi i programit përmban:
– tekste burimore të komentuara (lista) të moduleve të programit dhe modulit të kontrollit;
– një skemë për ndarjen e kompleksit softuerik në module softuerike;
– skema e flukseve të të dhënave të paketës softuerike;
– skema e ndërveprimit të moduleve softuerike;
– planet dhe të dhënat për testimin e paketës softuerike;
– materiale të tjera që ilustrojnë projektin, për shembull, skemat e algoritmeve.
Lloji i dytë i dokumenteve përmban informacionin e nevojshëm për të punuar me paketën e softuerit. Këto dokumente mund të lëshohen në formë të printuar dhe (ose) "të ngulitura" në paketën e softuerit.
Disiplina e programimit është një faktor i rëndësishëm në suksesin e zhvillimit të softuerit. Parimet e zhvillimit të programit të dhëna në kapitullin e fundit janë të vlefshme për gjuhët e programimit procedural dhe për gjuhët e orientuara nga objekti.
Versioni 6.0 i Turbo Pascal, i lëshuar në 1990, demonstroi qartë përfitimet e teknologjisë së programimit të orientuar nga objekti. Paketa e versionit të ri përfshinte bibliotekën Turbo Vision, mbi të cilën mijëra programues zotëruan parimet e OOP. Në një kohë të shkurtër, u shfaqën shumë programe komerciale të bazuara në Turbo Vision. Kjo bibliotekë po revolucionarizon vërtet procesin e zhvillimit të programeve ndërvepruese, duke reduktuar kohën në minimum dhe duke siguruar cilësinë më të lartë të programeve.
Evolucioni i mjeteve teknike të kompjuterëve personalë ka çuar në zëvendësimin e gjerë të sistemit operativ të mirë të vjetër MS-DOS me sisteme Windows shumë më të fuqishme, programimi për të cilin është shumë më i vështirë sesa programimi për MS-DOS. Me lëshimin e sistemit Borland Pascal with Objects, Borland u ka ofruar programuesve një mjet shumë të fuqishëm për zhvillimin dhe korrigjimin e programeve të dizajnuara për të ekzekutuar nën guaskën operative të Windows. Por akoma, disa vjet më parë, një programues i zakonshëm mund të ëndërronte vetëm të krijonte programet e tij nën Windows.
Formulimi i problemit. Krijimi i çdo programi fillon me formulimin e një problemi. Fillimisht, detyra formulohet sipas fushës lëndore dhe është e nevojshme të përkthehet
Oriz. 26.1.
atë në gjuhën e koncepteve më afër programimit. Meqenëse programuesi rrallë e kupton plotësisht fushën e lëndës, dhe klienti rrallë e kupton programimin (një shembull i thjeshtë: duhet të shkruani një program kontabiliteti), përcaktimi i problemit mund të bëhet një proces shumë i vështirë përsëritës. Përveç kësaj, kur vendos një detyrë, klienti shpesh nuk mund të formulojë qartë dhe plotësisht kërkesat dhe kriteret e tij.
Ky hap përcakton gjithashtu mjedisin në të cilin do të ekzekutohet programi: kërkesat e harduerit, sistemi operativ dhe softueri tjetër.
Deklarata e problemit përfundon me krijimin Termat e referencës, dhe pastaj specifikimet e programit të jashtëm, duke përfshirë:
■ përshkrimi i të dhënave hyrëse dhe rezultateve (llojet, formatet, saktësia, mënyra e transmetimit, kufizimet);
■ përshkrimin e detyrës së zbatuar nga programi;
■ mënyra e hyrjes në program;
■ përshkrimin e emergjencave të mundshme dhe gabimet e përdoruesit.
Kështu, programi konsiderohet si një "kuti e zezë", për të cilën janë përcaktuar një funksion dhe të dhënat hyrëse dhe dalëse.
Zgjedhja e modelit dhe metodës për zgjidhjen e problemit. Në këtë fazë analizohen kushtet e problemit dhe mbi këtë bazë ndërtohet një model i problemit dhe përcaktohet një metodë e përgjithshme për zgjidhjen e tij. Gjatë ndërtimit të modelit, veçohen karakteristikat e problemit që janë domethënëse nga pikëpamja e shqyrtimit, d.m.th. është e abstraguar. Këto karakteristika duhet të paraqiten në model me plotësinë dhe saktësinë e nevojshme. Me fjalë të tjera, në këtë fazë formalizohet deklarata e problemit dhe, mbi këtë bazë, përcaktohet një metodë e përgjithshme për zgjidhjen e tij. Nëse ka disa metoda, më e mira zgjidhet në bazë të kritereve të kompleksitetit, efikasitetit, saktësisë, në varësi të detyrave specifike me të cilat përballet programuesi.
Zhvillimi i strukturave të brendshme të të dhënave. Shumica e algoritmeve varen nga mënyra se si organizohen të dhënat, kështu që është intuitivisht e qartë se duhet të fillohet dizajnimi i një programi jo me algoritme, por me zhvillimin e strukturave të nevojshme për të përfaqësuar të dhënat hyrëse, dalëse dhe të ndërmjetme. Shumë faktorë merren parasysh, si kufizimet e madhësisë së të dhënave, saktësia e kërkuar dhe kërkesat e performancës së programit. Strukturat e të dhënave mund të jenë statike ose dinamike.
Kur vendosni se si do të organizohen të dhënat në një program, është e dobishme t'i bëni vetes pyetjet e mëposhtme.
■ Çfarë saktësie të paraqitjes së të dhënave nevojitet?
■ Cili është diapazoni i vlerave të të dhënave?
■ A ka një kufi maksimal të të dhënave?
■ A është e nevojshme mbajtja e tyre në program në të njëjtën kohë?
■ Çfarë veprimesh do t'ju duhet të kryeni mbi të dhënat?
Për shembull, nëse sasia maksimale e të dhënave të të njëjtit lloj që duhet të përpunohet është e njohur dhe e vogël, është më e lehtë të krijohet një grup statik për ta ruajtur atë. Nëse ka shumë vargje të tilla, segmentet e të dhënave dhe të stivës mund të mos jenë të mjaftueshme dhe do t'ju duhet të ndani hapësirë në memorien dinamike për këto vargje.
Nëse sasia maksimale e të dhënave është e panjohur dhe ndryshon vazhdimisht gjatë funksionimit të programit, atëherë strukturat dinamike përdoren për ruajtjen e tyre. Zgjedhja e llojit të strukturës varet nga operacionet e kërkuara në të dhëna. Për shembull, një pemë binare është më e përshtatshme për gjetjen e shpejtë të elementeve dhe nëse të dhënat duhet të përpunohen sipas rendit të mbërritjes, përdoret një radhë.
Dizajn. Nën hartimi i programit kuptohet përkufizimi i strukturës së përgjithshme dhe ndërveprimit të moduleve.
Në këtë fazë, aplikoni teknologji projektimi nga lart-poshtë, ideja kryesore e së cilës është diskutuar më lart. Në këtë rast, përdoret metoda e detajimit hap pas hapi.
Dikush mund ta imagjinojë këtë proces në atë mënyrë që programi fillimisht të shkruhet në gjuhën e një makine hipotetike që është në gjendje të kuptojë veprimet më të përgjithësuara, dhe më pas secila prej tyre përshkruhet në një nivel më të ulët abstraksioni, e kështu me radhë. Shumë e rëndësishme në këtë fazë është specifikimet e ndërfaqes, ato. përcaktimi i mënyrave të bashkëveprimit të nëndetyrave.
Për çdo nëndetyrë, përpilohet një specifikim i jashtëm, i ngjashëm me atë të dhënë më parë. Në të njëjtën fazë, zgjidhen çështjet e ndarjes së programit në module, kriteri kryesor për këtë është minimizimi i ndërveprimit të tyre. Një detyrë mund të zbatohet duke përdorur disa module, dhe anasjelltas, disa detyra mund të zgjidhen në një modul. Niveli i poshtëm i projektimit transferohet vetëm pas përfundimit të dizajnit të nivelit të sipërm. Algoritmet shkruhen në formë të përgjithësuar, si verbale, në formën e bllok diagrameve të përgjithësuara ose në mënyra të tjera.
KUJDES
Faza e projektimit duhet të marrë parasysh mundësinë e modifikimeve të programit në të ardhmen dhe të përpiqet të hartojë programin në atë mënyrë që të jetë sa më e lehtë për të bërë ndryshime.
Meqenëse nuk dihet se çfarë ndryshimesh do të duhen bërë, kjo dëshirë të kujton krijimin e një "teorie të përgjithshme të gjithçkaje"; në praktikë, njeriu duhet të kufizohet në kompromise të arsyeshme. Programuesi, bazuar në përvojën e tij dhe sensin e shëndoshë, vendos se cilat veçori të programit mund të kenë nevojë të ndryshohen ose përmirësohen në të ardhmen.
Procesi i projektimit është përsëritës, sepse në programet e madhësisë reale është e pamundur të mendohen të gjitha detajet herën e parë.
Programimi strukturor. Programimi këtu konsiderohet "në kuptimin e ngushtë", d.m.th. kuptohet si shkrimi i një programi në një gjuhë programimi sipas një algoritmi të gatshëm. Ky proces shpesh quhet kodimi për ta dalluar nga cikli i plotë i zhvillimit të programit.
Kodimi organizohet gjithashtu mbi bazën nga lart-poshtë: së pari, kodohen modulet e nivelit të lartë dhe përpilohen rastet e testimit për korrigjimin e tyre. Në të njëjtën kohë, cungët vendosen në vend të moduleve të nivelit tjetër që nuk janë shkruar ende, të cilët, në rastin më të thjeshtë, thjesht lëshojnë një mesazh se kontrolli u është transferuar atyre dhe më pas e kthejnë atë në modulin thirrës. . Në raste të tjera, cung mund të kthejë vlera që janë të paracaktuara ose të llogaritura duke përdorur një algoritëm të thjeshtuar.
Kështu, fillimisht krijohet skeleti logjik i programit, i cili më pas mbulohet me mishin e kodit. Do të dukej më logjike të zbatohej teknologjia nga poshtë-lart në procesin e programimit: fillimisht shkruani dhe korrigjoni modulet e nivelit më të ulët dhe më pas kombinoni ato në fragmente më të mëdha, por kjo qasje ka disa disavantazhe.
Së pari, në procesin e kodimit të nivelit të sipërm, mund të zbulohen disa vështirësi në hartimin e niveleve më të ulëta të programit (thjesht sepse kur shkruani një program, logjika e tij mendohet më me kujdes se sa gjatë dizajnimit). Nëse një gabim i tillë zbulohet i fundit, kërkohen kosto shtesë për ripërpunimin e moduleve tashmë të përfunduara të nivelit më të ulët.
Së dyti, korrigjimi i çdo moduli, dhe më pas pjesët më të mëdha të programit, kërkon shkrimin e rasteve të veta të testimit çdo herë, dhe programuesi shpesh detyrohet të imitojë mjedisin në të cilin duhet të funksionojë moduli. Teknologjia e programimit nga lart-poshtë ofron një rend natyror për krijimin e testeve - mundësinë e korrigjimit nga lart-poshtë, e cila diskutohet më poshtë.
Fazat e projektimit dhe programimit kombinohen në kohë: në mënyrë ideale, fillimisht projektohet dhe kodohet niveli i lartë, pastaj ai vijues e kështu me radhë. Kjo strategji përdoret sepse zvogëlon koston e një gabimi, pasi mund të jetë e nevojshme të bëhen ndryshime gjatë procesit të kodimit që prekin modulet e nivelit më të ulët.
Testimi në rënie. Kjo fazë regjistrohet e fundit, por kjo nuk do të thotë që testimi nuk duhet të kryhet në fazat e mëparshme. Si dizajni ashtu edhe programimi duhet të shoqërohen me shkrim komplet testimi – verifikimi i të dhënave fillestare dhe grupeve përkatëse të reaksioneve të referencës.
Është e nevojshme të bëhet dallimi midis proceseve të testimit dhe korrigjimit të një programi. Duke testuarështë procesi me të cilin verifikohet korrektësia e një programi. Testimi është pozitiv, qëllimi i tij është të tregojë se programi funksionon në mënyrë korrekte dhe plotëson të gjitha specifikimet e projektimit. Korrigjimi- procesi i korrigjimit të gabimeve në një program, në të cilin qëllimi nuk është të korrigjohen të gjitha gabimet. Rregulloni gabimet e gjetura gjatë testimit. Gjatë planifikimit, duhet pasur parasysh se procesi i zbulimit të gabimeve i bindet ligjit të ngopjes, d.m.th. shumica e gabimeve gjenden në fazat e hershme të testimit, dhe sa më pak gabime të mbeten në program, aq më shumë kohë duhet për të kërkuar secilin prej tyre.
Ekzistojnë dy strategji testimi: "kutia e zezë" dhe "kutia e bardhë". Kur përdorni të parën, struktura e brendshme e programit nuk merret parasysh dhe testet përpilohen në atë mënyrë që të kontrollohet plotësisht funksionimi i programit në hyrje të sakta dhe të pasakta.
Strategjia e "kutisë së bardhë" përfshin kontrollimin e të gjitha degëve të algoritmit. Numri i përgjithshëm i degëve përcaktohet nga kombinimi i të gjitha alternativave në çdo fazë. Ky është një numër i kufizuar, por mund të jetë shumë i madh, kështu që programi ndahet në fragmente, pas testimit shterues të të cilave ato konsiderohen si nyje elementare të degëve më të gjata. Përveç të dhënave që sigurojnë ekzekutimin e deklaratave në sekuencën e kërkuar, testet duhet të përmbajnë kontrolli i kushteve kufitare(për shembull, kalimi sipas kushteve X> 10 duhet të testohet për vlera më të mëdha se, më të vogla ose të barabarta me 10). Përgjigja e programit për hyrje të gabuara.
disavantazh Strategjia e "kutisë së bardhë" është se është e pamundur të zbulohet dega që mungon duke përdorur atë, dhe strategjia e "kutisë së zezë" kërkon një numër të madh opsionesh hyrëse, prandaj, në praktikë, përdoret një kombinim i të dyja strategjive.
KUJDES
Ideja e testimit nga lart-poshtë është të filloni testimin e një programi përpara se të përfundojë dizajni. Kjo ju lejon të provoni ndërfaqet kryesore ndër-module më herët, si dhe të siguroheni që programi në thelb i plotëson kërkesat e përdoruesit. Vetëm pasi bërthama logjike të jetë testuar në atë masë sa të ketë besim në zbatimin e saktë të ndërfaqeve kryesore, ata fillojnë të kodojnë dhe testojnë nivelin tjetër të programit.
Natyrisht, testimi i plotë i programit ndërsa ai paraqitet në formën e një skeleti është i pamundur, megjithatë, shtimi i çdo niveli tjetër ju lejon të zgjeroni gradualisht zonën e testimit.
Faza komplekse e korrigjimit në nivel sistemi në një dizajn nga lart-poshtë kërkon më pak kohë sesa një dizajn nga lart-poshtë dhe sjell më pak surpriza, pasi gjasat që gabimet serioze të prekin një pjesë të madhe të sistemit janë shumë më të ulëta. Përveç kësaj, për çdo modul të lidhur me sistemin, mjedisi i tij tashmë është krijuar dhe dalja e moduleve të debuguara mund të përdoret si hyrje për testimin e të tjerëve, gjë që lehtëson procesin e testimit. Kjo nuk do të thotë që moduli duhet të lidhet me sistemin plotësisht "të papërpunuar", mund të jetë i përshtatshëm për të kryer një pjesë të testimit jashtë linje, pasi është e vështirë të gjenerohen të gjitha opsionet e nevojshme për testimin e një moduli të veçantë në hyrjen e sistemit. .
Modeli i kaskadës në formën e tij të pastër përdoret vetëm për programe të thjeshta, pasi është e vështirë të parashikohen paraprakisht të gjitha detajet e zbatimit. Më realiste është skema me kontroll të ndërmjetëm (Fig. 26.2). Kontrolli i kryer pas çdo faze lejon, nëse është e nevojshme, të kthehet në çdo nivel më të lartë dhe të bëjë ndryshimet e nevojshme.
Rreziku kryesor i përdorimit të një skeme të tillë është se zhvillimi nuk do të përfundojë kurrë, duke qenë vazhdimisht në një gjendje të përsosjes dhe përmirësimit.
Oriz. 26.2.
- Llojet dhe formatet nuk nënkuptojnë llojet e gjuhëve të programimit.
