Proqram ömrü (proqram ömrü). Proqram sistemlərinin həyat dövrü Proqramın həyat dövrü anlayışı və onun mərhələləri

Mövzu: Klassik və çevik həyat dövrü modelləri: tərifi, təsviri, fərqli xüsusiyyətləri, mərhələlərin ardıcıllığı. Müxtəlif mövzu sahələrində proqram təminatının inkişafında bir həyat dövrü modeli seçmək üsulları.

Proqram ömrü modelləri və mərhələləri

Həyat dövrü modeli, proqram təminatının həyat dövrü ərzində proseslərin, hərəkətlərin və vəzifələrin icra ardıcıllığını və qarşılıqlı əlaqəsini təyin edən bir quruluş olaraq başa düşülür. Həyat dövrü modeli, layihənin xüsusiyyətlərindən, miqyasından və mürəkkəbliyindən və sistemin yaradıldığı və işlədiyi şərtlərin xüsusiyyətlərindən asılıdır.

ISO / IEC 12207, xüsusi bir həyat dövrü modeli və proqram inkişaf etdirmə üsulları təmin etmir. Onun müddəaları, hər hansı bir həyat dövrü modelləri, proqram inkişaf etdirmə üsulları və texnologiyaları üçün ortaqdır. Standart proqram həyat dövrü proseslərinin quruluşunu təsvir edir, lakin bu proseslərə daxil olan hərəkətləri və vəzifələri necə həyata keçirəcəyini və ya yerinə yetirməyini göstərmir.

Hər hansı bir xüsusi proqramın həyat dövrü modeli, vaxtında sifariş edilmiş, bir -biri ilə əlaqəli və işin mərhələlərində (mərhələlərində) birləşdirilmiş, icrası proqram təminatı yaratmaq üçün lazım olan və kifayət edən bir iş toplusu olan onun yaradılması prosesinin xarakterini müəyyən edir. müəyyən edilmiş tələblərə cavab verir.

Proqram təminatının yaradılmasının mərhələsi (mərhələsi), müəyyən bir zaman çərçivəsi ilə məhdudlaşan və tələblərlə müəyyən edilmiş müəyyən bir məhsulun (proqram modelləri, proqram komponentləri, sənədlər və s.) Buraxılması ilə bitən bir proqram yaradılması prosesinin bir hissəsi kimi başa düşülür. bu mərhələ üçün müəyyən edilir. Proqram təminatının inkişaf mərhələləri, göstərilən nəticələrlə bitən işin rasional planlaşdırılması və təşkili səbəbləri ilə fərqlənir. Proqramın həyat dövrü ümumiyyətlə aşağıdakı mərhələləri əhatə edir:

1. proqram tələblərinin formalaşdırılması;
2. dizayn (sistem layihəsinin hazırlanması);
3. həyata keçirilməsi (alt mərhələlərə bölünə bilər: ətraflı dizayn, kodlaşdırma);
4. test (müstəqil və bölünə bilər kompleks sınaq və inteqrasiya);
5. istismara verilməsi (həyata keçirilməsi);
6. istismar və texniki xidmət;
7. istismardan çıxarılması.

Bəzi mütəxəssislər əlavə bir ilkin mərhələ təqdim edirlər - texniki-iqtisadi əsaslandırmalı öyrənmə sistemlər. Bu, proqramın yaradıldığı, satın alındığı və ya dəyişdirildiyi proqram və hardware sisteminə aiddir.

Proqram tələblərinin formalaşması mərhələsi ən vaciblərindən biridir və bütün layihənin uğurunu böyük (hətta həlledici!) Dərəcəsi ilə müəyyən edir. Bu mərhələnin başlanğıcı, aparat və proqram təminatı arasında funksiyaların paylanmasına dair əsas razılaşmalar daxil olmaqla təsdiq edilmiş və təsdiq edilmiş sistem arxitekturasının əldə edilməsidir. Bu sənəd, eyni zamanda, insan və sistem arasında funksiyaların paylanmasına dair əsas razılaşmalar da daxil olmaqla, proqram təminatının işləməsi haqqında ümumi anlayışın təsdiqini ehtiva etməlidir.

Proqram təminatı tələblərinin formalaşması mərhələsinə aşağıdakı mərhələlər daxildir.

1. Bir layihə üzərində işləmədən əvvəl işin planlaşdırılması. Mərhələnin əsas vəzifələri, inkişaf məqsədlərinin əvvəlcədən müəyyənləşdirilməsidir iqtisadi qiymətləndirmə layihə, iş qrafikinin qurulması, birgə işçi qrupunun yaradılması və təlimi.
2. Gələcək sistem üçün tələblərin əvvəlcədən müəyyənləşdirilməsi, təşkilatın quruluşunun təyin edilməsi, hədəf funksiyalar siyahısının təyin edilməsi həyata keçirilən avtomatlaşdırılmış təşkilatın (obyektin) fəaliyyətinin araşdırılması. təşkilatın, şöbələr və işçilər tərəfindən funksiyaların paylanmasının təhlili, şöbələr arasındakı funksional qarşılıqlı əlaqələrin, şöbələr daxilində və arasında məlumat axınının, obyektlərin təşkili və xarici məlumat təsirləri ilə əlaqədar olaraq təhlili mövcud fondlar təşkilatın fəaliyyətinin avtomatlaşdırılması.

Tədqiqat materiallarının işlənməsini və iki növ modelin qurulmasını təmin edən təşkilatın (obyektin) fəaliyyət modelinin qurulması:

• anket zamanı təşkilatın mövcud vəziyyətini əks etdirən və təşkilatın necə işlədiyini anlamağa, həmçinin darboğazları müəyyən etməyə və yaxşılaşdırmaq üçün təkliflər hazırlamağa imkan verən "AS-IS" ("olduğu kimi") modeli vəziyyət;
• təşkilatın yeni texnologiyaları ideyasını əks etdirən "TO-BE" modeli ("necə olmalı").

Modellərin hər biri tam funksional və məlumat modeli təşkilatın fəaliyyəti, habelə (lazım olduqda) təşkilatın davranış dinamikasını təsvir edən bir model. Qeyd edək ki, tikilmiş modellər müstəqildir praktik əhəmiyyəti müəssisənin bir məlumat sistemi inkişaf etdirib tətbiq etməsindən asılı olmayaraq, işçilərin hazırlanması və müəssisənin iş proseslərinin təkmilləşdirilməsi üçün istifadə oluna bilər.

Proqram təminatı tələblərinin formalaşması mərhələsinin başa çatmasının nəticəsi, tamlığı, sınanma qabiliyyəti və məqsədəuyğunluğu təsdiqlənmiş proqram xüsusiyyətləri, funksional, texniki və interfeys xüsusiyyətləridir.

Dizayn mərhələsinə aşağıdakı mərhələlər daxildir.

1. Bir proqram sistemi layihəsinin hazırlanması. Bu mərhələdə "Gələcək sistem nə etməlidir?" Sualının cavabı, proqram ayıklama planı və keyfiyyətə nəzarət.

   Sistem dizaynı "TO-BE" modelinə əsaslanan sistem dizayn modellərinə əsaslanır. Bir sistem layihəsinin inkişafının nəticəsi, proqram tələblərinin təsdiq edilmiş və təsdiq edilmiş bir spesifikasiyası olmalıdır: funksionallıq, texniki və interfeys spesifikasiyaları, bunun üçün onların tamlığı, sınanabilirliyi və məqsədəuyğunluğu təsdiq edilmişdir.

2. Ətraflı (texniki) bir layihənin hazırlanması. Bu mərhələdə, sistem memarlığının dizaynı və detallı dizayn da daxil olmaqla, faktiki proqram dizaynı həyata keçirilir. Beləliklə, "Tələblərə cavab verən bir sistem necə qurulmalıdır?" Sualına cavab verilir.

Ətraflı dizaynın nəticəsi təsdiqlənmiş bir proqram spesifikasiyasının hazırlanmasıdır:

• proqram komponentlərinin hiyerarşisinin, məlumat və nəzarət üçün intermodular interfeyslərin formalaşdırılması;
• hər bir proqram komponentinin spesifikasiyası, adı, məqsədi, fərziyyələr, ölçülər, zənglərin ardıcıllığı, giriş və çıxış məlumatları, səhv Çıxışlar, alqoritmlər və məntiq sxemləri;
• fərdi sahələr səviyyəsinə qədər fiziki və məntiqi məlumat strukturlarının formalaşdırılması;
• hesablama mənbələrinin paylanması üçün bir planın hazırlanması (mərkəzi prosessorların vaxtı, yaddaş və s.);
• tələblərin tamlığının, ardıcıllığının, məqsədəuyğunluğunun və əsaslılığının yoxlanılması;
• ilkin inteqrasiya və ayıklama planı, istifadəçi təlimatı və qəbul test planı.

Ətraflı dizayn mərhələsinin başa çatması layihənin sona çatması və ya layihənin kritik blok analizidir.

İcra mərhələsi aşağıdakı işlərin həyata keçirilməsidir.

1. Hər bir alt proqramın təsdiqlənmiş ətraflı spesifikasiyasının hazırlanması (yüksək səviyyəli dilin 100-dən çox mənbə əmrindən ibarət olmayan bir blok).

   Xarici spesifikasiyalarda aşağıdakı məlumatlar olmalıdır:

   • modul adı - modulu çağırmaq üçün istifadə olunan adı göstərir (birdən çox girişi olan bir modul üçün hər giriş üçün ayrıca spesifikasiyalar olmalıdır);
   • funksiya - modulun yerinə yetirdiyi funksiyanın və ya funksiyaların tərifi verilir;
   • modula verilən parametrlərin siyahısı (sayı və sırası);
   • giriş parametrləri - modul tərəfindən qaytarılmış bütün məlumatların dəqiq təsviri (modulun davranışı istənilən giriş şəraitində müəyyən edilməlidir);
   • xarici effektlər (mesajın çap edilməsi, terminaldan sorğunun oxunması və s.).
2. Modulların məntiqinin və proqramlaşdırma (kodlaşdırma) modullarının dizaynı.
3. Modulların düzgünlüyünün yoxlanılması.
4. Test modulları.
5. Verilənlər bazasının fərdi parametrlər, simvollar və bitlər səviyyəsinə qədər təsviri.
6. Qəbul imtahan planı.
7. İstifadəçi kitabçası.
8. İnteqrasiya və ayıklama üçün ilkin plan. Sonrakı mərhələlərin məzmunu əsasən proqramın həyat dövrünün müvafiq prosesləri ilə üst -üstə düşür. Ümumiyyətlə, texnoloji mərhələlər işin ağlabatan və rasional planlaşdırılması və təşkili mülahizələrinə əsaslanaraq fərqlənir. Proqramın ömrü ilə əlaqənin və iş mərhələlərinin mümkün variantı şəkildə göstərilmişdir.

Pirinç. 1.

Həyat dövrü proqram modellərinin növləri

Şəlalə modeli (klassik həyat dövrü)

Bu model görünüşünü W. Royce (1970) borcludur. Modelin başqa adı da var - şəlalə. Modelin özəlliyi ondan ibarətdir ki, növbəti mərhələyə keçid yalnız əvvəlki mərhələdəki işlər tamamilə başa çatdıqdan sonra həyata keçirilir; keçən mərhələlərə geri qaytarılmır.

Yaradılması və təhlili mərhələlərində müəyyən edilmiş inkişaf etmiş proqram sisteminə olan tələblər ciddi şəkildə texniki şərtlər şəklində sənədləşdirilir və layihənin hazırlanma müddətinin tamamı üçün müəyyən edilir. Hər mərhələ, inkişafın başqa bir inkişaf qrupu tərəfindən davam etdirilməsi üçün kifayət qədər sənədlərin (TOR, EP, TP, RP) buraxılması ilə başa çatır. Bu yanaşma ilə inkişaf keyfiyyətinin meyarı TK spesifikasiyalarının yerinə yetirilməsinin dəqiqliyidir. Yaradıcıların əsas diqqəti optimal dəyərlərə nail olmaqdır texniki xüsusiyyətlər inkişaf etmiş proqram sistemi - performans, yaddaş ölçüsü və s.

Üstünlüklər kaskad modeli:

• hər mərhələdə tamlıq və ardıcıllıq meyarlarına cavab verən layihə sənədlərinin tam dəsti formalaşdırılır;
• məntiqi ardıcıllıqla aparılan işlərin mərhələləri bütün işlərin başa çatma vaxtını və müvafiq xərcləri planlaşdırmağa imkan verir.

Şəlalə yanaşması, layihənin əvvəlində bütün tələblərin tam və aydın şəkildə tərtib edilə biləcəyi bir proqram sistemi qurarkən özünü yaxşı sübut etdi. Bütün bunlara standartlar və müxtəlif dövlət qəbul komissiyaları nəzarət etdiyi müddətdə sxem yaxşı işləyir.

dezavantajlar kaskad modeli:

• səhvlərin müəyyən edilməsi və aradan qaldırılması yalnız əhəmiyyətli dərəcədə uzadıla bilən sınaq mərhələsində aparılır;
• real layihələr tez -tez standart addımlar ardıcıllığından kənara çıxmağı tələb edir;
• dövr PS üçün ilkin tələblərin dəqiq tərtibinə əsaslanır, əslində layihənin əvvəlində müştərinin tələbləri yalnız qismən müəyyən edilir;
• işin nəticələri müştəriyə yalnız layihə başa çatdıqdan sonra əldə edilə bilər.

