შესავალი

თანამედროვე რთული სისტემების ყველაზე მნიშვნელოვანი ნაწილია პროგრამული პროდუქტები - ინტელექტუალური კომპონენტი. პროგრამული პროდუქტები ახლა გამოიყენება მენეჯმენტის პრობლემების გადასაჭრელად ადამიანის საქმიანობის თითქმის ყველა სფეროში: ეკონომიკაში, სოციალურ, სამხედრო და სხვა სფეროებში. უსაფრთხოება Მაღალი ხარისხიშიდა პროგრამული პროდუქტები მათი მასობრივი განვითარებადა სხვადასხვა აპლიკაციების მიწოდება ქვეყანაში და მსოფლიო ბაზარზე სტრატეგიულ მიზნად იქცა.

ამჟამად, პროგრამული უზრუნველყოფის ინჟინერიისა და პროგრამული პროდუქტის ხარისხის უზრუნველყოფის სტანდარტიზაციის ორი თითქმის დამოუკიდებელი სფეროა, რომლებსაც პირობითად შეიძლება ვუწოდოთ ISO (საერთაშორისო სტანდარტების ორგანიზაცია) სტანდარტების პროფილები და SEI (აშშ პროგრამული ინჟინერიის ინსტიტუტი) სიმწიფის მოდელები. პირველი საკმაოდ სრულად არის წარმოდგენილი [, ]-ში, ხოლო მეორეები - [,]-ში. სტატიის ძირითადი შინაარსი ეძღვნება სიმწიფის მოდელებს.

რთული პროგრამული პროდუქტების სამყაროში კონკურენტუნარიანობის უზრუნველსაყოფად და მათი წარმატებული ექსპორტის შესაძლებლობის უზრუნველსაყოფად, ისინი უნდა იყოს შემუშავებული და სერტიფიცირებული მოთხოვნების შესაბამისად. საერთაშორისო სტანდარტების პროფილებიბაზაზე ISO 9000:2000ან სიმწიფის მოდელები - CMMI: 2003 წ(Capability Maturity Model Integration - ინტეგრირებული პროგრამული უზრუნველყოფის ინჟინერიის სიმწიფის შეფასების მოდელი). ეს ორი მიმართულება მეთოდოლოგიურად ძალიან ახლოს არის და ნაწილობრივ იკვეთება ურთიერთმიმართების გზით.

ტექნიკური და ეკონომიკური მაჩვენებლებისა და პროგრამული პროდუქტების ხარისხის გაუმჯობესება, ასევე შეცდომებისა და დეფექტების თავიდან აცილება უზრუნველყოფილია თანამედროვე ტექნოლოგიებიპროგრამული ინჟინერია და სისტემები კომპიუტერის დახმარებით დიზაინი. ეს არის მაღალი ხარისხის, რესურსების დაზოგვის ტექნოლოგიები მაღალი ხარისხის, საიმედოობისა და უსაფრთხოების პროგრამული კომპლექსების შესაქმნელად, რომლებიც მიზნად ისახავს რესურსების მთლიანი ღირებულების შემცირებას პროგრამული ხელსაწყოების დიზაინის, დანერგვისა და შენარჩუნებისთვის (PS). ამისათვის, უპირველეს ყოვლისა, აუცილებელია ანალიზისა და დიზაინის მეთოდებისა და ინსტრუმენტების გამოყენება, რაც უზრუნველყოფს კონკრეტიზაციას და თავიდანვე მიზნების, მიზნებისა და ფუნქციების ყველაზე ზუსტ წარმოდგენას. ცხოვრების ციკლი(LC) PS და სისტემის შესაძლო დეფექტების გავრცელების თავიდან აცილება განვითარების შემდგომ ეტაპებზე. პროგრამული უზრუნველყოფის ინჟინერიის ასეთი ტექნოლოგიები შესაძლებელს ხდის ექსპლუატაციისთვის გადაცემულ პროგრამულ პროდუქტებში სისტემური, ალგორითმული და პროგრამული შეცდომების აღმოფხვრას ან მნიშვნელოვნად შემცირებას. გარდა ამისა, ისინი ეფექტურია PS-ის მოდიფიკაციასა და შენარჩუნებაში, ასევე გარე გარემოში ცვლილებებში.

რთული, კრიტიკული სისტემების გამოყენების ხარისხის, საიმედოობისა და უსაფრთხოების დასადასტურებლად, მათში გამოყენებული პროგრამული პროდუქტები ექვემდებარება სერტიფიცირებასერტიფიცირებული, პრობლემაზე ორიენტირებული ტესტის ცენტრები ან ლაბორატორიები. ასეთი ტესტები უნდა ჩატარდეს, როდესაც პროგრამები მართავენ რთულ, კრიტიკულ პროცესებს ან ამუშავებენ ისეთ მნიშვნელოვან ინფორმაციას, რომ მათში არსებული დეფექტები ან არასაკმარისი ხარისხი შეიძლება გამოიწვიოს მნიშვნელოვანი ზიანი. სასერტიფიკაციო ტესტებმა უნდა დაადგინოს პროგრამული კომპლექსების შესაბამისობა დოკუმენტაციის მოთხოვნებთან და მისცეს მათ ფუნქციონირება ტესტების დროს შესწავლილი გარე გარემოს პარამეტრების ცვლილებების ფარგლებში. ამ ტიპის ტესტები ხასიათდება შემოწმების უდიდესი სიმძიმითა და სიღრმით და უნდა ჩატარდეს დეველოპერებისგან და მომხმარებლებისგან (მომხმარებლების)გან დამოუკიდებელი სპეციალისტების მიერ.

სერტიფიცირების საფუძველი უნდა იყოს დეტალური და ეფექტური პროგრამები და მეთოდები პროგრამული პაკეტების შესამოწმებლად მომხმარებელთა სტანდარტიზებული მოთხოვნების შესაბამისად, სპეციალურად შექმნილი სატესტო პრობლემები და მათი ფორმირებისთვის გენერატორები, ასევე ტესტერების მაღალი კვალიფიკაცია და ავტორიტეტი. განაცხადი საწარმოებში - პროგრამული პროდუქტების დეველოპერებში, სერტიფიცირებული ხარისხის სისტემებისთვის, PS-ის სასიცოცხლო ციკლის უზრუნველსაყოფად მოთხოვნილებებზე დაყრდნობით ISO 9000:2000ან CMMI: 2003 წ, უზრუნველყოფს მათი სასიცოცხლო ციკლის პროცესებისა და პროდუქტების მაღალი, მდგრადი ხარისხის მენეჯმენტს და ასევე ხშირ შემთხვევაში საშუალებას იძლევა ხელი შეუწყოს საბოლოო პროგრამული პროდუქტის სერტიფიცირებას. ამიტომ, კომპლექსური პროგრამული პროექტების კლიენტები ირჩევენ განმახორციელებელ კონტრაქტორებს, რომლებსაც აქვთ ხარისხის უზრუნველყოფის სისტემების გამოყენების დამადასტურებელი სერთიფიკატები ადაპტირებული საერთაშორისო სტანდარტების პროფილებზე ან სიმწიფის მოდელებზე დაყრდნობით.

პროგრამული უზრუნველყოფის ინჟინერიის მეთოდებში ტრენინგის ხარვეზები ფართო ზღვარს ტოვებს სპეციალისტების თვითნებობისთვის მათი მუშაობის ხარისხის შეფასებისას, ასევე პროგრამულ პროექტებში მრავალი დეფექტისა და შეცდომის გამოვლენისთვის. პროგრამებით გადაჭრილი თანამედროვე ამოცანების მზარდმა სირთულემ და პასუხისმგებლობამ, ისევე როგორც შესაძლო ზიანს მათი შედეგების არასაკმარისი ხარისხისგან, მნიშვნელოვნად გაზარდა ხარისხის მახასიათებლებისა და გაზომვის მეთოდების მოთხოვნების სრული, სტანდარტიზებული აღწერის მეთოდების დაუფლების აქტუალობა. მათი რეალური, მიღწეული მნიშვნელობები პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის სხვადასხვა ეტაპზე. მკვეთრად გაიზარდა სპეციალისტების მოთხოვნილება იცოდნენ ცნებები, განმარტებები და პროგრამული პროდუქტების ხარისხის მახასიათებლების შეფასების მეთოდები.

პროგრამული კომპლექსების სწრაფი ზრდა და გართულება იწვევს დიდი პროგრამირების გუნდების შექმნას შრომის პროფესიონალური დაყოფით, რომელშიც აუცილებელია სპეციალისტთა ჯგუფების კოორდინირებული საქმიანობის რეგულირება ერთ პროექტზე. დეველოპერების დაპირებები კონტრაქტებში მაღალი ხარისხის პროგრამული უზრუნველყოფის მიწოდების შესახებ შეთანხმებულ ვადებში ხშირად არ სრულდება. ხშირად ეს ხდება იმის გამო, რომ დამკვეთი და კონტრაქტორი აფასებენ ხარისხის დონეს სხვადასხვა კრიტერიუმების მიხედვით და მათ არ აქვთ შეთანხმება ამ საკითხზე და პროგრამების ხარისხის შეფასების მიდგომა არ არის საკმარისად ფორმალიზებული. გარდა ამისა, ხანდახან არ არსებობს მაღალი ხარისხის პროგრამების მისაღწევად საჭირო რესურსების სწორად შეფასების უნარი. შედეგად, პროგრამული პროდუქტების ხარისხი ხშირად რჩება დაბალი, არასანდო და არაკონკურენტული საერთაშორისო ბაზარზე. აქედან გამომდინარე, ყველაზე მნიშვნელოვანი პრობლემა განვითარებისა და გამოყენების მრავალი თანამედროვე სისტემებიარის პროგრამული უზრუნველყოფის ინჟინერიის დარგში სპეციალისტების მომზადება და განათლება, საერთაშორისო სტანდარტების გამოყენება, რომლებიც ხელს უწყობენ პროგრამული უზრუნველყოფის მაღალ ხარისხს და მის საიმედო შეფასებას, მთავარი მიზნით - პროექტის პროცესების განხორციელება. მართვადიდა შედეგები არის პროგნოზირებადი. აუცილებელია მოთხოვნების ფორმალიზება და რთული პროგრამული პაკეტების ფუნქციონირებისა და გამოყენების ხარისხის მახასიათებლების სპეციფიკური მნიშვნელობების მიღწევა, ამ ხარისხის უზრუნველსაყოფად და გასაუმჯობესებლად არსებული რესურსების გათვალისწინებით.

CMMI სიმწიფის მოდელი - 1.1აუმჯობესებს და აუმჯობესებს წინა მოდელებს CMM(იხ.) და ასევე ნაწილობრივ ითვალისწინებს არსებული საერთაშორისო სტანდარტების ძირითად მოთხოვნებს პროგრამული უზრუნველყოფის მართვის სფეროში. მნიშვნელოვანი ყურადღება CMMIეძლევა განვითარების პროცესებს და აღრიცხვას განმეორებით, როდესაც იცვლება მომხმარებლის მოთხოვნები, მათი მიკვლევადობა ფუნქციებზე, კომპონენტებზე, ტესტებსა და საპროექტო დოკუმენტებზე. ცოტა ხნის წინ გამოჩნდა ინფორმაცია 2003 წლის ვერსიის SEI ვერსიის მოდერნიზაციის შესახებ. CMMI-1.1დაგროვილი გამოცდილებისა და საწარმოების გამოხმაურების საფუძველზე. იგი სავარაუდოდ 2006 წელს გამოუშვებს მოდელის ახალ, მნიშვნელოვნად განახლებულ ვერსიას CMMI-1.2, რის შემდეგაც 1.1 ვერსია უნდა გაუქმდეს. 2007 წლის ბოლომდე მომხმარებლები უნდა გადავიდნენ ვერსიაზე CMMI-1.2, ხოლო მომავალში სავალდებულო გახდება საწარმოს ტექნოლოგიის ხარისხის (სერთიფიკაციის) ფორმალიზებული შეფასება პროგრამული უზრუნველყოფის ინჟინერიის სფეროში. სერტიფიკატის მოქმედების ვადა შემოიფარგლება სამი წლით. მომხმარებლებმა და მსხვილი პროგრამული სისტემების შემქმნელებმა უნდა მოემზადონ ამ ცვლილებებისთვის SEI-ის მიერ 1.2 ვერსიის ოფიციალურ გამოქვეყნებამდე.

CMMI სიმწიფის მოდელის სტრუქტურა და შინაარსი - 1.1

მოდელის ორი ვარიანტი CMMI-1.1შექმნილია უზრუნველსაყოფად უწყვეტიპროცესების კომპლექსის შეფასება გარკვეული ტერიტორიაპროგრამული უზრუნველყოფის შექმნა ან ეტაპობრივადსაწარმოს სიმწიფის შეფასება და გაუმჯობესება, ასევე ზოგადად პროგრამული კომპლექსების სასიცოცხლო ციკლის ორგანიზებისათვის. მოდელები CMMIდახმარება გაუწიონ სპეციალისტებს მათი პროდუქციის ორგანიზებასა და გაუმჯობესებაში, ასევე PS-ის განვითარებისა და შენარჩუნების პროცესების გამარტივებაში და მომსახურებაში. ამ მოდელების კონცეფცია მოიცავს კომპლექსური სისტემების სიმწიფის მართვასა და შეფასებას, პროგრამული უზრუნველყოფის ინჟინერიას, ასევე ინტეგრირებული პროგრამული პროდუქტების შექმნისა და მათი განვითარების გაუმჯობესების პროცესებს. უწყვეტი და ეტაპობრივი მოდელების კომპონენტები დიდწილად მსგავსია და მათი შერჩევა და გამოყენება შესაძლებელია სხვადასხვა შემადგენლობით და გამოყენების თანმიმდევრობით, კონკრეტული პროექტების თვისებებისა და მახასიათებლების მიხედვით.

მოდელის აღწერილობის ვარიანტები აგებულია ერთი სქემის მიხედვით, რომელიც მოიცავს ზოგად სექციებს:

• წინასიტყვაობა;
• 1 სექცია - შესავალი;
• ნაწილი 2 - კომპონენტის მოდელი;
• ნაწილი 3 - ტერმინოლოგია;
• ნაწილი 4 - დონეების შინაარსი და მოდელის თითოეული ვერსიის ძირითადი კომპონენტები (მიზნების და პროცედურების შემუშავება);
• ნაწილი 5 - პროცესების ურთიერთქმედების სტრუქტურა; მე-7 სექციაში აღწერილია პროცესების ოთხი კატეგორია, მათი ზოგადი მიმოხილვა და CMMI პროცესების ურთიერთქმედების სქემები:
  • პროცესის მართვა;
  • მენეჯმენტი - პროექტების მართვა;
  • ინჟინერია (ტექნოლოგია);
  • მხარდაჭერა;
• ნაწილი 6 - მოდელის გამოყენება CMMI- მოკლე რეკომენდაციები მომხმარებლებისთვის მოდელის გამოყენებისა და ტრენინგის შესახებ; აღნიშნულია მოდელის პროცესების თავსებადობა და შესაბამისობა წინა CMM მოდელის რეგულირებულ პროცესებთან სტანდარტის მე-2 და მე-3 ნაწილებში. ISO 15504.
• განყოფილება 7 არის ბოლო, უდიდესი თითოეულ სტანდარტში, ის იკავებს მთლიანი დოკუმენტის დაახლოებით 500 გვერდს, რაც 700 გვერდს აღემატება. ამ განყოფილებაში მოცემულია დეტალური რეკომენდაციები მასში ჩამოთვლილი თითოეული პროცესის განსახორციელებლად, რომელიც ითვალისწინებს კონკრეტული მოდელის მახასიათებლებს.

პირველი ვარიანტი(უწყვეტი) მოდელი ასახავს დოკუმენტს: შესაძლებლობების სიმწიფის მოდელის ინტეგრაცია (CMMI) სისტემური ინჟინერიისთვის/პროგრამული ინჟინერიისთვის/ინტეგრირებული პროდუქტებისა და პროცესების შემუშავებისთვის, ვერსია 1.1, უწყვეტი წარმოდგენა (CMMI-SE/SW/IPPD, V1.1, უწყვეტი). ინტეგრირებული სისტემის ინჟინერია/პროგრამული ინჟინერია/ინტეგრირებული პროდუქტები და განვითარების პროცესის სიმწიფის შეფასების მოდელი - უწყვეტი ხედი. ამ მოდელში მეშვიდე განყოფილება შედგება პროცესებისგან:

• პროცესის მართვა:
  • ტრენინგის ორგანიზება;
  • პროცესების ტრანსფორმაციის (ცვლილების) ორგანიზაცია;
  • ინოვაციებისა და გაფართოებების ორგანიზება;
• პროექტის მენეჯმენტი:
  • პროექტის დაგეგმვა;
  • პროექტის პროცესების მონიტორინგი და კონტროლი;
  • რისკების მართვა;
  • რაოდენობრივი პროექტის მართვა;
• ინჟინერია (ტექნოლოგია):
  • მოთხოვნების მართვა;
  • მოთხოვნების შემუშავება;
  • ტექნიკური გადაწყვეტილებები;
  • პროდუქტის ინტეგრაცია;
  • გადამოწმება;
  • ვალიდაცია (ატესტაცია, დამტკიცება);
