Proqramın həyat dövrü: konsepsiya, standartlar, proseslər. Proqramın həyat dövrü. Bir proqram inkişaf etdirmə layihəsinin həyat dövrünün mərhələləri və mərhələləri

Həyat dövrü proqram təminatı(Proqram təminatı) - bir 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. Bu dövr proqram təminatının qurulması və inkişafı prosesidir.

Həyat dövrü mərhələləri:

2. Dizayn

3. İcra

4. Montaj, sınaq, sınaq

5. İcra (buraxılış)

6. Müşayiət

Proqram istehsalının 2 hadisəsi var: 1) Proqram müəyyən bir müştəri üçün hazırlanmışdır. Bu vəziyyətdə tətbiq olunan vəzifəni proqramçıya çevirməlisiniz. Avtomatlaşdırılması lazım olan mühitin (iş prosesinin təhlili) necə işlədiyini başa düşməlisiniz. Nəticədə, hansı sənədlərin dəqiq göstərilməli olduğu tələbin sənədləşdirilməsi göstərilir. və hansı şərtlərlə həll olunur. Bu işi sistem analitiki (iş prosesi analitiki) yerinə yetirir.

2) Proqram bazar üçün hazırlanmışdır. Həyata keçirmək lazımdır marketinq araşdırması və bazarda olmayan məhsulu tapın. Bu böyük bir risk ilə əlaqələndirilir. Məqsəd tələblər spesifikasiyası hazırlamaqdır.

Dizayn

Məqsəd - tərif ümumi quruluş(memarlıq) proqramı. Nəticə bir proqram xüsusiyyətidir. Sistem proqramçısı bu işi görür.

İcra

Proqram kodu yazmaq. Tətbiqə inkişaf, sınaq və sənədləşmə daxildir.

Montaj, sınaq, sınaq

Fərqli proqramçılar tərəfindən edilən hər şeyi toplamaq. Bütün proqram paketinin sınanması. Hata ayıklama - səhvlərin səbəblərini tapmaq və aradan qaldırmaq. Test - incəlik texniki xüsusiyyətlər... Nəticədə proqramın işləməsinə zəmanət verilir.

İcra (buraxılış)

İcra - bir müştəri üçün işlədikdə. Proqramı müştərinin yerində qurmaq, müştəriyə təlim vermək, məsləhət vermək, səhvləri və aşkar çatışmazlıqları aradan qaldırmaq daxildir. Proqram özgəninkiləşdirilməlidir - istifadəçi müəllifin iştirakı olmadan proqram təminatı ilə işləyə bilər.

Buraxılış - proqram bazar üçün hazırlandıqda. Beta test mərhələsi ilə başlayır. Müvafiq versiya - beta versiyası. Alfa testi, proqram inkişaf etdirilməsində iştirak etməyən eyni təşkilatdakı insanlar tərəfindən yoxlanılır. Beta testi - proqramın bir neçə nüsxəsini çıxarmaq və potensial müştərilərə göndərmək. Məqsəd, proqram inkişafını iki dəfə yoxlamaqdır.

Bazara kökündən yeni bir proqram çıxarılsa, bir neçə beta testi mümkündür. Beta testdən sonra - kommersiya versiyasının buraxılması.

Müşayiət

Əməliyyat zamanı aşkar edilən səhvlərin aradan qaldırılması. Kiçik təkmilləşdirmələr etmək. Növbəti versiyanın hazırlanması üçün təkliflərin toplanması.

Həyat dövrü modelləri

1. Şəlalə ("şəlalə", kaskad modeli)

2. Prototipləşdirmə

Birincisi, inkişaf etdirilən proqram məhsulunun özü deyil, inkişaf etdiricilərin qarşısında duran əsas problemlərin həllini ehtiva edən prototipidir. Prototip hazırlanması uğurla başa çatdıqdan sonra, əsl proqram məhsulu eyni prinsiplərə uyğun olaraq hazırlanır. Prototip, hazırlanmış proqrama olan tələbləri daha yaxşı anlamağa imkan verir. Müştəri prototipdən istifadə edərək öz tələblərini daha dəqiq ifadə edə bilər. Geliştirici, prototipdən istifadə edərək işinin ilkin nəticələrini müştəriyə təqdim etmək imkanına malikdir.

3. İterativ model

Tapşırıq alt tapşırıqlara bölünür və onların yerinə yetirilmə qaydası müəyyən edilir ki, hər sonrakı alt tapşırıq proqramın imkanlarını genişləndirsin. Müvəffəqiyyət, vəzifələrin alt tapşırıqlara nə qədər yaxşı bölünməsindən və sifarişin necə seçilməsindən asılıdır. Üstünlüklər: 1) müştərinin inkişafda fəal iştirak etmə imkanı, inkişaf zamanı tələblərini aydınlaşdırmaq imkanı var; 2) yeni işlənmiş hissələri əvvəllər hazırlanmış hissələrlə birlikdə sınaqdan keçirmək bacarığı, bu, kompleks ayıklama xərclərini azaldacaq; 3) inkişaf zamanı hissə -hissə tətbiqə başlaya bilərsiniz.

Annotasiya.

Giriş.

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

Giriş.

Riley Proqramlaşdırma Prosesinin Addımları

Giriş.

1.1.1. Problemin formalaşdırılması.

1.1.2. Həll dizaynı.

1.1.3. Alqoritm kodlaşdırma.

1.1.4. Proqramın saxlanılması.

1.1.5. Proqram sənədləri.

Maddə 1.1 -in nəticəsi

1.2. Lehmana görə ZHCPO tərifi.

Giriş.

1.2.1 Sistem tərifi.

1.2.2. İcra.

1.2.3. Xidmət.

1.2 -ci maddənin nəticəsi.

1.3. Boehm görə ZHCPO mərhələləri və işi

1.3.1. Şəlalə modeli.

1.3.2. İqtisadi əsaslandırma kaskad modeli.

1.3.3. Şəlalə modelinin təkmilləşdirilməsi.

1.3.4. Həyat dövrünün mərhələlərinin təyini.

1.3.5. Layihə üzrə əsas işlər.

Ədəbiyyat.

Giriş

Kompüterlərin sənaye istifadəsi və proqram təminatına artan tələbat əhəmiyyətli bir artım üçün təcili vəzifələr təyin etdi proqram inkişaf məhsuldarlığı, proqramların planlaşdırılması və dizaynı üçün sənaye üsullarının hazırlanması, təşkilati və texniki, texniki, iqtisadi və sosial-psixoloji texnikaların, nümunə və metodların maddi istehsal sahəsindən kompüterlərdən istifadə sahəsinə köçürülməsi. Kompleks yanaşma proqram təminatının hazırlanması, istismarı və saxlanılması prosesləri, proqramların dizaynında "darboğazları" aradan qaldıracaq, işlərin başa çatma müddətini azaldacaq, mövcud olanların seçilməsini və uyğunlaşdırılmasını yaxşılaşdıracaq bir sıra aktual problemləri ortaya qoydu. proqramları və bəlkə də, quraşdırılmış kompüterləri olan sistemlərin taleyini təyin edir.

