96. Управління проектом після виконання першої ітерації.

Завершення першої ітерації - важливий рубіж проекту. В цей момент доречно

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

поділяються на змістовні результати, пов'язані з виконанням замовлення, і організаційні,

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

результатів, які необхідно отримати в ході виконання першої ітерації, є рольова

спеціалізація співробітників. Це необов'язково означає, що змінюється організація

колективної діяльності, переходячи від де персоніфікована схеми до розподілу

відповідальності. Просто певним співробітникам виявляється краще доручати певні види

робіт. Ідеально було б, якщо б така спеціалізація в точності відповідала планам розподілу

робіт в проекті. Це дозволило б менеджеру делегувати повноваження управління за

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

практика вимагає від менеджера більшого: йому доводиться заглиблюватися в завдання,

для вирішення яких не вистачає забезпеченості кадрами, розподіляти завдання між

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

вимоги до кваліфікації менеджера включають в себе достатньо високий рівень знань в

областях діяльності, що відносяться до всіх ключових ролей. Інша причина, що спонукає

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

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

різнобічної кваліфікації менеджерів: для більшості проектів неминучим є організація

навчання працівників, а це прямий обов'язок менеджера як відповідального за кадрове

забезпечення проекту.

Велика частина робіт, прямо пов'язаних з менеджерськими обов'язками, тобто з

плануванням і управлінням, вже розглядалася. До них відносяться: традиційні та об'єктно-

орієнтовані схеми життєвого циклу, оперування з технічними фінансовими та кадровими

ресурсами, управління якістю, ризиками і вимірювання, поточне і перспективне

планування, організація тестування, організація колективної діяльності і самоорганізація.

В рамках опису методу «Спочатку в глибину» роботи, пов'язані з етапами ітеративного

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

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

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

приводить до мети використання методів, а тому виходить за рамки окремої ітерації,

повертаючись до завдань, що вирішуються в процесі виконання, як першої ітерації, так і

попереднього аналізу і досліджень

97. Аналіз вимог.

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

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

У найбільш загальному вигляді

поняття вимог зводиться до наступних двох аспектів, фіксованих для виконання

конструкторських робіт:

засоби програмного продукту, яких потребує користувач для вирішення своїх

проблем або досягнення певних цілей;

характеристики програмного продукту, яким повинна володіти система в цілому

або її компонент, щоб задовольняти угодами, специфікаціям, стандартам або інший

формально встановленої документації.

Навіть це не дуже точне визначення неформального поняття вимог вказує на те, що

в реальному житті дуже важко, виходячи з аморфних і суперечливих побажань, виявити,

що конкретно й у якому вигляді повинно бути втілено в програмному продукті. Проблеми,

пов'язані з визначенням вимог, зводяться до наступних положень:

Вимоги не завжди очевидні і мають багато джерел. Зміст затвердження в тому,

що майбутні користувачі, замовник, консультанти з предметної області далеко не

завжди знають, якими засобами доцільно забезпечити підтримку автоматизованої

діяльності, в яких інтерфейсних формах ця підтримка повинна бути виражена;

Вимоги не завжди легко висловити словами. Інтуїтивне уявлення про те, які засоби

повинні надаватися, частіше за все не формулюються явно. Наводиться безліч

суперечливих прикладів, навідних міркувань, але не опис цих засобів. У зв'язку з

цим одна з головних задач аналізу - представити вимоги у вигляді узгоджених між

замовником і розробниками (однаково зрозумілих) тверджень, схем, діаграм,

моделей і т.п.;

Існує безліч різних типів вимог і різних рівнів їх деталізації. Сукупність вимог

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

із завдань аналізу є типізація наявних відомостей про вимоги і розподіл їх по

етапах і ітерація розробки;

Вимоги найчастіше взаємопов'язані і взаємозалежні, іноді суперечливі. Зв'язки між

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

системі понять, яка виходить з предметної області та поведінки користувача,

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

вимогами будуть добре відстеженні, що заздалегідь буде сформульована система

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

отримуючи відомості про вимоги, - це неформальне уявлення про те, хто буде

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

входить виявлення взаємозв'язків і взаємозалежносте, усунення протиріч шляхом

вироблення раціональних компромісів;

Вимоги завжди унікальні, тобто завжди знайдуться властивості або значення

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

твердження не настільки очевидно, якщо розглядати вихідний матеріал для вимог.

По суті, воно означає, що в результаті аналізу вимоги повинні бути сформульовані

з урахуванням даної умови (вимога до вимог);

Набір вимог найчастіше є компромісом між побажаннями майбутніх користувачів,

спрямованим на максимально можливе розширення сфери застосування системи.

Існує багато зацікавлених (майбутніх користувачів), чиї усереднені вимоги повинні

бути задоволені в рамках виконуваних ними функцій у прикладній області;

Вимоги змінюються. Фіксуються в уточненому замовленні на розробку вимоги для

системи, що претендує на широку сферу застосування і довге життя, не є

застиглими і непорушними. Вони змінюються, як через врахування нових факторів

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

Отже, необхідно так будувати аналітичну роботу, щоб мати можливість оперативно

змінювати одержувані результати, враховувати в них зміни і доповнення

початкової інформації;

Вимоги залежать від часу. Це положення вказує на те, що пробне та

експериментальне знайомство з першими одержуваними результатами

(програмними і документними) ймовірно спричинить за собою коригування вимог.

Як наслідок, потрібно мати на увазі, що при випуску чергової версії проміжних

робочих продуктів, при переході від релізу до релізу цілком реальна ситуація

проведення аналізу вимог знову, а тому аналіз і наступні за ним етапи повинні бути

організовані так, щоб мінімізувалися переробки програм і документів .

Щоб подолати зазначені проблеми пропонується ряд прийомів. Використання

деяких з них доцільно на початку проекту, інших - в ході аналітичної роботи, що

виконується на кожній ітерації.__