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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

o პრინციპი" გაყავი და იბატონე“;

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

ამ პრინციპებიდან მთავარია:

o აბსტრაქცია - სისტემის არსებითი ასპექტების ხაზგასმა;

o თანმიმდევრულობა - სისტემის ელემენტების ვალიდობა და თანმიმდევრულობა;

o მონაცემთა სტრუქტურირება - მონაცემები უნდა იყოს სტრუქტურირებული და იერარქიულად ორგანიზებული.

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

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

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

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

o მისი აღწერის აუცილებელი სისრულე;

o პროექტის მონაწილეთა ცოდნა და უნარები;

o დიზაინისთვის გამოყოფილი დრო.

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

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

1. კასკადი (ინგლისური ჩანჩქერი) - სტანდარტული განვითარების მოდელი

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

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

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

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

ჩანჩქერის განვითარების ძირითადი უპირატესობები:

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

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

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

არსებობს განვითარების რამდენიმე სწრაფი მეთოდი, მათგან ყველაზე ცნობილია Scrum, Extreme Programming, DSDM.

სწრაფი განვითარების ძირითადი უპირატესობები:

სწრაფი განვითარების პრინციპები:

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

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

1. „გაყავი და იბატონე“ პრინციპი;

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

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

1. აბსტრაქციის პრინციპი - სისტემის არსებითი ასპექტების გამოკვეთა და არაარსებითიდან ყურადღების გადატანა.

2. სისტემის ელემენტების თანმიმდევრულობის, მართებულობისა და თანმიმდევრულობის პრინციპი.

3. მონაცემთა სტრუქტურირების პრინციპი – მონაცემები უნდა იყოს სტრუქტურირებული და იერარქიულად ორგანიზებული.

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

· DFD (Data Flow Diagrams) - მონაცემთა ნაკადების დიაგრამები;

SADT (Structured Analysis and Design Technique - სტრუქტურული ანალიზისა და დიზაინის მეთოდოლოგია) - მოდელები და შესაბამისი ფუნქციური დიაგრამები: აღნიშვნები IDEF0 (სისტემების ფუნქციური მოდელირება), IDEF1x (ბაზების კონცეპტუალური მოდელირება), IDEF3x (ობიექტის ხარისხის შეფასების სისტემების აგება). ნაკადის პროცესების გრაფიკული აღწერა, პროცესებისა და ობიექტების ურთიერთქმედება, რომლებიც იცვლება ამ პროცესებით);

· ERD (Entity - Relationship Diagrams) - „ერთეული-ურთიერთობის“ დიაგრამები.

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

1. დიაგრამები, რომლებიც ასახავს ფუნქციებს, რომლებიც სისტემამ უნდა შეასრულოს და ამ ფუნქციებს შორის კავშირები - DFD ან SADT (IDEF0).

2. დიაგრამები მოდელირების მონაცემები და მათი ურთიერთობები (ERD).

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

პროგრამული მოთხოვნების ფორმირების ეტაპზე SADT მოდელები და DFD გამოიყენება "AS-IS" მოდელის და "TO-BE" მოდელის შესაქმნელად, რაც ასახავს ორგანიზაციის ბიზნეს პროცესების არსებულ და შემოთავაზებულ სტრუქტურას და მათ შორის ურთიერთქმედებას. (SADT მოდელების გამოყენება, როგორც წესი, შემოიფარგლება მხოლოდ ამ ეტაპით, რადგან ისინი თავდაპირველად არ იყო განკუთვნილი პროგრამული უზრუნველყოფის დიზაინისთვის). ERD-ის დახმარებით ხდება ორგანიზაციაში გამოყენებული მონაცემების აღწერა კონცეპტუალურ დონეზე, მიუხედავად მონაცემთა ბაზის დანერგვის საშუალებებისა (DBMS).

1.კოდირება

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

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

კოდირებისას აუცილებელია არჩეული ენის სტანდარტის დაცვა, მაგალითად, C ენისთვის არის ANSI C, ხოლო C++-ისთვის ISO/IEC 14882 „Standart for the C++ ProgrammingLanguage“.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

კარგად დოკუმენტირებული PP-ს აქვს შემდეგი უპირატესობები.

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

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

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

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