Proqram alətinin həyat dövrünün əsas mərhələləri. Proqram təminatının həyat dövrü

Həyat dövrü proqram təminatı

Proqram təminatının dizayn metodologiyasının əsas anlayışlarından biri onun proqram təminatının həyat dövrü (proqram təminatının həyat dövrü) konsepsiyasıdır. Proqram təminatının həyat dövrü, onun yaradılması zərurəti barədə qərar qəbul edildiyi andan başlayan və onun istismardan tamamilə çıxarılması anında başa çatan davamlı bir prosesdir.

Proqram təminatının həyat dövrünü tənzimləyən əsas normativ sənəd ISO/IEC 12207 beynəlxalq standartıdır (ISO - Beynəlxalq Standartlaşdırma Təşkilatı - Beynəlxalq Standartlaşdırma Təşkilatı, IEC - Beynəlxalq Elektrotexniki Komissiyası - Beynəlxalq Elektrotexniki Komissiya). O, proqram təminatının hazırlanması zamanı tamamlanmalı olan prosesləri, fəaliyyətləri və tapşırıqları ehtiva edən həyat dövrü strukturunu müəyyən edir. Bu standartda Proqram təminatı (proqram məhsulu) dəst kimi müəyyən edilir kompüter proqramları, prosedurlar və mümkün əlaqəli sənədlər və məlumatlar. Proses bəzi girişi çıxışa çevirən bir-biri ilə əlaqəli hərəkətlər toplusu kimi müəyyən edilir. Hər bir proses müəyyən vəzifələr və onların həlli üsulları, digər proseslərdən alınan ilkin məlumatlar və nəticələrlə xarakterizə olunur.

ISO/IEC 12207 standartına uyğun olaraq proqram təminatının həyat dövrünün strukturu üç qrup prosesə əsaslanır:

proqram təminatının həyat dövrünün əsas prosesləri (alınma, təchizat, inkişaf, istismar, texniki xidmət);

əsas proseslərin həyata keçirilməsini təmin edən köməkçi proseslər (sənədləşdirmə, konfiqurasiyanın idarə edilməsi, keyfiyyətin təminatı, yoxlama, sertifikatlaşdırma, qiymətləndirmə, audit, problemlərin həlli);

təşkilati proseslər (layihənin idarə edilməsi, layihə infrastrukturunun yaradılması, həyat dövrünün özünün müəyyən edilməsi, qiymətləndirilməsi və təkmilləşdirilməsi, təlim).

Proqram təminatının həyat dövrü modelləri

Həyat dövrü modeli- icra ardıcıllığını və həyat dövrü ərzində yerinə yetirilən mərhələ və mərhələlərin əlaqəsini müəyyən edən struktur. Həyat dövrü modeli proqram təminatının xüsusiyyətlərindən və sonuncunun yaradıldığı və işlədiyi şəraitin xüsusiyyətlərindən asılıdır. Əsas həyat dövrü modelləri aşağıdakılardır.

1. Kaskad modeli(XX əsrin 70-ci illərinə qədər) əvvəlki mərhələ başa çatdıqdan sonra növbəti mərhələyə ardıcıl keçidi müəyyən edir.

Bu model informasiya inteqrasiyası və uyğunluğu, proqram təminatı, texniki və təşkilati interfeys tələb etməyən ayrı-ayrı əlaqəli olmayan tapşırıqların avtomatlaşdırılması ilə xarakterizə olunur.

Ləyaqət: fərdi problemlərin həllində inkişaf vaxtı və etibarlılıq baxımından yaxşı performans.

Qüsur: uzun dizayn dövrü ərzində sistem tələblərinin dəyişkənliyinə görə böyük və mürəkkəb layihələrə tətbiq edilmir.

2. İterativ model(XX əsrin 70-80-ci illəri) "aşağıdan yuxarı" dizayn texnologiyasına uyğundur. Növbəti mərhələnin icrasından sonra əvvəlki mərhələlərə iterativ qayıtmağa imkan verir;

Model fərdi tapşırıqlar üçün əldə edilmiş dizayn həllərinin ümumi sistem həllərinə ümumiləşdirilməsini nəzərdə tutur. Bu halda, əvvəllər tərtib edilmiş tələblərin yenidən nəzərdən keçirilməsinə ehtiyac var.

Ləyaqət: layihəyə tez düzəlişlər etmək imkanı.

Qüsur:çox sayda iterasiya ilə dizayn müddəti artır, dizayn həlləri və sənədlərdə uyğunsuzluqlar olur və yaradılmış proqram təminatının funksional və sistem arxitekturasında qarışıqlıq yaranır. Köhnəni yenidən dizayn etmək və ya yaratmaq ehtiyacı yeni sistem icra və ya istismar mərhələsindən dərhal sonra baş verə bilər.

3. Spiral model(20-ci əsrin 80-90-cı illəri) yuxarıdan aşağıya dizayn texnologiyasına uyğundur. Proqram təminatının genişləndirilməsinə imkan verən proqram prototipinin istifadəsini nəzərdə tutur. Sistemin dizaynı tələblərin dəqiqləşdirilməsindən proqram kodunun dəqiqləşdirilməsinə qədər olan yolu dövri olaraq təkrarlayır.

Sistem arxitekturasının layihələndirilməsi zamanı ilk növbədə funksional altsistemlərin tərkibi müəyyən edilir və ümumsistem məsələləri həll olunur (inteqrasiya edilmiş verilənlər bazasının təşkili, məlumatların toplanması, ötürülməsi və toplanması texnologiyası). Sonra fərdi tapşırıqlar tərtib edilir və onların həlli üçün texnologiya hazırlanır.

Proqramlaşdırma zamanı əvvəlcə əsas proqram modulları, sonra isə ayrı-ayrı funksiyaları yerinə yetirən modullar hazırlanır. Əvvəlcə modullar bir-biri ilə və verilənlər bazası ilə qarşılıqlı əlaqədə olur, sonra isə alqoritmlər həyata keçirilir.

Üstünlüklər:

1. iterasiyaların sayının və nəticədə düzəldilməli olan səhvlərin və uyğunsuzluqların sayının azaldılması;

2. dizayn vaxtının azaldılması;

3. layihə sənədlərinin yaradılmasının sadələşdirilməsi.

Qüsur: sistemli repozitoriya üçün yüksək keyfiyyət tələbləri (ümumi dizayn verilənlər bazası).

Spiral model əsasdır sürətli tətbiq inkişaf texnologiyaları və ya gələcək sistemin son istifadəçilərinin onun yaradılması prosesində fəal iştirakını nəzərdə tutan RAD-texnologiyası (sürətli proqram inkişafı). İnformasiya mühəndisliyinin əsas mərhələləri aşağıdakılardır:

· İnformasiya strategiyasının təhlili və planlaşdırılması.İstifadəçilər mütəxəssis tərtibatçılarla birlikdə problem sahəsinin müəyyən edilməsində iştirak edirlər.

· Dizayn. Tərtibatçıların rəhbərliyi altında istifadəçilər texniki dizaynda iştirak edirlər.

· Dizayn. Tərtibatçılar 4-cü nəsil dillərdən istifadə edərək proqram təminatının işlək versiyasını tərtib edirlər;

· İcra. Tərtibatçılar istifadəçiləri yeni proqram mühitində işləmək üçün öyrədirlər.

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

İS-nin həyat dövrü sistemlə onun yaradılması və istifadəsi prosesində baş verən hadisələr silsiləsidir.

Mərhələ- proqram təminatının yaradılması prosesinin müəyyən müddətlə məhdudlaşan və bu mərhələ üçün müəyyən edilmiş tələblərlə müəyyən edilmiş konkret məhsulun (modellər, proqram komponentləri, sənədlər) buraxılması ilə bitən 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 proqram təminatı sisteminin həyat dövrünün mərhələlərə ümumi qəbul olunmuş bölgüsü yoxdur. Bəzən bir mərhələ ayrıca bir element kimi seçilir, bəzən daha böyük bir mərhələnin tərkib hissəsi kimi daxil edilir. Bu və ya digər mərhələdə həyata keçirilə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 təminatının həyat dövrünün aşağıdakı əsas mərhələləri fərqləndirilir:

Tələblərin təhlili,

Dizayn,

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

Test və sazlama,

İstismar və texniki xidmət.

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

kaskad modeli (70-80-ci illər) ≈ əvvəlki mərhələdə iş başa çatdıqdan sonra növbəti mərhələyə keçidi nəzərdə tutur,

Şəlalə modelinin əsas nailiyyəti mərhələlərin tamlığıdır. Bu, xərcləri və vaxtı planlaşdırmağa imkan verir. Bundan əlavə, tamlığı və ardıcıllığı olan layihə sənədləri formalaşır.

Şəlalə modeli dəqiq müəyyən edilmiş və dəyişməz tələbləri olan kiçik proqram layihələri üçün tətbiq edilir. 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ə geri dönməyə səbəb olur. Belə proqram istehsalının modeli kaskad-qaytarmadır

Proqram təminatının həyat dövrü. Aralıq idarəetmə ilə mərhələli model

aralıq idarəetmə ilə addım-addım model (80-85) ≈ dövrlərlə təkrarlanan proqram inkişaf modeli rəy mərhələlər arasında. Bu modelin üstünlüyü ondan ibarətdir ki, mərhələlərarası tənzimləmələr şəlalə modelindən daha az əmək tələb edir; lakin, mərhələlərin hər birinin ömrü bütün inkişaf dövrü boyunca uzanır,

Problemin həllinin əsas mərhələləri

Proqramlaşdırmanın məqsədi verilənlərin emalı proseslərini (bundan sonra sadəcə proseslər adlandırılacaq) təsvir etməkdir.

Verilənlər (məlumatlar) fakt və ideyaların hansısa prosesdə ötürülməsi və işlənilməsi üçün uyğun formallaşdırılmış formada təqdim edilməsi, informasiya (informasiya) isə təqdim edildikdə verilənlərə verilən mənadır.

Məlumatların işlənməsi verilənlər üzərində sistematik hərəkətlər 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ın emalında istifadə olunan məlumat daşıyıcıları toplusuna informasiya daşıyıcısı (məlumat daşıyıcısı) deyilir.

İnformasiya mühitində istənilən vaxt olan verilənlər toplusu - vəziyyət informasiya mühiti.

Proses bəzi informasiya mühitinin ardıcıl hallarının ardıcıllığı kimi müəyyən edilə bilər.

Prosesi təsvir etmək informasiya mühitinin vəziyyətlərinin ardıcıllığını müəyyən etmək deməkdir. Tələb olunan prosesin verilmiş təsvirə uyğun olaraq bəzi kompüterlərdə avtomatik olaraq yaradılması üçün bu təsvir rəsmiləşdirilməlidir.

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

Kommersiya məhsulu (məhsul, xidmət) istehlakçının tələblərinə cavab verməlidir.

Keyfiyyət - obyektiv xüsusiyyət müştəri məmnuniyyətinin dərəcəsini göstərən mallar (məhsullar, xidmətlər).

Keyfiyyət xüsusiyyətləri:

› performans- sistem işləyir və tələb olunan funksiyaları həyata keçirir.

› Etibarlılıq– sistem nasazlıq və nasazlıq olmadan işləyir.

› Bərpa qabiliyyəti.

› Səmərəlilik- sistem öz funksiyalarını ən yaxşı şəkildə yerinə yetirir.

› İqtisadi səmərəlilik- maksimum mənfəətlə son məhsulun minimum dəyəri.

Keyfiyyət xüsusiyyətləri:

› Mühasibat uçotu insan amili - istifadə rahatlığı, proqram təminatı ilə işləməyi öyrənmək sürəti, texniki xidmətin asanlığı, dəyişikliklərin edilməsi.

› Daşıma qabiliyyəti(mobillik) - kodun başqa platforma və ya sistemə daşınması.

› Funksional tamlıq– bəlkə də xarici funksiyaların ən tam icrası.

› Hesablama dəqiqliyi

Alqoritm xassələri.

