Proqram təminatının həyat dövrü. Proqram sistemlərinin həyat dövrü Proqramın həyat dövrü anlayışını təyin edin

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

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

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

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

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

Proqram təminatının yaradılmasının mərhələsi (mərhələsi), müəyyən bir zaman çərçivəsi ilə məhdudlaşan və tələblərlə müəyyən edilmiş müəyyən bir məhsulun (proqram modelləri, proqram komponentləri, sənədlər və s.) Buraxılması ilə bitən 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:

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

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

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

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

1. Layihə üzərində işləmədən əvvəl işin planlaşdırılması. Mərhələnin əsas vəzifələri, inkişaf məqsədlərinin əvvəlcədən müəyyənləşdirilməsidir iqtisadi qiymətləndirmə layihə, iş qrafikinin qurulması, birgə işçi qrupunun yaradılması və təlimi.
2. Gələcək sistem üçün tələblərin əvvəlcədən müəyyənləşdirilməsi, təşkilatın quruluşunun təyin edilməsi, hədəf funksiyalar siyahısının təyin edilməsi həyata keçirilən avtomatlaşdırılmış 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ə işin yaxşılaşdırılması üçün təkliflər hazırlamağa imkan verən "AS-IS" ("olduğu kimi") modeli. vəziyyət;
• təşkilatdakı yeni texnologiyalar ideyasını əks etdirən "TO-BE" modeli ("necə olmalı").

Modellərin hər biri tam funksional və məlumat modeli təşkilatın fəaliyyəti, habelə (lazım olduqda) təşkilatın davranış dinamikasını təsvir edən bir model. Qeyd edək ki, qurulmuş modellər müəssisənin informasiya sistemini işləyib hazırlamasından asılı olmayaraq müstəqil praktiki əhəmiyyətə malikdir, çünki işçilərin hazırlanması və müəssisənin iş proseslərinin yaxşılaşdırılması üçü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ə bilənliyi və məqsədəuyğunluğu təsdiqlənmiş proqram xüsusiyyətləri, funksional, texniki və interfeys xüsusiyyətləridir.

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

1. Bir proqram sistemi layihəsinin hazırlanması. Bu mərhələdə "Gələcək sistem nə etməlidir?" Sualının cavabı, proqram təminatını düzəltmə 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əsdiqlənmiş və təsdiq edilmiş bir spesifikasiyası olmalıdır: funksionallıq, texniki və interfeys spesifikasiyaları, bunların tamlığı, sınaqdan keçirilə bilənliyi və məqsədəuyğunluğu təsdiq edilmişdir.

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

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

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

Ətraflı dizayn mərhələsinin 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.

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

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

   • modul adı - modulu çağırmaq üçün istifadə olunan adı göstərir (birdən çox girişi olan bir modul üçün hər giriş üçün ayrıca spesifikasiyalar olmalıdır);
   • funksiya - modulun yerinə yetirdiyi funksiyanı 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.).
2. Modulların məntiqinin və proqramlaşdırma (kodlaşdırma) modullarının dizaynı.
3. Modulların düzgünlüyünün yoxlanılması.
4. Test modulları.
5. Verilənlər bazasının fərdi parametrlər, simvollar və bitlər səviyyəsinə qədər təsviri.
6. Qəbul imtahanı planı.
7. İstifadəçi kitabçası.
8. İnteqrasiya və ayıklama üçün ilkin plan. Sonrakı mərhələlərin məzmunu əsasən proqramın həyat dövrünün müvafiq prosesləri ilə üst -üstə düşür. Ümumiyyətlə, texnoloji mərhələlər işin ağlabatan və rasional planlaşdırılması və təşkili mülahizələrinə əsaslanaraq fərqlənir. Proqramın ömrü ilə əlaqənin və iş mərhələlərinin mümkün variantı şəkildə göstərilmişdir.

Pirinç. 1.

Proqram ömrü modellərinin növləri

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

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

Yaradılma və təhlil 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 bütün inkişaf dövrü üçü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əqiqliyidir. Yaradıcıların əsas diqqəti optimal dəyərlərə nail olmaqdır texniki xüsusiyyətlər inkişaf etmiş proqram sistemi - performans, yaddaş ölçüsü və s.

Üstünlüklər kaskad modeli:

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

Şəlalə yanaşması, layihənin əvvəlində bütün tələbləri tam və aydın şəkildə ifadə etmək mümkün olan 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 sapmalar 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 artması 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 sistemin yaradılması zamanı dinamik fəaliyyət sahələrində (iş) fəaliyyət göstərməsinin bir çox aspektləri dəyişir. Hər hansı bir inkişaf mərhələsi başa çatdıqdan sonra lazımi düzəlişlərin edilməsini təmin etmək üçün inkişaf prosesini dəyişdirmək lazım idi. Həyat dövrünün iterativ modeli belə ortaya çıxdı, buna ara nəzarətli model və ya fazaların dövri təkrarlanan modeli deyilir.

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

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

Layout

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

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

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

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

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

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

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

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

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

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

Proqram dizayn strategiyaları

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

• tək keçid (yuxarıda müzakirə olunan kaskad strategiyası) - dizayn addımlarının xətti ardıcıllığı;
• artan strategiya. Prosesin əvvəlində bütün istifadəçi və sistem tələbləri müəyyən edilir, dizaynın qalan hissəsi versiyalar ardıcıllığı kimi aparılır. Birinci versiya planlaşdırılan bəzi funksiyaları həyata keçirir, sonrakı versiya həyata keçirir əlavə xüsusiyyətlər və s., tam bir sistem əldə olunana qədər;
• təkamül strategiyası. Sistem eyni zamanda bir sıra 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 inkişafı nəticəsində təmizlənir. 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 təminatı ə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əşdirmə variantları; 3 -cü artımda - orfoqrafiya və qrammatik yoxlama; 4 -cü artımda - səhifə tərtibat imkanları.

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

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

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

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

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

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

İnteqrasiya edən aspekt spiral modeli spiralın radial ölçüsü nəzərə alındıqda aydındır. Hər təkrarlama ilə, daha çox tam versiyalar PS. 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.

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

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

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

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

Ləyaqət spiral modeli:

1. ən real olaraq (təkamül şəklində) inkişafı əks etdirir proqram təminatı;
2. inkişafın hər bir mərhələsindəki riski açıq şəkildə nəzərə almağa imkan verir;
3. addım daxildir sistem yanaşması iterativ inkişaf quruluşuna;
4. 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). Bir 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 neçə layihəyə bölünməsini əhatə edir və hər bir inkişaf iterasiyası, iterasiyanın sonunda əldə ediləcək 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 edilmiş məqsədlər toplusuna tam uyğun gəlməli olduğunu, yəni bütün tələblərin yerinə yetirilməsini nəzərdə tutur.

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

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

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

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

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

