Cikli jetësor i sistemeve softuerike. Cikli i jetës së softuerit Fazat e ciklit jetësor

Koncepti i "ciklit jetësor" nënkupton diçka që lind, zhvillohet dhe vdes. Ashtu si një organizëm i gjallë, produktet softuerike krijohen, operohen dhe zhvillohen me kalimin e kohës.

Cikli jetësor software përfshin të gjitha fazat e zhvillimit të tij: nga shfaqja e nevojës për të deri në ndërprerjen e plotë të përdorimit të tij për shkak të vjetërsimit ose humbjes së nevojës për zgjidhjen e problemeve përkatëse.

Mund të dallojmë disa faza të ekzistencës së një produkti softuer gjatë ciklit të tij jetësor. Nuk ka ende emra të pranuar përgjithësisht për këto faza dhe numrin e tyre. Por nuk ka ndonjë mosmarrëveshje të veçantë për këtë çështje. Prandaj, ekzistojnë disa opsione për ndarjen e ciklit jetësor të softuerit në faza. Nëse kjo ndarje e veçantë është më e mirë se të tjerat nuk është pyetja kryesore. Gjëja kryesore është të organizoni siç duhet zhvillimin e softuerit duke marrë parasysh ato.

Bazuar në kohëzgjatjen e ciklit të tyre jetësor, produktet softuerike mund të ndahen në dy klasa: i vogël Dhe jetë e gjatë. Këto klasa programesh korrespondojnë me një qasje fleksibël (të butë) për krijimin dhe përdorimin e tyre dhe një qasje të vështirë industriale ndaj dizajnit dhe funksionimit të rregulluar të produkteve softuerike. NË organizatat shkencore dhe universitetet, për shembull, mbizotëron zhvillimi i programeve të klasit të parë, dhe në organizatat e projektimit dhe industriale - i dyti.

Produkte softuerike me jetëgjatësi të shkurtër janë krijuar kryesisht për të zgjidhur probleme shkencore dhe inxhinierike, për të marrë rezultate specifike llogaritëse. Programe të tilla janë zakonisht relativisht të vogla. Ato zhvillohen nga një specialist ose një grup i vogël. Ideja kryesore programi diskutohet nga një programues dhe përdoruesi përfundimtar. Disa detaje janë hedhur në letër dhe projekti përfundon brenda pak ditësh ose javësh. Ato nuk janë të destinuara për riprodhim ose transferim për përdorim të mëvonshëm në grupe të tjera. Në thelb, programe të tilla janë pjesë e punës kërkimore-shkencore dhe nuk mund të konsiderohen si produkte softuerike të tjetërsueshme.

Cikli jetësor i tyre përbëhet nga një interval i gjatë i analizës së sistemit dhe formalizimi i problemit, një fazë e rëndësishme e hartimit të programit dhe një kohë relativisht e shkurtër e funksionimit dhe marrjes së rezultateve. Kërkesat për karakteristikat funksionale dhe të projektimit, si rregull, nuk janë të zyrtarizuara dhe nuk ka teste formale të programeve. Treguesit e cilësisë së tyre kontrollohen vetëm nga zhvilluesit në përputhje me idetë e tyre joformale.

Produkte softuerike me jetëgjatësi të shkurtër

Mirëmbajtja dhe modifikimi i programeve të tilla nuk kërkohet dhe cikli i jetës së tyre përfundon pas marrjes së rezultateve të llogaritjes. Kostot kryesore në ciklin jetësor të programeve të tilla bien në fazat e analizës dhe projektimit të sistemit, të cilat zgjasin nga një muaj deri në 1...2 vjet, si rezultat.

ku cikli i jetës së një produkti softuerik rrallë i kalon 3 vjet.

Produkte softuerike me një jetë të gjatë shërbimi janë krijuar për përpunimin dhe menaxhimin e rregullt të informacionit. Struktura e programeve të tilla është komplekse. Madhësitë e tyre mund të ndryshojnë shumë (1...1000 mijë komanda), por të gjitha kanë vetitë e njohjes dhe mundësinë e modifikimit gjatë mirëmbajtjes dhe përdorimit afatgjatë nga specialistë të ndryshëm. Produktet softuerike të kësaj klase mund të përsëriten, ato shoqërohen me dokumentacion si produkte industriale dhe përfaqësojnë produkte softuerike të tjetërsuar nga zhvilluesi.

Produkte softuerike me një jetë të gjatë shërbimi

Dizajni dhe funksionimi i tyre kryhen nga ekipe të mëdha specialistësh, gjë që kërkon formalizimin e sistemit softuerik, si dhe testimin e zyrtarizuar dhe përcaktimin e treguesve të cilësisë së arritur të produktit përfundimtar. Cikli jetësor i tyre është 10...20 vjet. Deri në 70...90% të kësaj kohe shpenzohet për funksionimin dhe mirëmbajtjen. Për shkak të riprodhimit masiv dhe mirëmbajtjes afatgjatë, kostot totale gjatë funksionimit dhe mirëmbajtjes së produkteve të tilla softuerike tejkalojnë ndjeshëm kostot e analizës dhe projektimit të sistemit.

I gjithë prezantimi i mëpasshëm fokusohet në temën e zhvillimit të madh (kompleks) software menaxhimi dhe përpunimi i informacionit.

Modeli i përgjithësuar cikli jetësor Produkti i softuerit mund të duket si ky:

I. Analiza e sistemit:

a) kërkime;

b) analiza e fizibilitetit:

Operacionale;

Ekonomik;

Komerciale.

II. Dizajni i softuerit:

a) dizajni:

Zbërthimi funksional i sistemit, arkitektura e tij;

Dizajn i jashtëm i softuerit;

Dizajni i bazës së të dhënave;

Arkitektura e softuerit;

b) programimi:

Dizajn i brendshëm i softuerit;

Dizajn i jashtëm i moduleve softuerike;

Dizajn i brendshëm i moduleve softuerike;

Kodimi;

Programet e korrigjimit;

Paraqitja e programit;

c) korrigjimi i softuerit.

III. Vlerësimi (testimi) i softuerit.

IV. Përdorimi i softuerit:

a) operacion;

b) shoqërim.

I. Analiza e sistemit. Në fillim të zhvillimit të softuerit, kryhet një analizë e sistemit (projektimi paraprak), gjatë së cilës përcaktohet nevoja për të, qëllimi i tij dhe karakteristikat kryesore funksionale. Janë vlerësuar kostot dhe efektiviteti i mundshëm i përdorimit të produktit të ardhshëm softuer.

Në këtë fazë, përpilohet një listë e kërkesave, domethënë një përcaktim i qartë i asaj që pret përdoruesi nga produkti i përfunduar. Këtu përcaktohen qëllimet dhe objektivat, për hir të të cilave zhvillohet vetë projekti. Në fazën e analizës së sistemit mund të dallohen dy drejtime: hulumtimi dhe analiza e fizibilitetit.

Hulumtimi fillon që nga momenti kur menaxheri i zhvillimit e kupton nevojën për softuerin.

Puna konsiston në planifikimin dhe koordinimin e aktiviteteve të nevojshme për të përgatitur një listë zyrtare, të shkruar me dorë të kërkesave për produktin softuer që po zhvillohet.

Hulumtimi përfundon kur kërkesat janë formuar në atë mënyrë që ato të bëhen të dukshme dhe, nëse është e nevojshme, të mund të modifikohen dhe miratohen nga drejtuesi përgjegjës.

Analiza e Fizibilitetit ka pjesa teknike kërkimi dhe fillon kur qëllimi i menaxhmentit është mjaft i fortë sa që një menaxher projekti të caktohet për të organizuar projektimin dhe shpërndarjen e burimeve (punës).

Puna konsiston në studimin e produktit softuerik të propozuar për të marrë një vlerësim praktik të fizibilitetit të projektit, në veçanti, përcaktohen sa vijon:

- fizibiliteti operacional , A do të jetë produkti mjaft i përshtatshëm për përdorim praktik?

- fizibiliteti ekonomik , A është e pranueshme kostoja e produktit që po zhvillohet? Sa është kjo kosto? A do të jetë produkti ekonomikisht mjet efektiv në duart e përdoruesit?

- fizibiliteti komercial, A do të jetë produkti tërheqës, i kërkuar, i lehtë për t'u instaluar, i lehtë për t'u mirëmbajtur, i lehtë për t'u mësuar?

Këto dhe çështje të tjera duhet të trajtohen kryesisht duke marrë parasysh kërkesat e mësipërme.

Studimi i fizibilitetit përfundon kur të jenë mbledhur dhe miratuar të gjitha kërkesat.

Përpara se të vazhdoni më tej me projektin, është e nevojshme të siguroheni që të gjitha informacionet e nevojshme janë marrë. Ky informacion duhet të jetë i saktë, i kuptueshëm dhe i zbatueshëm. Ai duhet të përfaqësojë një grup të plotë kërkesash që kënaqin përdoruesin për produktin softuer që po zhvillohet, të formalizuar në formën e një specifikimi.

Në rast mospërputhjeje këtë kërkesëështë e mundur të ngadalësohet ndjeshëm zbatimi i projektit në të ardhmen për shkak të kërkesave të përsëritura të përsëritura drejtuar përdoruesit për sqarimin e detajeve të interpretuara gabimisht, kushteve të paspecifikuara dhe, si rezultat, do të kërkohet ripërpunimi i pjesëve të tij tashmë të zhvilluara.

Shpesh gjatë periudhës së analizës së sistemit, merret një vendim për të ndaluar zhvillimin e mëtejshëm të softuerit.

II. Dizajni i softuerit. Dizajni është faza kryesore dhe vendimtare e ciklit jetësor të softuerit, gjatë së cilës krijohet një produkt softuerik dhe 90% merr formën e tij përfundimtare.

Kjo fazë e jetës mbulon lloje të ndryshme aktivitetet e projektit dhe mund të ndahen në tre faza kryesore: projektimi, programimi dhe korrigjimi i produktit softuer.

Ndërtimi zhvillimi i softuerit zakonisht fillon në fazën e analizës së fizibilitetit, sapo disa qëllime dhe kërkesa paraprake për të regjistrohen në letër.

Deri në momentin që kërkesat të miratohen, puna në fazën e projektimit do të jetë në lëvizje të plotë.

Në këtë fazë të jetës së softuerit, kryhen sa vijon:

Zbërthimi funksional i problemit që zgjidhet, në bazë të të cilit përcaktohet arkitektura e sistemit të kësaj detyre;

Dizajni i softuerit të jashtëm, i shprehur në formë ndërveprimi i jashtëm atë me përdoruesin;

Dizajnimi i bazës së të dhënave, nëse është e nevojshme;

Dizajni i arkitekturës së softuerit - përcaktimi i objekteve, moduleve dhe ndërfaqeve të tyre.

Fillon programimi tashmë në fazën e projektimit, sapo të bëhen të disponueshme specifikimet bazë për komponentët individualë të produktit softuer, por jo përpara miratimit të marrëveshjes së kërkesave. Mbivendosja e fazave të programimit dhe projektimit rezulton në kursime në kohën e përgjithshme të zhvillimit, si dhe në sigurimin e verifikimit të korrektësisë së vendimeve të projektimit dhe në disa raste ndikon në zgjidhjen e çështjeve kryesore.

