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

Annotasiya.

Giriş.

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

Giriş.

Riley Proqramlaşdırma Prosesi Addımları

Giriş.

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

1.1.2. Həll dizaynı.

1.1.3. Alqoritm kodlaşdırması.

1.1.4. Proqram dəstəyi.

1.1.5. Proqram təminatı sənədləri.

1.1-ci bənd üzrə nəticə

1.2. Lehmana görə ZhTsPO-nun tərifi.

Giriş.

1.2.1 Sistemin tərifi.

1.2.2. İcra.

1.2.3. Xidmət.

1.2-ci bənd üzrə nəticə.

1.3. Boehm-ə görə Həyat Dövrü Proqramının Fazaları və İşləri

1.3.1. kaskad modeli.

1.3.2. İqtisadi əsaslandırma kaskad modeli.

1.3.3. Kaskad modelinin təkmilləşdirilməsi.

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

1.3.5. Layihə üzərində əsas iş.

Ədəbiyyat.

Giriş

Sənaye Tətbiqi kompüterlərə və proqramlara artan tələbat əhəmiyyətli artım üçün təcili vəzifələr qoydu proqram təminatının inkişafı məhsuldarlığı, proqramların planlaşdırılması və layihələndirilməsi üçün sənaye üsullarının işlənib hazırlanması, təşkilati, texniki, texniki, iqtisadi və sosial-psixoloji metodların, nümunələrin və metodların maddi istehsal sferasından EHM sahəsinə köçürülməsi. Kompleks yanaşma proqram təminatının işlənib hazırlanması, istismarı və saxlanması proseslərinə bir sıra aktual problemlər qoyur ki, onların həlli proqramların tərtibatındakı “darboğazları” aradan qaldıracaq, tamamlanma müddətini azaldacaq, mövcud proqramların seçilməsini və uyğunlaşdırılmasını təkmilləşdirəcək və bəlkə də quraşdırılmış kompüterləri olan sistemlərin taleyini müəyyən edə bilər.

Böyük proqram layihələrinin hazırlanması praktikasında çox vaxt yoxdur vahid yanaşma proqram təminatının işlənməsinin məhsuldarlığının artmasına mane olan əmək məsrəflərinin, iş müddətlərinin və material xərclərinin qiymətləndirilməsinə və son nəticədə - effektiv idarəetmə proqram təminatının həyat dövrü. İstənilən tipli proqram məhsula çevrildiyindən (bəlkə də tədris, maket proqramlar istisna olmaqla) onun istehsalına yanaşma sənaye məhsullarının istehsalına yanaşma ilə bir çox cəhətdən oxşar olmalıdır və proqram təminatının dizaynı məsələləri son dərəcə aktuallaşır. . Bu ideyanın əsasında B.U. Boem "Mühəndislik dizaynı proqram təminatı”, bunu yazarkən istifadə etdik kurs işi. Bu kitabda proqram təminatının dizaynı proqram məhsulu üçün dizaynın yaradılması prosesinə aiddir.

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

GİRİŞ

LCPE, proqram təminatının yaradılması zərurəti ilə bağlı qərar qəbul edildiyi andan başlayan və tamamilə əməliyyatdan çıxarıldığı anda başa çatan davamlı bir prosesdir.

Proqram təminatının həyat dövrünün (SLLC) mərhələlərini və fəaliyyətlərini, proqramlaşdırma prosesi addımlarını, şəlalə və spiral modelləri müəyyən etmək üçün bir neçə yanaşma var. Lakin onların hamısı ümumi fundamental komponentləri ehtiva edir: problemin ifadəsi, həllin dizaynı, həyata keçirilməsi, texniki xidmət.

Ən məşhur və tam, bəlkə də, səkkiz mərhələni əhatə edən Boehm-ə görə həyat dövrünün quruluşudur. Daha sonra daha ətraflı təqdim olunacaq.

Mümkün variantlardan biri üç əsas mərhələni özündə cəmləşdirən və ən ümumi halda həyat dövrü proqramının təsvirini əks etdirən Lehmana görə yuxarı səviyyənin təsviri ola bilər.

Dəyişiklik üçün burada D. Riley tərəfindən “Modula-2 Dilindən İstifadə” kitabında təqdim olunan proqramlaşdırma prosesinin addımları verilmişdir. Bu fikir, məncə, çox sadə və tanışdır və biz onunla başlayacağıq.

1.1 Riley Proqramlaşdırma Prosesi Addımları

Giriş

Proqramlaşdırma prosesi dörd addımdan ibarətdir (Şəkil 1):

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

artıq qoyulmuş problemin həllinin layihələndirilməsi (ümumiyyətlə, belə bir həll yekun proqramdan daha az formaldır);

proqramın kodlaşdırılması, yəni hazırlanmış həllin maşında icra oluna bilən proqrama tərcüməsi;

proqram dəstəyi, yəni. proqramdakı səhvləri düzəltmək və yeni funksiyalar əlavə etmək üçün davam edən bir proses.

düyü. 1. Dörd proqramlaşdırma addımı.

Proqramlaşdırma olduğu andan başlayır istifadəçi, yəni. problemi həll etmək üçün proqrama ehtiyacı olan biri problem yaradır sistem analitiki.İstifadəçi və sistem analitiki birlikdə problem bəyanatını müəyyənləşdirirlər. Sonuncu daha sonra köçürülür alqoritmçi həllin layihələndirilməsinə kim cavabdehdir. Həll (və ya alqoritm) icrası məsələnin həllinə gətirib çıxaran əməliyyatlar ardıcıllığıdır. Alqoritm çox vaxt maşında icra olunmaq üçün uyğunlaşdırılmadığı üçün onu maşın proqramına çevirmək lazımdır. Bu əməliyyat kodlayıcı tərəfindən həyata keçirilir. Baxıcı proqrama sonrakı dəyişikliklərə görə məsuliyyət daşıyır. proqramçı. Sistem analitiki, alqoritmçi, kodlaşdırıcı və onu müşayiət edən proqramçı - onların hamısı proqramçılardır.

Böyük bir proqram layihəsi vəziyyətində 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 proqram təminatının diqqətli dizaynının lehinə əlavə arqument rolunu oynayır: hər bir 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 qoyulmasıdır. O, istifadəçi və proqramçı(lar) arasında müqavilə kimi fəaliyyət göstərir. Qanuni cəhətdən zəif tərtib edilmiş müqavilə kimi, pis missiya bəyanatı da faydasızdır. Yaxşı bir problem ifadəsi ilə həm istifadəçi, həm də proqramçı yerinə yetiriləcək 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 bacardığı biliyə əsaslanaraq hələ yaradılmamış proqram təminatından istifadə etməyi planlaşdıra bilər. Problemin yaxşı ifadəsi onun həllinin formalaşması üçün əsas rolunu oynayır.