1. Biznes 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.
2. Tələblərin idarə edilməsi, maraqlı tərəflərdən məlumat əldə etmək və onu inkişaf etdirilən sistemin məzmununu 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.
3. 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.
4. İ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.
5. Test (Test) yaradılan məhsulun keyfiyyətinin qiymətləndirilməsinə həsr edilmişdir.
6. Dağıtım, məhsullar müştərilərə ötürüldükdə və məhsul son istifadəçilərə təqdim edildikdə baş verən əməliyyatları əhatə edir.
7. Konfiqurasiya idarəçiliyi, orta proqram və son məhsulları sinxronizasiya etmək və layihə boyunca inkişafını idarə etmək və gizli problemləri tapmaqdır.
8. Layihə İdarəçiliyi (İdarəetmə) layihə planlaşdırma, risk idarəçiliyi, gedişatını izləmək və əsas göstəricilərin davamlı qiymətləndirilməsinə həsr edilmişdir.
9. Ətraf mühitin idarə edilməsi (Ətraf mühit) inkişaf mühitinin formalaşması elementlərini əhatə edir məlumat Sistemi və layihə fəaliyyətlərinə dəstək.

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 hər hansı bir 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əsidir;
• Rational ClearQuest, bir layihədəki dəyişikliklərin idarə edilməsi və qüsurların izlənməsi üçün bir məhsuldur (səhv izləmə), test və tələblərin idarə edilməsi vasitələri ilə sıx birləşdirilmiş və bütün səhvləri və sənədləri bir -biri ilə əlaqələndirmək üçün vahid bir mühit təmin edir;
• Rasional SoDA, daxili sənədlər üçün korporativ standart təyin etməyə imkan verən layihə sənədlərinin avtomatik istehsalı üçün bir məhsuldur. Sənədləri mövcud standartlara (ISO, CMM) gətirmək də mümkündür;
• Rational PureCoverage - Rational PureCoverage - 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 təminatında yaranan darboğazları aşkar etməyə və aradan qaldırmağa kömək edir;
• Rasional Visual PureCoverage - Test edilməyən kod sahələrini avtomatik olaraq təyin edir.
• Rational ClearCase, bütün layihə sənədlərinin versiya nəzarətinə imkan verən bir proqram konfiqurasiya idarəetmə məhsuludur (SCM). Eyni anda birdən çox layihənin versiyasını saxlamağa imkan verir, aralarında tez keçid edir. Rational Requisite Pro yeniləmələri dəstəkləyir və tələblərdəki dəyişiklikləri izləyir. inkişaf qrupu üçün;
• SQA TeamTest - Alət test avtomatlaşdırılması;
• Rasional TestManager, testlə əlaqəli bütün alətləri, əsərləri, skriptləri və məlumatları bir araya gətirən bir test idarəetmə sistemidir;
• Rasional Robot - testlər yaratmaq, dəyişdirmək və avtomatik işlətmək üçün bir vasitə;
• SiteLoad, SiteCheck - veb saytların performans və pozulmuş bağlantılar üçün sınanması üçün vasitələr;
• Rasional PerformansStudio - 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ı birləşdirir və bununla da memarlara və analitiklərə UML 2.0 -dan istifadə etməklə inkişaf etdirilən informasiya sistemi haqqında fərqli fikirlər yaratmağa imkan verir və inkişaf etdiricilərin inkişaf etdirməsini təmin edir. J2EE, XML, veb xidmətləri və s.

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

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

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

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 bir-biri ilə əlaqəli və bir-birini tamamlayan iki bilik sahəsi şəklində təqdim olunur: Microsoft Solutions Framework (MSF) və Microsoft Operations Framework (MOF).

Qeyd etmək lazımdır ki, Microsoft tətbiqli və xüsusi istifadə üçün ümumi MSF metodlarına əsaslanan metodologiyalar hazırlamışdır. Bundan əlavə, Microsoft, MSF tətbiqində xüsusi olaraq tətbiq olunan biliklərə sahib olan mütəxəssisləri sertifikatlaşdırır (məsələn, layihə idarəetmə ü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 cavablandırılması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 ehtiyacları ödəyirmi? müştəridən? " və s.

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

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

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

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

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

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

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

MSF daxilində kod, sənədlər, dizaynlar, planlar və digər iş materialları ümumiyyətlə iterativ şəkildə yaradılır. MSF, əsas funksiyalarını quraraq, sınayaraq və tətbiq edərək bir həll hazırlamağa 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, tək bir həll üçün birdən çox versiya yaratmaq imkanına diqqət yetirməyiniz tövsiyə olunur. Yeni versiyaların yaradılması ilə həllin funksionallığı inkişaf edir.

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

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

"Həyat dövrü" anlayışı doğulan, inkişaf edən və ölən bir şeyi nəzərdə tutur. Proqram məhsulları da canlı orqanizm kimi zamanla yaradılır, idarə olunur və inkişaf etdirilir.

Həyat dövrü proqram təminatı inkişafının bütün mərhələlərini əhatə edir: ehtiyac yarandıqdan köhnəlmə və ya müvafiq problemləri həll etmək ehtiyacının itirilməsi səbəbindən istifadənin tamamilə dayandırılmasına qədər.

Bir proqram məhsulunun həyat dövrü ərzində mövcudluğunun bir neçə mərhələsi vardır. Bu mərhələlər və onların sayı üçün hələ də qəbul edilmiş adlar yoxdur. Amma bu mövzuda da konkret fikir ayrılığı yoxdur. Buna görə də, proqram ömrünü mərhələlərə bölmək üçün bir neçə variant var. Müəyyən bir bölmənin digərlərindən daha yaxşı olub -olmadığı sualları əsas deyil. Əsas odur ki, onları nəzərə alaraq proqram təminatının hazırlanmasını düzgün təşkil etməkdir.

Həyat dövrünün müddətinə görə proqram məhsulları iki sinfə bölünə bilər: kiçik və uzun ömür. Proqramların bu sinifləri, onların yaradılması və istifadəsinə çevik (yumşaq) bir yanaşmaya və proqram məhsullarının tənzimlənən dizaynına və istismarına sərt bir sənaye yanaşmasına uyğundur. V elmi təşkilatlar və universitetlərdə, məsələn, birinci sinif proqramların, dizayn və sənaye təşkilatlarında isə ikincinin inkişafı üstünlük təşkil edir.

Qısa ömrü olan proqram məhsulları əsasən elmi və mühəndislik problemlərinin həlli, hesablamaların konkret nəticələrini əldə etmək üçün yaradılmışdır. Bu cür proqramlar ümumiyyətlə nisbətən kiçikdir. Onlar bir mütəxəssis və ya kiçik bir qrup tərəfindən hazırlanır. Proqramın əsas fikri bir proqramçı və son istifadəçi tərəfindən müzakirə olunur. Bəzi detallar kağız üzərində yazılır və layihə günlər və ya həftələr ərzində tamamlanır. Onlar təkrarlanmaq və sonradan digər komandalar tərəfindən istifadə olunmaq üçün nəzərdə tutulmayıb. Beləliklə, bu cür proqramlar tədqiqat və inkişafın bir hissəsidir və özgəninkiləşdirilə bilən proqram məhsulları olaraq qəbul edilə bilməz.

Onların həyat dövrü uzun bir sistem təhlili və problemin rəsmiləşdirilməsindən, proqramların dizaynında əhəmiyyətli bir mərhələdən və nisbətən qısa bir əməliyyat və nəticələr əldə etməkdən ibarətdir. Funksional və dizayn xüsusiyyətlərinə olan tələblər, bir qayda olaraq, rəsmiləşdirilmir, proqramların rəsmiləşdirilmiş testləri yoxdur. Onların keyfiyyət göstəriciləri yalnız qeyri -rəsmi fikirlərinə uyğun olaraq tərtibatçılar tərəfindən idarə olunur.

Qısa ömrü olan proqram məhsulları

Bu cür proqramların saxlanması və dəyişdirilməsi lazım deyil və hesablamaların nəticələrini aldıqdan sonra onların həyat dövrü başa çatır. Bu cür proqramların həyat dövründəki əsas xərclər, bir aydan 1 ... 2 ilə qədər davam edən sistem təhlili və dizayn mərhələlərinə düşür.

bir proqram məhsulunun ömrü nadir hallarda 3 ildən çoxdur.

Uzun xidmət müddəti olan proqram məhsulları müntəzəm məlumat emalı və idarə edilməsi üçün yaradılmışdır. Bu cür proqramların quruluşu mürəkkəbdir. Ölçüləri geniş bir diapazonda dəyişə bilər (1 ... 1000 min əmr), lakin hamısının tanınma xüsusiyyətlərinə və müxtəlif mütəxəssislər tərəfindən uzunmüddətli saxlanılması və istifadəsi prosesində dəyişiklik imkanı var. Bu sinif proqram məhsulları təkrarlana bilər, sənayelər kimi sənədlərlə müşayiət olunur və inkişaf etdiricidən kənarlaşdırılmış proqram məhsullarını təmsil edir.

Uzun xidmət müddəti olan proqram məhsulları

Proqram sisteminin rəsmiləşdirilməsini, son məhsulun əldə edilmiş keyfiyyət göstəricilərinin rəsmiləşdirilməsini və rəsmiləşdirilməsini tələb edən böyük mütəxəssis qrupları onların dizaynı və istismarı ilə məşğuldur. Onların həyat dövrü 10 ... 20 ildir. Bu vaxtın 70 ... 90% -ə qədəri istismar və texniki xidmətə sərf olunur. Kütləvi replikasiya və uzunmüddətli texniki xidmət sayəsində bu cür proqram məhsullarının istismarı və saxlanması zamanı ümumi xərclər istehsal xərclərini əhəmiyyətli dərəcədə üstələyir. sistem təhlili və dizayn.

Bütün sonrakı təqdimatlar nəzarət və məlumatların işlənməsi üçün böyük (kompleks) proqram vasitələrinin hazırlanmasına yönəlib.

Ümumiləşdirilmiş model həyat dövrü bir proqram məhsulu belə görünə bilər:

Mən Sistem təhlili:

a) tədqiqat;