• მხარდაჭერა:
  • კონფიგურაციის მართვა;
  • ცვლილებების ანალიზი და გადაწყვეტილების მიღება;
  • ძირეული მიზეზის ანალიზი და პრობლემის გადაჭრა (დეფექტის აღმოფხვრა).

ხუთ დანართში მოცემულია:

მაგრამ- გამოყენებული ლიტერატურული წყაროებისა და დოკუმენტების შემადგენლობა, სადაც, თუმცა, არ არის ნახსენები სტანდარტები ISO;

AT- აბრევიატურები;

FROM- ლექსიკონზე დაფუძნებული ტერმინოლოგია ISOგამოიყენება მხოლოდ ოთხ სტანდარტში ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D - მოთხოვნების აღწერა და წინადადებები მოდელის კომპონენტების ფორმირებისთვის სიმწიფის დონეების მიხედვით;

E - განვითარების მონაწილეთა სია CMMI- პროექტი.

ამ მოდელში ყურადღება გამახვილებულია ორგანიზაციულ პროცესებზე, პროგრამული უზრუნველყოფის პროექტების განხორციელების პროცესების დაგეგმვაზე, მართვასა და კონტროლზე, პროგრამული პროდუქტების მოთხოვნების შემუშავებასა და მართვაზე. ქვემოთ მოცემულია დეტალების მაგალითები CMMIზოგიერთი მათგანი.

Პროექტის დაგეგმვაროგორც ამ, ასევე მეორე მოდელში შედის:

• პროგრამული პროდუქტის შესაძლო ზომის (მასშტაბის) შეფასება;
• PS პროექტის ფუნქციებისა და მახასიათებლების სირთულის შეფასება;
• პროგრამული პაკეტის სასიცოცხლო ციკლის მოდელისა და ეტაპების განსაზღვრა;
• პროექტის ტექნიკურ-ეკონომიკური შესწავლა - ქვესადგურის სასიცოცხლო ციკლის ღირებულების, შრომის ინტენსივობის და ხანგრძლივობის განსაზღვრა;
• ეტაპობრივი სამუშაო გრაფიკისა და პროექტის ბიუჯეტის შემუშავება;
• პროექტის რისკების ანალიზი, იდენტიფიცირება და შეფასება;
• PS პროექტის სასიცოცხლო ციკლში პროცესებისა და პროდუქტების დოკუმენტაციის დაგეგმვა და მართვა;
• ტექნიკური და ადამიანური რესურსების დაგეგმვა და განაწილება PS-ის სასიცოცხლო ციკლის ეტაპების მიხედვით;
• პროექტის განსახორციელებლად სპეციალისტთა გუნდის ცოდნისა და კვალიფიკაციის მიწოდების დაგეგმვა;
• PS პროექტის გეგმების ნაკრების განზოგადება და ანალიზი;
• სასიცოცხლო ციკლის ეტაპებზე სამუშაოებისა და რესურსების კოორდინაცია დეველოპერის მიერ PS პროექტის მომხმარებელთან;
• სამუშაო გეგმის დოკუმენტირება და მისი დამტკიცება პროექტის შემქმნელი მენეჯერის მიერ.

მოთხოვნების შემუშავების პროცესებიპროგრამული პროდუქტის მსგავსია ორივე მოდელის პროცესები და მოიცავს:

• მომხმარებლისა და მომხმარებლების რეალური საჭიროებების იდენტიფიცირება პროგრამული პროდუქტის ფუნქციებსა და მახასიათებლებზე;
• დამკვეთსა და შემქმნელს შორის პროგრამული პროდუქტის ფუნქციების საწყისი, ძირითადი მოთხოვნების შემუშავება და კოორდინაცია;
• პროგრამული უზრუნველყოფის კომპლექტის პროექტის არსებული რესურსებისა და შეზღუდვების განსაზღვრა;
• PS-ის ფუნქციების ძირითადი საწყისი მოთხოვნების დაშლა პროგრამული პაკეტის კომპონენტებისა და ტესტების მოთხოვნების ერთობლიობაში;
• კომპონენტებს შორის, ოპერაციულ და გარე გარემოსთან ინტერფეისის მოთხოვნების ფორმალიზება;
• პროგრამული პროდუქტის კონცეფციისა და მისი გამოყენების სცენარების შემუშავება;
• ფუნქციონალური ვარგისიანობის განზოგადებული მახასიათებლების მოთხოვნების შემუშავება და პროგრამული პროდუქტის ფუნქციების დანიშნულებისამებრ გამოყენება.

მოთხოვნების მართვაორივე მოდელი მოიცავს:

• მომხმარებლისა და დეველოპერების მიერ PS პროექტის მოთხოვნების ცალსახა გაგების მიღწევა;
• მომხმარებლის მიერ დეველოპერებისგან პროგრამული პროდუქტის ყველა მოთხოვნის შესრულების ვალდებულების მიღება;
• კლიენტსა და დეველოპერს შორის შეთანხმებული PS პროექტის მოთხოვნების ცვლილებების მართვა;
• PS პროექტის ზოგადი მოთხოვნებიდან კომპონენტებისა და კონკრეტული პროცესების მოთხოვნების ცვლილების სისწორის უზრუნველყოფა;
• პროექტის განვითარების პროცესებსა და მომხმარებლის მოთხოვნებს შორის შეუსაბამობების იდენტიფიცირება და დადგენა.

მეორე ვარიანტიწარმოგიდგენთ დოკუმენტს: შესაძლებლობების სიმწიფის მოდელის ინტეგრაცია (CMMI) სისტემური ინჟინერიისთვის/პროგრამული ინჟინერიისთვის/პროდუქტისა და პროცესის ინტეგრირებული განვითარებისთვის, ვერსია 1.1, ეტაპობრივი წარმოდგენა (CMMI-SE/SW/IPPD, V1.1, დადგმული). ინტეგრირებული სისტემის ინჟინერია/პროგრამული ინჟინერია/ინტეგრირებული პროდუქტები და განვითარების პროცესის სიმწიფის შეფასების მოდელი - ეტაპობრივი შესავალი. მოდელი ეფუძნება სიმწიფის ხუთი დონის კონცეფციის შენარჩუნებას CMM[ , ]. პროცესების შემადგენლობა პრაქტიკულად იმეორებს ზემოთ მოცემულს მოდელის პირველი ვერსიისთვის, მაგრამ ოდნავ განსხვავებული თანმიმდევრობით და შედარებით მცირე დამატებებით.

პირველი დონეახასიათებს მნიშვნელოვანი გაურკვევლობა პროცესების შემადგენლობასა და შინაარსში სხვადასხვა შედარებით მარტივ პროექტებში, ამიტომ მასზე კომენტარი არ არის გაკეთებული დოკუმენტში. ამიტომ პროცესების შინაარსის ეტაპობრივი გარკვევისა და დეტალიზაციისას CMMIრეკომენდებულია შეზღუდული ოთხი ძირითადი დონე:

• მეორე დონე- აფორმებს ძირითადი მენეჯმენტიპროექტები:
  • მოთხოვნების მართვა;
  • პროექტის დაგეგმვა;
  • პროექტის მონიტორინგი და კონტროლი;
  • მომწოდებლებთან ხელშეკრულებების მართვა;
  • პროცესებისა და პროდუქტების გაზომვა და ანალიზი;
  • პროცესებისა და პროდუქციის ხარისხის უზრუნველყოფა;
  • კონფიგურაციის მართვა;
• მესამე დონე- შეიცავს ძირითადი პროცესების სტანდარტიზაციას:
  • მოთხოვნების შემუშავება;
  • ტექნიკური გადაწყვეტილებები;
  • პროდუქტის ინტეგრაცია;
  • გადამოწმება;
  • ვალიდაცია (სერთიფიკაცია);
  • ორგანიზაციული პროცესების შინაარსი;
  • ორგანიზაციული პროცესების განსაზღვრა;
  • ტრენინგის ორგანიზება;
  • პროექტის პროცესებისა და პროდუქტების ინტეგრირებული მართვა;
  • რისკების მართვა;
  • განვითარების გუნდის ინტეგრაცია;
  • მიმწოდებლის ინტეგრირებული მენეჯმენტი;
  • პრობლემების ანალიზი და გადაწყვეტა (დეფექტების აღმოფხვრა);
  • ინტეგრაციისათვის გარემოს ორგანიზება;
• მეოთხე დონე- განსაზღვრავს რაოდენობრივ მენეჯმენტს:
  • პროცესების ხარისხის წარმომადგენლობის ორგანიზება;
  • მთელი პროექტის და რესურსების რაოდენობრივი მართვა;
• მეხუთე დონე- ოპტიმიზაცია, უწყვეტი გაუმჯობესება:
  • ორგანიზაცია, ინოვაცია, პროცესების რაოდენობრივი მართვა და რესურსებით უზრუნველყოფა;
  • დეფექტების გამომწვევი მიზეზების ანალიზი, პროცესებისა და პროდუქტების ხარისხის გაუმჯობესება და მართვა.

მოდელის მეორე ვერსიაში აპლიკაციები შემადგენლობით მსგავსია პირველი მოდელის ზემოაღნიშნულ აპლიკაციებთან. რეკომენდირებულია სიმწიფის ყოველ უფრო მაღალ დონეზე გამოყენება ყველა პროცესიწინა ქვედა დონეები. მოდელის ორივე ვერსიაში, ზემოთ მონიშნული თითოეული ძირითადი პროცესი კომენტირებულია მისი პრაქტიკული განხორციელების დეტალური რეკომენდაციებით, რომლებიც შეიცავს სტრუქტურაში გაერთიანებულ დაახლოებით 20-30 გვერდის აღწერას:

• პროცესის საერთო მიზნების მიღწევა;
• შესავალი შენიშვნები და პროცესის ფუნქციების ზოგადი აღწერა;
• კონკრეტული პროცესის მიზნები;
• პროცესის მართვა;
• პროცესის მოთხოვნების შემუშავება;
• ურთიერთქმედება და ინტერფეისი სხვა პროცესებთან;
• პრაქტიკული მიზნები - პროცესის აქტივობების საჭირო შედეგები;
• მოქმედებების დაგეგმვა კონკრეტულ პროცესში;
• პროცესის განხორციელების შედეგების ანალიზი და დადასტურება (დამტკიცება);
• პროცესის მონიტორინგი და კონტროლი.

ეს რეკომენდაციები ძირითადი პროცესების აღწერის მოცულობის, შინაარსისა და სისრულის თვალსაზრისით მსგავსია PS-ის სასიცოცხლო ციკლის პროფილისთვის წარმოდგენილი რიგი სტანდარტებისა. გამოყენებული პროცესების სისრულის შეკვეთა და შეფასება სიმწიფის დონის შესაბამისად, საშუალებას გაძლევთ დაადგინოთ საწარმოების წარმოების პოტენციალი - პროგრამული პროდუქტების დეველოპერები პროცესების პროგნოზირებული ხარისხისა და მათი საქმიანობის შედეგებისა და სერტიფიცირებისთვის მზადყოფნის თვალსაზრისით. მოდელის სიმწიფის გარკვეულ დონესთან შესაბამისობა CMMI - 1.1.

აქცენტი მოდელებზე CMMIეძლევა PS პროექტის მართვის პროცესებს. მოდელების ეს მოთხოვნები და პროცესები პრაქტიკულად შეესაბამება სტანდარტებში დარეგულირებულ და დეტალურ რეკომენდაციებს. ISO 9001:2000და რთული PS სასიცოცხლო ციკლის სტანდარტების პროფილის ძირითადი კომპონენტები [ , ]. მოთხოვნები სტანდარტების 4-8 ფუნქციურ მონაკვეთებში მიმდინარე პროცესებზე ISO 9001, ISO 9004, ISO 90003მოდელში შეიძლება შევადაროთ ადეკვატური შინაარსის სექციები CMMI(ნახ. 1-ში, შინაარსის გადახურვის ზონა). პროცესებისა და მოთხოვნების საერთო მსგავსებაა: შემადგენლობა, ტერმინოლოგია, სტრუქტურა, რეკომენდირებული მართვის პროცესების ჩამონათვალი, დაგეგმვა, ხელმისაწვდომი რესურსების აღრიცხვა, პროგრამული უზრუნველყოფის ინჟინერიის პროცესების განხორციელება, სპეციალისტების შეფასება და ორგანიზაცია.

ნახაზი 1. პროცესებისა და მოთხოვნების საერთო სტანდარტები და სიმწიფის მოდელები

დიდი პროგრამული პროექტების სრული სასიცოცხლო ციკლის მხარდაჭერისა და რეგულირების თვალსაზრისით, მოდელების ნაკლოვანებები CMMIარსებული სტანდარტების პროფილთან დაკავშირებით ISOშეიძლება შეიცავდეს შემდეგს:

ვრცელი ტექნიკური ანგარიში შემუშავდა და თავდაპირველად დამტკიცდა 1998 წელს, რათა განისაზღვროს ზემოთ წარმოდგენილი PS-ის სასიცოცხლო ციკლის უზრუნველყოფის პროცესების სიმწიფის დონე. ISO 15504, რომელიც შედგება ცხრა ნაწილისგან და მრავალი აპლიკაციისგან. იგი ასახავს სიმწიფის მოდელს CMMდა რვა ძირითადი პრინციპებიპროგრამული უზრუნველყოფის ინჟინერია სტანდარტზე დაფუძნებული ISO 9000:2000. შემდეგ შიგნით ISOამ დოკუმენტმა განიცადა რადიკალური გადახედვა, შემცირება, სტრუქტურისა და შინაარსის გამარტივება, მიზნებისა და კონცეფციის სრულად შენარჩუნებით და დამტკიცებული სტანდარტულადხუთ ნაწილად.

სტანდარტული ISO 15504:1-5:2003-2006არეგულირებს საწარმოების მიერ შესრულებული პროგრამული ინსტრუმენტებისა და სისტემების შექმნის, შენარჩუნებისა და გაუმჯობესების პროცესების სიმწიფის შეფასებას და დამოწმებას:

• საკუთარი სახელმწიფოს ჩამოყალიბება ტექნოლოგიური პროცესებიდა მათი გაუმჯობესება;
• განსაზღვროს საკუთარი პროცესების შესაბამისობა კონკრეტული მოთხოვნების ან მომხმარებელთა მოთხოვნების კლასების დასაკმაყოფილებლად;
• შესრულებისთვის მისი ვარგისიანობის თვალსაზრისით გარკვეული ხელშეკრულებები PS და სისტემების მომხმარებლებთან.

სტანდარტი ხელს უწყობს: საწარმოების სიმწიფის თვითშეფასებას, ატესტირებული პროცესების ადეკვატური მართვის უზრუნველყოფას, პროცესის რეიტინგების პროფილის განსაზღვრას და ასევე შეესაბამება ოპერაციული სისტემის და სისტემების ნებისმიერ ფარგლებსა და ზომას. სტანდარტის გამოყენება მიზნად ისახავს საწარმოებისა და სპეციალისტების განვითარებას უწყვეტი გაუმჯობესების ტექნოლოგიური სიმწიფის კულტურა PS-ის სასიცოცხლო ციკლის უზრუნველყოფა, რომელიც აკმაყოფილებს პროექტების ბიზნეს მიზნებს და ხელმისაწვდომი რესურსების გამოყენების ოპტიმიზაციას. საწარმოს პროცესის სიმწიფის შეფასება იძლევა შესაძლებლობას შევადაროთ და შევარჩიოთ ისინი, რომლებიც სასურველია გარკვეული პროექტებისთვის:

• მომხმარებლებისთვის, მყიდველებისთვის, პროგრამული პროდუქტებისა და სისტემების მომხმარებლებისთვის: მიმწოდებლის სასიცოცხლო ციკლის პროცესების მიმდინარე და პოტენციური სიმწიფის განსაზღვრის უნარი;
• მოვაჭრეებისთვის და დეველოპერებისთვის: საკუთარი პროგრამული უზრუნველყოფის და სისტემების სასიცოცხლო ციკლის პროცესების მიმდინარე და პოტენციური სიმწიფის განსაზღვრის უნარი, პროცესის გაუმჯობესების სფეროები და პრიორიტეტები;
• სამაგისტრო შემფასებლებისთვის: შეფასების პროცესების წარმართვისა და გაუმჯობესების ჩარჩო.

სტანდარტში დამტკიცება განიხილება ორი ასპექტი: გააუმჯობესოს კონკრეტული საწარმოს PS და სისტემების სასიცოცხლო ციკლის პროცესები და დაადგინოს, შეესაბამება თუ არა პროექტის ან საწარმოს მხარდაჭერის პროცესების დეკლარირებული სიმწიფე რეალურ გამოყენებულ პროცესებს. ეს აისახება სტანდარტის შემდეგ ხუთ ნაწილში. ISO 15504:1-5:2003-2006.

Ნაწილი 1 - კონცეფცია და ლექსიკა.შეიცავს ზოგად ინფორმაციას პროგრამული უზრუნველყოფის და სისტემების სიმწიფის სერტიფიცირების პროცესების შესახებ და რეკომენდაციებს სტანდარტის ნაწილების გამოყენების შესახებ. გამოკვეთილი Ძირითადი მოთხოვნებისერტიფიცირებისთვის, ტერმინოლოგიისთვის, სტრუქტურისთვის განისაზღვრება სტანდარტის დარჩენილი ნაწილების ფარგლები.