PS həyat dövrünün təkrarlanan modeli

Kommersiya layihələrinin böyüməsi ilə gələcək sistemin layihəsini ətraflı şəkildə işlətməyin hər zaman mümkün olmadığı aydın oldu, çünki sistem yaradılarkən dinamik fəaliyyət sahələrində (iş) fəaliyyət göstərməsinin bir çox aspektləri dəyişir. Hər hansı bir inkişaf mərhələsi başa çatdıqdan sonra lazımi düzəlişlərin edilməsini təmin etmək üçün inkişaf prosesini dəyişdirmək lazım idi. Həyat dövrünün iterativ modeli belə ortaya çıxdı, buna ara nəzarətli model və ya fazaların dövri təkrarlanan modeli deyilir.

Təkrarlanan bir modeldə, dizayn və proqramlaşdırma qüsurları əvvəlki mərhələyə qismən qayıtmaqla sonradan düzəldilə bilər. Səhv aşkarlama dərəcəsi nə qədər aşağı olarsa, onu düzəltmək daha bahalıdır. Kod yazma mərhələsindəki səhvləri aşkar etmək və aradan qaldırmaq üçün lazım olan səylərin dəyəri vahid olaraq qəbul edilərsə, tələblərin hazırlanması mərhələsində bir səhvin aşkarlanması və aradan qaldırılması xərcləri 5-10 dəfə az olacaq. təmir mərhələsində bir səhvin müəyyən edilməsi və aradan qaldırılması 20 qat daha çox olacaq.

Belə bir vəziyyətdə tələblərin formalaşdırılması, spesifikasiyaların tərtib edilməsi və sistem planının hazırlanması mərhələsi böyük əhəmiyyət kəsb edir. Proqram memarları sonrakı bütün dizayn dəyişikliklərindən şəxsən məsuliyyət daşıyırlar. Sənədlərin həcmi minlərlə səhifədədir və təsdiqlənən görüşlərin sayı çox böyükdür. Bir çox layihə "analiz iflici" nə düşərək planlaşdırma mərhələsini heç vaxt tərk etmir. Belə vəziyyətlərdən qaçmağın mümkün yollarından biri də prototipləşdirmədir (prototipləşdirmə).

Layout

Çox vaxt müştəri gələcək proqram məhsulu üçün məlumatların daxil edilməsi, işlənməsi və ya çıxışı üçün tələbləri formalaşdıra bilməz. Geliştirici, istifadəçi ilə dialoq şəklində və ya alqoritmin effektivliyində məhsulun əməliyyat sisteminə uyğunluğundan şübhələnə bilər. Belə hallarda prototipdən istifadə etmək məsləhətdir. Prototip hazırlamağın əsas məqsədi müştərinin tələblərindəki qeyri -müəyyənliyi aradan qaldırmaqdır. Layihə (prototipləşdirmə), tələb olunan məhsulun modelini yaratmaq prosesidir.

Model aşağıdakı formalarda ola bilər.

1. Kağız maketi (insan-maşın dialoqunun əllə tərtib edilmiş diaqramı) və ya PC əsaslı maket.
2. Lazımi funksiyaları yerinə yetirən bir iş düzeni.
3. Xüsusiyyətlərinin yaxşılaşdırılması lazım olan mövcud bir proqram.

Şəkildə göstərildiyi kimi, prototipləşdirmə müştəri ilə inkişaf etdirici arasında təkrarlanan təkrarlamalara əsaslanır.

Prototipləşdirmə hərəkətlərinin ardıcıllığı şəkildə göstərilmişdir. Prototip yaratmaq, yaradılan proqram sisteminə olan tələblərin toplanması və aydınlaşdırılması ilə başlayır. Geliştirici və müştəri, proqramın məqsədlərini birlikdə müəyyənləşdirir, hansı tələblərin məlum olduğunu və daha da müəyyənləşdirilməli olduğunu təyin edir. Sonra sürətli bir dizayn hazırlanır. İstifadəçiyə görünməli olan xüsusiyyətlərə diqqət yetirir. Sürətli dizayn bir plan qurmağa gətirib çıxarır. Layihə müştəri tərəfindən qiymətləndirilir və proqram tələblərini aydınlaşdırmaq üçün istifadə olunur. Layihə bütün müştərinin tələblərini müəyyən edənə və inkişaf etdiriciyə nə edilməli olduğunu başa düşmə imkanı verənə qədər təkrarlamalar davam edir.

Prototipin üstünlükləri, tam sistem tələblərinin təyin olunmasını təmin etmək qabiliyyətidir. Layihənin dezavantajları:

• müştəri məhsulun planını götürə bilər;
• bir geliştirici bir məhsulun dizaynını səhv edə bilər.

Qüsurların mahiyyəti aydınlaşdırılmalıdır. Müştəri PS -nin işləyən bir versiyasını gördükdə, PS -nin işlək bir versiyasının axtarışında bir çox keyfiyyət problemlərinin həll edilmədiyini və qulluq asanlığı sistemlər. İnkişaf etdirici bu barədə müştəriyə məlumat verdikdə, cavab qəzəb və planın işlək bir məhsula ən sürətli çevrilməsi tələbi ola bilər. Bu, proqram inkişafının idarə edilməsinə mənfi təsir göstərir.

Digər tərəfdən, tez bir iş planı əldə etmək üçün geliştirici tez-tez müəyyən alış-verişlər edir. Məsələn, səhv proqramlaşdırma dili və ya əməliyyat sistemi istifadə edilə bilər. Sadə bir nümayiş üçün təsirsiz (sadə) bir alqoritm istifadə edilə bilər. Bir müddət sonra, geliştirici bu vasitələrin uyğun olmamasının səbəblərini unudur. Nəticədə, idealdan uzaq bir seçim sistemə inteqrasiya olunur.

Əvəz edilmiş digər həyat dövrü proqram modellərini nəzərdən keçirmədən əvvəl kaskad modeli, dizayn strategiyalarına diqqət yetirməliyik proqram sistemləri... Proqram ömrü modelini əsasən müəyyən edən proqram dizayn strategiyasıdır.

Proqram dizayn strategiyaları

Proqram sistemlərinin dizaynı üçün üç strategiya var:

• tək keçid (yuxarıda müzakirə olunan kaskad strategiyası) - dizayn addımlarının xətti ardıcıllığı;
• artan strategiya. Prosesin əvvəlində bütün istifadəçi və sistem tələbləri müəyyən edilir, dizaynın qalan hissəsi versiyalar ardıcıllığı kimi aparılır. Birinci versiya planlaşdırılan bəzi funksiyaları həyata keçirir, sonrakı versiya həyata keçirir əlavə xüsusiyyətlər və s., tam bir sistem əldə olunana qədər;
• təkamül strategiyası. Sistem eyni zamanda bir sıra ardıcıllıqla qurulmuşdur, lakin prosesin əvvəlində bütün tələblər müəyyən edilməmişdir. Tələblər versiya inkişafı nəticəsində təkmilləşdirilir. IEEE / EIA 12207 standartının tələblərinə uyğun olaraq proqram dizayn strategiyalarının xüsusiyyətləri Cədvəl 1 -də göstərilmişdir.

Artan model

Artan model, artan dizayn strategiyasının klassik bir nümunəsidir. Ardıcıl bir şəlalə modelinin elementlərini təkrarlanan prototip fəlsəfəsi ilə birləşdirir (B. Boehm tərəfindən təkmilləşdirmə olaraq təklif olunur) kaskad modeli). Buradakı hər bir xətti ardıcıllıq təmin edilmiş bir proqram artımı yaradır. Məsələn, 1 -ci artımda (versiya) sözlərin işlənməsi üçün proqram, əsas fayl işləmə, redaktə və sənədləşdirmə funksiyalarını yerinə yetirir; 2 -ci artımda - daha mürəkkəb redaktə və sənədləşmə variantları; 3 -cü artımda - orfoqrafiya və qrammatik yoxlama; 4 -cü artımda - səhifə tərtibat imkanları.

İlk artım, əsas tələbləri yerinə yetirən bir baza məhsulu ilə nəticələnir (baxmayaraq ki, bir çox köməkçi tələblər yerinə yetirilməmiş qalır). Növbəti artım planına əlavə xüsusiyyətlər və funksionallıq təmin etmək üçün əsas məhsula dəyişikliklər daxildir.

Artan bir proses təbii olaraq təkrarlanır, lakin prototipdən fərqli olaraq, artan model hər bir artımda işləyən bir məhsul təqdim edir.

Proqramın həyat dövrünün belə bir modelinin diaqramı şəkildə göstərilmişdir. Artan yanaşmanın müasir tətbiqlərindən biri həddindən artıq proqramlaşdırmadır (çox kiçik funksional artımlara yönəlmişdir).

Həyat dövrü proqramının spiral modeli

Spiral model Təkamüllü bir dizayn strategiyasının klassik bir nümunəsidir. Model (B. Boehm, 1988) əsasında qurulmuşdur ən yaxşı xüsusiyyətlər yeni bir elementin əlavə olunduğu klassik həyat dövrü və prototipləşdirmə - bu paradiqmalarda olmayan risk təhlili. Model, spiralin dörd kvadrantı ilə təmsil olunan dörd hərəkəti təyin edir.

1. Planlaşdırma - məqsədləri, variantları və məhdudiyyətləri müəyyənləşdirmək.
2. Risk təhlili - variantların təhlili və riskin tanınması / seçilməsi.
3. Mühəndislik məhsul inkişafının növbəti səviyyəsidir.
4. Qiymətləndirmə - müştərinin hazırkı dizayn nəticələrini qiymətləndirməsi.

İnteqrasiya edən aspekt spiral modeli spiralın radial ölçüsü nəzərə alındıqda aydındır. Hər bir təkrarlama ilə PS -nin daha çox tam versiyası bir spiraldə qurulur. Spiralın ilk növbəsində ilkin məqsədlər, variantlar və məhdudiyyətlər müəyyən edilir və risk tanınır və təhlil edilir. Risk təhlili tələblərin qeyri -müəyyənliyini ortaya qoyarsa, dizayn kvadrantında istifadə olunan prototip hazırlama və müştərini xilas etməyə gəlir.

Modelləşdirmə problemli və zərif tələbləri daha da müəyyən etmək üçün istifadə edilə bilər. Müştəri mühəndislik (dizayn) işini qiymətləndirir və dəyişikliklər üçün təkliflər verir (müştərinin qiymətləndirməsinin kvadrantı). Planlaşdırmanın və risk analizinin növbəti mərhələsi müştərinin təkliflərinə əsaslanır. Bir spiraldə hər dövrdə risk analizinin nəticələri "davam et, davam etmə" şəklində formalaşır. Risk çox böyükdürsə, layihə dayandırıla bilər.

Əksər hallarda, spiral davam edir, hər bir addım inkişaf etdiriciləri sistemin daha ümumi modelinə doğru hərəkət etdirir. Hər bir spiral dövrü, klassik həyat dövrü və ya prototipləşdirmə ilə həyata keçirilə bilən bir dizayn (sağ alt kvadrant) tələb edir. Diqqət yetirin ki, spiralin mərkəzindən hərəkət etdikcə inkişaf fəaliyyətlərinin sayı (sağ alt kadranda baş verir) artır.

Bu hərəkətlər nömrələnir və aşağıdakı məzmuna malikdir:

1. - tələblərin ilkin toplanması və layihə planlaşdırılması;
2. - eyni iş, lakin müştərinin tövsiyələrinə əsasən;
3. - ilkin tələblərə əsaslanan risk təhlili;
4. - müştərinin reaksiyasına əsaslanan risk təhlili;
5. - vahid sistemə keçid;
6. - sistemin ilkin quruluşu;
7. - layoutun növbəti səviyyəsi;
8. - dizayn edilmiş sistem;
9. - müştəri tərəfindən qiymətləndirmə.

Üstünlüklər spiral modeli:

1. ən real (təkamül şəklində) inkişafı əks etdirir proqram təminatı;
2. inkişafın hər bir mərhələsindəki riski açıq şəkildə nəzərə almağa imkan verir;
3. iterativ inkişaf strukturunda sistemli bir yanaşma addımını ehtiva edir;
4. riski azaltmaq və proqram məhsulunu təkmilləşdirmək üçün simulyasiyadan istifadə edir.

dezavantajlar spiral modeli:

• müqayisəli yenilik (modelin effektivliyi ilə bağlı kifayət qədər statistika yoxdur);
• müştəri üçün artan tələblər;
• inkişaf vaxtının idarə olunmasında və idarə olunmasında çətinliklər.

Spiral inkişaf prosesi modeli hazırda ən çox yayılmışdır. Ən məşhur variantlar Rational və MSF (Microsoft Solution Framework) dən RUP (Rational Unified Process). Modelləşdirmə dili olaraq UML (Vahid Modelləşdirmə Dili) istifadə olunur. Sistemin yaradılmasının bir döngədə, bir spiraldə hərəkət etməsi və eyni mərhələlərdən keçərək, hər bir döngədə gələcək məhsulun xüsusiyyətlərini təkmilləşdirməsi nəzərdə tutulur. Görünür, indi hər şey qaydasındadır: yalnız qabaqcadan planlaşdırılan, planlaşdırılan inkişaf etdirilir və istifadəçilər lazımi düzəlişlər etmək imkanı ilə məhsulla əvvəlcədən tanış olmağa başlayırlar.

