Міфічний «людино-місяць» в програмотворенні

Щоб приготувати смачну їжу, потрібен час. Якщо вам довелося чекати, то лише тому, що ми прагнемо краще вас обслугувати і зробити вам приємність. Меню ресторану «Антуан» у Нью-ОрлеаніПрограмні проекти частіше провалюються через нестачу календарного часу, аніж по всіх інших причинах разом узятих. Чому ця причина невдач настільки поширена? По-перше, слабко розвинені наші методи оцінок. По суті, вони відбивають мовчазне й зовсім невірне припущення, що все буде йти добре. По-друге, наші методи оцінки помилково плутають досягнутий прогрес із витраченими зусиллями, неявно допускаючи, що швидкість виконання проекту пропорційна кількості зайнятих у ньому співробітників. По-третє, оскільки менеджери програмних проектів не впевнені у своїх оцінках, їм часто бракує «ввічливої впертості», як у шеф-кухаря ресторану «Антуан». По-четверте, виконання графіка робіт слабко контролюється. Випробувані в інших інженерних дисциплінах методи вважаються радикальними нововведеннями при розробці програмного забезпечення. У п'ятих, при виявленні відставання від графіка природньою й загальноприйнятою реакцією є збільшення числа розробників. Це однаково, що гасити полум'я бензином. У результаті справи йдуть значно гірше. В підсумку цей шлях приводить до катастрофи. Контроль виконання графіка буде предметом окремої розмови.Розглянемо більш докладно інші аспекти проблеми. Оптимізм Усі програмісти – оптимісти. Можливо, цей сучасний різновид чаклунства особливо привабливий для тих, хто вірить у хіпі-енди й добрих фей. Як би то не було, результат один: «Цього разу вона точно піде!» Або: «Я тільки що виявив останню помилку!», …Отже, в основі планування розробки програм лежить неправильне допущення, що кожне завдання займе стільки часу, скільки «повинно» зайняти. Глибокий оптимізм програмістів заслуговує більш серйозного вивчення. Дороті Сейєрс (Dorothy Cayers) у своїй книзі "Розум творця" ("The Mind of the Maker") виділяє у творчій діяльності три стадії: задум, реалізацію, взаємодію. Відповідно, книга, комп'ютер або програма спочатку виникають як ідеальна побудова, що існує не в часі й просторі, а лише в мозку свого творця. Реалізація ж у часі й просторі відбувається за допомогою пера, чорнила, паперу, або – проводів, кремнію й ферриту. Робота буде завершеною, коли хто-небудь прочитає книгу, скористається комп'ютером або запустить програму, тим самим вступивши у взаємодію з розумом їх творця. Загалом, для людини, яка щось створює, неповнота й суперечливість ідей виявляються тільки при їхній реалізації. Тому для теоретика виклад на папері, експериментування, виготовлення є невід'ємними частинами творчого процесу. У багатьох видах творчої діяльності матеріал із труднощами піддається обробці. Дерево колеться, фарби паскудяться, електричні кола «замикаються».Ці фізичні обмеження звужують коло ідей, які можуть бути виражені, а також створюють несподівані труднощі при реалізації. Реалізація, таким чином, вимагає сил і часу як через фізичний матеріал, так і через неадекватність основних ідей. Більшу частину труднощів при реалізації ми схильні пояснювати недоліками фізичного матеріалу, оскільки він «далекий» для нас – на відміну від ідей, якими ми пишаємося. При створенні ж програм ми маємо справу з надмірно податливим матеріалом. Програміст здійснює свої побудови на основі чистого мислення – власних понять і дуже гнучких їхніх представлень. Оскільки матеріал настільки податливий, то ми не очікуємо труднощів при реалізації. Звідси й глибокий оптимізм. Через помилковість наших ідей виникають помилки в програмах. Отже, наш оптимізм не має виправдання! Для окремого завдання допущення, що все буде добре, виявляє у графіку робіт імовірнісний ефект. Усе може дійсно йти за планом, оскільки є деякий розподіл імовірності для можливої затримки й існує кінцева ймовірність того, що затримки не буде. Однак великий програмний проект складається з безлічі завдань, частина з яких може бути почата тільки після закінчення інших. Імовірність того, що всі завдання будуть завершені в строк, нескінченно мала. Людино-місяць Друга помилка закладена в самій одиниці виміру, використовуваної при оцінюванні й плануванні – людино-місяць. Вартість дійсно виміряється як добутку числа зайнятих на кількість витрачених місяців. Але не досягнутий результат. Тому використання людино-місяця як одиниці виміру обсягу роботи є небезпечною оманою. Рис. 1 Залежність часу від числа зайнятих – завдання, що повністю розділяється. Число зайнятих і число місяців є взаємозамінними величинами лише тоді, коли завдання можна розподілити серед працівників, які не мають між собою взаємозв'язків, або коли вони є сингулярними (мал. 2.1). Це вірно, коли жнуть пшеницю або збирають бавовна, але в системному програмуванні це далеко не так. Рис. 2 Залежність часу від числа зайнятих – неподільне завдання Якщо завдання не можна розбити на частини, оскільки існують обмеження на послідовність виконання етапів, то збільшення витрат не впливає на графік (мал. 2.2). Багато завдань програмування відносяться до цього типу, оскільки налагодження по своїй суті носить послідовний характер. Рис. 3 Залежність часу від числа зайнятих – розподільне завдання, що вимагає обміну даними Для завдань, які можуть бути розбиті на частини, але вимагають обміну даними між підзадачами, витрати на обмін даними повинні бути додані до загального обсягу необхідних робіт. Тому найкращий потенційно досяжний результат, виявляється трохи гірше, ніж проста відповідність числа зайнятих і кількості місяців (мал. 2.3). Додаткове навантаження складається із двох частин – навчання й обміну даними. Кожного працівника потрібно навчити технології, цілям проекту, загальної стратегії й плану роботи. Це навчання не можна розбити на частини, тому дана частина витрат змінюється лінійно залежно від числа зайнятих. Рис. 4 Залежність часу від числа зайнятих – завдання зі складними взаємозв'язками З обміном даними справа ще гірша. Якщо всі частини завдання повинні бути окремо скоординовані між собою, то витрати зростають як n(n-2)/2. Для трьох працівників потрібно втроє більше попарного спілкування, ніж для двох, для чотирьох – ушестеро. Якщо крім цього виникає необхідність у нарадах трьох, чотирьох і т.д. працівників для спільного рішення питань, положення стає ще гіршим. Додаткові витрати на обмін даними можуть повністю знецінити результат дроблення вихідного завдання й привести до положення, описуваного малюнком 2.4. Оскільки створення програмного продукту є по суті системним проектом – практикою складних взаємозв'язків, витрати на обмін даними великі й швидко починають переважати над скороченням строків, що досягаються в результаті розбивки завдання на більш дрібні підзадачі. У цьому випадку залучення додаткових працівників не скорочує, а подовжує графік робіт. Системне тестування Із усіх елементів графіка робіт найбільшому впливу з боку обмежень на послідовність виконання дій піддаються налагодження компонентів і системне тестування. Крім того, витрати часу залежать від кількості виявлених помилок і від того, наскільки вони "сховані". Теоретично, помилок бути не повинно. Через свій оптимізм розробники звичайно схильні недооцінювати дійсну кількість помилок. Тому в програмуванні дотримуватися графіків робіт зазвичай найважче при етапі налагодження. Є просте емпіричне правило: 1/3 - планування, 1/6 - написання програм, 1/4 - тестування компонентів і попереднє системнетестування, 1/4 - системне тестування при наявності всіх компонентів. Це правило має кілька важливих відмінностей із загальноприйнятим плануванням: 1. На планування приділяється більше часу, ніж звичайно. І однаково цього часу ледь достатньо для розробки докладних і надійних технічних умов і недостатньо для проведення дослідницьких робіт або пошуку новітніх технологій. 2. Половина графіка робіт, відведена на налагодження закінченого коду, значно вище норми. 3. Та частина, яку легко оцінити, тобто написання коду, займає всього одну шосту загальний часу. Вивчаючи проекти, графік яких був складений традиційним образом, можна побачити, що лише деякі з них відводять за графіком половину часу на налагодження, але на практиці в абсолютній більшості випадків витрати на це займали як мінімум половину фактичного часу. Багато проектів укладалися в графік на всіх етапах, крім системного тестування.Особливо катастрофічні наслідки може мати недолік часу для системного тестування. Оскільки затримка відбувається в кінцевій частині графіка, ніхто не підозрює про те, що графік перебуває під загрозою зриву аж до дня здачі продукту. Погані звістки, отримані пізно й без попередження, ставлять в тупик клієнтів і менеджерів. Більше того, затримка на цьому етапі має особливо важкі матеріальні й психологічні наслідки. Проект здійснюється при повній укомплектованості працівниками й максимальних фінансових витратах. Що важливіше, програмне забезпечення повинне забезпечити підтримку іншої ділової активності (поставки комп'ютерів, запуску нових виробничих потужностей і т.п.), і пов'язані із затримкою вторинні витрати дуже високі. На практиці ці вторинні витрати можуть бути вище, чим усі інші. Тому дуже важливо у вихідному графіку робіт відвести досить часу для системного тестування. Боязкість в оцінках Для програміста, як і для кухаря, тиск із боку хазяїна може визначати лише запланований строк завершення завдання, але не може визначати час його фактичного завершення. Омлет, обіцяний через дві хвилини, може успішно жаритися, але якщо через дві хвилини він не готовий, то в клієнта є дві можливості: чекати ще або з'їсти його сирим. Той же вибір встає й перед замовником програмного забезпечення. У кухаря є ще одна можливість – додати жару. У результаті омлет часто виявляється безнадійно зіпсованим: горілим з одного краю й сирим – з іншого. Не факт, що в менеджерів програмних продуктів менше хоробрості або твердості, ніж у кухарів або інших менеджерів в інженерних областях. Але «липові» графіки, націлені на бажану хазяїну дату, зустрічаються тут значно частіше, ніж у будь-які інших інженерних областях. Дуже важко, ризикуючи втратити робоче місце, з енергією й люб'язністю відстоювати строк, який визначений без застосування яких-небудь кількісних методів при недоліку даних і підкріплений, в основному, інтуїцією менеджера. Очевидно, необхідно зробити дві речі. Ми повинні одержати й зробити загальнодоступними чисельні дані, що характеризують продуктивність, частоту програмних помилок, методи оцінки і т.д. Уся галузь може тільки виграти від опублікування таких даних. Поки методи оцінювання не одержать більш міцної основи, менеджерам залишається тільки мужатися й захищати свої прогнози, стверджуючи, що покладатися на їхню слабку інтуїцію все-таки краще, ніж ґрунтуватися на одних бажаннях. Дії при зриві графіка Що роблять, коли важливий програмний проект починає відставати від графіка? Природно, додають людей. Як показують малюнки 2.1-2.4, це не завжди допомагає. Розглянемо приклад 3. Припустимо, що трудомісткість завдання оцінюється в 12 людино-місяців, і три людини повинні виконати її за 4 місяця, причому наприкінці кожного місяця є чотири контрольні точки A, B, C і D, у яких можна зробити виміри (мал. 2.5). Рис. 5 Припустимо тепер, що перша контрольна точка була досягнута лише після закінчення двох місяців. Які альтернативи є в менеджера? 1. Допустимо, що необхідно дотримати строку виконання завдання, і помилково оцінена була тільки перша частина завдання, тобто малюнок 2.6 вірно відображає стан речей. Виходить, залишається 9 людино-місяців працезатрат і два місяці, тому знадобиться 4,5 людини, і до трьох наявних потрібно додати ще двох. Рис 6 2. Допустимо, що необхідно дотримати строку виконання завдання, і однаково занижена була вся оцінка, тобто положення відповідає малюнку 2.7. Виходить, залишається 18 людино-місяців працезатрат і два місяці, тому знадобиться 9 людей. До трьох наявних потрібно додати ще шістьох. Рис. 7 3. Змінити графік. П. Фаггом (P. Fagg), досвідчений інженер по обчислювальній техніці зробив влучне зауваження: "Маленьких затримок не буває". Це означає, що в новому графіку повинне бути досить часу, щоб робота була виконана ретельно й повністю, і не довелося б знову переробляти графік. 4. Скоротити завдання. На практиці цим завжди й кінчається, коли команда виявляє, що не укладається в графік. Коли дуже високі вторинні витрати, це єдине, що можна зробити. Менеджерові надається можливість офіційно й акуратно скоротити завдання, змінити графік, або спостерігати, як завдання мовчки урізується при поспішній зміні проекту й неповному тестуванні. У перших двох випадках наполягати на тому, щоб завдання в незмінному виді було виконане за чотири місяці, може призвести до катастрофи. Розглянемо, приміром, ефект першої альтернативи (мал. 2.8). Двоє нових працівників, якими б знаючими вони не були, і як би швидко не вдалося їх знайти, повинні вивчити завдання за допомогою одного з досвідчених розроблювачів. Якщо для цього буде потрібно місяць, то 3 людино-місяця будуть витрачені на роботу, яка не враховується у вихідній оцінці. Крім того, завдання, розбите спочатку на три потоки, повинне бути тепер перекроєне на п'ять частин. Тому частина вже зробленої роботи буде загублена, а системне тестування потрібно буде продовжити. У результаті наприкінці третього місяця залишиться роботи суттєво більше, ніж на 7 людино-місяців, а в розпорядженні буде 5 підготовлених людей і один місяць. Згідно з малюнком 2.8 продукт буде запізнюватися так само, як якби жодного людини не було додано (див. мал. 2.6). Якщо розраховувати впоратися за чотири місяці з обліком тільки часу навчання, але не перерозподілу завдань і додаткового системного тестування, то наприкінці другого місяця буде потрібно додати 4, а не 2 людини. Щоб компенсувати вплив перерозподілу завдань і системного тестування, будуть потрібні ще нові люди. Тепер, однак, команда складається не з 3, а, принаймні, 7 людей, і такі питання, як організація команди й розподіл завдань здобувають новий якісний рівень. Зверніть увагу, що до кінця третього місяця справа виглядає досить похмуро. Незважаючи на всі адміністративні зусилля контрольна точка, намічена на 1 березня, не досягнена. Виникає сильна спокуса повторити цикл, додавши ще людей. Це божевільне рішення! Рис. 8 У попередніх міркуваннях передбачалося, що тільки перша контрольна точка була невірно розрахована. Якщо 1 березня зробити консервативне припущення, що весь графік був занадто оптимістичний, як відображено на малюнку 2.7, потрібно додати 6 людей до вихідного завдання. Розрахунок впливу навчання, перерозподілу завдань і системного тестування надається в якості практичної вправи. Немає сумнівів, що при спробі укластися в строк у підсумку вийде гірший продукт, ніж при зміні графіка й збереженні первісних трьох людей без «посилення» команди. Украй спрощуючи, Брукс сформулював наступну тезу: Теза Брукса. Якщо проект не укладається в строки, то додавання робочої сили затримає його ще більше. Це розвінчує міф про людино-місяць. Тривалість здійснення проекту залежить від обмежень, що накладаються послідовністю робіт. Максимальна кількість розроблювачів залежить від числа незалежних підзадач. Ці дві величини дозволяють одержати графік робіт, у якому буде менше зайнятих розробників і більше місяців. (Єдина небезпека полягає, як було зазначено, в можливому старінні продукту.) Не можна, однак, скласти працюючі графіки, у яких зайнято більше людей і потрібно менше часу. Програмні проекти частіше провалюються через нестачу календарного часу, ніж по всіх інших причинах разом узятих. Редукційне середовище моделювання ієрархічних структур Ф.П. Брукс блискуче обґрунтував недієздатність екстесійних методів розробки СКІ. Об’ємне залучення нових працівників до проекту комплексної інформатизації дасть протилежний очікуваному результат. Необхідно занурити робітників в адекватне задачі середовище, що дозволить зробити іх працю більш продуктивною. В першу чергу за рахунок вивільнення кожного з них від задач, пов’язаних зі взаємодією між собою. Адже дана задача, як задача композиціонування окремих рішень підзадач в рішення основної задачі є найбільш важливою і разом з цим найбільш складною в проекті в цілому. Тому викрити логіку композиціонування та зробити її «загальним знаменником» організації ефективної співпраці окремих розробників – нагальна необхідність. Розробка такого середовища моделювання вочевидь пов’язана з двома відносно окремими задачами:· аналіз базових елементів системи та їх ієрархічних залежностей і побудова на його основі дерева підлеглостей елементів структури, що вивчається;· збагачення базових елементів та відповідних їм залежностей підлеглості прагматико-обумовленими залежностями вищого рівня. Наприклад, залежності по задачах, функціональні, інформаційні залежності, т.і. Що стосується першого, то тут розроблено достатню кількість методів, як задання ієрархічних структур в тій чи іншій формі, так і трансляції цих форм. Найпоширенішими є традиційні задавання ієрархій у вигляді відношень, зокрема в формі таблиць виду <№, Батько, Син> чи у вигляді деревовидних структур:
Рис.9 Особливість даного випадку полягає в тому, що з одного боку для задавання ієрархії теоретично цілком достатньо тільки відношення підлеглості. Адже з того, що для будь-яких двох вузлів 1 та 2 вираз <1,2> означає «2 підлеглий до 1» безпосередньо слідує, що 1 є «начальником» 2. З іншого ж боку, така неявна заданість факту начальствування вузла 1 суттєво збіднює розгляді. Адже статус начальствування вузла такий же багатий, як і стан підлеглості. Тим більше, що переважній кількості вузлів, очевидно, властиві обидва статуси. Змістовно кажучи, кожний елемент ієрархії занурено в інтеграційне середовище, яке може бути представлене наступним деревом:
…Рис.10 Тут кольором виділено вузол, що є досліджуваним. Таке представлення, хоча і адекватне суті, загалом є обтяжливо узагальненим, а значить недостатньо багатим. Адже, якщо у структурного елемента є тільки один начальник, то кількість підлеглих теоретично необмежена нічим, крім скінченності цієї величини. Необхідно збагатити розгляди. Очевидно, це досягається переходом до більш уніфікованої ієрархії:
… Рис.11. Рис.12. Структура, представлена на рис.11 є більш багатою в розглядах ніж та, що представлена на рис.10. Але і вона ще досить обтяжлива. Адже за допомогою неї неадекватно представляти як корінь ієрархії, так і її листя. Таким чином, приходимо до наступного представлення:
Рис.13. Змістовно кажучи, останнє зведення означає, що дослідження будь-якого з елементів ієрархії полягає в розгляді його по можливості як «начальника» та як «підлеглого». Причому, як в першому, так і в другому варіанті маємо справу з розглядом класичного варіанту системи взаємодії типу <пристрій, що управляє, пристрій, яким управляють> без зворотного зв’язку. Різниця розгляду тільки в тому, який з полюсів біополя визначає точку зору на нього. Проведений аналіз дозволяє стверджувати, що функція збагачення структури, зображеної на рис.11 через змістовне збагачення біполей <начальник,підлеглий> та <підлеглий,начальник> представляє собою редукцію функції аналізу досліджуваної ієрархії . Тобто, . Таким чином, збагативши логіку функції , очевидно специфікуємо необхідне нам середовище взаємодії розробників СКІ.Перейдемо тепер до самої функції . Як і раніше, будемо дотримуватись тут в основному змістовних тлумачень. В першому наближенні, функція як функція збагачення будь-якого, але фіксованого в кожний момент часу вузла дерева підлеглості представляє собою систему взаємозбагачень трьох основних характеристик вузла. Умовно позначимо їх як «завдання», «функція» та «інформація». Розглянемо процеси взаємозбагачень більш ґрунтовно. Збагачення характеристики «завдання» через «функцію». Дане збагачення підтримується змістовною операцією «розпаралелювання». Сутність її полягає в тому, що характеристика «завдання» як носій найбільш загальних, не процедурних представлень про покладену на вузол задачу (тобто, «те, що треба зробити») збагачується сукупністю характеристик «функція» як конкретизацій, змістовно кажучи того, що треба зробити тим, як це робити. В першому наближенні, дане збагачення можна представити у вигляді наступної діаграми: …

Рис.15

При цьому, ніяких додаткових конкретизацій, наприклад, типу взаємодії самих функцій і т.і. не здійснюється. Вважаємо, що порядок взаємодії визначається змістом самого завдання. В цьому проявляється взаємність збагачення в парі <завдання,функція>.

Збагачення характеристики «функція» через «завдання». Дане збагачення підтримується змістовною операцією «функціональна конкретизація». Однією з найважливіших загально значних властивостей будь-якої функції є можливість її застосування до аргументу. Причому природа застосувань є також досить складною. В першому наближенні, необхідно розрізняти безпосередні та опосередковані застосування. Зокрема, останні складають основу широко відомого -числення, що складає фундамент об’єктно-орієнтованого підходу. Не вдаючись до глибокого аналізу цих застосувань, обмежимось лише їх змістовними трактовками.

Змістовно процедура безпосереднього застосування засобу побудови об’єктів, зокрема функції, включає виконання наступних трьох дій: а) вибір об’єктів, на яких визначений цей засіб, з сукупності засобів побудови об’єктів (зокрема даних та функцій), б) побудова, взагалі кажучи неоднозначна, з обраних об’єктів нових об’єктів (зокрема функцій та відношень), і, нарешті, в) посилка збудованих об’єктів в унiверсум об’єктів.