Მე -2 ნაწილი - სერტიფიცირების შესრულება (წარმოება).იგი მოიცავს დეტალურ მოთხოვნებს სერტიფიცირების პროცესების ჩასატარებლად, როგორც ტექნოლოგიური პროცესების სიმწიფის დონის გაუმჯობესებისა და განსაზღვრის საფუძველს PS და სისტემების სასიცოცხლო ციკლის უზრუნველსაყოფად. დოკუმენტი განსაზღვრავს ატესტაციის განხორციელების პროცესებს, ატესტაციისა და პროცესების გადამოწმების რეკომენდებული პროცესების მოდელებს ისე, რომ ისინი იყოს ობიექტური, შინაარსიანი და წარმომადგენლობითი.

ნაწილი 3 - სახელმძღვანელო სერტიფიკაციის წარმოებისთვის.გთავაზობთ ტექნოლოგიის მიმოხილვას სიმწიფის შეფასების პროცესების შესრულებისა და მოთხოვნების დანერგვის ინტერპრეტაციისთვის. იგი ასახავს: სერტიფიცირების შესრულებას; სიმწიფის პროცესების განსაზღვრის საზომი ხელსაწყოები; სერტიფიცირების ხელსაწყოების შერჩევა და გამოყენება; სერტიფიკატების კომპეტენციის შეფასება; დეკლარირებულ მოთხოვნებთან ატესტაციის შესაბამისობის შემოწმება. ვალიდაციის ინსტრუმენტები შეიძლება გამოყენებულ იქნას საწარმოების მიერ პროგრამული პროდუქტებისა და სისტემების დაგეგმვის, მართვის, მონიტორინგის, კონტროლისა და გაუმჯობესებაში, მათი შეძენის, განვითარების, გამოყენებისა და შენარჩუნებისას.

ნაწილი 4 - მომხმარებლის ინსტრუქცია პროცესის გაუმჯობესებისა და პროცესის სიმწიფისთვის ამ ორ ასპექტში. რეკომენდირებულია რამდენიმე ნაბიჯი, რომელიც მოიცავს: ვალიდაციის პროცესების შედეგების გამოყენებას; სიმწიფის შეფასების მიზნების დასახვა; სასერთიფიკატო საწყისი მონაცემების განსაზღვრა; მიღებული რისკების შესაძლო შემცირების შეფასება; ნაბიჯები პროცესების გასაუმჯობესებლად; სიმწიფის დონის განსაზღვრის ნაბიჯები; საკვალიფიკაციო ანალიზის შედეგების მოთხოვნებთან შედარება.

ნაწილი 5 - მე-2 ნაწილში წარმოდგენილ მოთხოვნებთან შესაბამისობის ატესტაციის პროცესების ნიმუშის მოდელი.ვრცელი დოკუმენტი (162 გვერდი) გთავაზობთ სტანდარტის წინა ნაწილების პრაქტიკულ მაგალითებს სასიცოცხლო ციკლის პროცესის სიმწიფის შეფასების ორგანიზებისთვის, შეფასებისთვის და გაუმჯობესებისთვის სხვადასხვა აპლიკაციის სფეროებისთვის, პროგრამული პროექტებისთვის და საწარმოებისთვის.

პროექტების პრაქტიკული განხორციელებისას და რთული პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის უზრუნველსაყოფად, დეველოპერებსა და მომწოდებლებს ზოგჯერ უჭირთ აპლიკაციის მოდელების უპირატესობების იდენტიფიცირება და ხაზგასმა. CMMI. საწარმოს ტრადიციებიდან და დიდი პროექტის მახასიათებლებიდან გამომდინარე, ხშირად მიზანშეწონილია გამოიყენოთ PS, როგორც მთავარი სრული. სტანდარტების პროფილიISOდა მომხმარებლის შეფასებისთვის სიმწიფის დონე PS პროექტების მართვა, ორგანიზაციული და ტექნოლოგიური მხარდაჭერა მიმართავს კონკრეტულ რეკომენდაციებს CMMI. ეს მითითებები შეიძლება ეფექტურად იქნას გამოყენებული პროცესის ხარისხის სერტიფიცირებასაწარმოებში, რომლებიც უზრუნველყოფენ PS-ის სასიცოცხლო ციკლს, როგორც ალტერნატივას ან სერტიფიცირებასთან ერთად მენეჯმენტის სტანდარტების მიხედვით ISO 9000, პროექტის სპეციფიკიდან და პროგრამული პროდუქტის ან ტექნოლოგიის სერტიფიცირების განმცხადებლის მოთხოვნებიდან გამომდინარე მისი სასიცოცხლო ციკლის უზრუნველსაყოფად.

პროგრამული პროდუქტების სერტიფიცირების ორგანიზაცია

სერტიფიცირება შედგება მთელი რიგი ორგანიზაციული პროცესებისგან, რომლებიც ქმნიან სერტიფიცირების სისტემა, ეს პროცესები მხარდაჭერილია რეგულირებული პროცედურებითა და დოკუმენტებით და უნდა განხორციელდეს კვალიფიციური, სერტიფიცირებული ექსპერტების - ინსპექტორების მიერ. საწარმო-დეველოპერის და მისი საქმიანობის შედეგების სერტიფიცირებისთვის - პროგრამული პროდუქტები, მოდელები CMMIან სტანდარტების პროფილები ISO[ , ] რეკომენდირებულია გარკვეული დისციპლინა, რომელიც ადაპტირებული უნდა იყოს ობიექტების სპეციფიკურ მახასიათებლებთან და PS-ის სასიცოცხლო ციკლის გარემოსთან. ქვემოთ ჩამოთვლილი პროცესები და დოკუმენტები განკუთვნილია მსხვილი პროექტებისთვის და შეიძლება შემცირდეს დეველოპერებს, კლიენტებსა და სერტიფიკატორებს შორის შეთანხმებით უფრო მარტივ შემთხვევებში.

სასერტიფიკაციო სამუშაოები იწყება ორგანოს ან ტესტირების ლაბორატორიის აკრედიტაციასთან, აკრედიტაციის მიზანშეწონილობის შესახებ გადაწყვეტილების მისაღებად განაცხადის და დოკუმენტების ნაკრების ფორმირებითა და წარდგენით ცენტრალურ სასერტიფიკაციო ორგანოში. თუ ტესტის შედეგები დადებითია, დგება და გაიცემა აკრედიტაციის მოწმობა.

რეგულაციები სერტიფიცირების ორგანოს ან ლაბორატორიის შესახებარის მთავარი დოკუმენტი, რომელიც ადგენს აკრედიტაციის საგანს, იურიდიულ სტატუსს, ფუნქციებს, სტრუქტურას, უფლება-მოვალეობებს, მეთოდებს, საშუალებებს და ტესტების ორგანიზებას. სასერტიფიკაციო ლაბორატორიის (ცენტრის) პასპორტი უნდა შეიცავდეს ინფორმაციას აღჭურვილობის შესახებ კომპიუტერული მეცნიერებაპერსონალზე და პერსონალზე ტესტირებისთვის საჭირო, სატესტო ხელსაწყოებით აღჭურვილობის, მარეგულირებელი, ტექნიკური და მეთოდოლოგიური დოკუმენტაციის, აგრეთვე ტესტირებისთვის საჭირო სხვა რესურსების უზრუნველყოფა.