b) texniki -iqtisadi analiz:

Əməliyyat;

İqtisadi;

Kommersiya.

II. Proqram dizaynı:

a) dizayn:

Sistemin funksional parçalanması, arxitekturası;

Xarici proqram dizaynı;

Verilənlər bazası dizaynı;

Proqram memarlığı;

b) proqramlaşdırma:

Daxili proqram dizaynı;

Proqram modullarının xarici dizaynı;

Proqram modullarının daxili dizaynı;

Kodlaşdırma;

Ayıklama proqramları;

Proqramlaşdırma;

c) proqram təminatının ayıklanması.

III. Proqram təminatının qiymətləndirilməsi (sınaqdan keçirilməsi).

IV. Proqramdan istifadə:

a) əməliyyat;

b) müşayiət.

Mən... Sistem təhlili. Proqram təminatının hazırlanmasının başlanğıcında ona ehtiyac, məqsədi və əsas funksional xüsusiyyətləri müəyyən edilən bir sistem təhlili (ilkin dizayn) aparılır. Gələcək proqram məhsulunun xərcləri və mümkün səmərəliliyi təxmin edilir.

Bu mərhələdə tələblərin siyahısı tərtib edilir, yəni istifadəçinin hazır məhsuldan nə gözlədiyinin aydın tərifi. Burada məqsəd və vəzifələrin təyin edilməsi həyata keçirilir, bunun üçün layihənin özü hazırlanır. Sistem təhlili mərhələsində iki istiqaməti ayırmaq olar: tədqiqat və texniki -iqtisadi analiz.

Araşdırma başlayır inkişaf meneceri proqrama ehtiyac duyduğundan.

İş, hazırlanan proqram məhsulu üçün tələblərin rəsmi əlyazma siyahısını hazırlamaq üçün lazım olan işləri planlaşdırmaq və əlaqələndirməkdən ibarətdir.

Araşdırma başa çatır tələblər görünə biləcək şəkildə formalaşdırıldıqda və zəruri hallarda məsul menecer tərəfindən dəyişdirilə və təsdiqlənə bilər.

Texniki-iqtisadi əsaslandırmalı öyrənmə tədqiqatın texniki bir hissəsi var və rəhbərliyin niyyəti o qədər gücləndikdə başlayır ki, bir layihə meneceri resursların (əməyin) dizaynını və bölgüsünü təşkil etmək üçün təyin olunsun.

İş, əldə etmək üçün təklif olunan proqram məhsulunu araşdırmaqdan ibarətdir praktik qiymətləndirmə Xüsusilə, layihənin həyata keçirilməsi imkanları aşağıdakılarla müəyyən edilir:

- əməliyyatın mümkünlüyü , Məhsul praktik istifadə üçün kifayət qədər rahat olacaqmı?

- iqtisadi məqsədəuyğunluq , Hazırlanan məhsulun dəyəri məqbuldurmu? Bu neçəyə başa gəlir? Məhsul iqtisadi olacaq təsirli vasitədir istifadəçinin əlindədir?

- kommersiya imkanları, Məhsul cəlbedici, tələbatlı, quraşdırılması asan, xidmətə uyğunlaşdırıla bilən, öyrənilməsi asan olacaqmı?

Bu və digər məsələlər əsasən yuxarıdakı tələblər nəzərə alınmaqla həll edilməlidir.

Texniki -iqtisadi əsaslandırma bütün tələblər toplandıqda və təsdiq edildikdə bitir.

Layihə üzərində daha çox işə başlamazdan əvvəl bütün lazımi məlumatların alındığından əmin olmalısınız. Bu məlumatlar dəqiq, başa düşülən və işlək olmalıdır. İstifadəçini spesifikasiya şəklində tərtib edilmiş proqram məhsulu üçün təmin edən bir sıra tələbləri təmsil etməlidir.

