Здійснити оцінювання і нормування праці керівників підрозділів, системних аналітиків, програмістів тощо, висококваліфікованих спеціалістів значно складніше. Для оцінювання праці цієї категорії робітників можна використовувати такі показники: дотримання термінів розроблення систем і програм; вивчення і практичне використання нових мов і методів програмування; створення ретельно відпрацьованих інструкцій, що полегшують використання програм; схвалення роботи з боку користувачів. Питання нормування праці за програмування є дуже важливим для планування, обліку, аналізу та оперативного управління діяльністю фірми. Створення відповідних норм і нормативів витрат праці — дуже складний процес насамперед через те, що програмування — творча праця, а також тому, що в програмуванні однієї задачі можуть брати участь фахівці різних професій і категорій: наукові працівники, математики, інженери-технологи, економісти, техніки, оператори. Крім того, продуктивність праці залежить від багатьох факторів, урахувати які важко. Це: логічна складність розроблюваної задачі; кваліфікація програміста; мова програмування; математичне забезпечення ЕОМ; система команд та адресність ЕОМ тощо. Тому в практиці нормування праці при програмуванні не використовують такий показник, як норма виробітку, а встановлюють норму часу (тривалість) на виконання певного завдання та його трудомісткість. На теперішній час існує кілька підходів до оцінювання тривалості і, відповідно, трудомісткості розроблення програмного забезпечення. Для них основним фактором, який впливає на час і трудомісткість, є складність розроблюваної системи. Залежно від способу оцінювання впливу цього фактора в розрахункових моделях їх можна згрупувати так: найпростіші методи, засновані на оцінюванні загального числа операторів (рядків, команд) у початкових текстах програм; методи, засновані на інших характеристиках складності. Як приклад першої групи методів розглянемо так звану модель СОСОМО — (Constructive Cost Model), а другої — метод функціональних балів — (Function Point Analysis, (FPA). Модель СОСОМО. Починаючи з середини 1970-х років у США постійно здійснюється збирання статистичних даних про зовнішні техніко-економічні показники розробок інформаційних систем, насамперед тих, які виконуються за держзамовленнями. Вони стали основою для досліджень з метою виявлення основних закономірностей, що дають змогу прогнозувати тривалість і витрати на розроблення ІС. Спочатку роботу зі збирання цих даних здійснювали у різний час групи дослідників, які отримували фінансову підтримку від управлінь військового відомства. Нині цю діяльність зосереджено в рамках Інституту програмної інженерії (Software Engeeniring Institute, SEI), що є, як відомо, головним науковим центром [53]. Попервах було запропоновано таки загальну модель для оцінювання трудомісткості проектів ІC [130]: Е = (а + b ( S c) ( m(Х), (18.1) де Е — трудомісткість; а, b, с — константи; S — оцінка складності розроблюваної ІС, виражена в тисячах рядків початкового програмного коду; m(Х) — нелінійна функція вектора інших параметрів проекту X. Однак незабаром з’ясувалося, що навіть у такому загальному вигляді неможливо побудувати єдину модель, придатну для будь-якої ІС. Це пояснюється тим, що техніко-економічні показники для різних класів ІС характеризуються дуже великим розсіюванням. Тому Б. Боемом [9] було запропоновано вдосконалений варіант моделі (18.1), яка отримала назву СОСОМО (Constructive Cost Model). Залежно від характеру проекту в ній використовують різні значення параметрів. Для цього виділено такі три класи ІС: прості, складні та середньої складності (проміжні). Прості системи порівняно невеликі за розміром, характеризуються відсутністю жорстких обмежень, не містять принципово нових технічних рішень і розробляються в умовах стабільних і чітко сформульованих вимог замовника. Складні ІС, як правило, є вбудованими у великі об’єкти, функціонують у реальному масштабі часу, в них широко застосовуються нові методи та алгоритми, вони повинні відповідати жорстким обмеженням, а вимоги до них змінюються та уточнюються під час розроблення. Проекти третього класу посідають проміжне місце. Власне кажучи, метод СОСОМО — це ієрархія моделей у порядку зростання деталізації та точності. Основне розрахункове співвідношення моделі, запропонованої Боемом, для трудозатрат (у людино-місяцях) таке: . (18.2) Значення параметрів аi, оцінені за відомими статистичними даними, залежно від класу ІС установлюють рівними 2,4, 3,0 і 3,6 відповідно для простих, середніх (проміжних) і складних систем. Параметру bi надають значення: 1,05, 1,12 і 1,20. Вектор Х містить 15 параметрів, а функція m(Х) є добутком 15 коефіцієнтів трудомісткості, відповідних кожному з параметрів. Передбачається, що в деяких усереднених умовах кожний коефіцієнт дорівнює одиниці. Вплив відповідних факторів на трудозатрати враховують шляхом добору значень цих коефіцієнтів. Фактори вибрані таким чином, що їх взаємним впливом можна знехтувати. Їх можна звести в чотири групи, що характеризують: властивості ІС (вимоги до надійності, складність бази даних, загальна складність системи); властивості обчислювальної системи (наявність обмежень на час вирішення задач і на об’єм пам’яті, а також необхідність забезпечення перенесення програм на різні типи ЕОМ); колектив розробників (наявність кваліфікованих проектувальників, досвід роботи в заданій предметній області, наявність програмістів, досвід роботи з системою програмування та апаратурою); технологія (використання передових методів розроблення програм, застосування CASE-засобів, якість планування робіт). На основі накопичених статистичних даних для кожної з цих груп розраховано діапазони значень відповідних коефіцієнтів і розроблено методику визначення їх в умовах конкретних проектів. Крім прогнозування трудозатрат, метод СОСОМО дає змогу оцінювати тривалість розроблення ІС. Її розраховують за формулою , (18.3) де Т — тривалість у місяцях. Значення параметра Сi для простих, середніх і складних проектів установлюють відповідно рівними 0,38; 0,35 і 0,32. Цю модель розроблено Б. Боемом на основі статистичних даних, накопичених в 1960—1970 рр. в основному фірмою TRW (розробником систем ракетно-космічної оборони). Перевірка її, виконана пізніше на шести інших сукупностях статистичних даних [130], показала, що для різних вибірок від 17% до 67% оцінок, отриманих з її допомогою, мають відносну погрішність не більшу за 25%, тобто модель має точність, яку не завжди можна визнати задовільною. Конкретні значення параметрів моделі СОСОМО, що використовуються для прогнозування витрат на створення ІС, можна знайти в літературі [9]. Але за час, що минув після перших публікацій, присвячених цій моделі, технологія проектування ІС значно змінилася на краще. Тому наведені дані, ясна річ, вже застаріли. У той же час, в літературі відсутні відомості про уточнені значення параметрів і структури методу СОСОМО, проте є відомості, що він, як і раніше, є основним у плануванні розробок на замовлення Міністерства оборони США [53]. Наведені вище результати, що характеризують точність прогнозування, стосуються раннього етапу застосування цієї моделі в умовах, коли не враховувалися специфічні особливості фірми-розробника. За останні 10 років, у зв’язку з введенням в дію системи атестування технологічної зрілості організації-розробників, вже з’явилися фірми, які характеризуються 4—5 рівнями зрілості. У таких фірмах має бути налагоджена власна система накопичення та аналізу статистичних даних, що дає змогу одержувати набагато достовірніші оцінки. Моделі прогнозування, засновані на методі, аналогічному СОСОМО, розповсюджуються на комерційній основі і прив’язуються до специфіки організації-розробника. При цьому фірми не розкривають конкретні значення параметрів моделі, оскільки це може бути використано конкурентами. Отже, модель СОСОМО у дещо вдосконаленому вигляді досить широко використовується в США в організаціях, що характеризуються достатньо високим рівнем технологічної зрілості. Однак відомостей про точність отримуваних прогнозів і конкретні удосконалення методу в доступних джерелах немає. Можна припустити, що вони є комерційною таємницею. На теренах СРСР в 1978—1986 рр. під керівництвом В. В. Ліпаєва також проводилися дослідження методів прогнозування витрат на створення ІС і було розроблено модель, засновану приблизно на тих самих ідеях, що і СОСОМО [70], але яка базувалася на вітчизняному матеріалі. Усі програми для обчислювальних машин В. В. Ліпаєв поділив на три класи. До першого класу ним віднесено програми, що розробляються для розв’язування окремих інженерних і науково-дослідних задач, які характеризуються малим використанням ресурсів обчислювальних систем і відносно коротким часом експлуатації. Ці програми носять експериментальний характер, не передбачають тиражування та промислового впровадження. Другий клас представлено складними комп’ютерними програмами інформаційно-довідкових систем, систем автоматизації проектування, оброблення інформації організаційного спрямування тощо, які функціонують не в реальному масштабі часу. Ці програми не повністю використовують ресурси обчислювальних систем, можуть тиражуватися та передаватися користувачам як готові виробі — програмні засоби. До третього класу віднесено програми автоматичного або автоматизованого управління, що безпосередньо входять до системи управління та функціонують в реальному масштабі часу. Такі програми практично повністю використовують ресурси обчислювальних машин, доповнюються документацією і багато років і навіть десятиліть експлуатуються та поетапно модернізуються як вироби. Виходячи з такого розподілу й проводиться аналіз витрат часу на розроблення їх. Основні вдосконалення стосувалися складу факторів, урахованих у моделі. Вона більш детальна, причому вплив деяких факторів враховується інакше, ніж в моделі Боема. Інших досліджень аналогічного масштабу на теренах СРСР в цьому напрямі не велося. Методу СОСОМО та аналогічним йому методам притаманна ціла низка вад. Основна вада є наслідком того, що для оцінювання витрат і тривалості розроблення необхідно мати оцінку складності ІС, виражену через число команд або операторів програми. Основні аргументи проти використання цієї характеристики складності такі: точне число операторів програми стає відомим лише у кінці розроблення, а розрахунки треба виконувати значно раніше — після складання технічного завдання; написання програм є лише невеликою частиною всіх трудозатрат і тому число операторів не характеризує їх повністю; у разі використання декількох різних мов програмування складно визначити кількість операторів, особливо для непроцедурних мов; далеко не завжди зрозуміло, як здійснювати підрахунок (наприклад, чи треба враховувати коментарі та оголошення змінних тощо); не всі розроблювані програми входять до комплекту постачання (наприклад, програми, що забезпечують налагодження та випробування). Тому були зроблені спроби відійти від кількості операторів програми як міри складності ІС і використати інші метрики. Одним з підходів, що набув досить значного поширення, є метод функціональних балів (Function Point Analysis, — FPA). Метод функціональних балів (FPA). Відомо, що до моменту завершення розроблення ТЗ на створення ІС у проектній документації є низка параметрів, значення яких характеризують складність системи. До цих параметрів можна віднести кількість: класів інформаційних об’єктів; атрибутів інформаційних об’єктів; функціональних задач (інформаційних та обробки); вхідних і вихідних змінних кожної задачі. Цей список може бути продовжений. Очевидно, що кожний з зазначених параметрів якось характеризує складність, тобто зі зростанням його значення, за інших рівних умов, складність, а з нею трудомісткість і тривалість розроблення ІС зростають. Питання полягає тільки в тому, яким чином агрегувати ці параметри в одному такому показникові, як трудомісткість. У виборі одного з можливих способів агрегування їх і полягає сутність методу функціональних балів (Function Point Analysis, FPA), уперше було запропоновано у [128]. Він призначений для більш вузького класу систем, ніж метод СОСОМО: FPA орієнтований на системи, що містять у своєму складі досить складні бази даних. Порівняно з СОСОМО метод FPA має вужчу спрямованість, оскільки він призначений тільки для оцінювання складності ІС, а не трудомісткості чи тривалості, тобто в ньому не враховуються фактори, безпосередньо пов’язані з процесом розроблення та реалізації, які враховує модель СОСОМО. По суті, метод FPA дає змогу оцінити тільки значення параметра, яке можна було б підставити у формули (18.1) або (18.2) замість довжини програми S. Розглянемо найпростіший варіант цього методу. В якості вхідних даних для оцінювання складності розроблюваної ІС використовують п’ять параметрів: число форм вхідних повідомлень — Inp; число форм вихідних повідомлень — Out; число інформаційних задач — Inq; число головних файлів — Maf; число інтерфейсів — Inf. Порівнюючи цей перелік з попереднім, можна помітити їх схожість і деякі відмінності. Так, число головних файлів є не що інше, як число класів інформаційних об’єктів, які мають зв’язки з іншими класами типу 1:М. Тобто, в цьому параметрі агреговано не тільки число класів, а й складність зв’язків між ними. Задачі обробки не представлені явно, але легко пересвідчитися, що їх число непрямо відображене в кожному з параметрів, тобто додання цього параметра тільки призведе до надмірності. Складність системи оцінюють у так званих функціональних балах за формулою FP = UFP ( TСF, (18.4) де перший співмножник характеризує логічну складність, виражену в балах, а другий є поправковим коефіцієнтом, що враховує інші фактори, від яких залежить складність системи. Логічну складність розраховують за формулою UFP = а ( Inp + b ( Out + с ( Inq + d ( Mat + е ( Inf, (18.5) де значення кожного з коефіцієнтів — a, b, с, d, е — встановлюють залежно від складності відповідного елементу ІС (табл. 20.1). Другий співмножник у (20.4) розраховують за формулою TCF = 0,65 + 0,01 ( DI, (18.6) де коефіцієнт DI (Degree of Influence) — це сума таких 14 зведених показників: наявність і складність телекомунікації; розподілене оброблення; особливі вимоги до якості; ступінь використання ресурсів обладнання; частота транзакції; діалоговий режим уведення даних; особливі вимоги до ефективності роботи кінцевих користувачів; діалоговий режим оновлення даних; наявність складних алгоритмів оброблення; можливість повторного використання компонентів системи; простота розгортання системи; зручність експлуатації; переносимість на інші платформи; простота супроводження. Кожному з наведених показників проектувальник присвоює оцінку з діапазону від 0 до 5, отже, параметр D1 може мати значення від 0 до 70, а коефіцієнт TCF — відповідно від 0,65 до 1,35. Таблиця 20.1 ВАГОВІ КОЕФІЦІЄНТИ ЛОГІЧНОЇ СКЛАДНОСТІ Елемент системи Міра складності елемента системи мала середня висока Вхідне повідомлення 3 4 6 Вихідне повідомлення 4 5 7 Інформаційна задача 3 4 6 Головний файл 7 10 15 Інтерфейс 5 7 10
Як видно, склад враховуваних факторів і спосіб обчислення їх досить суб’єктивні. Незважаючи на це, численні дослідження показали, що оцінка складності, виражена функціональними балами, значно краще відображує справжній стан речей, ніж кількість операторів програми. Проте і тут ще є місце для вдосконалення моделі FPA. Хоча в спеціально підібраних прикладах оцінка трудомісткості із застосуванням кількості операторів в найгіршому випадку дала відносну помилку 800%, а за методом FPA — «лише» 200%, це також є абсолютно незадовільним [53]. Недосконалість моделі FPA досить добре видно навіть з наведеного вище переліку факторів, враховуваних за розрахунку значення параметрів DI. Двократне врахування діалогового режиму як фактора, що впливає на складність, можна віднести до часів, коли процедури діалогової взаємодії було важко проектувати і реалізувати програмно. Це свідчить про те, що розглянута вище модель FPA потребує вдосконалення. Поліпшений варіант цього методу детально викладено у [137]. Як видно з публікацій, метод FPA досить широко використовується по обидва боки Атлантики. Існує Асоціація користувачів методу (FPA Users Group), яка регулярно проводить робочі зустрічі та конференції, що сприяють обміну інформацією між фахівцями та вдосконаленню методу. У Великобританії під егідою ССТА видано методичні вказівки щодо застосування FPA для прогнозування витрат і тривалості розроблення ІС. Усе це підтверджує, що метод FPA постійно вдосконалюється і має важливе практичне значення. Отже, з розглянутого вище, випливає, що на теперішній час вже виявлено склад основних факторів, які визначають тривалість, трудомісткість і вартість розроблення ІС, а також вивчено характер їх впливу. Як правило, залежності економічних показників від цих факторів порівняно прості і для їх повного опису досить вказати значення невеликої кількості параметрів (найчастіше — одного, рідше — до трьох-чотирьох). Основна складність полягає в тому, щоб оцінити ці параметри, тобто зробити калібрування моделі. Як показує практика останніх років, найточніші результати прогнозування дає калібрування, що виконується всередині організації-розробника з урахуванням її особливостей і, зокрема, характеру проектів ІС, на розробленні яких вона спеціалізується. Однак для проведення такого калібрування необхідно, щоб організація мала досить високу технологічну культуру і достатній обсяг накопичених статистичних даних. Якщо цих умов не додержано, доводиться задовольнятися результатами калібрування моделі, виконаними для інших організацій, що може різко знизити точність прогнозування. Іншими словами, головною умовою є висока технологічна культура організації-розробника. В Україні, на жаль, нині лише незначна кількість фірм має відповідний рівень розвитку. Для встановлення норм витрат праці на програмування деякі з фірм-розробників використовують Типові норми часу на програмування задач для ЕОМ [105], та Укрупнені норми часу на розроблення програмних засобів ОТ [110], затверджені у 1986 р. Держкомітетом СРСР з питань праці та соціальних питань. Розглянемо особливості нормування праці розробників ІС з використанням цих нормативних документів.
Ви переглядаєте статтю (реферат): «Методичні засади нормування праці програмістів» з дисципліни «Економіка та організація інформаційного бізнесу»