ხარისხის ხარისხიშეიცავს პრინციპების განცხადებას, მეთოდებისა და პროცედურების აღწერას, რომლებიც დაკავშირებულია სერტიფიცირების ორგანოს ან ლაბორატორიის ძირითადი ფუნქციებისა და ამოცანების შესრულებასთან, რაც უზრუნველყოფს ტესტების ხარისხს და ნდობას შეფასებების, ტესტებისა და გამოცდების შედეგების მიმართ. ხარისხის სახელმძღვანელო ჩვეულებრივ მოიცავს სექციებს [ TWLSC$

• პოლიტიკა ტესტირებისა და გამოცდების ხარისხის უზრუნველყოფის სფეროში;
• ცენტრის აღჭურვა შესაბამისი მეთოდოლოგიური მასალებით და პროგრამული უზრუნველყოფით და ტესტირების ინსტრუმენტებით;
• საცდელი ობიექტების მოთხოვნების ფორმალიზება;
• პოლიტიკა ცენტრის ტექნიკური აღჭურვილობისა და პერსონალის განვითარების სფეროში;
• სერტიფიცირების შედეგების დოკუმენტაციის არქივირება და უსაფრთხოების კონტროლი.

სერტიფიცირებას დაქვემდებარებული პროდუქციის ან პროცესების შეფასებისთვის განმცხადებელი აგზავნის განცხადებას სერტიფიკაციის ორგანოს სერტიფიცირების სისტემაში მიღებული ფორმით. სერტიფიკაციის ორგანო ახორციელებს სამუშაოებს პროდუქტის სერტიფიცირების მომზადებასა და ორგანიზებაზე განაცხადის საფუძველზე. ეს ნამუშევარი მოიცავს:

• სერტიფიცირების სქემის შერჩევა პროდუქციის სპეციფიკის (მოცულობა, ტექნოლოგია, მარეგულირებელი დოკუმენტების მოთხოვნები და ა.შ.) და დეველოპერის წინადადებების გათვალისწინებით;
• სინჯის აღების და შესამოწმებელი კომპონენტების რაოდენობისა და რიგის დადგენა, თუ ეს არ არის მითითებული სტანდარტებში;
• ტესტების ჩასატარებლად აკრედიტებული ტესტირების ლაბორატორიის შერჩევა და იდენტიფიცირება;
• სამუშაოს შესრულების ხელშეკრულების პროექტის მომზადება.

სერტიფიცირების სამუშაოების მოსამზადებელი ნაწილი მთავრდება გადაწყვეტილების გამოქვეყნებით სერტიფიცირების სისტემაში მიღებული ფორმით. გადაწყვეტილება სამუშაოს შესრულების ხელშეკრულების პროექტთან ერთად ეგზავნება განმცხადებელს. სასერთიფიკატო ტესტების ორგანიზებისას, სერტიფიცირებისთვის გამოცხადებული პროდუქტების მოქმედი მარეგულირებელი დოკუმენტების შერჩევა და შესწავლა ტარდება ტესტირებისა და შედეგების შეფასების მეთოდები.

განმცხადებელი იღებს საბოლოო გადაწყვეტილებებს, თუ რომელი ხარისხის სისტემის ელემენტები, ორგანიზაციული და ტექნიკური საქმიანობის სფეროები და სახეები ექვემდებარება შემოწმებას სერტიფიცირებისას მოცემულ დროის ინტერვალში. განმცხადებელმა უნდა შექმნას პირობები და წარადგინოს დოკუმენტები გადამოწმების პროცესების უზრუნველსაყოფად. მას შეუძლია სერტიფიცირების ორგანოს წარუდგინოს პროდუქციის შემუშავებისა და წარმოების დროს ჩატარებული ტესტის ანგარიშები, მესამე მხარის ტესტირების ლაბორატორიების მიერ ჩატარებული ტესტების დოკუმენტები და სხვა დოკუმენტები, რომლებიც მიუთითებს ტექნოლოგიის ან პროდუქტების შესაბამისობაზე დადგენილ მოთხოვნებთან. განაცხადის თანდასწრებით წარმოდგენილი პროდუქციის დადგენილ მოთხოვნებთან შესაბამისობის დოკუმენტირებული მტკიცებულებების ანალიზის საფუძველზე, სერტიფიცირების ორგანომ შეიძლება გადაწყვიტოს შემცირდეს ტესტების ფარგლები ან გასცეს სერტიფიკატი.

ტესტებს ატარებენ ტესტირების ლაბორატორიები, რომლებიც აკრედიტებულნი არიან მხოლოდ იმ ტესტების ჩასატარებლად, რომლებიც გათვალისწინებულია მათ მარეგულირებელ, აკრედიტაციის დოკუმენტებში. თუ შეუძლებელია ტესტების ჩატარება აკრედიტებული ლაბორატორიის სატესტო დაწესებულებაში, ტესტები შეიძლება ჩატარდეს ამ ლაბორატორიის პერსონალის მიერ ამ პროდუქტის მწარმოებელთან ან მომხმარებელთან, ტესტირების ლაბორატორიის საკუთარი ობიექტების ან მიმწოდებლისგან ხელმისაწვდომი სატესტო საშუალებების გამოყენებით. .

პროგრამული პროდუქტებისა და საწარმოს ხარისხის სისტემების სერტიფიცირების პროცესი მოიცავს:

• ამ სფეროში კომპეტენტური ორგანოს და სერტიფიცირებული ლაბორატორიის ანალიზი და შერჩევა დეველოპერის ან მომხმარებლის (განმცხადებლის) მიერ სასერტიფიკაციო ტესტების ჩასატარებლად;
• განმცხადებლის მიერ ტესტირებაზე განცხადების წარდგენა სერტიფიკაციის ორგანოსთვის და სერტიფიკატების მიერ განაცხადის შესახებ გადაწყვეტილების მიღება, სერტიფიცირების სქემის არჩევა, სასერტიფიკაციო ხელშეკრულების დადება;
• საწარმოს ხარისხის სისტემის ან/და პროგრამული პროდუქტის შესამოწმებელი ვერსიის მოთხოვნების იდენტიფიცირება;
• სასერტიფიკაციო ლაბორატორიის მიერ კომპანიის ხარისხის სისტემის ან პროგრამული პროდუქტის ვერსიის სასერტიფიკაციო ტესტების ჩატარება;
• მიღებული შედეგების ანალიზი და ლაბორატორიის ან/და სერტიფიცირების ორგანოს მიერ გადაწყვეტილების მიღება განმცხადებლისთვის შესაბამისობის სერტიფიკატის გაცემის შესაძლებლობის შესახებ;
• სერტიფიცირების ორგანოს მიერ განმცხადებლისთვის გაცემა - სერტიფიკატი და ლიცენზია შესაბამისობის ნიშნის გამოყენებისა და სერტიფიცირებული პროდუქტების - პროგრამული პროდუქტის ვერსიების გაცემის შესახებ;
• საწარმოს ან/და პროდუქციის სერტიფიცირებული ხარისხის სისტემის სერტიფიცირების ორგანოს მიერ საინსპექციო კონტროლის განხორციელება;
• განმცხადებლის მიერ მაკორექტირებელი ღონისძიებების გატარება ხარისხის სისტემის ან/და პროდუქციის პროცესების დადგენილ მოთხოვნებთან შესაბამისობის დარღვევის და შესაბამისობის ნიშნის არასწორად გამოყენების შემთხვევაში.

პროდუქტის ხარისხზე დეველოპერის მენეჯმენტის პასუხისმგებლობის შემოწმებისას, უნდა განისაზღვროს, რომ საწარმოს ან პროექტს აქვს ხარისხის დოკუმენტირებული პოლიტიკა, მიზნები და ვალდებულებები, ასევე რამდენად არის გაგებული, განხორციელებული და შენარჩუნებული სამუშაო წესრიგში ორგანიზაციის ყველა დონე. უნდა დადგინდეს, რომ საწარმოს ჰყავს მენეჯმენტის წარმომადგენელი, რომელსაც, განურჩევლად სხვა მოვალეობებისა, აქვს უფლებამოსილება და პასუხისმგებლობა ხარისხის სისტემის სტანდარტებისა და მარეგულირებელი დოკუმენტების მოთხოვნების უწყვეტი შესრულებისთვის. მოთხოვნების, პროცედურების, ხელსაწყოების და გაწვრთნილი პერსონალის ხელმისაწვდომობა ხარისხის სისტემის პროცესების პრაქტიკული განხორციელებისთვის, აგრეთვე ხარისხის სისტემის ყველა კომპონენტის, მოთხოვნისა და დებულების შესაბამისობა და სისტემატური დოკუმენტაცია, რომელიც არის ინტეგრირებული პროცესი მთელი ცხოვრების განმავლობაში. PS-ის ციკლი უნდა შემოწმდეს. ხარისხის სისტემის შემოწმებაუნდა შეიცავდეს განმარტებას:

• ტექნოლოგიური დოკუმენტაციის ხელმისაწვდომობა და სისრულე და მის მოთხოვნებთან შესაბამისობა პრაქტიკაში;
• ტექნოლოგიური აღჭურვილობის მდგომარეობა და მათი შენარჩუნების სისტემის ხელმისაწვდომობა;
• კონტროლისა და ტესტირების სისტემის არსებობა და ეფექტურობა;
• საზომი და საცდელი ხელსაწყოების მდგომარეობა;
• პროდუქტებსა თუ ტექნოლოგიაში გამოვლენილი ხარვეზების იდენტიფიცირებისა და აღმოფხვრის სისტემის ხელმისაწვდომობა.

ტესტების საფუძველზე ხდება მიღებული შედეგების შეფასება და დასაბუთებული დასკვნები პროდუქტების ან პროცესების მარეგულირებელი დოკუმენტების მოთხოვნებთან შესაბამისობის ან შეუსაბამობის შესახებ. ტესტირების ანგარიშები წარედგინება სერტიფიკაციის ორგანოს, ასევე განმცხადებელს მისი მოთხოვნით. ტესტის ანგარიშები ექვემდებარება შენახვას პროდუქტის სერტიფიცირების სისტემების წესებით და ტესტირების ლაბორატორიის დოკუმენტებში დადგენილი პერიოდებით, მაგრამ არანაკლებ სამი წლისა.

დოკუმენტაციის სისრულისა და ხარისხის მიღებისა და შემოწმების შემდეგ საცდელი ლაბორატორიის სპეციალისტებმა უნდა განახორციელონ ხარისხის სისტემის ფაქტობრივი გამოყენების ხარისხის შემოწმებასაწარმოში. ტესტირება იწყება ხარისხის სისტემის ტესტირების პროგრამის შემუშავებით, რომელიც უნდა იყოს სამუშაო გეგმა შემდგომი მუშაობისთვის. პროგრამა წარმოადგენს ტესტირების ლაბორატორიის შიდა სამუშაო დოკუმენტს და უნდა შეიცავდეს სამუშაოების ჩამონათვალს, დეტალურად დეველოპერული საწარმოს სპეციფიკის შესაბამისად და მოიცავს წარმოდგენილი წყაროს დოკუმენტების სისრულისა და ხარისხის ანალიზს და მათი პრაქტიკული გამოყენების ხარისხს. პროგრამული უზრუნველყოფის დიზაინში, განვითარებასა და მიწოდებაში. ხარისხის სისტემის პროცედურების გამოყენების შემოწმებას ახორციელებს ტესტირების ლაბორატორია საწარმოს სამუშაო ადგილებზე, რომელიც უზრუნველყოფს PS-ის სასიცოცხლო ციკლს. შემოწმებები ტარდება სამუშაო ადგილზე შესაბამისი დოკუმენტების სპეციალისტ-შემმუშავებლების არსებობისა და მათი დებულებებისა და რეკომენდაციების გამოყენების სისრულეზე. პროექტის სტატუსის მიმოხილვა და ხარისხის სისტემის, პროცესების ან/და პროდუქტების შიდა აუდიტი უნდა განხორციელდეს ამ სამუშაოების განხორციელებაზე უშუალო პასუხისმგებელი პირებისგან დამოუკიდებელი პერსონალის მიერ.

განვითარების ხარისხის შემოწმების მეთოდებიუზრუნველყოფილი უნდა იყოს საჭირო რესურსებიტესტირების პროგრამის განხორციელებისთვის, დაგეგმვის მეთოდებისა და კერძო ტესტირების პროცედურების შემუშავებისთვის. მეთოდები უნდა შეიცავდეს: ტესტირების ობიექტებს და მიზნებს; შეფასებული ხარისხის მაჩვენებლები; ტესტირების პირობები და პროცედურა; ტესტის შედეგების დამუშავების, ანალიზისა და შეფასების მეთოდები; ტექნიკური მხარდაჭერატესტირება და მოხსენება. უნდა იყოს მითითებული ტესტებისა და ტესტირების პროცედურის დროს გამოყენებული აპარატურა და პროგრამული უზრუნველყოფა, ასევე შემოწმების მოსალოდნელი შედეგები. შემუშავებული უნდა იყოს კორექტივების კონტროლის მეთოდები, დეფექტების გამოსწორების ქმედებები, თუ ასეთი მოთხოვნა მიიღებს აუდიტის მართვის სამსახურს. ტესტის პროგრამის მართვის სამსახურმა უნდა დააწესოს პროცედურები ნებისმიერი ტესტის ინფორმაციის, ასევე შემფასებლების მიერ შენახული მონაცემების კონფიდენციალურობის შესანარჩუნებლად.

ტესტის ანგარიშებიწარედგინება განმცხადებელს და სერტიფიცირების ორგანოს. განმცხადებელს შეუძლია სერტიფიკაციის ორგანოს წარუდგინოს ტესტირების ანგარიშები, მათი მოქმედების პირობების გათვალისწინებით, პროდუქციის შემუშავებისა და წარმოების დროს, ან დოკუმენტები ტესტების შესახებ, რომლებიც ჩატარებულია სერტიფიცირების სისტემაში აკრედიტებული ან აღიარებული შიდა ან უცხოური ტესტირების ლაბორატორიების მიერ. სერტიფიცირების ტესტის ანგარიშებზე დაყრდნობით ხდება მიღებული შედეგების შეფასება და დასაბუთებულია პროდუქციის მარეგულირებელი დოკუმენტების მოთხოვნებთან შესაბამისობის ან შეუსაბამობის შესახებ დასკვნები.

დასკვნა სასერტიფიკაციო ტესტების შედეგების შესახებშემუშავებულია სერტიფიკატების მიერ და შეიცავს განზოგადებულ ინფორმაციას ტესტის შედეგებისა და სერტიფიკატის გაცემის დასაბუთების შესახებ. სასერტიფიკაციო ტესტების უარყოფითი შედეგების მიღების შემთხვევაში მიიღება გადაწყვეტილება შესაბამისობის სერტიფიკატის გაცემაზე უარის თქმის შესახებ. სერტიფიცირებული პროდუქტის ან ხარისხის სისტემის დასრულების შემდეგ, ტესტები შეიძლება განმეორდეს. ტექნოლოგიის მდგომარეობის ან პროდუქტის ხარისხის ანალიზის შედეგები შედგენილია აქტით, რომელიც იძლევა შეფასებებს სატესტო პროგრამის ყველა პოზიციისთვის და შეიცავს დასკვნებს, მათ შორის წარმოების მდგომარეობისა და პროდუქტების ზოგად შეფასებას, მაკორექტირებელი ღონისძიებების საჭიროებას. აქტი გამოიყენება სერტიფიკაციის ორგანოს მიერ ტესტირების ანგარიშებთან ერთად, განცხადება პროგრამული პროდუქტის სერტიფიკატის გაცემისა და მოქმედების ვადის განსაზღვრის, ინსპექტირების კონტროლის სიხშირის, აგრეთვე მაკორექტირებელი ღონისძიებების შედგენისთვის.

სასერტიფიკაციო ტესტებისა და დოკუმენტაციის შემოწმების შედეგების საფუძველზე მიიღება გადაწყვეტილება სერტიფიკატის გაცემის შესახებ. სასერტიფიკაციო ტესტების უარყოფითი შედეგების მიღების შემთხვევაში მიიღება გადაწყვეტილება მოწმობის გაცემაზე უარიშესაბამისობა. გარდა ამისა, წინადადებები შეიძლება გაიგზავნოს განმცხადებელ საწარმოს უარყოფითი ტესტის შედეგების სავარაუდო მიზეზების აღმოსაფხვრელად, სერტიფიცირებული პროდუქტების დასრულების შემდეგ, ტესტები შეიძლება განმეორდეს.

სერტიფიცირების ორგანო ტესტირების ანგარიშების გაანალიზების, წარმოების შეფასების, ხარისხის სისტემის სერტიფიცირების, განაცხადის შესახებ გადაწყვეტილებაში მითითებული დოკუმენტაციის გაანალიზების შემდეგ, აფასებს პროდუქციის შესაბამისობას დადგენილ მოთხოვნებთან, ადგენს სერთიფიკატს ექსპერტების დასკვნის საფუძველზე. და აღრიცხავს მას. დიზაინში ან საოპერაციო დოკუმენტაციაში ცვლილებების შეტანისას, რამაც შეიძლება გავლენა მოახდინოს სერტიფიცირების დროს სერტიფიცირებული სისტემის ან პროგრამული პროდუქტის ხარისხზე, განმცხადებელმა უნდა აცნობოს ამის შესახებ სერტიფიკაციის ორგანოს, რათა გადაწყვიტოს დამატებითი ტესტების საჭიროება. რეგისტრაციის შემდეგ სერტიფიკატი ძალაში შედის და ეგზავნება განმცხადებელს. სერტიფიკატის გაცემის პარალელურად შესაძლებელია განმცხადებლის საწარმოს გაცემა ლიცენზიაშესაბამისობის ნიშნის გამოყენების უფლებისთვის.

სერტიფიცირებული პროგრამული პროდუქტებისთვის მათი მოქმედების განმავლობაში შესაბამისობის სერტიფიკატის მოქმედების მთელი პერიოდის განმავლობაში, ინსპექტირების კონტროლი. ინსპექტირების კონტროლი ტარდება პერიოდული სახით და დაუგეგმავი შემოწმებებიტექნოლოგიის ხარისხისა და სერტიფიცირებული პროდუქტების მოთხოვნებთან შესაბამისობა. კონტროლის ობიექტები, სერტიფიცირების სქემიდან გამომდინარე, არის სერტიფიცირებული პროდუქტები, ხარისხის სისტემა ან დეველოპერის წარმოების სტაბილურობა. შემოწმების სიხშირისა და მოცულობის განსაზღვრისას მხედველობაში მიიღება შემდეგი ფაქტორები: პროგრამული პროდუქტის პოტენციური საფრთხის ხარისხი, წარმოების სტაბილურობა, გამოშვების მოცულობა, ხარისხის სისტემის ხელმისაწვდომობა და გამოყენება განვითარების დროს, ინფორმაცია. მწარმოებლის, სახელმწიფო კონტროლისა და ზედამხედველობის ორგანოების მიერ ჩატარებული პროდუქტისა და მისი წარმოების ტესტების შედეგებზე.

ინსპექტირების კონტროლის შედეგები შედგენილია აქტით, რომელიც აფასებს სანიმუშო ტესტებისა და სხვა შემოწმებების შედეგებს, აკეთებს ზოგად დასკვნას სერტიფიცირებული პროდუქციის წარმოების მდგომარეობისა და გაცემული სერტიფიკატის მოქმედების შენარჩუნების შესაძლებლობის შესახებ. აქტი ინახება სერტიფიკაციის ორგანოში და მისი ასლები ეგზავნება დეველოპერს და იმ ორგანიზაციებს, რომლებმაც მონაწილეობა მიიღეს საინსპექციო კონტროლში. საინსპექციო კონტროლის შედეგების საფუძველზე, სერტიფიცირების ორგანოს შეუძლია შეაჩეროს ან გააუქმოს სერტიფიკატი და გააუქმოს შესაბამისობის ნიშნის გამოყენების უფლების ლიცენზია სერტიფიცირებისას კონტროლირებადი მარეგულირებელი დოკუმენტების მოთხოვნებთან პროდუქციის შეუსაბამობის შემთხვევაში. ასევე შემდეგ შემთხვევებში:

• ფუნდამენტური ცვლილებები სიმწიფის მოდელში, სტანდარტების პროფილში, პროდუქტის რეგულაციებში ან ტესტირების მეთოდში;
• ცვლილებები დიზაინში (შემადგენლობაში), პროდუქციის სისრულეში;
• განვითარებისა და წარმოების ორგანიზაციაში ან ტექნოლოგიაში ცვლილებები;
• ტექნოლოგიის, კონტროლისა და ტესტირების მეთოდების, ხარისხის სისტემის მოთხოვნებთან შეუსაბამობა, თუ ჩამოთვლილმა ცვლილებებმა შეიძლება გამოიწვიოს პროდუქციის შეუსაბამობა სერტიფიცირებისას კონტროლირებად მოთხოვნებთან.

სერტიფიკატის და შესაბამისობის ნიშნის გამოყენების უფლების ლიცენზიის შეჩერების შესახებ გადაწყვეტილება არ მიიღება, თუ მის გამცემი სერტიფიკაციის ორგანოსთან შეთანხმებული მაკორექტირებელი ღონისძიებების საშუალებით განმცხადებელს შეუძლია აღმოფხვრას შეუსაბამობის გამოვლენილი მიზეზები და დაადასტუროს, აკრედიტებულ ლაბორატორიაში ხელახალი ტესტირების გარეშე პროდუქტის ან პროცესების შესაბამისობა ნორმატიულ დოკუმენტებთან. თუ ეს შეუძლებელია, მაშინ უქმდება სერტიფიკატის მოქმედება და უქმდება შესაბამისობის ნიშნის გამოყენების უფლების ლიცენზია. სერტიფიკატის შეჩერების ან გაუქმების შესახებ ინფორმაციას სერტიფიკატის გამცემი ორგანო აწვდის განმცხადებელს, მომხმარებლებს და სხვა დაინტერესებულ ორგანიზაციებს. სერტიფიკატის მოქმედების ვადა და პროდუქციის შესაბამისობის ნიშნით ეტიკეტირების უფლება შეიძლება განახლდეს, თუ დეველოპერი საწარმო აკმაყოფილებს შემდეგ პირობებს:

• შეუსაბამობის მიზეზების იდენტიფიცირება და მათი აღმოფხვრა;
• პროდუქციის ხარისხის გაუმჯობესებისა და უზრუნველსაყოფად გაწეული სამუშაოს შესახებ სასერტიფიკაციო ორგანოსთვის ანგარიშის წარდგენა;
• პროდუქციის დამატებითი გამოცდების ჩატარება სერტიფიკაციის ორგანოს მეთოდებით და კონტროლის ქვეშ და დადებითი შედეგების მიღება.

პროგრამული პროდუქტების სერტიფიცირების პროცესებისა და შედეგების დოკუმენტაცია

ხარისხის სისტემის სერტიფიცირების დოკუმენტაციის შემადგენლობა და შინაარსისაწარმოები დამოკიდებულია პროგრამული უზრუნველყოფის დიზაინის, განვითარებისა და მოდიფიკაციის მახასიათებლებზე, ასევე მათ ხარისხზე და ტექნოლოგიური გარემოს მახასიათებლებზე. ამიტომ, თითოეული საწარმოსთვის ან პროექტისთვის საჭირო დოკუმენტების ნაკრები უნდა შეირჩეს და ადაპტირდეს ამ მახასიათებლებთან მიმართებაში. სერტიფიცირებისას შეფასებული ხარისხის სისტემის მაჩვენებლებია შესაბამისი დოკუმენტების ხელმისაწვდომობა და სიმწიფის მოდელის გარკვეული დონის მოთხოვნების პრაქტიკული შესრულება. SMMIან ადაპტირებული სტანდარტების პროფილის საფუძველზე ISO 9000:2000, ასევე მათ საფუძველზე შექმნილი, სამუშაოს აღწერასაწარმო-დეველოპერის სპეციალისტები. განმცხადებელმა უნდა მოამზადოს და სატესტო ლაბორატორიას წარუდგინოს მომხმარებელსა და დეველოპერს შორის შეთანხმებული დოკუმენტების ნაკრები და დამტკიცებული მათი სანდოობის, შემადგენლობის საკმარისობისა და სამუშაოს შესამოწმებლად მარეგულირებელი დოკუმენტების შესაბამისად.

სერტიფიცირების ძირითადი დოკუმენტების საორიენტაციო ნაკრები შედგება სამი ჯგუფისგან:

• ძირითადი რეგულაციებიხარისხის სისტემები ნომენკლატურისა და სტანდარტების პროფილის შინაარსის შესაბამისად ISO 9000:2000ან სიმწიფის მოდელები SMMI, ასევე დეველოპერების მიერ მათ საფუძველზე მომზადებული პროგრამა, სახელმძღვანელო და ინსტრუქციები, რომლებიც წარდგენილია აუდიტის ქვეშ მყოფი საწარმოს ხარისხის სისტემის ან პროდუქციის ტესტერებისთვის (ექსპერტებისთვის);
• წყარო დოკუმენტები, რომლებიც ახასიათებს კონკრეტულ საწარმოს ან პროექტს, აგრეთვე პროგრამული უზრუნველყოფის ხელსაწყოს სიცოცხლის ციკლს, რომელიც მომზადებულია პროექტის მენეჯმენტის მიერ მისი ხარისხის სერტიფიცირებისთვის;
• საწარმოს ხარისხის სისტემის ან/და პროგრამული პროდუქტის აუდიტის (სერტიფიკაციის) შედეგების ამსახველი ტესტერების საანგარიშგებო დოკუმენტები, წარდგენილი სერტიფიკაციის ორგანოს, განმცხადებელსა და აუდიტირებული საწარმოს ხელმძღვანელობას.

სერტიფიცირებისთვის წარმოდგენილი პროგრამული პროდუქტი ან საწარმოს ხარისხის სისტემა წარდგენილი უნდა იყოს შესაბამის დოკუმენტაციასთან ერთად. ამ დოკუმენტების ჯგუფების სია და სავარაუდო შინაარსი ორიენტირებულია საწარმოების ხარისხის სისტემების შემოწმების ზოგად შემთხვევაზე, რომლებიც უზრუნველყოფენ დიდი პროგრამული პროდუქტების სასიცოცხლო ციკლს. დოკუმენტების ნაკრები შეიძლება შემცირდეს და ადაპტირდეს განმცხადებელს, სერტიფიკატორსა და აუდიტირებული საწარმოს ხელმძღვანელობას შორის შეთანხმებული პროგრამული პროექტების მახასიათებლების შესაბამისად. ზოგიერთი დოკუმენტი შეიძლება გაერთიანდეს ინტეგრირებულ ანგარიშებში, გარკვეული სპეციალისტების მკაფიო პასუხისმგებლობით მათ განხორციელებაზე.

საწარმოს ხარისხის სისტემის ძირითადი დოკუმენტები და პროგრამული უზრუნველყოფის სასიცოცხლო ციკლი

1. კონცეფცია, ტერმინოლოგია, მოთხოვნები და მითითებები შესრულების გაუმჯობესებისთვის - ხარისხის მართვის სისტემები - ISO 9000:2000ან CMMI სიმწიფის მოდელის ვერსია.
2. ადაპტირებული ვერსიები ან სექციების სია და სტანდარტების რეკომენდაციები ISO 12207, ISO 15504, მათი ცვლილებები და გამოყენების სახელმძღვანელო მითითებები, შერჩეული ადაპტაციის დროს და სავალდებულოა კონკრეტული საწარმოს ან პროგრამული პროდუქტის პროექტის ხარისხის სისტემაში გამოსაყენებლად.
3. ადაპტირებული ვერსია ან სტანდარტის სექციებისა და რეკომენდაციების სია ISO 900003, შერჩეული ადაპტაციის დროს და სავალდებულო გამოსაყენებლად პროგრამული პროდუქტის მწარმოებელი საწარმოს ხარისხის სისტემაში.
4. PS პროექტის ძირითადი მახასიათებლები და ხარისხის ატრიბუტები, გამოვლენილი, ადაპტირებული და დაზუსტებული სტანდარტების საფუძველზე ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. ტექნიკური და კონფიგურაციის მართვის სახელმძღვანელოს ადაპტირებული ვერსია და დამტკიცებული გამოცემა სტანდარტების რეკომენდაციებზე დაყრდნობით ISO 14764, ISO 10007, ISO 15846.
6. სამუშაო აღწერილობების ერთობლიობა, რომელიც განსაზღვრავს პასუხისმგებლობას, უფლებამოსილებას და პროცედურებს ურთიერთქმედების ყველა მენეჯერის, შესრულებისა და შემოწმების პერსონალის მუშაობისთვის, რომელიც ჩართულია საწარმოს ხარისხის სისტემის პროცედურებში კონკრეტული PS პროექტისთვის.

წყარო დოკუმენტები, რომლებიც ასახავს კონკრეტული პროგრამული ხელსაწყოს სასიცოცხლო ციკლის მახასიათებლებს

1. საწარმოში შექმნილი პროგრამული პროდუქტების მახასიათებლების აღწერა, სისტემა და მათი სასიცოცხლო ციკლის გარე გარემო, რომელიც აუცილებელია PS პროექტის სტანდარტებისა და მოთხოვნების ადაპტაციისა და მომზადებისთვის და საწარმოს ხარისხის სისტემის შესაბამისად. სტანდარტების რეკომენდაციები ISO 12207, ISO 15504, ISO 90003და ISO 9126.
2. ხარისხის სისტემის სფეროში საწარმო-დეველოპერის მიზნების, მოთხოვნებისა და ვალდებულებების აღწერა, პროგრამული უზრუნველყოფის მთელი სასიცოცხლო ციკლის განვითარების პროცესებისა და პროდუქტების ხარისხის კრიტერიუმები, მიწოდება და მხარდაჭერა.
3. ოპერაციული დოკუმენტების ნაკრები, რომელიც მიეწოდება მომხმარებელს და მომხმარებლებს, რათა უზრუნველყოს პროგრამული პროდუქტის სასიცოცხლო ციკლი და გამოყენება ადაპტირებული სტანდარტების საფუძველზე. ISO 9294, ISO 15910, ISO 18019.
4. დოკუმენტაციისა და ავტომატიზაციის ხელსაწყოები დიზაინის, განვითარების, მოდიფიკაციის, კონტროლისა და ტესტირებისთვის, რომლებიც გამოიყენება პროგრამული პროდუქტის სასიცოცხლო ციკლის უზრუნველსაყოფად.
5. საწარმოს ხარისხის სისტემისა და პროგრამული პროდუქტის აპლიკაციის ტესტირებისა და პროცესების ეფექტურობის შეფასების გეგმები და მეთოდები.
6. შენარჩუნების მეთოდები, პროგრამული პროდუქტის კომპონენტებისა და დოკუმენტაციის იდენტიფიკაცია, პროგრამული უზრუნველყოფის და მონაცემთა კომპლექსების ვერსიების ანალიზი და დამტკიცება.
7. კონფიგურაციის მართვის, დამტკიცების, შენახვის, დაცვის, პროგრამული პროდუქტის ვერსიების და თანმხლები დოკუმენტების კოპირების მეთოდოლოგია, აგრეთვე საწარმოს არქივში რეგისტრირებული ხარისხის მახასიათებლების შესახებ მონაცემების დაგროვება და შენახვა პროგრამული პროდუქტის ვერსიების სასიცოცხლო ციკლის განმავლობაში.

მიღებული ტესტის დოკუმენტები - საწარმოს ხარისხის სისტემის ან/და პროგრამული პროდუქტის სერტიფიცირება

1. საწარმოს ხარისხის სისტემის მოთხოვნებსა და დებულებებზე ადაპტირებული დოკუმენტაციის ხელმისაწვდომობის, შესაბამისობისა და სისტემატური შესრულების შესახებ ანგარიში, რომელიც უზრუნველყოფს ხარისხის უზრუნველყოფის ინტეგრირებულ პროცესს პროგრამული პროდუქტის მთელი სასიცოცხლო ციკლის განმავლობაში.
2. ხარისხის სისტემის მდგომარეობისა და გამოყენების მონიტორინგისა და ტესტირების შედეგები, პერიოდულად ტარდება მისი ვარგისიანობისა და ეფექტურობის დასადგენად.
3. ანგარიში ინსპექტირების ჩატარების მეთოდების ხელმისაწვდომობისა და შენარჩუნების შესახებ და დოკუმენტირებული ანგარიშები მიღწეული ხარისხის შედეგების შესახებ მომხმარებელთან სერტიფიცირების ხელშეკრულების მოთხოვნების შესრულებისას.
4. პროგრამული პაკეტის მიღწეული ხარისხის მახასიათებლების რეგისტრაციის შედეგები: პროგრამული პროდუქტისა და მისი კომპონენტების ხარისხის მახასიათებლებისა და ატრიბუტების შესახებ რეგისტრირებული მონაცემების იდენტიფიკაცია, დაგროვება, შენახვა.
5. განვითარების გეგმის განხორციელების შედეგები, შემუშავების ეტაპების დოკუმენტირებული შეყვანისა და გამომავალი მონაცემები და პს-ის სასიცოცხლო ციკლის განხორციელების შემოწმების პროტოკოლები.
6. ხარისხის პროგრამის პრაქტიკული განხორციელებისა და ხარისხის სფეროში რეგულირებადი საქმიანობის განხორციელების შედეგები PS-ის სასიცოცხლო ციკლის ყველა ეტაპზე.
7. გარემოს ტრენაჟორების და ტესტის გენერატორების სერტიფიცირების შედეგები, აგრეთვე მათი საკმარისობის შეფასება პროგრამული პროდუქტის სასერტიფიკაციო ტესტების შესასრულებლად.
8. გეგმებისა და ტესტის მეთოდების განხორციელების ანალიზის შედეგები, ტესტის ანგარიშები, ტესტის შედეგების მოთხოვნებთან შესაბამისობის შეფასება, ასევე ტესტის შედეგები დამტკიცებული განმცხადებლის, მომხმარებლისა და მიმწოდებლის წარმომადგენლების მიერ.
9. პროგრამული სისტემის სასიცოცხლო ციკლის რეალური მახასიათებლებისა და საწარმოს ხარისხის სისტემის შემოწმების შედეგების აქტი, დასკვნები მათი შესაბამისობის შესახებ პროგრამული პროდუქტის წარმოების სერტიფიცირების მოთხოვნებთან.
10. საწარმოს ან/და პროგრამული პროდუქტის ხარისხის სისტემის სერთიფიკატი და მისი სასიცოცხლო ციკლის უზრუნველყოფა, შესაბამისობის ნიშნების გამოყენების ლიცენზია.

ლიტერატურა

ვ.ვ. ლიპაევი -- პროგრამული უზრუნველყოფის სიცოცხლის ციკლის სტანდარტების პროფილები. -- Jet Info, Newsletter, N 12, 2005 წ

კ. მილმანი, ს. მილმანი -- SMMI არის ნაბიჯი მომავლისკენ. -- ღია სისტემები. N 5-6 (2005), N2 (2006) 2005, 2006 წ.

ISO IEC TR 15504-CMMI პროგრამული ინსტრუმენტების და საინფორმაციო სისტემების შექმნისა და შენარჩუნების პროცესების სიმწიფის შეფასება და სერტიფიცირება. პერ. ინგლისურიდან -- მ.: წიგნი და ბიზნესი, 2001

ვ.ვ. ლიპაევი -- რთული პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის პროცესები და სტანდარტები. დირექტორია.-- M.: SINTEG, 2006 წ

ვ.ვ. ლიპაევი -- ფართომასშტაბიანი პროგრამული უზრუნველყოფის ხარისხის უზრუნველყოფის მეთოდები.-- M.: RFBR. SINTEG, 2003 წ

"; ანტიწყარო: "პროგრამული პროდუქტები ახლა გამოიყენება მენეჯმენტის პრობლემების გადასაჭრელად ადამიანის საქმიანობის თითქმის ყველა სფეროში: ეკონომიკაში, სოციალურ, სამხედრო და სხვა სფეროებში. შიდა პროგრამული პროდუქტების მაღალი ხარისხის უზრუნველყოფა მათი მასობრივი განვითარებისა და მიწოდების დროს სხვადასხვა აპლიკაციებისთვის ქვეყანაში და მსოფლიო ბაზარზე გახდა სტრატეგიული ამოცანა."; პირობა: 1]$

Ანოტაცია: დეტალურად არის შესწავლილი იდეების წრე, რომელიც ემყარება განვითარების პროცესების გაუმჯობესების ალბათ ყველაზე ცნობილ მეთოდოლოგიას. პროგრამული უზრუნველყოფა- SMM. გაანალიზებულია HMM-ის ლოგიკა და სტრუქტურა. ნაჩვენებია კავშირი HMM-სა და ადრე შესწავლილ პროცესის მოდელებს შორის.

ფარგლებში შექმნილი შესანიშნავი პრაქტიკული ინსტრუმენტი პროცესის მიდგომასაქმიანობის აღწერას დიზაინის ორგანიზაციაკერძოდ, ორგანიზაცია, რომელიც ავითარებს Ინფორმაციული სისტემები , აჩვენებს HMM მეთოდოლოგიას. CMM ნიშნავს შესაძლებლობების სიმწიფის მოდელს, რაც უხეშად ნიშნავს "მართვის სისტემის სიმწიფის მოდელს". ლიტერატურაში, CMM უფრო ხშირად მოიხსენიება, როგორც ორგანიზაციული სიმწიფის მოდელი და მეც მივყვები ამ ტრადიციას.

SMM-ის გაჩენის ისტორია ასეთია. 80-იანი წლების ბოლოს. გასულ საუკუნეში, აშშ-ს თავდაცვის დეპარტამენტმა დაავალა პროგრამული უზრუნველყოფის ინჟინერიის ინსტიტუტი 1Eng. SEI - პროგრამული უზრუნველყოფის ინჟინერიის ინსტიტუტიკარნეგი მელონის უნივერსიტეტი მუშაობს პროგრამული უზრუნველყოფის განვითარების პროექტებში ქვეკონტრაქტორების შერჩევის კრიტერიუმების სისტემაზე. სამუშაოები დასრულდა 1991 წელს და შედეგი იყო CMM. დაუყოვნებლივ უნდა გავაკეთოთ დათქმა, რომ მოდელი არ შეიცავს რაიმე ფინანსურ, ეკონომიკურ, პოლიტიკურ, ორგანიზაციულ ასარჩევი კრიტერიუმიქვეკონტრაქტორი, ასევე საიდუმლო სამუშაოზე დაშვების შესაძლებლობის კრიტერიუმები (ალბათ, ასეთი ამოცანები არ იყო დასახული). საუბარია მხოლოდ კრიტერიუმებზე, რომლებიც აღწერს პოტენციური ქვეკონტრაქტორის შესაძლებლობებს პროგრამული სისტემების შემუშავების თვალსაზრისით.

CMM სტრუქტურა

მოდელის შემქმნელებმა ორგანიზაციის პროცესები აიღეს საფუძვლად ორგანიზაციის ხარისხიანი სამუშაოს შესრულების უნარის შესაფასებლად, რომელსაც (უნარს) სიმწიფე ეწოდა. შემდეგ მათ გააკეთეს რამდენიმე არა ტრივიალური ვარაუდი, რომელიც შემდგომში იქნა მიღებული და სამართლიანად აღიარებული მრავალი IT პროფესიონალის მიერ (და შესაძლოა მათი უმეტესობა).

ვარაუდი 1. არსებობს ხარისხობრივად განსხვავებული სიმწიფის დონე დიზაინის ორგანიზაციაგანვითარებადი Ინფორმაციული სისტემები(HMM მოდელში არის ხუთი ასეთი დონე).

ვარაუდი 2. ნებისმიერი დეველოპერული ორგანიზაცია დაინტერესებულია გადავიდეს სიმწიფის უფრო მაღალ დონეზე (არა მხოლოდ იმისთვის, რომ გაზარდოს თავისი შანსები თავდაცვის დეპარტამენტის კონტრაქტებისთვის ბრძოლაში, არამედ საკუთარი გაუმჯობესების მიზნით).

ვარაუდი 3. რიგზე გადასვლა შესაძლებელია მხოლოდ შემდეგ დონეზე. დონეზე „გადახტომა“ შეუძლებელია (უფრო ზუსტად, ორგანიზაციისთვის რისკები ამავდროულად მკვეთრად იზრდება).

ამრიგად, დონეები ქმნიან „კიბეს“, რომლის გასწვრივ ორგანიზაცია მაღლა დგას საკუთარი განვითარება. თითოეულ დონეს ახასიათებს ორგანიზაციის პროცესების გარკვეული შემადგენლობა და თვისებები. SMM "დონის კიბე" ფართოდ იქნა მიღებული და გავრცელებული. აი, როგორ გამოიყურება იგი.

დონე 1 "დამწყები". მთლიანობაში წარმოების პროცესი ხასიათდება როგორც ყოველ ჯერზე შექმნილი კონკრეტული პროექტისთვის და ზოგჯერ ქაოტურიც. მხოლოდ რამდენიმე პროცესია განსაზღვრული და პროექტის წარმატება დამოკიდებულია ინდივიდების ძალისხმევაზე.

დონე 2 "განმეორებადი". ჩამოყალიბებულია პროექტის მართვის ძირითადი პროცესები, რაც საშუალებას გაძლევთ თვალყური ადევნოთ ხარჯებს, აკონტროლოთ სამუშაო გრაფიკი და შექმნილი პროგრამული გადაწყვეტის ფუნქციონირება. დაადგინა პროცესის დისციპლინა, რომელიც საჭიროა წარსული წარმატებების გასამეორებლად მსგავსი აპლიკაციების განვითარების პროექტებში.

დონე 3 "განსაზღვრული". წარმოების პროცესი დოკუმენტირებული და სტანდარტიზებულია ორივესთვის მენეჯერული მუშაობაასევე დიზაინისთვის. ეს პროცესი ინტეგრირებულია ორგანიზაციის სტანდარტული წარმოების პროცესში. ყველა პროექტი იყენებს ორგანიზაციის სტანდარტული საოპერაციო პროცესის დამტკიცებულ მორგებულ ვერსიას.

დონე 4 "მართული". გროვდება წარმოების პროცესისა და შექმნილი პროდუქციის ხარისხის დეტალური რაოდენობრივი მაჩვენებლები. როგორც წარმოების პროცესი, ასევე პროდუქცია ფასდება და კონტროლდება რაოდენობრივი თვალსაზრისით.

დონე 5 "ოპტიმიზაცია". პროცესის უწყვეტი გაუმჯობესება მიიღწევა რაოდენობრივი გზით უკუკავშირიპროცესით და მასში მოწინავე იდეებისა და ტექნოლოგიების დანერგვით.

სიმკაცრის ნაკლებობის მიუხედავად, ზემოაღნიშნული განმარტება ინტუიციურად ყველაზე ხშირად არ იწვევს წინააღმდეგობებს. უფრო მეტიც, გამოცდილ სპეციალისტებს ესმით, თუ რატომ არის შესაძლებელი გადასვლები მხოლოდ შემდეგ დონეზე, ასევე რატომ ღირს საერთოდ ასეთი გადასვლისკენ სწრაფვა. ამავდროულად, HMM მოდელი არ შეიცავს ამგვარი მიდგომის რაიმე რაოდენობრივ ან თუნდაც ფორმალურ დასაბუთებას, რაც, თუმცა, არ აკლებს მის დამსახურებას.

შემდგომ, როგორც ამბობენ, ტექნოლოგიის საკითხია. მოდელის სტრუქტურა განისაზღვრება (სურათი 7.1), მოცემულია განმარტებები და იწყება შრომატევადი სამუშაოები თითოეული პროცესის ზუსტად აღწერისთვის თითოეულ დონეზე. იმისათვის, რომ შევაფასოთ გაკეთებულის პრაქტიკული ღირებულება, მოდით გავიაროთ ამ გზის ნაწილი.

ბრინჯი. 7.1.

ნახ. 7.1 შეიცავს შემდეგ ცნებებს.

ძირითადი პროცესის ჯგუფი. როგორც ნათქვამია (Paulk, et al., 1995), "საკვანძო პროცესების თითოეული ჯგუფი განსაზღვრავს დაკავშირებული საქმიანობის ბლოკს, რის შედეგადაც მიიღწევა მიზნების ნაკრები, რომლებიც მნიშვნელოვანია წარმოების პროცესის პროდუქტიულობის გაზრდისთვის. მაგალითად, ძირითადი პროცესების ჯგუფისთვის " მოთხოვნების მართვა"(იხ. სურათი 7.2) მიზანია პროგრამული უზრუნველყოფის განვითარების პროექტის მოთხოვნების შეჯერება მომხმარებელსა და დეველოპერს შორის."

CMM-ში ინდივიდუალური პროცესები არ არის. სამაგიეროდ არსებობენ ინდივიდუალური სამუშაოები, სახელწოდებით ძირითადი პრაქტიკა (იხ. ქვემოთ), რომლებიც დაკავშირებულია ერთმანეთთან შეყვანით და გამომავალით და ემსახურება სამშენებლო პროცესების წყაროს მასალას. CMM არ იძლევა მითითებებს იმის შესახებ, თუ როგორ უნდა იყოს სტრუქტურირებული პროცესები, ანუ ძირითადი პრაქტიკის დაკავშირება ლოგიკურ თანმიმდევრობებში. ძირითადი პრაქტიკის ერთობლიობას ეწოდება ძირითადი პროცესის ჯგუფები.

ბრინჯი. 7.2.

CMM-ში ძირითადი პროცესების ჯგუფები შედგენილია სიმწიფის დონეზე (სურათი 7.2), ანუ, ყველა პრაქტიკა ამ დონეზე ურთიერთქმედებს მხოლოდ ერთმანეთთან და არ ურთიერთქმედებს სხვა დონეზე არსებულ პრაქტიკებთან. ეს საშუალებას გაძლევთ უზრუნველყოთ ყველა პროცესის სრული შესრულება კონკრეტულ დონეზე და, შესაბამისად, დააკავშიროთ დონე ორგანიზაციის განვითარების დასრულებულ ეტაპთან.

ზედსართავი სახელი "გასაღები" გულისხმობს, რომ არსებობს პროცესის ჯგუფები(ანუ პრაქტიკის ნაკრები), რომლებიც არ არის საკვანძო სიმწიფის კონკრეტული დონის თვალსაზრისით, ანუ არ არის დაკავშირებული ამ დონის მიზნების მიღწევასთან (იხ. ქვემოთ). HMM მოდელი არ აღწერს ყველაფერს პროცესის ჯგუფებიპროგრამული უზრუნველყოფის შემუშავებასა და შენარჩუნებასთან დაკავშირებული. იგი აღწერს მხოლოდ იმ ჯგუფებს, რომლებიც იდენტიფიცირებულნი არიან როგორც წარმოების პროცესის პროდუქტიულობის ძირითადი განმსაზღვრელი.

მიზნები. CMM-ში მიზნები არ არის დაკავშირებული პროცესებთან, არამედ ძირითადი პროცესების ჯგუფებთან. როგორც ზემოთ აღინიშნა, მიზნები მიიღწევა ძირითადი პრაქტიკის დანერგვით. CMM-ში მიზნის მიღწევა ნიშნავს, რომ ჯერ ერთი საკვანძო პრაქტიკის განხორციელების შემდეგ მიიღება სასურველი შედეგი და მეორეც საკმაოდ თანმიმდევრულად მიიღება. ძირითადი პროცესის ჯგუფის მიზნების მიღწევის გზა შეიძლება განსხვავდებოდეს პროექტიდან პროექტში განსხვავებების გამო. საგნობრივი სფერო ან გარემო.

თუ ეს მიზნები განხორციელებულია ყველა პროექტისთვის, მაშინ ეს ნიშნავს, რომ ორგანიზაციამ მიაღწია საწარმოო პროცესის სიმწიფის დონეს, რომელიც დაკავშირებულია ძირითადი პროცესების ამ ჯგუფთან.

თავი. სექციები (თითოეულ დონეზე არის ხუთი მათგანი და ისინი ყოველთვის ერთნაირია) წარმოადგენს ძირითადი პროცესების ჯგუფების თვისებებს, რომლებიც უნდა განხორციელდეს შესაბამის დონეზე. ეს თვისებები აღწერს, თუ როგორ ხორციელდება პროცესები და რამდენად ლეგალიზებულია ისინი ორგანიზაციაში, ანუ ოფიციალურად დამტკიცებული და კოორდინირებულია კორპორატიულ პროცედურებთან, პოლიტიკასთან და სხვა პროცესებთან. აქ არის ხუთი განყოფილება.

შესრულების ვალდებულებები

აღწერეთ ის ქმედებები, რომლებიც ორგანიზაციამ უნდა განახორციელოს, რათა უზრუნველყოს პროცესის ჩამოყალიბება და სტაბილურობა. შესრულების ვალდებულებები, როგორც წესი, დაკავშირებულია ორგანიზაციული პოლიტიკის ჩამოყალიბებასთან და უმაღლესი მენეჯმენტის მხარდაჭერასთან.

წინაპირობები

აღწერეთ წინაპირობები, რომლებიც უნდა აკმაყოფილებდეს პროექტს ან ორგანიზაციას საწარმოო პროცესის კომპეტენტური განხორციელებისთვის; ჩვეულებრივ ეხება რესურსებს, ორგანიზაციულ სტრუქტურებს და საჭირო ტრენინგს.

ოპერაციები მიმდინარეობს

ოპერაციების მიმდინარეობის სექცია აღწერს არსებით სამუშაოს, რომელიც უნდა შესრულდეს ამ დონეზე. შესრულებული ოპერაციები, როგორც წესი, მოიცავს გეგმების შექმნას და კონკრეტული ოპერაციების განხორციელებას, სამუშაოს შესრულებას და თვალყურის დევნებას და საჭიროების შემთხვევაში მაკორექტირებელი ქმედებების განხორციელებას.

გაზომვები და ანალიზი

განყოფილება „გაზომვები და

„საკვანძო პროცესების თითოეული ჯგუფი გამოიხატება ძირითადი პრაქტიკით, რომელთა განხორციელება ხელს უწყობს ჯგუფის მიზნების მიღწევას. ძირითადი პრაქტიკა აღწერს ინფრასტრუქტურას და ოპერაციებს, რომლებიც ყველაზე მეტად უწყობს ხელს ძირითადი პროცესების ჯგუფის ეფექტურ განხორციელებას და ჩამოყალიბებას.

თითოეული ძირითადი პრაქტიკა შედგება ერთი წინადადებისგან, რომელსაც ხშირად მოჰყვება უფრო დეტალური აღწერა, რომელიც შეიძლება შეიცავდეს მაგალითებსა და განმარტებებს. ძირითადი პრაქტიკა, რომელსაც ზოგჯერ უწოდებენ უმაღლესი დონის საკვანძო პრაქტიკებს, ადგენს ძირითად პოლიტიკას, პროცედურებსა და ოპერაციებს ძირითადი პროცესების ჯგუფისთვის. დეტალური აღწერილობის კომპონენტებს ხშირად მოიხსენიებენ, როგორც ქვეპრაქტიკებს“.

ძირითადი პრაქტიკა აღწერს იმას, თუ რა უნდა გაკეთდეს, მაგრამ ისინი არ უნდა იქნას მიღებული როგორც დოგმა იმის შესახებ, თუ როგორ უნდა მიაღწიოს მიზნებს. ძირითადი პროცესის ჯგუფის მიზნების მიღწევა შესაძლებელია ალტერნატიული პრაქტიკის მეშვეობით. ძირითადი პრაქტიკის ინტერპრეტაცია უნდა იყოს გონივრული, რაც საშუალებას მისცემს ძირითადი პროცესების ჯგუფის მიზნების მიღწევას. ეფექტური გზა, თუმცა შესაძლოა ფორმალურად და განსხვავებული რეკომენდირებული CMM-ისგან.

IT მენეჯმენტის აქტივობების გადახედვა, რომლებშიც პროცესების ნაცვლად განიხილება მათი კომპონენტები - ძირითადი პრაქტიკა და პროცესები წარმოდგენილია მხოლოდ ვირტუალურად, რადგან ის, რაც შეიძლება აშენდეს ძირითადი პრაქტიკებიდან, გამოიყურება გარკვეულწილად ეგზოტიკური ერთი შეხედვით. აქამდე IT მენეჯმენტის გაუმჯობესების ამოცანა წყდებოდა საცნობარო პროცესის მოდელიდან მზა პროცესების დანერგვით. ახლა არის მრავალი დონე, რომელიც შეიცავს განსხვავებულ (ანუ პროცესებში არ ინტეგრირებულ) საკვანძო პრაქტიკებს და დონეებში გადაადგილების რეკომენდებულ თანმიმდევრობას. IT მენეჯმენტი, CMM-ის თანახმად, უმჯობესდება, როდესაც ის გადადის სიმწიფის უფრო მაღალ დონეზე. რა ხდება ამ აქციასთან?

დონეების განმარტებებში (იხ. სურათი 7.2) გამოჩნდა ისეთი რამ, როგორიცაა "წარმოების პროცესი". ის ასევე გვხვდება ძირითადი პროცესების ჯგუფის განსაზღვრაში და ეს შემთხვევითი არ არის. წარმოების პროცესი, ან როგორც მას სწორად უწოდებენ CMM-ში, სტანდარტში Საწარმოო პროცესიორგანიზაციები (OSS) არის მთელი მოდელის ერთ-ერთი ცენტრალური კონცეფცია.

1986 წლის ნოემბერში, ამერიკის პროგრამული უზრუნველყოფის ინჟინერიის ინსტიტუტმა (SEI), Mitre Corporation-თან ერთად, დაიწყო პროგრამული უზრუნველყოფის განვითარების პროცესის სიმწიფის კვლევის შემუშავება, რომელიც გამიზნული იყო მათი შიდა პროცესების გაუმჯობესებაში.

ამ მიმოხილვის შემუშავება გამოწვეული იყო აშშ-ს ფედერალური მთავრობის თხოვნით, პროგრამული უზრუნველყოფის შემუშავებისთვის ქვეკონტრაქტორების შეფასების მეთოდის შესახებ. რეალური პრობლემა იყო მართვის უუნარობა დიდი პროექტები. ბევრ კომპანიაში პროექტები საგრძნობლად დაგვიანებით და ბიუჯეტზე მეტი იყო მიწოდებული. საჭირო იყო ამ პრობლემის გადაწყვეტის პოვნა.

1987 წლის სექტემბერში SEI გამოვიდა მოკლე მიმოხილვაპროგრამული უზრუნველყოფის განვითარების პროცესები მათი სიმწიფის დონის აღწერით, ისევე როგორც კითხვარი, რომელიც შექმნილია კომპანიის იმ სფეროების დასადგენად, რომლებშიც საჭირო იყო გაუმჯობესება. თუმცა კომპანიების უმეტესობამ ეს კითხვარი მზა მოდელად მიიჩნია, რის შედეგადაც 4 წლის შემდეგ კითხვარი გადაკეთდა რეალურ მოდელად, Capability Maturity Model for Software (CMM). CMM-ის პირველი ვერსია (ვერსია 1.0), რომელიც გამოვიდა 1991 წელს, გადაიხედა 1992 წელს სამუშაო შეხვედრის მონაწილეების მიერ, რომელსაც ესწრებოდა პროგრამული უზრუნველყოფის 200-მდე სპეციალისტი და დეველოპერების საზოგადოების წევრები.

1. ელემენტარული. ორგანიზაციის ყველაზე პრიმიტიული სტატუსი. ორგანიზაციას შეუძლია პროგრამული უზრუნველყოფის შემუშავება. ორგანიზაციას არ გააჩნია აშკარად გაცნობიერებული პროცესი და პროდუქტის ხარისხი მთლიანად განისაზღვრება დეველოპერების ინდივიდუალური შესაძლებლობებით. ერთი იღებს ინიციატივას და გუნდი მის მითითებებს ასრულებს. ერთი პროექტის წარმატება არ იძლევა მეორის წარმატების გარანტიას. პროექტის ბოლოს მონაცემები შრომის ხარჯების, გრაფიკისა და ხარისხის შესახებ არ ფიქსირდება.
2. განმეორებადი. გარკვეულწილად ხდება პროცესის მონიტორინგი. ჩანაწერები კეთდება შრომის ხარჯებისა და გეგმების შესახებ. თითოეული პროექტის ფუნქციონირება აღწერილია წერილობით. 1999 წლის შუა პერიოდში, ორგანიზაციების მხოლოდ 20% იყო მე-2 ან უფრო მაღალი დონე.
3. დაყენებულია. აქვს განსაზღვრული, დოკუმენტირებული და დადგენილი პროცესიინდივიდებისგან დამოუკიდებელი მუშაობა. ანუ შეთანხმდნენ პროფესიული სტანდარტებიდა დეველოპერები ახორციელებენ მათ. ასეთ ორგანიზაციებს შეუძლიათ საკმაოდ საიმედოდ იწინასწარმეტყველონ ადრე დასრულებული პროექტების ხარჯები.
4. მართული. მათ შეუძლიათ ზუსტად განსაზღვრონ სამუშაოს დრო და ღირებულება. არსებობს დაგროვილი გაზომვების მონაცემთა ბაზა. მაგრამ ახალი ტექნოლოგიებისა და პარადიგმების გაჩენით ცვლილებები არ შეინიშნება.
5. ოპტიმიზირებულია. მიმდინარეობს ახალი და გაუმჯობესებული მეთოდებისა და ინსტრუმენტების მოძიება და დაუფლების პროცედურა.

განვითარება

მოდელის პრაქტიკაში გამოყენებამ გამოავლინა ბუნდოვანება პროგრამული უზრუნველყოფის განვითარების პროცესების ორგანიზების უფრო მაღალი დონის მიღწევის მიდგომებში. ამიტომ 2002 წლისთვის მუშავდება განვითარების პროცესის გასაუმჯობესებლად რეკომენდაციები, რომლებიც ე.წ CMMI (Capability Maturity Model Integration). ამჟამად უახლესი ვერსია CMMi - 1.3 (გამოქვეყნებულია 2010 წლის ნოემბერში).

იხილეთ ასევე

ბმულები

MIT სტუდენტური ფორუმი > მთავარი განყოფილება > ტესტები > საკონტროლო სისტემების სიმულაცია

ხედი სრული ვერსია: მართვის სისტემების სიმულაცია

ყველა მოდული მოვაგვარე, ყველაფერი 4-ით ჩავაბარე, ბოლო 2-ით, ახლა სამ დღეში ვეცდები ჩავაბარო, არც ერთი იდენტური კითხვა არ ყოფილა. ვცადე ფინალური ტესტის გასწორება, მაგრამ შეამოწმე, სისწორის გარანტია არ შემიძლია, ვამხილავ ყველაფერს, რაც მაქვს, იქნებ ვინმემ ჩემზე უკეთ ჩააბაროს. თუ ვინმეს აქვს მეორე, მესამე მცდელობა დაიტანე, თუ წინააღმდეგი არ ხარ, დისციპლინა, მართლა ძალიან რთულია.:eek:

საბოლოო ტესტი 100 100-დან

ყოველ ჯერზე შედეგი განსხვავებულია?

სხვა კითხვები, რომლებიც აქ არ არის ჩამოთვლილი და დამჭირდა. პასუხებს არ ვეძებ, რადგან მის გარეშე 4 ჩავაბარე. ვისაც დაბნეულობა უნდა, დანარჩენისთვის პასუხები აქ ატვირთეთ 🙂

მოდული 1:
რა არ უნდა ჩაითვალოს ბიზნეს პროცესის დამახასიათებელ ნიშნად?

ღირებულების დამატება

აირჩიეთ ერთი პასუხი:
პროცესის პროდუქტი, რომელიც განასახიერებს ადრე დასახულ მიზნებს

აირჩიეთ ერთი პასუხი:

ფინალში (გავიდა 4.

რა არის შესაძლებლობების სიმწიფის მოდელი? (CMM)

ეს კითხვები + უკვე ფორუმზე):
1. აირჩიეთ სწორი განცხადება.
აირჩიეთ ერთი პასუხი:
განყოფილებების ბიზნეს პროცესი შედგება სხვადასხვა ღირებულების ჯაჭვებისგან (UNSURE)
საბოლოო ბიზნეს პროცესი შედგება ბიზნეს პროცესებისგან სხვადასხვა ორგანიზაციებს
ჯვარედინი ფუნქციური ბიზნეს პროცესი, როგორც წესი, შედგება დეპარტამენტების ბიზნეს პროცესებისგან

2. რა არ არის უნივერსალური ბიზნეს პროცესის სქემის ელემენტი?
აირჩიეთ ერთი ან მეტი პასუხი:
პროცესის რესურსები
რისკები
ბიზნეს პროცესის მართვის საქმიანობა
Გარემო ფაქტორები
შეყვანის გამოსავლებად გადაქცევის აქტივობა

3. მატერიალური რესურსებიროგორც პროცესების ძირითადი ელემენტია:
აირჩიეთ ერთი პასუხი:
ერთმანეთთან და სხვა რესურსებთან ურთიერთქმედების სისტემებში გაერთიანებული საქმიანობის აქტიური სუბიექტები
საკონტროლო მოქმედებები, რომლებიც მიმართულია საქმიანობის სუბიექტების მიერ საქმიანობის ობიექტებზე, პროცესების მიზნებისა და შედეგების განსაზღვრა.
პასიური საშუალებები და აქტივობები, რომლებიც გამოიყენება პროცესების განსახორციელებლად (დარწმუნებული არ არის)

28.03.2014, 10:07

მოდული 1:
რა არ უნდა ჩაითვალოს ბიზნეს პროცესის დამახასიათებელ ნიშნად? აირჩიეთ ერთი ან მეტი პასუხი:
შეყვანის კონვერტაცია გამოსავლებად
პროდუქტის მიწოდება გარე მომხმარებლისთვის
ღირებულების დამატება
ჭარბი ან/და გამოყენების ღირებულების ფორმირება

შედეგები, როგორც პროცესის ძირითადი ელემენტებია:
აირჩიეთ ერთი პასუხი:
ერთმანეთთან და სხვა რესურსებთან ურთიერთქმედების სისტემებში გაერთიანებული საქმიანობის აქტიური სუბიექტები
პროცესის პროდუქტი, რომელიც განასახიერებს ადრე დასახულ მიზნებს პასიური საშუალებები და აქტივობები, რომლებიც გამოიყენება პროცესების განსახორციელებლად
პროცესის დასასრულებლად აუცილებელი მატერიალური, ენერგეტიკული და საინფორმაციო ობიექტების ნაკრები

რა არის უკუკავშირი ბიზნეს პროცესში?
აირჩიეთ ერთი პასუხი:
მიზანმიმართული და შეგნებული გავლენა პროცესზე, შექმნილია სასურველი შედეგის უზრუნველსაყოფად
პროცესის შედეგების ანალიზი და შედარება ადრე დასახულ მიზნებთან
ზემოქმედება გარემოს ობიექტებისა და ფაქტორების სისტემაზე, რომლებიც წარმოადგენენ სისტემის ფუნქციონირებაში სხვადასხვა სახის გადახრების წყაროს.
ასე ვუპასუხე! მაგრამ მაინც გამოვიდა 4

ფინალში - ეს კითხვები + ის, რაც უკვე არსებობს:
1 სიიდან აირჩიეთ საპროექტო-სამიზნე სტრუქტურების ნაკლოვანებები.

2 აირჩიეთ სიიდან ბრძანების გამოყენების მაგალითები.
ხარისხის ჭიქები
კომიტეტები
სამუშაო გუნდები

3 სიიდან აირჩიეთ ორგანული ორგანიზაციული სტრუქტურების გამოყენების პირობები.
მუშები მოტივირებული არიან რთული საჭიროებებით
მიზნები ბუნდოვანია და დინამიურად იცვლება
ძალაუფლება კითხვის ნიშნის ქვეშ დგას და შემოწმებულია, მოითხოვს დადასტურებას ქვეშევრდომებისგან

4 სიიდან აირჩიეთ პროექტზე დაფუძნებული ორგანიზაციული სტრუქტურების უპირატესობები.
თანამშრომლების უშუალო დაქვემდებარება პროექტის მენეჯერის მიმართ და ამით მიიღწევა ამ თანამშრომლების ძალისხმევის მიმართულების გაურკვევლობა.

5 დამხმარე პროცესები:
Უზრუნველყოფა ეფექტური განხორციელებაძირითადი პროცესები

ბოლო კლასი 5
კითხვა 1
აირჩიეთ ბრძანების გამოყენების მაგალითების სიიდან.

ხარისხის ჭიქები
კომიტეტები
სამუშაო გუნდები

კითხვა 2
რისთვის გამოიყენება შუამავლები ფუნქციონალურ სტრუქტურაში?

სხვადასხვა სტრუქტურული სამმართველოს საქმიანობის ინტეგრირება

კითხვა 3
დაასახელეთ ურთიერთობების ტიპები SADT მოდელში:
კონტროლი
გასასვლელი მექანიზმი
შეყვანის გამოხმაურება

კითხვა 4
ქვემოთ ჩამოთვლილი ბიზნეს პროცესებიდან რომელია ყველაზე ხანმოკლე?
განყოფილების ბიზნეს პროცესი

კითხვა 5
რა მეთოდები, მეთოდოლოგიები და ინსტრუმენტები შეიძლება გამოყენებულ იქნას ბიზნეს პროცესის საინფორმაციო მოდელების შესაქმნელად?

გეინ-სარსონის მეთოდოლოგია
ჩენისა და ბარკერის სამოდელო ენა

კითხვა 6
რომელი ბიზნეს პროცესის წარმოდგენა შეესაბამება ყველაზე დაბალ დონეს (ჩამოთვლილთაგან)?

ბიზნეს პროცესის ოპერაციები

კითხვა 7
ბიზნეს პროცესის ხანგრძლივობა:

სუბიექტურია

კითხვა 8
მატერიალური რესურსები, როგორც პროცესების ძირითადი ელემენტია:

პასიური საშუალებები და საქმიანობის ობიექტები, რომლებიც გამოიყენება პროცესების განსახორციელებლად

კითხვა 9
აირჩიეთ სიიდან პროექტზე დაფუძნებული ორგანიზაციული სტრუქტურების უპირატესობები.

ხორციელდება თანამშრომლების უშუალო დაქვემდებარება პროექტის მენეჯერთან და ამით მიიღწევა ამ თანამშრომლების ძალისხმევის მიმართულების გაურკვევლობა.

კითხვა 10
აირჩიეთ სიიდან მატრიცული ორგანიზაციული სტრუქტურების უპირატესობები.

მოქნილად მორგების შესაძლებლობა ორგანიზაციული სტრუქტურაფართო სპექტრის ფარგლებში: სუსტიდან ძლიერ მატრიცამდე

კითხვა 11
რას მოიცავს ბიზნეს სისტემის მართვის მეორე ციკლი?

ოპერაციის კონტროლის ქვესისტემა
განვითარების მართვის ქვესისტემა

კითხვა 12
ბიზნეს სისტემის ზოგადი პროცესის მოდელი მოიცავს შემდეგ ელემენტებს:

გასვლა
პროცესი
შესასვლელი
არეულობა

კითხვა 13
რომელი IDEF სტანდარტი გაძლევთ საშუალებას შექმნათ აქტივობები, ნაკადები და ობიექტების მდგომარეობა?

კითხვა 14
რა უფლებამოსილებები აქვს პროექტის მენეჯერს ძლიერ მატრიცულ სტრუქტურაში?

საშუალოდან მაღალამდე

კითხვა 15
რა შეიძლება მივაკუთვნოთ საინვესტიციო და ფინანსური პროცესების ძირითად ელემენტებს?

ინვესტორები
გამსესხებლები

კითხვა 16
სიიდან აირჩიეთ საპროექტო-სამიზნე სტრუქტურების ნაკლოვანებები.

შემცირებული წარმოების უნარი ფუნქციურ სფეროებში

Control Systems Modeling.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

როგორია დომინირების რიგი SADT დიაგრამებში?
პასუხი: ყველაზე დომინანტური ფუნქციები მდებარეობს ზედა მარცხენა კუთხეში.

დახმარება 3 ტრენინგი ვისაც აქვს პლიზ

დაემატა 1 წუთის შემდეგ
ვთხოვ 3 ტრენინგს ვისაც აქვს მართვის სისტემების მოდელირება

vBulletin® v3.8.7, საავტორო უფლება 2000-2018, vBulletin Solutions, Inc.

თარგმანი, რომელიც შეგიძლიათ თქვათ:

ის-ის განვითარების მეთოდოლოგია. CMM/CMMI სიმწიფის მოდელი.

1991 წელს უნივერსიტეტის პროგრამული ინჟინერიის ინსტიტუტი

კარნეგი მელონმა (პროგრამული ინჟინერიის ინსტიტუტი, SEI) შექმნა CMM სიმწიფის მოდელი (Capability Maturity Model) პროგრამული პროდუქტების განვითარებისთვის. დროთა განმავლობაში გამოვიდა მოდელების მთელი ოჯახი:

SW-CMM - პროგრამული პროდუქტებისთვის, SE-CMM - სისტემების ინჟინერიისთვის, Acquisition CMM - შესყიდვისთვის, People CMM - ადამიანური რესურსების მართვისთვის, ICMM - პროდუქტის ინტეგრაციისთვის.

მრავალფეროვანი მოდელი საკმაოდ რთული გასაგები და დანერგილი აღმოჩნდა. ვინაიდან ისინი შეიქმნა სხვადასხვა ჯგუფებისპეციალისტების აზრით, ამ მოდელების შინაარსი ყოველთვის არ შეესაბამებოდა ერთმანეთს, ისევე როგორც

საერთაშორისო სტანდარტების მოთხოვნები. ამიტომ, 2002 წელს, SEI-მ გამოაქვეყნა ახალი CMMI მოდელი (Capability Maturity Model Integration), რომელიც აერთიანებს ადრე გამოშვებულ მოდელებს და ითვალისწინებს მოთხოვნებს.

საერთაშორისო სტანდარტები. CMMI არის მოდელების (მეთოდოლოგიების) ნაკრები სხვადასხვა ზომისა და საქმიანობის ორგანიზაციებში პროცესების გასაუმჯობესებლად. CMMI განასხვავებს გაუმჯობესების სფეროების შემდეგ ჯგუფებს: პროცესის მენეჯმენტი, პროექტის მენეჯმენტი, საინჟინრო სფეროები, მომსახურება

ტერიტორიები. ამ შემთხვევაში, ყველა სფერო მითითებულია მოთხოვნების სახით, რომლებიც განსაზღვრავს არა მათი განხორციელების, არამედ ინტერფეისის მოთხოვნებს. აქედან გამომდინარეობს ორი შედეგი.

შედეგი 1. CMMI იძლევა სხვადასხვა იმპლემენტაციის საშუალებას და არ არის პროგრამული უზრუნველყოფის განვითარების მეთოდოლოგია, როგორიცაა MSF, Scrum, RUP და ა.შ. ამ უკანასკნელის გამოყენება შესაძლებელია მის განხორციელებაში. მაგალითად, VSTS-ში არის სპეციალური პროცესის შაბლონი CMMI-სთვის, რომელსაც ეწოდება MSF for CMMI.

დასკვნა 2. CMMI გამოიყენება კომპანიების პროცესების სიმწიფის სერტიფიცირებისთვის. თავდაპირველად, 80-იანი წლების ბოლოს და 90-იანი წლების დასაწყისში, CMM (მაშინ ჯერ კიდევ არ იყო CMMI) შეიქმნა ზუსტად, როგორც სერტიფიცირების საშუალება.

ფედერალური ქვეკონტრაქტორები. და მხოლოდ მოგვიანებით, როდესაც ფართოდ გავრცელდა მსოფლიოში, დაიწყო მისი გამოყენება და შემდეგ ყურადღება გაამახვილა პროცესების გაუმჯობესებაზე. აღვნიშნავთ კიდევ ერთს მნიშვნელოვანი მახასიათებელი CMMI. იგი განკუთვნილია არა მხოლოდ პროგრამული სისტემების განვითარებისთვის. ბევრი დიდი კომპანიებიისინი აწარმოებენ არა პროგრამულ უზრუნველყოფას, არამედ მიზნობრივ პროდუქტებს, სადაც პროგრამული უზრუნველყოფა შედის როგორც განუყოფელი ნაწილი.

მაგალითად, ავიაცია, კოსმოსური ინდუსტრია. ანუ პროგრამული უზრუნველყოფის განვითარება

ხდება სხვა ტიპის საინჟინრო სამუშაოებთან ერთად. და ხშირად ხდება, რომ ერთ პროექტში ორზე მეტი სხვადასხვა ტიპის ინჟინერია ჩართულია. CMMI-ის ამოცანაა ასეთი პროექტებისა და კომპანიების მიწოდება განვითარების პროცესის ორგანიზებისთვის ერთიანი პლატფორმით.

კლასიკური CMM მოდელისგან განსხვავებით, რომელიც იყო მკაცრად იერარქიული და საშუალებას აძლევდა პროცესების მხოლოდ თანმიმდევრული გაუმჯობესება დონეების მიხედვით, CMMI მოდელს აქვს ორი განზომილება - თანმიმდევრული, მაგ.

ისევე, როგორც CMM-ში და უწყვეტი, რაც საშუალებას აძლევს ორგანიზაციაში პროცესების გარკვეულწილად გაუმჯობესდეს თვითნებურად. აქ ჩვენ გავამახვილებთ ყურადღებას თანმიმდევრული მოდელი. მას აქვს 5 დონე

პროცესის სიმწიფე (ნახ. 1).

პირველი დონე(სიმწიფის დონე 1) არის დონე, რომელშიც, განსაზღვრებით, იმყოფება ნებისმიერი კომპანია. ამ დონეზე პროგრამული უზრუნველყოფის განვითარება მეტ-ნაკლებად ქაოტურია.

მართული დონე(სიმწიფის დონე 2) - აქ უკვე ჩანს კომპანიის დონეზე დამტკიცებული პროცესების ორგანიზების პოლიტიკა და პროცედურები. მაგრამ პროცესების სრული მასშტაბები არსებობს მხოლოდ ინდივიდუალური პროექტების ფარგლებში.

გარკვეული დონე(სიმწიფის დონე 3) - აქ სტანდარტული პროცესი ჩნდება მთლიანი კომპანიის დონეზე.

რა არის შესაძლებლობების სიმწიფის მოდელი (CMM)? რა არის CMM დონეები?

ეს არის პროცესის აქტივების დიდი და მუდმივად მზარდი ნაკრები: დოკუმენტის შაბლონები,

სასიცოცხლო ციკლის მოდელები, პროგრამული ინსტრუმენტები, პრაქტიკა და ა.შ. ნებისმიერი კონკრეტული პროცესი მიიღება ამ სტანდარტის ამოჭრით.

რაოდენობრივი დონე(სიმწიფის დონე 4) გულისხმობს კომპანიაში გაზომვების სისტემის გაჩენას, რომელიც ხდება სტანდარტული პროცესის საფუძველზე და იძლევა განვითარების რაოდენობრივ მართვას.

დონის ოპტიმიზაცია(სიმწიფის დონე 5) გულისხმობს განვითარების პროცესების მუდმივ გაუმჯობესებას, როგორც ინკრემენტულ, ასევე ინკრემენტულ და რევოლუციურ. ამავდროულად, ეს ცვლილებები არა იძულებითი, არამედ პროაქტიული პრობლემები და სირთულეებია. პროცესი თავისთავად იხვეწება და მუდმივად, შესაბამისი მექანიზმები დანერგილია.

ბევრმა იცის აბრევიატურა CMMI, ბევრმა იცის, რომ ეს არის მოდელი, ე.ი. რეკომენდაციების ნაკრები, თუ როგორ უნდა გავაუმჯობესოთ პროცესები, რომლებიც დაკავშირებულია, მაგალითად, პროგრამული უზრუნველყოფის განვითარებასთან. მაგრამ ცოტამ თუ იცის, რომ არსებობს რამდენიმე CMMI მოდელი. მათგან ყველაზე ცნობილია CMMI განვითარებისთვის (CMMI-DEV), რომელიც მართლაც მრავალი თვალსაზრისით არის დაკავშირებული დეველოპერული კომპანიების საქმიანობასთან (ანუ ის კომპანიები და ორგანიზაციები, რომლებიც ავითარებენ და აწვდიან გარკვეულ პროგრამულ პროდუქტს ან სხვა რთულ პროგრამულ უზრუნველყოფას და აპარატურას. გამოსავალი).

რა შეიძლება ითქვას მათზე, ვინც აწვდის არა პროდუქტს, არამედ მომსახურებას (მაგალითად, პროდუქტის მხარდაჭერა განვითარების უმნიშვნელო წილით მთლიან შრომის ხარჯებში ან საერთოდ არ არის შრომის ხარჯები)? მათთვის ასევე არსებობს რეკომენდაციების ნაკრები - CMMI სერვისების მოდელი (CMMI-SVC). მაგალითად, IT დეპარტამენტებისთვის, ამ მოდელს (უფრო ზუსტად, მის რეკომენდაციებს) შეუძლია დაეხმაროს იმის გაგებაში, თუ რა უნდა გაკეთდეს ისე, რომ, მაგალითად, იგივე ITIL რეკომენდაციები გახდეს ნორმალური პროცესი და არა ერთგვარი „წმინდა პრაქტიკა“.

შესაძლებლობების სიმწიფის მოდელი (CMM)

საინტერესოა, რომ ამ მოდელის რეკომენდაციები საკმაოდ უნივერსალურია და არ "იხურება" მხოლოდ Საინფორმაციო ტექნოლოგია. ამ მოდელის პრაქტიკის პილოტური დანერგვა მოხდა... შეერთებული შტატების ერთ-ერთ საავადმყოფოში (ბოლოს და ბოლოს, სამედიცინო დახმარებაც მომსახურებაა).

თუმცა რომელიმე ჩამოთვლილი მოდელის სწავლა უკეთესია. და თუ რამდენიმე ასეული ადამიანია გაწვრთნილი CMMI-DEV მოდელში მთელი დსთ-სთვის (დაახლოებით 250-300 ადამიანი), მაშინ CMMI-SVC მოდელში მხოლოდ 6 ადამიანია გაწვრთნილი დსთ-ში. ჩვენ ვსაუბრობთ მომზადებულებზე და არა ინსტრუქტორებზე. სწორედ ეს იყო მთავარი პრობლემა 2011 წლის დეკემბრამდე: CMMI-DEV-სთვის მთელ მსოფლიოში არსებობდა მხოლოდ ერთი რუსულენოვანი ინსტრუქტორი, რომელიც სერტიფიცირებული იყო SEI-ს (CMMI მოდელის შემქმნელის) მიერ, ხოლო სხვა მოდელებისთვის საერთოდ არ იყო! ახლა ასეთი ინსტრუქტორიც გამოჩნდა CMMI-SVC მოდელის მიხედვით (აქედან პირველი 6 გაწვრთნილი). ეს ინსტრუქტორი არის ამ პუბლიკაციის ავტორი, რომელსაც შეუძლია უპასუხოს ნებისმიერ შეკითხვას აღნიშნული მოდელებისა და ფორმალური ტრენინგის შესახებ. იკითხე!

ეს მასალა არის Club.CNews საზოგადოების წევრის პირადი ჩანაწერი.
CNews-ის რედაქტორები არ არიან პასუხისმგებელი მის შინაარსზე.

ჩვენ განვიხილავთ ხარისხის უზრუნველყოფის მოდელების ევოლუციას „პროცესის სიმწიფის მოდელის“ ან „სიმძლავრის გაუმჯობესების მოდელის“ საფუძველზე. CMM (Capability Maturity Model).მიუხედავად იმისა, რომ მოდელი SMMმიზნად ისახავს პროგრამული უზრუნველყოფის ხარისხის უზრუნველყოფას, მისი მეთოდოლოგიური ასპექტები გამოიყენება ნებისმიერი პროდუქტის (საქონელი, სამუშაო, მომსახურება) ხარისხის უზრუნველსაყოფად მოდელებზე.

მოდელში მთავარი SMMარის ორგანიზაციული სიმწიფის კონცეფცია.

გაუაზრებელიითვლება ორგანიზაციად, რომელშიც პროგრამული უზრუნველყოფის დამუშავების პროცესი დამოკიდებულია მხოლოდ კონკრეტულ შემსრულებლებზე და მენეჯერებზე და გადაწყვეტილებები ხშირად მიიღება „დაფრენაზე“. ამ შემთხვევაში დიდია ბიუჯეტის გადამეტების ან პროექტის წარუმატებლობის ალბათობა და ამიტომ მენეჯერები იძულებულნი არიან მხოლოდ დაუყოვნებელი პრობლემების მოგვარებით.

მოწიფულიითვლება, რომ ორგანიზაცია აკმაყოფილებს შემდეგ პირობებს:

• – არის კარგად განსაზღვრული პროცედურები პროგრამული პროდუქტების შექმნისა და პროექტების მართვისთვის, რომლებიც დახვეწილია და გაუმჯობესებულია საპილოტე პროექტები„ღირებულება – მოგების“ კომპონენტების ანალიზით;
• – სამუშაოს შესრულების დროისა და ღირებულების შეფასებები ეფუძნება დაგროვილ გამოცდილებას და, შესაბამისად, საკმაოდ ზუსტია;
• – კომპანიას აქვს სტანდარტები პროგრამული უზრუნველყოფის შემუშავების, ტესტირებისა და დანერგვის პროცესებისთვის, საბოლოო პროგრამის კოდის დიზაინის წესები, კომპონენტები, ინტერფეისები და ა.შ. ეს ყველაფერი წარმოადგენს ინფრასტრუქტურას და კორპორატიული კულტურარომელიც მხარს უჭერს პროგრამული უზრუნველყოფის შემუშავების პროცესს.

ასე რომ, სტანდარტი SMMარის ხარისხის უზრუნველყოფის მოდელი, რომელიც შედგება ორგანიზაციის სიმწიფის შეფასების კრიტერიუმებისგან და არსებული პროცესების გაუმჯობესების რეცეპტებისგან. მოდელში SMMგანსაზღვრულია ორგანიზაციების სიმწიფის ხუთი დონე, რომელთა მახასიათებლები წარმოდგენილია ნახ. 5.3.

ბრინჯი. 5.3. მოდელის სიმწიფის ხუთი დონეSMM

პირველი დონე (საწყისი დონე)არის საწარმოს განვითარების საფუძველი შემდეგ დონეზე. ითვლება, რომ ორგანიზაციის საწყისი დონის საწარმოში არ არსებობს სტაბილური პირობები მაღალი ხარისხის პროგრამული უზრუნველყოფის შესაქმნელად. შესაბამისად, ნებისმიერი პროექტის შედეგი მთლიანად დამოკიდებულია მენეჯერის პიროვნულ თვისებებზე და პროგრამისტების გამოცდილებაზე. ეს ნიშნავს, რომ წარმატება ერთ პროექტში შეიძლება განმეორდეს მხოლოდ იმ შემთხვევაში, თუ იგივე მენეჯერები და პროგრამისტები დაინიშნენ შემდეგ პროექტზე. თუმცა, თუ მენეჯერები ან პროგრამისტები, რომლებმაც მიიღეს გამოცდილება პროექტებში, დატოვებენ საწარმოს, მაშინ წარმოებული პროგრამული უზრუნველყოფის ხარისხი მკვეთრად ეცემა მათი წასვლის შემდეგ.

უნდა აღინიშნოს, რომ საწყის დონეზე, სტრესულ სიტუაციებში, დიდი დამოკიდებულებაა ადამიანური ფაქტორიგანვითარების პროცესი მცირდება კოდის დაწერაზე და მის მინიმალურ ტესტირებაზე.

მეორეს მიღწევა განმეორებადი დონე (განმეორებადი დონე) განისაზღვრება საწარმოში პროექტების მართვის ტექნოლოგიის დანერგვით. საწარმოში დაგეგმვა და პროექტების მართვა ეფუძნება დაგროვილ გამოცდილებას, არსებობს და გამოიყენება შემუშავებული პროგრამული უზრუნველყოფის სტანდარტები, რომელთა შესაბამისობას აკონტროლებს ხარისხის უზრუნველყოფის სპეციალური ჯგუფი. ითვლება, რომ მეორე დონეს შეუძლია უზრუნველყოს შემდგომი გაუმჯობესების შესაძლებლობა (მესამე დონეზე გადასვლა), და არ გამორიცხავს კრიტიკულ პირობებში პროგრამული უზრუნველყოფის განვითარების პროცესის ხარისხის რეგრესიული დაბრუნების შესაძლებლობას საწყის დონეზე.

მესამე, გარკვეული დონე (განსაზღვრულია მარცხნივ)ხასიათდება იმით, რომ პროგრამული უზრუნველყოფის შექმნისა და შენარჩუნების სტანდარტული პროცესი სრულად არის დოკუმენტირებული, პროგრამული უზრუნველყოფის შემუშავებიდან პროექტის მენეჯმენტამდე. ამ დონის დანერგვის ჰიპოთეზა არის ის, რომ სტანდარტიზაციის პროცესში საწარმო გადადის ყველაზე ეფექტურ პრაქტიკასა და ტექნოლოგიებზე. ორგანიზაციაში პროგრამული უზრუნველყოფის დამუშავებისა და პროექტების მართვის სტანდარტების ფუნქციონირების შესაქმნელად და შესანარჩუნებლად, უნდა შეიქმნას სპეციალური ჯგუფი. მესამე დონის მიღწევის წინაპირობაა საწარმოში თანამშრომლების უწყვეტი პროფესიული განვითარებისა და მომზადების პროგრამის არსებობა. ითვლება, რომ ამ დონიდან დაწყებული, ორგანიზაცია წყვეტს კონკრეტული დეველოპერების თვისებებზე დამოკიდებულებას და სტრესულ სიტუაციებში არ მიდის უფრო დაბალ დონეზე.

მეოთხეზე, მართული დონე (მართული დონე)საწარმო ადგენს ხარისხის რაოდენობრივ ინდიკატორებს - როგორც პროგრამული პროდუქტებისთვის, ასევე ზოგადად მათი შექმნის პროცესებისთვის. ამრიგად, პროექტის უკეთესი მენეჯმენტი მიიღწევა სხვადასხვა პროექტის ინდიკატორების გადახრების შემცირებით. ამავდროულად, განცალკევებულია განხორციელებული პროგრამული უზრუნველყოფის განვითარების პროცესების მნიშვნელოვანი (სიგნალი) ვარიაციები და პროცესის შემთხვევითი (ხმაური) ვარიაციები.

მეხუთე (უმაღლესი), ოპტიმიზაციის დონე (ოპტიმიზაციის დონე)ხასიათდება იმით, რომ გაუმჯობესების ღონისძიებები გამოიყენება არა მხოლოდ არსებულ პროცესებზე, არამედ ახალი ტექნოლოგიების დანერგვის ეფექტურობის შესაფასებლად. ამ დონეზე საწარმოს მთავარი ამოცანაა არსებული პროცესების უწყვეტი გაუმჯობესება. ამავდროულად, პროცესის გაუმჯობესება ხელს შეუწყობს თავიდან აცილებას შესაძლო შეცდომებიდა დეფექტები. ამავდროულად, უნდა ჩატარდეს მუშაობა პროგრამული უზრუნველყოფის შემუშავების ხარჯების შესამცირებლად.

ორგანიზაციული პროცესების მართვის 5 ევოლუციური ეტაპი. შესაძლებლობების სიმწიფის მოდელის ახსნა. CMM

CM-CEI შესაძლებლობების სიმწიფის მოდელი არის ორგანიზაციული მოდელი, რომელიც აღწერს 5 ევოლუციურ ეტაპს (დონეებს), რომლებშიც იმართება ორგანიზაციაში მიმდინარე პროცესები.

თავდაპირველად შექმნილი პროგრამული უზრუნველყოფის განვითარებისთვის, შესაძლებლობების სიმწიფის მოდელის მიზანია ის, რომ ორგანიზაციას უნდა შეეძლოს მიიღოს და მხარი დაუჭიროს მის პროგრამულ აპლიკაციებს. მოდელი ასევე გვთავაზობს კონკრეტულ ნაბიჯებსა და ინიციატივებს, რათა დაეხმაროს ორგანიზაციას გაიზარდოს შემდეგ ეტაპზე.

შესაძლებლობების სიმწიფის მოდელის 5 ეტაპი

საწყისი (პროცესები არის ad hoc, ქაოტური, ან, ფაქტობრივად, რამდენიმე მათგანია განსაზღვრული) განმეორებადი (ძირითადი პროცესები ჩამოყალიბებულია და არსებობს დისციპლინა ამ პროცესების შესასრულებლად) განსაზღვრული (ყველა პროცესი არის განსაზღვრული, დოკუმენტირებული) , ერთიანი და ინტეგრირებული) მართვადი ( პროცესები იზომება პროცესებისა და მათი ხარისხის შესახებ დეტალური მონაცემების აგრეგაციით) ოპტიმიზაცია (პროცესის უწყვეტი განვითარება რაოდენობრივი უკუკავშირის და ახალი იდეებისა და ტექნოლოგიების ტესტირების გზით)