Böyük proqram layihələri hazırlamaq praktikasında çox vaxt belə olmur vahid yanaşmaəmək xərclərinin qiymətləndirilməsinə, işin vaxtına və maddi xərclər proqram inkişaf məhsuldarlığının artmasına mane olan və nəticədə - səmərəli idarəetmə proqramın həyat dövrü. İstənilən növ proqram bir məhsula çevrildiyindən (bəlkə də təhsil proqramlı model proqramları istisna olmaqla), onun istehsalına yanaşma bir çox cəhətdən sənaye məhsullarının istehsalına yanaşmaya bənzəməlidir və proqramların tərtib edilməsi məsələləri son dərəcə vacib hala gəlir. . Bu fikir B.W. -nin mərkəzindədir. Bunu yazarkən istifadə etdiyimiz Boehm "Proqram Mühəndisliyi" müddətli kağız... Bu kitabda proqram dizaynı, bir proqram məhsulu dizaynının yaradılması prosesinə aiddir.

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

GİRİŞ

Həyat dövrü proqramı, proqram təminatının yaradılmasına ehtiyac barədə qərar verildiyi andan başlayaraq xidmətdən tamamilə çıxdığı anda bitən davamlı bir prosesdir.

Proqram ömrü (LCP) mərhələlərini və fəaliyyətlərini, proqramlaşdırma prosesinin addımlarını, şəlaləni və spiral modellərini müəyyən etmək üçün bir neçə yanaşma var. Ancaq hamısının ortaq əsas komponentləri var: problemin ifadəsi, həll dizaynı, tətbiqi, saxlanması.

Boehm görə, səkkiz mərhələdən ibarət olan həyat dövrü mərkəzinin quruluşu ən tanınmış və tamdır. Gələcəkdə daha ətraflı təqdim ediləcək.

Mümkün variantlardan biri, Lehmanna görə üç əsas mərhələni əhatə edən və ən ümumi halda həyatın həyat dövrünün təsvirini təqdim edən yuxarı səviyyənin təsviridir.

Və bir dəyişiklik üçün, - "Module -2 dilindən istifadə" kitabında D. Riley tərəfindən təqdim olunan proqramlaşdırma prosesinin addımlarını təqdim edirik. Bu fikir, mənim fikrimcə, çox sadə və tanışdır və bununla başlayacağıq.

1.1 Riley proqramlaşdırma prosesində addımlar

Giriş

Proqramlaşdırma prosesi dörd mərhələdən ibarətdir (Şəkil 1):

problem ifadəsi, yəni. proqramın hansı vəzifəni yerinə yetirməli olduğu barədə adekvat fikir əldə etmək;

artıq qoyulmuş bir problemə bir həll hazırlamaq (ümumiyyətlə, belə bir həll son proqramdan daha az formaldır);

proqramı kodlaşdırmaq, yəni dizayn edilmiş həllini maşında icra edilə bilən bir proqrama çevirmək;

proqramın saxlanması, yəni. proqramdakı problemləri həll etmək və yeni xüsusiyyətlər əlavə etmək üçün davam edən bir proses.

Pirinç. 1. Proqramlaşdırmanın dörd mərhələsi.

Proqramlaşdırma başladığı andan başlayır istifadəçi yəni problemi həll etmək üçün proqrama ehtiyacı olan biri problemi təqdim edir sistem analitiki.İstifadəçi və sistem analitiki problemin ifadəsini birlikdə müəyyənləşdirirlər. Sonuncu ötürülür alqoritmçi həllini hazırlamaqdan kim məsuldur. Bir həll (və ya alqoritm) bir problemin həllinə səbəb olan əməliyyatların ardıcıllığını təmsil edir. Alqoritm çox vaxt maşın tərəfindən oxunmadığı üçün maşın proqramına çevrilməlidir. Bu əməliyyat kodlayıcı tərəfindən həyata keçirilir. Proqramdakı sonrakı dəyişikliklərə nəzarətçi cavabdehdir. proqramçı. Sistem analitiki, alqoritmist, kodlayıcı və müşayiət edən proqramçı hamısı proqramçıdır.

Böyük bir proqram layihəsi halında istifadəçilərin, sistem analitiklərinin və alqoritmlərin sayı əhəmiyyətli ola bilər. Bundan əlavə, gözlənilməz hallar səbəbindən əvvəlki addımlara qayıtmaq lazım ola bilər. Bütün bunlar diqqətli bir proqram dizaynı üçün arqument əlavə edir: hər addımın nəticələri tam, dəqiq və başa düşülən olmalıdır.

1.1.1 Problemin ifadəsi

Proqramlaşdırmada ən vacib addımlardan biri problemin ifadəsidir. İstifadəçi ilə proqramçı (lar) arasında müqavilə kimi xidmət edir. Qanuni olaraq pis yazılmış bir müqavilə kimi, pis hədəf almaq faydasızdır. Vəzifənin yaxşı tərtib edilməsi ilə həm istifadəçi, həm də proqramçı yerinə yetirilməsi lazım olan vəzifəni aydın və birmənalı şəkildə təmsil edir, yəni. bu zaman həm istifadəçinin, həm də proqramçının maraqları nəzərə alınır. İstifadəçi, əldə etdiyi biliklərə əsaslanaraq hələ yaradılmamış bir proqramdan istifadə etməyi planlaşdıra bilər. Problemin yaxşı tərtib edilməsi onun həllinin formalaşması üçün əsas kimi xidmət edir.

Problemin formalaşdırılması (proqram spesifikasiyası); əslində müəyyən bir proqram icra edildikdə baş verənlərin dəqiq, tam və başa düşülən təsviri deməkdir. İstifadəçi ümumiyyətlə kompüterə sanki qara qutu kimi baxır: onun üçün kompüterin necə işləməsinin əhəmiyyəti yoxdur, amma vacib olan kompüterin istifadəçini maraqlandıran nə edə biləcəyidir. Bu vəziyyətdə əsas diqqət bir insanın maşınla qarşılıqlı əlaqəsinə yönəldilir.

Yaxşı bir tapşırıq ifadəsinin xüsusiyyətləri:

Dəqiqlik yəni hər hansı bir qeyri -müəyyənliyin aradan qaldırılması. Verilən hər hansı bir giriş üçün proqramın çıxışının nə olacağına dair heç bir sual olmamalıdır.