Problemin formalaşdırılması (proqram spesifikasiyası); mahiyyətcə konkret proqram icra edildikdə baş verənlərin dəqiq, tam və başa düşülən təsviri deməkdir. İstifadəçi adətən kompüterə qara qutu kimi baxır: onun üçün kompüterin necə işləməsinin heç bir əhəmiyyəti yoxdur, lakin kompüterin istifadəçini maraqlandıran şeyi edə bilməsi vacibdir. Əsas diqqət insan və maşın arasındakı qarşılıqlı əlaqədir.

Yaxşı problem bəyanatının xüsusiyyətləri:

Dəqiqlik, yəni. hər hansı qeyri-müəyyənliyin istisna edilməsi. Proqramın çıxışının hər hansı xüsusi giriş üçün nə olacağı ilə bağlı heç bir sual olmamalıdır.

tamlıq, yəni. səhv və ya gözlənilməz giriş daxil olmaqla, verilmiş giriş üçün bütün variantları nəzərdən keçirmək və müvafiq çıxışı müəyyən etmək.

Aydınlıq, yəni. həm istifadəçi, həm də sistem analitiki üçün başa düşülməlidir, çünki problemin ifadəsi onlar arasında yeganə müqavilədir.

Çox vaxt dəqiqlik, tamlıq və aydınlıq tələbləri ziddiyyət təşkil edir. Bəli, çox hüquqi sənədlər başa düşmək çətindir, çünki onlar bu və ya digər mövqeyi ən cüzi uyğunsuzluqları belə istisna etməklə, son dərəcə dəqiqliklə ifadə etməyə imkan verən rəsmi dildə yazılmışdır. Məsələn, imtahan vərəqlərindəki bəzi suallar bəzən o qədər dəqiq yazılır ki, tələbə sualı cavablandırmaqdansa, onu başa düşməyə daha çox vaxt sərf edir. Üstəlik, təfərrüatların çoxluğuna görə tələbə sualın əsas mənasını ümumiyyətlə qavraya bilməz. Ən yaxşı problem bəyanatı hər üç tələbin tarazlığına nail olandır.

Problemin ifadəsinin standart forması.

Problemin aşağıdakı ifadəsini nəzərdən keçirin: "Üç ədəd daxil edin və nömrələri ardıcıllıqla çıxarın."

Belə bir ifadə yuxarıda göstərilən tələblərə cavab vermir: nə dəqiq, nə tam, nə də başa düşülən deyil. Həqiqətən, nömrələr hər sətirə bir daxil edilməlidir, yoxsa bütün nömrələr bir sətirdə? "Sıra ilə" ifadəsi böyükdən kiçiyə, kiçikdən böyüyə sıralamağı və ya onların daxil edildiyi eyni sıranı nəzərdə tutur.

Aydındır ki, belə bir formula bir çox suallara cavab vermir. Bütün sualların cavablarını nəzərə alsaq, problemin ifadəsi sözlü və anlaşılması çətin olacaq. Buna görə də, D. Riley problemin qoyulması üçün maksimum dəqiqliyi, tamlığı, aydınlığı təmin edən və aşağıdakıları ehtiva edən standart formadan istifadə etməyi təklif edir:

tapşırığın adı (şematik tərif);

ümumi təsvir (tapşırığın qısa ifadəsi);

səhvlər (istifadəçilərə və proqramçılara maşının belə vəziyyətlərdə görəcəyi tədbirləri göstərmək üçün qeyri-adi giriş seçimləri açıq şəkildə siyahıya alınmışdır);

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

Misal. Problemin standart formada ifadəsi.

NAME

Üç tam ədədi çeşidləyin.

TƏSVİRİ

Ən kiçikdən böyüyə sıralanan üç tam ədədin daxil edilməsi və çıxışı.

Hər sətirdə bir ədəd olmaqla üç tam ədəd daxil edilir. Bu halda, tam ədəd bir və ya daha çox ardıcıl onluq rəqəmdir, ondan əvvəl "+" və ya mənfi işarəsi "-" ola bilər.

Daxil edilmiş üç tam ədəd çıxarılır, hər üçü eyni sətirdə göstərilir. Qonşu nömrələr boşluqla ayrılır. Nömrələr ən kiçikdən böyüyə, soldan sağa göstərilir.

1) Üçdən az rəqəm daxil edilərsə, proqram əlavə daxiletməni gözləyir.

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

3) Əgər ilk üç sətirdən hər hansı birində birdən çox tam ədəd varsa, o zaman proqram çıxış edir və mesaj verir.

KT-nin inkişafı müxtəlif xarakterli məlumatların emalı ilə bağlı həll edilməli olan tapşırıqların siniflərini daim genişləndirir.

Bunlar əsasən üç növ məlumat və müvafiq olaraq kompüterlərin istifadə olunduğu üç tapşırıq sinfidir:

1) Ədədi informasiyanın emalı ilə bağlı hesablama tapşırıqları. Bunlara, məsələn, yüksək ölçülü xətti tənliklər sisteminin həlli məsələsi daxildir. Əvvəllər kompüterlərin istifadəsinin əsas, dominant sahəsi idi.

2) Mətn məlumatlarının yaradılması, redaktəsi və çevrilməsi ilə əlaqəli simvolik məlumatların emalı üçün tapşırıqlar. Məsələn, katibə-makinaçının işi belə problemlərin həlli ilə bağlıdır.

3) Qrafik məlumatların emalı üçün tapşırıqlar i.e. diaqramlar, çertyojlar, 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 çertyojlarının işlənib hazırlanması tapşırığı daxildir.

4) Alfasayısal məlumatların emalı üçün tapşırıqlar - İS. Hazırda kompüterlərin əsas tətbiq sahələrindən birinə çevrilib və tapşırıqlar getdikcə mürəkkəbləşir.

Hər bir sinfin problemlərinin kompüter həlli öz xüsusiyyətlərinə malikdir, lakin əksər problemlər üçün xarakterik olan bir neçə mərhələyə bölünə bilər.

Proqramlaşdırma texnologiyasıbilik, üsul və vasitələrdən istifadə etməklə texnoloji prosesləri və onların keçmə (mərhələləri) qaydasını öyrənir.

Texnologiyalar rahat şəkildə iki ölçüdə xarakterizə olunur - şaquli (prosesləri təmsil edən) və üfüqi (mərhələləri təmsil edən).

Rəsm

Proses bəzi giriş məlumatlarını çıxış məlumatlarına çevirən bir-biri ilə əlaqəli hərəkətlər (texnoloji əməliyyatlar) məcmusudur. Proseslər hərəkətlər toplusundan (texnoloji əməliyyatlar) ibarətdir və hər bir hərəkət tapşırıqlar toplusundan və onların həlli üsullarından ibarətdir. Şaquli ölçü proseslərin statik aspektlərini əks etdirir və iş prosesləri, hərəkətlər, tapşırıqlar, performans nəticələri, icraçılar kimi anlayışlarla işləyir.