პროგრამული უზრუნველყოფის განვითარების მოდელი

CMM აღწერს პრინციპებსა და პრაქტიკებს, რომლებიც ემყარება პროგრამული უზრუნველყოფის პროცესის სიმწიფის კონცეფციას. ისინი შექმნილია იმისთვის, რომ დაეხმარონ პროგრამული უზრუნველყოფის შემუშავებას და გაყიდვების ფირმებს გააუმჯობესონ თავიანთი პროგრამული პროცესების დახვეწილობა ევოლუციურად. დროებითი, ქაოტური პროცესებიდან დაწყებული, მომწიფებულ, დისციპლინირებულ პროგრამულ პროცესებზე გადასვლა. აქცენტი კეთდება ძირითადი პროცესის სფეროების და სამაგალითო პრაქტიკის იდენტიფიცირებაზე, რომლებიც შეიძლება წარმოადგენდეს დისციპლინირებულ პროგრამულ პროცესებს. CMM სიმწიფის კონცეფცია ქმნის კონტექსტს, რომელშიც:

პრაქტიკა შეიძლება განმეორდეს. თუ არ გაიმეორეთ რაიმე ოპერაცია, მაშინ არ უნდა გააუმჯობესოთ იგი. არსებობს წესები, პროცედურები და პრაქტიკა, რომლებიც აიძულებს ორგანიზაციას განახორციელოს და თანმიმდევრულად განახორციელოს. საწარმოო სამუშაოს ორგანიზების საუკეთესო პრაქტიკა შეიძლება სწრაფად იყოს გაზიარებული ჯგუფებს შორის. პრაქტიკა განსაზღვრულია პროექტებს შორის გაცვლის დასაშვებად, რაც უზრუნველყოფს ორგანიზაციის გარკვეულ სტანდარტიზაციას. ამ მეთოდების შესრულებისას გადახრები მინიმუმამდეა დაყვანილი. ამოცანების რაოდენობრივი მიზნები დგინდება; და გაზომვები დადგენილი, წარმოებული და შენარჩუნებულია შეფასების საფუძვლის შესაქმნელად. პრაქტიკა მუდმივად იხვეწება შესაძლებლობების გასაუმჯობესებლად (ოპტიმიზაცია).

