SE

SE#2.1 პროგრამული უზრუნველყოფის შექმნის პროცესი (Software Processes)

Reference: Sommerville, Software Engineering, 10 ed., Chapter 2

“ზეციურის დედამიწაზე განხორციელების მცდელობა ყოველთვის ჯოჯოხეთს იწვევს”
კარლ პოპერი – მეცნიერული აღმოჩენის ლოგიკა

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

პროგრამული უზრუნველყოფის შექმნის პროცესი – Software process (SP)

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

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

  1. Software Specification –  რას უნდა ასრულებდეს საინფორმაციო სისტემა;
  2. Software Design and implementation – სისტემის შექმნის, დანერგვის და ექსპლუატაციის საკითხების დადგენა; (#)
  3. Software Validation – სისტემის  მომხმარებლის საჭიროებებთან შესაბამისობის დადგენა;
  4. Software Evolution – სისტემის  მომხმარებლების, ახალ საჭიროებებთან მორგების შესაძლებლობა.

Specification – defining what the system should do;
Design and implementation – defining the organization of the system and implementing the system;
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing customer needs. #1, #2

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

  1. პროდუქტს – პროგრამული უზრუნველყოფის (Software) შექმნის  პროცესის აქტივობების შედეგს;
  2. როლებს –  პროდუქტის შექმნის პროცესში ჩართული მხარეების უფლება-მოვალეობებს;
  3. პროცესის დაწყებამდე და პროცესის დასრულების შემდეგ სისტემის მდგომარეობას.
  4. და ა.შ
  • Products, which are the outcomes of a process activity;
  • Roles, which reflect the responsibilities of the people involved in the process;
  • Pre- and Post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced.

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

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

ამ მეთოდების კერძო შემთხვევები ასეთია:

The waterfall model – (Plan-driven model- გეგმიური მოდელი)
S-ის სპეციფიკაციების დადგენის, დიზაინის, შექმნის, ტესტირების და დანერგვის შემდეგი მომსახურეობის ფაზების თანმიმდევრობა მკაცრად განსაზღვრულია.
Incremental development ( Plan-driven or Agile – ან იტერაციული მოდელი)
საინფორმაციო სისტემის შექმნა, სამუშაო გუნდის მიერ შეთანხმებული პრიორიტეტებით და პროდუქტის ვერსიების თანმიმდევრული სერიებით.  სისტემის ფუნქციონალის თანმიმდევრული ზრდა.
Integration and configuration ( Plan-driven or Agile – გეგმიური ან იტერაციული მოდელი)
არსებული გამოცდილების გათვალისწინებით, უკვე შემუშავებული კომპონენტების ახალ სისტემაში ინტეგრაცია.

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

Software process models #1

  1. The waterfall model – (Plan-driven model) – Separate and distinct phases of specification, software design, implementation, testing, and maintenance;
  2. Incremental development – (May be plan-driven or agile) – Specification, development and validation are interleaved. The system is developed as a series of versions (increments), with each version adding functionality to the previous version;
  3. Integration and configuration – (May be plan-driven or agile) – Based on the existence of a significant number of reusable components/systems. The system development process focuses on integrating these components into a system rather than developing them from scratch. May be plan-driven or agile.

The waterfall model – ში სისტემის შექმნა შემდეგი თანმიმდევრობით მიმდინარეობს

  1. Requirements analysis and definition
    • სისტემისადმი მოთხოვნები, ამოცანის მიზნები და საზღვრები დგინდება შემსრულებლის და შემკვეთის მონაწილეობით და შეტანხმებით. შედეგად ყალიბდება სისტემის სპეციფიკაციების დოკუმენტი; (Requirements Engineering)
  2. System and software design
    • გამოთვლითი სისტემის დიზაინის შექმნის პროცესში დგინდება პროგრამული და გამოთვლითი სისტემების არქიტექტურა და მოთხოვნები.  პროგრამული დიზაინის შექმნის პროცესში, პროგრამული მოდულების მოთხოვნები და მათ შორის ურთიერთკავშირი. (Software System Modeling)
  3. Implementation and unit testing
    • პროგრამული მოდულების შექმნა და ტესტირება, შეთანხმებულ სისტემურ  და პროგრამულ მოთხოვნებთან შესაბამისობაზე (Software Quality Management);
  4. Integration and system testing
    • პროგრამული მოდულების ტესტირება ურთიერთ თავსებადობაზე და მთლიანი სისტემის სპეციფიკაციებთან შესაბამისობაზე; ((Software Testing))
  5. Operation and maintenance
    • სისტემის რეალურ სამუშაო  რეჟიმში გაშვება და მისი მონიტორინგი, ხარვეზების აღმოჩენა და შესწორება. ახალი შესაძლებობების დოკუმენტირება სისტემის შემდგომი შესაძლო განახლებისთვის. (Software Evolution)

Related image

The waterfall model – შეფასება

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

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

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

Incremental development model –  შეფასება

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

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

concernsofagile

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

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

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

The waterfall და  Incremental development მეთოდების შედარებით ანალიზი

agilevsplan

The waterfall და  Incremental development მეთოდების პრაქტიკული გამოყენების სტატისტიკაWhy software development projects fail

agile vs. waterfall success rateსაკითხავი მასალა:

  1. Plan-Driven vs Agile methodologies  #1, #2, #3, #4
  2. People Factors in Software Management: Lessons From Comparing Agile and Plan-Driven Methods #1
  3. Using agile to accelerate your data transformation #1
  4. SWOT Analysis #1, #2;
  5. Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage #1
  6. SOFTWARE HORROR STORIES #1

დავალება:

  1. რას წარმოადგენს პროგრამული უზრუნველყოფის (Software) შექმნის პროცესი;
  2. ჩამოთვალეთ, განსხვავებული პროგრამული უზრუნველყოფის (Software) შექმნის მეთოდების, საერთო კომპონენტები;
  3. ჩაატარეთ გეგმიური (Plan-Driven)  მეთოდის SWOT  ანალიზი;
  4. ჩაატარეთ იტერაციული (Agile) მეთოდების SWOT  ანალიზი;
  5. შეადარეთ ერთმანეთს გეგმიური (Plan-Driven) და იტერაციული (Agile) მეთოდები;
  6. დაასახელეთ გეგმიური (Plan-Driven) მეთოდის კერძო შემთხვევები;
  7. დაასახელეთ იტერაციული (Agile) მეთოდის კერძო შემთხვევები;
  8. დაასახელეთ The waterfall model -ის პროცესები და მათი მიმდინარეობის თანმიმდევრობა;
  9. მოსახერხებელია თუ არა waterfall მეთოდის გამოყენება ისეთ პროდუქტების შექმნის დროს, სადაც სისტემის მახასიათებლები წინასწარ არაა ან სუსტადაა ცნობილი.  რატომ ?
  10. მოსახერხებელია თუ არა იტერაციული (Agile) მეთოდის გამოყენება ისეთ პროდუქტების შექმნის დროს, სადაც სისტემის მახასიათებლები წინასწარ არაა ან სუსტადაა ცნობილი.  რატომ ?
Advertisements

2 thoughts on “SE#2.1 პროგრამული უზრუნველყოფის შექმნის პროცესი (Software Processes)

  1. Pingback: DT#1.1 რა არის იდეების მოდელირება (What is Design Thinking) | IN@TIMES

  2. Pingback: DT#1.1 შემოქმედებითი აზროვნება (Design Thinking) | IN@TIMES

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s