Mərhələ bu mərhələ üçün müəyyən edilmiş tələblərlə müəyyən edilmiş, müəyyən bir zaman çərçivəsi ilə məhdudlaşan və müəyyən bir məhsulun buraxılması ilə başa çatan proqram təminatının hazırlanması 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ə birləşdirilir. Deməli, üfüqi ölçü zamanı təmsil edir, proseslərin dinamik tərəflə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 fəaliyyət göstərir.

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

Həyat dövrü Proqram təminatı bəzi proqram təminatının yaradılması ideyasının (konsepsiyasının) meydana çıxdığı andan etibarən proqram təminatının hazırlanması və istismarı üçün hər bir layihə çərçivəsində həyata keçirilən və idarə olunan davamlı və sifarişli fəaliyyətlər toplusudur. yaratmaq lazımdır və aşağıdakı səbəblərə görə istismardan tamamilə çıxdığı anda başa çatır:

a) köhnəlmə;

b) müvafiq vəzifələrin həlli ehtiyacının itirilməsi.

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

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

Həyat dövrü mərhələləri (fazaları, mərhələləri) müəyyən edir ki, proqram məhsulu bir mərhələdən digərinə, məhsulun konsepsiyasından onun qatlama mərhələsinə keçsin.

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

Dizayn

İcra

Test və sazlama

İcra, istismar və texniki xidmət.

Proqramın həyat dövrünün ən sadə təsviri (həyat dövrünün idarə edilməsinə kaskad texnologiya yanaşması):

Proseslər

Dizayn

Proqramlaşdırma

Test

Müşayiət

Təhlil Dizayn Tətbiqetmə Testi İcra Əməliyyatı

və sazlama və texniki xidmət

Əslində, hər mərhələdə işləyən yalnız bir proses var. Aydındır ki, böyük proqramlar hazırlayarkən və yaratarkən belə bir sxem kifayət qədər düzgün deyil (uyğun deyil), lakin əsas götürülə bilər.

Təhlil mərhələsi sistem tələblərinə diqqət yetirir. Tələblər müəyyən edilir və dəqiqləşdirilir (təsvir olunur). Sistem üçün funksional modellərin və verilənlər modellərinin hazırlanması və inteqrasiyası həyata keçirilir. Bundan əlavə, qeyri-funksional və s sistem tələbləri.

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əşdirilmişdir. Sistemin başa düşülməsinə, davamlılığına və miqyasına təsir edən dizayn problemləri qaldırılır və düzəldilir.

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

Aparat və proqram təminatındakı fərqlər xüsusilə mərhələdə görünür istismar. Əgər istehlak malları buraxılış, böyümə, yetkinlik və tənəzzül mərhələlərindən keçirsə, proqram təminatının həyatı daha çox yarımçıq, lakin daim tamamlanan və yenilənən bir binanın (təyyarə) hekayəsinə bənzəyir. (Abunəçi).

Proqram təminatının həyat dövrü bir çox standartlarla, o cümlədən beynəlxalq standartlarla tənzimlənir.

Kompleks PS-nin həyat dövrünün standartlaşdırılmasının məqsədi:

Bir çox mütəxəssislərin təcrübəsini və tədqiqat nəticələrini ümumiləşdirmək;

İşdən çıxır texnoloji proseslər və inkişaf texnikaları, habelə onların avtomatlaşdırılmasının metodoloji əsasları.

Standartlara aşağıdakılar daxildir:

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

Prosesə nəzarət qaydalarını müəyyən etmək;

Nəticələrin təqdimatı üçün tələbləri müəyyən etmək;

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

Müəyyən edin təşkilati strukturu inkişaf qrupu;

Tapşırıqların bölüşdürülməsini və planlaşdırılmasını təmin etmək;

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

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

Proqram təminatının inkişaf mərhələləri - GOST 19.102-77

AS-nin yaradılması mərhələləri - GOST 34.601-90;

AS-nin yaradılması üçün TK - GOST 34.602-89;

Test növləri AS - GOST 34.603-92;

Bununla belə, bu standartlarda ƏM üçün tətbiqi proqram təminatının yaradılması, saxlanması və inkişafı kifayət qədər öz əksini tapmamışdır və onların bəzi müddəaları tətbiqi proqramların müasir paylanmış sistemlərinin qurulması baxımından köhnəlmişdir. Yüksək keyfiyyət müxtəlif arxitekturalı idarəetmə və məlumatların emalı sistemlərində.

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

ISO - Beynəlxalq Standartlaşdırma Təşkilatı - beynəlxalq təşkilat standartlaşdırma üzrə, IEC - Beynəlxalq Elektrotexniki Komissiya - Beynəlxalq Elektrotexniki Komissiya.

O, proqram təminatının həyat dövrünün strukturunu və onun proseslərini müəyyən edir.

Bunlar. proqram təminatı yaratmaq o qədər də asan məsələ deyil, buna görə də hər şeyin yazıldığı standartlar var: nə etmək lazımdır, nə vaxt və necə.

Proqram təminatının həyat dövrünün strukturuna görə beynəlxalq standart ISO/IEC 12207-95 üç proses qrupuna əsaslanır:

1) proqram təminatının həyat dövrünün əsas prosesləri (alınması, təchizatı, inkişaf, istismar, texniki xidmət). 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ər, konfiqurasiyanın idarə edilməsi, keyfiyyətin təminatı, yoxlama, yoxlama, birgə nəzərdən keçirmə (qiymətləndirmə), audit, problemin həlli).

1. Konfiqurasiyanın idarə edilməsiBu proqram təminatının həyat dövrünün əsas proseslərini, ilk növbədə inkişaf və texniki xidmət proseslərini dəstəkləyən proses. Hər birinin çeşidləri və ya versiyaları ola bilən çoxlu komponentlərdən ibarət kompleks proqram layihələri hazırlayarkən, onların əlaqələrini və funksiyalarını nəzərə almaq, vahid (yəni vahid) struktur yaratmaq və bütün sistemin inkişafını təmin etmək problemi yaranır. Konfiqurasiyanın idarə edilməsi onun 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ə onlara nəzarət etməyə imkan verir.

2. Doğrulama müəyyən mərhələdə əldə edilmiş proqram təminatının cari vəziyyətinin həmin mərhələnin tələblərinə cavab verib-vermədiyini müəyyən etmək prosesidir.

3. Sertifikatlaşdırma– konkret obyektlərə qoyulan xüsusi tələblərin tam yerinə yetirildiyinin yoxlanılması və obyektiv sübutların təqdim edilməsi yolu ilə təsdiq edilməsi.

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