Tamlıq yəni səhv və ya gözlənilməz giriş daxil olmaqla, müəyyən bir giriş üçün bütün variantları nəzərdən keçirmək və uyğun çıxışı təyin etmək.

Aydınlıq yəni həm istifadəçi, həm də sistem analitiki üçün aydın olmalıdır, çünki problemin açıqlanması aralarındakı yeganə müqavilədir.

Çox vaxt dəqiqlik, tamlıq və aydınlıq tələbi ziddiyyət təşkil edir. Belə ki, bir çox hüquqi sənədləri müəyyən bir müddəanı son dərəcə dəqiq formada tərtib etməyə imkan verən rəsmi dildə yazıldığına görə başa düşmək çətindir, kiçik fərqlər istisna olmaqla. Məsələn, imtahan biletlərindəki bəzi suallar bəzən o qədər dəqiqdir ki, tələbə bu suala cavab verməkdən daha çox onu başa düşməyə vaxt ayırır. Üstəlik, şagird çoxlu detallara görə sualın əsas mənasını heç cür başa düşə bilməz. Problemin ən yaxşı formulu, hər üç tələbin tarazlığına nail olmaqdır.

Problem ifadəsinin standart forması.

Aşağıdakı problem ifadəsini nəzərdən keçirin: "Üç ədəd daxil edin və nömrələri sırayla çıxarın."

Bu tərif yuxarıdakı tələblərə cavab vermir: nə dəqiq, nə tam, nə də başa düşüləndir. Doğrudan da, nömrələr hər sətirdə bir və ya bütün sətirlər bir sətirdə daxil edilməlidirmi? "Sifarişlə" ifadəsi ən yüksəkdən aşağıya, ən aşağıdan ən yuxarıya və ya təqdim edildikləri eyni sıraya aiddir.

Aydındır ki, belə bir tərif bir çox suala cavab vermir. Bütün sualların cavablarını nəzərə alsaq, problemin ifadəsi sözsüz olacaq və başa düşülməsi çətin olacaq. Buna görə də D. Riley, problemi həll etmək üçün maksimum dəqiqlik, tamlıq, aydınlıq təmin edən və aşağıdakıları ehtiva edən standart bir formadan istifadə etməyi təklif edir.

tapşırıq adı (sxematik tərif);

ümumi təsviri(problemin xülasəsi);

səhvlər (istifadəçilərə və proqramçılara maşının belə vəziyyətlərdə nə edəcəyini göstərmək üçün qeyri -adi giriş variantları açıq şəkildə verilmişdir);

nümunə ( yaxşı nümunə problemin mahiyyətini çatdıra bilər, həm də müxtəlif halları təsvir edə bilər).

Misal. Problemin standart formada verilməsi.

TITLE

Üç tam ədədin çeşidlənməsi.

TƏSVİRİ

Ən aşağıdan yuxarıya qədər sıralanan üç tamsayı giriş və çıxış.

Satır başına bir ədəd olmaqla üç tam ədəd daxil edilir. Bu vəziyyətdə, tam ədəd bir və ya daha çox ardıcıl ondalık rəqəmdir və bunun önünə "+" işarəsi və ya "-" işarəsi qoyula bilər.

Daxil edilmiş üç tam ədəd göstərilir, hər üçü eyni sətirdə göstərilir. Bitişik ədədləri boşluqla ayırın. Nömrələr aşağıdan yuxarıya, soldan sağa göstərilir.

1) Üçdən az rəqəm daxil edildikdə, proqram əlavə girişi gözləyir.

2) İlk üçdən başqa giriş xətləri nəzərə alınmır.

3) Əgər ilk üç sətirdən hər hansı biri birdən çox tamsayı ehtiva edirsə, proqram çıxır və mesajı göstərir.

Annotasiya.

Giriş.

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

Giriş.

Riley Proqramlaşdırma Prosesinin Addımları

Giriş.

1.1.1. Problemin formalaşdırılması.

1.1.2. Həll dizaynı.

1.1.3. Alqoritm kodlaşdırma.

1.1.4. Proqramın saxlanılması.

1.1.5. Proqram sənədləri.

Maddə 1.1 -in nəticəsi

1.2. Lehmana görə ZHCPO tərifi.

Giriş.

1.2.1 Sistem tərifi.

1.2.2. İcra.

1.2.3. Xidmət.

1.2 -ci maddənin nəticəsi.

1.3. Boehm görə ZHCPO mərhələləri və işi

1.3.1. Şəlalə modeli.

1.3.2. Şəlalə modelinin iqtisadi əsaslandırılması.

1.3.3. Şəlalə modelinin təkmilləşdirilməsi.

1.3.4. Həyat dövrünün mərhələlərinin təyin edilməsi.

1.3.5. Layihə üzrə əsas işlər.

Ədəbiyyat.

Giriş

Kompüterlərin sənaye istifadəsi və proqram təminatına artan tələbat, əhəmiyyətli bir artımın təcili vəzifələrini təyin etdi proqram inkişaf məhsuldarlığı, proqramların planlaşdırılması və dizaynı üçün sənaye üsullarının inkişafı, təşkilati-texniki, texniki, iqtisadi və sosial-psixoloji texnikaların, nümunə və metodların maddi istehsal sahəsindən kompüterlərdən istifadə sahəsinə köçürülməsi. Kompleks yanaşma proqram təminatının hazırlanması, istismarı və saxlanılması prosesləri, proqramların dizaynında "darboğazları" aradan qaldıracaq, işlərin başa çatma müddətini azaldacaq, mövcud olanların seçilməsini və uyğunlaşmasını yaxşılaşdıracaq bir çox aktual problemləri ortaya qoydu. proqramları, və bəlkə də əlaqədar kompüterləri olan sistemlərin taleyini təyin edir.

Böyük proqram layihələri hazırlamaq praktikasında çox vaxt yoxdur vahid yanaşma proqram inkişaf məhsuldarlığının artmasına mane olan əmək xərclərinin, işin vaxtının və maddi xərclərin qiymətləndirilməsinə və nəticədə - proqram ömrünün səmərəli idarə olunmasına. İstənilən növ proqram bir məhsula çevrildiyindən (bəlkə də təhsil proqramlı model proqramları istisna olmaqla), onun istehsalına yanaşma bir çox cəhətdən sənaye məhsullarının istehsalına yanaşmaya bənzəməlidir və proqramların tərtib edilməsi məsələləri son dərəcə vacib hala gəlir. . Bu fikir B.W. -nin qəlbindədir. Bu müddətli yazını yazarkən istifadə etdiyimiz Boehm "Proqram Mühəndisliyi". Bu kitabda proqram dizaynı, bir proqram məhsulu dizaynının yaradılması prosesinə aiddir.

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

GİRİŞ

