Проектування інформаційних систем. Частина 5. Етапи розробки проекту: реалізація, тестування, експлуатація та супровід, Комерція, Різне, статті

Частина 4


Зміст



Реалізація


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


На етапі розробки здійснюється тісна взаємодія проектувальників, розробників і груп тестерів. У разі інтенсивної розробки тестер буквально «пристібається» до розробника, фактично будучи членом групи розробки.


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


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


Слід зазначити, що для складання всього проекту має бути виділене робоче місце. Саме ці модулі передаються на тестування. Взаємодія тестера і розробника без централізованої передачі частин проекту допустимо, але тільки у випадку, якщо необхідно терміново перевірити якусь правку. Дуже часто етап розробки і етап тестування взаємопов’язані і йдуть паралельно. Синхронізує дії тестерів і розробників система bug tracking.


При розробці повинні бути організовані постійно оновлювані сховища готових модулів проекту та бібліотек, які використовуються при складанні модулів. Бажано, щоб процес оновлення сховищ контролював одна людина. Одне зі сховищ має бути призначено для модулів, що пройшли функціональне тестування, а інше – для модулів, які пройшли тестування зв’язків. Перше з них – це чернетки. Друге – Те, з чого вже можна збирати дистрибутив системи і демонструвати його замовнику для проведення контрольних випробувань або здачі будь-яких етапів робіт.


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


Обробка результатів проектування


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


Бажано, щоб на етапі проектування вже була побудована матриця «функції-суті». Це фактично формалізоване уявлення того, що фірма намагається зробити (функції) і яку інформацію потрібно обробити для досягнення результату (сутності). Подібна матриця дозволяє перевірити наступні моменти:



Часто роль деструктора виконує комплект програм архівування даних. Нерідко в інформаційних системах інформацію просто накопичують. Це допустимо лише в тому випадку, якщо протягом усього періоду накопичення інформації (а фактично протягом всієї життєдіяльності інформаційної системи) характеристики її продуктивності задовольняють вимогам замовника. На практиці це надзвичайно рідкісне збіг обставин. Пов’язано це в основному із зростанням оброблюваних обсягів інформації. Слід зазначити, що сподіватися в цьому випадку тільки на потужність СУБД або апаратного забезпечення не можна, тому що подібні екстенсивні методи підвищення продуктивності дають низький розрахунковий приріст швидкості. Фактично завдання реагування системи або окремих її частин на зростання обсягу оброблюваних даних є найбільш вірогідною завданням тестування. У такому випадку група тестування створює модуль генерації (нехай навіть абстрактних) даних, вибирається набір запитів, для яких швидкісні характеристики критичні, далі виробляються заміри і будується залежність швидкості виконання від обсягу даних для кожного із запитів. Таке просте дію дозволить уникнути серйозних помилок і в проектуванні, і в реалізації інформаційної системи.


Специфікація модулів повинна бути виконана ще на етапі проектування, чому в реальних проектах часто просто не надають значення. І дарма – адже через непродуману реалізації модулів будь гідності схеми бази даних можуть бути втрачені. Так, нехтуючи специфікаціями модулів, ви ризикуєте закласти в інформаційну систему:



Це далеко не повний список проблем, які будуть виявлені або на етапі комплексного тестування, або при введенні системи в експлуатацію, а може бути, навіть в процесі експлуатації системи (коли почнуть реально використовуватися модулі).


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


Системні модулі


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



Частина цих функцій повинна виконувати операційна система, але якщо вона буде працювати в неоднорідному середовищі, то немає гарантії, що користувачам прийдеться до смаку наявність різноманітних інтерфейсів в різних операційних системах. В ідеалі всі програми-клієнти повинні працювати в одній операційній системі, однак на практиці розробникам часто доводиться стикатися з цілим «зоопарком» різних робочих станцій у замовника – Підсумком кількох спроб автоматизувати бізнес. Мета розробника – довести систему до максимально однорідного стану або зробити схожими хоча б робочі місця кінцевих користувачів.