Bu tələbin yerinə yetirilməməsi, səhv şərh edilmiş detalların, təyin olunmamış şərtlərin aydınlaşdırılması üçün istifadəçiyə dəfələrlə müraciət edilməsi səbəbindən gələcəkdə layihənin həyata keçirilməsini əhəmiyyətli dərəcədə ləngidə bilər və nəticədə artıq işlənmiş hissələrinin yenidən işlənməsi tələb olunacaq. .

Tez -tez sistem təhlili dövründə daha çox proqram inkişaf etdirilməsini dayandırmaq qərarı verilir.

II... Proqram dizaynı. Dizayn, bir proqram məhsulunun yaradıldığı və 90% -i son formasını əldə etdiyi proqram ömrü dövrünün əsas və həlledici mərhələsidir.

Həyatın bu mərhələsi əhatə edir müxtəlif növlər Layihənin fəaliyyətini üç əsas mərhələyə bölmək olar: bir proqram məhsulunun dizaynı, proqramlaşdırılması və ayıklanması.

Tikinti proqram təminatı, bəzi ilkin məqsədlər və tələblər kağız üzərində təsbit edildikdən sonra, texniki -iqtisadi əsaslandırma mərhələsindən başlayaraq başlayır.

Tələblər təsdiqlənəndə dizayn mərhələsindəki işlər tam sürətlə gedəcək.

Proqramın ömrünün bu seqmentində bunları həyata keçirirlər:

Həll olunan problemin funksional parçalanması, bunun əsasında bu problemin sistem arxitekturası müəyyən edilir;

İstifadəçi ilə xarici qarşılıqlı əlaqə şəklində ifadə olunan xarici proqram dizaynı;

Lazım gələrsə verilənlər bazası dizaynı;

Proqram memarlıq dizaynı - obyektləri, modulları və onların qarşılıqlı əlaqəsini təyin edir.

Proqramlaşdırma başlayır artıq proqram mərhələsində, proqram məhsulunun ayrı -ayrı komponentləri üçün əsas spesifikasiyalar mövcud olduqdan sonra, lakin tələblər razılaşmasının təsdiqindən əvvəl deyil. Proqramlaşdırma və dizayn mərhələlərinin üst -üstə düşməsi ümumi inkişaf müddətində qənaət etməyə, həmçinin dizayn qərarlarının təsdiqlənməsinə zəmanət verir və bəzi hallarda əsas məsələlərin həllinə təsir göstərir.

Bu mərhələdə proqram məhsulunun yığılması ilə əlaqədar işlər yerinə yetirilir. Bir proqram məhsulunun detallı daxili dizaynından, sistemin hər bir modulunun daxili məntiqinin inkişafından ibarətdir və sonra müəyyən bir proqramın mətnində ifadə olunur.

Proqramlaşdırma mərhələsi, inkişaf etdiricilər proqram məhsulunun ayrı -ayrı hissələrini sənədləşdirməyi, ayıklamağı və yığmağı bitirdikdən sonra sona çatır.

Ayıklama proqramı bütün komponentləri ayrıca düzəldildikdən və tək bir proqram məhsuluna yığıldıqdan sonra həyata keçirilir.

III... Proqram təminatının qiymətləndirilməsi (sınaqdan keçirilməsi). Bu mərhələdə, proqram məhsulu, inkişaf etdirməyən bir qrup tərəfindən ciddi sistem testlərinə məruz qalır.

Bu, hazır proqram məhsulunun bütün tələblərə və spesifikasiyalara cavab verdiyini, istifadəçi mühitində istifadə oluna biləcəyini, heç bir qüsur olmadığını və proqram məhsulunu dəqiq və tam şəkildə təsvir edən zəruri sənədləri ehtiva etməsini təmin etmək üçün edilir.

Qiymətləndirmə mərhələsi bütün komponentlər (modullar) yığılıb test edildikdən sonra başlayır, yəni. bitmiş proqram məhsulunun tam ayıklanmasından sonra. Proqram məhsulunun bütün sınaqlardan keçdiyini və istifadəyə hazır olduğunu təsdiqlədikdən sonra başa çatır.

Proqramlaşdırma qədər uzun çəkir.

IV. Proqram təminatının istifadəsi. Sistem təhlili döyüş üçün bir siqnaldırsa, dizayn hücum və qələbə ilə geri dönməkdirsə, bir proqram məhsulundan istifadə gündəlik həyati əhəmiyyət kəsb edir, lakin ümumiyyətlə inkişaf etdiricilər üçün şərəfli deyil.

Belə bir müqayisə, bir proqram məhsulunun istifadəsi zamanı dizayn prosesində yaranan səhvlərin düzəldilməsi baxımından uyğundur.

Bir proqram elementinin istifadə mərhələsi, maddə paylama sisteminə köçürüldükdə başlayır.

Məhsulun fəaliyyətdə olduğu və səmərəli istifadə edildiyi vaxtdır.

Bu zaman, kadr hazırlığı, tətbiqetmə, konfiqurasiya, texniki xidmət və ehtimal ki, proqram məhsulunun genişləndirilməsi həyata keçirilir - sözdə davam edən dizayn.

Məhsul istifadədən çıxarıldıqda və yuxarıdakı fəaliyyətlər dayandırıldıqda istifadə mərhələsi başa çatır. Ancaq unutmayın ki, proqram məhsulu başqası tərəfindən uzun müddət istifadə oluna bilər və burada təyin olunduğu kimi istifadə mərhələsi bitdikdən sonra. Çünki bu adam, geliştiricinin köməyi olmasa belə, evdə məhsul məhsulundan səmərəli istifadə edə bilər.

Bir proqram məhsulunun istifadəsi onun istismarı və istismarı ilə müəyyən edilir.

Proqram məhsulunun işləməsi onun icrasından, məlumatların işlənməsi üçün kompüterdə işləməsindən və yaradılmasının məqsədi olan nəticələrin əldə edilməsindən, həmçinin verilən məlumatların etibarlılığının və etibarlılığının təmin edilməsindən ibarətdir.

Proqram təminatı bir proqram məhsulunun saxlanılması, funksionallığının inkişafı və əməliyyat xüsusiyyətlərinin təkmilləşdirilməsi, bir proqram məhsulunun müxtəlif növ hesablama vasitələrinə kopyalanması və ötürülməsindən ibarətdir.

Baxım, əməliyyat mərhələsindən zəruri geribildirim rolunu oynayır.

Proqram təminatı işləyərkən proqramlardakı səhvləri aşkar etmək mümkündür və onların dəyişdirilməsinə və funksiyalarının genişləndirilməsinə ehtiyac var.

Bu dəyişikliklər ümumiyyətlə proqram məhsulunun cari versiyasının işləməsi ilə eyni vaxtda aparılır. Proqramların bir nüsxəsində hazırlanmış düzəlişləri yoxladıqdan sonra, proqram məhsulunun növbəti versiyası əvvəllər istifadə olunanları və ya bəzilərini əvəz edir. Bu halda, proqram məhsulunun işləmə prosesi demək olar ki, davamlı ola bilər, çünki proqram məhsulunun versiyasının dəyişdirilməsi qısamüddətlidir. Bu şərtlər, bir proqram məhsulunun bir versiyasının işləmə prosesinin ümumiyyətlə texniki xidmət mərhələsindən asılı olaraq paralel və müstəqil şəkildə davam etməsinə səbəb olur.

