6333

Менеджмент програмних проектів

Реферат

Менеджмент, консалтинг и предпринимательство

Менеджмент програмних проектів Процес розробки Моделі розробки додатків Модель водоспаду Спіральна модель Універсальний процес Етапи Фази Ітерації Компромісний трикутник Принципи моделі ...

Украинкский

2013-01-03

327.5 KB

32 чел.

Менеджмент програмних проектів

1. Процес розробки

1.1. Моделі розробки додатків

1.1.1. Модель водоспаду

1.1.2 Спіральна модель

1.1.3 Універсальний процес

1.1.3.1. Етапи

1.1.3.2. Фази

1.1.3.3. Ітерації

1.2 Компромісний трикутник

1.3. Принципи моделі процесу розробки

1.4. Рекомендації з організації випуску версій продукту

2. Склад проектної команди та обов’язки її членів

3. Ролі членів групи в моделі процесу розробки

1. Процес розробки

Для успішного керування проектами розробки програмного забезпечення потрібні дві важливих якості. Перше – строгість – необхідно для постійного контролю стану проекту. Друге – гнучкість – потрібно для успішної адаптації до неминучих несподіванок. Більша частина цієї лекції присвячена моделі процесу розробки додатків MSF (MSF Process Model for Application Development), або, коротше, моделі процесу розробки. Модель процесу MSF – це не детальна інструкція, а структурний каркас, на базі якого організації можуть створювати конкретні способи рішення своїх завдань. Модель процесу розробки – складова частина цієї структури, що описує життєвий цикл проекту розробки програмного забезпечення. Вона дозволяє проектній групі створювати продукт у постійному контакті із замовником і адаптувати процес відповідно до його побажань. Крім того, цей метод здатний забезпечувати найшвидшу реалізацію ключових складових проекту. Модель процесу розробки додатків MSF – гнучкий компонент загальної моделі процесу MSF. с успіхом застосовуваний в індустрії розробки програмного забезпечення для підвищення керованості проектів, мінімізації ризиків, підвищення якості продукції й прискорення розробки.

1.1. Моделі розробки додатків

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

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

1.1.1. Модель водоспаду

Як показано на рис. 1.1. модель водоспаду представляє процес розробки у вигляді строго впорядкованої послідовності етапів. До них відносяться:

  •  збір вимог до системи й програмного забезпечення;
  •  аналіз;
  •  проектування;
  •  кодування й тестування модулів;
  •  інтеграція системи;
  •  тестування додатка в цілому;
  •  передача в експлуатацію.

Рис. 1.1. Модель водоспаду

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

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

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

1.1.2 Спіральна модель

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

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

Кожна із цих стадій звичайно підрозділяється на п'ять фаз:

  •  збір вимог;
  •  проектування;
  •  реалізація;
  •  розгортання;
  •  керування.

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

Рис. 1.2. Спіральна модель

Як і модель водоспаду, спіральна модель породжує наступні проблеми:

  •  Затримка реалізації функціональних можливостей – реалізація складних компонентів, що представляють особливу важливість для замовників і користувачів, відкладається на завершальні ітерації. Це затягує виконання проекту й підвищує вартість робіт.
  •  Ніколи що не закінчуються проекти – проекти, реалізовані по спіральній моделі, часто починають жити власним життям, коли робота над проектом фактично перетворюється в роботу для проекту; такі проекти або ніколи не кінчаються, або кінчаються нічим. При зміні цілей проекту ітераційний підхід змушує групу продовжувати роботу над реалізацією колишніх цілей, ігноруючи нові завдання. Це веде до втрати орієнтації й різкому зниженню корисності проекту.
  •  Невідома вартість – постійне повторення стадій і затягування реалізації складних вимог утрудняє оцінку вартості й прибутковості проекту. Це, у свою чергу, ускладнює оцінку витрат і ефективності при обґрунтуванні наступних проектів.
  •  Відсутність стабільності – постійна зміна системи формує в замовників і користувачів думка про нестабільність продукту. Постійне відновлення всіх складових проекту на кожній ітерації різко збільшує витрати й підвищує вартість розгортання продукту.
  •  Відсутність автоматизації – необхідність інвестицій в автоматизацію процесу розробки програмного забезпечення часто упускається з виду. Значні первісні витрати на засоби автоматизації й підвищення продуктивності при цьому розглядаються як витрати, а не як капіталовкладення. Однак під час відсутності засобів автоматизації ітераційний підхід до розробки приводить до значних затримок випуску продукту. Навіть по закінченні розробки відсутність засобів автоматизації розгортання значно утрудняє установку нових версій продукту на комп'ютери користувачів.