Завдання створення інформаційної системи в різнорідної середовищі істотно підвищує вимоги до розробників коду і до обраної засобу розробки. Особливо це стосується розробки системних модулів. Слід приділити увагу модулям, реалізація коду яких залежить від операційної системи. Подібні модулі мають бути виділені окремо для кожної з операційних систем в групи, наприклад Win98, WinNT і т.д. Модулі кожної з груп повинні мати суворі інтерфейси обміну – дані, які вони передають і отримують, строго визначені, будь-яке відхилення від специфікації карається. Жоден з модулів поза цієї групи не може використовувати ніяких інших викликів, крім інтерфейсів обміну. Таким чином модулі, що залежать від операційної системи, ізолюються від інших модулів.


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


Засоби моніторингу інформаційної системи


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


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


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


Інтерфейси


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


Часто змінюваний компонент (компоненти) інформаційної системи слід ізолювати від рідко змінюваних компонентів, щоб одні зміни не тягли за собою інші. Один із прийомів подібної ізоляції – ізоляція запитів до даних від інтерфейсу наступним чином:



При обробці результатів запитів даних слід також особливу увагу приділити питанням відповідності типів включає мови і СУБД, в тому числі питань точності числових типів, так як уявлення їх у різних СУБД істотно розрізняється. Крім того, зверніть увагу на запити до даних, які використовують функції, що залежать від операційної системи, наприклад функції роботи з байтами і словами значення атрибута (наприклад, на Intel і SUN SPARC ці функції будуть працювати по-різному). Типи даних можуть бути приведені або явно в запиті функціями приведення cast і вбудованими в СУБД функціями, або у функції прикладної програми. Не для всіх СУБД неявне перетворення типів дає один і той же результат, тому якщо інформаційна система використовує дані з декількох баз даних під управлінням різних СУБД, то неявних перетворень типів краще уникати.


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


Версії бази даних


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


Скрипти створення бази даних і заповнення її стартовими даними – це теж вихідний код інформаційної системи, і на нього поширюються правила контролю версій. Слід зазначити, що підтримувати версії бази даних на рівні скриптів все ж простіше, ніж на рівні засобів вивантаження і завантаження даних, що надаються самої СУБД, так як в переважній більшості випадків подібні засоби не можуть надати кілька простих, але необхідних функцій:



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


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


Розміщення логіки обробки


Одим з важливих питань проектування є спосіб розміщення бізнес-логіки обробки даних: розміщувати її (і яку частину) або на сервері у вигляді збережених процедур, пакетів, тригерів, інших обмежень цілісності безпосередньо на сервері баз даних, або у вигляді функцій на клієнті (у складі ПО клієнта). Місцезнаходження правил інтерфейсу і правил даних задано точно: перші завжди розміщені на клієнта, другі – на сервері. Правила бізнес-логіки в сучасних СУБД можуть бути розміщені як на клієнті, так і на сервері. Розглянемо один із прикладів найпростішого бізнес-правила:



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


Шаблони


Використання шаблонів і бібліотек для побудови «схожих» модулів – досить поширена практика. Що використати в цьому випадку – об’єкти і класи або бібліотеки – вирішує конкретна група розробників. Диктувати спосіб розробки в більшості випадків безглуздо, тому що розробник пише код так, як вміє чи як звик. Ці моменти зазвичай контролює керівник проекту.


У будь-якому проекті забороняється копіювання коду, оскільки це веде до виникнення різних версій одного і того ж коду в різних фрагментах прикладної програми і, як наслідок, до складно детектіруемих і виправляємо помилки. Слід встановити жорстке правило: використовується виклик функції, а не його копія в коді; будь-яке відхилення від цього правила карається.


Тестування


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


Чим складніше проект, тим більше буде потреба в автоматизації системи зберігання помилок – bug tracking. Подібна система забезпечує наступні функції:



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


Власне тести систем можна розділити на декілька категорій:



У тести кожної групи обов’язково входять тести моделювання відмов. Тут перевіряється реакція компонента, групи компонентів, системи в цілому на відмови наступного типу:



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


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


Експлуатація та супровід


Дослідна експлуатація перекриває процес тестування. Як правило, система вводиться в експлуатацію не повністю, поступово.


