Міфічний людино-місяць

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
Назва Міфічний людино-місяць
Автор Фредерік Брукс
Назва мовою оригіналу The Mythical Man-Month
Мова англійська
Видавництво Addison–Wesley
Публікація 1975
ISBN ISBN 0-201-83595-9

«Міфі́чний люди́но-мі́сяць або Як ство́рюють програ́мні систе́ми» — книга Фредеріка Брукса про керування проектами в області розробки програмного забезпечення. Центральною темою книги стало те, що привнесення в проект нових сил на пізніх стадіях розробки лише відсуває термін здачі проекту. Ця ідея стала відома під назвою «закон Брукса». Книга була вперше опублікована 1975 року. Вдруге книга вийшла у вигляді ювілейного видання в 1995-ому, разом з коментарями автора та новим есе «Срібної кулі немає».

Спостереження Брукса спираються на його досвід роботи в IBM, отриманому під час керування проектом зі створення операційної системи OS/360. Для прискорення розробки він спробував залучити більше число працівників до проекту, терміни по якому вже були зірвані. Ця спроба виявилась невдалою. Помітивши схильність менеджерів повторювати такі помилки, Брукс глузливо називав свою книгу «біблією для програмної інженерії»: «всі її читали, але мало хто її використовує на практиці!»

Також Брукс стверджував, що написання компілятора мови АЛГОЛ потребуватиме шести місяців — незалежно від кількості людей, залучених в проект.

Основні ідеї[ред.ред. код]

Міфічний людино-місяць[ред.ред. код]

Час виконання проекту не обернено пропорційний числу програмістів, принаймні з двох причин.

  1. У програмуванні, на відміну від, наприклад, збирання бавовни, робота не може бути довільно розділена на кілька незалежних частин. Частини проекту залежать один від одної, і деякі завдання можна починати виконувати лише після того, як будуть закінчені інші.
  2. Програмісти повинні витрачати частину часу на взаємодію один з одним.

Якщо є N програмістів, то кількість пар програмістів N(N-1)/2, тобто зі зростанням числа програмістів витрати часу на взаємодію ростуть квадратично. Тому починаючи з якогось N, зростання числа програмістів уповільнює виконання проекту.

Якщо терміни закінчення проекту зірвані, наймання нових програмістів уповільнює виконання проекту і з іншої причини: новачкам потрібен час на навчання. У книзі сформульовано Закон Брукса:

Якщо проект не вкладається в терміни, то додавання робочої сили затримає його ще більше.

Якщо програмістів занадто багато проект може бути взагалі ніколи не закінчений: через загальну плутанину, спроби виправити баги породжують нові, так що система не поліпшується.

Програма та програмний продукт[ред.ред. код]

Програмний продукт відрізняється від програми:

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

Програмний продукт вимагає втричі більше витрат часу, ніж програма.

Ефект другої системи[ред.ред. код]

Програміст, який розробляє свою другу систему, схильний додавати всі ті можливості, які він не зміг додати в свою першу систему (через брак часу). Тому друга система часто виявляється перевантаженою можливостями.

Концептуальна цілісність[ред.ред. код]

Для забезпечення концептуальної цілісності системи необхідно відокремити архітектуру від реалізації. Один головний архітектор (або невелика група), вирішують, що повинно входити в систему, а що не повинно. «Дуже крута» ідея може бути знехтувана, якщо пропоновану можливість важко вписати в загальний дизайн системи. Простота дуже важлива; може бути корисним реалізувати лише частину можливостей, на які здатна система, оскільки якщо система занадто складна, частина її можливостей будуть залишатися невикористаними.

Головний архітектор повинен сформулювати свої рішення у вигляді керівництва для користувача.

Формальні документи[ред.ред. код]

Кожний менеджер проекту повинен скласти невеликий набір формальних документів, що описують цілі проекту, як, хто і коли буде їх реалізовувати, і скільки вони будуть коштувати. Ці документи можуть розкрити невідповідності, які інакше було б важко помітити.

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

Взаємодія[ред.ред. код]

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

Пілотна система[ред.ред. код]

Перед тим як розробляти остаточну систему, необхідно розробити пілотну систему. Пілотна система виявить помилки в проектуванні, після чого вона повинна бути повністю перероблена.

Хірургічні групи[ред.ред. код]

Розумно, якщо в групі розробників є один "гарний" програміст, який реалізовує найкритичніші частини системи, і кілька інших, що допомагають йому або реалізовують менш критичні частини. До речі так проводять хірургічні операції. Крім того, на думку Брукса, кращі програмісти працюють в 5-10 раз швидше за інших.

Спеціалізовані утиліти[ред.ред. код]

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

Версії та заморожування системи[ред.ред. код]

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

Зниження вартості розробки[ред.ред. код]

Брукс пропонує 2 способи знизити вартість розробки програмного забезпечення:

  • Найняти програмістів лише після того, як побудована архітектура системи. Інакше якщо ця стадія буде тривалою, наприклад розтягнеться в кілька місяців, програмістам буде нічого робити.
  • Придбати частину програмного забезпечення у інших розробників.

Посилання[ред.ред. код]