Həyat dövrü proqramı, proqram təminatının yaradılmasına ehtiyac barədə qərar verildiyi andan başlayaraq xidmətdən tamamilə çıxdığı anda bitən davamlı bir prosesdir.

Boehm görə, səkkiz mərhələdən ibarət olan həyat dövrü mərkəzinin quruluşu ən tanınmış və tamdır. Gələcəkdə daha ətraflı təqdim ediləcək.

Mümkün variantlardan biri, Lehmanna görə üç əsas mərhələni əhatə edən və ən ümumi halda həyatın həyat dövrünün təsvirini təqdim edən yuxarı səviyyənin təsviridir.

1.1 Riley proqramlaşdırma prosesində addımlar

Proqramlaşdırma prosesi dörd mərhələdən ibarətdir (Şəkil 1):

problem ifadəsi, yəni. proqramın hansı vəzifəni yerinə yetirməli olduğu barədə adekvat fikir əldə etmək;

artıq qoyulmuş bir problemə bir həll hazırlamaq (ümumiyyətlə, belə bir həll son proqramdan daha az formaldır);

proqramı kodlaşdırmaq, yəni dizayn edilmiş həllini maşında icra edilə bilən bir proqrama çevirmək;

proqramın saxlanması, yəni. proqramdakı problemləri həll etmək və yeni xüsusiyyətlər əlavə etmək üçün davam edən bir proses.

Pirinç. 1. Proqramlaşdırmanın dörd mərhələsi.

Proqramlaşdırma başladığı andan başlayır istifadəçi yəni problemi həll etmək üçün proqrama ehtiyacı olan biri problemi təqdim edir sistem analitiki.İstifadəçi və sistem analitiki problemin ifadəsini birlikdə müəyyənləşdirirlər. Sonuncu ötürülür alqoritmçi həllini hazırlamaqdan kim məsuldur. Bir həll (və ya alqoritm) bir problemin həllinə səbəb olan əməliyyatların ardıcıllığını təmsil edir. Alqoritm çox vaxt maşın tərəfindən oxunmadığı üçün maşın proqramına çevrilməlidir. Bu əməliyyat kodlayıcı tərəfindən həyata keçirilir. Proqramdakı sonrakı dəyişikliklərə nəzarətçi cavabdehdir. Sistem analitiki, alqoritmist, kodlayıcı və müşayiət edən proqramçı hamısı proqramçıdır.

1.1.1 Problemin ifadəsi

Yaxşı bir tapşırıq ifadəsinin xüsusiyyətləri:

Dəqiqlik yəni hər hansı bir qeyri -müəyyənliyin aradan qaldırılması. Verilən hər hansı bir giriş üçün proqramın nə olacağına dair heç bir sual olmamalıdır.

Tamlıq yəni səhv və ya gözlənilməz giriş daxil olmaqla, müəyyən bir giriş üçün bütün variantları nəzərdən keçirmək və uyğun çıxışı təyin etmək.

Aydınlıq yəni həm istifadəçi, həm də sistem analitiki üçün aydın olmalıdır, çünki problemin açıqlanması aralarındakı yeganə müqavilədir.

Çox vaxt dəqiqlik, tamlıq və aydınlıq tələbi ziddiyyət təşkil edir. Məsələn, bir çox hüquqi sənədlər, kiçik fərqlər istisna olmaqla, müəyyən müddəaların ən dəqiq tərtib edilməsinə imkan verən rəsmi bir dildə yazıldığı üçün başa düşülməsi çətindir. Məsələn, imtahan biletlərindəki bəzi suallar bəzən o qədər dəqiqdir ki, tələbə bu suala cavab verməkdən daha çox onu başa düşməyə vaxt ayırır. Üstəlik, şagird çoxlu detallara görə sualın əsas mənasını heç cür başa düşə bilməz. Problemin ən yaxşı formulu, hər üç tələbin tarazlığına nail olmaqdır.

Problem ifadəsinin standart forması.

Aşağıdakı problem ifadəsini nəzərdən keçirin: "Üç ədəd daxil edin və nömrələri sırayla çıxarın."

Bu tərif yuxarıdakı tələblərə cavab vermir: nə dəqiq, nə tam, nə də başa düşüləndir. Həqiqətən, nömrələr hər sətirdə bir və ya bütün sətirlər bir sətirdə daxil edilməlidirmi? "Sifarişlə" ifadəsi ən yüksəkdən aşağıya, ən aşağıdan ən yuxarıya və ya təqdim edildikləri eyni sıraya aiddir.

Aydındır ki, belə bir tərif bir çox suala cavab vermir. Bütün sualların cavablarını nəzərə alsaq, problemin ifadəsi sözlü və anlaşılmaz olacaq. Buna görə də D. Riley, problemi həll etmək üçün maksimum dəqiqlik, tamlıq, aydınlıq təmin edən və aşağıdakıları ehtiva edən standart bir formadan istifadə etməyi təklif edir.

tapşırıq adı (sxematik tərif);

ümumi təsvir (problemin qısa ifadəsi);

səhvlər (istifadəçilərə və proqramçılara maşının belə vəziyyətlərdə nə edəcəyini göstərmək üçün qeyri -adi giriş variantları açıq şəkildə verilmişdir);

nümunə (yaxşı bir nümunə, problemin mahiyyətini çatdıra bilər, həm də müxtəlif halları göstərə bilər).

Misal. Problemin standart formada verilməsi.

TITLE

Üç tam ədədin çeşidlənməsi.

TƏSVİRİ

Ən aşağıdan ən yuxarıya doğru sıralanan üç tam ədədin giriş və çıxışı.

Satır başına bir ədəd olmaqla üç tam ədəd daxil edilir. Bu halda, tam ədəd bir və ya daha çox ardıcıl ondalık rəqəmdir və onların önünə "+" işarəsi və ya "-" işarəsi qoyula bilər.

Daxil edilmiş üç tam ədəd göstərilir, hər üçü eyni sətirdə göstərilir. Bitişik ədədləri boşluqla ayırın. Nömrələr aşağıdan yuxarıya, soldan sağa göstərilir.

1) Üçdən az rəqəm daxil edildikdə, proqram əlavə girişi gözləyir.

Mövzu: Klassik və Çevik Ömrü Modelləri: Tərifi, Təsviri, fərqləndirici xüsusiyyətlər, mərhələlərin ardıcıllığı. Müxtəlif mövzu sahələrində proqram təminatının inkişafında həyat dövrü modelini seçmək üsulları.

Məlumat mənbəyi https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297

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, müəyyən bir həyat dövrü modeli və proqram inkişaf etdirmə üsulları təklif 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 proqramın 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:

proqram tələblərinin formalaşdırılması;
dizayn (sistem layihəsinin hazırlanması);
həyata keçirilməsi (alt mərhələlərə bölünə bilər: ətraflı dizayn, kodlaşdırma);
test (müstəqil və bölünə bilər kompleks sınaq və inteqrasiya);
istismara verilməsi (həyata keçirilməsi);
istismar və texniki xidmət;
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 müqavilələr də 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.

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.
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ış bir 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 bir 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 təşkilatın fəaliyyətinin tam funksional və məlumat modelini, habelə (zərurət olduqda) təşkilatın davranış dinamikasını təsvir edən bir modeli ehtiva etməlidir. Qeyd edək ki, tikilmiş modellər müstəqildir praktik əhəmiyyəti müəssisənin bir məlumat sistemi hazırlayıb 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, onların tamlığı, sınaqdan keçirilə bilmə 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.

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ınaqdan keçirilə bilənliyi və məqsədəuyğunluğu təsdiq edilmişdir.
Ə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;
fiziki və formalaşması məntiqi quruluşlar fərdi sahələr səviyyəsinə qədər məlumatlar;
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 tamamlanması, layihənin sona çatması və ya kritik blok analizidir.

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

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 xüsusiyyətlər aşağıdakı məlumatları ehtiva etməlidir:
- 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ı və ya funksiyaları müəyyən edir;
- 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.).
Modulların məntiqinin və proqramlaşdırma (kodlaşdırma) modullarının dizaynı.
Modulların düzgünlüyünün yoxlanılması.
Test modulları.
Verilənlər bazasının fərdi parametrlər, simvollar və bitlər səviyyəsinə qədər təsviri.
Qəbul imtahanı planı.
İstifadəçi kitabçası.
İ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.

Pirinç. 2

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 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 (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üzgünlüyüdür. Yaradıcıların əsas diqqəti inkişaf etmiş proqram sisteminin texniki xüsusiyyətlərinin optimal dəyərlərinə - performansa, tutulan yaddaşın miqdarına 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.

mənfi cəhətləri 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ü PS -nin, aralıq nəzarətli və ya fazaların dövri təkrarlanan modeli adlandırılan iterativ modeli belə ortaya çıxdı.

Pirinç. 3.

Təkrarlanan 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.

Pirinç. 4.

Belə bir vəziyyətdə tələblərin formalaşdırılması, spesifikasiyaların hazırlanması 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.

Kağız maketi (insan-maşın dialoqunun əllə tərtib edilmiş diaqramı) və ya PC əsaslı maket.
Lazımi funksiyaları yerinə yetirən bir iş düzeni.
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.

Pirinç. 5.

Prototipləmə zamanı edilən hərəkətlərin 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əyən 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.

Pirinç. 6.

Digər tərəfdən, bir işçi tez bir iş planı əldə etmək üçün tez-tez müəyyən güzəştlə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, növbəti versiya əlavə funksiyaları yerinə yetirir və s.
təkamül strategiyası. Sistem eyni zamanda bir sıra versiyalarda qurulmuşdur, lakin prosesin əvvəlində bütün tələblər müəyyən edilməmişdir. Tələblər versiya nəticəsində dəqiqləş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).

Pirinç. 7.

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) yeni bir elementin əlavə edildiyi klassik həyat dövrü və prototipin ən yaxşı xüsusiyyətlərinə əsaslanır - bu paradiqmalarda olmayan risk təhlili. Model, spiralin dörd kvadrantı ilə təmsil olunan dörd hərəkəti təyin edir.

Pirinç. səkkiz.

Planlaşdırma - məqsədləri, variantları və məhdudiyyətləri müəyyənləşdirmək.
Risk təhlili - variantların təhlili və riskin tanınması / seçilməsi.
Mühəndislik məhsul inkişafının növbəti səviyyəsidir.
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 bir 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:

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

Ləyaqət spiral modeli:

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

mənfi cəhətləri 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. Həqiqətən də ə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. Vahid Modelləşdirmə Dili (UML) ümumi məlumat bazasında modelləşdirmə dili olaraq istifadə olunur. RUP -də təkrarlanan və artan proqram inkişafı, bir layihənin ardıcıl olaraq icra edilən bir çox 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; İnkiş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 bir 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.

Pirinç. doqquz

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

Başlanğıc - bir layihə konsepsiyasının formalaşdırılması, yaratdıqlarımızı anlamaq, bir məhsula baxış, 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.
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 layihə.
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.
İcra, yerləşdirmə (Keçid). Məhsulun son versiyasının yaradılması. Məhsulun təqdimat 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.

Biznes analizi və modelləşdirmə (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ə onların 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.
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 təyin edən və sistemin nə etməli olduğuna dair gözləntiləri detallandıran bir sıra tələblərə çevirməkdən ibarətdir.
Analiz və dizayn, tələblərin necə yerinə yetirilməsini əks etdirən aralıq təsvirlərə (modellərə) çevrilmə prosedurlarını əhatə edir.
İcra, kodun inkişaf etdirilməsini, geliştirici səviyyəsində sınaqdan keçirilməsini və müəyyən edilmiş xüsusiyyətlərə uyğun olaraq komponentlərin, alt sistemlərin və bütün sistemin inteqrasiyasını əhatə edir.
Test (Test) yaradılan məhsulun keyfiyyətinin qiymətləndirilməsinə həsr edilmişdir.
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.
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.
Layihə İdarəçiliyi (İdarəetmə) layihə planlaşdırma, risklərin idarə edilməsi, gedişatın monitorinqi və əsas göstəricilərin davamlı qiymətləndirilməsinə həsr olunmuşdur.
Ətraf mühitin idarə edilməsi (Ətraf mühit) bir informasiya sistemi 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 artefaktlar, presedentlər və rollardan 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 bir və ya digər mərhələdə inkişaf qrupunun hər bir üzvünün məsuliyyətlərini - rollarını, yəni bu və ya digər əsərləri nə vaxt və kim yaratmalı olduğunu açıq şəkildə müəyyənləşdirir. 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 kod elementləri yaratmaq qabiliyyətinə malik olan informasiya sistemləri. 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 istənilən mərhələsində baş verən dəyişikliklər 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əsi;
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 - test 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 performansında darboğazların aşkarlanmasına və aradan qaldırılmasına 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 etdirmə ö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 yaratmaq üçü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ı özündə 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 və inkişaf etdiricilərə J2EE inkişaf etdirmək imkanı verir. 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, Microsoftun proqram təminatının hazırlanması və saxlanması üçün böyük layihələr üzərində işləyərkən qazandığı 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 iki qarşılıqlı əlaqəli və bir-birini tamamlayan bilik sahələri şəklində təqdim olunur: Microsoft Solutions Framework (MSF) və Microsoft Operations Framework (MOF).

Qeyd etmək lazımdır ki, Microsoft tətbiqi 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ə üsulları ü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 olunan İT İ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, dizayn qruplarına həllin iş dəyərinə diqqət yetirməyə 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əll yolu ilə 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 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ı adətən 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 çevik bir yol 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əklif 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, həyata keçirilməsi də daxil olmaqla, bir həllin bütün həyat dövrü var.

Proqram ömrü (proqram ömrü) anlayışı, proqram mühəndisliyindəki əsas anlayışlardan biridir. Həyat dövrü proqram təminatının yaradılmasına ehtiyac barədə qərar verildiyi andan başlayaraq xidmətdən tamamilə çıxdığı anda bitən müddətdir.

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

Altında həyat dövrü modeli Proqram, ömrü boyu proseslərin, hərəkətlərin və vəzifələrin ardıcıllığını və əlaqəsini təyin edən bir quruluş kimi başa düşülür. 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. Proqramın ömrü ümumiyyətlə aşağıdakı mərhələləri əhatə edir:

1. Proqram təminatı tələblərinin formalaşdırılması.

2. Dizayn.

3. İcra.

4. Test.

5. İstismara verilməsi.

6. İstismar və texniki xidmət.

7. İstismardan çıxarılması.

Hal -hazırda, proqram həyat dövrünün aşağıdakı əsas modelləri ən çox istifadə olunur:

a) kaskad və