Введення в експлуатацію проходить принаймні три фази:



  1. первісна завантаження інформації;
  2. накопичення інформації;
  3. вихід на проектну потужність.

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


В період накопичення інформації проявиться найбільшу кількість помилок, допущених при створенні інформаційної системи. Як правило, це помилки, пов’язані з багатокористувацьким доступом. Часто на етапі тестування таких помилок не приділяється належної уваги – мабуть, через складність моделювання та дорожнечі засобів автоматизації процесу тестування інформаційної системи в умовах багатокористувацького доступу. Деякі помилки виправити буде досить складно, так як вони є помилками проектування. Жоден найкращий проект від них не застрахований. Це означає, що на всякий випадок треба резервувати час на локалізацію та виправлення таких помилок.


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


В період накопичення інформації можна зіткнутися зі знаменитим «впала база». При найгіршому розкладі виявиться, що СУБД не витримує потоку інформації. При хорошому – просто параметри конфігурації невірні. Перший випадок небезпечний, так як вплинути на виробника СУБД досить складно, а замовник дуже не любить посилань на службу технічної підтримки СУБД. Вирішувати проблему відмови СУБД доведеться не виробникові, а вам – міняти схему, знижувати потік запитів, міняти самі запити; в загальному – варіантів багато. Добре, якщо час відновлення бази вписується в запланований.


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


Інші підходи до розробки додатків


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



Методи УРП і УРП можна використовувати далеко не завжди, а лише в тому випадку, якщо:



Проте методом УРП краще розробляти невеликі і, бажано, автономні частини проекту.


В даний час почата спроба представити ще один спосіб швидкого написання проекту – метод екстремального програмування. Нижче будуть розглянуті принципи даного підходу.


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


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


Часта зміна версій (small releases). Систему запускають в експлуатацію вже через кілька місяців після початку реалізації, не чекаючи остаточного вирішення усіх поставлених проблем. Випуск нових версій може відбуватися з періодичністю від щоденного до щомісячного.


Все добре, крім одного: протестувати за такий термін більш-менш складний компонент неможливо. Замовник фактично виступає в ролі бета-тестера. В цьому випадку він може бачити, що розробники трудяться і навіть помилки виправляють. Проте виникають резонні питання: чи варто присвячувати замовника в робочий процес і чи потрібно ставити експерименти на робочій системі? На додаток до сказаного необхідно зазначити, що подібний принцип навряд чи може бути реалізований для частин проекту, які вимагають роботи в режимі 24×7.


Метафора (metaphor). Загальний вигляд системи визначається за допомогою метафори або набору метафор, над якими спільно працюють замовник і програмісти.


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


Простий проект (simple design). У кожен момент часу розробляється система виконує всі тести і підтримує всі взаємозв’язки, що визначаються програмістом, не має дублікатів коду і містить мінімально можлива кількість класів і методів. Це правило коротко можна висловити так: «Кожну думку формулюй один і тільки один раз».


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


Тести (tests). Програмісти постійно пишуть тести для модулів (unit tests). Зібрані разом, ці тести повинні працювати коректно. Для етапів у ітерації замовники пишуть функціональні тести (functional tests), які також повинні працювати правильно. Однак на практиці це не завжди досяжно. Щоб прийняти правильне рішення, необхідно зрозуміти, у скільки обійдеться здача системи із заздалегідь відомим дефектом, і порівняти це з ціною затримки на виправлення дефекту.


