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

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



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

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

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


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

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


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

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

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

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


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

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

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

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

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

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


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

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

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


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

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

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

ზრდადი მოდელის უარყოფითი მხარეები

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

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

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


სწრაფი მოდელი

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

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

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


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

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



V მოდელი

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

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


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

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

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

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

V მოდელი - ნაკლოვანებები

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

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

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


ჩანჩქერის მოდელი

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

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

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

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

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

ჩანჩქერის მოდელის უპირატესობები

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

ჩანჩქერის მოდელის უარყოფითი მხარეები

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

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

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

საინტერესო სტატიები