а б розвиватися з найменшими витратами при внесенні змін в систему в міру її освоєння і старіння. Необхідно прогнозувати термін заміни застарілої системи на принципово нову.
Процес програмування необхідно планувати, контролювати і завершувати в задані терміни. Крім того, робота програмістів повинна бути оплачена за результатами їхньої праці: його якістю, кількістю, інтенсивності виконання робіт; стимулювати високі результати праці. Для перерахованих цілей часто використовують нормативи, щоб порівнювати і оцінювати плановані і фактичні результати.
З цією метою на перших етапах проектування слід виконувати укрупнені розрахунки трудомісткості робіт зі створення програмного забезпечення автоматизованих систем (підсистем, задач) з метою прогнозування термінів робіт, витрат на їх виконання, оцінки передбачуваної економічної ефективності автоматизації.
Відомо кілька нормативних методів укрупнених розрахунків трудомісткості робіт по створенню систем (завдань):
- порівняльний (метод аналогів), коли трудомісткість нових розробок приймають по досвідченим даним подібних розробок з використанням поправочних коефіцієнтів;
- метод емпіричних залежностей, заснований на застосуванні нормативів у вигляді математичних залежностей шуканого показника (трудомісткості, вартості робіт) від технічних параметрів об'єкта розробки (наприклад, показника складності програм);
- метод прямого рахунку, заснований на визначенні змісту та обсягів робіт та використанні нормативів на окремі одиниці робіт. Нормативи цього методу можна розділити на об'ємні, що характеризують передбачувані обсяги робіт (наприклад, кількість операторів у програмі, кількість вхідних і вихідних форм в задачі і т.п.), і ресурсні, що визначають трудомісткість типових одиниць роботи;
- метод структурних коефіцієнтів, заснований на використанні нормативів структури показників аналогічної розробки, наприклад, розподіл трудомісткості створення завдання по різним етапам робіт. При цьому трудомісткість загальна або окремого етапу повинна бути визначена попередньо яким-небудь іншим методом. Метод структурних коефіцієнтів завжди застосовують у комплексі з іншими.
Різноманітність методів пояснюється різними можливостями отримання вихідних даних про плановані роботах, наявністю відповідних нормативів, потребами деталізації і точності розрахунків. На перших етапах створення оригінальних розробок застосовують, як правило, самі укрупнені розрахунки трудомісткості робіт (а також витрат і економічної ефективності), а в міру деталізації проектних рішень деталізують, уточнюють і ці розрахунки.
Аналіз різних підходів до нормування процесу програмування показує, що в якості основного фактора слід приймати розмір вихідного тексту програмного забезпечення (для будь-якого типу програмного забезпечення).
Для швидкої наближеної оцінки трудомісткості і тривалості, розробки програмного забезпечення може використовуватися і так звана базова модель .
При цьому витрати праці (трудомісткість розробки програмного забезпечення) оцінюють таким чином, чол/міс.:
(6.1)
де N ик - число вихідних команд, тис.,
а тривалість розробки і , міс .:
(6.2)
Продуктивність праці групи розробників програмного виробу П р (вих. команд/люд.-міс.) визначається формулою:
(6.3)
Середнє число виконавців Ч І розраховують виходячи з певних або заданих характеристик трудомісткості і тривалості розробки програмного продукту, чол .:
(6.4)
Якщо відомі з досвіду роботи або задані за нормативами витрати праці на підготовку опису завдання, дослідження алгоритму розв'язання задачі, розробку блок-схеми алгоритму, програмування, налагодження програми на ЕОМ, підготовку документації по завданню, то трудомісткість розробки програмного забезпечення можна розрахувати за формулою:
(6.5)
де ti - трудомісткість i-го етапу.
При оцінці витрат праці на розробку програмного забезпечення припускають, що створення програмного забезпечення - процес творчий і точно витрати визначити неможливо. Тому слід використовувати поправочні коефіцієнти (таблиця 6.1) для корекції трудовитрат ti. Для цього номінальні трудовитрати t н множать на відповідні коефіцієнти R (табл. 6.1), тобто
(6.6)
де.
Вплив на t (формула (6.1)) числа тисяч вихідних команд зниж...