Səmərəlilik sonlu sayda əməliyyatları yerinə yetirdikdən sonra nəticə əldə etmək imkanını bildirir.

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

kütləvi xarakter alqoritmi ilkin məlumatların xüsusi dəyərlərində fərqlənən eyni tipli tapşırıqların bütün sinfinə tətbiq etmək imkanındadır.

diskretlik - alqoritmlə nəzərdə tutulmuş hesablamalar prosesini ayrı-ayrı mərhələlərə bölmək imkanı, proqramın müəyyən strukturlu bölmələrini işıqlandırmaq imkanı.

Alqoritmləri təsvir etmək yolları

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

1. şifahi təsvir;

2. riyazi düsturlardan istifadə etməklə alqoritmin təsviri;

3. blok-sxem şəklində alqoritmin qrafik təsviri;

4. psevdokoddan istifadə etməklə alqoritmin təsviri;

5. şifahi, qrafik və digər üsullardan istifadə etməklə alqoritmin təsvirinin birləşdirilmiş üsulu .

6. Petri şəbəkələrindən istifadə etməklə.

Şifahi təsvir alqoritm alqoritmin strukturunun təbii dildə təsviridir. Məsələn, cihazlar üçün məişət texnikası, bir qayda olaraq, bir təlimat kitabçası əlavə olunur, yəni. bu cihazın istifadə edilməli olduğu alqoritmin şifahi təsviri.

Qrafik təsvirbir sxem şəklində alqoritm istifadə alqoritmin strukturunun təsviridir həndəsi fiqurlar kommunikasiya xətləri ilə.

Alqoritmin blok diaqramı əməliyyatları göstərmək üçün xüsusi simvollardan istifadə edən problemin həlli metodunun qrafik təsviridir.

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

Psevdokod– təbii, lakin qismən rəsmiləşdirilmiş dildə alqoritmin strukturunun təsviri. Pseudocode bəzi formal konstruksiyalardan və ümumi riyazi simvolizmdən istifadə edir. Pseudocode yazmaq üçün ciddi sintaksis qaydaları yoxdur.

düşünün ən sadə misal. Monitor ekranında iki ədədin ən böyük qiymətinin göstərilməsi alqoritmini təsvir etmək lazım gəlsin.

Şəkil 1 - Blok diaqram şəklində alqoritmin təsvirinə nümunə

Pseudocode ilə eyni alqoritmin təsviri:

2. Nömrə daxiletmə: Z, X

3. Əgər Z > X olarsa, nəticə Z

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

Alqoritmləri təsvir etmək üçün yuxarıda göstərilən üsulları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 üsul genişdir və aydınlıqdan məhrumdur, lakin fərdi əməliyyatları daha yaxşı təsvir etməyə imkan verir. Qrafik üsul daha vizualdır, lakin bəzi əməliyyatları şifahi formada təsvir etmək çox vaxt lazım olur. Buna görə də, mürəkkəb alqoritmlər hazırlayarkən, birləşdirilmiş metoddan istifadə etmək daha yaxşıdır.

Alqoritmlərin növləri

xətti;

budaqlanma;

Dövri.

· Xətti alqoritm- ardıcıl olaraq bir-birinin ardınca yerinə yetirilən əmrlər (təlimatlar) toplusu.

· Budaqlanma alqoritmi- kompüterin iki mümkün addımdan birinə keçidi təmin etməsinin yoxlanılması nəticəsində ən azı bir şərti ehtiva edən alqoritm.

