Управување со софтверска конфигурација претставува употреба на стандарди и процедури и ги опфаќа следните области: започнување, еволуција, контролирање и следење на промените на софтверскиот продукт, и во фазата на неговиот развој и подоцна. Повеќе акцент се става на значењето на контролата при конфигурација кај управувањето со софтверскиот производ. Оваа поддисциплина на софтверското инженерство, е вклучена кај процесите за развој на софтвер и низ сите фази на животниот циклус на софтверот и негова задача е да бидат направени промени во постоечката документација, без притоа да се наруши интегритетот на софтверот.[1][2]
Управувањето вклучува четири активности :
- Изработка на план за управување со конфигурација
- Управување со промени
- Управување со верзии
- Градење системи
План за управување со софтверската конфигурација
Планoт за управување со софтверска конфигурација за одреден проект треба да биде усогласен со организациската содржина и ги опишува стандардите и чекорите кај управувањето. Тој план треба да ги има следните делови:[3]
- План за тоа кои единици ќе бидат опфатени при конфигурацијата и како ќе бидат избрани
- Назначување на одговорно лице за водење на процедурите при конфигурација.
- Опишување на постапките кои ќе се користат при управувањето со конфигурацијата и уредувањето на верзии.
- Опис на документите кои ќе бидат создавани при конфигурацијата.
- Дефинирање на алатките кои ќе се користат за управување.
- Опишување на базата на податоци за тоа како ќе се чуваат податоците во неа.
Управување на промени
При секоја промена што се прави мора да се води евиденција и да се документира, во спротивно може фазата на одржување на софтверот, па и останатите фази, да излезат од контрола и тешко да се спроведуваат. Сепак пред да се одобри некоја промена на системот потребно е за истата да има објаснување, односно која е причината, дали е по барање на клиентот или пак се прави како резултат на некој недостаток.[4]
Управување со верзии
Управувањето со верзии ни овозможува идентификација и евиденција на различните верзии кои се направени над еден систем. Верзијата претставува примерок на системот, што се разликува од останатите примероци. Нешто што мора да се обезбеди при секоја верзија е да се има уникатна идентификација. Обично секоја верзија идентификува со броеви на пример: верзија 1.0, верзија 1.1, верзија 2.0 итн. Постојат и други начини на идентификација како идентификација одредена од својствата, идентификација ориентирана на промени, но сепак идентификацијата со броеви е најчеста и најдобро прифатена.[5]
Градење на системи
Градењето на системи претставува процес во кои се компајлираат и поврзуваат компонентите во програмата која треба да се извршува на одредена целна конфигурација. Прашањата што требаа да се имаат предвид се:
- Дали според инструкциите за градење се вклучени сите предвидени компоненти (модули, заглавие, библиотеки и друго)?
- Дали инструкциите за градење ја вклучуваат соодветната верзија на секоја компонента?
- Дали сите датотеки со податоци се пристапни?
- Доколку се повикува некоја податотека со податоци, дали името на податотека е точно и таа податотека постои со тоа име?
- Дали соодветната верзија на компајлерот и компатибилна со алатките? [3]
Наводи