Në këtë fazë, kryhet puna në lidhje me montimin e produktit softuer. Ai konsiston në hartimin e brendshëm të detajuar të një produkti softuer, në zhvillimin e logjikës së brendshme të çdo moduli të sistemit, i cili më pas shprehet në tekstin e një programi specifik.

Faza e programimit përfundon kur zhvilluesit përfundojnë dokumentimin, korrigjimin dhe montimin e pjesëve individuale të produktit softuer në një tërësi të vetme.

Korrigjimi i softuerit kryhet pasi të gjithë përbërësit e tij të jenë korrigjuar veçmas dhe të grumbullohen në një produkt të vetëm softuerësh.

III. Vlerësimi (testimi) i softuerit. Në këtë fazë, produkti softuerik i nënshtrohet testimit rigoroz të sistemit nga një grup jo-zhvilluesish.

Kjo bëhet për t'u siguruar që produkti i përfunduar softuerik plotëson të gjitha kërkesat dhe specifikimet, mund të përdoret në mjedisin e përdoruesit, është i lirë nga çdo defekt dhe përmban dokumentacionin e nevojshëm, i cili përshkruan saktë dhe plotësisht produktin e softuerit.

Faza e vlerësimit fillon sapo të gjithë komponentët (modulet) të grumbullohen dhe testohen, d.m.th. pas korrigjimit të plotë të produktit softuerik të përfunduar. Ai përfundon pas marrjes së konfirmimit se produkti softuer i ka kaluar të gjitha testet dhe është gati për përdorim.

Zgjat aq sa programimi.

IV. Duke përdorur softuerin. Nëse analiza e sistemit është një sinjal për betejë, dizajni është një sulm dhe kthehet fitimtar, atëherë përdorimi i një produkti softuerësh është një mbrojtje e përditshme, jetike, por zakonisht jo e nderuar për zhvilluesit.

Një krahasim i tillë është i përshtatshëm për faktin se gjatë përdorimit të një produkti softuer, korrigjohen gabimet që depërtuan gjatë procesit të projektimit të tij.

Faza e përdorimit të një produkti softuer fillon kur produkti transferohet në sistemin e shpërndarjes.

Kjo është koha gjatë së cilës produkti është në funksion dhe përdoret në mënyrë efektive.

Në këtë kohë, kryhet trajnimi i personelit, zbatimi, konfigurimi, mirëmbajtja dhe, ndoshta, zgjerimi i produktit softuer - i ashtuquajturi dizajn i vazhdueshëm.

Faza e përdorimit përfundon kur produkti hiqet nga përdorimi dhe pushojnë aktivitetet e përmendura më sipër. Megjithatë, vini re se produkti softuer mund të vazhdojë të përdoret nga dikush tjetër shumë kohë pasi të ketë përfunduar faza e përdorimit siç përcaktohet këtu. Sepse ky dikush mund të përdorë produktin softuer në shtëpi edhe pa ndihmën e një zhvilluesi.

Përdorimi i një produkti softuer përcaktohet nga funksionimi dhe mirëmbajtja e tij.

Funksionimi i produktit softuerik konsiston në ekzekutimin e tij, funksionimin në një kompjuter për përpunimin e informacionit dhe marrjen e rezultateve që janë qëllimi i krijimit të tij, si dhe sigurimin e saktësisë dhe besueshmërisë së të dhënave të prodhuara.

Mirëmbajtja e Softuerit konsiston në mirëmbajtjen operacionale, zhvillimin funksionalitetin dhe rritjen e karakteristikave operacionale të produkteve softuerike, në replikimin dhe transferimin e produkteve softuerike në lloje të ndryshme objektet kompjuterike.

Shoqërimi luan një rol të domosdoshëm reagimet nga faza e operimit.

Gjatë funksionimit të softuerit, mund të zbulohen gabime në programe dhe ka nevojë për modifikimin e tyre dhe zgjerimin e funksioneve.

Këto përmirësime, si rregull, kryhen njëkohësisht me funksionimin e versionit aktual të produktit softuer. Pas kontrollit të rregullimeve të përgatitura në një nga kopjet e programit, versioni tjetër i produktit softuer zëvendëson ato të përdorura më parë ose disa prej tyre. Në këtë rast, procesi i funksionimit të një produkti softuer mund të jetë pothuajse i vazhdueshëm, pasi zëvendësimi i një versioni të një produkti softuerësh është afatshkurtër. Këto rrethana çojnë në faktin se procesi i funksionimit të një versioni të një produkti softuerësh zakonisht vazhdon paralelisht dhe pavarësisht nga faza e mirëmbajtjes.

Mbivendosja ndërmjet fazave të ciklit jetësor të produktit softuer

Mbivendosja ndërmjet fazave të ndryshme të ciklit jetësor të një produkti softuerësh është e mundur dhe zakonisht e dëshirueshme. Megjithatë, nuk duhet të ketë mbivendosje ndërmjet proceseve jo ngjitur.

Reagimi midis fazave është i mundur. Për shembull, gjatë një prej hapave të dizajnit të jashtëm, mund të zbulohen gabime në formulimin e qëllimeve, atëherë duhet të ktheheni menjëherë dhe t'i korrigjoni ato.

Modeli i konsideruar i ciklit jetësor të produktit softuer, me disa modifikime, mund të shërbejë si model për projekte të vogla.

Për shembull, kur projektohet një program i vetëm, shpesh është e mundur të shmanget dizajnimi i arkitekturës së sistemit dhe

dizajnimi i bazës së të dhënave; proceset fillestare dhe të detajuara të projektimit të jashtëm shpesh bashkohen, etj.

Standardet e ciklit jetësor të softuerit

• GOST 34.601-90
• ISO/IEC 12207:1995 ( Analog rus- GOST R ISO/IEC 12207-99)

Metodologjitë e zhvillimit të softuerit

• Procesi i Unifikuar Racional (RUP).
• Microsoft Solutions Framework (MSF). Përfshin 4 faza: analizë, dizajn, zhvillim, stabilizim dhe përfshin përdorimin e modelimit të orientuar nga objekti.
• Programim ekstrem ( Programim ekstrem, XP). Baza e metodologjisë punë ekipore, komunikim efektiv midis klientit dhe kontraktorit gjatë gjithë projektit të zhvillimit të IP. Zhvillimi kryhet duke përdorur prototipa të rafinuar në mënyrë të njëpasnjëshme.

Standardi GOST 34.601-90

Standardi GOST 34.601-90 parashikon fazat dhe fazat e mëposhtme të krijimit të një sistemi të automatizuar:

1. Formimi i kërkesave për folësit
   1. Inspektimi i objektit dhe arsyetimi për nevojën e krijimit të një centrali bërthamor
   2. Formimi i kërkesave të përdoruesve për folësit
   3. Përgatitja e një raporti për përfundimin e punës dhe një aplikim për zhvillimin e një NPP
2. Zhvillimi i konceptit të AC
   1. Studimi i objektit
   2. Kryerja e punës së nevojshme kërkimore
   3. Zhvillimi i opsioneve të konceptit AC dhe përzgjedhja e një opsioni koncepti AC që plotëson kërkesat e përdoruesit
   4. Hartimi i një raporti për punën e kryer
3. Kushtet e referencës
   1. Zhvillimi dhe miratimi termat e referencës për të krijuar një AS
4. Draft dizajn
   1. Zhvillimi i zgjidhjeve të projektimit paraprak për sistemin dhe pjesët e tij
5. Projekt teknik
   1. Zhvillimi i zgjidhjeve të projektimit për sistemin dhe pjesët e tij
   2. Zhvillimi i dokumentacionit për sistemin e altoparlantëve dhe pjesët e tij
   3. Zhvillimi dhe ekzekutimi i dokumentacionit për furnizimin e komponentëve
   4. Zhvillimi i detyrave të projektimit në pjesët ngjitur të projektit
6. Dokumentacioni i punës
   1. Hartimi i dokumentacionit të punës për TEC-in dhe pjesët e tij
   2. Zhvillimi dhe përshtatja e programeve
7. Komisionimi
   1. Përgatitja e një objekti automatizimi
   2. Trajnimi i personelit
   3. Set i plotë i altoparlantëve me produktet e furnizuara (softuer dhe mjete teknike, sistemet softuerike dhe harduerike, produktet e informacionit)
   4. Punimet e ndertimit dhe instalimit
   5. Puna komisionere
   6. Kryerja e testeve paraprake
   7. Kryerja e operacionit provë
   8. Kryerja e testeve të pranimit
8. Mbështetje AC.
   1. Kryerja e punës në përputhje me detyrimet e garancisë
   2. Shërbimi pas garancisë

Skicat, dizenjot teknike dhe dokumentacioni i punës janë ndërtimi konsistent i zgjidhjeve projektuese gjithnjë e më të sakta. Është e mundur që në të gjitha fazat të përjashtohen fazat e "Dizajnit të Skicave" dhe fazat individuale të punës, të kombinohen fazat "Dizajni Teknik" dhe "Dokumentacioni i Punës" në një "Projektim të Detajuar Teknik", për të kryer faza dhe punë të ndryshme paralelisht. , dhe për të përfshirë ato shtesë.

Ky standard nuk është plotësisht i përshtatshëm për zhvillimet aktuale: shumë procese nuk janë pasqyruar mjaftueshëm dhe disa dispozita janë të vjetruara.

Standardi ISO/IEC 12207/ dhe aplikimi i tij

Standardi ISO/IEC 12207:1995 "Teknologjia e Informacionit - Proceset e Ciklit të Jetës së Softuerit" është standardi kryesor dokument normativ rregullimi i përbërjes së proceseve të ciklit jetësor të softuerit. Ai përcakton një strukturë të ciklit jetësor që përmban proceset, aktivitetet dhe detyrat që duhet të kryhen gjatë krijimit të softuerit.

Çdo proces është i ndarë në një grup veprimesh, çdo veprim në një grup detyrash. Çdo proces, aktivitet ose detyrë inicohet dhe ekzekutohet nga një proces tjetër sipas nevojës dhe nuk ka sekuenca të paracaktuara ekzekutimi. Lidhjet ndërmjet të dhënave hyrëse ruhen.

Proceset e ciklit jetësor të softuerit

• Themelore:
  • Blerja (veprimet dhe detyrat e klientit që blen softuerin)
  • Dorëzimi (veprimet dhe detyrat e furnizuesit që furnizon klientin me një produkt ose shërbim softuerësh)
  • Zhvillimi (veprimet dhe detyrat e kryera nga zhvilluesi: krijimi i softuerit, hartimi dhe dokumentacioni operacional, përgatitja e testit dhe materiale edukative etj.)
  • Operacioni (veprimet dhe detyrat e operatorit - organizata që operon sistemin)
  • Mirëmbajtja (veprimet dhe detyrat e kryera nga organizata shoqëruese, domethënë shërbimi mbështetës). Mbështetje - duke bërë ndryshime në softuer për të korrigjuar gabimet, për të përmirësuar produktivitetin ose për t'u përshtatur me ndryshimin e kushteve ose kërkesave të funksionimit.
