Azərbaycanca
Беларускі
Dansk
Deutsch
Española
Français
Indonesia
Italiana
日本語
Қазақ
Lietuvos
Nederlands
Português
Русский
සිංහල
แบบไทย
Türkçe
Українська
中國人
United State
Afrikaans
«Міфі́чний люди́но-мі́сяць або Як ство́рюють програ́мні систе́ми» (англ. The Mythical Man-Month) — книга Фредеріка Брукса про управління проєктами в області розробки програмного забезпечення. Центральною темою книги стало те, що привнесення в проєкт нових сил на пізніх стадіях розробки лише відсуває термін здачі проєкту. Ця ідея стала відома під назвою «закон Брукса». Книга була вперше опублікована 1975 року. Вдруге книга вийшла у вигляді ювілейного видання в 1995-ому, разом з коментарями автора та новим есе «Срібної кулі немає».
 | |
| Автор | Фредерік Брукс |
|---|---|
| Назва мовою оригіналу | The Mythical Man-Month |
| Мова | англійська |
| Тема | розробка програмного забезпечення |
| Жанр | есей |
| Видавництво | Addison–Wesley |
| Видано | 1975, 1995 |
| ISBN | 0-201-00650-2 (1975), 0-201-83595-9 (1995) |
| Наступний твір | Срібної кулі немає |
Спостереження Брукса спираються на його досвід роботи в IBM, який він отримав під час керування проєктом зі створення операційної системи (OS/360). Для прискорення розробки він спробував залучити більше число працівників до проєкту, терміни по якому вже були зірвані. Ця спроба виявилась невдалою. Також Брукс помилився, зробивши припущення, що написання компілятора мови ALGOL потребуватиме шести місяців — незалежно від кількості людей, залучених до проєкту (насправді це зайняло більше часу).
Помітивши схильність менеджерів повторювати такі помилки, Брукс глузливо називав свою книгу «біблією для програмної інженерії»: «всі її цитують, дехто її читав, але одиниці живуть по ній!» Книга вважається класичною по опису людського чинника в програмній інженерії.
Основні ідеї
Міфічний людино-місяць
Час виконання проєкту не обернено пропорційний числу програмістів, принаймні з двох причин.
- У програмуванні, на відміну від, наприклад, збирання бавовни, робота не може бути довільно розділена на кілька незалежних частин. Частини проєкту залежать одна від одної, і деякі завдання можна починати виконувати лише після того, як будуть закінчені інші.
- Програмісти повинні витрачати частину часу на взаємодію один з одним.
Якщо є N програмістів, то кількість пар програмістів N(N-1)/2, тобто зі зростанням числа програмістів витрати часу на взаємодію ростуть квадратично. Тому починаючи з якогось N, зростання числа програмістів уповільнює виконання проєкту.
Якщо терміни закінчення проєкту зірвані, наймання нових програмістів уповільнює виконання проєкту і з іншої причини: новачкам потрібен час на навчання. У книзі сформульовано Закон Брукса:
Якщо проєкт не вкладається в терміни, то додавання робочої сили затримає його ще більше.
Якщо програмістів занадто багато, проєкт може бути взагалі ніколи не закінчений: через загальну плутанину, спроби виправити вади породжують нові, так що система не поліпшується.
Програма та програмний продукт
Програмний продукт відрізняється від програми:
- максимально узагальненим діапазоном та видом вхідних даних;
- ретельним тестуванням, що є несподівано складним етапом;
- наявністю докладної документації.
Програмний продукт вимагає втричі більше витрат часу, ніж програма.
Ефект другої системи
Програміст, який розробляє свою другу систему, схильний додавати всі ті можливості, які він не зміг додати в свою першу систему (через брак часу). Тому друга система часто виявляється перевантаженою можливостями.
Концептуальна цілісність
Для забезпечення концептуальної цілісності системи необхідно відокремити архітектуру від реалізації. Один головний архітектор (або невелика група), вирішують, що повинно входити в систему, а що не повинно. «Дуже крута» ідея може бути знехтувана, якщо пропоновану можливість важко вписати в загальний дизайн системи. Простота дуже важлива; може бути корисним реалізувати лише частину можливостей, на які здатна система, оскільки якщо система занадто складна, частина її можливостей будуть залишатися невикористаними.
Головний архітектор повинен сформулювати свої рішення у вигляді керівництва для користувача.
Формальні документи
Кожний менеджер проєкту повинен скласти невеликий набір формальних документів, що описують цілі проєкту, як, хто і коли буде їх реалізовувати, і скільки вони будуть коштувати. Ці документи можуть розкрити невідповідності, які інакше було б важко помітити.
Кожна група розробників отримує набір вимог до своєї частини системи, включаючи точний опис її функціональності та граничні вимоги до процесорного часу, пам'яті, місця на диску і т.д.
Взаємодія
Щоб запобігти катастрофі, групи розробників повинні взаємодіяти одна з одною всіма можливими способами. Замість того щоб робити припущення з приводу функції, що він її реалізовує, розробник повинен ставити архітекторові запитання, оскільки припущення можуть виявитися геть невірними.
Пілотна система
Перед тим як розробляти остаточну систему, необхідно розробити пілотну систему. Пілотна система виявить помилки в проєктуванні, після чого вона повинна бути повністю перероблена.
Хірургічні групи
Розумно, якщо в групі розробників є один "гарний" програміст, який реалізовує найкритичніші частини системи, і кілька інших, що допомагають йому або реалізовують менш критичні частини. До речі так проводять хірургічні операції. Крім того, на думку Брукса, найкращі програмісти працюють в 5-10 раз швидше за інших.
Спеціалізовані утиліти
Замість того, щоб кожний програміст писав власні утиліти, в кожній групі розробників повинен бути один програміст, відповідальний за написання утиліт для своєї групи (наприклад, генератор коду, що створює код згідно з якимись специфікаціями). Повинна бути також група, яка створює утиліти для всіх програмістів, що працюють над системою.
Версії та заморожування системи
Під час створення системи, вимоги користувача до неї можуть змінюватись під впливом його досвіду роботи з незакінченою системою. Ці побажання користувача слід враховувати, але лише до певного моменту, інакше робота над системою ніколи не буде закінчена. Після цього специфікації заморожуються, і всі такі вимоги змін відкладаються до початку роботи над наступною версією.
Зниження вартості розробки
Брукс пропонує 2 способи знизити вартість розробки програмного забезпечення:
- Найняти програмістів лише після того, як побудована архітектура системи. Інакше якщо ця стадія буде тривалою, наприклад розтягнеться в кілька місяців, програмістам буде нічого робити.
- Придбати частину програмного забезпечення у інших розробників.
Примітки
- Roth, Daniel (12 грудня 2005). . CNN. Архів оригіналу за 4 лютого 2019. Процитовано 23 жовтня 2010.
- . Архів оригіналу за 28 червня 2020. Процитовано 23 жовтня 2010.
Посилання
- Сайт Фредеріка Брукса [ 24 грудня 2006 у Wayback Machine.]
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Mifi chnij lyudi no mi syac abo Yak stvo ryuyut progra mni siste mi angl The Mythical Man Month kniga Frederika Bruksa pro upravlinnya proyektami v oblasti rozrobki programnogo zabezpechennya Centralnoyu temoyu knigi stalo te sho privnesennya v proyekt novih sil na piznih stadiyah rozrobki lishe vidsuvaye termin zdachi proyektu Cya ideya stala vidoma pid nazvoyu zakon Bruksa Kniga bula vpershe opublikovana 1975 roku Vdruge kniga vijshla u viglyadi yuvilejnogo vidannya v 1995 omu razom z komentaryami avtora ta novim ese Sribnoyi kuli nemaye Mifichnij lyudino misyac Avtor Frederik BruksNazva movoyu originalu The Mythical Man MonthMova anglijskaTema rozrobka programnogo zabezpechennyaZhanr esejVidavnictvo Addison WesleyVidano 1975 1995ISBN 0 201 00650 2 1975 0 201 83595 9 1995 Nastupnij tvir Sribnoyi kuli nemaye Sposterezhennya Bruksa spirayutsya na jogo dosvid roboti v IBM yakij vin otrimav pid chas keruvannya proyektom zi stvorennya operacijnoyi sistemi OS 360 Dlya priskorennya rozrobki vin sprobuvav zaluchiti bilshe chislo pracivnikiv do proyektu termini po yakomu vzhe buli zirvani Cya sproba viyavilas nevdaloyu Takozh Bruks pomilivsya zrobivshi pripushennya sho napisannya kompilyatora movi ALGOL potrebuvatime shesti misyaciv nezalezhno vid kilkosti lyudej zaluchenih do proyektu naspravdi ce zajnyalo bilshe chasu Pomitivshi shilnist menedzheriv povtoryuvati taki pomilki Bruks gluzlivo nazivav svoyu knigu bibliyeyu dlya programnoyi inzheneriyi vsi yiyi cituyut dehto yiyi chitav ale odinici zhivut po nij Kniga vvazhayetsya klasichnoyu po opisu lyudskogo chinnika v programnij inzheneriyi Osnovni ideyiMifichnij lyudino misyac Chas vikonannya proyektu ne oberneno proporcijnij chislu programistiv prinajmni z dvoh prichin U programuvanni na vidminu vid napriklad zbirannya bavovni robota ne mozhe buti dovilno rozdilena na kilka nezalezhnih chastin Chastini proyektu zalezhat odna vid odnoyi i deyaki zavdannya mozhna pochinati vikonuvati lishe pislya togo yak budut zakincheni inshi Programisti povinni vitrachati chastinu chasu na vzayemodiyu odin z odnim Yaksho ye N programistiv to kilkist par programistiv N N 1 2 tobto zi zrostannyam chisla programistiv vitrati chasu na vzayemodiyu rostut kvadratichno Tomu pochinayuchi z yakogos N zrostannya chisla programistiv upovilnyuye vikonannya proyektu Yaksho termini zakinchennya proyektu zirvani najmannya novih programistiv upovilnyuye vikonannya proyektu i z inshoyi prichini novachkam potriben chas na navchannya U knizi sformulovano Zakon Bruksa Yaksho proyekt ne vkladayetsya v termini to dodavannya robochoyi sili zatrimaye jogo she bilshe Yaksho programistiv zanadto bagato proyekt mozhe buti vzagali nikoli ne zakinchenij cherez zagalnu plutaninu sprobi vipraviti vadi porodzhuyut novi tak sho sistema ne polipshuyetsya Programa ta programnij produkt Programnij produkt vidriznyayetsya vid programi maksimalno uzagalnenim diapazonom ta vidom vhidnih danih retelnim testuvannyam sho ye nespodivano skladnim etapom nayavnistyu dokladnoyi dokumentaciyi Programnij produkt vimagaye vtrichi bilshe vitrat chasu nizh programa Efekt drugoyi sistemi Dokladnishe Efekt drugoyi sistemi Programist yakij rozroblyaye svoyu drugu sistemu shilnij dodavati vsi ti mozhlivosti yaki vin ne zmig dodati v svoyu pershu sistemu cherez brak chasu Tomu druga sistema chasto viyavlyayetsya perevantazhenoyu mozhlivostyami Konceptualna cilisnist Dlya zabezpechennya konceptualnoyi cilisnosti sistemi neobhidno vidokremiti arhitekturu vid realizaciyi Odin golovnij arhitektor abo nevelika grupa virishuyut sho povinno vhoditi v sistemu a sho ne povinno Duzhe kruta ideya mozhe buti znehtuvana yaksho proponovanu mozhlivist vazhko vpisati v zagalnij dizajn sistemi Prostota duzhe vazhliva mozhe buti korisnim realizuvati lishe chastinu mozhlivostej na yaki zdatna sistema oskilki yaksho sistema zanadto skladna chastina yiyi mozhlivostej budut zalishatisya nevikoristanimi Golovnij arhitektor povinen sformulyuvati svoyi rishennya u viglyadi kerivnictva dlya koristuvacha Formalni dokumenti Kozhnij menedzher proyektu povinen sklasti nevelikij nabir formalnih dokumentiv sho opisuyut cili proyektu yak hto i koli bude yih realizovuvati i skilki voni budut koshtuvati Ci dokumenti mozhut rozkriti nevidpovidnosti yaki inakshe bulo b vazhko pomititi Kozhna grupa rozrobnikiv otrimuye nabir vimog do svoyeyi chastini sistemi vklyuchayuchi tochnij opis yiyi funkcionalnosti ta granichni vimogi do procesornogo chasu pam yati miscya na disku i t d Vzayemodiya Shob zapobigti katastrofi grupi rozrobnikiv povinni vzayemodiyati odna z odnoyu vsima mozhlivimi sposobami Zamist togo shob robiti pripushennya z privodu funkciyi sho vin yiyi realizovuye rozrobnik povinen staviti arhitektorovi zapitannya oskilki pripushennya mozhut viyavitisya get nevirnimi Pilotna sistema Pered tim yak rozroblyati ostatochnu sistemu neobhidno rozrobiti pilotnu sistemu Pilotna sistema viyavit pomilki v proyektuvanni pislya chogo vona povinna buti povnistyu pereroblena Hirurgichni grupi Rozumno yaksho v grupi rozrobnikiv ye odin garnij programist yakij realizovuye najkritichnishi chastini sistemi i kilka inshih sho dopomagayut jomu abo realizovuyut mensh kritichni chastini Do rechi tak provodyat hirurgichni operaciyi Krim togo na dumku Bruksa najkrashi programisti pracyuyut v 5 10 raz shvidshe za inshih Specializovani utiliti Zamist togo shob kozhnij programist pisav vlasni utiliti v kozhnij grupi rozrobnikiv povinen buti odin programist vidpovidalnij za napisannya utilit dlya svoyeyi grupi napriklad generator kodu sho stvoryuye kod zgidno z yakimis specifikaciyami Povinna buti takozh grupa yaka stvoryuye utiliti dlya vsih programistiv sho pracyuyut nad sistemoyu Versiyi ta zamorozhuvannya sistemi Pid chas stvorennya sistemi vimogi koristuvacha do neyi mozhut zminyuvatis pid vplivom jogo dosvidu roboti z nezakinchenoyu sistemoyu Ci pobazhannya koristuvacha slid vrahovuvati ale lishe do pevnogo momentu inakshe robota nad sistemoyu nikoli ne bude zakinchena Pislya cogo specifikaciyi zamorozhuyutsya i vsi taki vimogi zmin vidkladayutsya do pochatku roboti nad nastupnoyu versiyeyu Znizhennya vartosti rozrobki Bruks proponuye 2 sposobi zniziti vartist rozrobki programnogo zabezpechennya Najnyati programistiv lishe pislya togo yak pobudovana arhitektura sistemi Inakshe yaksho cya stadiya bude trivaloyu napriklad roztyagnetsya v kilka misyaciv programistam bude nichogo robiti Pridbati chastinu programnogo zabezpechennya u inshih rozrobnikiv PrimitkiRoth Daniel 12 grudnya 2005 CNN Arhiv originalu za 4 lyutogo 2019 Procitovano 23 zhovtnya 2010 Arhiv originalu za 28 chervnya 2020 Procitovano 23 zhovtnya 2010 PosilannyaSajt Frederika Bruksa 24 grudnya 2006 u Wayback Machine