1.1.3 Універсальний процес

Універсальний процес (Unified Process, UP) – широко розповсюджений метод аналізу, проектування й розробки додатків масштабу підприємства. Основні характеристики цього процесу, що базується універсальною мовою моделювання, такі:

  •  сценарії використання як основа проекту;
  •  пріоритет архітектури;
  •  ітераційний і інкрементний процес розробки;
  •  прогнозування ризиків;
  •  об’єктно- і сервісно-орієнтоване проектування;
  •  активне нагромадження й повторне використання об’єктно-орієнтованих шаблонів і об'єктів.

1.1.3.1. Етапи

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

  •  Вимоги – збір бізнес-, технічних і прикладних вимог до проекту.
  •  Аналіз – бізнес- і прикладне моделювання на основі зібраних вимог.
  •  Проектування – створення архітектури на основі об’єктно-ориентированного підходу.
  •  Реалізація – розробка спроектованого додатка (на ранніх стадіях – розробка прототипів).
  •  Тестування – перевірка зробленої роботи.

Нижче опишемо основні етапи універсального процесу трохи докладніше.

Вимоги

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

Результати роботи етапу «Вимоги»:

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

Аналіз

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

Характеристики етапу «Аналіз» і його результати:

  •  уточнення вимог, сформульованих на попередньому етапі, включаючи уточнення моделі сценаріїв використання;
  •  аналітична модель формулюється мовою розробників, і тому на етапі «Аналіз» з'являється формалізм, що дозволяє судити про внутрішню структуру системи:
  •  аналітична модель структурує вимоги таким чином, що вони стають більш зрозумілими, тим самим підготовляючи їх до перетворення в проектні концепції;
  •  модель, побудовану на етапі аналізу, можна розглядати як перший начерк проектної моделі; отже, це – найважливіша вихідна інформація для проектування й розробки системи.

Основний результат етапу «Аналіз» – архітектурне подання аналітичної моделі. Це подання включає наступне:

  •  Аналіз класів, у тому числі прикордонні, елементні й керуючі класи. Прикордонні класи розташовуються між користувальницькими ролями (акторами в термінології універсальної мови моделювання) і внутрішніми структурами додатка; вони, як правило, є ідеальними кандидатами на роль сервісів подання їм користувальницьких сервісів. Елементні класи описують інформацію, що постійно зберігається. Класи, що управляють, реалізують різні типи поводження додатка пов'язані з порядком роботи й т.д.
  •  Аналіз реалізації схем використання – взаємодія різних складових аналітичної моделі, що описує реалізацію конкретної схеми використання в термінах класів і об'єктів, виділених на стадії аналізу. Таке сполучення діаграм використання й діаграм класів описує їхня взаємодія. На основі аналізу реалізації проектна група виробляє методи об'єднання схем використання по класах, об'єктам і ітераціям.
  •  Пакетування – організація класів і реалізацій схем використання у функціональні вимоги, що випливають зі схем використання. Пакет ґрунтується на схемі використання, що підтримує певний бізнес-процес, і конкретної користувальницької ролі або на групі схем використання, що допускають узагальнення або зв'язаних якими-небудь відносинами.

Проектування

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

На етапі проектування виконуються наступні роботи:

  •  визначаються структури підсистем (проектна модель);
  •  підсистеми розподіляються між рівнями (проектна модель);
  •  визначаються інтерфейси класів і об'єктів (проектна модель);
  •  активні класи зв'язуються з вузлами розгортання (модель розгортання).

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

Реалізація

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