• Ndihmës
  • Dokumentacioni (përshkrim i formalizuar i informacionit të krijuar gjatë ciklit jetësor të softuerit)
  • Menaxhimi i konfigurimit (aplikimi i procedurave administrative dhe teknike gjatë gjithë ciklit jetësor të softuerit për të përcaktuar statusin e komponentëve të softuerit dhe për të menaxhuar modifikimet e tij).
  • Sigurimi i cilësisë (duke dhënë garanci që sistemi i informacionit dhe proceset e ciklit të tij jetësor përputhen me kërkesat e specifikuara dhe planet e miratuara)
  • Verifikimi (përcaktimi që produktet softuerike që rezultojnë nga ndonjë veprim i plotësojnë plotësisht kërkesat ose kushtet e vendosura nga veprimet e mëparshme)
  • Certifikimi (përcaktimi i plotësisë së përputhshmërisë së kërkesave të specifikuara dhe sistemit të krijuar me qëllimin e tyre specifik funksional)
  • Vlerësimi i përbashkët (vlerësimi i statusit të punës në projekt: kontrolli i planifikimit dhe menaxhimit të burimeve, personelit, pajisjeve, mjeteve)
  • Auditimi (përcaktimi i përputhshmërisë me kërkesat, planet dhe kushtet e kontratës)
  • Zgjidhja e problemit (analiza dhe zgjidhja e problemeve, pavarësisht nga origjina ose burimi i tyre, që zbulohen gjatë zhvillimit, funksionimit, mirëmbajtjes ose proceseve të tjera)
• Organizative
  • Kontrolli (veprimet dhe detyrat që mund të kryhen nga çdo palë që menaxhon proceset e saj)
  • Krijimi i infrastrukturës (përzgjedhja dhe mirëmbajtja e teknologjisë, standardeve dhe mjeteve, përzgjedhja dhe instalimi i harduerit dhe softuerit të përdorur për zhvillimin, funksionimin ose mirëmbajtjen e softuerit)
  • Përmirësimi (vlerësimi, matja, kontrolli dhe përmirësimi i proceseve të ciklit jetësor)
  • Trajnimi (trajnimi fillestar dhe zhvillimi i vazhdueshëm i stafit)

Çdo proces përfshin një numër veprimesh. Për shembull, procesi i blerjes mbulon aktivitetet e mëposhtme:

1. Fillimi i blerjes
2. Përgatitja e propozimeve të ofertave
3. Përgatitja dhe rregullimi i kontratës
4. Mbikëqyrja e aktiviteteve të furnitorëve
5. Pranimi dhe përfundimi i punës

Çdo aktivitet përfshin një sërë detyrash. Për shembull, përgatitja e propozimeve të ofertës duhet të përfshijë:

1. Formimi i kërkesave të sistemit
2. Krijimi i një liste të produkteve softuerike
3. Vendosja e kushteve dhe marrëveshjeve
4. Përshkrimi i kufizimeve teknike (mjedisi i funksionimit të sistemit, etj.)

Fazat e ciklit jetësor të softuerit, marrëdhëniet ndërmjet proceseve dhe fazave

Modeli i ciklit jetësor të softuerit- një strukturë që përcakton sekuencën e ekzekutimit dhe marrëdhëniet midis proceseve, veprimeve dhe detyrave gjatë gjithë ciklit jetësor. Modeli i ciklit jetësor varet nga specifikat, shkalla dhe kompleksiteti i projektit dhe kushtet specifike në të cilat sistemi është krijuar dhe funksionon.

Standardi GOST R ISO/IEC 12207-99 nuk ofron model specifik cikli jetësor. Dispozitat e tij janë të zakonshme për çdo model të ciklit jetësor, metoda dhe teknologji për krijimin e IP. Ai përshkruan strukturën e proceseve të ciklit jetësor pa specifikuar se si të zbatohen ose plotësohen aktivitetet dhe detyrat e përfshira në ato procese.

Modeli i ciklit jetësor të softuerit përfshin:

1. Fazat;
2. Rezultatet e punës në çdo fazë;
3. Ngjarjet kryesore janë pikat e përfundimit të punës dhe të vendimmarrjes.

Skena- pjesë e procesit të krijimit të softuerit, e kufizuar nga një kornizë kohore e caktuar dhe që përfundon me lëshimin e një produkti specifik (modele, komponentë softuerësh, dokumentacion), të përcaktuar nga kërkesat e specifikuara për këtë fazë.

Në çdo fazë, mund të kryhen disa procese të përcaktuara në standardin GOST R ISO/IEC 12207-99 dhe anasjelltas, i njëjti proces mund të kryhet në faza të ndryshme. Marrëdhënia midis proceseve dhe fazave përcaktohet gjithashtu nga modeli i ciklit jetësor të softuerit të përdorur.

Modelet e ciklit jetësor të softuerit

Një model i ciklit jetësor është një strukturë që përcakton sekuencën e ekzekutimit dhe marrëdhëniet e proceseve, aktiviteteve dhe detyrave të kryera gjatë gjithë ciklit jetësor. Modeli i ciklit jetësor varet nga specifikat sistemi i informacionit dhe specifikat e kushteve në të cilat krijohet dhe funksionon kjo e fundit

Deri më sot, modelet kryesore të ciklit jetësor të mëposhtëm janë bërë më të përhapura:

• Modeli i problemit;

• modeli (ose sistemi) kaskadë (70-85);

• model spirale (i pranishëm).

Modeli i problemit

Kur zhvillohet një sistem "nga poshtë-lart" nga detyrat individuale në të gjithë sistemin (modeli i detyrës), një qasje e unifikuar ndaj zhvillimit humbet në mënyrë të pashmangshme dhe lindin probleme në lidhjen e informacionit të komponentëve individualë. Si rregull, me rritjen e numrit të detyrave, vështirësitë rriten dhe është e nevojshme të ndryshohen vazhdimisht programet ekzistuese dhe strukturat e të dhënave. Shpejtësia e zhvillimit të sistemit ngadalësohet, gjë që ngadalëson zhvillimin e vetë organizatës. Megjithatë, në disa raste kjo teknologji mund të jetë e këshillueshme:

• Urgjenca ekstreme (problemet duhet të zgjidhen disi; atëherë gjithçka do të duhet të bëhet përsëri);

• Eksperimenti dhe përshtatja e klientit (algoritmet nuk janë të qarta, zgjidhjet gjenden me provë dhe gabim).

Përfundim i përgjithshëm: është e pamundur të krijohet një sistem informacioni mjaft i madh dhe efektiv në këtë mënyrë.

Modeli i kaskadës

Modeli i kaskadës Cikli jetësor u propozua në vitin 1970 nga Winston Royce. Ai parashikon zbatimin vijues të të gjitha fazave të projektit në një mënyrë rreptësisht të caktuar. Shko tek fazën tjetër nënkupton përfundimin e plotë të punës në fazën e mëparshme (Fig. 1). Kërkesat e përcaktuara në fazën e formimit të kërkesave dokumentohen rreptësisht në formën e specifikimeve teknike dhe regjistrohen për të gjithë zhvillimin e projektit. Çdo fazë kulmon me lëshimin e një grupi të plotë dokumentacioni të mjaftueshëm për të lejuar vazhdimin e zhvillimit nga një ekip tjetër zhvillimi.

Aspektet pozitive të përdorimit të qasjes së kaskadës janë si më poshtë:

• në çdo fazë, gjenerohet një grup i plotë i dokumentacionit të projektimit që plotëson kriteret e plotësisë dhe konsistencës;

• fazat e punës së kryer në një sekuencë logjike bëjnë të mundur planifikimin e kohës së përfundimit të të gjithë punës dhe kostot përkatëse.

Fazat e projektit sipas modelit të ujëvarës:

1. Formimi i kërkesave;
2. Dizajn;
3. Zbatimi;
4. Testimi;
5. Zbatimi;
6. Funksionimi dhe mirëmbajtja.

Oriz. 1. Skema e zhvillimit të kaskadës

Qasja e kaskadës e ka dëshmuar veten mirë në ndërtimin e sistemeve të informacionit, për të cilat në fillim të zhvillimit të gjitha kërkesat mund të formulohen mjaft saktë dhe plotësisht në mënyrë që t'u jepet zhvilluesve lirinë për t'i zbatuar ato sa më mirë që të jetë e mundur nga një pikë teknike. pamje. Sistemet komplekse të llogaritjes, sistemet në kohë reale dhe detyra të tjera të ngjashme bien në këtë kategori. Sidoqoftë, në procesin e përdorimit të kësaj qasjeje, u zbuluan një sërë mangësish të saj, të shkaktuara kryesisht nga fakti se procesi real i krijimit të sistemeve nuk përshtatet kurrë plotësisht në një skemë kaq të ngurtë. Gjatë procesit të krijimit, ka pasur një nevojë të vazhdueshme për t'u kthyer në fazat e mëparshme dhe për të qartësuar ose rishikuar vendimet e marra më parë. Si rezultat, procesi aktual i krijimit të softuerit mori formën e mëposhtme (Fig. 2):

Oriz. 2. Procesi real i zhvillimit të softuerit duke përdorur një skemë ujëvarë

Disavantazhi kryesor i qasjes së kaskadës është vonesa e konsiderueshme në marrjen e rezultateve. Koordinimi i rezultateve me përdoruesit kryhet vetëm në pikat e planifikuara pas përfundimit të secilës fazë të punës, kërkesat për sistemet e informacionit janë "ngrirë" në formën e specifikimeve teknike për të gjithë kohën e krijimit të tij. Kështu, përdoruesit mund të bëjnë komentet e tyre vetëm pasi të ketë përfunduar plotësisht puna në sistem. Nëse kërkesat janë deklaruar në mënyrë të pasaktë ose ato ndryshojnë gjatë një periudhe të gjatë të zhvillimit të softuerit, përdoruesit përfundojnë me një sistem që nuk i plotëson nevojat e tyre. Modelet (si funksionale ashtu edhe ato informative) të objektit të automatizuar mund të bëhen të vjetëruara njëkohësisht me miratimin e tyre. Thelbi qasje sistematike zhvillimi i një SI qëndron në zbërthimin (zbërthimin) e tij në funksione të automatizuara: sistemi ndahet në nënsisteme funksionale, të cilat nga ana e tyre ndahen në nënfunksione, të nënndara në detyra, etj. Procesi i ndarjes vazhdon deri në procedura specifike. Në të njëjtën kohë, sistemi i automatizuar mban një pamje holistike në të cilën të gjithë komponentët janë të ndërlidhur. Kështu, ky model ka përparësinë kryesore të zhvillimit sistematik, dhe disavantazhet kryesore janë se është i ngadalshëm dhe i shtrenjtë.

Modeli spirale

Për të kapërcyer këto probleme, u propozua model spirale cikli jetësor (Figura 3), i cili u zhvillua në mesin e viteve 1980 nga Barry Boehm. Ai bazohet në fazat fillestare të ciklit jetësor: analiza dhe dizajni. Në këto faza, realizueshmëria e zgjidhjeve teknike testohet duke krijuar prototipa.

Prototip- një komponent softuerik operativ që zbaton funksionet individuale dhe ndërfaqet e jashtme. Çdo përsëritje korrespondon me krijimin e një fragmenti ose versioni të softuerit, në të cilin qartësohen qëllimet dhe karakteristikat e projektit, vlerësohet cilësia e rezultateve të marra dhe planifikohet puna e përsëritjes tjetër.