b) spiral (təkamül).

Birincisi, vahid bir bütöv olan kiçik proqramlar üçün istifadə edilmişdir. Əsas xüsusiyyət şəlalə yanaşması Növbəti mərhələyə keçid yalnız hazırkı iş tamamlandıqdan sonra həyata keçirilir və keçmiş mərhələlərə qayıtma yoxdur. Onun diaqramı Şəkildə göstərilmişdir. 2.2.

Şəlalə modelinin istifadəsinin üstünlükləri aşağıdakılardır:

Hər mərhələdə layihə sənədlərinin tam dəsti formalaşır;

Görülən işlərin mərhələləri başa çatma tarixini və müvafiq xərcləri planlaşdırmağa imkan verir.

Bu model, inkişafın əvvəlində bütün tələblərin dəqiq tərtib edilə biləcəyi sistemlər üçün istifadə olunur. Bunlara, məsələn, əsasən hesablama tipli problemlərin həll edildiyi sistemlər daxildir. Real proseslər ümumiyyətlə iterativ xarakter daşıyır: sonrakı mərhələnin nəticələri çox vaxt əvvəlki mərhələlərdə hazırlanmış dizayn həllərində dəyişikliklərə səbəb olur. Beləliklə, daha çox yayılmış model Şəkildə göstərilmiş aralıq nəzarətdir. 2.3.

Kaskad yanaşmasının əsas çatışmazlığı, nəticələrin əldə edilməsində əhəmiyyətli bir gecikmə və nəticədə istifadəçilərin dəyişmiş ehtiyaclarını ödəməyən bir sistem yaratmaq riskinin yüksək olmasıdır.

Bu problemlər bu sahədə həll olunur spiral həyat dövrü modeli (şəkil 2.4). Onun əsas xüsusiyyəti, tətbiq proqramının şəlalə yanaşmasında olduğu kimi dərhal deyil, metoddan istifadə edərək hissə -hissə yaradılmasıdır. prototipləşdirmə ... Prototip, fərdi funksiyaları və inkişaf etdirilən proqramın xarici interfeysini həyata keçirən əməliyyat proqramı komponenti kimi başa düşülür. Prototipləşdirmə bir neçə dəfə - spiral döngələrində aparılır.

Şəlalə (təkamül) modeli Şəkil 2.5 -də göstərilən bir diaqram şəklində təqdim edilə bilər.

Spiral həyat dövrü modelinin tətbiqinin nəticələrindən biri də sözdə geniş istifadə olunan üsuldur sürətli tətbiq inkişafı və ya RAD (Sürətli Tətbiq İnkişafı). Bu üsula görə, proqram ömrü dörd mərhələdən ibarətdir:

1) tələblərin təhlili və planlaşdırılması;

2) dizayn;

3) həyata keçirilməsi;

4) həyata keçirilməsi.

Proqramların həyat dövrünün təhlili, məzmununu aydınlaşdırmağa və kompleks sistemlərin dizaynı üçün aşağıdakı prosesləri vurğulamağa imkan verir.

1) Strategiya;

2) təhlil;

3) Dizayn;

4) İcra;

5) Test;

6) İcra;

7) Əməliyyat və texniki dəstək.

Strategiya

Strategiyanın müəyyən edilməsi sistemin araşdırılmasını nəzərdə tutur. Sorğunun əsas vəzifəsi layihənin real əhatə dairəsini, məqsəd və vəzifələrini qiymətləndirmək, həmçinin yüksək səviyyədə qurum və funksiyaların təriflərini əldə etməkdir. Bu mərhələdə, firmanın idarəçiliyinə daimi daxil olan yüksək ixtisaslı iş analitikləri cəlb olunur. Bundan əlavə, sistemin əsas istifadəçiləri və biznes mütəxəssisləri ilə sıx qarşılıqlı əlaqə gözlənilir. Bu cür qarşılıqlı əlaqənin əsas vəzifəsi, sistem haqqında mümkün qədər tam məlumat əldə etmək, müştərinin tələblərini birmənalı şəkildə başa düşmək və rəsmi şəkildə alınan məlumatları sistem analitiklərinə ötürməkdir. Tipik olaraq, sistem haqqında məlumatı rəhbərliklə, mütəxəssislərlə və istifadəçilərlə bir sıra söhbətlərdən (və ya seminarlardan) əldə etmək olar.

Strategiyanın müəyyənləşdirilməsi mərhələsinin nəticəsi, aşağıdakıların açıq şəkildə ifadə edildiyi bir sənəddir:

Müştərinin layihəni maliyyələşdirməyə razı olduğu təqdirdə nə etməli;

Hazır məhsulu nə vaxt ala biləcək (iş qrafiki);

Ona nə qədər başa gələcək (böyük layihələr üçün iş mərhələlərinin maliyyələşdirilməsi cədvəli).

Sənəd yalnız xərcləri deyil, həm də faydaları əks etdirməlidir, məsələn, layihənin geri qaytarılma müddəti, gözlənilən iqtisadi effekt (əgər təxmin edilə bilərsə).

Proqram həyat dövrünün nəzərdən keçirilmiş mərhələsi, xüsusən də modelin dövri quruluşa malik olması halında, modeldə yalnız bir dəfə təmsil oluna bilər. Bu, tsiklik modellərdə o demək deyil strateji planlaşdırma birdəfəlik istehsal olunur. Bu cür modellərdə strategiya və təhlili müəyyən etmək mərhələləri bir araya gətirilir və onların ayrılması yalnız müəssisə rəhbərliyinin qəbul etdiyi ilk mərhələdə mövcuddur. prinsipial qərar layihənin başlaması haqqında. Ümumiyyətlə, strateji mərhələ müəssisə idarəçiliyi səviyyəsində bir sənədin hazırlanmasına həsr olunmuşdur.

