BA / SE

SE#9.1 საინფორმაციო სისტემების განვითარება (Software evolution)

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

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

 

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

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

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

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

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

როგორც სურათზე ჩანს, სპირალურ მოდელის ერთ სრული ციკლი (Release),  შედგება ოთხი ფაზისგან:

  1. ცვლილების მოთხოვნის აღწერა (RFC – Specification);
  2. ცვლილების დაგეგმვა და მომზადება (Implementation);
  3. შესრულებული სამუშაოს შედარება დაგეგმილთან (Validation);
  4. ცვლილების საოპერაციო გარემოში დანერგვა (Implementation).

პროცესების და პროდუქტების განვითარება – Evolution processes

 საინფორმაციო სისტემიშ შიგნით მიმდინარე პროცესების და წარმოებული პროდუქტების განვითარების პროცესი დამოკიდებულია შემდეგ ფაქტორებზე:
  • The type of software being maintained – ინფორმაციული სისტემის სახე და ბიზნეს ოპერირების თვალსაზრისით მისი კრიტიკულობა;
  • The development processes used – სისტემის განახლების პროცესის გამართულობა;
  • The skills and experience of the people involved – ცვლილებების განსახორციელებლად კორპორატიული რესურსების არსებობა.

ცვლილების განხორციელების შესახებ მოთხოვნა (Proposals / Request for change – PFC / RFC),  წარმოადგენს ცვლილების ინიცირების დოკუმენტს. მასში ასახული უნდა იყოს, ცვლილების  განხორციელების შედეგად, მოსალოდნელი გავლენები ოპერირების გარემოზე და სხვა დაკავშირებულ სისტემებზე. ზოგადად ეს პროცესი შემდეგნაირად მიმდინარეობს:

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

ცვლილებების განხორციელების დინამიკა – Program evolution dynamics

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

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

Law Description
Continuing change / ცვლილებების უსასრულობა A program that is used in a real-world environment must necessarily change, or else become progressively less useful in that environment.
Increasing complexity / საინფორმაციო სისტემის გაზრდილი კომპლექსურობა As evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure.
Large program evolution / სისტემის განვითარების დაბალი ტემპი Program evolution is a self-regulating process. System attributes such as size, the time between releases, and the number of reported errors are approximately invariant for each system release.
Organizational stability / ორგანიზაციული სტაბილურობა Over a program’s lifetime, its rate of development is approximately constant and independent of the resources devoted to system development.
Conservation of familiarity / ცვლილებების მუდმივობა Over the lifetime of a system, the incremental change in each release is approximately constant.
Continuing growth / სისტემის და მისი მომხმარებლების ზრდა The functionality offered by systems has to continually increase to maintain user satisfaction.
Declining quality / სისტემის ხარისხის დეგრადირება The quality of systems will decline unless they are modified to reflect changes in their operational environment.
Feedback system / სისტემასტთან მომხმარებლის კავშირი Evolution processes incorporate multi-agent, multi-loop feedback systems and you have to treat them as feedback systems to achieve significant product improvement.

