Важкість управління процесом розробки

Основною задачею команди розробки програмного забезпечення є створення ілюзії простоти – захистити користувачів від цієї величезної та часто свавільної складності. Безсумнівно, розмір не є великим достоїнством програмної системи. Ми прагнемо менше коду, запроваджуючи розумні та потужні механізми, що дають нам ілюзію простоти, а також використовуючи повторно платформи існуючих проектів та коду. Однак великий обсяг вимог до системи іноді є невідворотнім та примушує нас писати велику кількість нового програмного забезпечення або повторно використовувати існуюче програмне забезпечення новим засобом. Лише декілька десятиріч тому програми на мові асемблера напружували границі наших можливостей створення програмного забезпечення вже на декількох тисячах рядків коду. Сьогодні не є незвичним знайти поставлені системи, розмір яких вимірюється у сотнях тисячах або навіть у мільйонах рядків коду (та все це високорівневими мовами програмування, звісно). Жодна особа ніколи не зможе зрозуміти подібні системи повністю. Навіть якщо ми розберемо нашу реалізацію в конструктивних відношеннях, ми залишимося в кінцевому рахунку з сотнями або навіть тисячами розділених модулів. Ця кількість роботи потребує того, що ми використовуємо команди розробників, та ідеально ми використовуємо настільки малу команду, наскільки можливо. Однак неважливо який її розмір, завжди існують істотні виклики, пов’язані з розробкою в команді. Мати більше розробників означає більш складний обмін повідомленнями більш важку координацію, особливо коли команда географічно розкидана, як це часто буває. Ключовий управлінський виклик з командою розробників є завжди підтримувати єдність та зв’язаність дизайну.
[1]

Складність проблемної області

Проблеми, що ми намагаємося розв’язати у програмному забезпеченні, часто включають елементи неминучої складності, в котрій ми знаходимо міріади конкуруючих, можливо несумісних вимог. Розглянемо вимоги для електронної системи багатомоторного літака, системи перемикання стільникового телефону або автономного робота. Пряма функціональність подібних систем достатньо складна до розуміння, але додамо тепер всі (часто неявні) не функціональні вимоги, такі як практичність, продуктивність, вартість, живучість, надійність. Ця нестримна зовнішня складність є тим, що спричиняє свавільну складність, про яку писав Брукс.
Ця зовнішня складність звичайно виникає з розірвання зв’язку між користувачами системи та її розробниками: користувачі загально вважають дуже важким надати точний вираз власних потреб у формі, яку розробники можуть зрозуміти. У деяких випадках користувачі можуть мати лише приблизні уявлення про те, чого вони хочуть від програмної системи. Це не стільки провина або користувачів, або розробників системи; скоріше це відбувається через те, що кожна група в основному потребує досвіду у області іншої. Користувачі та розробники мають різні точки зору на природу проблеми та роблять різні припущення відносно природи рішення. Дійсно, навіть якщо користувачі мають чудове знання власних потреб, ми на цей час маємо небагато інструментів для точного оволодіння цими вимогами. Загальний шлях щоб виразити вимоги є великі томи тексту, що іноді супроводжуються деякими кресленнями. Подібні документи є складними для розуміння, відкриті для різноманітних інтерпретацій та занадто часто містять елементи, що є скоріше дизайном, ніж істотними вимогами.
Подальшим ускладненням є те, що вимоги до програмної системи часто змінюються під час її розробки, головним чином через те, що саме існування проекту програмної розробки змінює правила проблеми. Розгляд ранніх виробів, таких як проектні документи та прототипи, та потім використання системи як тільки її встановлено та задіяно є посилюючою функцією, що заохочує користувачів краще розуміти та ясно виражати їхні дійсні потреби. У той самий час, цей процес допомагає розробникам оволодіти проблемною областю, дозволяючи їм задати кращі питання, що освітлюють темні кутки бажаної поведінки системи.
(Підпис до рисунку) Задачею команди розробки програмного забезпечення є створення ілюзії простоти.
Через те, що великі програмні системи є капітальними вкладеннями, ми не можемо дозволити перероблювати існуючу систему кожного разу, коли вимоги до неї змінюються. Заплановано це чи ні, системи прагнуть еволюціонувати через деякий час, обумовлюючи те, що часто невірно називають утриманням програмного забезпечення. Щоб бути точнішим, це є утримання, коли ми виправляємо помилки; це є еволюцією, коли ми відповідаємо на зміну вимог; це є збереженням, коли ми продовжуємо використовувати надзвичайні зусилля щоб залишити частину програмного забезпечення, що застаріле та приходить в занепад, у дієвості. Нажаль, реалії вирішують, що непомірний відсоток ресурсів розробки зайнятий у збереженні програмного забезпечення.
[1]

Чому програмне забезпечення є властиво складним

