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

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

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

UML არის გრაფიკული ენა სხვადასხვა სისტემების (კერძოდ, პროგრამების) ვიზუალიზაციის, პარამეტრების აღწერისთვის, დიზაინისა და დოკუმენტაციისთვის. დიაგრამები იქმნება სპეციალური CASE ინსტრუმენტების გამოყენებით, როგორიცაა Rational Rose (http://www-01.ibm.com/software/rational/) და Enterprise Architect (http://www.sparxsystems.com.au/). UML ტექნოლოგიაზე დაყრდნობით, ერთიანი ინფორმაციის მოდელი. ზემოთ მოყვანილ CASE ინსტრუმენტებს შეუძლიათ კოდის გენერირება სხვადასხვა ობიექტზე ორიენტირებულ ენაზე და ასევე აქვთ ძალიან სასარგებლო თვისებასაპირისპირო ინჟინერია. (უკუ ინჟინერია საშუალებას გაძლევთ შექმნათ გრაფიკული მოდელი არსებული პროგრამის კოდიდან და მასზე კომენტარებიდან.)

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

გამოიყენეთ საქმის დიაგრამა

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

კლასის დიაგრამა (კლასის დიაგრამა)

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

მდგომარეობის დიაგრამა (statechart დიაგრამა)

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

თანმიმდევრობის დიაგრამა

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

თანამშრომლობის დიაგრამა

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

კომპონენტის დიაგრამა

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

განლაგების დიაგრამა

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

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

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

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

1. "ჩანჩქერის მოდელი" (კასკადური მოდელი ან "ჩანჩქერი")

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

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

როდის გამოვიყენოთ ჩანჩქერის მეთოდოლოგია?

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

2. "V-Model"

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

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

როდის გამოვიყენოთ V- მოდელი?

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

3. „ინკრემენტალური მოდელი“ (ნამატიანი მოდელი)

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

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

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

როდის გამოვიყენოთ დამატებითი მოდელი?

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

4. "RAD მოდელი" (აპლიკაციის განვითარების სწრაფი მოდელი ან სწრაფი აპლიკაციის განვითარება)

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

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

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

როდის გამოიყენება RAD მოდელი?

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

5. "Agile Model" (სწრაფი განვითარების მეთოდოლოგია)

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

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

• ანგარიში ბოლო Scrum-ის შემდეგ გაწეული მუშაობის შესახებ;
• დავალებების სია, რომელიც თანამშრომელმა უნდა შეასრულოს მომდევნო შეხვედრამდე;
• სირთულეები, რომლებიც წარმოიქმნება მუშაობის პროცესში.

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

როდის გამოვიყენოთ Agile?

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

6. „იტერატიული მოდელი“ (იტერატიული ან განმეორებითი მოდელი)

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

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

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

როდის არის საუკეთესო დრო განმეორებითი მოდელის გამოსაყენებლად?

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

7. „სპირალური მოდელი“ (სპირალური მოდელი)

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

სპირალური მოდელი ითვალისწინებს 4 ეტაპს თითოეული მობრუნებისთვის:

1. დაგეგმვა;
2. რისკის ანალიზი;
3. მშენებლობა;
4. შედეგის შეფასება და თუ ხარისხი დამაკმაყოფილებელია, ახალ შემობრუნებაზე გადასვლა.

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

შევაჯამოთ

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

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

განვითარების ტექნოლოგიების შესახებ:
.
.
.
.

რა მეთოდოლოგიას იყენებთ?