Развитие ( evolution ) на софтуера

1. Развитие (evolution) на софтуера

2. Цели • Да обясни защо промените са неизбежни, ако искаме софтуерните с-ми да вършат работа • Да дискутира поддръжката на софтуера и факторите, които влияят в/у цената, • Да опише процесите, въвлечени развитието • Да се обсъди един подход за оценка на развитието на наследени с-ми

3. Теми • Динамика на развитието на програмите • Поддръжка на софтуера • Процес на развитието • Развитие на наследени с-ми

4. Промяна на софтуера • Промяната на софтуера е неизбежна • Когато се използва софтуера, възникват нови изисквания; • Променя се бизнес средата; • Трябва да се поправят грешките; • Към с-мата се добавят нови компютри и оборудване; • Трябва да се подобри ефективността или надеждността на с-мата. • Основният проблем за организациите е осъществяването и управлението на промените в съществуващите софтуерни с-ми

5. Значение на развитието • Организациите имат огромни инвестиции в софтуерните с-ми – те са критични бизнес активи • За да се поддържа тяхната стойност за бизнеса, те трябва да се променят и осъвременяват. • Голяма част от бюджета в големите компании е предназначен за развитие на съществуващия софтуер, а не за разработка на нов.

6. Спирален модел на развитието

7. Динамика на програмното развитие • Това е изучаване на процесите на промяна на с-мите • След значителни емпирични изследвания, Lehman и Belady предлагат няколко 'закона', които са били приложими към всички с-ми в развитие. • Това са по-скоро разумни наблюдения отколкото закони. Те са приложими за големи с-ми, разработвани от големи организации. Може би по-малко приложими в други случаи.

8. Закони на Lehman

9. Приложимост на законите на Lehman • Законите на Lehman са приложими за големи с-ми, разработени от големи организации • Потвърдено от по-скорошна работа на Lehman • Не е сигурно, дали могат да адаптират към: • Готови софтуерни продукти за масова консумация • С-ми включващи много готови компоненти • Малки организации • Средни по размер с-ми

10. Поддръжка на софтуера • Модифициране на програма, след като вече е предадена за използване. • Поддръжката обикновено не включва големи промени в архитектурата. • Промените се осъществяват чрез промени в съществуващите компоненти и добавяне на нови такива.

11. Поддръжката е неизбежна • Много вероятно е още по време на разработката да се променят с-мните изисквания поради промяна на обкръжението. Така предоставената с-ма няма да отговаря на новите изисквания. • С-мите са тясно свързани с обкръжението си. Когато 1 с-ма се инсталира в обкръжение, самото обкръжение се променя и оттам изискванията към с-мата. • С-мите ТРЯБВА да се поддържат, ако искаме да останат полезни в обкръжението си.

12. Видове поддръжка • Поправка на грешки в с-мата Промяна за отстраняване на дефектите, така ч е да отговаря на изискванията. • Адаптиране към различно операционно обкръжение Промяна на с-мата, така че да работи в различна от началната среда (компютър, ОС). • Добавяне или промяна на функционалността Модифициране на с-мата, за да удовлетворява новите изисквания.

13. Разпределение на усилията за поддръжка

14. Разходи за поддръжка • Обикновено са по-големи от тези за разработка (до 4 пъти в зависимост от приложението). • Влияят се от технически и нетехнически фактори. • Увеличават с времето. Поддръжката поврежда структурата на програмата, което прави поддръжката по-трудна. • Остаряващият софтуер има по-големи разходи за поддръжка (напр. стари езици, компилатори и др.)

15. Разходи за разработка/поддръжка

16. Фактори влияещи на разходите • Стабилност на екипа Разходите за поддръжки се намаляват, ако едни и същи хора работят в/у един същи елемент за известно време • Договорена отговорност Разработчиците може да нямат договореност за поддръжка и затова да не се грижат в проекта за бъдещи промени. • Умения на персонала Често персоналът по поддръжката е неопитен и е с ограничени познания в областта на приложение. • Възраст на програмата и структура С остаряването на програмата, структурата се влошава и те стават по-трудни за разбиране и промени