Ancaq bunun üçün çox böyük vəsait lazımdır. Doğrudan da, əvvəllər lazım olduğu qədər mütəxəssis qrupları yaratmaq və dağıtmaq mümkün idisə, indi hamısı layihədə daim iştirak etməlidirlər: memarlar, proqramçılar, sınaqçılar, təlimçilər və s. dizayn həllərini vaxtında əks etdirmək və lazımi dəyişiklikləri etmək.

Rasional vahid proses

Rasional vahid proses(Rational Unified Process, RUP) ən yaxşı proqram inkişaf metodologiyalarından biridir. Bir çox uğurlu proqram layihələrinin təcrübəsinə əsaslanaraq RUP, sənaye inkişaf üsullarına əsaslanan kompleks proqram sistemləri yaratmağa imkan verir. RUP -un inkişafı üçün ilkin şərtlər 1980 -ci illərin əvvəllərində başladı. Rational Software korporasiyasında. 2003 -cü ilin əvvəlində Rational IBM aldı. RUP -un əsas sütunlarından biri, Vahid Modelləşdirmə Dilindən (UML) istifadə edərək modellərin yaradılması prosesidir.

RUP, spiral proqram inkişaf metodologiyalarından biridir. Metodologiya Rational Software tərəfindən dəstəklənir və inkişaf etdirilir. Bir model dili olaraq ümumi baza bilik vahid modelləşdirmə dilindən (UML) istifadə edir. RUP -də təkrarlanan və artan proqram inkişafı, bir layihənin ardıcıl olaraq icra olunan bir neçə layihəyə bölünməsini əhatə edir və hər bir inkişaf iterasiyası, iterasiyanın sonunda əldə edilməli olan bir sıra məqsədlərlə aydın şəkildə müəyyən edilir. Yekun təkrarlama, məhsulun müştərisi tərəfindən təyin olunan məqsədlər toplusuna tam uyğun gəlməli olduğunu, yəni bütün tələblərin yerinə yetirilməsini nəzərdə tutur.

Bu proses modellərin təkamülünü əhatə edir; inkişaf dövrünün təkrarlanması, proqram modelinin xüsusi bir versiyası ilə bənzərsiz şəkildə əlaqələndirilir. Təkrarlamaların hər birində nəzarət var proqram ömrü: analiz və dizayn (modelləşdirmə), tətbiq, inteqrasiya, test, tətbiq. Bu mənada RUP bir tətbiqdir spiral modeli tez-tez bir qrafik masası şəklində təsvir olunsa da ..

Bu rəqəm iki ölçü təqdim edir: üfüqi ox zamanı təmsil edir və prosesin həyat dövrünün müvəqqəti aspektlərini göstərir; şaquli ox, prosesin fiziki quruluşunu təyin edən fənləri təmsil edir. Zamanla layihədəki vurğuların necə dəyişdiyini görə bilərsiniz. Məsələn, erkən təkrarlamalarda tələblərə daha çox vaxt ayrılır; sonrakı təkrarlamalarda, həyata keçirilməsinə daha çox vaxt ayrılır. Üfüqi ox, hər biri müstəqil inkişaf dövrü olan zaman aralıqlarından - təkrarlardan əmələ gəlir; dövrünün məqsədi son məhsula maraqlı tərəflər baxımından faydalı olan bəzi əvvəlcədən müəyyən edilmiş maddi zəriflik gətirməkdir.

Zaman oxu boyunca həyat dövrü dörd əsas mərhələyə bölünür.

1. Başlanğıc - bir layihə konsepsiyasının formalaşdırılması, yaratdıqlarımızı başa düşmək, bir məhsulun vizyonu (vizyon), bir iş planının hazırlanması (iş nümunəsi), bir proqram prototipinin və ya qismən həllinin hazırlanması. Bu, məlumat toplamaq və tələbləri təhlil etmək, bütövlükdə layihənin imicini müəyyən etmək mərhələsidir. Məqsəd dəstək və maliyyə əldə etməkdir. Son iterasiyada bu mərhələnin nəticəsi texniki tapşırıqlardır.
2. Dizayn, inkişaf (işlənmə) - planı aydınlaşdırmaq, necə yaratdığımızı anlamaq, layihələndirmək, lazımi hərəkətləri və mənbələri planlaşdırmaq, xüsusiyyətləri detallandırmaq. Mərhələ, bütün memarlıq qərarlarının verildiyi və risklərin nəzərə alındığı zaman, icra edilə bilən memarlıqla başa çatır. İcra edilə bilən bir arxitektura, əsas memarlıq həllərinin tətbiqini nümayiş etdirən çalışan bir proqramdır. Son iterasiyada bu texniki bir layihədir.
3. Sistemin tətbiqi, yaradılması (İnşaat) - sistemin memarlığa daxil olan funksionallığının genişləndirilməsi mərhələsidir. Son iterasiyada bu işləyən bir layihədir.
4. İcra, yerləşdirmə (Keçid). Məhsulun son versiyasının yaradılması. Məhsulun tətbiqi mərhələsi, məhsulun müəyyən bir istifadəçiyə çatdırılması (replikasiya, çatdırılma və təlim).

Şaquli ox fənlərdən ibarətdir, hər biri yerinə yetirilən vəzifələr, bunlardan məsul olan rollar, tapşırıqlara giriş kimi təqdim olunan və icrası zamanı sərbəst buraxılan məhsullar və s.

Bu ox boyunca, tez-tez rus dilində proseslər adlanan RUP həyat dövrünün əsas fənləri var, baxmayaraq ki, IBM (və / və ya üçüncü tərəf) vasitələri tərəfindən dəstəklənən bu metodologiya baxımından tamamilə doğru deyil.

1. Biznes təhlili və modelləşdirilməsi (Biznes modelləşdirmə), bir təşkilatın işini öyrənmək və bu barədə məlumat toplamaq, iş proseslərini optimallaşdırmaq və qismən və ya tam avtomatlaşdırılmasına qərar vermək üçün modelləşdirmə prinsiplərinin həyata keçirilməsini təmin edir.
2. Tələblərin idarə edilməsi, maraqlı tərəflərdən məlumat əldə etmək və onu inkişaf etdirilən sistemin məzmununu və sistemin nə etməli olduğu ilə bağlı gözləntiləri təyin edən bir sıra tələblərə çevirməkdən ibarətdir.
3. Analiz və dizayn, tələblərin necə həyata keçirilməsini əks etdirən aralıq təsvirlərə (modellərə) çevrilmə prosedurlarını əhatə edir.
4. İcra, kodun hazırlanmasını, geliştirici səviyyəsində sınaqdan keçirilməsini və komponentlərin, alt sistemlərin və bütün sistemin müəyyən edilmiş spesifikasiyalara uyğun olaraq inteqrasiyasını əhatə edir.
5. Test (Test) yaradılan məhsulun keyfiyyətinin qiymətləndirilməsinə həsr edilmişdir.
6. Dağıtım, məhsullar müştərilərə ötürüldükdə və məhsul son istifadəçilərə təqdim edildikdə baş verən əməliyyatları əhatə edir.
7. Konfiqurasiya idarəçiliyi, orta proqram və son məhsulları sinxronizasiya etmək və layihə boyunca inkişafını idarə etmək və gizli problemləri tapmaqdır.
8. Layihə İdarəçiliyi (İdarəetmə) bir layihə planlaşdırmağa, riski idarə etməyə, gedişini izləməyə və əsas göstəriciləri davamlı olaraq qiymətləndirməyə həsr edilmişdir.
9. Ətraf mühitin idarə edilməsi (Ətraf mühit) bir informasiya sisteminin inkişaf mühitinin formalaşması və layihə fəaliyyətlərinə dəstək elementlərini ehtiva edir.

Layihənin xüsusiyyətlərindən asılı olaraq hər hansı bir IBM Rational və ya üçüncü tərəf vasitələrindən istifadə edilə bilər. RUP layihənin uğurlu inkişafı üçün altı təcrübə tövsiyə edir: iterativ inkişaf; tələblərin idarə edilməsi; modul memarlıqdan istifadə; vizual modelləşdirmə; keyfiyyətin yoxlanılması; dəyişiklikləri izləmək.

RUP -un ayrılmaz hissəsi artefakt, presedent və roldan ibarətdir. Artefaktlar, son məhsul üzərində işdə yaranan və ya istifadə olunan bir layihənin məhsullarından bəziləridir. İstifadə halları, müşahidə edilə bilən bir nəticə əldə etmək üçün sistem tərəfindən edilən hərəkətlər ardıcıllığıdır. Əslində, bir fərdin və ya qrupun işinin hər hansı bir nəticəsi bir təhlil sənədi, bir model elementi, bir kod faylı, bir test skripti, bir səhvin təsviri və s. bu və ya digər növ əsərlərdən. Beləliklə, RUP inkişaf qrupunun hər bir üzvünün bu və ya digər mərhələdəki məsuliyyətlərini - rollarını - yəni bu və ya digər əsərin nə vaxt və kim tərəfindən yaradılmasını aydın şəkildə müəyyən edir. Bir proqram sisteminin inkişaf etdirilməsinin bütün prosesi RUP -da artefaktların yaradılması prosesi hesab olunur - ilkin analiz sənədlərindən icra olunan modullara, istifadəçi təlimatlarına və s.

RUP proseslərinin kompüter dəstəyi üçün IBM geniş bir alət dəsti hazırladı:

• Rasional Gül - CASE- vizual simulyator informasiya sistemləri kod elementləri yaratmaq qabiliyyətinə malikdir. Məhsulun xüsusi bir nəşri - Rational Rose RealTime - çıxışda icra edilə bilən bir modul əldə etməyə imkan verir;
• Rational Requisite Pro, tətbiq komponentlərinin inkişafının hər hansı bir mərhələsində baş verən dəyişiklikləri yaratmağa, qurmağa, prioritetləşdirməyə, izləməyə və nəzarət etməyə imkan verən tələblər idarəetmə vasitəsidir;
• Rational ClearQuest, bir layihədəki dəyişikliklərin idarə edilməsi və qüsurların izlənməsi üçün bir məhsuldur (səhv izləmə), test və tələblərin idarə edilməsi vasitələri ilə sıx birləşdirilmiş və bütün səhvləri və sənədləri bir -biri ilə əlaqələndirmək üçün vahid bir mühit təmin edir;
• Rasional SoDA, daxili sənədlər üçün korporativ standart təyin etməyə imkan verən layihə sənədlərinin avtomatik istehsalı üçün bir məhsuldur. Sənədləri mövcud standartlara (ISO, CMM) gətirmək də mümkündür;
• Rational PureCoverage - Rational PureCoverage - Sınaq və ayıklama vasitələri;
• Rational Visual Quantify, C / C ++, Visual Basic və Java proqramlaşdıran proqram və komponent inkişaf etdiriciləri üçün bir performans ölçmə vasitəsidir; proqram təminatında yaranan darboğazları aşkar etməyə və aradan qaldırmağa kömək edir;
• Rasional Visual PureCoverage - Test edilməyən kod sahələrini avtomatik olaraq təyin edir.
• Rational ClearCase, bütün layihə sənədlərinin versiya nəzarətinə imkan verən bir proqram konfiqurasiya idarəetmə məhsuludur (SCM). Eyni anda birdən çox layihənin versiyasını saxlamağa imkan verir, aralarında tez keçid edir. Rational Requisite Pro yeniləmələri dəstəkləyir və tələblərdəki dəyişiklikləri izləyir. inkişaf qrupu üçün;
• SQA TeamTest - Alət test avtomatlaşdırılması;
• Rasional TestManager, testlə əlaqəli bütün alətləri, əsərləri, skriptləri və məlumatları bir araya gətirən bir test idarəetmə sistemidir;
• Rational Robot, testlər yaratmaq, dəyişdirmək və avtomatik olaraq işlətmək üçün bir vasitədir;
• SiteLoad, SiteCheck - veb saytların performans və pozulmuş bağlantılar üçün sınanması üçün vasitələr;
• Rational PerformanceStudio - Sistemin performans xüsusiyyətlərini ölçün və proqnozlaşdırın.

Bu məhsullar dəsti daim təkmilləşdirilir və doldurulur. Məsələn, son məhsul olan IBM Rational Software Architect (RSA), proqram inkişaf ömrünü dəstəkləyən alətlər dəsti olan IBM Software Development Platform -un bir hissəsidir. IBM Rational Software Architect məhsulu, UML 2.0 -in vahid modelləşdirmə dilindən istifadə edərək inkişaf etmiş proqram sistemlərinin modellərini, ilk növbədə inkişaf etdirilən tətbiqin memarlıq modellərini qurmaq üçün nəzərdə tutulmuşdur. Bununla birlikdə, RSA Rational Application Developer, Rational Web Developer və Rational Software Modeler kimi proqram məhsullarının funksiyalarını birləşdirir və bununla da memarlara və analitiklərə UML 2.0 -dan istifadə etməklə inkişaf etdirilən informasiya sistemi haqqında fərqli fikirlər yaratmağa və inkişaf etdiricilərə inkişaf etdirməyə imkan verir. J2EE, XML, veb xidmətləri və s.

RUP prinsiplərinə riayət edərək Rational Software Architect, aşağıdakı kimi fənlərin iş axını daxilində lazımi modelləri yaratmağa imkan verir:

• biznes təhlili və modelləşdirilməsi (Biznes modelləşdirmə);
• tələblərin idarə edilməsi (Tələblər);
• analiz və dizayn (Analiz və Dizayn);
• həyata keçirilməsi

Bundan əlavə, Rational Software Architect, proqramın modelləşdirilməsinə imkan verən modelə əsaslanan inkişaf (MDD) texnologiyasını dəstəkləyir müxtəlif səviyyələrdə izlənilə bilən abstraksiyalar.

MSF (Microsoft Solution Framework)

1994 -cü ildə, İT layihələrinin təsirini maksimum dərəcədə artırmaq məqsədi ilə, Microsoft öz texnologiyalarına əsaslanan həllərin effektiv dizaynı, inkişafı, tətbiqi və saxlanılması üçün bir sıra təlimatlar dərc etdi. Bu bilik, proqram təminatının hazırlanması və saxlanılması üçün böyük layihələr üzərində işləyərkən Microsoft -un əldə etdiyi təcrübəyə, Microsoft məsləhətçilərinin təcrübəsinə və İT sənayesinin bu günə qədər topladığı ən yaxşısına əsaslanır. Bütün bunlar bir-biri ilə əlaqəli və bir-birini tamamlayan iki bilik sahəsi şəklində təqdim olunur: Microsoft Solutions Framework (MSF) və Microsoft Operations Framework (MOF).

Qeyd etmək lazımdır ki, Microsoft tətbiqli və xüsusi istifadə üçün ümumi MSF metodlarına əsaslanan metodologiyalar hazırlamışdır. Bundan əlavə, Microsoft, MSF tətbiqində xüsusi olaraq tətbiq olunan biliklərə sahib olan mütəxəssisləri sertifikatlaşdırır (məsələn, layihə idarəetmə texnikası üzrə təcrübə üçün MCTS 74-131 sertifikatı). MSF üsullarını öyrənməzdən əvvəl, hansı MSF tətbiqinə istinad etdiyinizi təyin etməlisiniz.

Microsoft tərəfindən hazırlanmış ən populyar MSF proqramları bunlardır:

• layihə idarəçiliyi sahəsində həllərin həyata keçirilməsi metodologiyası;
• MSF və Çevik metodologiyalarına əsaslanan İT layihələrinin idarə edilməsi metodologiyası.

Microsoft -un İT layihələrində MSF metodologiyasından "təmiz versiyada" istifadə etməməsi MSF tətbiqlərinin əhəmiyyətini vurğulayır. Microsoft Consulting Services layihələri hibrid MSF və Çevik metodologiyasından istifadə edir. Microsoft mütəxəssisləri tərəfindən hazırlanmış MSF -nin tətbiq olunan versiyalarında xarici əhəmiyyətli fərqlərə baxmayaraq, onlar üçün MSF metodlarının əsası ümumi olaraq qalır və təkrarlanan layihə idarəçiliyinə ümumi metodoloji yanaşmaları əks etdirir.

MOF, Microsoft məhsullarına və texnologiyalarına əsaslanan kritik BT həlləri quran təşkilatlara etibarlılıq, əlçatanlıq, qulluq asanlığı(dəstəklənə bilən) və idarə oluna bilən (idarə oluna bilən). MOF insanların və proseslərin təşkili ilə bağlı məsələləri həll edir; mürəkkəb, paylanmış və heterojen İT mühitlərində texnologiya və idarəetmə. MOF, Böyük Britaniyanın hökumət təşkilatı olan Mərkəzi Kompüter və Telekommunikasiya Agentliyi tərəfindən tərtib edilən IT İnfrastruktur Kitabxanasında (ITIL) tərtib edilmiş ən yaxşı istehsal təcrübələrinə əsaslanır.

Ayrılmış vaxt və büdcə daxilində bir iş həllinin qurulması sübut edilmiş metodoloji çərçivə tələb edir. MSF uğurlu İT həllərinin planlaşdırılması, dizaynı, inkişafı və tətbiqi üçün sübut edilmiş metodologiyalar təqdim edir. MSF, elastikliyi, ölçeklenebilirliği və sərt qaydaların olmaması sayəsində istənilən ölçülü bir təşkilatın və ya layihə qrupunun ehtiyaclarını ödəyə bilir. MSF metodologiyası, əksər layihələr üçün ümumi olan insanları, prosesləri, texnologiya elementlərini və əlaqəli problemləri idarə etmək üçün prinsiplərdən, modellərdən və fənlərdən ibarətdir. MSF iki model və üç fəndən ibarətdir. Bunlar 5 bəyannamədə ətraflı şəkildə verilmişdir. MSF -ni modellərlə öyrənməyə başlamaq daha yaxşıdır (layihə komandası modeli, proses modeli) və sonra fənlərə keçmək (layihə idarəetmə intizamı, risk idarəetmə intizamı, təlim idarəetmə intizamı).

MSF proses modeli İT həllərinin hazırlanması və tətbiqi üçün ümumi metodologiyanı təmin edir. Bu modelin özəlliyi, elastikliyi və sərt şəkildə tətbiq olunan prosedurların olmaması səbəbindən çox geniş İT layihələrinin hazırlanmasında tətbiq oluna bilməsidir. Bu model iki standart istehsal modelinin xüsusiyyətlərini özündə birləşdirir: şəlalə və spiral. MSF 3.0 -dakı proses modeli başqa bir yenilikçi cəhətlə tamamlandı: başlanğıc nöqtəsindən faktiki tətbiqinə qədər bir həll yaratmağın bütün həyat dövrünü əhatə edir. Bu yanaşma, layihə qruplarının həllinin iş dəyərinə diqqət yetirməsinə kömək edir, çünki bu gəlir yalnız məhsul yerləşdirildikdən və istifadə edildikdən sonra gerçəkləşir.

MSF prosesi, hər hansı bir əhəmiyyətli (aralıq və ya son) nəticə əldə etməyi xarakterizə edən, layihənin əsas məqamları olan "mərhələlərə" yönəlmişdir. Bu nəticəni qiymətləndirmək və təhlil etmək olar ki, bu da sualların cavabını nəzərdə tutur: "Layihə qrupu layihənin məqsədləri və əhatə dairəsi haqqında birmənalı bir anlayışa varmı?", "Fəaliyyət planı kifayət qədər hazırdırmı?" Həlli cavab verirmi? müştərinin ehtiyacları? " və s.

MSF Proses Modeli dizayn tələblərində daimi dəyişiklikləri qəbul edir. Bir həllin inkişafının, həllin ən sadə versiyalarından son formasına qədər mütərəqqi bir hərəkət yaradan qısa dövrlərdən ibarət olması lazım olduğunu düşünür.

MSF Proses Modelinin xüsusiyyətləri bunlardır:

• mərhələ və mərhələ yanaşması;
• iterativ yanaşma;
• həllərin yaradılması və həyata keçirilməsinə vahid bir yanaşma.

Proses modeli inkişaf prosesinin əsas mərhələlərini əhatə edir:

• konsepsiya inkişafı (Təsəvvür);
• planlaşdırma (Planlaşdırma);
• inkişaf (İnkişaf etməkdədir);
• sabitləşmə;
• yerləşdirmə (yerləşdirmə).

Bundan əlavə, layihədə müəyyən irəliləyişlər göstərən və böyük iş seqmentlərini daha kiçik, görünən sahələrə ayıran çox sayda mərhələ var. Proses modelinin hər mərhələsi üçün MSF müəyyən edir:

• bu mərhələnin nəticəsidir (hansı əsərlər);
• rol qruplarının hər biri bu mərhələdə nə üzərində işləyir.

MSF daxilində kod, sənədlər, dizaynlar, planlar və digər iş materialları ümumiyyətlə iterativ şəkildə yaradılır. MSF, həlli inkişaf etdirməyə əsas funksiyaları qurmaq, sınamaq və tətbiq etməklə başlamağı tövsiyə edir. Daha sonra həll yoluna daha çox xüsusiyyət əlavə olunur. Bu strategiyaya versiya strategiyası deyilir. Kiçik layihələr üçün tək versiya buraxılışı kifayət olsa da, bir həll üçün birdən çox versiya yaratmaq fürsətini əldən verməməyiniz tövsiyə olunur. Yeni versiyaların yaradılması ilə həllin funksionallığı inkişaf edir.

İnkişaf prosesinə təkrarlanan bir yanaşma, sənədlərin saxlanmasının çevik bir yolunu tələb edir. Layihə son məhsula olan tələblərin dəyişməsi ilə birlikdə yaşayış sənədləri də dəyişməlidir. MSF, məhsul inkişafının hər bir mərhələsinin əsərləri olan və inkişaf prosesini planlaşdırmaq və idarə etmək üçün istifadə edilə bilən bir sıra standart sənəd şablonları təqdim edir.

Həll tətbiq olunana qədər heç bir iş dəyəri yoxdur. Məhz bu səbəbdən MSF Proses Modelində, həllinin ödəməyə başladığı vaxta qədər, onun həyata keçirilməsi də daxil olmaqla, bir həllin bütün həyat dövrü var.

Müəyyən etməklə başlayınProqramın həyat dövrü(Proqram Həyat Döngüsü Modeli), bir proqram məhsulu yaratmaq qərarının verildiyi andan başlayaraq tam istifadədən çıxdığı anda bitən bir müddətdir. Bu dövr, proqram qurma və inkişaf etdirmə prosesidir.

Proqram Ömrü Modelləri

Həyat dövrü modellər şəklində təqdim edilə bilər. Hal -hazırda ən çox yayılmışlar:kaskad, artımlı (ara nəzarət ilə addım-addım model ) və spiralhəyat dövrü modelləri.

Kaskad modeli

Kaskad modeli(ing. şəlalə modeli) Həyat dövrü tələblərin təhlili və dizayn mərhələlərindən ardıcıl keçən bir axına bənzəyən bir proqram inkişaf prosesinin bir modelidir. tətbiq, test, inteqrasiya və dəstək.

İnkişaf prosesi sifarişli müstəqil addımlar ardıcıllığı ilə həyata keçirilir. Model, hər bir sonrakı addımın əvvəlki addımın tamamlanmasından sonra başladığını güman edir. Modelin bütün addımlarında, layihə idarəçiliyi, qiymətləndirmə və keyfiyyət idarəçiliyi, yoxlama və doğrulama, konfiqurasiya idarəçiliyi və sənədlərin hazırlanması da daxil olmaqla köməkçi və təşkilati proseslər və fəaliyyətlər həyata keçirilir. Addımların tamamlanması nəticəsində sonrakı mərhələlərdə dəyişdirilə bilməyən aralıq məhsullar əmələ gəlir.

Həyat dövrü ənənəvi olaraq aşağıdakı əsaslara bölünürmərhələlər:

1. Tələblərin təhlili,
2. Dizayn,
3. Kodlaşdırma (proqramlaşdırma),
4. Test və ayıklama,
5. Əməliyyat və texniki xidmət.

Modelin üstünlükləri:

• bütün inkişaf dövrü ərzində tələblərin sabitliyi;
• hər mərhələdə tamlıq və ardıcıllıq meyarlarına cavab verən layihə sənədlərinin tam dəsti formalaşdırılır;
• modelin addımlarının dəqiqliyi və başa düşülməsi və tətbiqinin asanlığı;
• məntiqi ardıcıllıqla görülən işlərin mərhələləri, bütün işlərin başa çatma vaxtını və müvafiq mənbələri (pul, maddi və insan) planlaşdırmağa imkan verir.

Modelin dezavantajları:

• tələblərin aydın tərtib edilməsinin mürəkkəbliyi və tam həyat dövrü ərzində dinamik dəyişməsinin mümkünsüzlüyü;
• layihə idarəçiliyində aşağı çeviklik;
• inkişaf prosesinin xətti quruluşunun ardıcıllığı, nəticədə ortaya çıxan problemləri həll etmək üçün əvvəlki addımlara qayıtmaq xərclərin artmasına və iş qrafikinin pozulmasına səbəb olur;
• aralıq məhsulun istifadəyə uyğun olmaması;
• unikal sistemlərin çevik modelləşdirilməsinin mümkünsüzlüyü;
• inkişafın sonunda bütün nəticələrin eyni vaxtda inteqrasiyası səbəbindən montaj problemlərinin gec aşkarlanması;
• sistemin yaradılmasında kifayət qədər istifadəçi iştirakı - başlanğıcda (tələblər hazırlanarkən) və sonunda (qəbul testləri zamanı);
• istifadəçilər bütün inkişaf prosesinin sonuna qədər inkişaf etdirilən məhsulun keyfiyyətindən əmin ola bilməzlər. Keyfiyyəti qiymətləndirmək imkanları yoxdur, çünki inkişafın bitmiş məhsulunu görə bilməzsiniz;
• istifadəçinin tədricən sistemə alışması üçün heç bir yol yoxdur. Öyrənmə prosesi həyat dövrünün sonunda, proqram təminatı artıq istifadəyə verildikdə baş verir;
• hər bir mərhələ sonrakı hərəkətlərin həyata keçirilməsi üçün bir şərtdir, bu da analoqu olmayan sistemlər üçün bu üsulu riskli bir seçim halına gətirir, çünki çevik modelləşdirməyə qarşı çıxır.