Laws of Program Evolution [Belady & Lehman]

  • Observations about maintenance (#)
    • Maintainers often get less respect than developers
    • Maintenance is generally assigned to the least experienced programmers
    • Software structure degrades over time
    • Documentation is often poor and is often inconsistent with the code
      Law of continuing change.
  • Law of continuing change (#)
    • A large program that is used undergoes continuing change or becomes progressively less useful.
    • Analogies to biological evolution have been made; the rate of change in software is far faster;
  • Law of increasing complexity (#)
    • As a large program is continuously changed, its complexity, which reflects deteriorating structure, increases unless work is done to maintain or reduce it.
    • Complexity, in part, is relative to a programmer’s knowledge of a system. Novices vs. experts doing maintenance
    • Cleaning up structure is done relatively infrequently
    • As a large program is continuously changed, its complexity, which reflects deteriorating structure, increases unless work is done to maintain or reduce it.

სისტემის მომსახურეობა – Software maintenance

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

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

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

  • Team stability:  სისტემის პროგრამისტების გუნდის შეცვლა ან მოძველებული ტექნოლოგიური უნარ ჩვევების სპეციალისტების ყოლის აუცილებლობა;
  • Contractual responsibility:  ჯგუფი (კომპანია) რომელიც მუშაობდა , მხარეებს შორის დადებული კონტრაქტის პირობებით სისტემის შექმნაზე, სისტემის დანერგვის შემდეგ აღარ ახორციელებს სისტემის მხარდაჭერას. სისტემის საოპერაციო მომსახურეობისთვის მოითხოვება ახალი მომსახურეობსი კონტრაქტი და მისი ინვესტირება;
  • knowledge –  სისტემაში რადიკალური ცვლილებების  ჩატარება მოითხოვს კვალიფიციურ სევიალისტებს. როგორც წესი  სისტემის განახლებებით დაკავებულნი არიან დაბალკვალიფიციური  სპეციალისტები, რომელთა პასუხისმგებლობების  საგანი იშვიათად არის სისტემაში კრიტიკული პროცესების ოპტიმიზირება;
  • Program age and structure: სისტემური არქიტექტურის, კოდის და დიზაინის დოკუმენტაცია არ არსებობს. თუ არსებობს განსხვავდება რეალური სისტემისგან და ეს განსხვავება იზრდება სისტემის ასაკთან ერთად;
  • Old Operational platform and Interfaces: ძველი, მწარმოებლის მიერ გამოყენებული ტექნოლოგიები და პროგრამირების ენები.

Image result for software evolution cartoonაღნიშნული პრობლემების შემცირების უნივერსალური ინსტრუმენტები არ არსებობს,  მაგრამ მათი შემცირებისთვის შეიძლება გამოყენებული იქნეს შემდეგი ხერხები:

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

სისტემის კომპონენტების ჩანაცვლების მეთოდი – System re-engineering

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

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

  • Source code translation: convert code to a new language- ძველი კოდის ახალ კოდში კონვერტირება;
  • Reverse engineering: analyze the program to understand it; – სისტემის ან მისი მოდულის ქცევის ანალიზის ჩატარებით, მის ფუნქციონირების შესწავლა და დოკუმენტირება;
  • Program structure improvement: restructure automatically for understandability;  –  სისტემის სტრუქტურის ანალიზი და მისი ოპტიმიზირება;
  • Program modularization: reorganize the program structure; –   სისტემის მოდულებად და ქვემოდულებად დაშლა;
  • Data reengineering: clean-up and restructure system data. – სისტემური მონაცემების და კოდების ინპექტირება, ანალიზი და გაწმენდა.

სისტემის მუდმივი გაუმჯობესების პროცესი – Refactoring

საინფორმაციო სისტემის შექმნის და ოპერირების თანმდევი საფრთხეების და მომსახურეობის ხარჯების შესამცირებლად, ასევე ეფექტურად გამოიყენება, სისტემის ძველი კომპონენტების გაუმჯობესების (Refactoring) მეთოდი.  მეთოდით სარგებლობის დროს, არ იცვლება კომპონენტების და მათი სხვა კომპონენტებთან ფუნქციონირების პროცესები.  სისტემაზე და მის კომპონენტებზე, მუდმივად ხდება დაკვირვება და მოიცავს შემდეგ აქტივობებს (#):
  • Duplicate code or very similar code may be included at different places in a program; it can be removed and implemented as a single method or function that is called as required. – სისტემაში აღმოჩენილი განმეორებითი კოდების გაერთიანება ერთ უნიფიცირებილ მოდულში. მასზე სხვა მოდულებიდან, საჭირო წვდომების წვდომის უზრუნველყოფით;
  • Long methods should be redesigned as a number of shorter methods. – გრძელი ალგორითმების ოპტიმიზირება და შემოკლება;
  • Switch (case) statements often involve duplication, where the switch depends on the type of a value or the switch statements may be scattered around a program. – ისეთი ალგორითმების შექმნა და პროცედურებში გაერთიანება, რომლებიც მათთვის დასამუსავებლად გადაცემული მონაცემების ტიპის მიხედვით, იძლევიან შესაბამის, განსხვავებულ მონაცემებს;
  • Data clumping occurs when the same group of data items (fields in classes, parameters in methods) re-occurs in several places in a program. These can often be replaced with an object that encapsulates all of the data. – სისტემის კოდში გაბნეული, მონაცემთა  დამუშავების ფრაგმენტების გაერთიანება და  მათი ერთ ფუნქციაში კონსოლიდირება;
  • Speculative generality occurs when developers include generality in a program in case it is required in the future. This can often simply be removed. – გაუგებარი სისტემური კოდების დაკომენტირება და გამორთვა სისტემის ქცევის შემდეგი ანალიზისთვის და ამ კოდების შემდგომი Refactoring – ისთვის.

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

სისტემის შემდეგი მომსახურეობის გადაწყვეტილების მიღება

საინფორმაციო სისტემის შემდეგი მომსახურეობის და განვითარების შესახებ გადაწყვეტილების მისაღებად, ორგანიზაციამ ისინი უნდა შეაფასოს  ორგანიზაციული (ბიზნეს) (Busines Value) და ტექნოლოგიური ღირებულებების (System value / Quality) ჭრილში:

  • Low quality, low business value: should be scrapped. –  სისტემას არ ააქვს არც ბიზნეს არც ტექნოლოგიური ღირებულება, უნდა მოხდეს სისტემის  ოპერირების შეჩერება და თუ შესაძლებელია გაყიდვა;
  • Low-quality, high-business value: make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available. – სისტემას მოაქვს ბიზნეს ღირებულება, მაგრამ ტექნოლოგიურად დაბალი ხარისხისაა, ამიტომ უნდა მოხდეს სისტემის Reengineering – ი, ან მოხდეს მისი ჩანაცვლება ბაზარზე არსებული ანალოგიური სისტემით;
  • High-quality, low business value: replace with COTS, scrap completely, or maintain. – სისტემას არ ააქვს კომპანიისთვის ბიზნეს ღირებულება,  მაგრამ ტექნოლოგიურად მაღალი ხარისხისაა. ამიტომ ან უნდა გაიზარდოს მის მიერ ბიზნეს ღირებულების მოტანა ან უნდა მოხდეს მისი შეჩერება და გაყიდვა;
  • High-quality, high business value: continue in operation using normal system maintenance. – სისტემას გააჩნია ბიზნეს ღირებულება და არის მაღალი ტექნოლოგიური ღირებულების.  უნდა მოხდეს მის შემდგომი განვითარებაში და ოპერაციულ მხარდაჭერაში ინვესტირება.

 

დამატებითი მასალა:

  • Innovation vs. Operations- Different Approaches to Management #1, #2
  • SDLC – Software Development Life Cycle  #1#2
  • Software Evolution #1, #2, #3, #4, #5
  • 6 Best Tools To Auto Share Posts On Social Media #1
  • Lehman’s laws of software evolution #1, #2, #3
  • Reverse Engineering and Innovations #1, #2, #3
  • Code Reingenering and Refactoring – #1, #2, #3, #4, #5

კითხვები:

  1. სისტემის ოპერირების გარემოს, რა სახის ცვლილებებს ცვლილებებს შეიძლება ჰქონდეს ადგილი?
  2. რას ნიშნავს ტერმინი “ორგანიზაციული მდგრადობა”? რა კომპონენტებისგან შედგება იგი?
  3. ცვლილებების განხორციელებისთვის, რა სახის ინვესტირება შეიძლება დასჭირდეს ორგანიზაციას?
  4. გააკეთეთ შედარებითი ანალიზი Innovation და Operations;
  5. მოახდინეთ საინფორმაციო სიტემის განვითარებაზე, Lehman და Belady მიერ გამოთქმული მოსაზრებების ანალიზი;
  6. რატომ იზრდება სისტემის მომსახურეობის ხარჯები, სისტემის წლოვანების ზრდის კვალდაკვალ?
  7. რას ნიშნავს ტესტში მოყვანილი წინადადება “ჰეტეროგენული სიტემების შეძენა, რომელთა მომსახურეობის საკითხები ცხადის არაა სისტემის ოპერირების გარემოში”?
  8. მოახდინეთ Reverse Engineering და Code Refactoring ის დანიშნულების აღწერა და შედარებითი ანალიზი;
  9. შესაძლებელია თუ არა, სისტემის შემდეგი მომსახურეობის გადაწყვეტილება განსხვავებული იყოს სხვადასხვა კომპანიებისთვის ? რა ფაქტორებმა უნდა განსაზღვრონ გადაწყვეტილების მიღება?
  10. რა ფაქტორებზეა დამოკიდებული სისტემის მომსახურების ზრდა?

Advertisements

3 thoughts on “SE#9.1 საინფორმაციო სისტემების განვითარება (Software evolution)

  1. Pingback: SE#10.1 System Dependability | IN@TIMES

  2. Pingback: SE#1.1 Introduction to Software Engineering | IN@TIMES

  3. Pingback: SE#2.1 საინფორმაციო სისტემების შექმნის პროცესი – Software Processes | 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