четвер, 14 лютого 2008 р.

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

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

понеділок, 11 лютого 2008 р.

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

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

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

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

пʼятниця, 8 лютого 2008 р.

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

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

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

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

середа, 16 січня 2008 р.

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

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

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

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