Поддршка и одржување на софтвер
Од Википедија, слободна енциклопедија
На оваа статија ѝ е потребно правилно форматирање, категоризирање, граматика, интервики и слично. Може да помогнете со тоа што ќе ја уредите и трансформирате во стандардна вики-статија.
За време на неговиот живот, софтверот ќе биде подложен на притисоци за извршување на одредени негови измени. Овие настојувања се неизбежни последици предизвикани од неговата природа и менливата средина во која тој функционира. Еден метод за намалување на непосакуваното влијание на одредена промена е да се дизајнира, развие, и одржува систем, на начин кој ќе овозможи полесно извршување на промени во него, во однос на нивното влијание на остатокот од системот. Овој процес е познат како изолација на промената. Методите достапни на дизајнерите се во опсег од методи за конструкција на објекти на ниво на кодирање, па до методи на бизнис ниво, за купување на продукти кои се надвор од полиците (пурцхасе оф цоммерциал офф тхе схелф продуцтс).
Со користење на методот на изолација на промената може:
- Да се намалат трошоците за оддржување.
- Да се продуцира модуларен дизајн кој е полесен за разбирање.
- Да се намали структуралната нарушеност (струцтурал децаѕ).
- Да се продолжи животниот век на системот (сѕстем лифеспан).
- Да се спречи на подолг период замената на системот со друг систем.
- Да се овозможи повторна употреба на модулите и компонентите.
Во минатото системите биле конструирани на ад-хок начин, со поединечно развивање, немајќи заедничка стратегија која ќе овозможи најдобро искористување на ресурсите за поддршка. Стратегија, која се фокусира на долгорочната поддршка на системите, отколку чисто брз развој (рапид девелопмент), е дизајнерска цел за која вреди да се потроши време од архитектонска и финансиска гледна точка.
Содржина |
[уреди] Историска перспектива
Во минатото процесот на оддржување на софтверот не бил истакнуван како важен критериум во процесите на продуцирање или прифаќање. Па и покрај тоа софтверското одржување е најскапиот дел од животниот циклус на еден софтвер. Само во 2004 големите бизнис корпорации, организации и сл. потрошиле £450 милијарди за оддржување на нивните ИТ системи.
Бизнис системите создадени пред 15-20-тина години сé уште се во функција и служба и претрпеа многу генерации на измени. Овие системи денес се практично неодржливи, поради константната примена на измени и поради загубата на оригиналните дизајнери во работната сила.
Многу наследни системи имаат потреба од опсежни, темелни истражувања за да останат конкурентни, но и покрај тоа, овие апликации сé уште ги исполнуваат бизнис функциите. Заради овие причини многу менаџери немаат желба да го посветат времето и потребните ресурси за да ги упдате-уваат овие системи. На застарени системи, модификацијата троши и дополнително време за истражувања, бидејќи релевантната документација е некомплетна. Непознавањето на изградбата, исто така, прави да разбирањето и спротивното (реверзибилно) инженерство да трошат дополнително време.
Дури и најмалата промена може да предизвика целиот систем да падне, а може и да ги дисбалансира претходните генерации на промени што биле применети. Во кратки зборови кажано, наследените системи кои се инсталирани во големите корпорации често предизвикуваат доста трошоци за да се оддржуваат. Тие се рестриктивни на корпоративно развивање, бидејќи тие не можат брзо да реагираат на промените на побарањата.
[уреди] Трошоците за одржување на системите
ИЕЕЕ стандардот за одржување на софтвер (СТД 1219-1993) го дефинира одржувањето како:
Модификација на софтверскиот продукт по испораката со цел да се корегираат грешките, да се подобрат перформансите или други атрибути, или да се адаптира продуктот на модифицираната или променета средина.
Оваа дефиниција кажува дека одржувањето започнува по испораката, но ова не спречува софтверот да се подготвува за одржување пред неговата испорака.
Минатите истражувања даваат до знаење дека најголемите трошоци на софтверска продукција се појавуваат по завршување на фазата на развој - учествувајќи со над 70% од вкупните трошоци.
Може да се каже дека ова трошливото одржување е резултат од лошото собирање информации за побарувањата и потребите и лошиот дизајн. Да претпоставиме дека е можно да се создаде совршен систем, кој потполно одговара на потребите и системот да е т.н. “ригхт фирст тиме”. Дали со користење на денешните најдобри практики би се намалиле трошоците за одржување?
Се знае дека промената е неизбежна, некои причини се:
- Политички одлуки (на пр. воведување на некој нов данок).
- Промени поврзани со хардверот.
- Промени во оперативниот систем.
- Конкуренција (цомпетитион) - нови одлики кои се додаваат.
Оддржување кое предизвикува големи трошоци, не постои само заради лошиот дизајн, туку и заради променливите побарувања на муштериите или барањата на средината и начинот на кој системот бил изграден.
Градбата, поради тоа, може да не влијае на функцијата, но мошне многу влијае на одржливоста во иднина. Со други зборови, постојат добри методи и лоши методи кои можат да бидат искористени за градење на системи ако процесот на изолација на промената е дизајнерската цел.
[уреди] Процесот на промена
Како што се вршат модификации на системот, така и дизајнот се менува. Тоа може да биде мало дизајнерско отстапување од иницијалниот концептуален правец, или може да биде перфективно одржување. Дури и ако строги основни напатствија за проекти и процеси се адаптирани, дизајнот ќе отстапи од неговиот иницијален концепт.
Овој ефект е опишан како структурална нарушеност. Системот може сé уште да им излегува во пресрет на потребите, но веќе тоа не го прави на начин одреден од системските иницијални спецификации (особини). Тој ќе користи помалку ефикасни механизми од оние што оригиналните дизајнери ги избрале.
Ако се дозволува структуралната нарушеност да продолжи неконтролирано т.е. да не се спречува, без процедури, документација и дизајн кој поддржува промени, софтверот ќе стане неекономски за одржување. Во тој момент често се прави решение за замена на системот. За да се осигура успех, замената треба да ги добие:
- Свежите информации за потребите и побарувањата,
- Примена на најновите алатки,
- Најновите дизајнерски методологии и најдобрите практики.
Постојат невидливи трошоци кои, ако не се земат во предвид, можат да предизвикаат замената на системот да стане неочекувано скапа. Еве некои примери:
- Заборавени процеси. Самиот систем станува процес. Иницијалниот дизајн бил изменет преку одреден број на генерации на измени, а не постои друга документација со која ќе се поддржат бизнис процесите.
- Проблематично реверзибилно инженерство. Иако постојат алатки и процеси за да се здобие системската функционалност, резултатот не секогаш ги застапува сегашните потреби - туку приближна претстава за раните побарувања.
- Скриени вложувања. Уште од периодот на иницијалниот развој, тимот за поддршка може да инвестирал многу многу години за ускладување на системот за да се обезбеди подобрена функционалност, перформанси и особини.
- Системско прочистување (облагодорување). Новиот систем ќе треба да еволуира од неговата прва испорака. Овој процес е растечки и може да се одвива неколку години за да се комплетира.
Јасно е дека е од голем бенефит ако системите се дизајнирани за да над нив може се извршуваат промени, со користење на методи кои ќе дозволуваат да се прават модификации на контролиран начин.
Структуралните нарушувања тогаш би биле намалени, трошоците за одржување, исто така, би биле намалени и системот едноставно би траел подолго.
[уреди] Издавање на нова верзија на софтверот
Во една вообичаена средина за развој на софтвер, развојната организација или тимот би требало да имаат некои механизми за документирање и следење на грешките и недостатоците на софтерскиот продукт. Софтверот, исто како и повеќето други продукти, е вообичаено издаден со множество на познати грешки и недостатоци. Тој се издава со недостатоците, бидејќи, развојната организација проценила дека функционалноста, употребливоста и вредноста на софтверот на одредено ниво на квалитет, го надминува влијанието на познатите грешки и недостатоци.
Познатите проблеми и спорни точки, се документираат вообичаено во писмо за управувачки размислувања кои треба да се земат во предвид (оператионал цонсидератионс) или белешки за издадениот продукт, па така корисниците на софтверот ќе бидат во можност да се справат донекаде со познатите проблеми и ќе знаат кога софтверот би бил несоодветен за одредени задачи.
И самите корисници можат да детектираат некои нови грешки и недостатоци и да го известат развојниот тим за тоа, па тие грешки и недостатоци да се додадат во познатите.
Нова верзија на софтерот се издава кога развојниот тим ќе реши одреден број на проблеми со софтверот или ќе додаде нови карактеристики или ќе изврши некои други промени и ќе увиди дека е погодно да се издаде нова верзија на софтверот.