Təhlil mərhələsi iş proseslərinin (əvvəlki mərhələdə müəyyən edilmiş funksiyalar) və onların həyata keçirilməsi üçün lazım olan məlumatların (qurumlar, atributları və əlaqələri (əlaqələri)) ətraflı öyrənilməsini əhatə edir. Bu mərhələ məlumat modelini təmin edir və növbəti dizayn mərhələsi məlumat modelidir.

Strategiyanın müəyyənləşdirilməsi mərhələsində toplanan sistem haqqında bütün məlumatlar təhlil mərhələsində rəsmiləşdirilir və təmizlənir. Alınan məlumatların tamlığına, ardıcıllığının təhlilinə, həmçinin istifadə olunmamış və ya təkrarlanan məlumatların axtarışına xüsusi diqqət yetirilir. Bir qayda olaraq, müştəri ilk növbədə sistem üçün deyil, ayrı -ayrı komponentləri üçün tələblər formalaşdırır. Və bu vəziyyətdə, proqram ömrü dövrünün tsiklik modelləri üstünlük qazanır, çünki zaman keçdikcə çox güman ki, tələb olunacaq yenidən analiz Müştərinin iştahı tez -tez yeməklə gəlir. Eyni mərhələdə test planının zəruri komponentləri müəyyən edilir.

Analitiklər məlumatları bir -biri ilə əlaqəli iki formada toplayır və qeyd edirlər:

a) funksiyalar - işdə baş verən hadisələr və proseslər haqqında məlumat;

b) varlıqlar - təşkilata aid olan və bir şeyin məlum olduğu maddələr haqqında məlumatlar.

Eyni zamanda, sistemin dinamikasını təsvir edən komponentlərin, məlumat axınının və həyat dövrlərinin diaqramları qurulur. Onlar daha sonra müzakirə olunacaq.

Dizayn

Dizayn mərhələsində bir məlumat modeli formalaşır. Dizaynerlər analiz məlumatlarını emal edirlər. Dizayn mərhələsinin son məhsulu bir verilənlər bazası sxemidir (layihədə varsa) və ya bir məlumat anbarı sxemi (ER modeli) və bir sıra sistem modulu spesifikasiyaları (funksiya modeli).

Kiçik bir layihədə (məsələn, kurs layihəsində) eyni insanlar analitik, dizayner və inkişaf etdirici kimi çıxış edə bilərlər. Yuxarıda sadalanan sxemlər və modellər, məsələn, ümumiyyətlə təsvir olunmamış, qeyri -müəyyən şəkildə təsvir edilmiş, ziddiyyətli təsvir edilmiş sistem komponentlərini və potensial səhvlərin qarşısını almağa kömək edən digər çatışmazlıqları tapmağa kömək edir.

Bütün spesifikasiyalar çox dəqiq olmalıdır. İnkişafın bu mərhələsində sistem test planı da tamamlanır. Bir çox layihədə dizayn mərhələsinin nəticələri tək bir sənəddə - sözdə texniki spesifikasiyada sənədləşdirilir. Eyni zamanda, UML dili daha az təfərrüatlı analiz sənədlərini (istehlakçıları istehsal menecerləridir) və dizayn sənədlərini (istehlakçıları inkişaf və test qruplarının menecerləridir) eyni vaxtda əldə etməyə imkan verən geniş yayılmışdır. Bu dil daha sonra müzakirə olunacaq. UML istifadə edərək qurulmuş proqram, kodun yaradılmasını asanlaşdırır - ən azından sinif iyerarxiyası, həm də metodların (prosedur və funksiyaların) özünün bəzi hissələri.

Dizayn vəzifələri bunlardır:

Təhlil nəticələrinin nəzərdən keçirilməsi və tamlığının yoxlanılması;

Müştəri ilə seminar;

Layihənin kritik sahələrinin müəyyən edilməsi və məhdudiyyətlərinin qiymətləndirilməsi;

Sistem quruluşunun təyin edilməsi;

Üçüncü tərəf məhsullarının istifadəsi, habelə bu məhsullarla inteqrasiya üsulları və məlumat mübadiləsi mexanizmləri haqqında qərar qəbul etmək;

Məlumat anbarı dizaynı: verilənlər bazası modeli;

Proses və kod dizaynı: inkişaf vasitələrinin son seçimi, proqram interfeyslərinin tərifi, sistem funksiyalarının modullarına uyğunlaşdırılması və modul xüsusiyyətlərinin təyin edilməsi;

Test prosesi üçün tələblərin müəyyən edilməsi;

Sistem təhlükəsizlik tələblərinin müəyyən edilməsi.

İcra

Bir layihəni həyata keçirərkən, inkişaf qruplarını koordinasiya etmək xüsusilə vacibdir. Bütün inkişaf etdiricilər ciddi mənbə nəzarət qaydalarına riayət etməlidirlər. Texniki bir layihə aldıqdan sonra modul kodu yazmağa başlayırlar. İnkişaf etdiricilərin əsas vəzifəsi spesifikasiyanı başa düşməkdir: dizayner nə edilməli olduğunu yazdı və inkişaf etdirici bunu necə edəcəyini müəyyənləşdirdi.

İnkişaf mərhələsində dizaynerlər, inkişaf etdiricilər və sınaq qrupları arasında sıx qarşılıqlı əlaqə var. İntensiv inkişaf halında, test cihazı, inkişaf etdirmə qrupunun üzvü olaraq, inkişaf etdiricidən ayrılmazdır.

Çox vaxt istifadəçi interfeysi inkişaf mərhələsində dəyişir. Bu, modulların müştəriyə vaxtaşırı nümayiş etdirilməsi ilə əlaqədardır. Məlumat sorğularını da əhəmiyyətli dərəcədə dəyişə bilər.

İnkişaf mərhələsi test mərhələsi ilə əlaqələndirilir və hər iki proses paralel olaraq aparılır. Hata izləmə sistemi, sınaqçıların və inkişaf etdiricilərin hərəkətlərini sinxronlaşdırır.

Səhvlər prioritetə görə təsnif edilməlidir. Hər bir səhv sinfi üçün hərəkətlərin aydın bir quruluşu müəyyən edilməlidir: "nə etməli", "nə qədər təcili", "nəticəyə kim cavabdehdir". Hər bir problem, onu həll etməkdən məsul bir dizayner / geliştirici / sınaqçı tərəfindən izlənilməlidir. Eyni şey, planlaşdırma müddətinin və sınaq üçün modulların təqdim edilməsinin pozulduğu vəziyyətlərə də aiddir.