· Dövr alqoritmi- yeni ilkin məlumatlar üzərində eyni hərəkətin (eyni əməliyyatların) təkrar təkrarlanmasını nəzərdə tutan alqoritm. Hesablama üsullarının əksəriyyəti və variantların sadalanması dövri alqoritmlərə endirilir. Proqram dövrü - müəyyən şərt yerinə yetirilənə qədər təkrar (yeni ilkin məlumatlar üçün) yerinə yetirilə bilən əmrlər ardıcıllığı (seriya, dövrə 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 diapazonunun təsviridir. Hər bir məlumat növü aşağıdakılarla xarakterizə olunur:
1. işğal olunmuş baytların sayı (ölçüsü)
2. bu tip dəyişənin ala biləcəyi dəyərlər diapazonu.

Bütün məlumat növlərini aşağıdakı növlərə bölmək olar:
1. sadə (skalyar) və mürəkkəb (vektor) növlər;
2. əsas (sistem) və istifadəçi (istifadəçi tərəfindən müəyyən edilir).
C dilində əsas tip sistem dörd məlumat tipindən ibarətdir:
1. simvolik,
2. tam ədəd,
3. real tək dəqiqlik,
4. real ikiqat dəqiqlik.

C proqramının strukturu.

1. C++ dilinin operatorları

Operatorlar proqramın icrasına nəzarət edirlər. C++ dilinin operator dəsti strukturlaşdırılmış proqramlaşdırmanın bütün idarəetmə konstruksiyalarını ehtiva edir.
Mürəkkəb ifadə əyri mötərizələrlə ayrılır. Bütün digər ifadələr nöqtəli vergüllə bitir.
Boş operator - ;
Boş bəyanat yalnız nöqtəli vergüldən ibarət ifadədir. O, proqramın sintaksisinin ifadə tələb etdiyi hər yerdə görünə bilər. Boş bəyanatın icrası proqramın vəziyyətini dəyişmir.
Mürəkkəb operator - (...)
Mürəkkəb ifadənin hərəkəti, hər hansı bir ifadənin idarəetməni proqramın başqa yerinə açıq şəkildə köçürdüyü hallar istisna olmaqla, onun tərkibindəki ifadələri ardıcıl olaraq yerinə yetirməkdən ibarətdir.
İstisna ilə işləmə operatoru

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

Şərti operator

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

keçid operatoru

keçid(<выражение>)
(hal<константное выражение 1>: <операторы 1>
hal<константное выражение 2>: <операторы 2>
...
hal<константное выражение N>: <операторы N>
}
Switch bəyanatı proqramın icrasının bir neçə alternativ üsullarından birini seçmək üçün nəzərdə tutulmuşdur. Switch bəyanatının qiymətləndirilməsi ifadənin qiymətləndirilməsi ilə başlayır, bundan sonra idarəetmə ifadənin qiymətləndirilmiş dəyərinə bərabər sabit ifadə ilə işarələnmiş operatora ötürülür. Switch ifadəsi break ifadəsi ilə çıxarılır. Əgər ifadənin qiyməti hər hansı sabit ifadəyə bərabər deyilsə, onda idarəetmə varsa, defolt açar sözü ilə işarələnmiş operatora ötürülür.
İlkin şərtlə loop bəyanatı

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

Postşart ilə loop bəyanatı

et<оператор>isə<выражение>;
C++ dilində bu operator postşərti olan dövrənin klassik icrasından onunla fərqlənir ki, ifadə doğru olduqda, dövrə döngədən çıxmaqdan daha çox davam edir.
Addım döngə operatoru

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

fasilə;
Break operatoru while, do, for və switch ifadələrinin icrasını dayandırır. Bu, yalnız bu ifadələrin mətnində ola bilər. Nəzarət kəsiləndən sonra proqram bəyanatına ötürülür. Əgər fasilə ifadəsi nested while, do, for, switch ifadələrinin içərisində yazılıbsa, o, yalnız onu dərhal əhatə edən ifadəni dayandırır.
davam operatoru

davam etdirmək;
Davam operatoru while, do, for loop ifadələrində idarəetməni növbəti iterasiyaya ötürür. Bu, yalnız bu ifadələrin mətnində ola bilər. do və while ifadələrində növbəti təkrarlama şərti ifadənin qiymətləndirilməsi ilə başlayır. For ifadəsində növbəti iterasiya artım ifadəsinin qiymətləndirilməsi ilə başlayır və sonra şərti ifadə qiymətləndirilir.
geri qaytarma bəyanatı

qayıt [<выражение>];
Qaytarma ifadəsi onu ehtiva edən funksiyanın icrasını dayandırır və nəzarəti çağıran funksiyaya qaytarır. Nəzarət çağırış funksiyasının nöqtəsinə ötürülür

if (boolean ifadəsi)

operator;

if (boolean ifadəsi)

operator_1;

operator_2;

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

Məntiqi ifadənin qiyməti doğrudursa, ifadə_1 qiymətləndirilir, əks halda ifadə_2 qiymətləndirilir.

keçid (tam tip ifadə)

hal dəyəri_1:

operatorların_ardıcıllığı 1;

hal dəyəri_2:

operatorların_ardıcıllığı 2;

hal dəyəri_n:

operatorların_ardıcıllığı;

defolt:

operatorların_ardıcıllığı n+1;

filialı default təsvir edilə bilməz. Yuxarıdakı ifadələrdən heç biri təmin edilmədikdə icra edilir.

loop operatoru.

Turbo C proqramlaşdırma döngələri üçün aşağıdakı konstruksiyaları təmin edir: zamanı et Və üçün . Onların quruluşunu aşağıdakı kimi təsvir etmək olar:

Üst tərəfdə vəziyyət yoxlanışı ilə döngə:

Bəyanat seçin

Əgər proqramda yerinə yetiriləcək hərəkətlər hansısa dəyişənin qiymətindən asılıdırsa, seçim ifadəsindən istifadə etmək olar. Eyni zamanda, C++ dilində seçim ifadəsində dəyişənlər kimi yalnız ədədi dəyişənlər istifadə edilə bilər. Ümumiyyətlə, seçilmiş ifadənin qeydi belə görünür:

keçid (dəyişən)
{
hal dəyəri 1:
tədbirlər 1
fasilə;

hal dəyəri 2:
hərəkətlər2
fasilə;
...

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

Break açar sözü hər filialın sonuna əlavə edilməlidir. Seçmə əməliyyatının icrasını dayandırır. Əgər onu yazmasanız, bir seçim budağından hərəkətləri yerinə yetirdikdən sonra aşağıdakı budaqlardan hərəkətlərin icrası davam edəcək. Ancaq bəzən belə bir seçim xüsusiyyəti faydalıdır, məsələn, dəyişənin müxtəlif dəyərləri üçün eyni hərəkətləri yerinə yetirmək lazımdırsa.

keçid (dəyişən)
{
hal dəyəri 1:
hal dəyəri 2:
tədbirlər 1
fasilə;

hal dəyəri3:
hərəkətlər2
fasilə;
...
}

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

int n, x;
...
keçid(n)
{
hal 0:
fasilə; //əgər n 0-dırsa, heç nə etməyin

hal 1:
hal 2:
hal 3:
x = 3 * n; //əgər n 1, 2 və ya 3-ə bərabərdirsə, onda bəzi hərəkətləri yerinə yetirin
fasilə;

hal 4:
x=n; //əgər n 4-ə bərabərdirsə, onda digər hərəkətləri yerinə yetirin
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.Cycle: parametrli dövrə

Ümumi qeyd

üçün (parametrin işə salınması; son vəziyyətin yoxlanılması; parametrin düzəldilməsi) (

əməliyyatlar bloku;

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

§ parametrin işə salınması- dövr parametrinə ilkin qiymətin təyin edilməsi;

§ son vəziyyətin yoxlanılması- parametrin qiymətinin hansısa sərhəd dəyəri ilə müqayisəsi;

§ parametr korreksiyası- döngə gövdəsinin hər keçidi ilə parametrin qiymətinin dəyişdirilməsi.

Bu üç əməliyyat mötərizədə yazılır və nöqtəli vergül (;) ilə ayrılır. Bir qayda olaraq, loop parametri tam dəyişəndir.
Parametrin işə salınması yalnız bir dəfə həyata keçirilir - for döngüsü icra etməyə başlayanda. Döngə gövdəsinin hər mümkün yerinə yetirilməsindən əvvəl xitam şərti yoxlanılır. İfadə yalnış olduqda (sıfıra bərabərdir), dövrə başa çatır. Parametrlərin düzəldilməsi loop gövdəsinin hər icrasının sonunda həyata keçirilir. Parametr arta və ya azala bilər.

Misal

#daxildir
int main() (

üçün(num = 1; ədəd< 5; num++)

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

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

Ümumi qeyd

while(ifadə) (

əməliyyatlar bloku;
}

Əgər ifadə doğrudursa (sıfıra bərabər deyil), onda əyri mötərizələrə daxil edilmiş əməliyyatlar bloku yerinə yetirilir, sonra ifadə yenidən yoxlanılır. Əməliyyatlar blokunun yoxlanılması və yerinə yetirilməsindən ibarət olan hərəkətlər ardıcıllığı ifadə yalan olana qədər (sıfıra bərabər) təkrarlanır. Bu halda, dövrədən çıxarılır və dövrə bəyanatından sonrakı əməliyyat yerinə yetirilir.

Misal

intk=5;
int i=1;
insum=0;
isə (i<=k) {

while dövrəsini qurarkən yoxlanılan ifadənin qiymətini dəyişdirən konstruksiyalar daxil etmək lazımdır ki, sonda yalançı olsun (sıfıra bərabər). Əks halda, döngə qeyri-müəyyən müddətə yerinə yetiriləcək (sonsuz dövrə), məsələn

əməliyyatlar bloku;
}

while ilkin şərti olan dövrədir, ona görə də ilk yoxlama zamanı sınaqdan keçirilən şərt yalan olarsa, dövrənin gövdəsinin bir dəfə də olsa yerinə yetirilməməsi tamamilə mümkündür.

Si. Postşart ilə döngə

do...while postcondition ilə döngə

Ümumi qeyd

əməliyyatlar bloku;

) while(ifadə);

Postşart ilə döngə

do...while döngəsi postşərtli döngədir, burada əyri mötərizələrlə ayrılmış bloka daxil olan bütün əməliyyatlar yerinə yetirildikdən sonra ifadənin doğruluğu yoxlanılır.Dövr gövdəsi ifadə yalan olana qədər yerinə yetirilir ki, ki, postşərtli döngə gövdəsi bir dəfə olsa da icra olunur.

Ən azı bir iterasiya yerinə yetirilməli olduğu hallarda və ya vəziyyət testində iştirak edən obyektlərin inisializasiyası döngə gövdəsi daxilində baş verdikdə, do...while loopundan istifadə etmək daha yaxşıdır.

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

#daxildir
#daxildir
int main() (

sistem("chcp 1251");

printf("0-dan 10-a kimi rəqəm daxil edin: ");

scanf("%d", &num);

) while((nöm< 0) || (num > 10));

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

getchar(); getchar();

Funksiya tərifi

Cəm funksiyasının nümunəsindən istifadə edərək funksiyanın tərifini nəzərdən keçirin.

C və C++ dillərində funksiyalar istifadə olunana qədər müəyyən edilməməlidir, lakin onlar daha əvvəl elan edilməlidir. Amma bütün bunlardan sonra da sonda bu funksiya müəyyən edilməlidir. Bundan sonra funksiyanın prototipi və onun tərifi əlaqələndirilir və bu funksiyadan istifadə etmək olar.

Əgər funksiya əvvəl elan edilibsə, o, eyni qaytarma dəyəri və məlumat növləri ilə müəyyən edilməlidir, əks halda yeni, həddindən artıq yüklənmiş funksiya yaradılacaq. Qeyd edək ki, funksiya parametrlərinin adları eyni olmamalıdır.

Bu PS standartında (və ya proqram təminatı) kompüter proqramları, prosedurları və ola bilsin əlaqəli sənədlər və verilənlər toplusu kimi müəyyən edilir. Proses bəzi giriş məlumatlarını çıxış məlumatlarına çevirən bir-biri ilə əlaqəli hərəkətlər toplusu kimi müəyyən edilir (G. Myers bunu məlumatların tərcüməsi adlandırır). Hər bir proses müəyyən vəzifələr və onların həlli üsulları ilə xarakterizə olunur. Öz növbəsində hər bir proses hərəkətlər toplusuna, hər bir hərəkət isə tapşırıqlar toplusuna bölünür. Hər bir proses, hərəkət və ya tapşırıq lazım gəldikdə başqa bir proses tərəfindən başlanır və yerinə yetirilir və əvvəlcədən müəyyən edilmiş icra ardıcıllığı yoxdur (əlbəttə ki, giriş verilənləri əlaqələrini qoruyarkən).

Qeyd etmək lazımdır ki, Sovet İttifaqında, sonra isə Rusiyada proqram təminatının yaradılması (SW), əvvəlcə, keçən əsrin 70-ci illərində, GOST ESPD standartları ilə tənzimlənirdi ( vahid sistem proqram sənədləri - fərdi proqramçılar tərəfindən yaradılmış nisbətən sadə kiçik həcmli proqramlar sinfinə yönəlmiş bir sıra GOST 19.XXX). Hazırda bu standartlar konseptual və formaca köhnəlib, etibarlılıq müddəti başa çatıb və istifadəsi məqsədəuyğun deyil.

Yaradılış prosesləri avtomatlaşdırılmış sistemlər Proqram təminatı da daxil olan (AS) GOST 34.601-90 " ilə tənzimlənir. İnformasiya texnologiyaları. Avtomatlaşdırılmış sistemlər üçün standartlar toplusu. Yaradılma mərhələləri", GOST 34.602-89 "İnformasiya texnologiyası. Avtomatlaşdırılmış sistemlər üçün standartlar toplusu. Texniki tapşırıq avtomatlaşdırılmış sistemin yaradılması üçün” və QOST 34.603-92 “İnformasiya texnologiyası. Avtomatlaşdırılmış sistemlərin sınaqlarının növləri". Lakin bu standartların bir çox müddəaları köhnəlmişdir, digərləri isə PS-nin yaradılması üzrə ciddi layihələrdə istifadə olunmaq üçün kifayət qədər əks olunmamışdır. Ona görə də yerli inkişaflarda müasir beynəlxalq standartlardan istifadə etmək məqsədəuyğundur.

ISO / IEC 12207 standartına uyğun olaraq, proqram təminatının bütün həyat dövrü prosesləri üç qrupa bölünür (Şəkil 5.1).

düyü. 5.1.

Qruplarda beş əsas proses müəyyən edilir: satınalma, təchizat, inkişaf, istismar və texniki xidmət. Səkkiz alt proses əsas proseslərin icrasını təmin edir, yəni sənədlər, konfiqurasiyanın idarə edilməsi, keyfiyyət təminatı, yoxlama, qiymətləndirmə, birgə qiymətləndirmə, audit, problemin həlli. Dörd təşkilati proses idarəetmə, infrastrukturun qurulması, təkmilləşdirmə və öyrənməni təmin edir.

5.2. PS-nin həyat dövrünün əsas prosesləri

Alma prosesi proqram təminatını alan müştərinin fəaliyyət və tapşırıqlarından ibarətdir. Bu proses aşağıdakı fəaliyyətləri əhatə edir:

1. alışın başlanması;
2. ərizə təkliflərinin hazırlanması;
3. müqavilənin hazırlanması və tənzimlənməsi;
4. təchizatçının fəaliyyətinə nəzarət;
5. işin qəbulu və başa çatdırılması.

Qəbulun başlaması aşağıdakı vəzifələri əhatə edir:

1. müştəri tərəfindən sistemin əldə edilməsi, inkişafı və ya təkmilləşdirilməsi ilə bağlı ehtiyaclarının müəyyən edilməsi; proqram məhsulları və ya xidmətlər;
2. mövcud proqram təminatının alınması, inkişafı və ya təkmilləşdirilməsi ilə bağlı qərar qəbul etmək;
3. proqram məhsulunun alınması zamanı zəruri sənədlərin, zəmanətlərin, sertifikatların, lisenziyaların və dəstəyin mövcudluğunun yoxlanılması;
4. sistem tələbləri, müqavilənin növü, tərəflərin öhdəlikləri və s. daxil olmaqla əldə etmə planının hazırlanması və təsdiqi.

Təkliflərdə aşağıdakılar olmalıdır:

1. sistem tələbləri;
2. proqram məhsullarının siyahısı;
3. alış və müqavilə şərtləri;
4. texniki məhdudiyyətlər (məsələn, sistemin əməliyyat mühitində).

Təkliflər tender zamanı seçilmiş təchizatçıya və ya bir neçə təchizatçıya göndərilir. Təchizatçı müqavilədə müəyyən edilmiş şərtlərlə sistem, proqram təminatı və ya proqram təminatı xidmətinin tədarükü üçün sifarişçi ilə müqavilə bağlayan təşkilatdır.

Müqavilənin hazırlanması və tənzimlənməsi aşağıdakı vəzifələri əhatə edir:

1. mümkün təchizatçıların təkliflərinin qiymətləndirilməsi meyarları daxil olmaqla, tədarükçünün seçilməsi prosedurunun sifarişçi tərəfindən müəyyən edilməsi;
2. təkliflərin təhlili əsasında konkret təchizatçının seçilməsi;
3. hazırlanması və yekunlaşdırılması təchizatçı müqavilələri;
4. müqavilənin icrası prosesində ona dəyişikliklərin (zəruri hallarda) edilməsi.

Təchizatçının fəaliyyətinə nəzarət birgə qiymətləndirmə və audit proseslərində nəzərdə tutulmuş tədbirlərə uyğun olaraq həyata keçirilir. Qəbul prosesi zamanı lazımi testlər hazırlanır və həyata keçirilir. Müqavilə üzrə işlərin başa çatdırılması qəbulun bütün şərtləri təmin edildikdə həyata keçirilir.

Çatdırılma prosesi müştərini proqram təminatı məhsulu və ya xidməti ilə təmin edən satıcı tərəfindən həyata keçirilən fəaliyyətləri və tapşırıqları əhatə edir. Bu prosesə aşağıdakı addımlar daxildir:

1. çatdırılma başlanması;
2. tender təkliflərinə cavabın hazırlanması;
3. müqavilənin hazırlanması;
4. müqavilə işlərinin planlaşdırılması;
5. müqavilə işlərinin yerinə yetirilməsi və nəzarəti və onların qiymətləndirilməsi;
6. işlərin çatdırılması və başa çatdırılması.

Təchizatın başlanması tədarükçü tərəfindən tender təkliflərinə baxılmasından və müəyyən edilmiş tələb və şərtlərlə razılaşmaq və ya öz təkliflərini təklif etmək (razılaşdırılmış) qərarından ibarətdir. Planlaşdırma aşağıdakı vəzifələri əhatə edir:

1. Təchizatçı tərəfindən işin təkbaşına və ya subpodratçının iştirakı ilə yerinə yetirilməsi ilə bağlı qərar qəbul edilməsi;
2. ehtiva edən bir layihə idarəetmə planının təchizatçı tərəfindən hazırlanması təşkilati strukturu layihə, məsuliyyət bölgüsü, inkişaf mühiti və resurslarına texniki tələblər, subpodratçıların idarə edilməsi və s.

İnkişaf prosesi tərtibatçının yerinə yetirdiyi fəaliyyətləri və tapşırıqları təmin edir və müəyyən edilmiş tələblərə uyğun olaraq proqram təminatı və onun komponentlərinin yaradılması işini əhatə edir. Buraya dizayn və istismar sənədlərinin hazırlanması, performansın yoxlanılması üçün lazım olan materialların hazırlanması və proqram məhsullarının keyfiyyəti, kadr hazırlığının təşkili üçün lazım olan materiallar və s.

İnkişaf prosesi aşağıdakı addımları əhatə edir:

1. hazırlıq işləri;
2. sistemə olan tələblərin təhlili;
3. sistem arxitekturasının dizaynı;
4. proqram təminatına olan tələblərin təhlili;
5. proqram təminatının arxitekturasının dizaynı;
6. ətraflı proqram təminatı dizaynı;
7. proqram təminatının kodlaşdırılması və sınaqdan keçirilməsi;
8. proqram təminatının inteqrasiyası;
9. proqram təminatının ixtisas testi;
10. sistem inteqrasiyası;
11. sistemin ixtisas sınağı;
12. proqram təminatının quraşdırılması;
13. proqram təminatının qəbulu.

Hazırlıq işi layihənin miqyasına, əhəmiyyətinə və mürəkkəbliyinə uyğun olan proqram təminatının həyat dövrü modelinin seçilməsi ilə başlayır. İnkişaf prosesinin fəaliyyəti və vəzifələri seçilmiş modelə uyğun olmalıdır. Tərtibatçı seçməli, layihənin şərtlərinə uyğunlaşmalı və sifarişçi ilə razılaşdırılmış standartları, metodları və metodları istifadə etməlidir. inkişaf vasitələri, həmçinin iş planını tərtib etmək.

Sistemə olan tələblərin təhlili onun funksionallığının müəyyən edilməsini, xüsusi tələblər, etibarlılıq, təhlükəsizlik tələbləri, xarici interfeyslərə olan tələblər, performans və s. Sistem tələbləri sınaq zamanı fizibilite meyarlarına və yoxlanıla bilənliyə əsasən qiymətləndirilir.

Sistemin arxitekturasının dizaynı onun avadanlıqlarının (aparatının), proqram təminatının və sistemi idarə edən personal tərəfindən yerinə yetirilən əməliyyatların komponentlərinin müəyyən edilməsindən ibarətdir. Sistemin arxitekturası sistem tələblərinə və qəbul edilmiş dizayn standartlarına və təcrübələrinə uyğun olmalıdır.

Proqram tələblərinin təhlili hər bir proqram komponenti üçün aşağıdakı xüsusiyyətlərin müəyyən edilməsini nəzərdə tutur:

1. komponentin performans xüsusiyyətləri və əməliyyat mühiti daxil olmaqla funksionallıq;
2. xarici interfeyslər;
3. etibarlılıq və təhlükəsizlik xüsusiyyətləri;
4. erqonomik tələblər;
5. istifadə olunan məlumatlara dair tələblər;
6. quraşdırma və qəbul tələbləri;
7. istifadəçi sənədləri üçün tələblər;
8. istismar və texniki xidmət üçün tələblər.

Proqram təminatına olan tələblər bütövlükdə sistemə olan tələblərə uyğunluq, sınaq zamanı texniki-iqtisadi əsaslandırma və yoxlanılabilirlik meyarları əsasında qiymətləndirilir.

Proqram təminatının arxitekturasının dizaynına hər bir proqram komponenti üçün aşağıdakı tapşırıqlar daxildir:

1. proqram təminatı tələblərinin proqram təminatının strukturunu və onun komponentlərinin tərkibini yüksək səviyyədə müəyyən edən arxitekturaya çevrilməsi;
2. proqram təminatı və verilənlər bazası (DB) üçün proqram interfeyslərinin hazırlanması və sənədləşdirilməsi;
3. istifadəçi sənədlərinin ilkin versiyasının hazırlanması;
4. testlər üçün ilkin şərtlərin və proqram təminatının inteqrasiya planının hazırlanması və sənədləşdirilməsi.

Ətraflı proqram təminatının dizaynı aşağıdakı vəzifələri əhatə edir:

1. proqram komponentlərinin və onlar arasındakı interfeyslərin sonrakı kodlaşdırma və sınaq üçün kifayət qədər aşağı səviyyədə təsviri;
2. ətraflı verilənlər bazası dizaynının hazırlanması və sənədləşdirilməsi;
3. istifadəçi sənədlərinin yenilənməsi (lazım olduqda);
4. test tələblərinin və proqram komponentlərinin sınaqdan keçirilməsi planının işlənib hazırlanması və sənədləşdirilməsi;

Proqram təminatının kodlaşdırılması və sınaqdan keçirilməsi aşağıdakı vəzifələri əhatə edir:

1. proqram təminatının və verilənlər bazasının hər bir komponentinin kodlaşdırılması və sənədləşdirilməsi, habelə onların sınaqdan keçirilməsi üçün test prosedurları və verilənlər toplusunun hazırlanması;
2. proqram təminatının və verilənlər bazasının hər bir komponentinin onlara olan tələblərə uyğunluğunun yoxlanılması, sonra sınaq nəticələrinin sənədləşdirilməsi;
3. sənədlərin yenilənməsi (lazım olduqda);
4. proqram təminatının inteqrasiya planının yenilənməsi.

Proqram təminatının inteqrasiyası yığılmış komponentlər üçün inteqrasiya və sınaq planına uyğun olaraq hazırlanmış proqram komponentlərinin yığılmasını təmin edir. Birləşdirilmiş komponentlərin hər biri üçün növbəti səriştə testlərində hər bir səriştəni yoxlamaq üçün test dəstləri və test prosedurları hazırlanır. İxtisas tələbi uyğun olmaq üçün yerinə yetirilməli olan meyarlar və ya şərtlər toplusudur proqram təminatı spesifikasiyalarına uyğundur və sahədə istifadəyə hazırdır.

Proqram təminatının ixtisas sınağı sifarişçinin iştirakı ilə tərtibatçı tərəfindən həyata keçirilir (

Əməliyyat prosesi sistemi idarə edən operatorun təşkilatının fəaliyyətini və vəzifələrini əhatə edir. Əməliyyat prosesi aşağıdakı addımları əhatə edir.

1. Operator tərəfindən aşağıdakı vəzifələrin yerinə yetirilməsini əhatə edən hazırlıq işləri:

   1. fəaliyyətin və istismar zamanı görülən işlərin planlaşdırılması və əməliyyat standartlarının müəyyən edilməsi;
   2. əməliyyat zamanı yaranan problemlərin lokallaşdırılması və həlli prosedurlarının müəyyən edilməsi.
2. Proqram məhsulunun hər növbəti buraxılışı üçün əməliyyat sınaqları aparılır, bundan sonra bu nəşr istismara verilir.
3. İstifadəçi sənədlərinə uyğun olaraq bunun üçün nəzərdə tutulmuş mühitdə yerinə yetirilən sistemin faktiki işləməsi.
4. problemlərin təhlili və proqram təminatının modifikasiyası üçün müraciətlər (ortaya çıxan problem və ya dəyişiklik tələbi haqqında mesajların təhlili, miqyasın qiymətləndirilməsi, modifikasiyanın dəyəri, nəticədə effekt, modifikasiyanın mümkünlüyünün qiymətləndirilməsi);
5. proqram təminatının modifikasiyası (inkişaf prosesinin qaydalarına uyğun olaraq proqram məhsulunun komponentlərinə və sənədlərinə dəyişikliklərin edilməsi);
6. yoxlama və qəbul (dəyişiklik edilən sistemin bütövlüyü baxımından);
7. proqram təminatının başqa mühitə ötürülməsi (proqramların və verilənlərin çevrilməsi, proqram təminatının müəyyən müddət ərzində köhnə və yeni mühitdə paralel işləməsi);
8. əməliyyat təşkilatının, texniki xidmətin və istifadəçilərin iştirakı ilə sifarişçinin qərarı ilə proqram təminatının istismardan çıxarılması. Eyni zamanda, proqram məhsulları və sənədlər müqaviləyə uyğun olaraq arxivləşdirilməlidir.

Proqram təminatının həyat dövrü

Proqram təminatının həyat dövrü proqram məhsulunun yaradılması zərurəti barədə qərar qəbul edildiyi andan başlayan və onun istismardan tamamilə çıxarılması anında başa çatan bir müddətdir. (IEEE Std 610.12)

Proqram təminatının həyat dövrünün (LC) mərhələlərinin müəyyənləşdirilməsi zərurəti tərtibatçıların optimal inkişafın idarə edilməsi və tapşırıqların qoyulmasından proqram təminatının müəllifliyinə qədər hər mərhələdə müxtəlif keyfiyyətə nəzarət mexanizmlərindən istifadə etməklə proqram təminatının keyfiyyətini artırmaq istəyi ilə bağlıdır. Proqram təminatının həyat dövrünün ən ümumi təsviri əsas mərhələlər - proseslər şəklində bir modeldir, bunlara aşağıdakılar daxildir:

Sistem təhlili və proqram təminatı tələblərinin əsaslandırılması;

İlkin (eskiz) və təfərrüatlı (texniki) proqram təminatının dizaynı;

Proqram komponentlərinin hazırlanması, onların inteqrasiyası və ümumilikdə proqram təminatının sazlanması;

Proqram təminatının sınaqdan keçirilməsi, sınaq əməliyyatı və təkrarlanması;

Proqram təminatının müntəzəm istismarı, əməliyyatın saxlanılması və nəticələrin təhlili;

Proqram təminatına texniki qulluq, onun modifikasiyası və təkmilləşdirilməsi, yeni versiyaların yaradılması.

Bu model ümumiyyətlə qəbul edilir və həm yerli modellərə uyğun gəlir normativ sənədlər proqram təminatının hazırlanması sahəsində və xarici. Texnoloji təhlükəsizliyin təmin edilməsi nöqteyi-nəzərindən həyat dövrünün mərhələlərini təmsil etmə xüsusiyyətlərini daha ətraflı nəzərdən keçirmək məqsədəuyğundur. xarici modellər, çünki təxribat tipli proqram qüsurlarının ən çox daşıyıcısı xarici proqramdır.

Proqram təminatının həyat dövrü standartları

GOST 34.601-90

ISO/IEC 12207:1995 (Rus analoqu - GOST R ISO/IEC 12207-99)

Həyat dövrü modellərinin qrafik təsviri onların xüsusiyyətlərini və proseslərin bəzi xüsusiyyətlərini vizual olaraq vurğulamağa imkan verir.

Əvvəlcə nəticələrdən istifadə edərək əsas mərhələlərin bir-birinin ardınca başladığı kaskad həyat dövrü modeli yaradılmışdır. əvvəlki işlər. O, ciddi şəkildə müəyyən edilmiş qaydada layihənin bütün mərhələlərinin ardıcıl həyata keçirilməsini təmin edir. Növbəti mərhələyə keçid əvvəlki mərhələdəki işin tam başa çatdırılması deməkdir. Tələblərin formalaşma mərhələsində müəyyən edilmiş tələblər ciddi şəkildə texniki tapşırıqlar şəklində sənədləşdirilir və layihənin inkişafının bütün müddəti üçün müəyyən edilir. Hər bir mərhələ, inkişafın başqa bir inkişaf komandası tərəfindən davam etdirilməsi üçün kifayət qədər tam sənədlər toplusunun buraxılması ilə başa çatır. İstənilən tələbin qeyri-dəqiqliyi və ya nəticədə onun yanlış təfsiri ona gətirib çıxarır ki, siz layihənin ilkin mərhələsinə “geri qayıtmalı”sınız və tələb olunan revizyon nəinki layihə qrupunu vaxtından kənara çıxarır, həm də tez-tez layihənin ilkin mərhələsinə qayıdır. xərclərin keyfiyyətcə artması və layihənin ilkin olaraq düşünüldüyü formada dayandırılması mümkündür. Şəlalə modelinin müəlliflərinin əsas yanlışlığı dizaynın bütün prosesdən bir dəfə keçməsi, dizayn edilmiş arxitekturanın yaxşı və istifadəsi asan, tətbiqin dizaynının ağlabatan olması və tətbiqetmədəki səhvlərin asanlıqla aradan qaldırılacağı fərziyyəsidir. sınaq. Bu model bütün səhvlərin həyata keçirilməsində cəmlənəcəyini nəzərdə tutur və buna görə də onların aradan qaldırılması komponent və sistem sınaqları zamanı bərabər şəkildə baş verir. Beləliklə, böyük layihələr üçün şəlalə modeli çox real deyil və yalnız kiçik sistemlər yaratmaq üçün səmərəli istifadə edilə bilər.

Ən spesifik həyat dövrünün spiral modelidir. Bu model iterativ prosesə diqqət yetirir ilkin mərhələlər dizayn. Bu mərhələlərdə ardıcıl olaraq konsepsiyalar, tələblərin spesifikasiyası, ilkin və ətraflı dizayn yaradılır. Hər turda işin məzmunu dəqiqləşdirilir və yaradılan proqram təminatının görünüşü cəmlənir, alınan nəticələrin keyfiyyəti qiymətləndirilir və növbəti təkrarlamanın işi planlaşdırılır. Hər təkrarlamada aşağıdakılar qiymətləndirilir:

Layihənin şərtlərini və dəyərini aşmaq riski;

Başqa bir iterasiya etmək ehtiyacı;

Sistemə olan tələblərin başa düşülməsinin tamlıq və dəqiqlik dərəcəsi;

Layihənin dayandırılmasının məqsədəuyğunluğu.

Proqram təminatının həyat dövrünün standartlaşdırılması üç istiqamətdə aparılır. Birinci istiqamət Beynəlxalq Standartlaşdırma Təşkilatı (ISO - Beynəlxalq Standart Təşkilatı) və Beynəlxalq Elektrotexniki Komissiya (IEC - Beynəlxalq Elektrotexniki Komissiya) tərəfindən təşkil edilir və stimullaşdırılır. Bu səviyyədə beynəlxalq əməkdaşlıq üçün vacib olan ən ümumi texnoloji proseslərin standartlaşdırılması həyata keçirilir. İkinci istiqamət ABŞ-da Amerika Milli Standartlar İnstitutu (ANSI) ilə birlikdə Elektrik və Elektronika Mühəndisləri İnstitutu (IEEE - Elektrotexnika və Elektronika Mühəndisləri İnstitutu) tərəfindən fəal şəkildə inkişaf etdirilir. ISO/IEC və ANSI/IEEE standartları əsasən məsləhət xarakteri daşıyır. Üçüncü istiqamət ABŞ Müdafiə Nazirliyi (Müdafiə Departamenti-DOD) tərəfindən stimullaşdırılır. DOD standartları ABŞ Müdafiə Nazirliyi adından işləyən firmalar üçün məcburidir.

Proqram dizaynı üçün mürəkkəb sistem, xüsusilə real vaxt sistemləri üçün nəzərdə tutulan əsas proseslər çərçivəsində bütün məlum işlərin birləşməsinə əsaslanan həyat dövrünün sistem miqyaslı modelindən istifadə etmək məqsədəuyğundur. Bu model müxtəlif proqram layihələrinin planlaşdırılması, planlaşdırılması, idarə edilməsində istifadə üçün nəzərdə tutulub.

Bu həyat dövrü modelinin mərhələlər toplusunu proseslərin xüsusiyyətlərinə, texniki-iqtisadi xüsusiyyətlərinə və onlara təsir edən amillərə görə əhəmiyyətli dərəcədə fərqlənən iki hissəyə bölmək məqsədəuyğundur.

Həyat dövrünün birinci hissəsində, sistem təhlili, proqram təminatının dizaynı, inkişafı, sınaqdan keçirilməsi və sınaqdan keçirilməsi. Bu mərhələlərdə işlərin çeşidi, onların mürəkkəbliyi, müddəti və digər xüsusiyyətləri əhəmiyyətli dərəcədə obyekt və inkişaf mühitindən asılıdır. Proqram təminatının müxtəlif sinifləri üçün belə asılılıqların öyrənilməsi proqram təminatının yeni versiyaları üçün iş qrafiklərinin tərkibini və əsas xüsusiyyətlərini proqnozlaşdırmağa imkan verir.

Proqram təminatının istismarı və saxlanmasına dəstəyi əks etdirən həyat dövrünün ikinci hissəsi obyektin və inkişaf mühitinin xüsusiyyətləri ilə nisbətən zəif bağlıdır. Bu mərhələlərdə iş diapazonu daha sabitdir və onların mürəkkəbliyi və müddəti əhəmiyyətli dərəcədə dəyişə bilər və proqram təminatının kütləvi tətbiqindən asılıdır. Həyat dövrü təminatının istənilən modeli üçün Yüksək keyfiyyət proqram sistemləri yalnız bu mərhələlərin hər birində tənzimlənən texnoloji prosesdən istifadə edildikdə mümkündür. Belə bir proses, mövcud olanlardan seçmək və ya inkişaf obyektini və ona adekvat olan işlərin siyahısını nəzərə alaraq yaratmaq məsləhət görülən inkişaf avtomatlaşdırma vasitələri ilə dəstəklənir.

Mövzu: LCPP-nin klassik və çevik modelləri: tərifi, təsviri, fərqləndirici xüsusiyyətləri, mərhələlərin ardıcıllığı. Müxtəlif mövzularda proqram təminatının hazırlanmasında ZhCPP modelinin seçilməsi üsulları.

Proqram təminatının həyat dövrünün modelləri və mərhələləri

Proqram təminatının həyat dövrü modeli dedikdə proqram təminatının həyat dövrü ərzində icra ardıcıllığını və proseslərin, hərəkətlərin və tapşırıqların əlaqəsini müəyyən edən struktur 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, sistemin yaradıldığı və işlədiyi xüsusi şəraitdən asılıdır.

ISO/IEC 12207 standartı xüsusi həyat dövrü modeli və proqram təminatının inkişaf etdirilməsi üsullarını təklif etmir. Onun müddəaları proqram təminatının inkişafının istənilən həyat dövrü modelləri, metodları və texnologiyaları üçün ümumidir. Standart proqram təminatının həyat dövrü proseslərinin strukturunu təsvir edir, lakin bu proseslərə daxil olan fəaliyyətlərin və tapşırıqların necə həyata keçiriləcəyini və ya yerinə yetirilməsini müəyyən etmir.

Hər hansı bir konkret proqram təminatının həyat dövrü modeli onun yaradılması prosesinin xarakterini müəyyən edir, bu, vaxtında sifariş edilmiş, bir-biri ilə əlaqəli və mərhələlər (mərhələlər) üzrə birləşdirilən işlərin məcmusudur, həyata keçirilməsi tələblərə cavab verən proqram təminatı yaratmaq üçün zəruri və kifayətdir. müəyyən edilmiş tələblər.

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

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

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

Proqram təminatı tələblərinin formalaşması mərhələsi ən vaciblərdən biridir və bütün layihənin uğurunu böyük ölçüdə (hətta həlledicidir!) müəyyənləşdirir. Bu mərhələnin başlanğıcı, aparat və proqram təminatı arasında funksiyaların bölüşdürülməsinə dair əsas razılaşmaların daxil edilməsi ilə təsdiq edilmiş və təsdiq edilmiş sistem arxitekturasının əldə edilməsidir. Bu sənəd həm də proqram təminatının işləməsi haqqında ümumi fikrin təsdiqini, o cümlədən insan və sistem arasında funksiyaların bölüşdürülməsinə dair əsas razılaşmaları ehtiva etməlidir.

Proqram təminatı tələblərinin formalaşması mərhələsi aşağıdakı mərhələləri əhatə edir.

1. Layihədən əvvəl planlaşdırma işləri. Mərhələnin əsas vəzifələri inkişaf məqsədlərinin müəyyən edilməsi, ilkindir 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 ilkin müəyyənləşdirilməsi, təşkilatın strukturunun müəyyən edilməsi, təşkilatın hədəf funksiyalarının siyahısının müəyyənləşdirilməsi, təhlili, avtomatlaşdırılmış təşkilatın (obyektin) fəaliyyətinin sorğusunun aparılması. funksiyaların şöbələr və işçilər üzrə bölüşdürülməsi, şöbələr arasında funksional qarşılıqlı əlaqənin müəyyən edilməsi, informasiya axınları bölmə daxilində və arasında, obyektlərin təşkilindən kənar və xarici informasiya təsirləri, təşkilatın fəaliyyətinin avtomatlaşdırılmasının mövcud vasitələrinin təhlili.

Sorğu materiallarının emalı və iki növ modelin qurulmasını təmin edən bir təşkilatın (obyektin) fəaliyyət modelinin qurulması:

• sorğu zamanı təşkilatda mövcud işlərin vəziyyətini əks etdirən və təşkilatın necə işlədiyini başa düşməyə, habelə maneələri müəyyən etməyə və işin təkmilləşdirilməsi üçün təkliflər hazırlamağa imkan verən "AS-IS" ("olduğu kimi") modeli. vəziyyət;
• Təşkilatın işinin yeni texnologiyaları ideyasını əks etdirən "TO-BE" modeli ("olduğu kimi").

Modellərin hər biri təşkilatın fəaliyyətinin tam funksional və informasiya modelini, eləcə də (zəruri hallarda) təşkilatın davranış dinamikasını təsvir edən modeli ehtiva etməlidir. Qeyd edək ki, qurulmuş modellər, müəssisənin informasiya sistemini işləyib-hazırlayıb tətbiq etməməsindən asılı olmayaraq müstəqil praktiki əhəmiyyət kəsb edir, çünki onlardan işçilərin təlimi və müəssisənin biznes 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 proqram təminatının spesifikasiyası, funksional, texniki və interfeys spesifikasiyasıdır ki, bunun üçün onların tamlığı, yoxlanılması və həyata keçirilməsinin mümkünlüyü təsdiqlənir.

Dizayn mərhələsi aşağıdakı addımları əhatə edir.

1. Proqram təminatı sistemi layihəsinin hazırlanması. Bu mərhələdə “Gələcək sistem nə etməlidir?” sualına cavab verilir, yəni: sistemin arxitekturası, funksiyaları, xarici şərtlər funksionallıq, interfeyslər və istifadəçilərlə sistem arasında funksiyaların paylanması, proqram təminatı və informasiya komponentlərinə tələblər, icraçıların tərkibi və işlənmə vaxtı, proqram təminatının sazlanması planı və keyfiyyətə nəzarət.

   Sistem layihəsinin əsasını layihələndirilmiş sistemin “TO-BE” modeli üzərində qurulan modelləri təşkil edir. Sistem layihəsinin inkişafının nəticəsi proqram təminatı tələblərinin təsdiq edilmiş və təsdiq edilmiş spesifikasiyası olmalıdır: funksional, texniki və interfeys spesifikasiyası, onların tamlığı, yoxlanılması və mümkünlüyü təsdiqlənir.

2. Ətraflı (texniki) layihənin hazırlanması. Bu mərhələdə sistem arxitekturasının dizaynı və detallı dizayn daxil olmaqla faktiki proqram təminatının dizaynı həyata keçirilir. Beləliklə, sualın cavabı verilir: "Sistemi necə qurmaq olar ki, tələbləri ödəsin?"

Ətraflı dizaynın nəticəsi təsdiqlənmiş proqram təminatının spesifikasiyasıdır, o cümlədən:

• proqram komponentlərinin iyerarxiyasının, verilənlər və idarəetmə üçün modullararası interfeyslərin formalaşdırılması;
• hər bir proqram komponentinin spesifikasiyası, adı, məqsədi, fərziyyələri, ölçüləri, çağırış ardıcıllığı, giriş və çıxış məlumatları, səhv çıxışlar, alqoritmlər və məntiqi sxemlər;
• ayrı-ayrı sahələr səviyyəsinə qədər fiziki və məntiqi məlumat strukturlarının formalaşdırılması;
• hesablama resurslarının paylanması planını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ümkünlüyünün və əsaslılığının yoxlanılması;
• ilkin inteqrasiya və sazlama planı, istifadəçi təlimatı və qəbul test planı.

Təfərrüatlı dizayn mərhələsinin tamamlanması layihənin sona qədər nəzarəti və ya layihənin kritik blok təhlilidir.

İcra mərhələsi – aşağıdakı işlərin icrası.

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

   Xarici spesifikasiyalar aşağıdakı məlumatları ehtiva etməlidir:

   • modulun adı - modulu çağırmaq üçün istifadə olunan ad göstərilir (bir neçə girişi olan modul üçün hər bir giriş üçün ayrıca spesifikasiyalar olmalıdır);
   • funksiya - modulun yerinə yetirdiyi funksiya və ya funksiyaları müəyyən edir;
   • modula ötürülən parametrlərin siyahısı (nömrə və sıra);
   • giriş parametrləri - modul tərəfindən qaytarılan bütün məlumatların dəqiq təsviri (istənilən giriş şəraitində modulun davranışı müəyyən edilməlidir);
   • xarici effektlər (mesajın çapı, terminaldan sorğunun oxunması və s.).
2. Modul məntiqinin dizaynı və modulun proqramlaşdırılması (kodlaşdırma).
3. Modulların düzgünlüyünün yoxlanılması.
4. Modul testi.
5. Fərdi parametrlər, simvollar və bitlər səviyyəsinə qədər verilənlər bazasının təsviri.
6. Qəbul imtahan planı.
7. İstifadəçi təlimatı.
8. İnteqrasiya və sazlama üçün ilkin plan. Sonrakı mərhələlərin məzmunu əsasən proqram təminatının həyat dövrünün müvafiq prosesləri ilə üst-üstə düşür. Ümumiyyətlə, işin əsaslı və rasional planlaşdırılması və təşkili mülahizələri əsasında texnoloji mərhələlər fərqləndirilir. Mümkün variant proqram təminatının həyat dövrü prosesləri ilə əlaqəsi və iş mərhələləri şəkildə göstərilmişdir.

düyü. 1.

Proqram təminatının həyat dövrü modellərinin növləri

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

Bu model görünüşünə görə W. Royce (1970) borcludur. Modelin başqa adı var - şəlalə (şə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 tam başa çatdıqdan sonra həyata keçirilir; Tamamlanmış mərhələlərə qayıdış təmin edilmir.

Formalaşma və təhlil mərhələlərində müəyyən edilmiş hazırlanmış PS-yə olan tələblər ciddi şəkildə TOR şəklində sənədləşdirilir və layihənin inkişafının bütün müddəti üçün müəyyən edilir. 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 tam sənədlər toplusunun (TOR, EP, TP, RP) buraxılması ilə başa çatır. Bu yanaşma ilə inkişaf keyfiyyətinin meyarı TOR-un spesifikasiyalarının yerinə yetirilməsinin dəqiqliyidir. Tərtibatçıların əsas diqqəti optimal dəyərlərə nail olmaqdır spesifikasiyalar işlənmiş PS - performans, işğal edilmiş yaddaşın miqdarı və s.

Üstünlüklər şəlalə 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şır;
• məntiqi ardıcıllıqla yerinə yetirilən işlərin mərhələləri bütün işlərin tamamlanma vaxtını və müvafiq xərcləri planlaşdırmağa imkan verir.

Kaskad yanaşması PS-lərin qurulmasında özünü yaxşı sübut etdi, bunun üçün bütün tələblər layihənin ən əvvəlində tam və aydın şəkildə ifadə oluna bilər. Nə qədər ki, bütün bunlar standartlar və müxtəlif dövlət qəbul komissiyaları tərəfindən idarə olunur, sxem yaxşı işləyir.

Qüsurlar şəlalə modeli:

• səhvlərin müəyyən edilməsi və aradan qaldırılması yalnız sınaq mərhələsində həyata keçirilir ki, bu da əhəmiyyətli dərəcədə genişləndirilə bilə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 formalaşdırılmasına əsaslanır, əslində layihənin başlanğıcında müştərinin tələbləri yalnız qismən müəyyən edilir;
• işin nəticələri yalnız layihə başa çatdıqdan sonra sifarişçiyə təqdim olunur.

PS-nin həyat dövrünün iterativ modeli

Kommersiya layihələrinin böyüməsi ilə aydın oldu ki, gələcək sistemin layihəsini hər zaman ətraflı şəkildə işləmək mümkün deyil, çünki sistem yaradılarkən onun dinamik fəaliyyət sahələrində (biznesdə) işləməsinin bir çox aspektləri dəyişir. İnkişafın istənilən 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. Beləliklə, PS-nin həyat dövrünün iterativ modeli meydana çıxdı, aralıq idarəetmə ilə model və ya fazaların tsiklik təkrarlanması ilə model adlanır.

İterativ modeldə dizayn və proqramlaşdırma çatışmazlıqları sonradan əvvəlki mərhələyə qismən qayıtmaqla aradan qaldırıla bilər. Səhv aşkarlanma dərəcəsi nə qədər aşağı olarsa, onu düzəltmək bir o qədər bahalıdır. Kodun yazılması mərhələsində səhvləri aşkar etmək və aradan qaldırmaq üçün tələb olunan səylərin dəyəri bir kimi qəbul edilərsə, tələblərin hazırlanması mərhələsində səhvin müəyyən edilməsi və aradan qaldırılması xərcləri 5-10 dəfə az olacaqdır. texniki xidmət mərhələsində xətanın müəyyən edilməsi və aradan qaldırılması 20 dəfə az olacaq.daha çox.

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

Prototipləşdirmə

Çox vaxt müştəri gələcək proqram məhsulu üçün məlumatların daxil edilməsi, emalı və ya çıxışı üçün tələbləri formalaşdıra bilmir. Tərtibatçı istifadəçi ilə dialoq şəklində məhsulun əməliyyat sistemi üçün uyğunluğuna və ya alqoritmin effektivliyinə şübhə edə bilər. Belə hallarda prototipdən istifadə etmək məqsədəuyğundur. Prototipləşdirmənin əsas məqsədi müştərinin tələblərindəki qeyri-müəyyənliyi aradan qaldırmaqdır. Modelləşdirmə (prototipləşdirmə) tələb olunan məhsulun modelinin yaradılması prosesidir.

Model aşağıdakı formaları ala bilər.

1. Kağız maketi (insan-maşın dialoqunun əl ilə çəkilmiş diaqramı) və ya PC əsaslı maket.
2. Tələb olunan bəzi funksiyaları həyata keçirən iş planı.
3. Xüsusiyyətləri təkmilləşdirilməli olan mövcud proqram.

Şəkildə göstərildiyi kimi, prototipləşdirmə müştəri və tərtibatçının iştirak etdiyi təkrarlanan təkrarlamalara əsaslanır.

Prototipləmə üçün hərəkətlərin ardıcıllığı şəkildə göstərilmişdir. Prototipləşdirmə yaradılan proqram təminatı sisteminə tələblərin toplanması və dəqiqləşdirilməsi ilə başlayır. Tərtibatçı və müştəri birlikdə proqram təminatının məqsədlərini müəyyən edir, hansı tələblərin məlum olduğunu və hansının yenidən müəyyən edilməsini müəyyənləşdirir. Sonra sürətli dizayn həyata keçirilir. O, istifadəçiyə görünməli olan xüsusiyyətlərə diqqət yetirir. Sürətli dizayn bir planın qurulmasına gətirib çıxarır. Dizayn müştəri tərəfindən qiymətləndirilir və proqram təminatı tələblərini aydınlaşdırmaq üçün istifadə olunur. Planlaşdırma müştərinin bütün tələblərini ortaya qoyana və tərtibatçıya nə edilməli olduğunu başa düşməyə imkan verənə qədər təkrarlamalar davam edir.

Prototipləşdirmənin üstünlüyü tam sistem tələblərinin müəyyən edilməsini təmin etmək qabiliyyətidir. Layout Dezavantajları:

• müştəri məhsulun planını götürə bilər;
• tərtibatçı məhsulun tərtibatını səhv sala bilər.

Çatışmazlıqlar izah edilməlidir. Müştəri PS-nin işlək versiyasını görəndə başa düşməyi dayandırır ki, PS-nin işlək versiyasının ardınca bir çox keyfiyyət problemləri və müşayiət rahatlığı sistemləri. Tərtibatçı bu barədə müştəriyə məlumat verdikdə, cavab qəzəb və layoutun sürətlə işləyən məhsula çevrilməsi tələbi ola bilər. Bu, proqram təminatının hazırlanmasının idarə edilməsinə mənfi təsir göstərir.

Digər tərəfdən, tez bir iş sxemi əldə etmək üçün tərtibatçı tez-tez müəyyən güzəştlərə gedir. Məsələn, uyğun olmayan proqramlaşdırma dilləri istifadə edilə bilər və ya əməliyyat sistemi. Sadə bir nümayiş üçün səmərəsiz (sadə) alqoritmdən istifadə edilə bilər. Bir müddət sonra tərtibatçı bu vasitələrin uyğun olmadığının səbəblərini unudur. Nəticədə idealdan uzaq seçilmiş variant sistemə inteqrasiya olunur.

Əvəz edilmiş digər proqram təminatının həyat dövrü modellərinə baxmadan əvvəl şəlalə modeli, proqram sistemlərinin layihələndirilməsi strategiyaları üzərində dayanmalıyıq. Proqram təminatının həyat dövrü modelini böyük ölçüdə müəyyən edən proqram dizayn strategiyasıdır.

Proqram təminatının dizayn strategiyaları

Proqram təminatı sistemlərinin qurulması üçü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, tikintinin qalan hissəsi versiyaların ardıcıllığı kimi həyata keçirilir. Birinci versiya planlaşdırılmış funksiyaların bəzilərini həyata keçirir, növbəti versiya əlavə funksiyaları həyata keçirir və s. tam sistem əldə olunana qədər;
• təkamül strategiyası. Sistem həmçinin bir sıra versiyalar kimi qurulub, lakin prosesin əvvəlində bütün tələblər müəyyən edilməyib. Tələblər versiyaların hazırlanması nəticəsində müəyyən edilir. IEEE/EIA 12207 standartının tələblərinə uyğun proqram təminatının layihələndirilməsi strategiyalarının xüsusiyyətləri Cədvəl 1-də göstərilmişdir.

artan model

Artan model artımlı dizayn strategiyasının klassik nümunəsidir. O, ardıcıl şəlalə modelinin elementlərini iterativ tərtibat fəlsəfəsi ilə birləşdirir (təkmilləşdirmə kimi B. Boehm tərəfindən təklif edilmişdir). şəlalə modeli). Buradakı hər bir xətt ardıcıllığı təchiz edilmiş proqram artımını yaradır. Məsələn, 1-ci artımda (versiyada) mətn emal proqramı əsas faylların işlənməsi, redaktə edilməsi və sənədləşdirmə funksiyalarını həyata keçirir; 2-ci artımda - daha mürəkkəb redaktə və sənədləşdirmə imkanları; 3-cü artımda - orfoqrafiya və qrammatik yoxlama; 4-cü artımda - səhifə düzeni imkanları.

Birinci artım əsas tələbləri yerinə yetirən əsas məhsulla nəticələnir (lakin bir çox köməkçi tələblər həyata keçirilməmiş qalır). Növbəti artım planı əlavə funksiyalar və funksionallıq təmin etmək üçün əsas məhsulun dəyişdirilməsini nəzərdə tutur.

Təbiətinə görə artan proses iterativdir, lakin çörək lövhəsindən fərqli olaraq, artımlı model hər artımda işləyən bir məhsul təmin edir.

Belə bir proqram təminatının həyat dövrü modelinin diaqramı şəkildə göstərilmişdir. Artan yanaşmanın müasir tətbiqlərindən biri ekstremal proqramlaşdırmadır (funksionallığın çox kiçik artımlarına diqqət yetirilir).

Spiral proqram təminatının həyat dövrü modeli

spiral modeli təkamül dizayn strategiyasının klassik nümunəsidir. Model (müəllif B. Boehm, 1988) klassik həyat dövrünün və prototipləşdirmənin ən yaxşı xüsusiyyətlərinə əsaslanır, ona yeni element əlavə olunur - bu paradiqmalarda olmayan risk təhlili. Model spiralın dörd kvadrantı ilə təmsil olunan dörd fəaliyyəti müəyyən edir.

1. Planlaşdırma məqsədlərin, seçimlərin və məhdudiyyətlərin müəyyən edilməsidir.
2. Risk təhlili – variantların təhlili və riskin tanınması/seçimi.
3. Mühəndislik məhsulun inkişafının növbəti səviyyəsidir.
4. Qiymətləndirmə - cari dizayn nəticələrinin müştəri tərəfindən qiymətləndirilməsi.

İnteqrasiya aspekti spiral modeli spiralın radial ölçüsünü nəzərə aldıqda aydın olur. Spiral boyunca hər iterasiya ilə PS-nin getdikcə daha tam versiyaları qurulur. Spiralın ilk növbədə ilkin məqsədlər, seçimlər 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 aşkar edərsə, dizayn kvadrantında istifadə olunan prototipləmə tərtibatçı və müştərinin köməyinə gəlir.

Modelləşdirmə problemli və dəqiqləşdirilmiş 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əri qiymətləndirmə kvadrantı). Planlaşdırma və risk təhlilinin növbəti mərhələsi müştərilərin təkliflərinə əsaslanır. Spiraldan keçən hər bir dövrədə risk təhlilinin nəticələri “davam et, davam etmə” şəklində formalaşır. Əgər risk çox böyükdürsə, layihə dayandırıla bilər.

Əksər hallarda, spiral davam edir, hər bir addım tərtibatçıları daha ümumi sistem modelinə doğru itələyir. Spiraldakı hər bir döngə klassik həyat dövrü və ya maket tərəfindən həyata keçirilə bilən konstruksiya (sağ alt kvadrant) tələb edir. Qeyd edək ki, spiralın mərkəzindən uzaqlaşdıqca inkişaf fəaliyyətlərinin sayı (aşağı sağ kvadrantda baş verir) artır.

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

1. – ilkin tələblərin toplanması və layihənin planlaşdırılması;
2. – eyni iş, lakin müştərinin tövsiyələri əsasında;
3. – ilkin tələblər əsasında risk təhlili;
4. – müştəri reaksiyasına əsaslanan risk təhlili;
5. – inteqrasiya olunmuş sistemə keçid;
6. – sistemin ilkin tərtibatı;
7. - tərtibatın növbəti səviyyəsi;
8. - layihələndirilmiş 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ə) proqram təminatının işlənməsini əks etdirir;
2. inkişafın təkamülünün hər bir mərhələsində riski açıq şəkildə nəzərə almağa imkan verir;
3. addım daxildir sistemli yanaşma iterativ inkişaf strukturuna;
4. riski azaltmaq və proqram məhsulunu təkmilləşdirmək üçün simulyasiyadan istifadə edir.

Qüsurlar spiral modeli:

• müqayisəli yenilik (modelin effektivliyinə dair kifayət qədər statistik məlumat yoxdur);
• müştəri üçün artan tələblər;
• İnkişaf vaxtını izləmək və idarə etməkdə çətinliklər.

Spiral inkişaf prosesi modeli hazırda ən çox yayılmışdır. Onun ən məşhur variantları Rational-dan RUP (Rational Unified Process) və MSF-dir (Microsoft Solution Framework). Modelləşdirmə dili kimi UML (Unified Modeling Language) istifadə olunur. Sistemin yaradılması, gələcək məhsulun xüsusiyyətlərini təkmilləşdirmək üçün hər növbədə bir spiralda hərəkət edən və eyni mərhələlərdən keçərək təkrarlanan şəkildə həyata keçirilməlidir. Görünür ki, indi hər şey yaxşıdır: yalnız proqnozlaşdırıla bilənlər planlaşdırılır, planlaşdırılanlar hazırlanır və istifadəçilər lazımi düzəlişlər etmək imkanı əldə edərək məhsulla əvvəlcədən tanış olmağa başlayırlar.

Lakin bunun üçün çox böyük vəsait tələb olunur. Həqiqətən də, əgər əvvəllər ehtiyac olduqda mütəxəssislər qruplarını yaratmaq və ləğv etmək mümkün idisə, indi onların hamısı layihədə daim iştirak etməlidirlər: memarlar, proqramçılar, testçilər, təlimatçılar və s. Üstəlik, müxtəlif qrupların səyləri müvafiq qaydada sinxronlaşdırılmalıdır. dizayn qərarlarını vaxtında əks etdirmək və lazımi dəyişikliklər 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ı metodlarına əsaslanan mürəkkəb proqram sistemləri yaratmağa imkan verir. RUP-un inkişafı üçün ilkin şərtlər 1980-ci illərin əvvəllərində yaranmışdır. Rational Software korporasiyasında. 2003-cü ilin əvvəlində Rational IBM-i satın aldı. RUP-un güvəndiyi əsas sütunlardan 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 saxlanılır və hazırlanır. Ümumi Bilik Bazası modelləşdirmə dili kimi Vahid Modelləşdirmə Dilindən (UML) istifadə edir. RUP-da təkrarlanan və artan proqram təminatının inkişafı layihənin ardıcıl icra olunan bir neçə layihəyə bölünməsini nəzərdə tutur və hər bir inkişaf iterasiyası iterasiyanın sonunda əldə ediləcək məqsədlər toplusu ilə aydın şəkildə müəyyən edilir. Yekun iterasiya hesab edir ki, iterasiyanın məqsədləri toplusu məhsulun müştərisi tərəfindən müəyyən edilmiş məqsədlər toplusuna tam uyğun olmalıdır, yəni bütün tələblər yerinə yetirilməlidir.

Proses modellərin təkamülünü əhatə edir; inkişaf dövrünün iterasiyası proqram modelinin xüsusi versiyasına unikal şəkildə uyğun gəlir. İterasiyaların hər biri nəzarət elementlərini ehtiva edir proqram təminatının həyat dövrü: təhlil və dizayn (modelləşdirmə), həyata keçirmə, inteqrasiya, sınaq, həyata keçirmə. Bu mənada RUP bir tətbiqdir spiral modeli, baxmayaraq ki, o, çox vaxt qrafik-cədvəl şəklində təsvir olunur.

Bu rəqəm iki ölçünü göstərir: üfüqi ox vaxtı təmsil edir və prosesin həyat dövrünün müvəqqəti aspektlərini göstərir; şaquli ox prosesin fiziki strukturunu müəyyən edən fənləri təmsil edir. Layihədəki vurğunun zamanla necə dəyişdiyini görə bilərsiniz. Məsələn, erkən təkrarlamalar tələblərə daha çox vaxt sərf edir; sonrakı iterasiyalarda icraya daha çox vaxt ayrılır. Üfüqi ox zaman dövrlərindən - hər biri müstəqil inkişaf dövrü olan iterasiyalardan formalaşır; dövrün məqsədi maraqlı tərəflərin nöqteyi-nəzərindən faydalı olan son məhsula əvvəlcədən müəyyən edilmiş bəzi dəqiqləşdirmələr 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 (Başlanğıc) - layihə konsepsiyasının formalaşması, nə yaratdığımızı başa düşmək, məhsul haqqında fikir (vizion), biznes planın hazırlanması (biznes işi), layihənin hazırlanması. prototip proqramı və ya qismən həll. Bu, məlumatların toplanması və tələblərin təhlili, bütövlükdə layihənin imicinin müəyyənləşdirilməsi mərhələsidir. Məqsəd dəstək və maliyyə almaqdır. Son təkrarlamada bu mərhələnin nəticəsi texniki tapşırıqdır.
2. Dizayn, inkişaf (İnkişaf) - planın aydınlaşdırılması, onu necə yaratdığımızı başa düşmək, layihələndirmək, lazımi hərəkətləri və resursları planlaşdırmaq, xüsusiyyətlərin detallaşdırılması. Səhnə bütün memarlıq qərarlarının qəbul edildiyi və risklərin nəzərə alındığı icra edilə bilən bir memarlıqla başa çatır. İcra edilə bilən arxitektura əsas memarlıq qərarlarının həyata keçirilməsini nümayiş etdirən proqram təminatıdır. Son iterasiyada bu texniki layihədir.
3. Sistemin həyata keçirilməsi, yaradılması (Tikinti) arxitekturaya daxil edilmiş sistemin funksionallığının genişləndirilməsi mərhələsidir. Son təkrarlamada bu, işləyən bir layihədir.
4. Həyata keçirmə, yerləşdirmə (Keçid). Məhsulun son versiyasının yaradılması. Məhsulun tətbiqi mərhələsi, məhsulun konkret istifadəçiyə çatdırılması (replikasiya, çatdırılma və təlim).

Şaquli ox, hər biri yerinə yetirilən vəzifələr, onlara cavabdeh olan rollar, tapşırıqlara daxil olan və onların icrası zamanı buraxılan məhsullar və s. baxımından daha ətraflı təsvir edilə bilən fənlərdən ibarətdir.

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

1. Biznesin təhlili və modelləşdirilməsi ( Biznes modelləşdirmə ) təşkilatın biznesini öyrənmək və bu barədə bilik toplamaq, biznes proseslərini optimallaşdırmaq və onların qismən və ya tam avtomatlaşdırılması ilə bağlı qərarlar qəbul etmə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 almaq və onu inkişaf etdirilən sistemin məzmununu müəyyən edən və sistemin nə etməli olduğuna dair gözləntiləri ətraflı təsvir edən tələblər toplusuna çevirməkdən ibarətdir.
3. Təhlil və dizayn (Təhlil və dizayn) tələblərin bu tələblərin necə həyata keçirilməli olduğunu göstərən ara təsvirlərə (modellərə) çevrilməsi prosedurlarını əhatə edir.
4. Tətbiq kodun işlənib hazırlanmasını, tərtibatçı səviyyəsində sınaqdan keçirilməsini və müəyyən edilmiş spesifikasiyalara uyğun olaraq komponentlərin, alt sistemlərin və bütün sistemin inteqrasiyasını əhatə edir.
5. Sınaq yaradılan məhsulun keyfiyyətinin qiymətləndirilməsinə həsr edilmişdir.
6. Yerləşdirmə məhsulların müştərilərə çatdırılması və məhsulun son istifadəçilər üçün əlçatan olması ilə bağlı həyata keçirilən əməliyyatları əhatə edir.
7. Konfiqurasiyanın idarə edilməsi və dəyişikliklərin idarə edilməsi (Konfiqurasiyanın idarə edilməsi) aralıq və son məhsulların sinxronlaşdırılmasına və layihə zamanı onların inkişafının idarə edilməsinə və gizli problemlərin tapılmasına həsr edilmişdir.
8. Layihə İdarəetməsi layihənin planlaşdırılmasına, risklərin idarə edilməsinə, layihənin gedişatının monitorinqinə və əsas göstəricilərin davamlı qiymətləndirilməsinə həsr edilmişdir.
9. İdarəetmə mühiti (Ətraf mühit) inkişaf mühitinin formalaşması elementlərini ehtiva edir məlumat Sistemi və layihə fəaliyyətlərinə dəstək.

Layihənin xüsusiyyətlərindən asılı olaraq istənilən IBM Rational alətləri, eləcə də üçüncü tərəf alətləri istifadə edilə bilər. RUP layihənin uğurlu inkişafı üçün altı təcrübəyə riayət etməyi tövsiyə edir: iterativ inkişaf; tələblərin idarə edilməsi; modul arxitekturadan istifadə; vizual modelləşdirmə; keyfiyyət yoxlaması; izləməni dəyişdirin.

RUP-un tərkib hissəsi artefaktlar (artefakt), presedentlər (presedent) və rollardır (rol). Artefaktlar, son məhsul üzərində işləyərkən yaradılan və ya istifadə olunan layihənin bəzi məhsullarıdır. İstifadə halları müşahidə edilə bilən nəticə əldə etmək üçün sistem tərəfindən həyata keçirilən hərəkətlərin ardıcıllığıdır. Əslində, fərdin və ya qrupun hər hansı bir işinin nəticəsi artefaktdır, istər təhlil sənədi, istər model elementi, istər kod faylı, istər test skripti, istərsə də xətanın təsviri və s. bu və ya digər növ artefakt yaratmaq. Beləliklə, RUP bu və ya digər mərhələdə inkişaf qrupunun hər bir üzvünün vəzifələrini - rollarını, yəni bu və ya digər artefaktı nə vaxt və kimin yaratmalı olduğunu dəqiq müəyyənləşdirir. Proqram təminatı sisteminin yaradılmasının bütün prosesi RUP-da artefaktların yaradılması prosesi kimi nəzərdən keçirilir ilkin sənədlər təhlili və icra olunan modullar, istifadəçi təlimatları və s.

RUP proseslərinin kompüter dəstəyi üçün IBM geniş çeşidli alətlər hazırlayıb:

• Rasional Gül-CASE- deməkdir vizual modelləşdirmə kod elementlərini yaratmaq qabiliyyətinə malik olan informasiya sistemləri. Məhsulun xüsusi buraxılışı - Rational Rose RealTime - çıxışda icra olunan modul əldə etməyə imkan verir;
• Rational Requisite Pro proqram komponentlərinin inkişafının istənilən mərhələsində baş verən tələb dəyişikliklərini yaratmağa, strukturlaşdırmağa, prioritetləşdirməyə, izləməyə, nəzarət etməyə imkan verən tələblərin idarə edilməsi vasitəsidir;
• Rational ClearQuest sınaq və tələblərin idarə edilməsi alətləri ilə sıx inteqrasiya edən və bütün səhvləri və sənədləri bir-biri ilə əlaqələndirmək üçün vahid mühiti təmin edən dəyişikliklərin idarə edilməsi və səhv izləmə məhsuludur;
• Rational SoDA, daxili şirkət sənədləri üçün korporativ standart təyin etməyə imkan verən layihə sənədlərinin avtomatik yaradılması üçün məhsuldur. Sənədləri mövcud standartlara (ISO, CMM) uyğunlaşdırmaq da mümkündür;
• Rasional Təmizləmə, Rasional Kəmiyyət Rasional PureCoverage, sınaq və sazlama vasitələri;
• Rational Visual Quantify proqram və komponentlərin C/C++, Visual Basic və Java tərtibatçıları üçün performans ölçmə vasitəsidir; proqram təminatının işində darboğazları müəyyən etməyə və aradan qaldırmağa kömək edir;
• Rational Visual PureCoverage - kodun yoxlanılmayan sahələrini avtomatik aşkarlayır;
• Rational ClearCase bütün layihə sənədlərinin versiyalarına nəzarət etməyə imkan verən proqram konfiqurasiyasının idarə edilməsi məhsuludur (Rational's Software Configuration Management, SCM). O, eyni vaxtda layihələrin bir neçə versiyasını saxlamaq, onlar arasında sürətlə keçid etmək üçün istifadə edilə bilər. Rational Requisite Pro yeniləmələri dəstəkləyir. və inkişaf qrupu üçün tələblərdəki dəyişiklikləri izləyir;
• SQA TeamTest aləti sınaq avtomatlaşdırılması;
• Rasional TestManager testlə əlaqəli bütün alətləri, artefaktları, skriptləri və məlumatları bir araya gətirən test idarəetmə sistemidir;
• Rasional Robot - testlərin yaradılması, dəyişdirilməsi və avtomatik icrası üçün alət;
• SiteLoad, SiteCheck - performans və pozulmuş keçidlər üçün veb saytları sınaqdan keçirmək üçün alətlər;
• Rational PerformanceStudio - Sistemlərin performans xüsusiyyətlərini ölçün və proqnozlaşdırın.

Bu məhsul dəsti daim təkmilləşdirilir və genişləndirilir. Məsələn, son məhsul IBM Rational Software Architect (RSA) IBM Software Development Platform-un bir hissəsidir, proqram təminatı sistemlərinin işlənməsinin həyat dövrünü dəstəkləyən alətlər dəstidir. IBM Rational Software Architect məhsulu UML 2.0 vahid modelləşdirmə dilindən istifadə etməklə işlənib hazırlanmaqda olan proqram təminatı sistemlərinin modellərini, ilk növbədə işlənən proqramın arxitekturasının modellərini qurmaq üçün nəzərdə tutulmuşdur. Bununla belə, RSA Rational Application Developer, Rational Web Developer və Rasional Software Modeler kimi proqram məhsullarının funksionallığını özündə birləşdirir və bununla da memarlara və analitiklərə UML 2.0 dilindən istifadə etməklə hazırlanmaqda olan informasiya sisteminin müxtəlif görünüşlərini yaratmağa, tərtibatçılara isə inkişaf etdirməyə imkan verir. J2EE, XML, veb xidmətləri və s.

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

• biznesin təhlili və modelləşdirilməsi (Biznes modelləşdirmə);
• tələblərin idarə edilməsi (Tələblər);
• təhlil və dizayn (Təhlil və dizayn);
• icra (İcra).

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

MSF (Microsoft Solution Framework)

1994-cü ildə İT layihələrindən maksimum yararlanmaq üçün Microsoft öz texnologiyası əsasında qurulmuş həllərin effektiv şəkildə layihələndirilməsi, işlənib hazırlanması, həyata keçirilməsi və saxlanması üçün bir sıra təlimatlar buraxdı. Bu bilik Microsoft-un iri proqram təminatının hazırlanması və texniki xidmət layihələri üzərində işləyərkən ə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şı təcrübəyə ə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 əsasında inkişaf etmişdir ümumi üsullar Tətbiqi və xüsusi tətbiqlər üçün MSF metodologiyaları. Bundan əlavə, Microsoft MSF-nin tətbiqi sahəsində tətbiqi biliklərə görə mütəxəssisləri sertifikatlaşdırır (məsələn, layihənin idarə edilməsi metodologiyasında ekspertiza üçün MCTS 74-131 sertifikatı). MSF üsulları haqqında məlumat əldə etməzdən əvvəl, ilk növbədə hansı MSF tətbiqini nəzərdə tutduğunuzu müəyyənləşdirməlisiniz.

Microsoft tərəfindən hazırlanmış MSF-nin ən populyar tətbiq variantları bunlardır:

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

MSF-nin tətbiqi variantlarının əhəmiyyəti onunla vurğulanır ki, “saf versiyada” MSF metodologiyasının özü Microsoft tərəfindən İT layihələrində istifadə edilmir. Microsoft Consulting Services layihələri MSF və Agile arasında hibrid metodologiyadan istifadə edir. Microsoft ekspertləri tərəfindən hazırlanmış MSF-nin tətbiqi versiyaları arasında xarici əhəmiyyətli fərqlərə baxmayaraq, onlar üçün MSF metodlarının bazası ümumi olaraq qalır və iterativ layihələrin idarə edilməsinə ümumi metodoloji yanaşmaları əks etdirir.

MOF Microsoft məhsulları və texnologiyalarına əsaslanan mühüm İT həlləri yaradan təşkilatlara onların etibarlılığına, əlçatanlığına, müşayiət rahatlığı(dəstəklənmə qabiliyyəti) və idarəolunma (idarəetmə qabiliyyəti). MN kadrların və proseslərin təşkili ilə bağlı məsələləri həll edir; mürəkkəb (mürəkkəb), paylanmış (paylanmış) və heterogen (heterogen) İT mühitləri şəraitində texnologiyalar və idarəetmə. MOF ən yaxşıya əsaslanır istehsal üsulları Böyük Britaniya hökumətinin agentliyi olan Mərkəzi Kompüter və Telekommunikasiya Agentliyi tərəfindən tərtib edilmiş İT İnfrastruktur Kitabxanasında (ITIL) toplanmışdır.

Ayrılmış vaxt və büdcə çərçivəsində biznes həllinin yaradılması sübut edilmiş metodoloji əsas tələb edir. MSF uğurlu İT həllərinin planlaşdırılması, dizaynı, işlənib hazırlanması və həyata keçirilməsi üçün sübut edilmiş metodologiyalar təqdim edir. Çevikliyi, miqyası və sərt təlimatların olmaması ilə MSF istənilən ölçülü təşkilatın və ya layihə komandasının ehtiyaclarını qarşılaya bilir. MSF metodologiyası əksər layihələr üçün xarakterik olan bütün bu amillərlə bağlı kadrların, proseslərin, texnoloji elementlərin və məsələlərlə bağlı prinsiplər, modellər və intizamlardan ibarətdir. MSF iki model və üç fənndən ibarətdir. Onlar 5 sənəddə ətraflı təsvir edilmişdir. MSF-nin öyrənilməsinə modellərlə (layihə komandası modeli, proses modeli) başlamaq daha yaxşıdır, sonra isə fənlərə (layihənin idarə edilməsi intizamı, risklərin idarə edilməsi intizamı, təlimin idarə edilməsi intizamı) keçmək daha yaxşıdır.

MSF proses modeli İT həllərinin işlənib hazırlanması və həyata keçirilməsi üçün ümumi metodologiyanı təmsil edir. Bu modelin özəlliyi ondan ibarətdir ki, onun çevikliyi və sərt tətbiq edilmiş prosedurların olmaması səbəbindən çox geniş spektrli İT layihələrinin hazırlanmasında tətbiq oluna bilər. Bu model iki standart istehsal modelinin xüsusiyyətlərini birləşdirir: kaskad (şəlalə) və spiral (spiral). MSF 3.0-dakı proses modeli daha da innovativ olmuşdur: o, həllin başlanğıcından tətbiqinə qədər bütün həyat dövrünü əhatə edir. Bu yanaşma layihə komandalarına həllin biznes dəyərinə diqqət yetirməyə kömək edir, çünki bu dəyər yalnız icra tamamlandıqdan və məhsul istifadəyə verildikdən sonra reallaşır.

MSF prosesi hər hansı əhəmiyyətli (aralıq və ya yekun) nəticə çərçivəsində nailiyyəti xarakterizə edən layihənin əsas məqamlarına - "mərhələlərə" yönəldilmişdir. Bu nəticəni qiymətləndirmək və təhlil etmək olar ki, bu da suallara cavab vermək deməkdir: “Layihə komandası layihənin məqsədlərini və əhatə dairəsini birmənalı başa düşə bilibmi?”, “Fəaliyyət planı kifayət qədər hazırlanıbmı?”, “Məhsul tələblərə cavab verirmi? təsdiq edilmiş spesifikasiya?", " Həll müştərinin ehtiyaclarına cavab verirmi? və s.

MSF proses modeli daim dəyişən layihə tələblərini nəzərə alır. O, ondan irəli gəlir ki, bir həllin inkişafı, 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 olmalıdı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ə inteqrasiya olunmuş yanaşma.

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

• konsepsiyanın inkişafı (Təxmin etmə);
• planlaşdırma (Planlaşdırma);
• inkişaf (inkişaf etmək);
• sabitləşmə (sabitləşdirici);
• həyata keçirmə (yerləşdirmə).

Bundan əlavə, layihənin gedişində müəyyən irəliləyişin əldə edildiyini göstərən və işin böyük seqmentlərini daha kiçik, müşahidə edilə bilən hissələrə ayıran çoxlu sayda ara mərhələlər var. Proses modelinin hər bir mərhələsi üçün MSF müəyyən edir:

• bu mərhələnin nəticəsi nədir (hansı əsərlər);
• rol klasterlərinin 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ı adətən iterativ şəkildə yaradılır. MSF sizə onun əsas funksionallığını qurmaq, sınaqdan keçirmək və tətbiq etməklə həlli inkişaf etdirməyə başlamağı tövsiyə edir. Sonra həllə getdikcə daha çox xüsusiyyət əlavə olunur. Bu strategiya versiya strategiyası adlanır. Kiçik layihələr üçün tək buraxılış kifayət ola bilsə də, bir həll üçün birdən çox versiya yaratmaq fürsətini qaçırmamağınız tövsiyə olunur. Yeni versiyaların yaradılması ilə həllin funksionallığı inkişaf edir.

İnkişaf prosesinə iterativ yanaşma çevik sənədlərin istifadəsini tələb edir. Son məhsula olan tələblərin dəyişməsi ilə birlikdə layihə inkişaf etdikcə canlı sənədlər dəyişməlidir. MSF məhsulun inkişafının hər bir mərhələsinin artefaktları 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əklif edir.

Həll həyata keçirilməyənə qədər onun biznes dəyəri yoxdur. Məhz bu səbəbdən MSF proses modeli həllin dəyər verməyə başladığı ana qədər onun həyata keçirilməsi də daxil olmaqla, həllin yaradılmasının bütün həyat dövrünü ehtiva edir.