Mürəkkəb proqram sistemlərinin həyat dövrü sistemin yaradılması ideyasından başlayır, layihələndirmə, proqramlaşdırma, tətbiq və sistemin müşayiət edilməsi ilə sona çatır. Sistemin həyat dövrü modelini ardıcıl yerinə yetirilən mərhələlərə bölürlər. Hər mərhələdə yerinə yetiriləcək proseslər, məsələlər və işlər göstərilir, həmin işlərin sona çatması yeni mərhələyə keçməklə nəticələnir.
Proqramların həyat dövrünün xassə və xüsusiyyətlərinə görə onları bir sıra sinif və kateqoriyalara bölürlər, bunlardan ikisi daha çox əhəmiyyət kəsb edir: kiçik və böyük sinif proqramlar.
Kiçik sinif proqramlara çox da böyük olmayan, ayrı-ayrı insanlar və ya kiçik kollektivlər (3-5 nəfər) tərəfindən yaradılan proqramlar daxildir. Bu proqramlar aşağıda göstərilən xüsusiyyətlərə malikdir:
- Elmi tədqiqatların avtomatlaşdırılmasında konkret nəticələr almaq və ya proqramçıların özlərinin hər hansı bir sadə prosesi təhlil etməsi məqsədilə yaradılır;
- Bazarda proqram məhsulu kimi kütləvi şəkildə yayılmaq üçün nəzərdə tutulmayıb və onlara keyfiyyətinə görə qiymət verilir;
- Qiymətini və ona olan tələbləri təyin etmək üçün konkret sifarişçilər yoxdur;
- Sifarişçi tərəfindən proqramın qiyməti və yaradılma müddəti məhdudlaşdırılmır, keyfiyyətə tələblərin qoyulması, sənədləşdirmə və s. tələb olunmur;
- Testləşdirmə, keyfiyyətə zəmanət və ya sertifikatlaşdırma tələb olunmur.
Yuxarıda göstərilənlərə əsaslanaraq deyə bilərik ki, kiçik sinif proqramlar üçün onların həyat dövrünün reqlamentləşdirilməsi, versiyalarının yenilənməsi, müxtəlif standartların tətbiq edilməsi, keyfiyyətin sertifikatlaşdırılması zərurəti yoxdur.
İIkinci sinif proqram məhsullarına mürəkkəb sistemlərin idarə edilməsi və informasiyanın emalı üçün yaradılmış böyük miqyaslı proqram kompleksləri aiddir. Bu proqramların keyfiyyətinə zəmanət verilir və onlar həyat dövrünün aşağıda göstərilən xüsusiyyətlərinə görə fərqlənirlər:
- Belə komplekslərin böyük ölçülü olması, əmək tutumu və yaradılma qiymətinin yüksək olması, onların bütün həyat dövrünün iqtisadi effektivliyinin və bazarda mümkün ola biləcək rəqabətə davamlılığının hərtərəfli təhlil edilməsi tələbatını yaradır;
- Proqram vasitələrini və ya verilənlər bazası layihəsini maliyyələşdirən sifarişçilər layihənin və məhsulun funksiya və xüsusiyyətlərinə konkret tələblər qoyurlar. Proqramı işləyən mütəxəssislər ayrılan maliyyəyə və layihənin icraçılarının ixtisas səviyyəsinə müvafiq olaraq bu tələbləri təmin etməlidirlər;
- Vahid və böyük ölçülü proqram vasitələrini işləyən mütəxəssislərin fəaliyyətinin təşkil edilməsi, uzlaşdırılması və mükəmməl proqram məhsulu yaratmaq üçün ixtisaslı layihə menecerləri lazımdır;
- Mürəkkəb proqram və verilənlər bazası layihələrinin yaradılmasında müxtəlif ixtisaslı mütəxəssislər işləyə bilər və bunların hər birindən layihənin nəticəsinə görə yüksək dərəcədə cavabdehlik tələb olunur;
- Layihəni işləyənlərdən sifarişçinin və istifadəçilərin dəyişiklik etmək üçün müdaxiləsinə icazə verilməyən komponentlərin və proqram məhsulunun tətbiqinin təhlükəsizliyinə, fəaliyyətinin etibarlılığına və keyfiyyətinin yüksək olmasına zəmanət tələb olunur;
- Proqram komplekslərinin həyat dövründə standartlarla reqlamentləşdirilmiş proseslər, mərhələlər və sənədlər, eyni zamanda metod, metodika, avtomatlaşdırma vasitələri və texnologiyalar tətbiq edilməlidir.
Proqram təminatının (PT) həyat dövrünü modellər şəklində göstərmək olar. Model - proqram məhsulunun işlənilməsi, tətbiqi və müşayiət edilməsi zamanı istifadə ediləcək fəaliyyət və məsələləri özündə birləşdirən bir strukturdur. Modelin düzgün seçilməsi PT yaradılmasında birinci vacib addımdır. Proqram təminatı modellərinin aşağıdakı tipləri var:
- İşlərin ardıcıl yerinə yetirilmə modeli. Bu modeldə PT yaradılmasında yerinə yetiriləcək mərhələlərin ardıcıllığı, hər bir mərhələnin başlanğıcı və sonu və bu mərhələlər arasında asılılıq göstərilir;
- Verilənlər və proseslər axınının modeli. Burada PT-nin yaradılması proseslər çoxluğu kimi verilir və hər prosesdə verilənlər dəyişilərək növbəti mərhələyə ötürülür. Hər prosesdə verilənlərin dəyişilməsini PT-ni işləyənlər də, kompüter də yerinə yetirə bilər;
- Rol modeli. PT-nin yaradılması prosesində iştirak edən insanların rolları və bu rollarda onların yerinə yetirəcəyik işlər təyin edilir.
Birinci tip modellərdə proqram məhsulunun yaradılması üçün yerinə yetiriləcək fəaliyyətin ardıcıllığı verilir. Bunlardan ən məşhurları aşağıdakılardır:
1. Kaskad (şəlalə) modeli;
2. Spiral (dövri) modeli;
3. Komponent modeli.
Kaskad (şəlalə model) Proses ardıcıl yerinə yetirilən mərhələlərə bölünür. Hər mərhələ əvvəlki mərhələ yerinə yetirildikdən sonra başlayır, sonuncu mərhələnin bitməsi ilə məhsulun yaradılması sona çatır və o, əvvəlcədən qoyulmuş tələblərə müvafiq olmalıdır. Hər mərhələnin nəticəsi sənədləşdirilməlidir. İlk dəfə bu model haqqında U.U. Roys 1970-ci ildə öz məqaləsində məlumat verib.
Modelin çatışmayan cəhəti mərhələlər arasında əks-əlaqənin olmamasıdır. Çox zaman əvvəlki mərhələlərə qayıtmaq tələbatı yaranır. Məsələn, layihələndirmə mərhələsində sistem tələblərinin dəyişdirilməsi lazım ola bilər və ya proqramın kodlaşdırılması zamanı elə problemlər yarana bilər ki, bunu ancaq layihələndirmə mərhələsində aradan qaldırmaq mümkün olsun. Hər mərhələdə müəyyən işlər görülür və sənədləşdirilir, mərhələyə təkrar qayıdıb yenidən işlənilməsi xərcləri artırır.
PT-nin həyat dövrünün son mərhələsi proqramın istifadəyə verilməsidir. Bu mərhələdə əvvəlki mərhələlərdə (məsələn, birinci mərhələdə) yol verilmiş xətalar aşkarlanır. Bunu aradan qaldırmaq üçün dəyişikliklərin edilməsi bir neçə mərhələnin, bəzən bütün mərhələlərin təkrar işlənilməsini tələb edə bilər. Bu səbəbdən də kaskad modeli ancaq tələblər kifayət qədər dəqiq və düzgün göstərildikdə tətbiq edilir. Spiral (dövri) modeli. Proses yenə də mərhələlərə bölünür, lakin bunlar ardıcıl olaraq bir neçə dəfə təkrarlana bilər (şəkil 2). Birinci dövrdə ümumi tələblər əsasında proqram məhsulu yaradılır. Sonra həmin tələblər sifarişçinin istəyinə uyğun olaraq dəqiqləşdirilir. Proqram sistemi yenidən işlənilir və yeni tələblərə müvafiq olaraq attestasiyadan keçirilir. Növbəti dövrlərdə proqram tələblərə tam cavab verənədək.
Bu model iki cür işlənilə bilər:
1. Nümunələrin işlənilməsi ilə. Burada proqram məhsulunun son versiyasının hazırlanmasında lazım olan bütün tələblərin təyin edilməsi üçün sifarişçi (istifadəçi) ilə daim əlaqə saxlamaq vacib şərtlərdəndir. Belə yanaşmada əvvəlcə sistemin tələbləri aydın və dəqiq göstərilən hissələri işlənilir. Sonra sifarişçinin istəyinə uyğun olaraq ona əlavələr edilir;
2. Prototipin yaradılması. Prototip - nümunəlik obyektdir. Onun nümunəsində ona oxşar olaraq digər obyektlər yaradılır. Tələblər dəqiq məlum olmadıqda və ya tərəddüdlər olduqda onlar əsasında müəyyən bir prototip yaradılır. Sonra dəyişən tələblərə uyğun olaraq onu təkmilləşdirirlər.
Spiral modeli əsasında PT-nin işlənilməsinin üstünlüyü ondan ibarətdir ki, istifadəçi tələbləri istənilən mərhələdə dəyişə bilər. Spiral modeli əsasında PT-nin işlənilməsinin çatışmayan cəhətləri aşağıda göstərilib:
1. PT-nin yaradılma prosesinin bəzi mərhələləri sənədləşdirilmir. PT-nin yaradılması üzrə layihə menecerləri işlərin yerinə yetirilməsini sənədlərlə fasiləsiz olaraq izləyirlər, sənədləşdirilməyən mərhələlər diqqətdən kənarda qalır. Tələblərdən asılı olaraq sistem tez-tez dəyişdirilirsə, onların hamısını sənədləşdirmək iqtisadi cəhətdən sərfəli deyil;
2. Sistemin strukturu qarışıq olur. Tələblərin tez-tez dəyişməsi strukturda xətaların olmasına gətirib çıxarır. Müəyyən bir vaxtdan sonra strukturda dəyişiklik etmək çətinləşir və artıq xərc tələb edir;
3. PT-nin işlənilməsinin xüsusi və texnologiyaları tələb olunur. Bu proqramın versiyası tez-tez dəyişməsi ilə əlaqədardır. Tətbiq ediləcək bəzi texnologiyalar arasında uyğunsuzluqlar ola bilər.
Spiral modeli çox da böyük olmayan proqram sistemlərində tətbiq edilə bilər. Böyük sistemlərdə kaskad və spiral modeldən qarışıq şəkildə istifadə edilə bilər. Proqram sisteminin tələblərin dəqiq verildiyi hissələrində kaskad modeli, tələblərin qeyri-müəyyən olan hissəsində spiral modeli tətbiq edilir. Məsələn, istifadəçi interfeysinin spiral modeli əsasında işlənilməsi daha əlverişlidir.
Komponent modeli proqram məhsulunun əvvəlcədən yazılmış komponentlərdən yaradılmasından ibarətdir. Bu zaman proqram sisteminin əsas komponentləri əvvəlcədən işlənilmiş olur. PT-ni yaradarkən diqqət bu komponentlərin yaradılmasına deyil, bir yerə yığılmasına və birgə sınaqdan keçirilməsinə verilir. Komponent - sərbəst yerinə yetirilə bilən proqram obyektidir. Komponentin ilkin kodu əlyetərli olmaya bilər, ona görə də proqramın digər hissələri ilə kompilyasiya olunmur.
Proqram layihələrinin əksəriyyətində bəzi proqram komponentlərindən təkrar istifadə edilə bilər. Proqram məhsulunu işləyənlər qoyulan tələblərə təxminən uyğun gələn hazır proqram komponentlərində yeni tələblərə uyğun olaraq bəzi dəyişikliklər edirlər. Sonra onu yeni proqram sisteminə əlavə edirlər. Bu modeldə tələblərin təyin edilməsi və attestasiya prosesi digər modellərdə olduğu kimidir. Onlar arasındakı mərhələlər isə aşağıdakı kimi yerinə yetirilir:
Komponentlərin təhlili. Tələblər təyin edildikdən sonra bu tələblərə cavab verəcək hazır proqram komponentləri axtarılır. Adətən tələblərə tam cavab verən proqram komponenti tapmaq mümkün deyil;
Tələblərin dəyişdirilməsi. Tələblər elə dəyişdirilir ki, götürülmüş komponentlərin imkanlarından tam istifadə etmək mümkün olsun. Əgər tələblərin dəyişdirilməsi mümkün deyilsə, müəyyən alternativ həlli tapmaq üçün yenidən komponentlərin təhlili aparılır;
Sistemin layihələndirilməsi. Yaradılacaq sistemin strukturu layihələndirilir və yaxud da təkrar istifadə ediləcək sistemin strukturu yeniləndirilir;
Sistemin işlənilməsi və yığılması. Proqram sistemi işlənilir və hazır komponentlər sistemə əlavə edilir.
Bu modelin əsas üstünlüyü ondadır ki, işləniləcək komponentlərin sayı azalır və yaradılacaq sistemin qiyməti aşağı düşür. Lakin tələblərdə bəzi dəyişikliklərin edilməsi sifarişçinin narazılığına səbəb ola bilər. Gələcəkdə sistemi təkmilləşdirərkən əlavə edilən komponentlərin yeni versiyalarının işlənilmə imkanının olmaması təkmilləşdirmə prosesini çətinləşdirə bilər.
Bu modellər arasında fərq ancaq nəzəriyyədədir. Təcrübədə isə spiral modeldə kaskad və komponent modelinin elementlərindən də istifadə edilə bilər. Həyat dövrünün hər bir modeli ardıcıl, təkrar və qarışıq şəkildə istifadə edilə bilən proseslərdən ibarətdir.
PT-nin yaradılmasına çəkilən xərclərin strukturu proqram təminatını yaradılmasında istifadə edilən proseslərdən və işlənilən proqram məhsulunun tipindən asılıdır. Əgər PT-nin yaradılma qiymətini şərti olaraq 100 vahid kimi götürsək, hər mərhələyə çəkilən xərclər aşağıdakı kimi göstərilə bilər.
Xərclərin bu cür strukturu tələb, layihələndirmə, işlənilmə və testləşmənin qiymətini ayrılıqda hesabladıqda olur. Qeyd etmək lazımdır ki, çox vaxt sınağın qiyməti PT-nin işlənilmə qiymətindən çox olur. Məsələn, xərclərin təxminən 40%-i sınağa düşür, bununla yanaşı, bəzi kritik sistemlərdə bu xərclər 50%-dən çox ola bilər.
Təkamül modeldən istifadə etdikdə tələb, layihələndirmə və işlənilmənin qiymətlərini dəqiq təyin etmək olmur (şəkil 5). Burada əvvəldə göstərilən tələb mərhələsi ümumi tələbləri göstərir. Digər tələblər, layihələndirmə, işlənilmə və sınaq isə paralel yerinə yetirilir. Bundan sonra sistem bütövlükdə sınaqdan keçirilir. PT-nin yaradılma qiymətinə istismardan sonra onun təkamülünə çəkilən xərclər də daxil ola bilər.
Sistemə qoyulan tələblər
Proqram sistemlərinə qoyulan funksional imkanların və məhdudiyyətlərin müəyyən olunması sistemə qoyulan tələblər, funksional imkan və məhdudiyyətlərin formalaşdırılması, təhlili, sənədləşdirilməsi, yoxlanılması isə tələblərin təhlili (requirements engineering) adlanır. Tələblər aşağıda göstərilən növlərə bölünür:
1. İstifadəçi tələbləri (user requirements) - sistemin yerinə yetirəcəyi funksiya və məhdudiyyətlərin adi dildə (diaqramlarla da ola bilər) təsviri;
2. Sistem tələbləri (system requirements) - sistemin funksiya və məhdudiyyətlərinin təfsilatı ilə təsviri, bunu çox zaman funksional xüsusiyyətlər də adlandırırlar. Bu tələblər sistemi, PT-ni alan ilə işləyən arasında kontraktın bağlanması üçün əsas olur;
3. Layihə - sistem tələbləri (Project - system requirements) - proqram sisteminin strukturunun ümumiləşdirilmiş təsviridir, sistemin daha mükəmməl layihələndirilməsi və həyata keçirilməsi zamanı vasitə kimi istifadə edilir.
Bütün tələblər sənədləşdirilməlidir. Tələblərdən ibarət olan bu sənəd sistem tələblərinin spesifikasiyası da adlandırılır və sistemi işləyənlər üçün rəsmi təlimatdır. Burada istifadəçi tələbləri və sistem tələblərinin bütün təfsilatı ilə təsviri göstərilir. Bir neçə təşkilat tərəfindən tələblərin sənədləşdirilməsinə dair standartlar işlənilmişdir. Bunlardan ən çox tanınanı “İEEE/ANSİ 830-1993” standartıdır.
Sistemin layihələndirilməsi
Sistemin layihələndirilməsi layihənin planının işlənilməsindən başlayır.
Ümumiyyətlə, planda aşağıda göstərilən bölmələr olmalıdır:
- Giriş. Layihənin idarə edilməsi üçün layihənin məqsədlərinin və məhdudiyyətlərinin (büdcə, vaxt və s.) qısa təsviri;
- Layihənin yerinə yetirilməsinin təşkili. Layihəni işləyəcək komandanın seçilmə qaydasının təsviri və komanda üzvləri arasında vəzifələrin bölünməsi;
- Risklərin təhlili. Mümkün ola biləcək risklərin, onların yaranma ehtimalının azaldılmasına yönəldilən strategiyaların təsviri;
- Layihənin reallaşdırılması üçün lazım olan aparat və proqram resurslarının təsviri. Əgər aparat vasitələrini almaq lazım gələrsə, onların qiymətinin də layihənin qiymətinə əlavə edilməsi;
- İşlərin mərhələlərə bölünməsi. Hər mərhələnin yerinə yetirilmə müddətinin təyin edilməsi.
Layihələndirmə prosesi aşağıda göstərilən ardıcıllıqla yerinə yetirilir.
- Sistemin arxitekturunun layihələndirilməsi. Altsistemlər və onlar arasındakı qarşılıqlı əlaqə təyin edilir və sənədləşdirilir;
- Altsistemlərə qoyulan tələblərin təyin edilməsi. Hər altsistem üçün onun göstərəcəyi xidmət və məhdudiyyətlər müəyyən edilir və sənədləşdirilir;
- İstifadəçi interfeysinin layihələndirilməsi. Hər altsistem üçün elə interfeys işlənilir ki, onlardan istifadə edərkən bu sistemlərin öz funksiyalarını necə yerinə yetirdikləri barədə biliklərə ehtiyac yaranmasın;
- Komponentlərin layihələndirilməsi. Altsistemlərin funksiyaları müxtəlif komponentlər arasında bölünür və onlar sənədləşdirilir; - Verilənlərin strukturunun layihələndirilməsi. Proqram sisteminin reallaşdırılması üçün lazım olan verilənlərin strukturu təfsilatı ilə müəyyən edilir və işlənilir;
- Alqoritmin işlənilməsi.
Altsistem - fəaliyyəti digər sistemlər tərəfindən göstərilən xidmətlərdən asılı olmayan sistemdir. Altsistem modullardan ibarətdir və digər altsistemlərlə qarşılıqlı əlaqə saxlamaq üçün müəyyən interfeysə malikdir.
Modul - sistemin komponentidir. Modul digər modullar tərəfindən dəstəklənən xidmətlərdən istifadə edə bilər. Adətən modula sərbəst sistem kimi baxılmır. Modullar daha sadə komponentlərdən təşkil olunur.
Sistemin arxitekturasının düzgün layihələndirilməsi aşağıda göstərilən xarakteristikalara təsir edir:
1. Məhsuldarlıq. Əgər ən vacib tələb məhsuldarlıqdırsa, elə arxitektura işlənilməlidir ki, o, aralarındakı qarşılıqlı əlaqənin maksimal dərəcədə az olduğu mümkün qədər az sayda altsistemlərdən ibarət olsun. Komponentlər arasındakı qarşılıqlı əlaqəni azaltmaq üçün xırda struktur elementlərindən deyil, böyük modullu komponentlərdən istifadə etmək daha məqsədəuyğun olur;
2. Mühafizə olunma. Bu halda arxitektura çoxsəviyyəli struktura malik olmalıdır. Burada sistemin ən böhranlı elementləri daxili səviyyələrdə qorunur, bu səviyyələrin təhlükəsizliyi isə daha yuxarı səviyyədə yoxlanılır;
3. Təhlükəsizlik. Bu halda sistemin arxitekturunu elə layihələndirmək lazımdır ki, onun təhlükəsizliyinə təsir edən bütün əməliyyatlara cavabdeh olan mümkün qədər az altsistem yaradılsın. Belə yanaşma proqramın işlənilməsinin qiymətini aşağı salır və etibarlılığın yoxlanılması problemini aradan qaldırır;
4. Etibarlılıq. Bu halda arxitekturu lazım olduğundan artıq komponentlər daxil etməklə elə işləmək lazımdır ki, sistemin işini dayandırmadan onları dəyişmək və yeniləmək mümkün olsun;
5. Müşayiət edilmənin rahatlığı. Bu halda sistemi xırda struktur komponentləri səviyyəsində layihələndirmək lazımdır ki, onu asanlıqla dəyişmək olsun. Verilənləri yaradan proqram, bu verilənlərdən istifadə edən proqramdan ayrılmalıdır.
Bəzi hallarda sistem bir neçə tələbə cavab verməli olur, bu zaman bu, arxitekturalarda ziddiyyət yaradır, məsələn, sistemin həm məhsuldarlığı, həm də müşayiət edilmənin rahatlığı tələb olunarsa. Belə hallarda kompromis həllərdən istifadə edilir.
Sistemin sınağı və attestasiya
Sınaq və attestasiya proqram təminatının qoyulan tələblərə cavab verib-vermədiyini yoxlamaq üçün keçirilən təhlil və yoxlama prosesləridir. Sınaq və attestasiya PT-nin bütün həyat dövrünü əhatə edir - tələblərin təhlilindən başlayıb, hazır proqram kodunun yoxlanılması ilə sona çatır. Sınaq və attestasiya anlayışlarını eyniləşdirmək olmaz:
1. Sınaq sistemin düzgün yaradılıb-yaradılmadığını yoxlamaq üçün keçirilir;
2. Attestasiya sistemin düzgün işləyib-işləmədiyini yoxlayır.
Buna müvafiq olaraq demək olar ki, sınaq sistemin funksional və qeyri-funksional tələblərə uyğunluğunu yoxlayır, attestasiya isə daha ümumi proses olub proqram məhsulunun sifarişçinin istəklərinə uyğun olub-olmamasını yoxlayır.
Sınaq və attestasiya proseslərində iki yoxlama metodundan istifadə olunur:
1. PT-nin təftiş edilməsi - sistemin müxtəlif hissələrinin (məsələn, tələblərin spesifikasiyasının sənədləşdirilməsi, arxitektur sxemlər və ya ilkin kodun) təhlili və yoxla-nılması. Yoxlanılma proqram sisteminin işlənilməsinin bütün mərhələlərində yerinə yetirilir. Yoxlanılma statik metoddur, belə ki, onun üçün icra olunan sistem tələb olunmur;
2. PT-nin sınaqdan keçirilməsi - sınaq verilənlərini daxil edərək sistemin işə salınması və sistemin düzgün işlədiyini yoxlamaq üçün çıxış verilənləri əsasında proqram məhsulunun işçi xarakteristikalarının yoxlanılması. Sınaqdan keçirmə dinamik metoddur.
Sınaq aşağıda göstərilən ardıcıllıqla yerinə yetirilir:
- Komponentlərin sınaqdan keçirilməsi. Hər bir komponent ayrı-ayrılıqda sınaqdan keçirilir.
- Modulların sınaqdan keçirilməsi. Proqram modulu qarşılıqlı əlaqəli olan komponentlərdən təşkil edilir. Hər modul ayrılıqda sınaqdan keçirilir.
- Altsistemlərin sınaqdan keçirilməsi. Altsistemlər modullardan təşkil olunur. Bu mərhələdə ən çox rast gəlinən xəta modulların interfeysləri arasındakı uyğunsuzluqların yaranmasıdır. Ona görə də bu interfeyslər bütün iş rejimlərində yoxlanılır.
- Sistemin sınağı. Altsistemlərdən sistem yığılır. Sistem sınaqdan keçirilən zaman əsasən altsistemlərin interfeysləri arasında uyğunsuzluqlar və altsistemlərin birgə işləməsi zamanı proqram kodunda yaranan xətalar aşkar edilir. Bu mərhələdə sistemin attestasiyası da aparılır, yəni sistemin tələblərə uyğun olub-olmadığı və sistemin xarakteristikaları yoxlanılır.
- Sistemin qəbul edilməsi üçün sınağın keçirilməsi. Bu son mərhələdir, bundan sonra sistem istismar üçün qəbul edilir. Bu mərhələdə sistem sifarişçinin verilənləri əsasında sınaqdan keçirilir. Bu zaman müxtəlif problemlər yarana bilər.
Sistemin idarə edilməsi
Effektiv menecment - şirkətin heyətinin effektiv idarə edilməsindən ibarətdir. Menecerlər - layihə rəhbərləri texniki problemlərlə yanaşı, texniki hissəyə aid olmayan məsələləri də həll etməlidirlər, bu zaman komandanın üzvlərindən optimal effektivliklə istifadə olunmalıdır. Onlar insanların işini təşkil etməyi və onun keyfiyyətlə yerinə yetiriləcəyini təmin etməyi bacarmalıdırlar. Zəif menecment proqram layihələrinin müvəffəqiyyətsizliyinin əsas səbəblərindən biridir.
Proqram üzərində effektiv işləyə biləcək komandanın yaradılması menecer üçün kifayət qədər çətin məsələdir. Aşağıda qrup şəklində işləməyə təsir edən amillər verilib:
- Komandanın tərkibi. Komandada vərdiş, təcrübə və şəxsi keyfiyyətlərin nisbəti eyni olmalıdır;
- Komandanın yekdilliyi. İşçi qrupun üzvləri özlərini ayrı-ayrı fərdlərin yığımı kimi deyil, eyni problem üzərində çalışan vahid komanda kimi qəbul etməlidirlər;
- Komandada ünsiyyət. Komandanın üzvləri arasında dost münasibətləri olmalıdır;
- Komandanın təşkil edilməsi. Komandanı elə təşkil etmək lazımdır ki, hər bir kəs özünün dəyərli olduğunu başa düşsün və komandadakı rolundan razı qalsın.
Proqram məhsulunun keyfiyyətinin idarə edilməsi
Proqram məhsulunun keyfiyyəti mürəkkəb anlayışdır və təyin edilməsi çətindir. Adətən məhsul texniki tələblərə tam cavab verdikdə keyfiyyətli sayılır. Bu tərifi proqram məhsullarına da aid etmək olar, lakin qarşıya bəzi problemlər çıxır:
1. Proqramı işləyən müəssisənin məhsula öz tələbləri ola bilər (məsələn, müşayiət etmənin sadəliyi) və adətən bunlar sifarişçinin texniki tələblərində göstərilmir;
2. Bəzi keyfiyyət göstəricilərinin təyin edilməsi və ölçülməsi məlum deyil (məsələn, müşayiət etmənin sadəliyi);
3. Proqram məhsulunun tələblərini tam əhatə etmək mümkün olmur. Buna görə də proqram məhsulunun tam olaraq göstərilən tələblərə cavab verməsinə baxmayaraq sifarişçi keyfiyyətdən narazı qala bilər.
Keyfiyyətin idarə edilməsi prosesi üç fəaliyyət növündən ibarətdir:
1. Keyfiyyətin təmin edilməsi. Yüksək keyfiyyətli PT yaratmaq məqsədilə təşkilati prosedur və standartlar çoxluğunun təyin edilməsi;
2. Keyfiyyətin planlaşdırılması. Bu çoxluqdan verilən PT-nin işlənilməsi üçün prosedur və standartların düzgün seçilməsi;
3. Keyfiyyətə nəzarət. PT-ni işləyən komandanın bütün üzvləri tərəfindən normativ prosedur və standartların yerinə yetiriləcəyinə zəmanət verən tədbirlərin keçirilməsi.
Keyfiyyətin idarə edilməsinin baza standartı kimi Standartlaşdırma üzrə Beynəlxalq Təşkilat (İSO) tərəfindən işlənilmiş İSO 9000 götürülə bilər.
Keyfiyyətin təmin edilməsi prosesində iki tip standartdan istifadə edilə bilər:
1. Məhsulun standartları. Hazır proqram məhsuluna tətbiq edilə bilir. Buraya müşayiət etmə sənədlərinin standartları, proqram kodunun yazılma standartları və s. daxildir;
2. PT-nin yaradılma prosesinin standartları. Proqram məhsulunun yaradılma prosesinin özünü təyin edir, məsələn, tələblərin işlənilməsi, layihələndirmə, attestasiya. Bu proseslərin sənədləşdirilməsi standartda nəzərə alınır.
(ardı var)
AMEA İnformasiya Texnologiyaları İnstitutunun sektor müdiri, texnika üzrə fəlsəfə doktoru
Şəfəqət Mahmudova
AMEA İnformasiya Texnologiyaları İnstitutunun böyük elmi işçisi
Tamilla Bayramova
"Rabitə Dünyası" qəzeti, 13 iyun 2014-cü il