Çdo përsëritje përfaqëson një cikël të plotë zhvillimi, që rezulton në lëshimin e një versioni të brendshëm ose të jashtëm të një produkti (ose një nëngrupi të produktit përfundimtar) që përmirësohet nga përsëritja në përsëritje për t'u bërë një sistem i plotë.

Çdo kthesë e spirales korrespondon me krijimin e një fragmenti ose versioni të softuerit, ku qartësohen qëllimet dhe karakteristikat e projektit, përcaktohet cilësia e tij dhe planifikohet puna e kthesës tjetër të spirales. Kështu, detajet e projektit thellohen dhe saktësohen në mënyrë konsekuente dhe si rrjedhojë zgjidhet një opsion i arsyeshëm, i cili vihet në zbatim.

Zhvillimi me përsëritje pasqyron ciklin spirale ekzistues objektiv të krijimit të një sistemi. Përfundimi jo i plotë i punës në çdo fazë ju lejon të kaloni në fazën tjetër pa pritur përfundimin e plotë të punës në atë aktuale. Me një metodë zhvillimi iterativ, puna që mungon mund të plotësohet në përsëritjen tjetër. Detyra kryesore është t'u tregohet përdoruesve të sistemit një produkt të zbatueshëm sa më shpejt të jetë e mundur, duke aktivizuar kështu procesin e sqarimit dhe plotësimit të kërkesave.

Problemi kryesor i ciklit spirale është përcaktimi i momentit të kalimit në fazën tjetër. Për ta zgjidhur atë, është e nevojshme të futen kufizime kohore për secilën fazë të ciklit jetësor. Tranzicioni vazhdon siç është planifikuar, edhe nëse jo të gjitha punët e planifikuara janë përfunduar. Plani është hartuar në bazë të të dhënave statistikore të marra në projektet e mëparshme dhe përvojë personale zhvilluesit.

Figura 3. Modeli spirale i ciklit jetësor të një IC

Një qasje e mundshme për zhvillimin e softuerit brenda modelit të ciklit jetësor spirale është metodologjia RAD (Rapid Application Development), e cila kohët e fundit është bërë e përhapur. Ky term zakonisht i referohet një procesi të zhvillimit të softuerit që përmban 3 elementë:

• një ekip i vogël programuesish (nga 2 deri në 10 persona);

• orar i shkurtër, por i përpunuar me kujdes i prodhimit (nga 2 në 6 muaj);

• një cikël përsëritës në të cilin zhvilluesit, kur aplikacioni fillon të marrë formë, kërkojnë dhe zbatojnë në produkt kërkesat e marra përmes ndërveprimit me klientin.

Cikli i jetës së softuerit sipas metodologjisë RAD përbëhet nga katër faza:

• faza e përcaktimit dhe analizës së kërkesave;

• faza e projektimit;

• faza e zbatimit;

• faza e zbatimit.

Në çdo përsëritje vlerësohen sa vijon:

• rreziku i tejkalimit të afateve dhe kostove të projektit;
• nevoja për të kryer një përsëritje tjetër;
• shkalla e plotësisë dhe saktësisë së të kuptuarit të kërkesave të sistemit;
• fizibiliteti i përfundimit të projektit.

Përparësitë e qasjes përsëritëse:

• Zhvillimi përsëritës thjeshton shumë ndryshimet në projekt kur ndryshojnë kërkesat e klientëve.
• Kur përdorni modelin spirale, elementët individualë të sistemit të informacionit integrohen gradualisht në një tërësi të vetme. Me një qasje përsëritëse, integrimi ndodh praktikisht vazhdimisht. Duke qenë se integrimi fillon me më pak elementë, ka shumë më pak probleme gjatë zbatimit të tij (sipas disa vlerësimeve, kur përdoret modeli i zhvillimit të ujëvarës, integrimi përbën deri në 40% të të gjitha kostove në fund të projektit).
• Zhvillimi përsëritës siguron fleksibilitet më të madh në menaxhimin e projektit, duke bërë të mundur që të bëhen ndryshime taktike në produktin që po zhvillohet.
• Qasja përsëritëse thjeshton ripërdorimin e komponentëve (zbaton një qasje të bazuar në komponentë në programim). Kjo është për shkak se është shumë më e lehtë të identifikohen pjesët e përbashkëta të një projekti kur ato janë tashmë pjesërisht të zhvilluara sesa të përpiqesh t'i identifikosh ato që në fillim të projektit. Analizimi i dizajnit pas disa përsëritjeve fillestare zbulon komponentë të zakonshëm, të ripërdorshëm që do të përmirësohen në përsëritjet pasuese.
• Modeli spirale ju lejon të merrni një më të besueshëm dhe sistem të qëndrueshëm. Kjo ndodh sepse ndërsa sistemi evoluon, gabimet dhe dobësitë zbulohen dhe korrigjohen në çdo përsëritje. Në të njëjtën kohë, parametrat kritikë të performancës mund të rregullohen, gjë që në rastin e një modeli kaskadë është e mundur vetëm përpara se sistemi të zbatohet.
• Qasja përsëritëse bën të mundur përmirësimin e procesit të zhvillimit - analiza e kryer në fund të çdo përsëritjeje na lejon të vlerësojmë se çfarë duhet të ndryshohet në organizatën e zhvillimit dhe ta përmirësojmë atë në përsëritjen tjetër.

Duhet të fillojmë duke përcaktuarCikli i jetës së softuerit(Modeli i Ciklit të Jetës së Softuerit) është një periudhë kohore që fillon nga momenti kur merret vendimi për të krijuar një produkt softuer dhe përfundon në momentin që ai hiqet plotësisht nga shërbimi. Ky cikël është procesi i ndërtimit dhe zhvillimit të softuerit.

Modelet e ciklit jetësor të softuerit

Cikli i jetës mund të përfaqësohet në formën e modeleve. Aktualisht më të zakonshmet janë:kaskadë, në rritje (model hap pas hapi me kontroll të ndërmjetëm ) Dhe spiralemodelet e ciklit jetësor.

Modeli i kaskadës

Modeli i kaskadës(anglisht) modeli i ujëvarës) është një model i procesit të zhvillimit të softuerit, cikli jetësor i të cilit duket si një rrjedhë që kalon në mënyrë sekuenciale nëpër fazat e analizës dhe projektimit të kërkesave. zbatimin, testimin, integrimin dhe mbështetjen.

Procesi i zhvillimit zbatohet përmes një sekuence të urdhëruar hapash të pavarur. Modeli parashikon që çdo hap pasues fillon pasi hapi i mëparshëm është përfunduar plotësisht. Në të gjitha hapat e modelit, ndihmës dhe proceset organizative dhe punë duke përfshirë menaxhimin e projektit, vlerësimin dhe menaxhimin e cilësisë, verifikimin dhe certifikimin, menaxhimin e konfigurimit, zhvillimin e dokumentacionit. Si rezultat i përfundimit të hapave, formohen produkte të ndërmjetme që nuk mund të ndryshohen në hapat pasues.

Cikli i jetës tradicionalisht ndahet në kryesoret e mëposhtmefazat:

1. Analiza e Kërkesave,
2. Dizajn,
3. Kodimi (programimi),
4. Testimi dhe korrigjimi,
5. Funksionimi dhe mirëmbajtja.

Përparësitë e modelit:

• stabiliteti i kërkesave gjatë gjithë ciklit jetësor të zhvillimit;
• në çdo fazë, gjenerohet një grup i plotë i dokumentacionit të projektimit që plotëson kriteret e plotësisë dhe konsistencës;
• siguria dhe qartësia e hapave të modelit dhe lehtësia e zbatimit të tij;
• fazat e punës së kryer në një sekuencë logjike bëjnë të mundur planifikimin e kohës së përfundimit të të gjithë punës dhe burimeve përkatëse (monetare, materiale dhe njerëzore).

Disavantazhet e modelit:

• vështirësia e formulimit të qartë të kërkesave dhe pamundësia për t'i ndryshuar ato në mënyrë dinamike gjatë gjithë ciklit të jetës;
• fleksibilitet i ulët në menaxhimin e projektit;
• pasues strukturë lineare procesi i zhvillimit, si rezultat, kthimi në hapat e mëparshëm për zgjidhjen e problemeve të shfaqura çon në rritje të kostove dhe prishje të orarit të punës;
• papërshtatshmëria e produktit të ndërmjetëm për përdorim;
• pamundësia e modelimit fleksibël të sistemeve unike;
• Zbulimi i vonshëm i problemeve të montimit për shkak të integrimit të njëkohshëm të të gjitha rezultateve në fund të zhvillimit;
• pjesëmarrja e pamjaftueshme e përdoruesit në krijimin e sistemit - në fillim (gjatë zhvillimit të kërkesave) dhe në fund (gjatë testeve të pranimit);
• përdoruesit nuk mund të jenë të sigurt për cilësinë e produktit që po zhvillohet derisa të përfundojë i gjithë procesi i zhvillimit. Ata nuk kanë mundësinë të vlerësojnë cilësinë, pasi është e pamundur të shihet produkti i përfunduar i zhvillimit;
• përdoruesi nuk ka mundësi të mësohet gradualisht me sistemin. Procesi i mësimit ndodh në fund të ciklit jetësor, kur softueri është vënë tashmë në funksion;
• secila fazë është një parakusht për veprimet e mëvonshme, gjë që e bën këtë metodë një zgjedhje të rrezikshme për sistemet që nuk kanë analoge, sepse nuk i përshtatet modelimit fleksibël.

Është e vështirë të zbatohet modeli i ciklit jetësor të Kaskadës për shkak të kompleksitetit të zhvillimit të një sistemi softuerësh pa u kthyer në hapat e mëparshëm dhe pa ndryshuar rezultatet e tyre për të eliminuar problemet e shfaqura.

Fusha e zbatimit të modelit Kaskadë

Kufizimi i fushës së aplikimit të modelit të kaskadës përcaktohet nga të metat e tij. Përdorimi i tij është më efektiv në rastet e mëposhtme:

1. kur zhvillohen projekte me të qarta, të pandryshueshmecikli jetësor kërkesat, zbatimi i kuptueshëm dhe metodat teknike;
2. kur zhvillon një projekt të fokusuar në ndërtimin e një sistemi ose produkti të të njëjtit lloj që është zhvilluar tashmë nga zhvilluesit më parë;
3. kur zhvillon një projekt në lidhje me krijimin dhe lëshimin version i ri një produkt ose sistem ekzistues;
4. kur zhvillon një projekt në lidhje me transferimin e një produkti ose sistemi ekzistues në një platformë të re;
5. kur ekzekutoni projekte të mëdha që përfshijnë disa ekipe të mëdha zhvillimi.

Modeli në rritje

(modeli hap pas hapi me kontroll të ndërmjetëm)

Modeli në rritje(anglisht) rritje- rritje, rritje) nënkupton zhvillimin e softuerit me një sekuencë lineare fazash, por në disa rritje (versione), d.m.th. me përmirësime të planifikuara të produktit për të gjithë kohën derisa të përfundojë Cikli Jetës i Zhvillimit të Softuerit.

