რა შედის პროგრამული უზრუნველყოფის სასიცოცხლო ციკლში. პროგრამული უზრუნველყოფის სიცოცხლის ციკლი

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

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

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

კასკადის მოდელი

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

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

სასიცოცხლო ციკლი ტრადიციულად იყოფა შემდეგ ძირითადებადეტაპები:

1. მოთხოვნების ანალიზი,
2. დიზაინი,
3. კოდირება (პროგრამირება),
4. ტესტირება და გამართვა,
5. ექსპლუატაცია და მოვლა.

მოდელის უპირატესობები:

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

მოდელის ნაკლოვანებები:

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

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

კასკადის მოდელის ფარგლები

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

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

დამატებითი მოდელი

(დადგმული მოდელი შუალედური კონტროლით)

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

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

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

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

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

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

უპირატესობები:

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

მოდელის ნაკლოვანებები:

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

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

სპირალური მოდელი

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

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

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

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

მოდელის უპირატესობები:

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

მოდელის ნაკლოვანებები:

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

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

სპირალური მოდელის ფარგლები

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

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

ელექტრო ინჟინერიაში). ეს სტანდარტი განსაზღვრავს სასიცოცხლო ციკლის სტრუქტურას, რომელიც შეიცავს პროცესებს, აქტივობებსა და ამოცანებს, რომლებიც უნდა შესრულდეს PS-ის შექმნისას.

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

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

ავტომატური სისტემების (AS) შექმნის პროცესები, რომლებიც ასევე მოიცავს პროგრამულ უზრუნველყოფას, რეგულირდება სტანდარტებით GOST 34.601-90 "ინფორმაციული ტექნოლოგია. სტანდარტების ნაკრები ავტომატური სისტემებისთვის. შექმნის ეტაპები", GOST 34.602-89 "ინფორმაციული ტექნოლოგია. ა. სტანდარტების ნაკრები ავტომატური სისტემებისთვის. ტექნიკური დავალებაავტომატური სისტემის შესაქმნელად" და GOST 34.603-92 "ინფორმაციული ტექნოლოგია. ავტომატური სისტემების ტესტების სახეები". თუმცა, ამ სტანდარტების ბევრი დებულება მოძველებულია, ზოგი კი საკმარისად არ არის ასახული იმისთვის, რომ გამოიყენონ სერიოზული პროექტები PS-ის შესაქმნელად. ამიტომ მიზანშეწონილია თანამედროვე საერთაშორისო სტანდარტების გამოყენება შიდა განვითარებაში.

ISO/IEC 12207 სტანდარტის შესაბამისად, პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის ყველა პროცესი იყოფა სამ ჯგუფად (ნახ. 5.1).

ბრინჯი. 5.1.

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

5.2. PS-ის სასიცოცხლო ციკლის ძირითადი პროცესები

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

1. შეძენის დაწყება;
2. სააპლიკაციო წინადადებების მომზადება;
3. ხელშეკრულების მომზადება და კორექტირება;
4. მიმწოდებლის საქმიანობის ზედამხედველობა;
5. სამუშაოს მიღება და დასრულება.

შეძენის დაწყება მოიცავს შემდეგ ამოცანებს:

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

წინადადებები უნდა შეიცავდეს:

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

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

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

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

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

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

1. მიწოდების დაწყება;
2. წინადადებებზე პასუხის მომზადება;
3. ხელშეკრულების მომზადება;
4. საკონტრაქტო სამუშაოების დაგეგმვა;
5. სახელშეკრულებო სამუშაოების შესრულება და კონტროლი და მათი შეფასება;
6. სამუშაოების მიწოდება და დასრულება.

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

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

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

განვითარების პროცესი მოიცავს შემდეგ ნაბიჯებს:

1. მოსამზადებელი სამუშაოები;
2. სისტემის მოთხოვნების ანალიზი;
3. სისტემის არქიტექტურის დიზაინი;
4. პროგრამული უზრუნველყოფის მოთხოვნების ანალიზი;
5. პროგრამული არქიტექტურის დიზაინი;
6. დეტალური პროგრამული დიზაინი;
7. პროგრამული კოდირება და ტესტირება;
8. პროგრამული უზრუნველყოფის ინტეგრაცია;
9. პროგრამული უზრუნველყოფის საკვალიფიკაციო ტესტირება;
10. სისტემის ინტეგრაცია;
11. სისტემის საკვალიფიკაციო ტესტირება;
12. პროგრამული უზრუნველყოფის ინსტალაცია;
13. პროგრამული უზრუნველყოფის მიღება.

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

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

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

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

1. ფუნქციონალურობა, მათ შორის შესრულების მახასიათებლები და კომპონენტის ოპერაციული გარემო;
2. გარე ინტერფეისები;
3. საიმედოობისა და უსაფრთხოების სპეციფიკაციები;
4. ერგონომიული მოთხოვნები;
5. გამოყენებული მონაცემების მოთხოვნები;
6. ინსტალაციისა და მიღების მოთხოვნები;
7. მოთხოვნები მომხმარებლის დოკუმენტაციისთვის;
8. მოთხოვნები ექსპლუატაციისა და მოვლისთვის.

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

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

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

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

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

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

1. პროგრამული უზრუნველყოფისა და მონაცემთა ბაზის თითოეული კომპონენტის კოდირება და დოკუმენტირება, აგრეთვე ტესტირების პროცედურებისა და მონაცემების ნაკრების მომზადება მათი შესამოწმებლად;
2. პროგრამული უზრუნველყოფის და მონაცემთა ბაზის თითოეული კომპონენტის ტესტირება მათ მოთხოვნებთან შესაბამისობაში, რასაც მოჰყვება ტესტის შედეგების დოკუმენტაცია;
3. დოკუმენტაციის განახლება (საჭიროების შემთხვევაში);
4. პროგრამული უზრუნველყოფის ინტეგრაციის გეგმის განახლება.

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

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

ექსპლუატაციის პროცესი მოიცავს სისტემაში მომუშავე ოპერატორის ორგანიზაციის საქმიანობასა და ამოცანებს. ოპერაციის პროცესი მოიცავს შემდეგ ნაბიჯებს.

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

   1. მოქმედებების დაგეგმვა და ექსპლუატაციის დროს შესრულებული სამუშაოები და საოპერაციო სტანდარტების დადგენა;
   2. ოპერაციის დროს წარმოქმნილი პრობლემების ლოკალიზაციისა და მოგვარების პროცედურების განსაზღვრა.
2. ოპერაციული ტესტირება ტარდება პროგრამული პროდუქტის ყოველი შემდეგი გამოცემისთვის, რის შემდეგაც ეს გამოცემა გადადის ექსპლუატაციაში.
3. სისტემის ფაქტობრივი მოქმედება, რომელიც შესრულებულია ამისთვის განკუთვნილ გარემოში მომხმარებლის დოკუმენტაციის შესაბამისად.
4. პრობლემებისა და პროგრამული უზრუნველყოფის მოდიფიკაციის მოთხოვნების ანალიზი (შეტყობინებების ანალიზი წარმოშობილი პრობლემის ან მოთხოვნის მოთხოვნის შესახებ, მასშტაბის შეფასება, მოდიფიკაციის ღირებულება, შედეგად მიღებული ეფექტი, მოდიფიკაციის მიზანშეწონილობის შეფასება);
5. პროგრამული უზრუნველყოფის მოდიფიკაცია (პროგრამული პროდუქტის კომპონენტებსა და დოკუმენტაციაში ცვლილებების შეტანა დამუშავების პროცესის წესების შესაბამისად);
6. შემოწმება და მიღება (მოდიფიცირებული სისტემის მთლიანობის თვალსაზრისით);
7. პროგრამული უზრუნველყოფის სხვა გარემოში გადატანა (პროგრამებისა და მონაცემების კონვერტაცია, პროგრამული უზრუნველყოფის პარალელური მუშაობა ძველ და ახალ გარემოში გარკვეული პერიოდის განმავლობაში);
8. პროგრამული უზრუნველყოფის გაუქმება მომხმარებლის გადაწყვეტილებით მოქმედი ორგანიზაციის, ტექნიკური მომსახურებისა და მომხმარებლების მონაწილეობით. ამავდროულად, პროგრამული პროდუქტები და დოკუმენტაცია ექვემდებარება დაარქივებას ხელშეკრულების შესაბამისად.

