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

Software Engineering, 7th edition. Chapter 21 Slide 1

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


Цели

Да обясни защо промените са неизбежни, ако искаме софтуерните с-ми да вършат работа

Да дискутира поддръжката на софтуера и факторите, които влияят в/у цената,

Да опише процесите, въвлечени развитието

Да се обсъди един подход за оценка на развитието на наследени с-ми


Теми

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


Промяна на софтуера

Промяната на софтуера е неизбежна• Когато се използва софтуера, възникват нови

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

надеждността на с-мата. Основният проблем за организациите е

осъществяването и управлението на промените в съществуващите софтуерни с-ми


Значение на развитието

Организациите имат огромни инвестиции в софтуерните с-ми – те са критични бизнес активи

За да се поддържа тяхната стойност за бизнеса, те трябва да се променят и осъвременяват.

Голяма част от бюджета в големите компании е предназначен за развитие на съществуващия софтуер, а не за разработка на нов.


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

Specification Implemention

ValidationOperation

Start

Release 1

Release 2

Release 3


Това е изучаване на процесите на промяна на с-мите

След значителни емпирични изследвания, Lehman и Belady предлагат няколко 'закона', които са били приложими към всички с-ми в развитие.

Това са по-скоро разумни наблюдения отколкото закони. Те са приложими за големи с-ми, разработвани от големи организации. Може би по-малко приложими в други случаи.

Динамика на програмното развитие


Закони на Lehman

Закон Описание

Непрекъснати промени Програма, която се използва в реална среда, непременно трябва да се променя или става все по-безполезна в тази среда.

Увеличаваща се сложност

С промените, структурата на програмата се усложнява. Трябва да се привлекат допълнителни ресурси, за да се запази и опрости структурата.

Развитие на големите програми

Развитието на програмите е саморегулиращ процес. С-мни атрибути, като размер, време м/у рилизите и броя на грешките е приблизително инвариантен във всеки рилиз

Организационна стабилност

През жизнения цикъл, скоростта на развитие е приблизително постоянна и независима от отделните за това ресурси.

Запазване на познаваемостта

През жизнения цикъл, промените във всеки рилиз са приблизително постоянни по рамер.

Непрекъснат растеж Функционалността трябва непрекъснато да расте, за да поддържа задоволяването на потребителите.

Намаляващо качество Качеството видимо намалява, освен ако с-мата не се адаптира към промените в операционната среда.

С-ма за обратна връзка В процеса на развитие са включени мулти-агентни, сложни с-ми за обратна връзка, които трябва да се разгледат и използват за постигането на значителни подобрения


Приложимост на законите на Lehman

Законите на Lehman са приложими за големи с-ми, разработени от големи организации• Потвърдено от по-скорошна работа на

Lehman Не е сигурно, дали могат да адаптират

към:• Готови софтуерни продукти за масова

консумация• С-ми включващи много готови компоненти• Малки организации• Средни по размер с-ми


Модифициране на програма, след като вече е предадена за използване.

Поддръжката обикновено не включва големи промени в архитектурата.

Промените се осъществяват чрез промени в съществуващите компоненти и добавяне на нови такива.

Поддръжка на софтуера


Много вероятно е още по време на разработката да се променят с-мните изисквания поради промяна на обкръжението. Така предоставената с-ма няма да отговаря на новите изисквания.

С-мите са тясно свързани с обкръжението си. Когато 1 с-ма се инсталира в обкръжение, самото обкръжение се променя и оттам изискванията към с-мата.

С-мите ТРЯБВА да се поддържат, ако искаме да останат полезни в обкръжението си.

Поддръжката е неизбежна


Поправка на грешки в с-матаПромяна за отстраняване на дефектите, така ч е

да отговаря на изискванията. Адаптиране към различно операционно

обкръжениеПромяна на с-мата, така че да работи в

различна от началната среда (компютър, ОС).

Добавяне или промяна на функционалносттаМодифициране на с-мата, за да удовлетворява

новите изисквания.

Видове поддръжка


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

Functionalityaddition or

modification(65%)

Fault repair(17%)

Softwareadaptation

(18%)


Обикновено са по-големи от тези за разработка (до 4 пъти в зависимост от приложението).

Влияят се от технически и нетехнически фактори. Увеличават с времето. Поддръжката поврежда

структурата на програмата, което прави поддръжката по-трудна.

Остаряващият софтуер има по-големи разходи за поддръжка (напр. стари езици, компилатори и др.)

Разходи за поддръжка


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