17. Предсказване на поддръжката • То е свързано с оценка, кои части от с-мата могат да предизвикат проблеми и да високи разходи за поддръжка. • Приемането на промяна зависи от способността за поддръжка на компонентите засегнати от промяната • Осъществяването на промените влошава структурата на с-мата и намалява способността й за поддръжка, • Разходите за поддръжка зависят от броя на промените, а цената на промяната зависи от способността за поддръжка.

18. Предсказване на поддръжката Кои части от с-мата са най-скъпи за поддръжка Кои части от с-мата е най-вероятно да се засегнат от искания за промени Predicting maintainability Какви ще бъдат разходите за поддръжка за целия жизнен цикъл? Predicting Predicting system maintenance changes costs Какви ще бъдат разходите за поддръжка за следващата година? Колко искания за промени могат да се очакват

19. Предвиждане на промените • Предвиждането на броя на промените изисква разбиране на връзката м/у с-мата и обкръжението • Силно свързаните с-ми изискват промени всеки път, когато се промени обкръжението. • Факторите, които влияят в.у връзката са: • Броят и сложността на интерфейсите на с-мата; • Броят на по природа непостоянните изисквания; • Бизнес процесите, в които се използва с-мата.

20. Измерване на сложността • Предвиждането на способността за поддръжка може да се направи чрез оценяване на сложността на компонентите. • Изследванията показват,че повечето усилия за поддръжка се разходват на малко на брой компоненти. • Сложността зависи от • Сложността на управляващите структури • Сложността на структурите от данни • Размерът на обектите, методите(процедурите) и модулите

21. Измерване на процеса • Измерванията на процеса могат да служат за оценка на способността за поддръжка • Брой на исканията за поправки • Средно време изисквано за анализ на въздействието • Средно време за осъществяване на промените • Брой на неизпълнените заявки за промяна • Ако някоя от горните величини се увеличи, това може да покаже намаление на способността за поддръжка.

22. Процес на развитие • Процесът на развитие зависи от • Типът на софтуера, който се поддържа • Използваният процес на разработка • Уменията и опита на хората, които се занимават с това • Предложенията за промени са двигателя на развитието. То продължава през целия живот на с-мата.

23. Идентификация на промените и развитие на с-мата

24. Процес на развитие на с-мата Change Impact Release Change S ystem release r equests anal ysis planning implementation Platform S ystem F ault repair adaptation enhancement

25. Осъществяване на промените Proposed Requirements Requirment Software development changes analysis updating

26. Спешни искания за промени • Спешните искания могат да се осъществят без преминаване през всички етапи на процеса. • Когато трябва да се изправи сериозна грешка; • Когато промени в обкръжението (промяна в ОС) има непредвидени ефекти; • Когато има промени в бизнеса, които изискват много бърз отговор (напр. пускането на конкурентен продукт)

27. Спешна поправка

28. Преработка(re-engineering) на с-мата • Преструктуриране и или пренаписване на част от или на цялата наследена с-ма без да се променя функционалността й. • Прилага се, когато някои, но не всички под-с-ми на една голяма с-ма изискват честа поддръжка. • Изразходват се допълнителни усилия, за да се направи с-мата по-лесна за поддръжка. С-мата може да се преструктурира и да се документира отново.

29. Предимства на преработката • Намален риск Разработката на нов софтуер крие голям риск. Може да има проблеми в разработката, с персонала и със спецификациите. • Намалени разходи Разходите за преработка са често значително по-ниски от тези за разработка на нов софтуер.

30. Нова разработка и преработка S ystem Design and Ne w specification implementation system F orw ar d eng ineering Re-engineered Existing Understanding and software system tr ansf or ma tion system Softw ar e r e-eng ineering

31. Процес на преработката Modularised Pr og ram Orig inal data Orig inal program documentation program Reverse enginineering Data Prog ram Source code re-engineering modularisation translation Prog ram structure improvement Structured Re-engineered program data