Zhvillimi i softuerit ndodh në përsëritje, me cikle reagimesh ndërmjet fazave. Rregullimet ndërfazore bëjnë të mundur që të merret parasysh ndikimi aktual i ndërsjellë i rezultateve të zhvillimit në faza të ndryshme, jetëgjatësia e secilës fazë zgjatet gjatë gjithë periudhës së zhvillimit.

Në fillim të punës në projekt, të gjitha kërkesat themelore për sistemin përcaktohen dhe ndahen në ato gjithnjë e më pak të rëndësishme. Sistemi më pas zhvillohet gradualisht në mënyrë që zhvilluesi të mund të përdorë të dhënat e marra gjatë zhvillimit të softuerit. Çdo rritje duhet të shtojë funksione të caktuara në sistem. Në këtë rast, lëshimi fillon me komponentët me përparësinë më të lartë. Pasi të identifikohen pjesët e sistemit, merrni pjesën e parë dhe filloni ta detajoni duke përdorur procesin më të përshtatshëm për këtë. Në të njëjtën kohë, është e mundur të sqarohen kërkesat për pjesët e tjera që janë ngrirë në grupin aktual të kërkesave për këtë punë. Nëse është e nevojshme, mund të ktheheni në këtë pjesë më vonë. Nëse pjesa është gati, i dorëzohet klientit, i cili mund ta përdorë atë në punën e tij. Kjo do t'i lejojë klientit të qartësojë kërkesat për komponentët e mëposhtëm. Pastaj ata zhvillojnë pjesën tjetër të sistemit. Pikat kryesore Ky proces përfshin thjesht zbatimin e një nëngrupi të kërkesave të softuerit dhe rafinimin e modelit në një seri lëshimesh të njëpasnjëshme derisa softueri të zbatohet plotësisht.

Cikli jetësor i këtij modeli është tipik kur zhvillohet kompleks dhe sisteme komplekse, për të cilat ekziston një vizion i qartë (si nga ana e klientit ashtu edhe nga ana e zhvilluesit) se çfarë rezultati përfundimtar. Zhvillimi i versionit kryhet për arsye të ndryshme:

• paaftësia e klientit për të financuar të gjithë projektin e shtrenjtë menjëherë;
• zhvilluesit i mungojnë burimet e nevojshme për të zbatuar një projekt kompleks në një kohë të shkurtër;
• kërkesat për zbatimin në faza dhe miratimin e produktit nga përdoruesit përfundimtarë. Zbatimi i të gjithë sistemit menjëherë mund të shkaktojë refuzim tek përdoruesit e tij dhe vetëm të "ngadalësojë" procesin e kalimit në teknologjitë e reja. Në mënyrë figurative, ata thjesht mund të "mos tresin një copë të madhe, kështu që duhet të copëtohet dhe të jepet në pjesë".

Avantazhet Dhe të metatKy model (strategji) janë të njëjta me ato të ujëvarës (modeli klasik i ciklit jetësor). Por ndryshe nga strategjia klasike, klienti mund të shohë rezultatet më herët. Bazuar në rezultatet e zhvillimit dhe zbatimit të versionit të parë, ai mund të ndryshojë pak kërkesat për zhvillim, ta braktisë atë ose të ofrojë zhvillimin e një produkti më të avancuar me lidhjen e një kontrate të re.

Përparësitë:

• kostot e bëra për shkak të ndryshimeve në kërkesat e përdoruesve janë reduktuar, ri-analiza dhe dokumentacioni janë reduktuar ndjeshëm në krahasim me modelin e ujëvarës;
• Është më e lehtë të marrësh komente nga klienti për punën e bërë - klientët mund të shprehin komentet e tyre për pjesët e përfunduara dhe mund të shohin se çfarë është bërë tashmë. Sepse Pjesët e para të sistemit janë një prototip i sistemit në tërësi.
• klienti ka aftësinë për të marrë dhe zotëruar shpejt softuerin - klientët mund të realizojnë përfitime reale nga sistemi më shpejt se sa do të ishte e mundur me një model ujëvarë.

Disavantazhet e modelit:

• menaxherët duhet të masin vazhdimisht progresin e procesit. në rastin e zhvillimit të shpejtë, nuk duhet të krijoni dokumente për çdo ndryshim minimal të versionit;
• struktura e një sistemi tenton të përkeqësohet me shtimin e komponentëve të rinj - ndryshimet e vazhdueshme prishin strukturën e sistemit. Për të shmangur këtë ju duhet kohë shtesë dhe para për rifaktorim. Dizajni i dobët e bën softuerin të vështirë dhe të shtrenjtë për ta ndryshuar më vonë. Dhe një cikël jetësor i ndërprerë i softuerit çon në humbje edhe më të mëdha.

Skema nuk ju lejon të merrni parasysh shpejt ndryshimet në zhvillim dhe sqarimet e kërkesave të softuerit. Koordinimi i rezultateve të zhvillimit me përdoruesit kryhet vetëm në pikat e planifikuara pas përfundimit të secilës fazë të punës, dhe kërkesat e përgjithshme në softuer regjistrohen në formën e specifikimeve teknike për të gjithë kohën e krijimit të tij. Kështu, përdoruesit shpesh marrin softuer që nuk i plotëson nevojat e tyre reale.

Modeli spirale

Modeli spirale:Cikli i jetës - në çdo kthesë të spirales, krijohet versioni tjetër i produktit, qartësohen kërkesat e projektit, përcaktohet cilësia e tij dhe planifikohet puna e kthesës tjetër. Vëmendje e veçantë paguhet në fazat fillestare të zhvillimit - analizës dhe projektimit, ku testohet dhe justifikohet fizibiliteti i zgjidhjeve të caktuara teknike përmes krijimit të prototipeve.

Ky model është një proces zhvillimi softuerësh që kombinon dizajnin dhe prototipin në rritje për të kombinuar përfitimet e koncepteve nga poshtë-lart dhe nga lart-poshtë, duke theksuar fazat fillestare cikli i jetës: analiza dhe dizajni.Tipar dallues Ky model i kushton vëmendje të veçantë rreziqeve që ndikojnë në organizimin e ciklit jetësor.

Në fazat e analizës dhe projektimit, realizueshmëria e zgjidhjeve teknike dhe shkalla në të cilën plotësohen nevojat e klientëve verifikohen duke krijuar prototipa. Çdo kthesë e spirales korrespondon me krijimin e një fragmenti ose versioni të funksionueshëm të sistemit. Kjo ju lejon të sqaroni kërkesat, qëllimet dhe karakteristikat e projektit, të përcaktoni cilësinë e zhvillimit dhe të planifikoni punën e kthesës tjetër të spiralës. Në këtë mënyrë thellohen dhe specifikohen në mënyrë konsistente detajet e projektit dhe si rezultat zgjidhet një opsion i arsyeshëm që plotëson kërkesat aktuale të klientit dhe vihet në zbatim.

Cikli i jetës në çdo kthesë të spirales - mund të përdoret modele të ndryshme procesi i zhvillimit të softuerit. Në fund të fundit, produkti është një produkt i përfunduar. Modeli kombinon aftësitë e një modeli prototipues dhemodeli i ujëvarës. Zhvillimi me përsëritje pasqyron ciklin spirale ekzistues objektiv të krijimit të një sistemi. Përfundimi jo i plotë i punës në çdo fazë ju lejon të kaloni në fazën tjetër pa pritur përfundimin e plotë të punës në atë aktuale. Detyra kryesore është t'u tregohet përdoruesve të sistemit një produkt të zbatueshëm sa më shpejt të jetë e mundur, duke aktivizuar kështu procesin e sqarimit dhe plotësimit të kërkesave.

Përparësitë e modelit:

• ju lejon t'u tregoni shpejt përdoruesve të sistemit një produkt të zbatueshëm, duke aktivizuar kështu procesin e sqarimit dhe plotësimit të kërkesave;
• lejon ndryshime në kërkesat gjatë zhvillimit të softuerit, gjë që është tipike për shumicën e zhvillimeve, përfshirë ato standarde;
• modeli lejon dizajn fleksibël sepse mishëron përfitimet e modelit të ujëvarës, ndërsa në të njëjtën kohë lejon përsëritjet në të gjitha fazat e të njëjtit model;
• ju lejon të merrni një sistem më të besueshëm dhe të qëndrueshëm. Ndërsa softueri evoluon, gabimet dhe dobësitë zbulohen dhe korrigjohen në çdo përsëritje;
• ky model i lejon përdoruesit të marrin pjesë aktive në aktivitetet e planifikimit, analizës së rrezikut, projektimit dhe vlerësimit;
• rreziqet e klientëve janë reduktuar. Klienti mund të përfundojë zhvillimin e një projekti jo premtues me humbje minimale financiare;
• Reagimet nga përdoruesit tek zhvilluesit ndodhin me frekuencë të lartë dhe në fillim të modelit, gjë që siguron krijimin e produktit të dëshiruar me cilësi të lartë.

Disavantazhet e modelit:

• nëse projekti është me rrezik të ulët ose i vogël në përmasa, modeli mund të jetë i shtrenjtë. Vlerësimi i rrezikut pas çdo spirale shoqërohet me kosto të larta;
• Cikli i jetës së modelit ka një strukturë komplekse, kështu që përdorimi i tij nga zhvilluesit, menaxherët dhe klientët mund të jetë i vështirë;
• spiralja mund të vazhdojë pafundësisht, pasi çdo përgjigje e klientit ndaj versionit të krijuar mund të gjenerojë një cikël të ri, i cili vonon përfundimin e projektit;
• një numër i madh i cikleve të ndërmjetme mund të çojë në nevojën për të përpunuar dokumentacion shtesë;
• përdorimi i modelit mund të rezultojë i shtrenjtë dhe madje i papërballueshëm, sepse koha. koha e shpenzuar për planifikimin, ripërcaktimin e qëllimeve, kryerjen e analizave të rrezikut dhe prototipimin mund të jetë e tepërt;
• Mund të jetë e vështirë të përcaktohen qëllimet dhe piketa që tregojnë gatishmërinë për të vazhduar procesin e zhvillimit në të ardhmen dhe

Problemi kryesor i ciklit spirale është përcaktimi i momentit të kalimit në fazën tjetër. Për të zgjidhur këtë problem, futen kufizime kohore për çdo fazë.cikli jetësor dhe tranzicioni vazhdon siç është planifikuar, edhe nëse jo e gjithë puna e planifikuar është përfunduar.Planifikimiprodhuar në bazë të të dhënave statistikore të marra në projektet e mëparshme dhe përvojën personale të zhvilluesve.

Fusha e zbatimit të modelit spirale

Përdorimi i modelit spirale këshillohet në rastet e mëposhtme:

• kur zhvilloni projekte duke përdorur teknologji të reja;
• kur zhvillon një seri të re produktesh ose sistemesh;
• kur zhvilloni projekte me ndryshime të rëndësishme ose shtesa të pritshme në kërkesa;
• për të realizuar projekte afatgjata;
• kur zhvilloni projekte që kërkojnë demonstrimin e cilësisë dhe versioneve të një sistemi ose produkti për një periudhë të shkurtër kohore;
• gjatë zhvillimit të projekteve. për të cilat është e nevojshme të llogariten kostot që lidhen me vlerësimin dhe zgjidhjen e rreziqeve.

Shënim.

Hyrje.

1. Cikli i jetës së softuerit

Hyrje.

Hapat e procesit të programimit Riley

Hyrje.