Ანოტაცია.

შესავალი.

1. პროგრამული უზრუნველყოფის სიცოცხლის ციკლი

შესავალი.

რაილი პროგრამირების პროცესის საფეხურები

შესავალი.

1.1.1. პრობლემის ფორმულირება.

1.1.2. გადაწყვეტის დიზაინი.

1.1.3. ალგორითმის კოდირება.

1.1.4. პროგრამის მხარდაჭერა.

1.1.5. პროგრამული დოკუმენტაცია.

1.1 პუნქტის დასკვნა

1.2. ZhTsPO-ს განმარტება ლემანის მიხედვით.

შესავალი.

1.2.1 სისტემის განმარტება.

1.2.2. განხორციელება.

1.2.3. სერვისი.

1.2 პუნქტის დასკვნა.

1.3. სიცოცხლის ციკლის პროგრამის ფაზები და სამუშაოები ბოემის მიხედვით

1.3.1. კასკადის მოდელი.

1.3.2. კასკადის მოდელის ეკონომიკური დასაბუთება.

1.3.3. კასკადის მოდელის გაუმჯობესება.

1.3.4. სასიცოცხლო ციკლის ფაზების განსაზღვრა.

1.3.5. ძირითადი სამუშაო პროექტზე.

ლიტერატურა.

შესავალი

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

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

1 პროგრამული უზრუნველყოფის სასიცოცხლო ციკლი

შესავალი

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

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

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

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

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

1.1 რაილის პროგრამირების პროცესის საფეხურები

შესავალი

პროგრამირების პროცესი მოიცავს ოთხ საფეხურს (ნახ. 1):

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

უკვე დასმული პრობლემის გადაწყვეტის შემუშავება (ზოგადად, ასეთი გადაწყვეტა ნაკლებად ფორმალურია, ვიდრე საბოლოო პროგრამა);

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

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

ბრინჯი. 1.პროგრამირების ოთხი ნაბიჯი.

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

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

1.1.1 პრობლემის განცხადება

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

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

კარგი პრობლემის განცხადების მახასიათებლები:

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

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

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

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

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

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

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

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

დავალების დასახელება (სქემატური განმარტება);

ზოგადი აღწერა (დავალების მოკლე განცხადება);

შეცდომები (არაჩვეულებრივი შეყვანის ვარიანტები ცალსახად არის ჩამოთვლილი, რათა მომხმარებლებს და პროგრამისტებს აჩვენონ მოქმედებები, რომლებსაც მანქანა განახორციელებს ასეთ სიტუაციებში);

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

მაგალითი. პრობლემის განცხადება სტანდარტული ფორმით.

TITLE

დაალაგეთ სამი მთელი რიცხვი.

აღწერა

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

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

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

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

2) პირველი სამის გარდა შეყვანის ხაზები იგნორირებულია.

3) თუ პირველი სამი ხაზიდან რომელიმე შეიცავს ერთზე მეტ რიცხვს, მაშინ პროგრამა გადის და გამოსცემს შეტყობინებას.

Ანოტაცია.

შესავალი.

1. პროგრამული უზრუნველყოფის სიცოცხლის ციკლი

შესავალი.

რაილის პროგრამირების პროცესის საფეხურები

შესავალი.

1.1.1. პრობლემის ფორმულირება.

1.1.2. გადაწყვეტის დიზაინი.

1.1.3. ალგორითმის კოდირება.

1.1.4. პროგრამის მხარდაჭერა.

1.1.5. პროგრამული დოკუმენტაცია.