შესაძლებლობების სიმწიფის მოდელი სასარგებლოა არა მხოლოდ პროგრამული უზრუნველყოფის შემუშავებისთვის, არამედ ზოგადად ორგანიზაციების ევოლუციური დონის აღსაწერად და მენეჯმენტის დონის აღსაწერად, რომელიც ორგანიზაციამ განახორციელა ან უნდა მიაღწიოს.

მახასიათებლების განვითარების მოდელის სტრუქტურა

სიმწიფის დონე არის ფენიანი კონცეფცია, რომელიც უზრუნველყოფს დისციპლინის თანმიმდევრულობას, რომელიც საჭიროა მუდმივი გაუმჯობესების მისაღწევად. აქ მნიშვნელოვანია აღინიშნოს, რომ ორგანიზაციას უვითარდება ახალი პრაქტიკის, ტექნოლოგიის ან ხელსაწყოს შედეგების შეფასების უნარი. აქედან გამომდინარე, საქმე არ არის ამ ინოვაციების მიღებაზე, არამედ იმაზე, თუ როგორ მოქმედებს ეს ინოვაციური ძალისხმევა არსებულ პრაქტიკაზე. ის მხარს უჭერს პროექტებს, ჯგუფებს და ორგანიზაციებს, რაც მათ აძლევს საფუძველს ინფორმირებული არჩევანის გაკეთების მიზნით. ძირითადი პროცესის სფეროები - ძირითადი პროცესის არეალი (KPA) განსაზღვრავს დაკავშირებული აქტივობების ჯგუფს, რომლებიც ერთობლივად განხორციელებისას მიაღწევენ რიგ მნიშვნელოვან მიზნებს. მიზნები - ძირითადი პროცესის სფეროს მიზნები აღწერს დებულებებს, რომლებიც უნდა არსებობდეს ამ ძირითადი პროცესის სფეროსთვის. რეგულაციები უნდა განხორციელდეს ეფექტურად და უსაფრთხოდ. რამდენად მიიღწევა მიზნები, მიუთითებს იმაზე, თუ რა შესაძლებლობები აქვს ორგანიზაციას ჩამოყალიბებული სრულყოფილების ამ დონეზე. მიზნები ასახავს თითოეული ძირითადი პროცესის სფეროს ფარგლებს, საზღვრებს და მიზანს. ზოგადი მახასიათებლები - ზოგადი მახასიათებლები მოიცავს პრაქტიკას, რომელიც ახორციელებს და ახდენს პროცესის ძირითადი სფეროების ინსტიტუციონალიზაციას. ეს 5 ტიპი ზოგადი მახასიათებლებიმოიცავს: შესრულების ვალდებულებას, შესრულების უნარს, განსახორციელებელ ინიციატივებს, გაზომვას და ანალიზს და განხორციელების კონტროლს. ძირითადი პრაქტიკა - ძირითადი პრაქტიკა აღწერს ინფრასტრუქტურულ ელემენტებს და პრაქტიკებს, რომლებიც ყველაზე ეფექტურად უწყობს ხელს ძირითადი პროცესის სფეროების განხორციელებასა და ინსტიტუციონალიზაციას.

პროცესის განსაზღვრის კრიტერიუმები

პროცესის განსაზღვრის კრიტერიუმები არის პროცესის ელემენტების ერთობლიობა, რომელიც უნდა იყოს შეტანილი პროგრამული პროცესის აღწერაში, რათა ადამიანებმა გამოიყენონ ისინი პრაქტიკაში. კრიტერიუმების დასადგენად, თქვენ უნდა დაისვათ კითხვა - „რა ინფორმაციაზეა პროგრამული პროცესისაჭიროა დოკუმენტაციისთვის?