Процедура опосередкованого застосування засобів побудови об’єктів виконує ці ж дії а)-в), але, на відміну від процедури безпосереднього застосування не безпосередньо, а опосередковано. Конкретно, воно опосередковане попереднім вибором самого засобу побудови об’єктів, залежно від того чи іншого конкретного кроку в покроковому використанні цієї процедури застосування.

Фактично, будь-яка функція, що характеризує поточний вузол дерева підлеглостей може бути або виконана безпосередньо на самому вузлі (безпосереднє застосування), або аплікована (передана) в якості завдання на один з підлеглих вузлів (опосередковане застосування). В першому випадку вся необхідна конкретизація функції виконується виключно на вузлі-володарі. В іншому випадку функція, передається як завдання до підлеглого вузла і проходить знову весь процес збагачення, починаючи з розпаралелювання. Зазначимо, що в даному випадку функція опосередковано збагачується характеристикою «завдання». Домовимось, функції, що застосовуються безпосередньо називати базовими функціями, а виконувані опосередковано – складними функціями. Тоді весь процес можна представити в першому наближенні, у вигляді наступної діаграми:

Рис.16

Інформаційне збагачення характеристик «функція» та «завдання». Дане збагачення теж є взаємним. З одного боку «інформація» змістовно збагачує безпосередньо базові функції та опосередковано складні функції та завдання. З іншого боку, функції не тільки отримують інформацію, але й збагачують інформаційне поле. З огляду на достатню прозорість цих процесів, ґрунтовно зупинятись на них немає потреби. Єдине, що необхідно зазначити, це те, що на відміну від складних функцій, інформаційне збагачення яких не є обов’язковим з огляду на не первинність самої функції, будь-яка базова функція повинна(!) бути повністю конкретизована на вузлі-володарі. Тобто, вона повинна бути збагачена щонайменше джерелами та витоками інформації. Адже подальших конкретизацій її вже не передбачається.

Зазначимо, що з змістовної точки зору процеси розпаралелювання та функціональної конкретизації (ФК) являють собою декомпозицію (у розумінні розкладу) задачі, що уточнюється складною функцією по контекстній умові у вигляді «завдання».

Таким чином, процес репродукції завдань і функцій, в загальному вигляді, можна представити так:

Рис.17

Виходячи із змістовних характеристик процесів взаємозбагачення характеристик тепер можна зробити деякі безпосередні їх збагачення у вигляді параметрів, що підтримують вищерозглянуті процеси.