Proqram inkişafının mürəkkəbliyi səbəbiylə, əvvəlki addımlara qayıtmadan və ortaya çıxan problemləri aradan qaldırmaq üçün nəticələrini dəyişdirmədən Şəlalə Həyat Dövrü Modelini tətbiq etmək çətindir.

Şəlalə Modelinin əhatə dairəsi

Şəlalə modelinin əhatə dairəsinin məhdudluğu onun mənfi cəhətləri ilə müəyyən edilir. Onun istifadəsi aşağıdakı hallarda ən təsirli olur:

1. aydın, dəyişməz olan layihələr hazırlayarkənhəyat dövrü tələblər, başa düşülən tətbiq və texniki metodologiya;
2. əvvəllər inkişaf etdiricilər tərəfindən hazırlanan eyni tipli bir sistem və ya məhsul qurmağa yönəlmiş bir layihə hazırlayarkən;
3. mövcud bir məhsulun və ya sistemin yeni bir versiyasının yaradılması və buraxılması ilə əlaqədar bir layihə hazırlayarkən;
4. mövcud bir məhsulun və ya sistemin yeni bir platformaya köçürülməsi ilə əlaqədar bir layihə hazırlayarkən;
5. bir neçə böyük inkişaf qrupunun iştirak etdiyi böyük layihələr həyata keçirərkən.

Artan model

(aralıq nəzarət ilə mərhələli model)

Artan model(ing. artım- artım, artım) xətti mərhələlər ardıcıllığı ilə proqram təminatının hazırlanmasını nəzərdə tutur, lakin bir neçə artımla (versiya), yəni. Proqram İnkişaf Ömrü sona çatana qədər bütün müddət ərzində məhsulun planlaşdırılan təkmilləşdirilməsi ilə.

Proqram təminatı inkişaf mərhələləri arasında geribildirim döngələri ilə təkrarlanır. Mərhələlərarası düzəlişlər, inkişaf mərhələlərinin müxtəlif mərhələlərdə həqiqətən mövcud olan qarşılıqlı təsirini nəzərə almağa imkan verir, hər mərhələnin ömrü bütün inkişaf dövrü boyunca uzanır.

Bir layihə üzərində işin əvvəlində, sistem üçün bütün əsas tələblər müəyyən edilir və daha az əhəmiyyət kəsb edir. Bundan sonra, sistem artımlar prinsipinə uyğun olaraq inkişaf etdirilir ki, geliştirici proqramın hazırlanması zamanı əldə edilən məlumatlardan istifadə edə bilsin. Hər bir artım sistemə bəzi funksiyalar əlavə etməlidir. Buraxılış ən yüksək prioritet komponentlərdən başlayır. Sistemin hissələri müəyyən edildikdə, birinci hissəni götürür və ən uyğun prosesi istifadə edərək detallandırmağa başlayırlar. Eyni zamanda, bu işin mövcud tələblər dəstində dondurulmuş digər hissələrə olan tələbləri aydınlaşdırmaq mümkündür. Gerekirse, daha sonra bu hissəyə qayıda bilərsiniz. Parça hazırdırsa, işdə istifadə edə biləcək müştəriyə çatdırılır. Bu, müştəriyə aşağıdakı komponentlərə olan tələbləri aydınlaşdırmağa imkan verəcəkdir. Sonra sistemin növbəti hissəsini inkişaf etdirirlər. Bu prosesdəki əsas addımlar, proqram tələblərinin bir alt qrupunu sadəcə tətbiq etmək və proqram tam tətbiq olunana qədər modeli ardıcıl buraxılışlarda təkmilləşdirməkdir.

Bu modelin həyat dövrü, son nəticənin nəyi əks etdirməli olduğu barədə (həm müştəri tərəfdən, həm də inkişaf etdirici tərəfdən) aydın bir baxışa malik olan kompleks və kompleks sistemlərin inkişafı üçün xarakterikdir. Versiyanın inkişafı müxtəlif səbəblərə görə aparılır:

• müştərinin bütün bahalı layihəni dərhal maliyyələşdirmə qabiliyyətinin olmaması;
• inkişaf etdiricinin qısa müddətdə kompleks bir layihə həyata keçirmək üçün lazımi mənbələri yoxdur;
• son istifadəçilər tərəfindən mərhələli tətbiq və məhsulun inkişafı üçün tələblər. Bütün sistemin bir anda tətbiqi istifadəçiləri arasında rədd edilməsinə səbəb ola bilər və yalnız yeni texnologiyalara keçid prosesini "ləngidir". Obrazlı desək, "böyük bir parçanı həzm edə bilmirlər, buna görə də parçalanıb parçalara bölünməlidir".

Üstünlüklər və məhdudiyyətlərbu model (strategiya) şəlalə ilə eynidir (klassik həyat dövrü modeli). Ancaq klassik strategiyadan fərqli olaraq müştəri nəticəni daha erkən görə bilər. Artıq birinci versiyanın hazırlanması və tətbiqinin nəticələrinə əsaslanaraq, inkişaf tələblərini bir qədər dəyişdirə bilər, ondan imtina edə bilər və ya yeni bir müqavilə bağlayaraq daha mükəmməl bir məhsulun inkişafını təklif edə bilər.

Üstünlüklər:

• dəyişən istifadəçi tələbləri səbəbindən çəkilən xərclər azalır, yenidən təhlil və sənədlərin toplanması şəlalə modelinə nisbətən əhəmiyyətli dərəcədə azalır;
• Müştəridən görülən işlər haqqında rəy almaq daha asandır - müştərilər hazır hissələr haqqında öz fikirlərini səsləndirə və artıq nə edildiyini görə bilərlər. Çünki sistemin ilk hissələri bir bütün olaraq sistemin prototipidir.
• müştəri proqram təminatını tez əldə etmək və mənimsəmək qabiliyyətinə malikdir - müştərilər şəlalə modeli ilə mümkün olandan daha erkən sistemdən real faydalar əldə edə bilərlər.

Modelin dezavantajları:

• menecerlər prosesin gedişatını daim ölçməlidirlər. sürətli inkişaf halında, hər bir minimum versiya dəyişikliyi üçün sənədlər yaratmağa dəyməz;
• yeni komponentlər əlavə edildikdə sistemin quruluşu pisləşməyə meyllidir - daimi dəyişikliklər sistemin quruluşunu pozur. Bunun qarşısını almaq, yenidən işləmək üçün əlavə vaxt və pul tələb edir. Zəif quruluş proqramın dəyişdirilməsini çətinləşdirir və bahalı edir. Proqramın kəsilmiş bir həyat dövrü daha da böyük itkilərə səbəb olur.

Sxem, ortaya çıxan dəyişikliklərin dərhal nəzərdən keçirilməsinə və proqram tələblərinin aydınlaşdırılmasına imkan vermir. İstifadəçilərlə inkişaf nəticələrinin əlaqələndirilməsi yalnız işin hər bir mərhələsi başa çatdıqdan sonra planlaşdırılan nöqtələrdə aparılır və proqram təminatı üçün ümumi tələblər yaradıldığı bütün müddət üçün texniki tapşırıq şəklində müəyyən edilir. Beləliklə, istifadəçilər tez -tez real ehtiyaclarını ödəməyən bir PP alırlar.

Spiral model

Spiral model:Həyat dövrü - spiralin hər döngəsində məhsulun növbəti versiyası yaradılır, layihənin tələbləri aydınlaşdırılır, keyfiyyəti müəyyən edilir və növbəti növbənin işi planlaşdırılır. İnkişafın ilkin mərhələlərinə - analiz və dizayna xüsusi diqqət yetirilir ki, burada müəyyən texniki həllərin məqsədəuyğunluğu prototipləşdirmə yolu ilə yoxlanılır və əsaslandırılır.

Bu model, aşağıdan yuxarıya və yuxarıdan aşağıya doğru bir anlayışın üstünlüklərini birləşdirmək üçün həm dizaynı, həm də mərhələli prototipləşdirməni özündə birləşdirən, həyat dövrünün ilkin mərhələlərinə: təhlil və dizayna diqqət yetirən bir proqram inkişaf prosesidir.Fərqləndirici xüsusiyyət Bu model, həyat dövrünün təşkilinə təsir edən risklərə xüsusi diqqət yetirir.

Analiz və dizayn mərhələlərində texniki həllərin məqsədəuyğunluğu və müştəri məmnuniyyətinin dərəcəsi prototipləşdirmə yolu ilə yoxlanılır. Spiralın hər növbəsi sistemin işlək bir hissəsinin və ya versiyasının yaradılmasına uyğundur. Bu, layihənin tələblərini, məqsədlərini və xüsusiyyətlərini aydınlaşdırmağa, inkişaf keyfiyyətini təyin etməyə, spiralın növbəti turunun işini planlaşdırmağa imkan verir. Beləliklə, layihənin təfərrüatları dərinləşdirilir və ardıcıl olaraq dəqiqləşdirilir və nəticədə müştərinin faktiki tələblərinə cavab verən və həyata keçirilməsinə gətirilən ağlabatan bir seçim seçilir.

Spiralın hər döngəsindəki həyat dövrü - proqram inkişaf prosesinin fərqli modelləri tətbiq oluna bilər. Nəhayət, son məhsul bitmiş məhsuldur. Model, prototipləşdirmə modelinin imkanlarını özündə birləşdirirşəlalə modeli... Yinelemelerle inkişaf, sistem yaratmanın obyektiv olaraq mövcud olan spiral dövrünü əks etdirir. Hər mərhələdə işin tamamlanmaması, hazırkı mərhələdə işin tamamlanmasını gözləmədən növbəti mərhələyə keçməyə imkan verir. Əsas vəzifə, sistem istifadəçilərinə mümkün qədər tez işləyən bir məhsul göstərmək və bununla da tələblərin dəqiqləşdirilməsi və tamamlanması prosesini aktivləşdirməkdir.

Modelin üstünlükləri:

• sistem istifadəçilərinə işlək bir məhsulu tez bir zamanda göstərməyə imkan verir və bununla da tələblərin aydınlaşdırılması və tamamlanması prosesini aktivləşdirir;
• standart inkişaflar da daxil olmaqla, əksər inkişaflar üçün tipik olan proqram təminatının inkişafı üçün tələblərin dəyişdirilməsinə imkan verir;
• model, şəlalə modelinin üstünlüklərini təcəssüm etdirdiyi üçün eyni modelin bütün mərhələlərində təkrarlanmasına icazə verildiyi üçün çevik dizayn imkanı verir;
• daha etibarlı və sabit bir sistem əldə etməyə imkan verir. Proqram inkişaf etdikcə hər iterasiyada səhvlər və zəifliklər aşkar edilir və düzəldilir;
• bu model istifadəçilərə planlaşdırma, risk təhlili, inkişaf və qiymətləndirmə fəaliyyətlərində fəal iştirak etməyə imkan verir;
• müştəri riskləri azalır. Müştəri özü üçün minimal maliyyə itkisi ilə perspektivsiz bir layihənin hazırlanmasını başa çatdıra bilər;
• İstifadəçilərdən inkişaf etdiricilərə olan geribildirim, istədiyiniz məhsulun yüksək keyfiyyətli olmasını təmin etmək üçün yüksək tezlikdə və modelin əvvəlində edilir.

Modelin dezavantajları:

• layihə aşağı riskli və ya kiçik ölçülüdürsə, model bahalı ola bilər. Hər spiraldən sonra risklərin qiymətləndirilməsi baha başa gəlir;
• Bir modelin həyat dövrü mürəkkəb bir quruluşa malikdir, buna görə inkişaf etdiricilər, menecerlər və müştərilər üçün ondan istifadə etmək çətin ola bilər;
• spiral sonsuza qədər davam edə bilər, çünki hər bir müştərinin yaradılmış versiyaya cavabı layihənin tamamlanmasını gecikdirən yeni bir dövr yarada bilər;
• çox sayda ara dövrə əlavə sənədlərin işlənməsinə ehtiyac yarada bilər;
• modelin istifadəsi baha başa gələ bilər və hətta qadağan edilə bilər. vaxt. xərclənmiş planlaşdırma, hədəfləri yenidən müəyyənləşdirmə, risk təhlili və prototip hazırlama həddindən artıq ola bilər;
• gələcəkdə inkişaf prosesini davam etdirmək istəyini göstərən məqsəd və mərhələləri təyin etmək çətin ola bilər

Spiral dövrünün əsas problemi, növbəti mərhələyə nə vaxt keçiləcəyini müəyyənləşdirməkdir. Bunu həll etmək üçün mərhələlərin hər biri üçün vaxt məhdudiyyətləri tətbiq olunur.həyat dövrü və keçid planlaşdırılan işlərin hamısı tamamlanmasa da, planlaşdırıldığı kimi davam edir.Planlaşdırmaəvvəlki layihələrdə əldə edilən statistik məlumatlar əsasında hazırlanır və Şəxsi təcrübə inkişaf etdiricilər.

Spiral Model Tətbiqləri

Spiral modelin istifadəsi aşağıdakı hallarda məsləhət görülür:

• yeni texnologiyalardan istifadə edərək layihələr hazırlayarkən;
• yeni bir məhsul və ya sistem seriyası hazırlayarkən;
• gözlənilən layihələr hazırlayarkən əhəmiyyətli dəyişikliklər və ya tələblərə əlavələr;
• uzunmüddətli layihələr həyata keçirmək;
• qısa müddət ərzində bir sistemin və ya məhsulun keyfiyyətinin və versiyalarının nümayişini tələb edən layihələr hazırlayarkən;
• layihələr hazırlayarkən. bunun üçün risklərin qiymətləndirilməsi və həlli ilə əlaqədar xərcləri hesablamaq lazımdır.