1.1 პუნქტის დასკვნა

1.2. ZhTsPO-ს განმარტება ლემანის მიხედვით.

შესავალი.

1.2.1 სისტემის განმარტება.

1.2.2. განხორციელება.

1.2.3. სერვისი.

1.2 პუნქტის დასკვნა.

1.3. სიცოცხლის ციკლის პროგრამის ფაზები და სამუშაოები ბოემის მიხედვით

1.3.1. კასკადის მოდელი.

1.3.2. კასკადის მოდელის ეკონომიკური დასაბუთება.

1.3.3. კასკადის მოდელის გაუმჯობესება.

1.3.4. სასიცოცხლო ციკლის ფაზების განსაზღვრა.

1.3.5. ძირითადი სამუშაო პროექტზე.

ლიტერატურა.

შესავალი

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

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

1 პროგრამული უზრუნველყოფის სასიცოცხლო ციკლი

შესავალი

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

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

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

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

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

1.1 რაილის პროგრამირების პროცესის საფეხურები

პროგრამირების პროცესი მოიცავს ოთხ საფეხურს (ნახ. 1):

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

უკვე დასმული პრობლემის გადაწყვეტის შემუშავება (ზოგადად, ასეთი გადაწყვეტა ნაკლებად ფორმალურია, ვიდრე საბოლოო პროგრამა);

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

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

ბრინჯი. 1.პროგრამირების ოთხი ნაბიჯი.

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

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

1.1.1 პრობლემის განცხადება

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

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

კარგი პრობლემის განცხადების მახასიათებლები:

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

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

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

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

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

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

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

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

დავალების დასახელება (სქემატური განმარტება);

ზოგადი აღწერა (დავალების მოკლე განცხადება);

შეცდომები (არაჩვეულებრივი შეყვანის ვარიანტები ცალსახად არის ჩამოთვლილი, რათა მომხმარებლებს და პროგრამისტებს აჩვენონ მოქმედებები, რომლებსაც მანქანა განახორციელებს ასეთ სიტუაციებში);

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

მაგალითი. პრობლემის განცხადება სტანდარტული ფორმით.

TITLE

დაალაგეთ სამი მთელი რიცხვი.

აღწერა

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

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

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

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

2012 წლის 1 მარტს რუსეთის ფედერაციის ტექნიკური რეგულირებისა და მეტროლოგიის ფედერალურმა სააგენტომ მიიღო GOST R ISO/IEC 12207-2010 სტანდარტი „ინფორმაციული ტექნოლოგია. სისტემური და პროგრამული ინჟინერია. პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის პროცესები“, იდენტურია საერთაშორისო სტანდარტის ISO/IEC 12207:2008 „სისტემისა და პროგრამული უზრუნველყოფის ინჟინერია - პროგრამული უზრუნველყოფის სიცოცხლის ციკლის პროცესები“.

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

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

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

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

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

1. შეძენის დაწყება
2. წინადადებების მომზადება
3. ხელშეკრულების მომზადება და კორექტირება
4. მიმწოდებლის ზედამხედველობა
5. სამუშაოების მიღება და დასრულება

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

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

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

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

GOST R ISO/IEC 12207-2010 სტანდარტი არ გვთავაზობს სიცოცხლის ციკლის კონკრეტულ მოდელს. მისი დებულებები საერთოა ნებისმიერი სასიცოცხლო ციკლის მოდელისთვის, IP-ის შექმნის მეთოდებისა და ტექნოლოგიებისთვის. იგი აღწერს სასიცოცხლო ციკლის პროცესების სტრუქტურას ისე, თუ როგორ უნდა განხორციელდეს ან შეასრულოს ამ პროცესებში შემავალი აქტივობები და ამოცანები.

პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის მოდელი მოიცავს:

1. ეტაპები;
2. მუშაობის შედეგები თითოეულ ეტაპზე;
3. ძირითადი მოვლენები - სამუშაოს დასრულების და გადაწყვეტილების მიღების პუნქტები.