Етап «Реалізація» складається з:

  •  реалізації прототипу архітектури;
  •  реалізації компонентів (класів і об'єктів);
  •  тестування компонентів;
  •  інтеграції компонентів;
  •  складання додатка:
  •  створення тестів на основі схем використання;
  •  перевірки архітектури;
  •  планування наступного складання;
  •  переходу до наступної ітерації.

Тестування

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

1.1.3.2. Фази

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

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

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

Дослідження

Число ітерацій цієї фази важко пророчити заздалегідь, однак звичайно воно не перевершує двох, а основна увага приділяється етапу «Збір вимог». Завдання фази «Дослідження» чітко визначені її цілями: опис основних характеристик додатка, зниження ймовірності реалізації основних ризиків і підготовка обґрунтування проекту з погляду його зв'язку з основними завданнями бізнесу. На цій стадії:

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

Фаза «Дослідження» завершується формулюванням цілей проекту.

Пророблення

Як і фаза «Дослідження», фаза «Пророблення» звичайно обмежується двома-трьома ітераціями. На цій фазі основна увага приділяється створенню базової архітектури додатка, більш-менш детальній оцінці вартості й виробітку попереднього графіка. Крім того, на цій стадії плануються роботи фази «Створення». Перелічимо основні роботи, виконувані на фазі «Пророблення»:

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

Фаза «Пророблення» завершується створенням архітектури додатка.

Створення

Фаза «Створення» – основна за часом і споживанням ресурсів. Вона ж вимагає найбільшого числа ітерацій. Ціль цієї фази – створення додатка, а основне завдання – завершити розробку додатка й переконатися, що воно готово до перехідного періоду. До початку перехідного періоду треба переконатися, що додаток досяг первісної стабільності й готово до бета-тестування. Інкрементальний підхід до розробки рекомендує послідовно нарощувати функціональні можливості продукту. На стадії «Створення»:

  •  розширюється список схем використання, включаючи уточнення, деталізацію й опис всіх схем;
  •  завершується виконання перших трьох етапів;
  •  починається тестування (звичайно на цій фазі виконується приблизно 15% етапу «Тестування»);
  •  підтримується цілісність додатка – всі внесені зміни не повинні виходити за рамки затвердженої архітектури;
  •  ведеться керування ризиками, виявленими на попередніх стадіях.

Фаза «Створення» завершується етапом «Готовність до досвідченої експлуатації».

Перехідний період

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

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

1.1.3.3. Ітерації

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

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

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

1.2. Компромісний трикутник

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

Рис. 1.3. Компромісний трикутник

1.3. Принципи моделі процесу розробки

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

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

Випуск версій

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

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

  •  Контакт із замовником.
  •  Рання версія.
  •  Обмежене коло розв'язуваних питань.
  •  Ясність цілей.
  •  Воля й гнучкість.
  •  Послідовне й постійне розширення функціональних можливостей продукту.

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

«Живі» документи

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

Планування процесу

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

Резерв часу

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

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

Як показано на рис. 4.8, резервний час не розподіляється між окремими етапами – вони як і раніше повинні завершуватися в строк за графіком. Додавання резервного часу до графіка приводить до появи двох дат випуску. При складанні графіка «знизу – нагору» визначається внутрішня дата випуску. Додавши до неї резервний час, ви одержите зовнішню дату випуску для замовника.

Планування з урахуванням ризиків

Це спосіб, при якому завдання з високим ступенем ризику одержують високий пріоритет, а завдання, сполучені з малим ризиком, – низький. Якщо завдання, пов'язане з високим ступенем ризику, зажадає більше часу, такий план дозволить збільшити виділений час. Переваги:

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

Пошук компромісів

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

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

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

Табл. 1.1. Приклад матриці альтернатив

Проект 1

Проект 2

Оптимізація

Обмеження

Як вийде

Оптимізація

Обмеження

Як вийде

Ресурси

Дата випуску

Характеристики

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

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

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

Керування ризиками

Для більшості проектів керування ризиками – найважливіший фактор успіху. Щоб упоратися із проектом, проектна група повинна:

  •  навчатися;
  •  швидко адаптуватися до змін;
  •  передбачати зміни;
  •  діяти ефективно.

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

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

Орієнтація на випуск у строк

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

Орієнтація на випуск продукту в строк має масу переваг.

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

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

Розбивка великих проектів на керовані частини

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

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

Щоденне складання

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

Щоденне складання має кілька важливих переваг:

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

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

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

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

Планування «знизу – нагору»

Роботу повинні планувати ті, хто неї робить. Це:

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

1.4. Рекомендації з організації випуску версій продукту

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

Приведемо рекомендації загального характеру.

  •  Орієнтуйтеся на продукт.
  •  Створіть план випуску версій .
  •  Проаналізуйте всі характеристики продукту з погляду важливості, реалізуємості й пріоритетності.
  •  Реалізуйте базові можливості в першій версії.
  •  Якщо версія не вирішує завдань бізнесу .

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

  •  Прототип – на стадії «Аналіз» прототип служить зручним інструментом обміну думками й уточнення концепції. Прототип – це нефункціональна демонстраційна версія продукту, найчастіше лише набір знімків з екрана або WEB-сторінок. Помнете, що прототип лише допомагає проектній групі й замовникові дійти згоди щодо концепції додатка і його користувальницького інтерфейсу.
  •  Доказ коректності концепції – на відміну від демонстраційного прототипу, концептуальні системи, що служать для доказу концепції, є повнофункціональними додатками, ціль яких – довести реалізуємість концепції. Прототип націлений на демонстрацію концепції й користувальницького інтерфейсу, а концепт-системи – архітектури й технології. Вони відповідають на запитання: « чи можна створити стабільно працюючий додаток у рамках запропонованого проекту?» Концепт-система звичайно створюється на стадії «Планування».
  •  Альфа-, бета- і проміжні випуски – на стадії розробки проектна група чаші всього створює дві основних проміжних версії – альфа й бета, Вони демонструють поступове злиття користувальницького інтерфейсу, продемонстрованого на прототипі, і технологій, перевірених концептом-системою. У більших проектах таких випусків може бути кілька. Так рекомендуємо випускати принаймні альфа- і бета-версію у всіх проектах, крім самих незначних. Альфа-версія відповідає на запитання: «От так технологія й інтерфейс виглядають разом. Є чи якісь серйозні проблеми?», а бета-версія – «вирішили всі основні проблеми й більшість дрібних, нічого не упустили?». Ця фаза розробки завершується створенням «золотий» версії.
  •  «Золота» версія – на стадії «Стабілізація» саме ця версія передається обмеженому колу користувачів для тестування. У міру виявлення й усунення помилок і проблем, пов'язаних із продуктивністю, слідом за нею розгортаються наступні випуски. Остаточна «золота» версія, що з'являється наприкінці стадії «Стабілізація», сигналізує про завершення проекту й передачі результатів замовникові.

2. Склад проектної команди та обов’язки її членів

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

Щоб проект уважався вдалим, варто вирішити певні завдання:

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

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

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

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

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

Табл. 2.1. Роль і ціль

Ціль

Роль

Менеджер продукту

Задоволення вимог замовників

Менеджер програми

Дотримання обмежень проекту

Розробник

Відповідність специфікаціям

Тестер

Випуск тільки після виявлення й усунення проблем

Інструктор

Підвищення ефективності праці користувача

Логістик

Простота розгортання й постійний супровід

Модель проектної групи

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

Рис. 1.1. Ролі в моделі проектної групи

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

Менеджер продукту

Менеджер продукту повинен вчасно реагувати на потреби замовника. Його головне завдання – сформувати загальне подання про поставлене завдання й про те, як його вирішувати. Він повинен відповістити на запитання – «Навіщо робимо все це?» і переконатися, що всі члени групи знають і розуміють відповідь на нього.

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

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

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

Менеджер програми

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

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

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

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

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

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

Розробник

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

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

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

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

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

Тестер

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

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

Важливо розрізняти тестування й загальну оцінку якості (Total Quality Assurance, TQA). Тестування стосується тільки проекту – його технічної сторони. Перевірку якості організує керівник, відповідальний за якість, – він з'ясовує відповідність продукту корпоративним, урядовим і іншим стандартам.

Не можна суміщати посади тестера й розробника. Поділ цих обов'язків:

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

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

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

Контроль змін

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

Для керування змінами необхідно:

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

Інші обов'язки

Деякі важливі обов'язки тестерів часто випустять із уваги. До них ставляться:

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

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

Інструктор

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

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

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

Досить часто додаток здається в експлуатацію без плану навчання, а проектні групи навіть не мають подання про те, як користувачі будуть вивчати додаток. Завдання інструкторів – не допустити цього, заздалегідь спроектувавши, склавши й протестувавши всі необхідні матеріали, включаючи короткі пам'ятки, керівництва користувачів, системи онлайнової допомоги, Web-Сторінки й навіть – якщо знадобиться – цілий навчальний курс. Коли матеріали підготовлені, група координує навчання користувачів.

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

Логістик

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

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

Логістик зобов'язаний розбиратися в інфраструктурі продукту й вимогах до його супроводу. Його завдання – перевірити, щоб всі сервери розгортання й робітники станції користувачів задовольняли цим вимогам. Звичайно дані питання враховуються в планах випуску, розгортання й супроводи продукту.

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

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

Багато організацій використовують системи моніторингу продуктивності й стабільності. Тому логістики обов'язково повинні проінформувати розробників про наявність таких засобів.

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

3. Ролі членів групи в моделі процесу розробки

Хоча за загальний хід проекту відповідає менеджер програми, у досягненні кожного етапу, як показано в таблиці 3.1, беруть участь всі ролі. Зіставляючи кожну з ролей (або груп ролей) з основними етапами, одержуємо ясне подання про те, хто відповідає за кожний етап. Такий підхід дозволяє чітко розподілити обов'язку в групі.

Табл. 3.1. Відповідальність ролей моделі групи за основні етапи

Фаза

Етап

Відповідальна особа

Аналіз

Схвалення концепції

Менеджер продукту

Планування

Схвалення плану проекту

Менеджер програми

Розробка

Завершення розробки

Розробник, інструктор

Стабілізація

Випуск продукту

Тестер, логістик

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

PAGE  36


 

А также другие работы, которые могут Вас заинтересовать

17437. Ознайомлення з принципом роботи аналого-цифрових перетворювачів порозрядного зрівноваження 402 KB
  Мета роботи :Ознайомлення з принципом роботи аналогоцифрових перетворювачів порозрядного зрівноваження. Теоретичні відомості Аналогоцифрове перетворення використовується для обробки зберігання або передачі аналогових сигнал в цифровій формі. Наприклад швидкі в
17438. Ознайомлення з роботою систем автоматичного регулювання зі зворотнім зв’язком 198 KB
  Мета роботи:Ознайомлення з роботою систем автоматичного регулювання зі зворотнім зв’язком. Теоретичні відомості Значні обчислювальні та логічні можливості ЕОМ визначають їх використання для керування автоматизованими об’єктами. Інтегральні пристрої цифрового опр
17439. Поняття Колективного несвідомого та архетипу в концепції К. Юнга 23.87 KB
  Поняття Колективного несвідомого та архетипу в концепції К. Юнга Аналітична психологія один з видів аналізу особистості засновником якого є швейцарський психолог і культуролог К. Г. Юнг. Цей напрямок близький до психоаналізу однак має істотні відмінності. Його
17440. Основні етапи розвитку позитивізму 20.68 KB
  Основні етапи розвитку позитивізму Незвичайність новітніх наукових відкриттів гостро поставила питання про природу наукових понять співвідношення чуттєвого і раціонального моментів пізнання емпіричного і теоретичного знання про істину та її критерії законом...
17441. Головні ідеї Філософії життя Ф. Ніцше 17.6 KB
  Головні ідеї Філософії життя Ф. Ніцше Наприкінці XIX у першій половині XX ст. в Європі набула популярності філософія життя найпомітнішими представниками якої були Ф. Ніцше З. Фрейд А. Бергсон які відійшли від онтологічної та характерної для класичної філософії гн...
17442. Інтуїтивізм А. Бергсона 16.86 KB
  Інтуїтивізм А. Бергсона Один із філософських напрямів кінця XIX початку XX століть інтуїтивізм пов'язаний передусім з іменем видатного французького філософа лауреата Нобелівської премії Анрі Бергсона 18591941. Інтуїтивізм Бергсона складна суперечлива т...
17443. Характеристика напрямків філософії XX ст. 29.75 KB
  Характеристика напрямків філософії XX ст. Початок XX століття ознаменувався революційними змінами в науці відкриттям атома й електрона побудовою теорії відносності та квантової механіки а також становленню психології фрейдизму. На початку століття інтен
17444. Основні ідеї філософської позиції екзистенціалізму 21.53 KB
  Основні ідеї філософської позиції екзистенціалізму Екзистенціалі́зм фр. existentialisme від лат. exsistentia існування Філософія існування напрям у філософії XX ст. що позиціонує і досліджує людину як унікальну духовну істоту що здатна до вибору власної долі. Основни...
17445. Проблеми людини та її свободи у філософії Ж. П. Сартра 17.51 KB
  Проблеми людини та її свободи у філософії Ж. П. Сартра Вихідний пункт екзистенціалізму за Сартром це проблема яку вирішують герої Достоєвського: якщо Бога немає то все дозволено. Разом з Богом зникає можливість знайти якінебудь цінності у надчуттєвому світі. Немає ...