Редукційно-композиційна технологія аналізу бізнес-процесів в предметній області

Аналіз бізнес-процесів безпосередньо спирається на процеси їх декомпозиції. Їх дескриптування може бути адекватним, виходячи з принципу композиційності, тільки тоді. Коли воно спирається на ґрунтовне викриття відповідних композиційних механізмів. Останні, вочевидь, жорстко пов’язані з прагматикою розглядів.

Прагматика розглядів даного розділу базується на очевидній важливості в сучасному системо творенні задачі створення систем комплексної інформатизації управлінських та предметних процесів в області адміністративно-господарського будівництва (СКІ).

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

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

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

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

Меню ресторану «Антуан» у Нью-Орлеані

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

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

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

По-третє, оскільки менеджери програмних проектів не впевнені у своїх оцінках, їм часто бракує «ввічливої впертості», як у шеф-кухаря ресторану «Антуан».

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

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

Розглянемо більш докладно інші аспекти проблеми.

Оптимізм

Усі програмісти – оптимісти. Можливо, цей сучасний різновид чаклунства особливо привабливий для тих, хто вірить у хіпі-енди й добрих фей. Як би то не було, результат один: « Цього разу вона точно піде!» Або : «Я тільки що виявив останню помилку!», …

Отже, в основі планування розробки програм лежить неправильне допущення, що кожне завдання займе стільки часу, скільки « повинно» зайняти.

Глибокий оптимізм програмістів заслуговує більш серйозного вивчення. Дороті Сейєрс (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 людей до вихідного завдання. Розрахунок впливу навчання, перерозподілу завдань і системного тестування надається в якості практичної вправи. Немає сумнівів, що при спробі укластися в строк у підсумку вийде гірший продукт, ніж при зміні графіка й збереженні первісних трьох людей без «посилення» команди.

Украй спрощуючи, Брукс сформулював наступну тезу:

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

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