5. Audit- uyğunluq dərəcəsinin müstəqil qiymətləndirilməsini təmin etmək üçün səlahiyyətli orqan (şəxs) tərəfindən həyata keçirilən yoxlama proqram məhsulları və ya müəyyən edilmiş tələblərə uyğun proseslər. İmtahan inkişaf parametrlərinin ilkin 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ərqləri müəyyən etmək və proqram xüsusiyyətlərinin orijinal tələblərə cavab verib-vermədiyini qiymətləndirmək üçün həyata keçirilən sınaq ilə üst-üstə düşür. Layihənin həyata keçirilməsi prosesində ayrı-ayrı komponentlərin və bütövlükdə bütün sistemin konfiqurasiyasının müəyyən edilməsi, təsviri və nəzarəti məsələləri mühüm yer tutur.

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ən edilmə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, tərtibatçılar qruplarının yaradılması və yerinə yetirilən işlərin vaxtına və keyfiyyətinə nəzarət məsələləri ilə bağlıdır. Layihənin texniki və təşkilati dəstəyi layihənin həyata keçirilməsi üçün üsul və vasitələrin seçimini, 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ınaqdan keçirilməsi üçün metod və vasitələrin işlənib hazırlanmasını, kadr hazırlığını və s. . Layihənin keyfiyyət təminatı proqram komponentlərinin yoxlanılması, yoxlanılması və sınaqdan keçirilməsi problemləri ilə bağlıdır.

Proqram təminatının həyat dövrünü tərtibatçının nöqteyi-nəzərindən nəzərdən keçirəcəyik.

Standarta uyğun olaraq inkişaf prosesi tərtibatçının yerinə yetirdiyi hərəkətləri və tapşırıqları nəzərdə tutur və müəyyən edilmiş tələblərə uyğun olaraq proqram təminatının və onun komponentlərinin yaradılmasını, o cümlədən dizayn və istismar sənədlərinin hazırlanmasını, proqram məhsullarının keyfiyyətinin işləkliyini və uyğunluğunu yoxlamaq üçün lazım olan materiallar, kadr hazırlığı üçün lazım olan materiallar və s.

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

1) ideyanın (konsepsiya) yaranması və öyrənilməsi;

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 sisteminə tələblərin təhlili - onu müəyyən edir

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

4) informasiya sisteminin arxitekturasının dizaynı - tərkibinin müəyyən edilməsi zəruri avadanlıq, proqram təminatı və xidmət personalı tərəfindən həyata keçirilən əməliyyatlar.

5) proqram təminatı tələblərinin təhlili- performans xüsusiyyətləri, komponentin əməliyyat mühiti, xarici interfeyslər, etibarlılıq və təhlükəsizlik spesifikasiyası daxil olmaqla funksionallığın müəyyən edilməsi, erqonomik tələblər, verilənlərdən istifadə tələbləri, quraşdırma, qəbul, istifadəçi sənədləri, istismar və texniki xidmət.

6) proqram arxitekturasının dizaynı - proqram təminatının strukturunun müəyyən edilməsi, onun komponentlərinin interfeyslərinin sənədləşdirilməsi, istifadəçi sənədlərinin ilkin versiyasının, həmçinin sınaq tələblərinin və inteqrasiya planının işlənib hazırlanması.

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

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

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

hər bir proqram komponenti;

9)proqram təminatı testi – test prosedurları və onların sınaqdan keçirilməsi üçün verilənlər toplusunun hazırlanması, komponentlərin sınaqdan keçirilməsi, istifadəçi sənədlərinin yenilənməsi, proqram təminatının inteqrasiya planının yenilənməsi;

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

uyğunluq üçün inteqrasiya planı və proqram təminatı testi ixtisas tələbləri, proqram məhsulunun spesifikasiyalara uyğun olması və verilmiş iş şəraitində istifadəyə hazır olması üçün yerinə yetirilməli olan meyarlar və ya şərtlər toplusudur;

11) proqram təminatının ixtisas testi – proqram təminatının sınaqdan keçirilməsi

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

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

12) sistem inteqrasiyası – bütün komponentlərin yığılması məlumat Sistemi proqram təminatı və avadanlıq da daxil olmaqla;

13) IP kvalifikasiya sınağı – üçün sistem testi

ona olan tələblərə uyğunluq və sənədlərin dizaynının və tamlığının yoxlanılması;

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

15) proqram təminatının qəbulu – ixtisaslı nəticələrin qiymətləndirilməsi

ümumən proqram təminatı və informasiya sisteminin sınaqdan keçirilməsi və

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

16) Sənədləşmənin idarə edilməsi və işlənib hazırlanması;

17) əməliyyat

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

proqram məhsulu.;

19) əməliyyatın başa çatması.

Bu tədbirlər proqram təminatının inkişafının aşağıdakı əsas mərhələlərini şərti olaraq vurğulamaqla qruplaşdırıla bilər:

tapşırığın bəyanatı (TOR) (GOST 19.102-77 "Texniki tapşırıqlar" mərhələsinə uyğun olaraq)

Annotasiya.

Giriş.

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

Giriş.

Riley Proqramlaşdırma Prosesi Addımları

Giriş.

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

1.1.2. Həll dizaynı.

1.1.3. Alqoritm kodlaşdırması.

1.1.4. Proqram dəstəyi.

1.1.5. Proqram təminatı sənədləri.

1.1-ci bənd üzrə nəticə

1.2. Lehmana görə ZhTsPO-nun tərifi.

Giriş.

1.2.1 Sistemin tərifi.

1.2.2. İcra.

1.2.3. Xidmət.

1.2-ci bənd üzrə nəticə.

1.3. Boehm-ə görə Həyat Dövrü Proqramının Fazaları və İşləri

1.3.1. kaskad modeli.

1.3.2. Kaskad modelinin iqtisadi əsaslandırılması.

1.3.3. Kaskad modelinin təkmilləşdirilməsi.

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

1.3.5. Layihə üzərində əsas iş.

Ədəbiyyat.

Giriş

Kompüterlərin sənaye tətbiqi və proqramlara artan tələbat əhəmiyyətli artım üçün təcili vəzifələr qoydu proqram təminatının inkişafı məhsuldarlığı, proqramların planlaşdırılması və layihələndirilməsi üçün sənaye üsullarının işlənib hazırlanması, təşkilati, texniki, texniki, iqtisadi və sosial-psixoloji metodların, nümunələrin və metodların maddi istehsal sferasından EHM sahəsinə köçürülməsi. Kompleks yanaşma proqram təminatının işlənib hazırlanması, istismarı və saxlanması proseslərinə bir sıra aktual problemlər qoyur ki, onların həlli proqramların tərtibatındakı “darboğazları” aradan qaldıracaq, tamamlanma müddətini azaldacaq, mövcud proqramların seçilməsini və uyğunlaşdırılmasını təkmilləşdirəcək və bəlkə də quraşdırılmış kompüterləri olan sistemlərin taleyini müəyyən edə bilər.