Proqram ömrü standartları

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

Standart GOST 34 .601-90

İterativ model

Ardıcıl modelə alternativ, sözdə iterativ və artan inkişaf modelidir (ing. təkrarlanan və artan inkişaf, IID ), 70 -ci illərdə T. Gilbdən də almışdır. başlıq təkamül modeli... Bu model də adlanır təkrarlanan model və artımlı model .

IID modeli, bütövlükdə layihə ilə müqayisədə daha kiçik funksionallıqların yaradılması üçün tətbiq olunan bütün inkişaf prosesləri daxil olmaqla, hər biri "mini layihəyə" bənzəyən bir sıra təkrarlamalara bölünməyi nəzərdə tutur. Hər birinin məqsədi təkrarlamalar- bütün əvvəlki və cari iterasiyaların inteqrasiya olunmuş məzmunu ilə müəyyən edilmiş funksionallıq daxil olmaqla proqram sisteminin işlək bir versiyasını əldə etmək. Son təkrarlamanın nəticəsi məhsulun bütün lazımi funksiyalarını ehtiva edir. Beləliklə, hər bir iterasiyanın tamamlanması ilə məhsul artım qazanır - artım- bu səbəbdən inkişaf edən qabiliyyətlərinə təkamüllə... Bu vəziyyətdə təkrarlama, artanlıq və təkamülçülük, eyni mənanın bir az fərqli nöqtələrdən fərqli sözlərlə ifadəsidir.

T. Gilbaya görə, “təkamül sabitliyin görünüşünü yaratmaq üçün hazırlanmış bir texnikadır. Oran uğurlu quruluş kompleks sistem bir neçə kiçik addımda həyata keçirilərsə və hər bir addımda yaxşı müəyyən edilmiş bir müvəffəqiyyət varsa və uğursuzluq halında əvvəlki müvəffəqiyyətli mərhələyə "geri çəkilmə" ehtimalı varsa, maksimuma çatacaq. Bir sistem yaratmaq üçün nəzərdə tutulmuş bütün mənbələri işə salmadan əvvəl, geliştirici real dünyadan rəy almaq və düzəltmək imkanı əldə edir. mümkün səhvlər layihədə ".

IID yanaşmasının mənfi cəhətləri var, bunlar əslində - arxa tərəf ləyaqət. Birincisi, uzun müddətdir ki, layihənin imkanları və məhdudiyyətləri haqqında vahid bir anlayış yoxdur. İkincisi, təkrar edərkən, əvvəllər görülən işlərin bir hissəsini ləğv etməlisiniz. Üçüncüsü, iş görərkən mütəxəssislərin vicdanlılığı hələ də azalır, bu da psixoloji cəhətdən başa düşüləndir, çünki daim "hər şey sonradan dəyişdirilə və yaxşılaşdırıla bilər" hissinin hakimiyyəti altındadır.

İterativ yanaşmanın müxtəlif versiyaları ən müasir inkişaf metodologiyalarında (RUP, MSF,) tətbiq olunur.

Spiral model

Hər bir təkrar proqramın bir hissəsinin və ya bir versiyasının yaradılmasına uyğundur, bunun üzərində layihənin məqsədləri və xüsusiyyətləri göstərilir, əldə edilən nəticələrin keyfiyyəti qiymətləndirilir və növbəti iterasiyanın işi planlaşdırılır.

Hər təkrarlama zamanı aşağıdakılar qiymətləndirilir:

• layihənin şərtlərini və dəyərini aşma riski;
• başqa bir təkrarlama etmək ehtiyacı;
• sistemə olan tələbləri başa düşməyin tamlığı və dəqiqliyi;
• layihənin dayandırılmasının mümkünlüyü.

Spiral modelin təkamül modelinə (IID modeli) alternativ deyil, xüsusi olaraq hazırlanmış bir model olduğunu başa düşmək vacibdir. Təəssüf ki, spiral model tez -tez ya səhvən ümumiyyətlə təkamül modelinin sinonimi kimi istifadə olunur, ya da (daha az səhvən) IID ilə birlikdə tamamilə müstəqil bir model olaraq adlandırılır.

Spiral modelin fərqli bir xüsusiyyəti, həyat dövrünün təşkilinə və mərhələlərinə təsir edən risklərə xüsusi diqqət yetirilməsidir. Boehm ən çox yayılmış (prioritet) 10 riski sadalayır:

1. Mütəxəssis çatışmazlığı.
2. Qeyri -real vaxt qrafiki və büdcə.
3. Uyğun olmayan funksiyaların tətbiqi.
4. Səhv istifadəçi interfeysi dizaynı.
5. Mükəmməllik, lazımsız optimallaşdırma və detallar.
6. Ardıcıl dəyişiklik axını.
7. Sistem mühitini təyin edən və ya inteqrasiyada iştirak edən xarici komponentlər haqqında məlumatın olmaması.
8. Xarici (layihə ilə əlaqədar) qaynaqlar tərəfindən görülən işlərdə çatışmazlıqlar.
9. Yaranan sistemin qeyri -kafi performansı.
10. Fərqli sahələrdə mütəxəssislərin ixtisasındakı boşluq.

Mövcud spiral model aşağıdakı ümumi nəzarət nöqtələrini təyin edir:

1. Əməliyyat Konsepsiyası (COO) - sistemin konsepsiyası (istifadəsi);
2. Həyat dövrünün məqsədləri (LCO) - həyat dövrünün məqsədləri və məzmunu;
3. Life Cycle Architecture (LCA) - həyat dövrü memarlığı; burada hədəf proqram sisteminin konseptual arxitekturasının hazırlığından danışmaq olar;
4. İlkin Əməliyyat Qabiliyyəti (IOC) - yaradılan məhsulun sınaq üçün yararlı ilk versiyası;
5. Final Operational Capability (FOC), real əməliyyat üçün yerləşdirilən (quraşdırılmış və konfiqurasiya edilmiş) hazır bir məhsuldur.

Proqram təminatı inkişaf etdirmə metodologiyası

• Microsoft Solutions Framework (MSF). 4 mərhələ daxildir: analiz, dizayn, inkişaf, sabitləşmə, obyekt yönümlü modelləşdirmənin istifadəsini əhatə edir.
• Həddindən artıq proqramlaşdırma (ing. Ekstremal Proqramlaşdırma, XP). Metodologiya komanda işinə əsaslanır. effektiv ünsiyyətİS -in inkişafı üçün bütün layihə zamanı müştəri ilə podratçı arasında. İnkişaf ardıcıl olaraq təmizlənmiş prototiplərdən istifadə etməklə həyata keçirilir.
• ESPD - bir sıra dövlət standartları Rusiya Federasiyası proqramların və proqram sənədlərinin hazırlanması, tərtib edilməsi və dövriyyəsi üçün bir -biri ilə əlaqəli qaydalar müəyyən edən.

Ədəbiyyat

• Bratishchenko V.V.İnformasiya sistemlərinin dizaynı. - İrkutsk: BSUEP Nəşriyyatı, 2004 .-- 84 s.
• Vendrov A.M.İqtisadi informasiya sistemləri üçün proqram dizaynı. - M.: Maliyyə və statistika, 2000.
• Grekul V.I., Denischenko G.N., Korovkina N.L.İnformasiya sistemlərinin dizaynı. - M.: İnternet Universiteti informasiya texnologiyaları- INTUIT.ru, 2005.
• Mishenin A.I.İqtisadi informasiya sistemləri nəzəriyyəsi. - M.: Maliyyə və statistika, 2000 .-- 240 s.

Qeydlər (redaktə)

Vikimedia Vəqfi. 2010.

Proqram təminatının həyat dövrü - proqram məhsulunun yaradılmasına ehtiyac barədə qərar verildiyi andan başlayaraq xidmətdən tamamilə çıxdığı anda bitən bir müddət.

Həyat dövrü proqram prosesləri:

Əsas,

Köməkçi,

Təşkilati.

Əsas:

1. Satınalma - proqram təminatını alanın müştərinin hərəkətləri və vəzifələri;

2. Çatdırılma - müştəriyə proqram məhsulu və ya xidmət təqdim edən tədarükçünün hərəkətləri və vəzifələri;

3. İnkişaf - geliştirici tərəfindən yerinə yetirilən hərəkətlər və vəzifələr: proqram təminatının hazırlanması, dizayn və əməliyyat sənədləri, test və təlim materiallarının hazırlanması;

4. Əməliyyat - sistemi idarə edən təşkilat operatorunun hərəkətləri və vəzifələri;

5. Baxım - səhvləri düzəltmək, performansı yaxşılaşdırmaq və ya dəyişdirilmiş iş şəraitinə və ya tələblərinə uyğunlaşmaq üçün proqramda dəyişikliklər etmək.

Köməkçi:

1. Sənədləşmə - proqram təminatının ömrü boyu yaradılan məlumatların rəsmiləşdirilmiş təsviri;

2. Konfiqurasiya idarəçiliyi - proqram komponentlərinin vəziyyətini müəyyən etmək, dəyişikliklərini idarə etmək üçün proqram ömrü boyu inzibati və texniki prosedurların tətbiqi;

3. Keyfiyyət təminatı - proqram təminatının və onun həyat dövrü proseslərinin müəyyən edilmiş tələblərə və təsdiq edilmiş planlara uyğun olmasını təmin etmək;

4. Doğrulama - proqram məhsullarının əvvəlki hərəkətlərə görə tələblərə və ya şərtlərə tam cavab verdiyini müəyyən etmək;

5. Attestasiya - verilən tələblərin və yaradılmış sistemin onların konkret funksional məqsədinə uyğunluğunun tamlığının müəyyən edilməsi;

6. Birgə qiymətləndirmə - layihə üzərində işin vəziyyətinin qiymətləndirilməsi: resursların, işçilərin, avadanlıqların, alətlərin planlaşdırılması və idarə olunmasına nəzarət;

7. Audit - müqavilənin tələblərinə, planlarına və şərtlərinə uyğunluğun müəyyən edilməsi;

8. Problemlərin həlli - Mənşəyindən və mənbəyindən asılı olmayaraq, inkişaf, istismar, texniki xidmət və ya digər proseslər zamanı aşkarlanan problemlərin təhlili və həlli.

Təşkilati:

1. İdarəetmə - proseslərinə nəzarət edən hər hansı bir tərəfin həyata keçirə biləcəyi hərəkətlər və vəzifələr;

2. Altyapının yaradılması - texnologiyanın, standartların və alətlərin seçilməsi və saxlanılması, proqram təminatının hazırlanması, istismarı və ya saxlanılması üçün istifadə olunan aparat və proqram təminatının seçilməsi və quraşdırılması;

3. Təkmilləşdirmə - həyat dövrü proseslərinin qiymətləndirilməsi, ölçülməsi, nəzarət edilməsi və təkmilləşdirilməsi;

4. Təlim - kadrların ilkin təhsili və sonrakı davamlı peşəkar inkişafı.

2002 -ci ildə sistemlərin həyat dövrü prosesləri üçün standart (ISO / IEC 15288 Sistem həyat dövrü prosesləri) nəşr olundu. Standartın hazırlanmasına müxtəlif sahələrdən olan mütəxəssislər cəlb edilmişdir: sistem mühəndisliyi, proqramlaşdırma, keyfiyyət idarəçiliyi, insan resursları, təhlükəsizlik və s. Hökumət, ticarət, hərbi və akademik təşkilatlarda sistemlərin yaradılmasının praktiki təcrübəsi nəzərə alınmışdır. Standart geniş bir sistem sinifinə aiddir, lakin əsas məqsədi kompüterləşdirilmiş sistemlərin yaradılmasına dəstək verməkdir.

ISO / IEC 15288 standartına uyğun olaraq, həyat dövrü quruluşuna aşağıdakı proses qrupları daxil edilməlidir:

1. Müqavilə prosesləri:

Satınalma (daxili və ya xarici satıcı həlləri);

Çatdırılma (daxili həllər və ya xarici təchizatçıların həlləri);

2. Müəssisə prosesləri:

Müəssisənin ətraf mühitin idarə edilməsi;

İnvestisiyaların idarə edilməsi;

IS həyat dövrü idarəetmə;

Resursların idarə edilməsi;

Keyfiyyətə nəzarət;

3. Dizayn prosesləri:

Layihənin planlaşdırılması;

Layihənin qiymətləndirilməsi;

Layihəyə nəzarət;

Risklərin idarə edilməsi;

Konfiqurasiya idarəetmə;

Məlumat axınının idarə edilməsi;

Qərarlar qəbul etmək.

4. Texniki Proseslər:

Tələblərin tərifi;

Tələblərin təhlili;

Memarlığın inkişafı;

İcra;

İnteqrasiya;

Doğrulama;

Keçid;

Sertifikatlaşdırma;

İstismar;

Müşayiət;

Sərəncam.

5. Xüsusi proseslər:

Məqsəd və hədəflərə əsaslanaraq əlaqələrin təyin edilməsi və qurulması.

IP (ISO / IEC 15288) üçün proqram ömrü dövrünün əsas proseslərinin yaradılması

Sistemlərin yaradılması mərhələləri (ISO / IEC 15288)