1.1.1. Deklarata e problemit.

1.1.2. Dizajni i zgjidhjes.

1.1.3. Kodimi i algoritmit.

1.1.4. Mbështetja e programit.

1.1.5. Dokumentacioni i softuerit.

Konkluzioni për pikën 1.1

1.2. Përkufizimi i LCPO sipas Lehman.

Hyrje.

1.2.1 Përkufizimi i sistemit.

1.2.2. Zbatimi.

1.2.3. Shërbimi.

Konkluzioni për pikën 1.2.

1.3. Fazat dhe puna e LCPO sipas Boehm

1.3.1. Modeli kaskadë.

1.3.2. Arsyetimi ekonomik modeli i kaskadës.

1.3.3. Përmirësimi i modelit të kaskadës.

1.3.4. Përcaktimi i fazave të ciklit jetësor.

1.3.5. Puna kryesore në projekt.

Letërsia.

Hyrje

Aplikim Industrial kompjuterët dhe kërkesa në rritje për programe kanë shtruar detyra urgjente për t'u rritur ndjeshëm produktiviteti i zhvillimit të softuerit, zhvillimi i metodave industriale të planifikimit dhe hartimit të programeve, transferimi i teknikave, modeleve dhe metodave organizative, teknike, teknike, ekonomike dhe socio-psikologjike nga sfera. prodhim material në fushën e aplikacioneve kompjuterike. Qasje e integruar proceseve të zhvillimit, funksionimit dhe mirëmbajtjes së softuerit ka paraqitur një sërë problemesh të ngutshme, zgjidhja e të cilave do të eliminojë " fyte të ngushta"në hartimin e programit, do të zvogëlojë kohën e përfundimit, do të përmirësojë përzgjedhjen dhe përshtatjen e programeve ekzistuese dhe ndoshta do të përcaktojë fatin e sistemeve me kompjuterë të integruar.

Në praktikën e zhvillimit të projekteve të mëdha softuerike, shpesh nuk ka qasje të unifikuar për të vlerësuar kostot e punës, kohën e punës dhe kostot materiale, e cila pengon përmirësimin e produktivitetit të zhvillimit të softuerit, dhe në fund - menaxhim efektiv cikli jetësor i softuerit. Meqenëse një program i çdo lloji bëhet produkt (përveç, ndoshta, programeve edukative, prototip), qasja ndaj prodhimit të tij duhet në shumë mënyra të jetë e ngjashme me qasjen ndaj prodhimit të produkteve industriale, dhe çështjet e hartimit të programit bëhen jashtëzakonisht të rëndësishme. Kjo ide është në qendër të librit të B.W. "Inxhinieri Softuerike" e Boehm-it, të cilën e përdorëm për ta shkruar këtë puna e kursit. Në këtë libër, dizajni i softuerit i referohet procesit të krijimit të një dizajni për një produkt softuer.

1 Cikli i jetës së softuerit

HYRJE

ZHTSPO është proces i vazhdueshëm, i cili fillon nga momenti kur merret një vendim për nevojën e krijimit të softuerit dhe përfundon në momentin kur ai është hequr plotësisht nga shërbimi.

Ekzistojnë disa qasje për përcaktimin e fazave dhe aktiviteteve të ciklit jetësor të softuerit (SLC), hapave të procesit të programimit, modeleve kaskadë dhe spirale. Por të gjitha ato përmbajnë komponentë të përbashkët themelorë: deklaratën e problemit, dizajnin e zgjidhjes, zbatimin, mirëmbajtjen.

Më e famshmja dhe më e plota, ndoshta, është struktura e cikleve të jetës së Boehm, e cila përfshin tetë faza. Do të prezantohet më në detaje në të ardhmen.

Një nga opsionet e mundshme mund të shërbejë një përshkrim i nivelit të lartë sipas Lehmann, i cili përfshin tre faza kryesore dhe përfaqëson një përshkrim të ciklit jetësor në rastin më të përgjithshëm.

Dhe, për shumëllojshmëri, ne paraqesim hapat e procesit të programimit të paraqitur nga D. Riley në librin “Using the Modula-2 Language”. Kjo ide, për mendimin tim, është shumë e thjeshtë dhe e njohur, dhe le të fillojmë me të.

1.1 Hapat në procesin e programimit Riley

Procesi i programimit përfshin katër hapa (Figura 1):

deklarimi i problemit, d.m.th. marrjen e një kuptimi adekuat se çfarë detyre duhet të kryejë programi;

hartimi i një zgjidhjeje për një problem të deklaruar tashmë (në përgjithësi, një zgjidhje e tillë është më pak formale se programi përfundimtar);

kodimi i programit, pra përkthimi i zgjidhjes së projektuar në një program që mund të ekzekutohet në një makinë;

mbështetjen e programit, d.m.th. procesi i vazhdueshëm i zgjidhjes së problemeve të programit dhe shtimit të veçorive të reja.

Oriz. 1.Katër hapa programimi.

Programimi fillon nga momenti kur përdorues, d.m.th. dikush që ka nevojë për një program për të zgjidhur një problem e deklaron problemin analist i sistemit. Përdoruesi dhe analisti i sistemit përcaktojnë së bashku deklaratën e problemit. Kjo e fundit më pas transmetohet algoritmisti, i cili është përgjegjës për hartimin e zgjidhjes. Një zgjidhje (ose algoritëm) përfaqëson një sekuencë operacionesh, ekzekutimi i të cilave çon në zgjidhjen e një problemi. Meqenëse algoritmi shpesh nuk është i përshtatshëm për ekzekutim në një makinë, ai duhet të përkthehet në një program makine. Ky operacion kryhet nga koduesi. Programuesi shoqërues është përgjegjës për ndryshimet e mëvonshme në program. Dhe analisti i sistemit, dhe algoritmisti, dhe koduesi dhe programuesi shoqërues - ata janë të gjithë programues.

Në rastin e një projekti të madh softuerësh, numri i përdoruesve, analistëve të sistemit dhe algoritmistëve mund të jetë i rëndësishëm. Përveç kësaj, mund të jetë e nevojshme të ktheheni në hapat e mëparshëm për shkak të rrethanave të paparashikuara. E gjithë kjo shërben si një argument shtesë për hartimin e kujdesshëm të softuerit: rezultatet e secilit hap duhet të jenë të plota, të sakta dhe të kuptueshme.

1.1.1 Paraqitja e problemit

Një nga më hapa të rëndësishëm programimi është deklarata e problemit. Ajo funksionon si një kontratë midis përdoruesit dhe programuesit. Ashtu si një kontratë e hartuar dobët ligjërisht, një deklaratë e dobët e problemit është e padobishme. Me një deklaratë të mirë problemi, si përdoruesi ashtu edhe programuesi përfaqësojnë qartë dhe pa mëdyshje detyrën që duhet të kryhet, d.m.th. në këtë rast merren parasysh interesat si të përdoruesit ashtu edhe të programuesit. Përdoruesi mund të planifikojë të përdorë softuer që ende nuk është krijuar, bazuar në njohuritë që mundet. Një deklaratë e mirë e problemit shërben si bazë për formulimin e zgjidhjes së tij.

Deklarata e problemit (specifikimi i programit); në thelb nënkupton një përshkrim të saktë, të plotë dhe të kuptueshëm të asaj që ndodh kur ekzekutohet një program specifik. Përdoruesi zakonisht e shikon kompjuterin si një kuti të zezë: për të nuk ka rëndësi se si funksionon kompjuteri, por e rëndësishme është se çfarë mund të bëjë kompjuteri që i intereson përdoruesit. Në këtë rast, vëmendja kryesore përqendrohet në ndërveprimin e njeriut me makinën.

Karakteristikat e një deklarate të mirë problemi:

Saktësia, d.m.th. duke eliminuar çdo paqartësi. Nuk duhet të ketë dyshim se cili do të jetë rezultati i programit për çdo hyrje të dhënë.

Plotësia, d.m.th. duke marrë parasysh të gjitha opsionet për një input të caktuar, duke përfshirë hyrjen e gabuar ose të paqëllimshme, dhe përcaktimin e prodhimit të duhur.

Qartësia, d.m.th. ai duhet të jetë i kuptueshëm si për përdoruesin ashtu edhe për analistin e sistemit, pasi deklarata e problemit është e vetmja kontratë ndërmjet tyre.

Shpesh kërkesat për saktësi, plotësi dhe qartësi janë në konflikt. Kështu, shumë dokumente ligjore janë të vështira për t'u kuptuar sepse ato janë të shkruara në gjuhë formale, gjë që lejon që disa dispozita të formulohen me saktësi ekstreme, duke përjashtuar çdo mospërputhje të vogël. Për shembull, disa pyetje në fletët e provimit ndonjëherë formulohen aq saktë sa studenti shpenzon më shumë kohë për të kuptuar pyetjen sesa për t'iu përgjigjur asaj. Për më tepër, studenti mund të mos e kuptojë fare kuptimin kryesor të pyetjes për shkak të sasi e madhe detajet. Formulimi më i mirë i problemit është ai që arrin një ekuilibër të të tre kërkesave.

Forma standarde e deklaratës së problemit.

Merrni parasysh deklaratën e mëposhtme të problemit: "Fut tre numra dhe nxirr numrat me radhë."

Një deklaratë e tillë nuk i plotëson kërkesat e mësipërme: nuk është as e saktë, as e plotë dhe as e kuptueshme. Në të vërtetë, a duhet të futen numrat një për rresht apo të gjithë numrat në një rresht? A do të thotë shprehja "në rregull" renditja nga më e madhja tek më e vogla, nga më e vogla te më e madhja, apo të njëjtin rend në të cilin u prezantuan.

Natyrisht, një deklaratë e tillë nuk i përgjigjet shumë pyetjeve. Nëse marrim parasysh përgjigjet e të gjitha pyetjeve, atëherë deklarata e problemit do të bëhet e folur dhe e vështirë për t'u kuptuar. Prandaj, D. Riley sugjeron përdorimin e një formulari standard për të vendosur problemin, i cili siguron saktësinë, plotësinë, qartësinë maksimale dhe përfshin:

emri i detyrës (përkufizimi skematik);

përshkrim i përgjithshëm(deklaratë e shkurtër e problemit);

gabime (opsionet e pazakonta të hyrjes janë renditur në mënyrë eksplicite për t'u treguar përdoruesve dhe programuesve se çfarë veprimesh do të ndërmerrte makina në situata të tilla);

shembull ( shembull i mirë mund të përcjellë thelbin e problemit, si dhe të ilustrojë raste të ndryshme).

Shembull. Deklarata e problemit në një formë standarde.

EMRI

Renditja e tre numrave të plotë.

PËRSHKRIMI

Hyrja dhe dalja e tre numrave të plotë, të renditur nga numri më i vogël tek numri më i madh.

Futen tre numra të plotë, një numër për rresht. Një numër i plotë është një ose më shumë shifra dhjetore të njëpasnjëshme, të cilat mund të paraprihen nga një shenjë plus "+" ose një shenjë minus "-".

Tre numrat e plotë të futur janë shtypur, me të tre të shtypur në të njëjtën linjë. Numrat ngjitur ndahen me një hapësirë. Numrat shfaqen nga më i vogli tek më i madhi, nga e majta në të djathtë.

1) Nëse futen më pak se tre numra, programi pret për hyrje shtesë.