Böyük proqram layihələrinin hazırlanması praktikasında çox vaxt yoxdur vahid yanaşma proqram təminatının işlənməsinin məhsuldarlığının artmasına mane olan əmək məsrəflərinin, iş müddətlərinin və material məsrəflərinin qiymətləndirilməsinə və son nəticədə proqram təminatının həyat dövrünün səmərəli idarə olunmasına. İstənilən tipli proqram məhsula çevrildiyindən (bəlkə də tədris, maket proqramlar istisna olmaqla) onun istehsalına yanaşma sənaye məhsullarının istehsalına yanaşma ilə bir çox cəhətdən oxşar olmalıdır və proqram təminatının dizaynı məsələləri son dərəcə aktuallaşır. . Bu ideyanın əsasında B.U. Bu kurs işini yazarkən istifadə etdiyimiz Boehm "Mühəndislik Proqramının Dizaynı". Bu kitabda proqram təminatının dizaynı proqram məhsulu üçün dizaynın yaradılması prosesinə aiddir.

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

GİRİŞ

LCPE, proqram təminatının yaradılması zərurəti ilə bağlı qərar qəbul edildiyi andan başlayan və tamamilə əməliyyatdan çıxarıldığı anda başa çatan davamlı bir prosesdir.

Ən məşhur və tam, bəlkə də, səkkiz mərhələni əhatə edən Boehm-ə görə həyat dövrünün quruluşudur. Daha sonra daha ətraflı təqdim olunacaq.

1.1 Riley Proqramlaşdırma Prosesi Addımları

Proqramlaşdırma prosesi dörd addımdan ibarətdir (Şəkil 1):

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

artıq qoyulmuş problemin həllinin layihələndirilməsi (ümumiyyətlə, belə bir həll yekun proqramdan daha az formaldır);

proqramın kodlaşdırılması, yəni hazırlanmış həllin maşında icra oluna bilən proqrama tərcüməsi;

proqram dəstəyi, yəni. proqramdakı səhvləri düzəltmək və yeni funksiyalar əlavə etmək üçün davam edən bir proses.

düyü. 1. Dörd proqramlaşdırma addımı.

Proqramlaşdırma olduğu andan başlayır istifadəçi, yəni. problemi həll etmək üçün proqrama ehtiyacı olan biri problem yaradır sistem analitiki.İstifadəçi və sistem analitiki birlikdə problem bəyanatını müəyyənləşdirirlər. Sonuncu daha sonra köçürülür alqoritmçi həllin layihələndirilməsinə kim cavabdehdir. Həll (və ya alqoritm) icrası məsələnin həllinə gətirib çıxaran əməliyyatlar ardıcıllığıdır. Alqoritm çox vaxt maşında icra olunmaq üçün uyğunlaşdırılmadığı üçün onu maşın proqramına çevirmək lazımdır. Bu əməliyyat kodlayıcı tərəfindən həyata keçirilir. Müşayiət edən proqramçı proqrama sonrakı dəyişikliklərə görə məsuliyyət daşıyır. Sistem analitiki, alqoritmçi, kodlaşdırıcı və onu müşayiət edən proqramçı - onların hamısı proqramçılardır.

1.1.1 Problemin ifadəsi

Yaxşı problem bəyanatının xüsusiyyətləri:

Dəqiqlik, yəni. hər hansı qeyri-müəyyənliyin istisna edilməsi. Proqramın çıxışının hər hansı xüsusi giriş üçün nə olacağı ilə bağlı heç bir sual olmamalıdır.

tamlıq, yəni. səhv və ya gözlənilməz giriş daxil olmaqla, verilmiş giriş üçün bütün variantları nəzərdən keçirmək və müvafiq çıxışı müəyyən etmək.

Aydınlıq, yəni. həm istifadəçi, həm də sistem analitiki üçün başa düşülməlidir, çünki problemin ifadəsi onlar arasında yeganə müqavilədir.

Çox vaxt dəqiqlik, tamlıq və aydınlıq tələbləri ziddiyyət təşkil edir. Beləliklə, bir çox hüquqi sənədləri başa düşmək çətindir, çünki onlar hətta ən əhəmiyyətsiz uyğunsuzluqlar istisna olmaqla, müəyyən müddəaları son dərəcə dəqiqliklə tərtib etməyə imkan verən rəsmi dildə yazılmışdır. Məsələn, imtahan vərəqlərindəki bəzi suallar bəzən o qədər dəqiq yazılır ki, tələbə sualı cavablandırmaqdansa, onu başa düşməyə daha çox vaxt sərf edir. Üstəlik, təfərrüatların çoxluğuna görə tələbə sualın əsas mənasını ümumiyyətlə qavraya bilməz. Ən yaxşı problem bəyanatı hər üç tələbin tarazlığına nail olandır.

Problemin ifadəsinin standart forması.

Problemin aşağıdakı ifadəsini nəzərdən keçirin: "Üç ədəd daxil edin və nömrələri ardıcıllıqla çıxarın."

tapşırığın adı (şematik tərif);

ümumi təsvir (tapşırığın qısa ifadəsi);

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

Misal. Problemin standart formada ifadəsi.

NAME

Üç tam ədədi çeşidləyin.

TƏSVİRİ

Ən kiçikdən böyüyə sıralanan üç tam ədədin daxil edilməsi və çıxışı.

Hər sətirdə bir ədəd olmaqla üç tam ədəd daxil edilir. Bu halda, tam ədəd bir və ya daha çox ardıcıl onluq rəqəmdir, ondan əvvəl "+" və ya mənfi işarəsi "-" ola bilər.

Daxil edilmiş üç tam ədəd çıxarılır, hər üçü eyni sətirdə göstərilir. Qonşu nömrələr boşluqla ayrılır. Nömrələr ən kiçikdən böyüyə, soldan sağa göstərilir.

1) Üçdən az rəqəm daxil edilərsə, proqram əlavə daxiletməni gözləyir.

düyü. 5.2.

Bu aspektlər bunlardır:

sifarişçi ilə təchizatçının müqavilə münasibətlərinə girdiyi və satınalma və çatdırılma proseslərinin həyata keçirildiyi müqavilə aspekti;
proqram təminatının həyat tsiklində iştirak edən şəxslərin (təchizatçı, sifarişçi, tərtibatçı, operator və s.) idarəetmə hərəkətlərini əhatə edən idarəetmə aspekti;
sistemin istifadəçilərinə xidmət göstərmək üçün operatorun hərəkətlərini özündə əks etdirən əməliyyat aspekti;
proqram məhsullarının inkişafı və ya dəyişdirilməsi ilə bağlı texniki problemlərin həlli üçün tərtibatçının və ya dəstək xidmətinin hərəkətlərini ehtiva edən mühəndislik aspekti;
dəstək xidmətlərinin işin bütün digər iştirakçılarına lazımi xidmətləri təqdim etdiyi dəstək proseslərinin həyata keçirilməsi ilə əlaqəli dəstəyin aspekti. Bu aspektdə keyfiyyət təminatı prosesləri, yoxlama, sertifikatlaşdırma, birgə qiymətləndirmə və audit daxil olmaqla proqram təminatının keyfiyyətinin idarə edilməsi aspektini ayırmaq olar.

Üzərində təşkilati proseslər həyata keçirilir korporativ səviyyə və ya bütövlükdə bütün təşkilat səviyyəsində proqram təminatının həyat dövrü proseslərinin həyata keçirilməsi və davamlı təkmilləşdirilməsi üçün zəmin yaradır.

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

Proqram təminatının həyat dövrü modeli dedikdə proqram təminatının həyat dövrü ərzində icra ardıcıllığını və proseslərin, hərəkətlərin və tapşırıqların əlaqəsini müəyyən edən struktur başa düşülür. Həyat dövrü modeli layihənin xüsusiyyətlərindən, miqyasından və mürəkkəbliyindən, sistemin yaradıldığı və işlədiyi xüsusi şəraitdən asılıdır.

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

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

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

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

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

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

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

Layihədən əvvəl planlaşdırma işləri. Mərhələnin əsas vəzifələri inkişaf məqsədlərinin müəyyən edilməsi, ilkindir iqtisadi qiymətləndirmə layihə, iş qrafikinin qurulması, birgə işçi qrupunun yaradılması və təlimi.
Gələcək sistem üçün tələblərin ilkin müəyyənləşdirilməsi, təşkilatın strukturunun müəyyən edilməsi, təşkilatın hədəf funksiyalarının siyahısının müəyyənləşdirilməsi, təhlili, avtomatlaşdırılmış təşkilatın (obyektin) fəaliyyətinin sorğusunun aparılması. funksiyaların şöbələr və işçilər tərəfindən bölüşdürülməsi, şöbələr arasında funksional qarşılıqlı əlaqənin, şöbə daxilində və onlar arasında məlumat axınlarının, təşkilatdan kənar obyektlərin və xarici informasiya təsirlərinin müəyyən edilməsi, təşkilatın fəaliyyətinin avtomatlaşdırılması üçün mövcud vasitələrin təhlili.

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

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

Modellərin hər biri təşkilatın fəaliyyətinin tam funksional və informasiya modelini, eləcə də (zəruri hallarda) təşkilatın davranış dinamikasını təsvir edən modeli ehtiva etməlidir. Qeyd edək ki, qurulmuş modellər, müəssisənin informasiya sistemini işləyib-hazırlayıb tətbiq etməməsindən asılı olmayaraq müstəqil praktiki əhəmiyyət kəsb edir, çünki onlardan işçilərin təlimi və müəssisənin biznes proseslərinin təkmilləşdirilməsi üçün istifadə oluna bilər.

Proqram təminatı tələblərinin formalaşması mərhələsinin başa çatmasının nəticəsi proqram təminatının spesifikasiyası, funksional, texniki və interfeys spesifikasiyasıdır ki, bunun üçün onların tamlığı, yoxlanılması və həyata keçirilməsinin mümkünlüyü təsdiqlənir.

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

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

Sistem layihəsinin əsasını layihələndirilmiş sistemin “TO-BE” modeli üzərində qurulan modelləri təşkil edir. Sistem layihəsinin inkişafının nəticəsi proqram təminatı tələblərinin təsdiq edilmiş və təsdiq edilmiş spesifikasiyası olmalıdır: funksional, texniki və interfeys spesifikasiyası, onların tamlığı, yoxlanılması və mümkünlüyü təsdiqlənir.
Ətraflı (texniki) layihənin hazırlanması. Bu mərhələdə sistem arxitekturasının dizaynı və detallı dizayn daxil olmaqla faktiki proqram təminatının dizaynı həyata keçirilir. Beləliklə, sualın cavabı verilir: "Sistemi necə qurmaq olar ki, tələbləri ödəsin?"

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

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

Təfərrüatlı dizayn mərhələsinin başa çatması başa çatır

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

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

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

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

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

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

Layihədən əvvəl planlaşdırma işləri. Mərhələnin əsas vəzifələri inkişaf məqsədlərinin müəyyən edilməsi, layihənin ilkin iqtisadi qiymətləndirilməsi, iş qrafikinin qurulması, birgə işçi qrupunun yaradılması və təlimidir.
Gələcək sistem üçün tələblərin ilkin müəyyənləşdirilməsi, təşkilatın strukturunun müəyyən edilməsi, təşkilatın hədəf funksiyalarının siyahısının müəyyənləşdirilməsi, təhlili, avtomatlaşdırılmış təşkilatın (obyektin) fəaliyyətinin sorğusunun aparılması. funksiyaların şöbələr və işçilər tərəfindən bölüşdürülməsi, şöbələr arasında funksional qarşılıqlı əlaqənin, şöbə daxilində və onlar arasında məlumat axınlarının, təşkilatdan kənar obyektlərin və xarici informasiya təsirlərinin müəyyən edilməsi, təşkilatın fəaliyyətinin avtomatlaşdırılması üçün mövcud vasitələrin təhlili.

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

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

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

Proqram təminatı sistemi layihəsinin hazırlanması. Bu mərhələdə “Gələcək sistem nə etməlidir?” sualına cavab verilir, yəni: sistemin arxitekturası, onun funksiyaları, xarici iş şəraiti, interfeyslər və istifadəçilərlə sistem arasında funksiyaların paylanması, proqram təminatına qoyulan tələblər. və informasiya komponentləri, ifaçıların tərkibi və son tarixlər müəyyən edilir.inkişaf, proqram təminatının sazlanması planı və keyfiyyətə nəzarət.

Sistem layihəsinin əsasını layihələndirilmiş sistemin “TO-BE” modeli üzərində qurulan modelləri təşkil edir. Sistem layihəsinin inkişafının nəticəsi proqram təminatı tələblərinin təsdiq edilmiş və təsdiq edilmiş spesifikasiyası olmalıdır: funksional, texniki və interfeys spesifikasiyası, onların tamlığı, yoxlanılması və mümkünlüyü təsdiqlənir.
Ətraflı (texniki) layihənin hazırlanması. Bu mərhələdə sistem arxitekturasının dizaynı və detallı dizayn daxil olmaqla faktiki proqram təminatının dizaynı həyata keçirilir. Beləliklə, sualın cavabı verilir: "Sistemi necə qurmaq olar ki, tələbləri ödəsin?"

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

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

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

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

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

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

