პროგრამულიუზრუნველყოფისინჟინერია - შესავალი

მიხეილ კაპანაძე

კომპიუტერიზაციის გარიჟრაჟზე

n იწერებოდა მცირე ზომის პროგრამები

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

n ამ ადამიანს ჰქონდა იმ დარგის ექსპერტული ცოდნარომლისთვისაც წერდა

n ინფორმაციის შეტანა–გამოტანა მთლიანად ციფრულიიყო

Software–ინდუსტრია ძველად

n თითქმის არ არსებობდნენ დამოუკიდებელი Software–კომპანიები

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

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

სიტუაცია დღეს

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

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

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

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

n მოკლედ, სიტუაცია სრულიად შეცვლილია

1960–იანი წლების სიტუაცია

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

n პროგრამირება ისევ აღიქმებოდა როგორც ხელოვნებადა არა ხელობა

n ამოცანებზე მუშაობდნენ ძირითადად თვითნასწავლიკადრები

n პრობლემები წყდებოდა პროექტში ახალ–ახალიპროგრამისტების დამატებით

მილიონი მაიმუნი

n თეორემა ამბობს რომ თუკიმაიმუნი უსასრულო დროისგანმავლობაში დააჭერს თითებსსაბეჭდ მანქანაზე, მაშინ თითქმისგარანტირებულია რომ ის ადრე თუგვიან აკრეფს საჭირო ტექსტს.

n რა მოხდება თუკი მილიონ მაიმუნსკომპიუტერებს დავუდგამთ?

კრიზისი 1960–იანებში

n ამოცანები დროში ჭიანურდებოდა და მიწოდებისვადები ხშირად ირღვეოდა

n პროგრამები არ მუშაობდნენ ისე როგორც ამასმომხმარებლები მოელოდნენ

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

n ბევრი შეცდომის აღმოჩენა ხდებოდა მხოლოდ მაშინროცა პროგრამა უკვე მოხმარებაში იყო ჩაშვებული

ტერმინი Software Engineering

n 1968 და 1969 წელს კრიზისსმიეძღვნა NATO–ს ორიკონფერენცია

n ამ კონფერენციებზეპირველად გამოიყენესტერმინი Software Engineering

n ნუთუ არ შეიძლება, შევქმნთპროგრამები ისე როგორცვქმნით, მაგალითად, ხიდებს?

მშვიდობის ხიდი თბილისში. წყარო: http://www.wikipedia.org

რატომაა ეს ასე მნიშვნელოვანი?

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

n 1991 წლის 25 თებერვალს სპარსეთის ყურის ომშიერაყული რაკეტა დაეცა აშშ არმიის ყაზარმებს.

n დაიღუპა 28 ჯარისკაცი. დაიჭრა 100.

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

განმარტება IEEE-ს ლექსიკონიდან(IEEE610, 1990)

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

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

n პროგრამული უზრუნველყოფის ინჟინერია ფოკუსირდებამხოლოდ დიდ პროგრამებზე. q არსებობს ცნებები programming-in-the-large და programming-in-the-

small.q ამ შემთხვევაში “დიდი” და “პატარა”, ინტუიციურად განისაზღვრება.

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

n თავად სიტყვა “პროგრამაც” უადგილოა. მაგალითად, Windows 7–ს შეუძლებელია ვუწოდოთ “პროგრამა”.

სირთულის მართვა

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

n ამას ეწოდება პასუხისმგებლობების განაწილება

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

n აქ საუბარია არაა გამოთვლით სირთულეზე. ამოცანას ართულებსმცირე ნიუანსების დიდი რაოდენობა.

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

n პროგრამული უზრუნველყოფა იქმნება რეალური ამოცანებისგადასაჭრელად

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

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

პროცესის ეფექტურობა

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

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

n ბაზარი მუდმივად ითხოვს ახალ და ახალ გადაწყვეტებს

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

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

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

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

n ხშირად გუნდები გეოგრაფიულადაც არიან დაშორებულები

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

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

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

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

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

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

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

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

მულტიკულტურულობა

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

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

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

კომპრომისების ხელოვნება

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

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

n თუმცა ზოგიერთი “უცნაური” მოთხოვნა მაინც რჩება.

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

პროგრამირება?

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

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

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

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

n რასაკვირველია, ორივე პროცესს ბევრი საერთო გააჩნია

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

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

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

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

n რასაკვირველია, ორივე პროცესს ასევე გააჩნია ბევრიგანმასხვავებელი

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

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

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

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

n რა მოხდება თუ პროგრამას არ მოვუვლით? ის იმუშავებს ისე, როგორც მუშაობდა.

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

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

იმის თქმა, საქმე 90%–თაა დასრულებული თუ 60%–ით

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

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

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

დასკვნა

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

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

ლიტერატურა

Software Engineering: Principles and Practiceავტორი: Hans van Vlietგამომცემლობა: John Wiley & Sonsგამოცემულია: June 30, 2008ISBN: 978-0-470-03146-9Web ISBN: 0-47-003146-8

გმადლობთყურადღებისათვის!

მომავალ შეხვედრამდე!