Proqram məhsullarının həyat dövrü mərhələləri arasında üst -üstə düşür

Proqram məhsulunun həyat dövrünün müxtəlif mərhələləri arasında üst -üstə düşmələr mümkündür və adətən arzuolunandır. Ancaq bitişik olmayan proseslər arasında heç bir üst-üstə düşmə olmamalıdır.

Mərhələlər arasında əks əlaqə mümkündür. Məsələn, xarici dizayn addımlarından birində məqsədlərin tərtibində səhvlər aşkar edilə bilər, sonra dərhal geri qayıtmalı və düzəltməlisiniz.

Bir proqram məhsulunun həyat dövrünün düşünülmüş modeli, bəzi dəyişikliklərlə kiçik layihələr üçün də bir model ola bilər.

Məsələn, tək bir proqram tərtib edildikdə, sistem arxitekturası tez -tez və

verilənlər bazası dizaynı; ilkin və detallı xarici dizayn prosesləri tez -tez bir araya gəlir və s.

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ə həyat dövrü istehsalının 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əyin edilməsi.

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

Ədəbiyyat.

Giriş

Sənaye tətbiqi kompüterlər və proqram təminatına artan tələbat əhəmiyyətli dərəcədə artırmaq üçün təcili vəzifələr qoymuşdur 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 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 həyat dövrü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ı modellər 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 həlli, 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ə yuxarı səviyyənin üç ə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 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ə bundan başlayaq.

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.

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 problem ifadəsi də faydasızdır. Problemin 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şı formalaşdırılması 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: kompüterin necə işlədiyi onun üçün önəmli deyil, 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 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 hər hansı bir kiçik uyğunsuzluq istisna olmaqla, müəyyən müddəaları son dərəcə dəqiq tərtib etməyə imkan verən rəsmi bir dildə yazıldığı üçün anlamaq çə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 yuxarıdan aşağıya, ən aşağıdan 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 hərtərəfli 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 (xülasə vəzifələr);

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 yuxarıya qədər 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.

Proqramın həyat dövrü

Proqram təminatının həyat dövrü, bir proqram məhsulu yaratmaq ehtiyacı ilə əlaqədar qərar verildiyi andan başlayaraq tam istifadədən çıxdığı anda bitən bir müddətdir. (IEEE Std 610.12 standartı)

Proqram təminatının həyat dövrünün (LC) mərhələlərini müəyyən etmək ehtiyacı, inkişaf etdiricilərin problemin həllindən başlayaraq hər bir mərhələdə optimal inkişaf idarəetməsi və müxtəlif keyfiyyətə nəzarət mexanizmlərindən istifadə edərək proqram təminatının keyfiyyətini artırmaq istəyi ilə əlaqədardır. müəllifin proqram təminatı dəstəyi. Proqram ömrü dövrünün ən ümumi nümayişi, əsas mərhələlər - proseslər şəklində bir modeldir:

Proqram tələblərinin sistem təhlili və əsaslandırılması;

İlkin (eskiz) və ətraflı (texniki) proqram dizaynı;

Proqram komponentlərinin inkişafı, onların inteqrasiyası və bütövlükdə proqram təminatının ayıklanması;

Test, sınaq istismarı və proqramın təkrarlanması;

Proqram təminatının müntəzəm istifadəsi, texniki dəstək və nəticələrin təhlili;

Proqram təminatı, onun dəyişdirilməsi və təkmilləşdirilməsi, yeni versiyaların yaradılması.

Bu model ümumiyyətlə qəbul edilir və həm yerli modelə uyğundur tənzimləyici sənədlər proqram təminatı sahəsində və xarici. Texnoloji təhlükəsizliyin təmin edilməsi baxımından, həyat modelinin xarici modellərdə təqdim edilməsinin xüsusiyyətlərini daha ətraflı nəzərdən keçirməyiniz məsləhətdir, çünki proqram təminatı qüsurlarının ən çox daşıyıcısı xarici proqramdır. təxribat növü.

Proqram ömrü 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əqdimatı onların xüsusiyyətlərini və proseslərin bəzi xüsusiyyətlərini vizual olaraq vurğulamağa imkan verir.

Başlanğıcda, əvvəlki işlərin nəticələrindən istifadə edərək əsas mərhələlərin bir -birinin ardınca başladığı kaskadlı bir həyat dövrü modeli yaradıldı. Layihənin bütün mərhələlərinin ciddi şəkildə müəyyən edilmiş ardıcıllıqla yerinə yetirilməsini təmin edir. Növbəti mərhələyə keçid, işin əvvəlki mərhələdə tamamlanması deməkdir. Tələblərin formalaşdırılması mərhələsində müəyyən edilmiş tələblər formada ciddi şəkildə sənədləşdirilir texniki tapşırıqlar və layihənin hazırlanması müddətində qeyd olunur. Hər bir mərhələ, inkişafın başqa bir inkişaf qrupu tərəfindən davam etdirilməsi üçün kifayət qədər sənədlərin tam dəsti ilə başa çatır. Hər hansı bir tələbin qeyri -dəqiqliyi və ya yanlış təfsiri, nəticədə, layihənin ilkin mərhələsinə "geri çəkilməyin" lazım olduğuna və lazımi yenidən işlərin aparılması layihə qrupunu nəinki cədvəldən kənarlaşdırır, xərclərin keyfiyyətcə artmasına və ehtimal ki, layihənin əvvəlcədən düşünülmüş formada dayandırılmasına gətirib çıxarır. Şəlalə modelinin müəlliflərinin əsas yanlış düşüncəsi, layihənin bütün prosesdən bir dəfə keçdiyi, dizayn edilmiş memarlığın yaxşı və istifadəsi asan olduğu, tətbiq dizaynının ağlabatan olması və sınaq getdikcə tətbiq səhvlərinin asanlıqla aradan qaldırılması fərziyyəsidir. Bu model, bütün səhvlərin tətbiqdə cəmləşəcəyini düşünür və buna görə də komponent və sistem sınaqları zamanı bərabər şəkildə aradan qaldırılır. Beləliklə, böyük layihələr üçün şəlalə modeli çox real deyil və yalnız kiçik sistemlərin yaradılması üçün səmərəli istifadə edilə bilər.

Ən spesifik spiral həyat dövrü modelidir. Bu modeldə, ilkin dizayn mərhələlərinin təkrarlanan prosesinə diqqət yetirilir. Bu mərhələlərdə ardıcıl olaraq anlayışlar, tələblər spesifikasiyası, ilkin və ətraflı dizayn yaradılır. Hər mərhələdə işin məzmunu dəqiqləşdirilir və yaradılan proqramın görünüşü cəmləşir, əldə edilən nəticələrin keyfiyyəti qiymətləndirilir və növbəti iterasiyanın işi planlaşdırılır. Hər təkrarlama zamanı aşağıdakılar qiymətləndirilir:

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