Як запропонував Брукс: «Складність програмного забезпечення є істотною властивістю, а не випадковістю». Ми дослідимо, що ця властива складність визначається з чотирьох елементів: складності проблемної області, важкістю управління процесом розробки, гнучкістю можливостей програмного забезпечення та проблемами з характеристики поведінки дискретних систем.
[1]

Визначення складності програмного забезпечення

Ми визнаємо, що деякі програмні системи не є складними. Це є в основному додатки, що можуть бути забутими, які є специфіковані, сконструйовані та підтримуються однією особою, звичайно програмістом-любителем або професійним розробником, працюючим ізольовано. Це не каже ані те, що подібні системи незрілі або неелегантні, ані те, що ми принижуємо їхніх творців. Подібні системи прагнуть мати дуже обмежені цілі та дуже короткий життєвий проміжок. Ми можемо дозволити викинути їх геть та замінити їх цілковито новими програмами ніж намагатися знов використати, полагодити або розширити їхні можливості. Подібні додатки є загалом більш скучно ніж складно розробляти; відповідно, вивчення того, як їх проектувати, нас не цікавить.
Навпаки, ми набагато більше зацікавлені у викликах розробки того, що ми будемо називати промисловим програмним забезпеченням. Тут ми знайдемо додатки, що виявляють дуже багату множину поведінки, як, наприклад, в реактивних системах, що керують або керуються подіями фізичного світу, та для яких час та простір є скудними ресурсами; додатки, що підтримують цілісність сотень тисяч записів інформації коли дозволяються паралельні поновлення та запити; та системи для управління та контролю сутностями реального світу, подібні маршрутизації повітряного та залізничного руху. Програмні системи подібні цим прагнуть мати довгий життєвий проміжок та з часом багато користувачів стають залежними від їхнього належного функціонування. У світі промислового програмного забезпечення ми також знаходимо платформи, що спрощують створення предметно-направлених додатків, та програми, що імітують деякі аспекти інтелекту людини. Хоча подібні додатки в основному є результатом дослідження та розробки, вони є не менш складними, тому що вони є засобами та артефактами інкрементної та дослідницької розробки.
Відмінною характеристикою промислового програмного забезпечення є те, що для окремих розробників надзвичайно складно, якщо не неможливо, зрозуміти усі тонкощі його побудови. Кажучи простими словами, складність подібних систем перевищує місткість інтелекту людини. Нажаль, ця складність, про яку ми говоримо виглядає суттєвою складністю усіх великих програмних систем. Під сутністю ми розуміємо, що ми можемо оволодіти цією складністю, але ніколи не зможемо її позбутися.
[1]

1.2 Властива складність програмного забезпечення

Вмираюча зірка на грані колапсу, дитина, що вчиться читати, білі осередки крови, що кидаються, щоб напасти на вірус: Це є лише декілька з об’єктів фізичного світу, які мають дійсно богоподібну складність. Програмне забезпечення може також містити елементи великої складності; однак складність, яку ми тут знаходимо, є фундаментально іншого вигляду. Як вказував Брукс, «Ейнштейн аргументував, що пояснення природи має бути найпростішим, бо Бог не капризний або свавільний. Подібної довірливої зручності нема для інженера програмного забезпечення. Більшість складності, над якою він має поратися є обрана складність.»
[1]

Структура соціальних інститутів

У якості останнього прикладу складних систем ми звернемося до структури соціальних інститутів. Групи людей об’єднуються разом для досягнення цілей, які не можуть бути виконані одноосібно. Деякі організації є швидкоплинні, деякі витримують багато поколінь. Коли організації ростуть швидко, ми бачимо появу чіткої ієрархії. Транснаціональні корпорації містять компанії, які в свою чергу складаються з підрозділів, які в свою чергу містять гілки, які в свою чергу містять місцеві офіси і так далі. Якщо організація довгограюча, границі між цими частинами можуть змінюватися, та через якийсь час може з’явитися нова стабільніша ієрархія.
Взаємини між різними частинами великої організації лише подібні таким, що знайдені між складовими комп’ютеру, або рослини, або навіть галактики. Наприклад, рівень взаємодії між робітниками всередині окремого офісу є більшим, ніж між робітниками різних офісів. Поштовий службовець звичайно не взаємодіє з головним виконавчим директором компанії, але часто взаємодіє з іншими людьми у поштовій кімнаті. Тут також ці різні рівні об’єднані загальними механізмами. Службовець та директор оплачуються однією фінансовою організацією та розділяють загальні засоби, подібні телефонній системі компанії, щоб виконувати свої задачі.
[1]

Структура матерії