SRS: www.mastertz.ru saytında "Növbə" layihəsi üçün texniki tapşırıqlar yaradın

Həyat dövrü proqram modelləri:

1. kaskad,

2. spiral,

3. iterativ.

Kaskad modeli həyat dövrü ("şəlalə modeli", ing. şəlalə modeli) 1970 -ci ildə Winston Royce tərəfindən təklif edilmişdir. Layihənin bütün mərhələlərinin ciddi şəkildə müəyyən edilmiş ardıcıllıqla yerinə yetirilməsini təmin edir. Növbəti mərhələyə keçid, işin əvvəlki mərhələdə tamamlanması deməkdir.

Tələblərin formalaşdırılması mərhələsində müəyyən edilmiş tələblər ciddi şəkildə texniki tapşırıq şəklində sənədləşdirilir və layihənin hazırlanmasının bütün müddəti ərzində qeyd olunur.

Hər bir mərhələ, inkişafın başqa bir inkişaf qrupu tərəfindən davam etdirilməsi üçün kifayət qədər sənədlərin tam dəsti ilə başa çatır.

Spiral model(ing. spiral model) 1980-ci illərin ortalarında Barry Boehm tərəfindən hazırlanmışdır. Williams Edward Deming-in klassik PDCA (plan-do-check-act) dövrünə əsaslanır. Bu modeli istifadə edərkən, proqramlaşdırma prototipləşdirmə yolu ilə bir neçə dəfə təkrarlanır (spiral döngələr).

Prototip, fərdi funksiyaları və xarici interfeysləri həyata keçirən aktiv bir proqram komponentidir.

Hər bir təkrar proqramın bir hissəsinin və ya bir versiyasının yaradılmasına uyğundur, bunun üzərində layihənin məqsədləri və xüsusiyyətləri göstərilir, əldə edilən nəticələrin keyfiyyəti qiymətləndirilir və növbəti iterasiyanın işi planlaşdırılır.

Pirinç. 21. Həyat dövrü proqramının spiral modeli

Hər təkrarlama zamanı aşağıdakılar qiymətləndirilir:

1. Layihənin şərtlərini və dəyərini aşma riski;

2. Daha bir təkrarlama yerinə yetirmək ehtiyacı;

3. Sistemə olan tələbləri başa düşməyin tamlığı və dəqiqliyi;

4. Layihəyə xitam verilməsinin məqsədəuyğunluğu.

Spiral modelin tətbiqinə bir nümunə RAD -dir.

RAD -in əsas prinsipləri:

1. Alətlər dəsti inkişaf müddətinin minimuma endirilməsinə yönəldilməlidir;

2. Müştəri tələblərini aydınlaşdırmaq üçün prototipin yaradılması;

3. Siklik inkişaf: məhsulun hər yeni versiyası müştəri tərəfindən əvvəlki versiyanın nəticəsinin qiymətləndirilməsinə əsaslanır;

4. Hazır modulları köçürmək və funksionallıq əlavə etməklə versiya hazırlama müddətinin minimuma endirilməsi yeni versiya;

5. İnkişaf qrupu sıx əməkdaşlıq etməlidir, hər bir iştirakçı bir neçə vəzifəni yerinə yetirməyə hazır olmalıdır;

6. Layihə rəhbərliyi inkişaf dövrü müddətlərini minimuma endirməlidir.

İterativ model: kaskad və spiral modellərin təbii inkişafı onların yaxınlaşmasına və bu modellərin rasional birləşməsini təmsil edən müasir bir iterativ yanaşmanın yaranmasına səbəb oldu.

Pirinç. 22. Proqram təminatı həyat dövrünün təkrarlanan modeli

Proqram təminatının həyat dövrü. Mərhələlər və mərhələlər

Bir İS -in həyat dövrü, sistemin yaradılması və istifadəsi prosesində meydana gələn bir sıra hadisələrdir.

Səhnə- müəyyən bir zaman çərçivəsi ilə məhdudlaşan və müəyyən bir məhsulun (modellər, proqram komponentləri, sənədlər) buraxılması ilə bitən proqram hazırlama prosesinin bu mərhələ üçün qoyulan tələblərlə müəyyən edilmiş bir hissəsi.

Həyat dövrü ənənəvi olaraq bir sıra ardıcıl mərhələlər (və ya mərhələlər, mərhələlər) kimi modelləşdirilir. Hal -hazırda, bir proqram sisteminin həyat dövrünün mərhələlərə bölünməsi ümumiyyətlə qəbul edilməmişdir. Bəzən bir mərhələ ayrı bir maddə kimi seçilir, bəzən daha böyük bir səhnənin ayrılmaz hissəsi olaraq daxil edilir. Bu və ya digər mərhələdə edilən hərəkətlər fərqli ola bilər. Bu mərhələlərin adlarında vahidlik yoxdur.

Ənənəvi olaraq, proqramın həyat dövrünün aşağıdakı əsas mərhələləri fərqlənir:

Tələblərin təhlili,

Dizayn,

Kodlaşdırma (proqramlaşdırma),

Test və ayıklama,

Əməliyyat və texniki xidmət.

Proqramın həyat dövrü. Kaskad modeli

kaskad modeli (70-80 il) ≈ əvvəlki mərhələdəki işlər tamamlandıqdan sonra növbəti mərhələyə keçməyi nəzərdə tutur,

Şəlalə modelinin əsas uğuru mərhələlərin tamamlanmasıdır. Bu, xərcləri və müddətləri planlaşdırmağa imkan verir. Bundan əlavə, tam və ardıcıl olan layihə sənədləri formalaşdırılır.

Şəlalə modeli kiçiklərə tətbiq olunur proqram layihələri, açıq şəkildə ifadə edilmiş və dəyişdirilməyən tələblərlə. Həqiqi proses istənilən mərhələdə uğursuzluqları aşkar edə bilər ki, bu da əvvəlki mərhələlərdən birinə qayıdır. Bu cür proqram istehsalının modeli kaskad-qaytarılmadır

Proqram təminatının həyat dövrü. Aralıq nəzarət ilə addım-addım model

ara nəzarət (80-85 il) ilə addım-addım model ≈ mərhələlər arasında geribildirim döngələri olan proqram təminatının təkrarlanan modeli. Bu modelin üstünlüyü, addımlar arası tənzimləmələrin şəlalə modelindən daha az əmək tələb etməsidir; lakin, hər mərhələnin ömrü bütün inkişaf dövrü boyunca uzadılır,

Problemlərin həllinin əsas mərhələləri

Proqramlaşdırmanın məqsədi məlumatların işlənməsi proseslərini (bundan sonra sadə proseslər adlandırılacaq) təsvir etməkdir.

Məlumat (məlumatlar), müəyyən bir prosesdə ötürülməsi və işlənməsi üçün uyğun olan, fakt və fikirlərin rəsmiləşdirilmiş formada təqdim edilməsidir və məlumat (informasiya) məlumatların təqdim edildiyi zaman verilən mənadır.

Məlumatların emalı, məlumatlar üzərində sistemli bir hərəkət ardıcıllığının yerinə yetirilməsidir. Məlumatlar məlumat daşıyıcılarında təqdim olunur və saxlanılır.

Hər hansı bir məlumat emalında istifadə olunan məlumat daşıyıcıları toplusuna məlumat mühiti deyilir.

İnformasiya mühitində hər an mövcud olan məlumatlar toplusu informasiya mühitinin vəziyyətidir.

Proses müəyyən bir informasiya mühitinin ardıcıl vəziyyətlərinin ardıcıllığı olaraq təyin edilə bilər.

Bir prosesi təsvir etmək, informasiya mühitinin vəziyyətlərinin ardıcıllığını təyin etmək deməkdir. Verilən bir təsvirə uyğun olaraq hər hansı bir kompüterdə lazımi prosesin avtomatik olaraq meydana gəlməsi üçün bu təsvir rəsmiləşdirilməlidir.

Proqram təminatının keyfiyyət meyarları

Ticarət məhsulu (məhsul, xidmət) müştəri tələblərinə cavab verməlidir.

Keyfiyyət müştəri məmnuniyyətinin dərəcəsini göstərən bir məhsulun (məhsulun, xidmətin) obyektiv xüsusiyyətidir

Keyfiyyət xüsusiyyətləri:

› Əməliyyat qabiliyyəti- sistem işləyir və lazımi funksiyaları həyata keçirir.

› Etibarlılıq- sistem uğursuz və uğursuz işləyir.

› Bərpa oluna bilər.

› Səmərəlilik- sistem öz funksiyalarını ən yaxşı şəkildə həyata keçirir.

› İqtisadi səmərəlilik- maksimum qazanc əldə edən son məhsulun minimum dəyəri.

Keyfiyyət xüsusiyyətləri:

› İnsan faktorunu nəzərə alaraq- istifadə rahatlığı, PP ilə işləməyi öyrənmə sürəti, baxımın asanlığı, dəyişikliklər edilməsi.

› Taşınabilirlik(taşınabilirlik) - kodun başqa bir platforma və ya sistemə daşınması.

› Funksional tamlıq- Bəlkə də xarici funksiyaların ən tam şəkildə həyata keçirilməsi.

› Hesablama dəqiqliyi

Alqoritm xüsusiyyətləri.

Effektivlik sonlu sayda əməliyyatlar etdikdən sonra nəticə əldə etmək imkanı deməkdir.

Əminlik istifadəçi və tətbiq olunan texniki vasitələrdən asılı olmayaraq əldə edilən nəticələrin üst -üstə düşməsindən ibarətdir.

Kütləvi xarakter alqoritmi, ilkin məlumatların spesifik dəyərləri ilə fərqlənən eyni tipli bir problem sinifinə tətbiq etmək imkanından ibarətdir.

Ayrılıq - alqoritm tərəfindən təyin edilmiş hesablama prosesini ayrı -ayrı mərhələlərə bölmək imkanı, proqramın müəyyən bir quruluşa malik bölmələrini seçmək imkanı.

Alqoritmləri təsvir etmək üsulları

Alqoritmləri təsvir etməyin (təqdim etmənin) aşağıdakı yolları var:

1. şifahi təsvir;

2. riyazi düsturlardan istifadə edərək alqoritmin təsviri;

3. alqoritmin blok diaqram şəklində qrafik təsviri;

4. pseudocode istifadə edərək alqoritmin təsviri;

5. Şifahi, qrafik və digər üsullardan istifadə edərək alqoritmi göstərməyin birləşmiş üsulu .

6. Petri torlarından istifadə etməklə.

Şifahi təsvir alqoritm alqoritmin quruluşunun təbii dildə təsviridir. Məsələn, məişət texnikası ümumiyyətlə bir təlimatla müşayiət olunur, yəni. bu cihazın istifadə ediləcəyi alqoritmin şifahi təsviri.

Qrafik Təsviraxın cədvəli şəklində alqoritmƏlaqə xətləri ilə həndəsi formalar istifadə edərək alqoritm quruluşunun təsviridir.

Bir axın sxemi, əməliyyatları təmsil etmək üçün xüsusi simvollardan istifadə edən bir problemi həll etmək üçün bir metodun qrafik təsviridir.

Alqoritmin sxemini təşkil edən simvollar GOST 19.701-90 ilə müəyyən edilir. Bu GOST alqoritmlərin dizaynı üçün beynəlxalq standarta uyğundur, buna görə də GOST 19.701-90 uyğun olaraq tərtib edilmiş alqoritmlərin blok sxemləri müxtəlif ölkələrdə birmənalı şəkildə başa düşülür.

Psevdokod- alqoritmin strukturunun təbii, lakin qismən rəsmiləşdirilmiş bir dildə təsviri. Pseudocode bəzi rəsmi quruluşlardan və ümumi riyazi qeydlərdən istifadə edir. Pseudocode yazmaq üçün ciddi sintaksis qaydaları yoxdur.

Ən sadə nümunəyə baxaq. Monitör ekranında iki ədədin ən böyük dəyərinin göstərilməsi alqoritmini izah etmək lazım gəlsin.

Şəkil 1 - Alqoritmin blok diaqram şəklində təsvirinə bir nümunə

Pseudocode -da eyni alqoritmin təsviri:

2. Nömrələrin daxil edilməsi: Z, X

3. Z> X olarsa Nəticə Z

4. Əks halda, X çıxışı

Alqoritmləri göstərmək üçün sadalanan metodların hər birinin həm üstünlükləri, həm də mənfi cəhətləri var. Məsələn, şifahi metod çox sözlü və aydın olmaması ilə diqqət çəkir, lakin ayrı -ayrı əməliyyatları daha yaxşı təsvir etməyə imkan verir. Qrafik metod daha çox təsvir edir, lakin bəzi əməliyyatları şifahi formada təsvir etmək çox vaxt lazım olur. Buna görə də, kompleks alqoritmlər hazırlayarkən birləşmiş metoddan istifadə etmək daha yaxşıdır.

Alqoritm növləri

xətti;

dallanma;

dövri

· Xətti Alqoritm- bir -birinin ardınca yerinə yetirilən əmrlər (təlimatlar).

· Çəngəl alqoritmi- kompüterin iki mümkün addımdan birinə keçidi təmin etdiyi yoxlanılması nəticəsində ən azı bir şərt olan bir alqoritm.