Daha bir təkrarlama etmək ehtiyacı;

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

Layihənin dayandırılmasının mümkünlüyü.

Proqram təminatı ömrü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ə təbliğ olunur. Bu səviyyədə ən ümumi texnoloji proseslər ilə əlaqəli beynəlxalq əməkdaşlıq... İkinci istiqamət ABŞ -da Elektrotexnika və Elektronika Mühəndisləri İnstitutu (IEEE) və Amerika Milli Standartlar İnstitutu (ANSI) ilə birlikdə fəal şəkildə inkişaf etdirilir. ISO / IEC və ANSI / IEEE standartları əsasən məsləhət xarakterlidir. Üçüncü sahə ABŞ Müdafiə Nazirliyi (Müdafiə Nazirliyi-DOD) tərəfindən stimullaşdırılır. DOD standartları, ABŞ Müdafiə Nazirliyinin sifariş verdiyi firmalar üçün məcburidir.

Mürəkkəb bir sistem, xüsusən də real vaxt sistemi üçün proqram təminatı hazırlamaq üçün nəzərdən keçirilən əsas proseslər çərçivəsində bütün məlum əsərlərin birləşməsinə əsaslanan sistem boyu həyat dövrü modelindən istifadə etmək məsləhətdir. Bu model müxtəlif proqram layihələrinin planlaşdırılması, planlaşdırılması və idarə edilməsində istifadə üçün nəzərdə tutulmuşdur.

Proseslərin xüsusiyyətləri, texniki və iqtisadi xüsusiyyətləri və onlara təsir edən amillər baxımından əhəmiyyətli dərəcədə fərqlənən bu həyat dövrü modelinin mərhələlər toplusunu iki hissəyə bölmək məsləhətdir.

Həyat dövrünün birinci hissəsində bir sistem təhlili, dizaynı, inkişafı, sınanması və proqram testi aparılır. Bu mərhələlərdə işlərin çeşidi, əmək intensivliyi, müddəti və digər xüsusiyyətləri obyektdən və inkişaf mühitindən əhəmiyyətli dərəcədə asılıdır. Fərqli proqram sinifləri üçün bu cür asılılıqların öyrənilməsi yeni proqram versiyaları üçün iş cədvəllərinin tərkibini və əsas xüsusiyyətlərini proqnozlaşdırmağa imkan verir.

Həyat dövrünün ikinci hissəsi, proqram təminatının istismarı və saxlanmasını əks etdirərək, obyektin xüsusiyyətləri və inkişaf mühiti ilə nisbətən zəif əlaqəlidir. Bu mərhələlərdəki iş diapazonu daha sabitdir və onların əmək intensivliyi və müddəti əhəmiyyətli dərəcədə dəyişə bilər və proqramın kütləvi istifadəsindən asılıdır. İstənilən həyat dövrü modeli üçün proqram sistemlərinin yüksək keyfiyyətini təmin etmək yalnız bu mərhələlərin hər birində tənzimlənmiş texnoloji prosesdən istifadə etməklə mümkündür. Belə bir proses, mövcud olanlardan seçmək və ya inkişaf obyektini və ona uyğun olan işlərin siyahısını nəzərə almaqla yaratmaq məsləhət görülən inkişaf avtomatlaşdırma vasitələri ilə dəstəklənir.

VT -nin inkişafı, fərqli bir xarakterli məlumatların işlənməsi ilə əlaqədar həll ediləcək vəzifələrin siniflərini daim genişləndirir.

Bunlar əsasən üç növ məlumat və buna görə də kompüterlərin həlli üçün istifadə olunan üç sinif problemidir:

1) Rəqəmsal məlumatların işlənməsi ilə əlaqədar hesablama vəzifələri. Bunlara, məsələn, böyük ölçülü xətti tənliklər sisteminin həlli problemi daxildir. Əvvəllər kompüter istifadəsinin əsas, dominant sahəsi idi.

2) Mətn məlumatlarının yaradılması, redaktəsi və çevrilməsi ilə əlaqədar simvolik məlumatların işlənməsi üçün tapşırıqlar. Bu cür problemlərin həlli, məsələn, katib-mətbəə işi ilə əlaqədardır.

3) Qrafik məlumatların işlənməsi üçün tapşırıqlar, yəni. diaqramlar, rəsmlər, qrafiklər, eskizlər və s. Bu cür vəzifələrə, məsələn, dizayner tərəfindən yeni məhsulların təsvirlərini hazırlamaq vəzifəsi daxildir.

4) Alfasayısal məlumatların işlənməsi üçün tapşırıqlar - İS. Hal -hazırda kompüter tətbiqinin əsas sahələrindən birinə çevrilmişdir və vəzifələr daha da çətinləşir.

Hər sinifdəki problemlərin kompüterdə həllinin özünəməxsus xüsusiyyətləri var, lakin əksər problemlərə xas olan bir neçə mərhələyə bölünə bilər.

Proqramlaşdırma texnologiyasıbilik, metod və vasitələrdən istifadə edərək texnoloji prosesləri və keçmə (mərhələləri) qaydasını öyrənir.

Texnologiyanı iki ölçüdə - şaquli (prosesləri təmsil edən) və üfüqi (mərhələləri təmsil edən) xarakterizə etmək rahatdır.

Rəsm

Proses qarşılıqlı əlaqəli hərəkətlər toplusudur ( texnoloji əməliyyatlar) bəzi girişləri çıxışa çevirmək. Proseslər bir sıra hərəkətlərdən (texnoloji əməliyyatlar) ibarətdir və hər bir hərəkət bir sıra vəzifələrdən və onların həlli üsullarından ibarətdir. Şaquli ölçü proseslərin statik tərəflərini əks etdirir və iş prosesləri, hərəkətlər, vəzifələr, performans nəticələri, ifaçılar kimi anlayışlarla işləyir.

Mərhələ, müəyyən bir müddətlə məhdudlaşan və müəyyən bir məhsulun buraxılması ilə bitən, bu mərhələ üçün qoyulan tələblərlə müəyyən edilən proqram təminatı fəaliyyətinin bir hissəsidir. Bəzən mərhələlər mərhələlər və ya mərhələlər adlanan daha böyük zaman çərçivələrinə qruplaşdırılır. Beləliklə, üfüqi ölçü vaxtı təmsil edir, proseslərin dinamik aspektlərini əks etdirir və mərhələlər, mərhələlər, mərhələlər, təkrarlamalar və nəzarət nöqtələri kimi anlayışlarla işləyir.

Proqram təminatı müəyyən bir həyat dövrünü izləyir.

Həyat dövrü Proqram təminatı, proqram təminatının hazırlanması və istismarı üçün hər bir layihə çərçivəsində həyata keçirilmiş və idarə olunan, bəzi proqramların yaradılması ideyasının (konsepsiyasının) yaradılmasının zəruriliyinə dair qərar verildiyi andan başlayaraq həyata keçirilən və idarə olunan davamlı və nizamlı fəaliyyətlər toplusudur. və səbəblərdən əməliyyatdan tamamilə çıxdığı anda bitən:

a) köhnəlmə;

b) müvafiq problemləri həll etmək ehtiyacının itirilməsi.

Texnoloji yanaşmalar həyat dövrünün həyata keçirilmə mexanizmləridir.

Texnoloji yanaşma, müxtəlif proqram siniflərinə və inkişaf qrupunun xüsusiyyətlərinə yönəlmiş mərhələlər və proseslərin birləşməsinin xüsusiyyətləri ilə müəyyən edilir.

Həyat dövrü mərhələləri (mərhələləri, mərhələləri) müəyyən edir ki, proqram məhsulu məhsul konsepsiyasının başlanğıcından başlayaraq onun qatlanması mərhələsinə qədər bir mərhələdən digərinə keçir.

Proqram təminatının inkişaf dövrü, mərhələlərin müxtəlif dərəcələri ilə təqdim edilə bilər. Ən sadə həyat dövrü görünüşü mərhələləri əhatə edir:

Dizayn

İcra

Test və ayıklama

Tətbiq, istismar və texniki xidmət.

Bir proqramın həyat dövrünün ən sadə təsviri (həyat dövrünün qorunması üçün kaskadlı texnoloji yanaşma):

Proseslər

Dizayn

Proqramlaşdırma

Test

Müşayiət

Analiz Dizayn Tətbiqi Testi Tətbiq Əməliyyatı

və ayıklama və təmir

Əslində burada hər mərhələdə tək bir proses aparılır. Aydındır ki, böyük proqramlar hazırlayarkən və yaradarkən belə bir sxem kifayət qədər düzgün deyil (tətbiq oluna bilməz), amma əsas götürülə bilər.

Analiz mərhələsi sistem tələblərinə diqqət yetirir. Tələblər müəyyən edilir və göstərilir (təsvir olunur). Sistem üçün funksional və məlumat modellərinin hazırlanması və inteqrasiyası davam edir. Bundan əlavə, qeyri-funksional və digər sistem tələbləri qeyd olunur.

Dizayn mərhələsi iki əsas alt mərhələyə bölünür: memarlıq və detallı dizayn. Xüsusilə, proqram dizaynı, istifadəçi interfeysi və məlumat strukturları təkmilləşdirilir. Sistemin anlaşılırlığını, saxlanılmasını və ölçeklenebilirliğini təsir edən dizayn məsələləri qaldırılır və qeyd olunur.

İcra mərhələsi proqram yazmaq daxildir.

Xüsusilə mərhələdə hardware və proqram fərqləri görünür istismar... İstehlak malları bazara çıxma, böyümə, yetkinlik və tənəzzül mərhələlərindən keçirsə, proqram təminatının ömrü daha çox bitməmiş, lakin daim tamamlanaraq yenilənən bir binanın (təyyarələrin) hekayəsinə bənzəyir. (Abunəçi).

Həyat dövrü proqramı beynəlxalq standartlar da daxil olmaqla bir çox standartlarla tənzimlənir.

Mürəkkəb proqram sistemlərinin həyat dövrünü standartlaşdırmaq məqsədi:

Bir çox mütəxəssisin təcrübəsinin və tədqiqat nəticələrinin ümumiləşdirilməsi;

Texnoloji proseslərin və inkişaf texnikalarının, habelə onların avtomatlaşdırılması üçün metodoloji bazanın inkişafı.

Standartlara daxildir:

İlkin məlumatların təsvir edilməsi qaydaları, əməliyyatların yerinə yetirilməsi üsul və üsulları;

Texnoloji proseslərə nəzarət qaydalarını müəyyən etmək;

Nəticələrin təqdim edilməsi üçün tələblər qurmaq;

Texnoloji və əməliyyat sənədlərinin məzmununu tənzimləmək;

İnkişaf qrupunun təşkilati quruluşunu müəyyənləşdirmək;

Tapşırıqların verilməsini və cədvəlini təmin etmək;

PS -nin yaradılmasının gedişatına nəzarət etmək.

Rusiyada həyat dövrünü tənzimləyən standartlar var:

Proqram inkişaf mərhələləri - GOST 19.102-77

AES -in inkişaf mərhələləri - GOST 34.601–90;

AU -nun yaradılması üçün texniki tapşırıqlar - GOST 34.602-89;

Dinamik test növləri - GOST 34.603-92;

Bununla birlikdə, İS üçün tətbiqli proqram sistemlərinin yaradılması, saxlanması və inkişafı bu standartlarda kifayət qədər əks olunmur və onların bəzi müddəaları, idarə və məlumatlarda yüksək keyfiyyətli tətbiq proqramlarının müasir paylanmış komplekslərinin qurulması baxımından köhnəlmişdir. fərqli quruluşa malik emal sistemləri.

Bu baxımdan ISO / IEC 12207-1999 beynəlxalq standartını qeyd etmək lazımdır - “ İnformasiya texnologiyaları- Proqram ömrü prosesləri ”.

ISO - Beynəlxalq Standartlaşdırma Təşkilatı - Beynəlxalq Standartlaşdırma Təşkilatı, IEC - Beynəlxalq Elektrotexniki Komissiya - Beynəlxalq Elektrotexniki Komissiya.

Proqram ömrü quruluşunu və proseslərini təyin edir.

Bunlar. proqram təminatı hazırlamaq o qədər də asan bir iş deyil, bu səbəbdən hər şeyin yazıldığı standartlar var: nə etmək lazımdır, nə vaxt və necə.

ISO / IEC 12207-95 beynəlxalq standartına uyğun olaraq proqram ömrü quruluşu üç qrup prosesə əsaslanır:

1) proqram ömrünün əsas prosesləri (satın alma, çatdırılma, inkişaf, istismar, təmir). Sonuncuya diqqət yetirəcəyik.

2) əsas proseslərin həyata keçirilməsini təmin edən köməkçi proseslər ( sənədləşdirmə, konfiqurasiya idarəçiliyi, keyfiyyət təminatı, yoxlama, doğrulama, birgə baxış (qiymətləndirmə), audit, problemlərin həlli).

1. Konfiqurasiya idarəçiliyibu proqram həyat dövrünün əsas proseslərini, ilk növbədə inkişaf etdirmə və texniki xidmət proseslərini dəstəkləyən bir proses. Hər birinin çeşidi və ya versiyası ola biləcək bir çox komponentdən ibarət kompleks proqram təminatı layihələri hazırlayarkən, əlaqələri və funksiyalarını nəzərə almaq, vahid (yəni vahid) bir quruluş yaratmaq və bütün inkişafını təmin etmək problemi ortaya çıxır. sistem. Konfiqurasiya idarəçiliyi, həyat dövrünün bütün mərhələlərində müxtəlif proqram komponentlərində dəyişiklikləri təşkil etməyə, sistematik şəkildə nəzərə almağa və nəzarət etməyə imkan verir.

2. Doğrulama tərəfindən əldə edilən proqramın cari vəziyyətinin olub olmadığını müəyyən etmək prosesidir bu mərhələ, bu mərhələnin tələbləri.