Cikli i jetës së softuerit. Fazat dhe etapat

Cikli jetësor i një SI është një seri ngjarjesh që ndodhin me një sistem gjatë procesit të krijimit dhe përdorimit të tij.

Skena- pjesë e procesit të krijimit të softuerit, e kufizuar nga një kornizë kohore e caktuar dhe që përfundon me lëshimin e një produkti specifik (modele, komponentë softuerësh, dokumentacion), të përcaktuar nga kërkesat e specifikuara për këtë fazë.

Cikli jetësor modelohet tradicionalisht si një numër i caktuar fazash (ose faza, faza) të njëpasnjëshme. Aktualisht, nuk ka një ndarje të pranuar përgjithësisht të ciklit jetësor të një sistemi softuerësh në faza. Ndonjëherë një skenë theksohet si një pikë më vete, ndonjëherë përfshihet si pjesë përbërëse e një skene më të madhe. Veprimet e kryera në një ose në një fazë tjetër mund të ndryshojnë. Nuk ka uniformitet në emrat e këtyre fazave.

Tradicionalisht, dallohen fazat kryesore të mëposhtme të ciklit jetësor të softuerit:

Analiza e kërkesave,

Dizajn,

Kodimi (programimi),

Testimi dhe korrigjimi,

Funksionimi dhe mirëmbajtja.

Cikli i jetës së softuerit. Modeli i kaskadës

modeli kaskadë (70-80 vjet) ≈ përfshin kalimin në fazën tjetër pas përfundimit të plotë të punës në fazën e mëparshme,

Arritja kryesore e modelit të kaskadës është plotësia e fazave. Kjo bën të mundur planifikimin e kostove dhe afateve. Përveç kësaj, ajo është formuar dokumentacionin e projektit, i plotë dhe konsistent.

Modeli i ujëvarës është i zbatueshëm për projekte të vogla softuerike me kërkesa të përcaktuara qartë dhe të pandryshueshme. Një proces i vërtetë mund të zbulojë dështime në çdo fazë, gjë që çon në një rikthim në një nga fazat e mëparshme. Modeli i prodhimit të tillë softuerësh është kthimi në kaskadë

Cikli i jetës së softuerit. Modeli hap pas hapi me kontroll të ndërmjetëm

model hap pas hapi me kontroll të ndërmjetëm (80-85) ≈ model iterativ i zhvillimit të softuerit me unaza kthyese ndërmjet fazave. Avantazhi i këtij modeli është se rregullimet ndërfazore ofrojnë më pak intensitet të punës në krahasim me modelin kaskadë; megjithatë, jetëgjatësia e çdo faze shtrihet gjatë gjithë periudhës së zhvillimit,

Fazat kryesore të zgjidhjes së problemit

Qëllimi i programimit është të përshkruajë proceset e përpunimit të të dhënave (në tekstin e mëtejmë thjesht procese).

Të dhënat janë prezantimi i fakteve dhe ideve në formë të formalizuar, të përshtatshme për transmetim dhe përpunim në një proces të caktuar dhe informacioni është kuptimi që i jepet të dhënave kur ato paraqiten.

Përpunimi i të dhënave është kryerja e një sekuence sistematike veprimesh mbi të dhënat. Të dhënat paraqiten dhe ruhen në median e ruajtjes.

Tërësia e bartësve të të dhënave të përdorura për çdo përpunim të të dhënave quhet medium informacioni.

Një grup të dhënash që përmbahen në çdo moment në mjedisin informativ - gjendje mjedis informacioni.

Një proces mund të përkufizohet si një sekuencë e gjendjeve të njëpasnjëshme të një mjedisi informacioni.

Të përshkruash një proces do të thotë të përcaktosh sekuencën e gjendjeve të mjedisit të informacionit. Në mënyrë që procesi i kërkuar të gjenerohet automatikisht në çdo kompjuter sipas një përshkrimi të dhënë, është e nevojshme që ky përshkrim të zyrtarizohet.

Kriteret e cilësisë së softuerit

Një produkt (produkt, shërbim) komercial duhet të plotësojë kërkesat e konsumatorit.

Cilësia është një karakteristikë objektive e një produkti (produkti, shërbimi), duke treguar shkallën e kënaqësisë së konsumatorit

Karakteristikat e cilësisë:

› Performanca– sistemi funksionon dhe zbaton funksionet e kërkuara.

› Besueshmëria– sistemi funksionon pa defekte ose defekte.

› Rikuperimi.

› Efikasiteti– sistemi zbaton funksionet e tij në mënyrën më të mirë të mundshme.

› Efikasiteti ekonomik – kosto minimale e produktit final me fitim maksimal.

Karakteristikat e cilësisë:

› Duke marrë parasysh faktorin njerëzor- lehtësia e përdorimit, shpejtësia e të mësuarit për të punuar me softuer, lehtësia e mirëmbajtjes, bërja e ndryshimeve.

› Transportueshmëri(lëvizshmëri) - transportueshmëri e kodit në një platformë ose sistem tjetër.

› Plotësia funksionale– ndoshta zbatimi më i plotë i funksioneve të jashtme.

› Saktësia e llogaritjes

Vetitë e algoritmit.

Efikasiteti nënkupton mundësinë e marrjes së një rezultati pas kryerjes së një numri të kufizuar operacionesh.

Siguria konsiston në koincidencën e rezultateve të marra, pavarësisht nga përdoruesi dhe mjetet teknike të përdorura.

Karakteri masiv qëndron në mundësinë e aplikimit të algoritmit në një klasë të tërë problemesh të ngjashme që ndryshojnë në vlerat specifike të të dhënave fillestare.

Diskretiteti - mundësia e ndarjes së procesit të llogaritjeve të përshkruara nga algoritmi në faza të veçanta, mundësia e zgjedhjes së seksioneve të programit me një strukturë të caktuar.

Mënyrat për të përshkruar algoritmet

Ka mënyrat e mëposhtme për të përshkruar algoritmet (të pranishëm):

1. përshkrim verbal;

2. përshkrimi i algoritmit duke përdorur formulat matematikore;

3. përshkrim grafik i algoritmit në formën e bllok-diagramit;

4. përshkrimi i algoritmit duke përdorur pseudokodin;

5. metodë e kombinuar imazhet e algoritmit duke përdorur metoda verbale, grafike dhe metoda të tjera .

6. duke përdorur rrjetat e Petrit.

Përshkrimi verbal algoritmi është një përshkrim i strukturës së algoritmit në gjuhën natyrore. Për shembull, për pajisjet pajisje shtëpiake, si rregull, është bashkangjitur një manual udhëzimi, d.m.th. një përshkrim verbal të algoritmit sipas të cilit duhet të përdoret kjo pajisje.

Përshkrimi grafikalgoritmi në formën e një grafiku të rrjedhësështë një përshkrim i strukturës së algoritmit duke përdorur forma gjeometrike me linja komunikimi.

Një grafik i rrjedhës së algoritmit është një paraqitje grafike e një metode për zgjidhjen e një problemi që përdor simbole të veçanta për të përfaqësuar operacionet.

Simbolet që përbëjnë bllok diagramin e algoritmit përcaktohen nga GOST 19.701-90. Ky GOST është në përputhje standard ndërkombëtar hartimi i algoritmeve, pra, diagramet e rrjedhës së algoritmeve, të dizajnuara në përputhje me GOST 19.701-90, në vende të ndryshme kuptohen qartë.

Pseudokodi– përshkrimi i strukturës së algoritmit në një gjuhë natyrale, por pjesërisht të formalizuar. Pseudokodi përdor disa konstruksione formale dhe simbole të zakonshme matematikore. Nuk ka rregulla strikte sintaksore për të shkruar pseudokod.

Le të shqyrtojmë shembulli më i thjeshtë. Supozoni se është e nevojshme të përshkruani algoritmin për shfaqjen në ekranin e monitorit vlerën më të lartë prej dy numrash.

Figura 1 - Një shembull i një përshkrimi të algoritmit në formën e një diagrami bllok

Përshkrimi i të njëjtit algoritëm në pseudokod:

2. Futni numrat: Z, X

3. Nëse Z > X atëherë dalja Z

4. Përndryshe, nxirret X

Secila nga metodat e listuara të përshkrimit të algoritmeve ka avantazhe dhe disavantazhe. Për shembull, metoda verbale është e folur dhe nuk ka qartësi, por bën të mundur përshkrimin më të mirë të operacioneve individuale. Metoda grafike është më vizuale, por shpesh ka nevojë për të përshkruar disa operacione në formë verbale. Prandaj, kur zhvilloni algoritme komplekse, është më mirë të përdorni një metodë të kombinuar.

Llojet e algoritmeve

lineare;

degëzimi;

ciklike.

· Algoritmi linear- një grup komandash (udhëzimesh) të ekzekutuara në mënyrë sekuenciale njëra pas tjetrës.

· Algoritmi i degëzimit- një algoritëm që përmban të paktën një kusht, si rezultat i kontrollit se cili kompjuter ofron një kalim në një nga dy hapat e mundshëm.

· Algoritmi i rrumbullakët- një algoritëm që përfshin përsëritjen e përsëritur të të njëjtit veprim (të njëjtat operacione) në të dhëna të reja fillestare. Shumica e metodave të llogaritjeve dhe numërimit të opsioneve reduktohen në algoritme ciklike. Cikli i programit - një sekuencë komandash (seri, trupi i ciklit) që mund të ekzekutohen në mënyrë të përsëritur (për të dhënat e burimit të ri) derisa të plotësohet një kusht i caktuar.

C. Llojet e të dhënave.

Një lloj i të dhënave është një përshkrim i gamës së vlerave që mund të marrë një variabël i një lloji të caktuar. Çdo lloj i të dhënave karakterizohet nga:
   1. numri i bajteve të zëna (madhësia)
   2. diapazoni i vlerave që mund të marrë një variabël i këtij lloji.

Të gjitha llojet e të dhënave mund të ndahen në llojet e mëposhtme:
   1. Llojet e thjeshta (skalare) dhe komplekse (vektoriale);
   2. bazë (sistemi) dhe përdorues (përcaktuar nga përdoruesi).
  Në gjuhën SI, sistemi i llojeve bazë formohet nga katër lloje të dhënash:
   1. simbolike,
   2. numër i plotë,
   3. saktësi e vetme reale,
   4. saktësi e dyfishtë reale.

Struktura e një programi C.

1. Operatorët e gjuhës C++

Operatorët kontrollojnë procesin e ekzekutimit të programit. Seti i operatorëve të gjuhës C++ përmban të gjitha konstruktet e kontrollit të programimit të strukturuar.
Një deklaratë e përbërë kufizohet me kllapa kaçurrelë. Të gjitha deklaratat e tjera përfundojnë me një pikëpresje.
Operatori bosh – ;
Një deklaratë boshe është një deklaratë e përbërë vetëm nga një pikëpresje. Mund të shfaqet kudo në një program ku sintaksa kërkon një deklaratë. Ekzekutimi i një deklarate boshe nuk e ndryshon gjendjen e programit.
Operatori i përbërë - (...)
Efekti i një deklarate të përbërë është të ekzekutojë deklaratat që ai përmban në mënyrë sekuenciale, përveç nëse një deklaratë transferon në mënyrë të qartë kontrollin në një vend tjetër në program.
Deklarata e trajtimit të përjashtimit