При написанні тестів самими програмістами (особливо в умовах надурочних робіт) ці тести не полнофункциональни, і вже тим більше не враховують особливостей багатокористувацької роботи. На більш просунуті тести у розробників зазвичай не вистачає часу. Можна, звичайно, побудувати систему розробки так, що всім будуть займатися одні й ті ж люди, але все-таки не варто перетворювати проект в аналог телепередачі «Сам собі режисер». До сказаного необхідно додати, що тестування системи зовсім не вичерпується тестами компонентів (units), не менш важливі тести взаємодії між ними, це ж відноситься і до тестам надійності роботи. І тим не менше метод екстремального програмування не передбачає створення тестів даного класу. Це пояснюється тим, що самі такі тести можуть представляти достатньо складний код (особливо це стосується тестів-імітаторів реальної роботи системи). У даній технології також ніяк не враховується ще один важливий клас тестів – тести поведінки системи при зростанні обсягів оброблюваної інформації. При високій швидкості зміни версій виконати такий тест технологічно неможливо, оскільки його проведення вимагає стабільного і незмінного коду проекту, наприклад, протягом тижня. Подібні терміни, взагалі кажучи, не гарантуються через часту зміну версій. У такому разі доведеться або припиняти розробку компонентів, або на час проведення тесту створювати паралельну версію проекту, яка буде зберігатися незмінною, тоді як друга при цьому буде змінюватися. Потім потрібно буде виконувати процес злиття коду. Але в цьому випадку тест доведеться створювати знову, тому що методи екстремального програмування просто не передбачають розробку засобів, що дозволяють прогнозувати поведінку системи при тих чи інших змінах.


Переробка системи (refactoring). Архітектура системи постійно еволюціонує. Поточний проект трансформується, при цьому гарантується правильне виконання всіх тестів.


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


Програмування в парі (pair programming). Весь код проекту пишуть дві людини, які використовують одну настільну систему.


Виникає питання: хто-небудь бачив двох абсолютно однакових програмістів, кожен з яких до того ж в кінці робочого дня встигав би писати документацію для напарника? Чи можна знайти таких програмістів-близнюків, приголосних у всьому?


А головне, навіщо потрібна така пара програмістів? Причина, в общем-то, проста: не всі витримують нав’язуваний при екстремальному програмуванні високий темп робіт, неминучий відтік персоналу. Подібна пара може дати якусь страховку – якщо звільниться один, то, може бути, другий доведе справу до кінця. Правда, що залишився потрапить у ще більш жорсткі тимчасові рамки – адже обсяг робіт залишиться колишнім ж, а дублера вже не буде, принаймні якийсь час. Далі слід природний процес передачі інформації новому дублеру, що знову-таки вимагає часу. І так без кінця.


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


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


Колективне володіння (collective ownership). Кожен програміст має можливість у будь-який час вдосконалити будь-яку частину коду в системі, якщо визнає це необхідним.


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


Замовник з постійним участю (on-site customer). Замовник, який в період роботи над системою знаходиться в команді розробників.


Це, звичайно, добре, але незрозуміла мета: чи присвятити замовника в суть справи, то чи зробити його співавтором? Навряд чи тільки у замовника знайдеться настільки висококваліфікований фахівець.


40-годинний тиждень (40-hour weeks). Обсяг надурочних робіт не може перевищувати за тривалістю один робочий тиждень. Навіть окремі випадки надурочних робіт, що повторюються надто часто, є сигналом серйозних проблем, які вимагають невідкладного рішення.


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


Відкрите робочий простір (open workspace). Команда розробників розташовується у великому приміщенні, оточеному кімнатами меншої площі. В центрі робочого простору встановлюються комп’ютери, на яких працюють пари програмістів.


Причому все це, судячи з попереднім принципам, має розташовуватися на території замовника, раз він досить активно залучається до процесу розробки. Виникає питання: чи реально настільки вдалий збіг обставин?


Не більше ніж правила (just rules). Члени колективу, що працює за технологією екстремального програмування, зобов’язуються виконувати викладені правила. Однак це не більше ніж правила і команда може в будь-який момент поміняти їх, якщо її члени досягли принципової угоди з приводу внесених змін.


Може бути, в кінці кінців і буде вироблено одне корисне правило: «спочатку подумай, потім зроби». В цьому випадку ми будемо мати схему, дуже схожу на «водоспад». Чомусь прихильники екстремального програмування переконані, що при використанні «водоспаду» і його клонів цикл розробки обов’язково повинен бути довгим. Незрозуміло, чим обумовлена ​​така впевненість. Адже не заборонено дробити проект на етапи. Чомусь вважається, що планування обов’язково буде одноразовим і незмінним, хоча насправді це не відповідає істині, в тому числі і в разі «водоспаду».


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

Частина 6


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*