0 50 100 150 200 250 300 350 400 450 500

System 1

System 2

Development costs Maintenance costs

$


Стабилност на екипаРазходите за поддръжки се намаляват, ако едни и същи

хора работят в/у един същи елемент за известно време Договорена отговорност

Разработчиците може да нямат договореност за поддръжка и затова да не се грижат в проекта за бъдещи промени.

Умения на персоналаЧесто персоналът по поддръжката е неопитен и е с

ограничени познания в областта на приложение. Възраст на програмата и структура

С остаряването на програмата, структурата се влошава и те стават по-трудни за разбиране и промени

Фактори влияещи на разходите


Предсказване на поддръжката

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

поддръжка на компонентите засегнати от промяната• Осъществяването на промените влошава структурата

на с-мата и намалява способността й за поддръжка,• Разходите за поддръжка зависят от броя на

промените, а цената на промяната зависи от способността за поддръжка.


Предсказване на поддръжката

Predictingmaintainability

Predicting systemchanges

Predictingmaintenance

costs

Какви ще бъдат разходите за поддръжка за целия жизнен цикъл?

Кои части от с-мата са най-скъпи за поддръжка

Колко искания за промени могат да се очакват

Кои части от с-мата е най-вероятно да се засегнат от искания за промени

Какви ще бъдат разходите за поддръжка за следващата година?


Предвиждане на промените

Предвиждането на броя на промените изисква разбиране на връзката м/у с-мата и обкръжението

Силно свързаните с-ми изискват промени всеки път, когато се промени обкръжението.

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


Измерване на сложността

Предвиждането на способността за поддръжка може да се направи чрез оценяване на сложността на компонентите.

Изследванията показват,че повечето усилия за поддръжка се разходват на малко на брой компоненти.

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

модулите


Измерване на процеса

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

Ако някоя от горните величини се увеличи, това може да покаже намаление на способността за поддръжка.


Процес на развитие

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

занимават с това Предложенията за промени са двигателя

на развитието. То продължава през целия живот на с-мата.


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

Change proposalsNew system

Change identificationprocess

Software evolutionprocess


Процес на развитие на с-мата

Releaseplanning

Changeimplementation

Systemrelease

Impactanalysis

Changerequests

Platformadaptation

Systemenhancement

Fault repair


Осъществяване на промените

Requirmentupdating

Softwaredevelopment

Requirementsanalysis

Proposedchanges


Спешни искания за промени

Спешните искания могат да се осъществят без преминаване през всички етапи на процеса.• Когато трябва да се изправи сериозна

грешка;• Когато промени в обкръжението (промяна в

ОС) има непредвидени ефекти; • Когато има промени в бизнеса, които

изискват много бърз отговор (напр. пускането на конкурентен продукт)


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

Modifysource code

Deliver modifiedsystem

Analysesource code

Changerequests


Преработка (re-engineering) на с-мата

Преструктуриране и или пренаписване на част от или на цялата наследена с-ма без да се променя функционалността й.

Прилага се, когато някои, но не всички под-с-ми на една голяма с-ма изискват честа поддръжка.

Изразходват се допълнителни усилия, за да се направи с-мата по-лесна за поддръжка. С-мата може да се преструктурира и да се документира отново.


Предимства на преработката

Намален рискРазработката на нов софтуер крие голям риск.

Може да има проблеми в разработката, с персонала и със спецификациите.

Намалени разходиРазходите за преработка са често значително

по-ниски от тези за разработка на нов софтуер.


Нова разработка и преработка

Understanding andtransformation

Existingsoftware system

Re-engineeredsystem

Design andimplementation

Systemspecification

Newsystem

Software re-engineering

Forward engineering


Процес на преработката

Reverseenginineering

Programdocumentation

Datare-engineering

Original data

Programstructure

improvement

Programmodularisation

Structuredprogram

Re-engineereddata

Modularisedprogram

Originalprogram

Source codetranslation


Дейности на процеса на преработка

Превод на сорс кодаКода се пренася на нов език

Обратен инженеринг• Анализира се програмата, за да се разбере

Подобрение на програмната структураУправляващите структури се анализират и променят за

по-голяма разбираемост и яснота. Промяна на модулността

Реорганизира се структурата на програмата, цс цел подобрение и адаптиране към новите условия.

Преработка на даннитеПочистване и преструктуриране на данните на с-мата.


Подходи за преработка

Автоматично преструктуриране с

ръчни промени

Автоматизирано конвертиране на

сорс кода