Əlavə olaraq, modulların yığılması zamanı istifadə olunan hazır layihə modullarının və kitabxanaların depoları təşkil edilməlidir. Bu depo daim yenilənir. Yeniləmə prosesinə bir nəfər nəzarət etməlidir. Bir depo, funksional testdən keçən modullar üçün, ikincisi, bağlantı testindən keçən modullar üçün yaradılmışdır. Birincisi qaralamalar, ikincisi, sistemin paylama dəstini yığaraq müştəriyə nəzarət testləri və ya işin hər hansı bir mərhələsinin çatdırılması üçün nümayiş etdirməyin mümkün olduğu bir şeydir.

Test

Test qrupları bir layihənin hazırlanmasının əvvəlində əməkdaşlığa cəlb edilə bilər. Adətən kompleks sınaq ayrı bir inkişaf mərhələsi olaraq seçilir. Layihənin mürəkkəbliyindən asılı olaraq, sınaq və səhvlərin düzəldilməsi ümumi layihə müddətinin üçdə birini, yarısını və ya daha çoxunu ala bilər.

Layihə nə qədər mürəkkəbdirsə, aşağıdakı funksiyaları təmin edən səhv izləmə sisteminin avtomatlaşdırılmasına ehtiyac daha çoxdur:

Səhv mesajının saxlanması (səhv sistemin hansı komponentinə aiddir, onu kim tapdı, onu necə çoxaldır, kim düzəltməkdən məsuldur, nə vaxt düzəldilməlidir);

Yeni səhvlərin ortaya çıxması, sistemdə bilinən səhvlərin vəziyyətindəki dəyişikliklər haqqında bildiriş sistemi (e-poçt ilə bildirişlər);

Sistem komponentlərinin faktiki səhvləri haqqında hesabatlar;

Səhv və onun tarixi haqqında məlumat;

Bəzi kateqoriyalardakı səhvlərə giriş qaydaları;

Hata izləmə sistemi son istifadəçi üçün məhdud giriş interfeysi.

Bu cür sistemlər bir çox təşkilati problemləri, xüsusən də avtomatik səhv bildirişi məsələlərini öz üzərinə götürür.

Həqiqi sistem testləri ümumiyyətlə bir neçə kateqoriyaya bölünür:

a) offline testlər modullar; onlar artıq sistem komponentlərinin inkişaf mərhələsində istifadə olunur və ayrı -ayrı komponentlərin səhvlərini izləməyə imkan verir;

b) bağlantı testləri sistem komponentləri; bu testlər inkişaf mərhələsində də istifadə olunur, sistem komponentləri arasında düzgün qarşılıqlı əlaqəni və məlumat mübadiləsini izləməyə imkan verir;

c) sistem testi; sistemin qəbul edilməsi üçün əsas meyardır; Tipik olaraq, bu, həm müstəqil testləri, həm də əlaqə testlərini və modelləri özündə birləşdirən bir test qrupudur; belə bir test sistemin bütün komponentlərinin və funksiyalarının işini təkrar etməlidir; əsas məqsədi sistemin daxili qəbulu və keyfiyyətinin qiymətləndirilməsidir;

d) qəbul imtahanı; əsas məqsədi sistemi müştəriyə təhvil verməkdir;

e) performans və yük testləri; bu test qrupu sistemə daxil edilir, sistemin etibarlılığını qiymətləndirmək üçün əsasdır.

Hər bir qrup mütləq modelləşdirmə uğursuzluqları üçün testləri ehtiva edir. Bir komponentin, bir qrup komponentin və bütövlükdə sistemin aşağıdakı uğursuzluqlara cavabını yoxlayırlar:

İnformasiya sisteminin ayrı bir komponenti;

Sistem komponentlərinin qrupları;

Sistemin əsas modulları;

Əməliyyat sistemi;

Sərt uğursuzluq (elektrik kəsilməsi, sabit disklər).

Bu testlər, informasiya sisteminin düzgün vəziyyətini bərpa etmək üçün alt sistemin keyfiyyətini qiymətləndirməyə imkan verir və sənaye istismarı zamanı uğursuzluqların mənfi nəticələrinin qarşısını almaq üçün strategiyalar hazırlamaq üçün əsas məlumat mənbəyi olaraq xidmət edir.

İnformasiya sistemlərinin sınaq proqramının digər bir vacib cəhəti test məlumatları generatorlarının olmasıdır. Sistemin funksionallığını, etibarlılığını və performansını yoxlamaq üçün istifadə olunur. Məlumat generatorları olmadan bir məlumat sisteminin işlənməsinin həcminin artmasından asılılığının xüsusiyyətlərinin qiymətləndirilməsi problemini həll etmək mümkün deyil.

İcra

Sınaq əməliyyatı test prosesi ilə üst -üstə düşür. Sistem nadir hallarda tam tətbiq olunur. Tipik olaraq, bu tədricən və ya təkrarlanan bir prosesdir (dövrü bir həyat dövrü vəziyyətində).

İstismara verilməsi ən azı üç mərhələdən keçir:

2) məlumatların toplanması;

3) dizayn qabiliyyətinə çatmaq (yəni əməliyyat mərhələsinə faktiki keçid).

məlumatlar olduqca dar bir sıra səhvlərə səbəb ola bilər: əsasən, yükləmə zamanı məlumatların uyğunsuzluğu və yükləyicinin öz səhvləri. Bunları müəyyən etmək və aradan qaldırmaq üçün məlumatların keyfiyyətinə nəzarət üsullarından istifadə olunur. Bu cür səhvlər ən qısa müddətdə düzəldilməlidir.

Dövr ərzində məlumatların toplanması v məlumat Sistemiçox istifadəçi girişi ilə əlaqəli ən çox səhv aşkarlanır. İkinci düzəlişlər, istifadəçinin interfeysdən məmnun olmaması ilə əlaqədardır. Eyni zamanda, mərhələlərin tsiklik və geribildirim modelləri xərcləri azalda bilər. Bu mərhələ həm də ən ciddi sınaqdır - müştəri qəbul testləri.

Sistem dizayn gücünə çatır yaxşı bir variantda, kiçik səhvlərin və nadir ciddi səhvlərin incə tənzimlənməsi.

Əməliyyat və texniki dəstək

Bu mərhələdə, inkişaf etdiricilər üçün son sənəd texniki qəbul aktıdır. Sənəd sistemin iş qabiliyyətini dəstəkləmək üçün lazımi kadrları və tələb olunan avadanlıqları, habelə məhsulun işini pozmaq şərtlərini və tərəflərin məsuliyyətlərini təyin edir. Bundan əlavə, texniki dəstək şərtləri ümumiyyətlə ayrı bir sənəd şəklində tərtib edilir.