Вивчення областей настільки різних як астрономія та ядерна фізика забезпечує нас багатьма іншими прикладами неймовірно складних систем. Охоплюючи ці дві дисципліни, ми знаходимо ще іншу структурну ієрархію. Астрономи вивчають галактики, що групуються в кластерах. Зірки, планети та сміття є складовими галактик. Подібно, фізики-ядерники піклуються про структурну ієрархію, але на повністю іншій шкалі. Атоми зроблені з електронів, протонів та нейтронів; електрони, здається, є елементарними частинками, але протони, нейтрони та інші частинки сформовані з більш простих складових які звуться кварки.
Знов ми знаходимо, що велика спільність у формі загальних механізмів об’єднує цю обширну ієрархію. Особливо, там, здається, є тільки чотири чітких види сил, які працюють у всесвіті: гравітація, електромагнітна взаємодія, сильна сила, слабка сила. Багато законів фізики включають ці елементарні сили, такі як закони збереження енергії та моменту, придатні як до галактик, так і до кварків.
[1]

Структура рослин та тварин

У ботаніці науковці шукають розуміння подібностей та відмінностей між рослинами через вивчення їхньої морфології, що є їхньою формою та структурою. Рослини є складними багатоклітинними організмами, та від скооперованої діяльності різноманітних систем органів рослини виникає подібна складна поведінка я фотосинтез та транспірація.
Рослини містять три основні структури (корені, стеблини та листя). Кожна з них має різну специфічну структуру. Наприклад, корені містять придаткові корені, кореневі волоски, кореневу вершину та кореневий ковпак. Подібно, поперечний перетин листа показує його епідерміс, мезофіл та судинну тканину. Кожна з цих структур у свою чергу складається з набору клітинок, та всередині кожної клітини ми знайдемо інший рівень, якій містить такі елементи, як хлоропласти, ядра і тому подібне. Як зі структурою комп’ютера, частини рослини формують ієрархію, та кожен рівень цієї ієрархії втілює власну складність.
Всі частини на одному рівні абстракції взаємодіють організованим шляхом. Наприклад, на найвищому рівні абстракції, корені відповідають за витягування води та мінералів з солі. Корені взаємодіють зі стеблинами, котрі переносять ці корисні речовини вверх до листя. Листя в свою чергу використовує воду та мінерали, надані стеблинами, щоб виробляти їжу через фотосинтез.
Завжди існують чіткі границі між зовнішнім та внутрішнім даного рівня. Наприклад, ми можемо встановити, що частини листа працюють разом щоб надати функціональність листа як цілого та також мають маленьку або непряму взаємодію з елементарними частинами коренів. Іншими словами, існує чітке розділення відповідальності між частинами на різних рівнях абстракції.
У комп’ютерах ми знаходимо вентилі ТА-НІ, використані у розробці ЦП так само як жорсткого диску. Подібно, значущий обсяг загальності пронизує всі частини структурної ієрархії рослини. Це божественний шлях досягнення стриманості виразів. Наприклад, клітини слугують основними будівельними блоками у всіх структурах рослини; у кінцевому рахунку, корені, стеблини та листя рослини цілком побудовані з клітинок. Одначе, хоча кожен з цих найпростіших елементів є дійсно клітиною, існує багато різновидів клітинок. Наприклад, існують клітини з та без хромопластів, клітини зі стінками, що непроникні для води та клітини зі стінами, що є проникними, та навіть живі клітини та мертві клітини.
Вивчаючи морфологію рослини, ми не знаходимо окремі частини, такі, що кожна відповідає за маленький крок у єдиному більшому процесі, такому як фотосинтез. Фактично, немає ніяких централізованих частин, які безпосередньо координують дії
підлеглих. Навпаки, ми знаходимо окремі частини, які діють як окремі агенти, кожен з яких виявляє деяку достатньо складну поведінку, та кожен з яких сприяє багатьом функціям вищого рівня. Лише через взаємну кооперацію значних наборів цих агентів ми бачимо функціональність рослини високого рівня. Наука про складність називає це складною поведінкою: поведінка цілого є більшою ніж суми його частин.
Звернувшись трохи до області зоології, ми помітимо, що багатоклітинні організми проявляють ієрархічну структуру подібно такій у рослин, набори клітин формують тканини, тканини працюють разом як органи, групи органів визначають системи (такі як травна система), і так далі. Ми не можемо дати собі раду щоб не звернутися до божої великої стриманості виразів: основоположним будівельним блоком усіх тваринних матерій є клітина, подібно тому, як клітина є елементарною структурою усього рослинного життя. Припустимо, існують відмінності між ними обома. Наприклад, рослинні клітини, обмежені жорсткими целюлозними стінками, але тваринні клітини ні. Незважаючи на ці відмінності, однак, обидві з цих структур є безперечно клітинами. Це є приклад спільності областей, що перетинаються.
Численні механізми вище клітинного рівня також розділяються між рослинним та тваринним життям. Наприклад, обидві використовують деякий вид судинної системи для перенесення живильних речовин всередині організму, та обидві проявляють статеве розрізнення серед членів одного різновиду.
[1]