Управување со софтверска конфигурација претставува употреба на стандарди и процедури и ги опфаќа следните области: започнување, еволуција, контролирање и следење на промените на софтверскиот продукт, и во фазата на неговиот развој и подоцна. Повеќе акцент се става на значењето на контролата при конфигурација кај управувањето со софтверскиот производ. Оваа поддисциплина на софтверското инженерство, е вклучена кај процесите за развој на софтвер и низ сите фази на животниот циклус на софтверот и негова задача е да бидат направени промени во постоечката документација, без притоа да се наруши интегритетот на софтверот.^[1][2]

Управувањето вклучува четири активности :

• Изработка на план за управување со конфигурација
• Управување со промени
• Управување со верзии
• Градење системи

Планoт за управување со софтверска конфигурација за одреден проект треба да биде усогласен со организациската содржина и ги опишува стандардите и чекорите кај управувањето. Тој план треба да ги има следните делови:^[3]

• План за тоа кои единици ќе бидат опфатени при конфигурацијата и како ќе бидат избрани
• Назначување на одговорно лице за водење на процедурите при конфигурација.
• Опишување на постапките кои ќе се користат при управувањето со конфигурацијата и уредувањето на верзии.
• Опис на документите кои ќе бидат создавани при конфигурацијата.
• Дефинирање на алатките кои ќе се користат за управување.
• Опишување на базата на податоци за тоа како ќе се чуваат податоците во неа.

При секоја промена што се прави мора да се води евиденција и да се документира, во спротивно може фазата на одржување на софтверот, па и останатите фази, да излезат од контрола и тешко да се спроведуваат. Сепак пред да се одобри некоја промена на системот потребно е за истата да има објаснување, односно која е причината, дали е по барање на клиентот или пак се прави како резултат на некој недостаток.^[4]

Управувањето со верзии ни овозможува идентификација и евиденција на различните верзии кои се направени над еден систем. Верзијата претставува примерок на системот, што се разликува од останатите примероци. Нешто што мора да се обезбеди при секоја верзија е да се има уникатна идентификација. Обично секоја верзија идентификува со броеви на пример: верзија 1.0, верзија 1.1, верзија 2.0 итн. Постојат и други начини на идентификација како идентификација одредена од својствата, идентификација ориентирана на промени, но сепак идентификацијата со броеви е најчеста и најдобро прифатена.^[5]

Градењето на системи претставува процес во кои се компајлираат и поврзуваат компонентите во програмата која треба да се извршува на одредена целна конфигурација. Прашањата што требаа да се имаат предвид се:

1. Дали според инструкциите за градење се вклучени сите предвидени компоненти (модули, заглавие, библиотеки и друго)?
2. Дали инструкциите за градење ја вклучуваат соодветната верзија на секоја компонента?
3. Дали сите датотеки со податоци се пристапни?
4. Доколку се повикува некоја податотека со податоци, дали името на податотека е точно и таа податотека постои со тоа име?
5. Дали соодветната верзија на компајлерот и компатибилна со алатките? ^[3]