· Siklik alqoritm- eyni hərəkətin (eyni əməliyyatlar) yeni ilkin məlumatlar üzərində çox dəfə təkrarlanmasını təmin edən alqoritm. Hesablama metodlarının çoxu, seçimlərin sayılması tsiklik alqoritmlərə endirilir. Proqram döngəsi - müəyyən bir şərt yerinə yetirilənə qədər dəfələrlə (yeni ilkin məlumatlar üçün) icra oluna bilən əmrlər ardıcıllığı (seriya, döngə gövdəsi).

C. Məlumat növləri.

Məlumat növü, müəyyən bir növ dəyişənin ala biləcəyi dəyərlər aralığının təsviridir. Hər bir məlumat növü xarakterizə olunur:
1. işğal olunmuş baytların sayı (ölçü)
2. bu tip bir dəyişənin ala biləcəyi dəyərlər aralığı.

Bütün məlumat növləri bölünə bilər aşağıdakı növlər:
1. sadə (skalar) və kompleks (vektor) növlər;
2. baza (sistem) və istifadəçi (istifadəçi tərəfindən müəyyən edilir).
C dilində əsas tip sistemi dörd məlumat növü ilə formalaşır:
1. xarakter,
2. bütöv,
3. real tək dəqiqlik,
4. ikiqat dəqiqlik.

C proqramının quruluşu.

1. C ++ dilinin operatorları

Operatorlar proqramın icrası prosesinə nəzarət edirlər. C ++ operatorları, strukturlaşdırılmış proqramlaşdırmanın bütün idarəetmə quruluşlarını ehtiva edir.
Mürəkkəb ifadə, buruq mötərizələrlə ayrılır. Bütün digər operatorlar nöqtəli vergüllə bitir.
Boş operator -;
Boş operator yalnız nöqtəli vergüllə işlədilən operatordur. Sintaksisin bir bəyanat tələb etdiyi bir proqramda hər yerdə görünə bilər. Boş bir ifadənin yerinə yetirilməsi proqramın vəziyyətini dəyişdirmir.
Mürəkkəb operator - [...]
Mürəkkəb ifadənin hərəkəti, hər hansı bir ifadənin nəzarəti proqramın başqa bir yerinə açıq şəkildə köçürdüyü hallar istisna olmaqla, tərkibindəki ifadələrin ardıcıl icrasından ibarətdir.
İstisna İdarəetmə Operatoru

cəhd et (<операторы> }
tutmaq (<объявление исключения>) { <операторы> }
tutmaq (<объявление исключения>) { <операторы> }
...
tutmaq (<объявление исключения>) { <операторы> }

Şərti operator

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

Operator dəyişdirin

keçid (<выражение>)
(halda<константное выражение 1>: <операторы 1>
dava<константное выражение 2>: <операторы 2>
...
dava<константное выражение N>: <операторы N>
}
Keçid operatoru, proqramın yerinə yetirilməsinin bir neçə alternativ yolundan birini seçmək üçün nəzərdə tutulmuşdur. Keçid operatorunun qiymətləndirilməsi ifadənin qiymətləndirilməsi ilə başlayır, bundan sonra nəzarət ifadənin qiymətləndirilmiş dəyərinə bərabər olan sabit ifadə ilə işarələnmiş operatora verilir. Keçid operatorundan çıxış kəsmə operatoru tərəfindən həyata keçirilir. İfadənin dəyəri heç bir sabit ifadəyə bərabər deyilsə, nəzarət, əgər varsa, standart açar sözlə işarələnmiş operatora verilir.
Ön şərtlə döngə operatoru

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

Şərtli döngə operatoru

etmək<оператор>isə<выражение>;
C ++ dilində bu operator, bir şərtlə bir döngənin klassik tətbiqindən fərqlənir ki, ifadə doğrudursa, döngə çıxır, döngə davam edir.
Addım Dövr Operatoru

üçün ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
For ifadəsinin gövdəsi, şərti ifadə yanlış olana qədər yerinə yetirilir (0 -a bərabərdir). Başlanğıc ifadə və artım ifadəsi ümumiyyətlə loop parametrlərini və digər dəyərləri işə salmaq və dəyişdirmək üçün istifadə olunur. İlkin ifadə şərti ifadənin ilk sınağından əvvəl bir dəfə, artım ifadəsi isə hər bir ifadənin icrasından sonra qiymətləndirilir. Üç döngə başlıq ifadəsindən hər hansı biri, hətta üçü də buraxıla bilər (nöqtəli vergül qoymağı unutmayın). Şərti ifadə buraxılırsa, doğru hesab olunur və döngə sonsuz olur.
C ++ dilində addım -addım döngə operatoru çevik və rahat bir quruluşdur, buna görə də halbuki halbuki halbuki C ++ dilində son dərəcə nadir hallarda istifadə olunur. əksər hallarda for ifadəsini istifadə etmək daha rahatdır.
Break operatoru

fasilə;
Break ifadəsi while, do, for və switch ifadələrinin icrasını kəsir. Yalnız bu ifadələrin tərkibində ola bilər. Nəzarət kəsiləndən sonra proqram operatoruna verilir. If, do, for, switch ifadələrinin içərisində bir break ifadəsi yazılırsa, dərhal onu əhatə edən ifadəni bitirir.
Davam edən operator

davam et;
Davam ifadəsi, idarəetmə müddət döngələri üçün while, do sonrakı iterasiyaya keçir. Yalnız bu ifadələrin tərkibində ola bilər. Do və while ifadələrində növbəti iterasiya şərti ifadəni qiymətləndirməklə başlayır. For ifadəsində, növbəti təkrarlama artım ifadəsini qiymətləndirməklə başlayır və sonra şərti ifadəni qiymətləndirir.
Qaytarma operatoru

qayıt [<выражение>];
Qaytarma ifadəsi, içərisində olan funksiyanın icrasını bitirir və nəzarəti çağırış funksiyasına qaytarır. Nəzarət çağırış funksiyasının nöqtəsinə keçir

Əgər (boolean ifadə)

operator;

Əgər (boolean ifadə)

operator_1;

operator_2;

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

Məntiqi ifadənin dəyəri doğrudursa, expression_1 qiymətləndirilir, əks halda express_2 qiymətləndirilir.

keçid (tam ədəd ifadəsi)

hal dəyəri_1:

statement_sequence_1;

işin dəyəri_2:

statement_sequence_2;

hal dəyəri_n:

bəyanat_ nəticə_n;

defolt:

bəyanat_ nəticəsi_n + 1;

Filial defolt təsvir etmək olmur. Yüksək səviyyəli ifadələrdən heç biri razı deyilsə icra olunur.

Döngə operatoru.

Turbo C, döngələri proqramlaşdırmağa imkan verən aşağıdakı quruluşlara malikdir: bir müddət, bir müddət etmək və üçün ... Onların quruluşunu belə təsvir etmək olar:

Yuxarıdakı vəziyyət yoxlaması ilə döngə:

Seçim operatoru

Proqramda yerinə yetirilməsi lazım olan hərəkətlər hansısa dəyişənin dəyərindən asılıdırsa, Select ifadəsini istifadə edə bilərsiniz. Eyni zamanda, C ++ dilində yalnız dəyişkənlər seçmə ifadəsində istifadə edilə bilər. Ümumiyyətlə, seçim operatorunun qeydləri belə görünür:

keçid (dəyişən)
{
dava dəyəri 1:
hərəkətlər1
fasilə;

halda dəyəri 2:
hərəkət 2
fasilə;
...

defolt:
standart hərəkətlər
}

Açar söz hər filialın sonuna fasilə əlavə edilməlidir. Seçim əməliyyatının icrasını dayandırır. Bunu yazmasanız, seçimin bir qolundan hərəkətlər etdikdən sonra aşağıdakı qollardan hərəkətlərin icrası davam edəcək. Ancaq bəzən bu seçim xüsusiyyəti faydalıdır, məsələn, dəyişənin fərqli dəyərləri üçün eyni hərəkətləri etməlisiniz.

keçid (dəyişən)
{
dava dəyəri 1:
halda dəyəri 2:
hərəkətlər1
fasilə;

halda dəyəri 3:
hərəkət 2
fasilə;
...
}

Seçimdən istifadə nümunəsi:

int n, x;
...
keçid (n)
{
hal 0:
fasilə; // n 0 olarsa, heç bir hərəkət etmirik

hal 1:
hal 2:
hal 3:
x = 3 * n; // n 1, 2 və ya 3 olarsa, bəzi hərəkətlər edirik
fasilə;

hal 4:
x = n; // n 4 olarsa, başqa hərəkətlər edirik
fasilə;

defolt:
x = 0; // n -nin bütün digər dəyərləri üçün standart hərəkətləri yerinə yetirin
}

C. Döngü: parametrli bir döngə

Ümumi giriş forması

for (parametrlərin işə salınması; sonlanma vəziyyətinin yoxlanılması; parametrlərin düzəldilməsi) (

əməliyyat bloku;

for parametrik bir döngədir (müəyyən sayda təkrarlanan döngü). Belə bir dövrü təşkil etmək üçün üç əməliyyatı yerinə yetirmək lazımdır:

§ parametrlərin işə salınması- dövr parametrinə ilkin dəyərin təyin edilməsi;

§ bitmə vəziyyətinin yoxlanılması- parametr dəyərinin bəzi sərhəd dəyəri ilə müqayisə edilməsi;

§ parametr korreksiyası- döngə gövdəsinin hər keçidində parametrin dəyərinin dəyişdirilməsi.

Bu üç əməliyyat mötərizədə yazılır və nöqtəli vergüllə ayrılır (;). Tipik olaraq, loop parametri bir tam ədəd dəyişənidir.
Parametr yalnız bir dəfə işə salınır - for loop icra etməyə başlayanda. Döngə gövdəsinin hər mümkün icrasından əvvəl sonlandırma vəziyyəti yoxlanılır. İfadə yalan olduqda (sıfıra bərabər), döngə bitir. Parametr korreksiyası döngə gövdəsinin hər bir icrasının sonunda həyata keçirilir. Parametr həm artıra, həm də azalda bilər.

Misal

#daxil edin
int main () (

üçün (sayı = 1; sayı< 5; num++)

printf ("sayı =% d \ n", sayı);

Si. Ön şərtlə döngə

Ümumi giriş forması

while (ifadə) (

əməliyyat bloku;
}

Ifadə doğrudursa (sıfırdan başqa), buruq mötərizədə olan əməliyyatlar bloku yerinə yetirilir, sonra ifadə yenidən yoxlanılır. Əməliyyat blokunun yoxlanılması və yerinə yetirilməsindən ibarət olan hərəkətlər ardıcıllığı, ifadə yalan (sıfıra bərabər) olana qədər təkrarlanır. Bu halda döngədən çıxılır və döngə operatorundan sonrakı əməliyyat icra edilir.

Misal

int k = 5;
int i = 1;
int cəmi = 0;
isə (i<=k) {

Müvəqqəti bir döngə qurarkən, sınanmış ifadənin dəyərini dəyişən konstruksiyalar daxil etmək lazımdır ki, nəticədə yalan olsun (sıfıra bərabərdir). Əks təqdirdə, döngə sonsuz (məsələn, sonsuz döngə) icra ediləcək

əməliyyat bloku;
}

while əvvəlcədən şərt qoyulmuş bir döngədir, buna görə də, ilk yoxlama anında yoxlanmış vəziyyətin yalan olduğu ortaya çıxsa, döngənin gövdəsinin bir dəfə belə icra olunmaması mümkündür.

Si. Sonrakı şərt ilə döngə

Döngü sonrası şərtlə ... edərkən

Ümumi giriş forması

əməliyyat bloku;

) while (ifadə);

Sonrakı şərt ilə döngə

Do ... while döngəsi, qıvrım mötərizələrlə məhdudlaşan bloka daxil olan bütün əməliyyatlardan sonra ifadənin doğruluğunun yoxlanıldığı bir şərt olan bir döngədir. olduğu halda, postcondition ilə döngənin gövdəsi bir dəfə olsa da icra edilir.

Ən azı bir iterasyonun edilməli olduğu və ya bir vəziyyətin sınağına qatılan obyektlərin başlanğıc halqasının gövdəsinin içərisində meydana gəldiyi hallarda bir do ... while istifadə etmək daha yaxşıdır.

Misal... 0 -dan 10 -a qədər bir rəqəm daxil edin

#daxil edin
#daxil edin
int main () (

sistem ("chcp 1251");

printf ("Zəhmət olmasa 0 ilə 10 arasında bir rəqəm daxil edin:");

scanf ("% d", & num);

) isə ((sayı< 0) || (num > 10));

printf ("% d rəqəmini daxil etdiniz", num);

getchar (); getchar ();

Funksiyaların təyin edilməsi

Nümunə olaraq sum funksiyasından istifadə edərək bir funksiyanın tərifini nəzərdən keçirək.

C və C ++ da funksiyaların istifadə olunana qədər təyin edilməsinə ehtiyac yoxdur, lakin əvvəlcədən elan edilməlidir. Ancaq bütün bunlardan sonra da, sonunda, bu funksiya müəyyən edilməlidir. Bundan sonra funksiyanın prototipi və onun tərifi əlaqələndirilir və funksiyadan istifadə oluna bilər.

Funksiya əvvəlcədən elan edilmişsə, eyni qaytarılma dəyəri və məlumat növləri ilə təyin olunmalıdır, əks halda yeni, həddən artıq yüklənmiş funksiya yaradılacaqdır. Qeyd edək ki, funksiya parametrlərinin adlarının eyni olması lazım deyil.