Преструктуриране + промени в

архитектурата

Автоматично преструктуриране

на програмата

Преструктуриране на данните и на програмата

Увеличение на разходите


Фактори за разходите за преработка

Качеството на софтуера, който се преработва

Наличните инструменти (средства) за това

Степента на нужното преструктуриране на данните

Наличието на експертен персонал• Това може да е проблем със стари с-ми,

базирани на отмряла технология.


Развитие на наследени с-ми

Организациите, които разчитат на наследени с-ми трябва да използват стратегия за развитие на тези с-ми.• Спри напълно с-мата и промени бизнес процесите по

такъв начин, че тя да не е повече нужна.• Продължи да поддържаш с-мата• Преработи с-мата, за да се подобри нейната

способност за поддръжка• Замени с-мата с нова.

Избраната стратегия зависи от качеството на с-мата и нейната бизнес стойност.


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

12

3 45

6

7

89

10

System quality

High business valueLow quality High business value

High quality

Low business valueLow quality

Low business valueHigh quality


Класове наследени с-ми

Ниско качество, ниска стойностТези с-ми трябва да се изхвърлят

Ниско качество, висока стойностТе са важни за бизнеса, но са скъпи за

поддръжка. Трябва да се преработят или да се заменят с нови.

Високо качество, ниска стойностТези с-ми трябва да се заменят с готови

компоненти, да се изхвърлят или поддържат Високо качество, висока стойност

Използването трябва да се продължи с нормална поддръжка.


Оценка на бизнес стойността

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

Интервюират се различните поръчители и резултатите се събират заедно.


Оценка на качеството на с-мата

Оценка на бизнес процесаКолко добре бизнес процесите поддържат текущите цени

на бизнеса? Оценка на обкръжението

Колко ефективно е обкръжението и колко е трудна поддръжката му?

Оценка на приложениетоКакво е качеството на приложната софтуерна с-ма?

Application assessment• What is the quality of the application software system?


Оценка на бизнес процеса

Използват се различни гледни точки и се търсят отговори от поръчителите.• Има ли дефиниран модел на процеса и следва ли се

този модел?• Дали различните части на организацията използват

различни процеси за едни същи функции?• Как е бил адаптиран процеса?• Каква е връзката с другите бизнес процеси и дали са

нужни те?• Дали процесът е добре поддържан от наследената с-

ма? Пример – с-ма за пътническа агенция може да

има ниска бизнес стойност заради широкото разпространение на WEB-базираното поръчване на билети


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


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


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

Фактор Въпроси

Разбираемост Колко трудно е да се разбере сорс кода на с-мат? Колко са сложни използваните управляващи структури? Имената на променливите мнемонични ли са?

Документация Каква документация на с-мата съществува? Дали документацията е пълна, актуална и непротиворечива?

Данни Има ли явен модел на данните? До каква степен има повтарящи се данни в различните файлове? Данните използвани в с-мата актуални и непротиворечиви ли са?

Ефективност Адекватно ли е изпълнението на програмата? Дали проблемите на ефективността се отразяват в/у крайните потребители?


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

Програмен език Има ли модерни компилатори за програмния език, използван в разработката на с-мата? Използва ли се още програмния език за разработка на нови с-ми?

Управление на конфигурацията

Дали всички версии на всички части на с-мата са управлявани от с-ма за управление на конфигурацията? Има ли явно описание на версиите на компонентите, използвани в съществуващата с-ма?

Тестови данни Съществуват ли тестови данни за с-мата? Има ли записи от регресивни тестове, когато са добавяни нови функции?

Умения на персонала Има ли хора, притежаващи умения да поддържат приложението. Само няколко ли са хората, които разбират с-мата?


Измерване на с-мата

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

интерфейси, използвани от с-мата• Обем на данните, използвани от с-мата.


Обобщение

Разработката и развитието на с-мата трябва да е един итеративен процес.

Законите на Lehman описва няколко интуитивни прозрения за развитието на с-мите.

Трите вида поддръжка са: оправяне на грешките. промяна на софтуера за ново обкръжение и осъществяване на нови изисквания.

За индивидуални с-ми, разходите по поддръжка обикновено надвишават тези за разработка,


Обобщение

Процесът на развитието се води от исканията за промени от поръчителите.

Преработката на софтуера се занимава с преструктурирането и наново документиране на софтуера, за да го направи по-лесн за промени.

Бизнес стойността на наследената с-ма и нейното качество трябва да определят стратегията за развитие.

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

Documents