düyü. 1.

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

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

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

düyü. 2.

Formalaşma və təhlil mərhələlərində müəyyən edilmiş hazırlanmış PS-yə olan tələblər ciddi şəkildə TOR şəklində sənədləşdirilir və layihənin inkişafının bütün müddəti üçün müəyyən edilir. Hər bir mərhələ, inkişafın başqa bir inkişaf qrupu tərəfindən davam etdirilməsi üçün kifayət qədər tam sənədlər toplusunun (TOR, EP, TP, RP) buraxılması ilə başa çatır. Bu yanaşma ilə inkişaf keyfiyyətinin meyarı TOR-un spesifikasiyalarının yerinə yetirilməsinin dəqiqliyidir. Tərtibatçıların əsas diqqəti hazırlanmış PS-nin texniki xüsusiyyətlərinin optimal dəyərlərinə nail olmağa yönəldilmişdir - performans, işğal edilmiş yaddaş miqdarı və s.

Üstünlüklər şəlalə modeli:

hər mərhələdə tam dəst formalaşır layihə sənədləri tamlıq və ardıcıllıq meyarlarına cavab verən ;
məntiqi ardıcıllıqla yerinə yetirilən işlərin mərhələləri bütün işlərin tamamlanma vaxtını və müvafiq xərcləri planlaşdırmağa imkan verir.

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

Qüsurlar şəlalə modeli:

səhvlərin müəyyən edilməsi və aradan qaldırılması yalnız sınaq mərhələsində həyata keçirilir ki, bu da əhəmiyyətli dərəcədə genişləndirilə bilər;
real layihələr tez-tez standart addımlar ardıcıllığından kənara çıxmağı tələb edir;
dövr PS üçün ilkin tələblərin dəqiq formalaşdırılmasına əsaslanır, əslində layihənin başlanğıcında müştərinin tələbləri yalnız qismən müəyyən edilir;
işin nəticələri yalnız layihə başa çatdıqdan sonra sifarişçiyə təqdim olunur.

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

Kommersiya layihələrinin böyüməsi ilə aydın oldu ki, gələcək sistemin layihəsini hər zaman ətraflı şəkildə işləmək mümkün deyil, çünki sistem yaradılarkən onun dinamik fəaliyyət sahələrində (biznesdə) işləməsinin bir çox aspektləri dəyişir. İnkişafın istənilən mərhələsi başa çatdıqdan sonra lazımi düzəlişlərin edilməsini təmin etmək üçün inkişaf prosesini dəyişdirmək lazım idi. Beləliklə, PS-nin həyat dövrünün iterativ modeli meydana çıxdı, aralıq idarəetmə ilə model və ya fazaların tsiklik təkrarlanması ilə model adlanır.

düyü. 3.

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

düyü. 4.

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

Prototipləşdirmə

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

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

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

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

düyü. 5.

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

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

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

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

düyü. 6.

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

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

Proqram təminatının dizayn strategiyaları

Proqram təminatı sistemlərinin qurulması üçün üç strategiya var:

tək keçid (yuxarıda müzakirə olunan kaskad strategiyası) - dizayn addımlarının xətti ardıcıllığı;
artan strategiya. Prosesin başlanğıcında bütün istifadəçi və sistem tələbləri müəyyən edilir, tikintinin qalan hissəsi bir sıra versiyalar kimi həyata keçirilir. Birinci versiya planlaşdırılmış funksiyaların bəzilərini həyata keçirir, sonrakı versiya əlavə funksiyaları həyata keçirir və s. tam sistem əldə olunana qədər;
təkamül strategiyası. Sistem həmçinin bir sıra versiyalar kimi qurulub, lakin prosesin əvvəlində bütün tələblər müəyyən edilməyib. Tələblər versiyaların hazırlanması nəticəsində müəyyən edilir. IEEE/EIA 12207 standartının tələblərinə uyğun proqram təminatının layihələndirilməsi strategiyalarının xüsusiyyətləri Cədvəl 1-də göstərilmişdir.

artan model

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

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

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

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

düyü. 7.

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

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

düyü. 8.

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

İnteqrasiya aspekti spiral modeli spiralın radial ölçüsünü nəzərə aldıqda aydın olur. Spiral boyunca hər iterasiya ilə PS-nin getdikcə daha tam versiyaları qurulur. Spiralın ilk növbədə ilkin məqsədlər, seçimlər və məhdudiyyətlər müəyyən edilir, risk tanınır və təhlil edilir. Risk təhlili tələblərin qeyri-müəyyənliyini aşkar edərsə, dizayn kvadrantında istifadə olunan prototipləmə tərtibatçı və müştərinin köməyinə gəlir.

Modelləşdirmə problemli və dəqiqləşdirilmiş tələbləri daha da müəyyən etmək üçün istifadə edilə bilər. Müştəri mühəndislik (dizayn) işini qiymətləndirir və dəyişikliklər üçün təkliflər verir (müştəri qiymətləndirmə kvadrantı). Planlaşdırma və risk təhlilinin növbəti mərhələsi müştərilərin təkliflərinə əsaslanır. Spiraldan keçən hər bir dövrədə risk təhlilinin nəticələri “davam et, davam etmə” şəklində formalaşır. Əgər risk çox böyükdürsə, layihə dayandırıla bilər.

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

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

– ilkin tələblərin toplanması və layihənin planlaşdırılması;
– eyni iş, lakin müştərinin tövsiyələri əsasında;
– ilkin tələblər əsasında risk təhlili;
– müştəri reaksiyasına əsaslanan risk təhlili;
- keçid inteqrasiya olunmuş sistem;
– sistemin ilkin tərtibatı;
- tərtibatın növbəti səviyyəsi;
- layihələndirilmiş sistem;
- Müştəri tərəfindən qiymətləndirmə.

Üstünlüklər spiral modeli:

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

Qüsurlar spiral modeli:

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

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

Lakin bunun üçün çox böyük vəsait tələb olunur. Doğrudan da, əgər əvvəllər ehtiyac olduqda mütəxəssislər qruplarını yaratmaq və ləğv etmək mümkün idisə, indi onların hamısı layihədə daim iştirak etməlidirlər: memarlar, proqramçılar, testçilər, təlimatçılar və s. Bundan başqa, səylər müxtəlif qruplar dizayn qərarlarını vaxtında əks etdirmək və lazımi dəyişiklikləri etmək üçün sinxronlaşdırılmalıdır.

Rasional vahid proses

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