provoni (<операторы> }
kap (<объявление исключения>) { <операторы> }
kap (<объявление исключения>) { <операторы> }
...
kap (<объявление исключения>) { <операторы> }

Operatori i kushtëzuar

nese (<выражение>) <оператор 1>

Operatori i kalimit

kaloni (<выражение>)
(rast<константное выражение 1>: <операторы 1>
rasti<константное выражение 2>: <операторы 2>
...
rasti<константное выражение N>: <операторы N>
}
Deklarata switch përdoret për të zgjedhur një nga disa shtigje alternative për ekzekutimin e programit. Vlerësimi i një deklarate switch fillon me vlerësimin e një shprehjeje, pas së cilës kontrolli transferohet në deklaratën e shënuar me një shprehje konstante të barabartë me vlerën e vlerësuar të shprehjes. Dalja nga deklarata switch kryhet nga deklarata break. Nëse vlera e shprehjes nuk është e barabartë me ndonjë shprehje konstante, atëherë kontrolli transferohet në deklaratën e shënuar me fjalën kyçe të paracaktuar, nëse ka.
Operatori i ciklit me parakusht

ndersa (<выражение>) <оператор>

Operator i ciklit me gjendje postare

bëj<оператор>ndërsa<выражение>;
Në gjuhën C++, ky operator ndryshon nga zbatimi klasik i një cikli me një kusht pas, në atë që nëse shprehja është e vërtetë, cikli vazhdon, në vend që të dalë nga cikli.
Operatori i ciklit të hapit

per ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
Trupi i deklaratës for ekzekutohet derisa shprehja e kushtëzuar të bëhet false (e barabartë me 0). Shprehjet fillestare dhe në rritje përdoren zakonisht për të inicializuar dhe modifikuar parametrat e lakut dhe vlerat e tjera. Shprehja fillestare vlerësohet një herë përpara se shprehja e kushtëzuar të testohet për herë të parë, dhe shprehja në rritje vlerësohet pas çdo ekzekutimi të deklaratës. Secila nga tre shprehjet e kokës së lakut, dhe madje të treja, mund të hiqet (vetëm mos harroni të lini jashtë pikëpresjes). Nëse shprehja e kushtëzuar hiqet, ajo konsiderohet e vërtetë dhe cikli bëhet i pafund.
Operatori hap pas hapi loop në gjuhën C++ është një konstruksion fleksibël dhe i përshtatshëm, prandaj operatori i ciklit me një parakusht while përdoret jashtëzakonisht rrallë në gjuhën C++, sepse në shumicën e rasteve është më i përshtatshëm për të përdorur operatorin for.
Operatori i thyerjes

pushim;
Operatori break ndërpret ekzekutimin e deklaratave while, do, for dhe switch. Ajo mund të përmbahet vetëm në trupin e këtyre deklaratave. Kontrolli i transferohet operatorit të programit pas atij të ndërprerë. Nëse një deklaratë pushimi shkruhet brenda deklaratave të ndërlidhura ndërsa, do, for, switch, atëherë ai përfundon vetëm deklaratën duke e mbyllur menjëherë.
operatori i vazhdimit

vazhdo;
Operatori i vazhdimit transferon kontrollin në përsëritjen tjetër në while, do, për operatorët e ciklit. Ajo mund të përmbahet vetëm në trupin e këtyre deklaratave. Në deklaratat do dhe ndërsa, përsëritja tjetër fillon me vlerësimin e shprehjes kushtore. Në një deklaratë for, përsëritja tjetër fillon duke vlerësuar shprehjen e rritjes dhe më pas vlerëson shprehjen e kushtëzuar.
Operatori i kthimit

kthehu [<выражение>];
Deklarata kthyese përfundon ekzekutimin e funksionit që e përmban atë dhe kthen kontrollin në funksionin thirrës. Kontrolli transferohet në pikën e funksionit thirrës

Nëse (shprehje boolean)

operator;

Nëse (shprehje boolean)

operator_1;

operator_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

Nëse vlera e shprehjes logjike është e vërtetë, atëherë vlerësohet shprehja_1, përndryshe vlerësohet shprehja_2.

ndërprerës (shprehje me numër të plotë)

vlera e rastit_1:

deklarata_sekuenca_1;

vlera e rastit_2:

deklarata_sekuenca_2;

vlera e rastit_n:

deklarata_sekuenca_n;

default:

operatori_sekuenca_n+1;

Dega default nuk mund të përshkruhet. Ai ekzekutohet nëse asnjë nga shprehjet më të larta nuk është i kënaqur.

Operatori i ciklit.

Turbo C ka konstruktet e mëposhtme që ju lejojnë të programoni ciklet: ndërsa, bëj ndërkohë Dhe për . Struktura e tyre mund të përshkruhet si më poshtë:

Lloko kontrollon gjendjen në krye:

Operatori i përzgjedhjes

Nëse veprimet që dëshironi të kryeni në një program varen nga vlera e disa ndryshoreve, mund të përdorni operatorin e përzgjedhur. Megjithatë, në C++ vetëm variablat numerike mund të përdoren si variabla në operatorin e përzgjedhjes. NË pamje e përgjithshme hyrja e deklaratës së përzgjedhjes duket kështu:

ndërprerës (ndryshueshme)
{
vlera e rastit 1:
veprimet 1
pushim;

vlera e rastit 2:
veprimet2
pushim;
...

default:
veprimet e paracaktuara
}

Fjalë kyçe pushimi duhet shtuar në fund të çdo dege. Ai ndalon ekzekutimin e operacionit të përzgjedhjes. Nëse nuk e shkruani, pas ekzekutimit të veprimeve nga një degë përzgjedhjeje, ekzekutimi i veprimeve nga degët e mëposhtme do të vazhdojë. Megjithatë, ndonjëherë kjo veçori e përzgjedhjes është e dobishme, për shembull, nëse duhet të kryeni të njëjtat veprime për kuptime të ndryshme e ndryshueshme.

ndërprerës (ndryshueshme)
{
vlera e rastit 1:
vlera e rastit 2:
veprimet 1
pushim;

vlera e rastit 3:
veprimet2
pushim;
...
}

Shembull i përdorimit të zgjidhni:

int n, x;
...
ndërprerës (n)
{
rasti 0:
pushim; //nëse n është 0, atëherë nuk kryejmë asnjë veprim

rasti 1:
rasti 2:
rasti 3:
x = 3 * n; //nëse n është 1, 2 ose 3, atëherë kryeni disa veprime
pushim;

rasti 4:
x = n; //nëse n është 4, atëherë kryeni veprime të tjera
pushim;

default:
x = 0; //për të gjitha vlerat e tjera të n, kryeni veprimet e paracaktuara
}

C.Cikli: lak me parametër

Forma e përgjithshme rekorde

për (inicializimi i parametrave; kontrollimi i gjendjes përfundimtare; korrigjimi i parametrave) (

blloku i operacioneve;

for - cikli parametrik (lak me një numër të caktuar përsëritjesh). Për të organizuar një cikël të tillë, duhet të kryhen tre operacione:

§ inicializimi i parametrave- caktimi i një vlere fillestare për parametrin e ciklit;

§ duke kontrolluar gjendjen përfundimtare- krahasimi i vlerës së parametrit me një vlerë të caktuar kufitare;

§ korrigjimi i parametrave- ndryshimi i vlerës së parametrit sa herë që kalon trupi i lakut.

Këto tre veprime shkruhen në kllapa dhe ndahen me një pikëpresje (;). Në mënyrë tipike, parametri i lakut është një ndryshore numër i plotë.
Parametri inicializohet vetëm një herë - kur cikli for fillon të ekzekutohet. Gjendja e përfundimit kontrollohet përpara çdo ekzekutimi të mundshëm të trupit të lakut. Kur një shprehje bëhet false ( e barabartë me zero), përfundon cikli. Parametri rregullohet në fund të çdo ekzekutimi të trupit të lakut. Parametri mund të rritet ose ulet.

Shembull

#përfshi
int main() (

for(num = 1; num< 5; num++)

printf("num = %d\n",num);

Si. Lak me parakusht

Formulari i përgjithshëm i regjistrimit

ndërsa (shprehje) (

blloku i operacioneve;
}

Nëse shprehja është e vërtetë (jo e barabartë me zero), atëherë ekzekutohet blloku i operacioneve i mbyllur në kllapa kaçurrela, atëherë shprehja kontrollohet përsëri. Sekuenca e veprimeve që konsiston në kontrollimin dhe ekzekutimin e një blloku operacionesh përsëritet derisa shprehja të bëhet false (e barabartë me zero). Në këtë rast, cikli del jashtë dhe operacioni pas operatorit të ciklit ekzekutohet.

Shembull

int k=5;
int i=1;
shuma int=0;
ndërsa (i<=k) {

Kur ndërtohet një qark while, është e nevojshme të përfshihen konstruksione që ndryshojnë vlerën e shprehjes që testohet në mënyrë që përfundimisht të bëhet false (e barabartë me zero). Përndryshe, cikli do të funksionojë pafundësisht (lak i pafund), për shembull

blloku i operacioneve;
}

while është një lak me një parakusht, kështu që është mjaft e mundshme që trupi i ciklit të mos ekzekutohet qoftë edhe një herë nëse në momentin e kontrollit të parë gjendja që kontrollohet rezulton false.

Si. Lak me kusht

Loop me do...while postcondition

Formulari i përgjithshëm i regjistrimit

blloku i operacioneve;

) while(shprehje);

Lak me kusht

Një cikli do...while është një lak me një kusht postar, ku kontrollohet vërtetësia e shprehjes pasi të kryhen të gjitha operacionet e përfshira në bllokun e kufizuar me kllapa kaçurrela Trupi i ciklit ekzekutohet derisa shprehja të bëhet false është, trupi i ciklit me një kusht postar ekzekutohet edhe pse vetëm një herë.

Është më mirë të përdoret një cikli do...while në rastet kur duhet të përfundojë të paktën një përsëritje, ose kur inicializimi i objekteve të përfshira në kontrollimin e gjendjes ndodh brenda trupit të ciklit.

Shembull. Futni një numër nga 0 në 10

#përfshi
#përfshi
int main() (

system ("chcp 1251");

printf("Fut një numër nga 0 në 10: ");

scanf("%d", &num);

) ndërsa ((num< 0) || (num > 10));

printf("Keni futur numrin %d", num);

getchar (); getchar ();

Përcaktimi i funksioneve

Le të shohim përkufizimin e një funksioni duke përdorur funksionin shuma si shembull.

Në C dhe C++, funksionet nuk duhet të përcaktohen derisa të përdoren, por ato duhet të deklarohen më parë. Por edhe pas gjithë kësaj, përfundimisht ky funksion duhet të definohet. Prototipi i funksionit dhe përkufizimi i tij shoqërohen më pas dhe funksioni mund të përdoret.

Nëse një funksion është deklaruar më parë, ai duhet të përcaktohet me të njëjtën vlerë kthyese dhe tipe të dhënash, përndryshe do të krijohet një funksion i ri, i mbingarkuar. Vini re se emrat e parametrave të funksioneve nuk duhet të jenë të njëjtë.