3. Sertifikatlaşdırma- konkret obyektlər üçün konkret tələblərin tam yerinə yetirildiyini obyektiv sübutların araşdırılması və təqdim edilməsi ilə təsdiq edilməsi.

4. Birgə analiz (qiymətləndirmə) – obyektin müəyyən edilmiş meyarlara uyğunluq dərəcəsinin sistematik şəkildə müəyyən edilməsi.

5. Audit- təmin etmək üçün səlahiyyətli orqan (şəxs) tərəfindən aparılan yoxlama müstəqil qiymətləndirmə proqram məhsullarının və ya proseslərin müəyyən edilmiş tələblərə uyğunluq dərəcəsi. İmtahan inkişaf parametrlərinin orijinal tələblərə uyğunluğunu qiymətləndirməyə imkan verir. Doğrulama, faktiki və gözlənilən nəticələr arasındakı fərqi müəyyən etmək və proqram xüsusiyyətlərinin orijinal tələblərə uyğun olub olmadığını qiymətləndirmək üçün edilən testlərlə üst -üstə düşür. Layihənin icrası prosesində vacib yer ayrı -ayrı komponentlərin və bütövlükdə bütün sistemin konfiqurasiyasının müəyyənləşdirilməsi, təsviri və nəzarəti məsələlərini öz üzərinə götürür.

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

Layihənin idarə olunması işin planlaşdırılması və təşkili, inkişaf etdiricilər qruplarının yaradılması və görülən işlərin vaxtına və keyfiyyətinə nəzarət ilə əlaqədardır. Layihənin texniki və təşkilati dəstəyi layihənin həyata keçirilməsi üçün metod və vasitələrin seçilməsini, inkişafın aralıq vəziyyətlərini təsvir etmək üsullarının müəyyənləşdirilməsini, yaradılmış proqram təminatının sınanması üçün metod və vasitələrin işlənməsini, kadr hazırlığını, və s. Layihənin keyfiyyət təminatı proqram komponentlərinin yoxlanılması, təsdiqlənməsi və sınanması ilə əlaqədardır.

Proqram təminatçısının ömrünü geliştirici baxımından nəzərdən keçirəcəyik.

Standarta uyğun olaraq inkişaf prosesi, geliştirici tərəfindən yerinə yetirilən hərəkətləri və tapşırıqları təmin edir və dizayn və istismar sənədlərinin hazırlanması da daxil olmaqla, müəyyən edilmiş tələblərə uyğun olaraq proqram təminatı və komponentlərinin yaradılması üzrə işləri əhatə edir. proqram məhsullarının performansını və keyfiyyətini yoxlamaq üçün lazım olan materiallardan, kadr hazırlığı üçün lazım olan materiallardan və s.

Standarta görə, bir IP proqramının həyat dövrü aşağıdakı hərəkətləri əhatə edir:

1) bir fikrin (konsepsiyanın) ortaya çıxması və araşdırılması;

2) hazırlıq mərhələsi - həyat dövrü modelinin, standartların, metodların və inkişaf vasitələrinin seçilməsi, habelə iş planının tərtib edilməsi.

3) informasiya sisteminin tələblərinin təhlili - onu müəyyən etmək

funksionallıq, istifadəçi tələbləri, etibarlılıq və təhlükəsizlik tələbləri, xarici interfeys tələbləri və s.

4) məlumat sistemi memarlıq dizaynı - kompozisiyanın təyin edilməsi lazımi avadanlıq, xidmət işçiləri tərəfindən həyata keçirilən proqram və əməliyyatlar.

5) proqram tələblərinin təhlili- performans xüsusiyyətləri, komponentlərin iş mühiti, xarici interfeyslər, etibarlılıq və təhlükəsizlik xüsusiyyətləri, erqonomik tələblər, istifadə olunan məlumatlara olan tələblər, quraşdırma, qəbul etmə, istifadəçi sənədləri, istismar və texniki xidmət daxil olmaqla funksionallığın tərifi.

6) proqram memarlıq dizaynı - proqram quruluşunu təyin etmək, komponentlərinin interfeyslərini sənədləşdirmək, istifadəçi sənədlərinin ilkin versiyasını, həmçinin test tələblərini və inteqrasiya planını hazırlamaq.

7) ətraflı proqram dizaynı - ətraflı

proqram komponentlərinin və aralarındakı interfeyslərin təsviri, istifadəçi sənədlərinin yenilənməsi, test tələblərinin və test planının, proqram komponentlərinin hazırlanması və sənədləşdirilməsi, komponent inteqrasiya planının yenilənməsi.

8) proqram kodlaşdırma -– inkişaf və sənədləşmə

hər bir proqram komponenti;

9)proqram testi - test prosedurları və onların test edilməsi, komponentlərin sınanması, istifadəçi sənədlərinin yenilənməsi, proqram inteqrasiya planının yenilənməsi üçün bir sıra test prosedurları və məlumatların hazırlanması;

10) proqram inteqrasiyası–uyğun olaraq proqram komponentlərinin yığılması

inteqrasiya planı və proqram uyğunluğu testi ixtisas tələbləri bir proqram məhsulunun spesifikasiyalarına cavab verən və müəyyən bir əməliyyat mühitində istifadəyə hazır olması üçün yerinə yetirilməli olan bir sıra meyarlar və ya şərtlərdir;

11) proqram kvalifikasiya testi – daxilində proqram testi

uyğunluğunu nümayiş etdirmək üçün müştərinin iştirakı

tələblər və işə hazırlıq; eyni zamanda texniki və istifadəçi sənədlərinin hazırlığı və tamlığı da yoxlanılır;

12) sistem inteqrasiyası – proqram sistemi və aparat daxil olmaqla informasiya sisteminin bütün komponentlərinin yığılması;

13) IP ixtisas testi – üçün sistemin sınanması

tələblərə uyğunluq və sənədlərin dizaynını və tamlığını yoxlamaq;

14) proqram quraşdırılması – müştərinin avadanlıqları üçün proqram təminatının quraşdırılması və onun işinin yoxlanılması;;

15) proqram qəbulu – ixtisaslı şəxslərin nəticələrinin qiymətləndirilməsi

proqram təminatını və məlumat sistemini bir bütün olaraq sınamaq və

qiymətləndirmə nəticələrinin müştəri ilə birlikdə sənədləşdirilməsi, proqramın sertifikatlaşdırılması və müştəriyə son təhvil verilməsi.

16) Sənədlərin idarə edilməsi və inkişafı;

17) istismar

18) müşayiət - yeni versiyaların yaradılması və tətbiqi prosesi

proqram məhsulu.;

19) əməliyyatın tamamlanması.

Proqram inkişafının aşağıdakı əsas mərhələlərini şərti olaraq vurğulayaraq bu hərəkətləri qruplaşdırmaq olar:

· Problemin ifadəsi (TZ) (GOST 19.102-77 mərhələsinə görə "Texniki tapşırıqlar")