RUP spiral proqram inkişaf metodologiyalarından biridir. Metodologiya Rational Software tərəfindən saxlanılır və hazırlanır. Ümumi Bilik Bazası modelləşdirmə dili kimi Vahid Modelləşdirmə Dilindən (UML) istifadə edir. RUP-da təkrarlanan və artan proqram təminatının inkişafı layihənin ardıcıl icra olunan bir neçə layihəyə bölünməsini nəzərdə tutur və hər bir inkişaf iterasiyası iterasiyanın sonunda əldə ediləcək məqsədlər toplusu ilə aydın şəkildə müəyyən edilir. Yekun iterasiya hesab edir ki, iterasiyanın məqsədləri toplusu məhsulun müştərisi tərəfindən müəyyən edilmiş məqsədlər toplusuna tam uyğun olmalıdır, yəni bütün tələblər yerinə yetirilməlidir.

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

Bu rəqəm iki ölçünü göstərir: üfüqi ox vaxtı təmsil edir və prosesin həyat dövrünün müvəqqəti aspektlərini göstərir; şaquli ox prosesin fiziki strukturunu müəyyən edən fənləri təmsil edir. Layihədəki vurğunun zamanla necə dəyişdiyini görə bilərsiniz. Məsələn, erkən təkrarlamalar tələblərə daha çox vaxt sərf edir; sonrakı iterasiyalarda icraya daha çox vaxt ayrılır. Üfüqi ox zaman dövrlərindən - hər biri müstəqil inkişaf dövrü olan iterasiyalardan formalaşır; dövrün məqsədi maraqlı tərəflərin nöqteyi-nəzərindən faydalı olan son məhsula əvvəlcədən müəyyən edilmiş bəzi dəqiqləşdirmələr gətirməkdir.

düyü. 9.

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

Başlanğıc (Başlanğıc) - layihə konsepsiyasının formalaşması, nə yaratdığımızı başa düşmək, məhsul haqqında fikir (vizion), biznes planın hazırlanması (biznes işi), layihənin hazırlanması. prototip proqramı və ya qismən həll. Bu, məlumatların toplanması və tələblərin təhlili, bütövlükdə layihənin imicinin müəyyənləşdirilməsi mərhələsidir. Məqsəd dəstək və maliyyə almaqdır. Son təkrarlamada bu mərhələnin nəticəsi texniki tapşırıqdır.
Dizayn, inkişaf (İnkişaf) - planın aydınlaşdırılması, onu necə yaratdığımızı başa düşmək, layihələndirmək, lazımi hərəkətləri və resursları planlaşdırmaq, xüsusiyyətlərin detallaşdırılması. Səhnə bütün memarlıq qərarlarının qəbul edildiyi və risklərin nəzərə alındığı icra edilə bilən bir memarlıqla başa çatır. İcra edilə bilən arxitektura əsas memarlıq qərarlarının həyata keçirilməsini nümayiş etdirən proqram təminatıdır. Son iterasiyada bu texniki layihədir.
Sistemin həyata keçirilməsi, yaradılması (Tikinti) arxitekturaya daxil edilmiş sistemin funksionallığının genişləndirilməsi mərhələsidir. Son təkrarlamada bu, işləyən bir layihədir.
Həyata keçirmə, yerləşdirmə (Keçid). Məhsulun son versiyasının yaradılması. Məhsulun tətbiqi mərhələsi, məhsulun konkret istifadəçiyə çatdırılması (replikasiya, çatdırılma və təlim).

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

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

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

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

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

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

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

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

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

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

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

MSF (Microsoft Solution Framework)

1994-cü ildə İT layihələrindən maksimum yararlanmaq üçün Microsoft öz texnologiyası əsasında qurulmuş həllərin effektiv şəkildə layihələndirilməsi, işlənib hazırlanması, həyata keçirilməsi və saxlanması üçün bir sıra təlimatlar buraxdı. Bu bilik Microsoft-un iri proqram təminatının hazırlanması və texniki xidmət layihələri üzərində işləyərkən əldə etdiyi təcrübəyə, Microsoft məsləhətçilərinin təcrübəsinə və İT sənayesinin bu günə qədər topladığı ən yaxşı təcrübəyə əsaslanır. Bütün bunlar bir-biri ilə əlaqəli və bir-birini tamamlayan iki bilik sahəsi şəklində təqdim olunur: Microsoft Solutions Framework (MSF) və Microsoft Operations Framework (MOF).

Qeyd etmək lazımdır ki, Microsoft əsasında inkişaf etmişdir ümumi üsullar Tətbiqi və xüsusi tətbiqlər üçün MSF metodologiyaları. Bundan əlavə, Microsoft MSF-nin tətbiqi sahəsində tətbiqi biliklərə görə mütəxəssisləri sertifikatlaşdırır (məsələn, layihənin idarə edilməsi metodologiyasında ekspertiza üçün MCTS 74-131 sertifikatı). MSF üsulları haqqında məlumat əldə etməzdən əvvəl, ilk növbədə hansı MSF tətbiqini nəzərdə tutduğunuzu müəyyənləşdirməlisiniz.

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

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

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

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

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

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

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

MSF proses modeli daim dəyişən layihə tələblərini nəzərə alır. O, ondan irəli gəlir ki, bir həllin inkişafı, həllin ən sadə versiyalarından son formasına qədər mütərəqqi bir hərəkət yaradan qısa dövrlərdən ibarət olmalıdır.

MSF proses modelinin xüsusiyyətləri bunlardır:

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

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

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

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

bu mərhələnin nəticəsi nədir (hansı əsərlər);
rol klasterlərinin hər biri bu mərhələdə nə üzərində işləyir.

MSF daxilində kod, sənədlər, dizaynlar, planlar və digər iş materialları adətən iterativ şəkildə yaradılır. MSF sizə onun əsas funksionallığını qurmaq, sınaqdan keçirmək və tətbiq etməklə həlli inkişaf etdirməyə başlamağı tövsiyə edir. Sonra həllə getdikcə daha çox xüsusiyyət əlavə olunur. Bu strategiya versiya strategiyası adlanır. Kiçik layihələr üçün tək buraxılış kifayət ola bilsə də, bir həll üçün birdən çox versiya yaratmaq fürsətini qaçırmamağınız tövsiyə olunur. Yeni versiyaların yaradılması ilə həllin funksionallığı inkişaf edir.

İnkişaf prosesinə iterativ yanaşma çevik sənədlərin istifadəsini tələb edir. Son məhsula olan tələblərin dəyişməsi ilə birlikdə layihə inkişaf etdikcə canlı sənədlər dəyişməlidir. MSF məhsulun inkişafının hər bir mərhələsinin artefaktları olan və inkişaf prosesini planlaşdırmaq və idarə etmək üçün istifadə edilə bilən bir sıra standart sənəd şablonları təklif edir.

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