89. Етап VI: програмування і зборка першої ітерації.

 Тестування програмних компонентів. Обговорюваний етап не може бути завершений без тестування і, зокрема, без тестування програмних

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

 Зборка. В ході виконання попередніх робіт створюване програмне забезпечення виявляється представленим набором пов'язаних один з одним компонентів. Ряд реалізацій класів буде існувати в декількох варіантах; варіантність реалізацій обумовлена різними режимами можливого використання компонентів

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

 Перевірка функціональності (FVT - від Function Validation Testing). Корисно передбачити час для попередньої перевірки розробляється програмного вироби (так

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

встановлення зворотного зв'язку з користувачами;

 Особливості управління проектом. Етап займає від п'ятдесяти до шістдесяти відсотків часу розробки першої ітерації. Відведений час поділяється наступним

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

збірки і проведення перевірки функціональності.

90. Етап VII: оцінка ітерації.

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

Основні роботи етапу:

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

 Проведення експертизи. Збираються відомості про використання робочих продуктів, отриманих на даній ітерації і про процес виконання ітерації;

 Вимірювання. Визначаються заплановані для вимірювання показники розміру, продуктивності, якості та переіспользуемості. Отримані значення зіставляються з апріорними значеннями;

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

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

 Реорганізаційні заходи. Якщо виявлені помилкові рішення в розподілі ролей виконавців, в організації робіт та інших аспектах виконання ітерації, то виробляються заходи, що виправляють ці рішення;

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

 Особливості управління проектом. Етап займає до п'яти відсотків часу розробки першої ітерації. Якщо фактично потрібно більше часу, то це означає помилки в плануванні більш ранніх робіт, які необхідно виявити і усунути.

91. Обговорення методу.

Підхід “Спочатку в глибину” є різновидом звичайного ітеративного нарощування, застосовуваного, коли потрібно швидше зануритися в проект. В цьому полягає основне його гідність. Коли немає потреби спеціально вивчати область додатка системи і методи об'єктно-орієнтованого програмування, протилежний підхід “Спочатку в ширину” (DepthFirst), спрямований на побудову закінченою функціональності на кожній ітерації виявляється переважніше, оскільки комплексний аналіз і повне моделювання використання системи дають можливість побудуватипрацездатну архітектуру системи без переробок і дублювання. Найефективніше при використанні методу “Спочатку в глибину” колективну роботу організовувати спочатку по деперсоніфікована схемою (див. п. 5.1.3), а

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

 колективне обговорення результатів виконання індивідуальних завдань, доручених розробникам;

 затвердження ключових проектних рішень менеджером тільки за результатами їх колективних обговорень;

 виділення коротких строків для контролю виконуваних завдань;

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

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

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

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

інших - явно виділяються ведучі та ведені. Варто відстежувати такі контакти для

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

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

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

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

контактами.Але й тоді, коли менеджеру доводиться брати на себе функції лідера, не варто

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

чому визначають ефективність роботи колективу.

Положення про неформальні контакті є загальними для деперсоніфікована схеми -

вони безпосередньо не пов'язані з методом “Спочатку в глибину”. Але і тут

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

неформальні контакти. Переваги обговорюваного методу для розробки не дуже чітко

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

Метод “Спочатку в глибину” виявляється ефективним лише для невеликих робочих груп.

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

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

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

проекту, то для таких підсистем метод “Спочатку в глибину” цілком можна

рекомендувати.

Запропонований метод не є жорстко регламентованим. Як вибір сценаріїв для мініциклів,

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

практично не обмежені. Єдина умова успішного застосування підходу “Спочатку в

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

зникають.

З самого призначення методу “Спочатку в глибину” випливає, що його використання

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

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

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

аналітичних та оціночних робіт.

92. Менеджмент в ході виконання першої ітерації.

У період, що передує виконанню першої ітерації, діяльність менеджера переважно

пов'язана з плануванням. Подальша його робота - це, в основному, реалізація планів.

Зрозуміло, поточне планування, а також планування подальших ітерацій не повинні

випадати з поля зору менеджера і тоді, коли колектив приступає до роботи над итерацией,

але тепер ця діяльність набуває два нових якості. Тепер планування:

 виконується на тлі управління колективною роботою і

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

робіт.

Постійний зворотний зв'язок змушує коригувати не тільки поточні рішення і

розпорядження, а також і майбутні плани. Для менеджера важливо своєчасно вловлювати

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

зміни потрібно робити висновки, спрямовані в майбутнє: що з неврахованого при

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

постійно діючих факторів, що впливають на виробництво системи. Ця інформація -

джерело корекції планів. Цикл управління при розробці проекту досить очевидний. Він

включає постановку задачі (видачу завдання), виділення ресурсів і вказівка контрольних

термінів (проміжних і остаточних). Стосовно до менеджерської діяльності, цикл

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

виконання завдання йде за планом. Якщо з'ясовується, що це не так, надається допомога:

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

встановлюються додаткові контрольні терміни і т.п. Як небажаних, але іноді необхідних

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

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

проекту.

Відмінною особливістю циклу управління в ході робіт над першою итерацией є

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

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

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

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