32. Дейности на процеса на преработка • Превод на сорс кода Кода се пренася на нов език • Обратен инженеринг • Анализира се програмата, за да се разбере • Подобрение на програмната структура Управляващите структури се анализират и променят за по-голяма разбираемост и яснота. • Промяна на модулността Реорганизира се структурата на програмата, цс цел подобрение и адаптиране към новите условия. • Преработка на данните Почистване и преструктуриране на данните на с-мата.

33. Подходи за преработка Автоматично преструктуриране на програмата Преструктуриране на данните и на програмата Автоматизирано конвертиране на сорс кода Автоматично преструктуриране с ръчни промени Преструктуриране + промени в архитектурата Увеличение на разходите

34. Фактори за разходите за преработка • Качеството на софтуера, който се преработва • Наличните инструменти (средства) за това • Степента на нужното преструктуриране на данните • Наличието на експертен персонал • Това може да е проблем със стари с-ми, базирани на отмряла технология.

35. Развитие на наследени с-ми • Организациите, които разчитат на наследени с-ми трябва да използват стратегия за развитие на тези с-ми. • Спри напълно с-мата и промени бизнес процесите по такъв начин, че тя да не е повече нужна. • Продължи да поддържаш с-мата • Преработи с-мата, за да се подобри нейната способност за поддръжка • Замени с-мата с нова. • Избраната стратегия зависи от качеството на с-мата и нейната бизнес стойност.

36. Качество и бизнес стойност на с-мата

37. Класове наследени с-ми • Ниско качество, ниска стойност Тези с-ми трябва да се изхвърлят • Ниско качество, висока стойност Те са важни за бизнеса, но са скъпи за поддръжка. Трябва да се преработят или да се заменят с нови. • Високо качество, ниска стойност Тези с-ми трябва да се заменят с готови компоненти, да се изхвърлят или поддържат • Високо качество, висока стойност Използването трябва да се продължи с нормална поддръжка.

38. Оценка на бизнес стойността • Оценката трябва да вземе предвид различни гледни точки • Крайните потребители • Клиентите на бизнеса • Ръководителите – ниско ниво • IT ръководителите • Висшето ръководство • Интервюират се различните поръчители и резултатите се събират заедно.

39. Оценка на качеството на с-мата • Оценка на бизнес процеса Колко добре бизнес процесите поддържат текущите цени на бизнеса? • Оценка на обкръжението Колко ефективно е обкръжението и колко е трудна поддръжката му? • Оценка на приложението Какво е качеството на приложната софтуерна с-ма? • Application assessment • What is the quality of the application software system?

40. Оценка на бизнес процеса • Използват се различни гледни точки и се търсят отговори от поръчителите. • Има ли дефиниран модел на процеса и следва ли се този модел? • Дали различните части на организацията използват различни процеси за едни същи функции? • Как е бил адаптиран процеса? • Каква е връзката с другите бизнес процеси и дали са нужни те? • Дали процесът е добре поддържан от наследената с-ма? • Пример – с-ма за пътническа агенция може да има ниска бизнес стойност заради широкото разпространение на WEB-базираното поръчване на билети

41. Оценка на обкръжението 1

42. Оценка на обкръжението 2

43. Оценка на приложението 1

44. Оценка на приложението2

45. Измерване на с-мата • може да се събират количествени данни, за да се направи оценка на качеството на приложната с-ма. • Брой на исканията за промени в с-мата • Брой на различните потребителски интерфейси, използвани от с-мата • Обем на данните, използвани от с-мата.

46. Обобщение • Разработката и развитието на с-мата трябва да е един итеративен процес. • Законите на Lehman описва няколко интуитивни прозрения за развитието на с-мите. • Трите вида поддръжка са: оправяне на грешките. промяна на софтуера за ново обкръжение и осъществяване на нови изисквания. • За индивидуални с-ми, разходите по поддръжка обикновено надвишават тези за разработка,

47. Обобщение • Процесът на развитието се води от исканията за промени от поръчителите. • Преработката на софтуера се занимава с преструктурирането и наново документиране на софтуера, за да го направи по-лесн за промени. • Бизнес стойността на наследената с-ма и нейното качество трябва да определят стратегията за развитие.