Управління документацією в проектах розробки ПЗ
- Один зі стереотипів, що існують в середовищі російських і зарубіжних розробників програмного забезпечення,...
- Опис проекту
- плани
- Завдання виконавцям і звіти про хід робіт
- протоколи
- Звіти про результати активностей
- журнали
- Технічні вимоги
- Технічні специфікації
- Відомості про випуск
- керівництва
- Документація, методології та стандарти якості
Один зі стереотипів, що існують в середовищі російських і зарубіжних розробників програмного забезпечення, - ставлення до проектної документації як до другорядного атрибуту, уповільнює і бюрократизуються роботу. Разом з тим багато стандартів і моделі якості, такі як ISO 9000, CMMI і COBIT, приділяють значну увагу документації, а багато послідовників різних «швидких» методик, навпаки, відводять документації мінімум місця в своїх проектах. Розумний оптимум, як зазвичай, знаходиться посередині. 
Документація використовується для зберігання і передачі знань і фактів самого різного характеру - від «глобальних» на зразок вимог до системи до знань обмеженого застосування (наприклад, список дефектів, знайдених в ході певного раунду тестування). Документація формалізує домовленості і зобов'язання, під якими можна розуміти широкий спектр обіцянок, намірів або завдань, що циркулюють між однією чи кількома організаціями. Документи можуть служити формальним контрактом, визначальним взаємні очікування сторін. Нарешті, проектна документація служить для демонстрації просування проекту і підвищення особистої відповідальності його учасників за результат - на багатьох стадіях проекту при відсутності документально підтверджених результатів робіт переконати керівництво в успішному ході проекту стає надзвичайно важким завданням. Крім цього, факт власноручного викладу результатів робіт в письмовій формі є декларацією здібностей і успіхів виконавця, і документацію такого роду можна використовувати для відновлення історії і як основу для різного роду дисциплінарних впливів - як позитивних, так і негативних.
Класифікація та види документації
Документацію, яка використовується в проектах розробки програмного забезпечення, можна розділити на наступні групи (див. Малюнок): Документація проекту і Документація продукту.
Опис проекту
Опис проекту (project statement) містить основну інформацію про суть і призначення проекту, включаючи постановку задачі, оцінки, пріоритети і обмеження технічного, бюджетного та тимчасового характеру і критерії, при виконанні яких проект буде вважатися успішним. При цьому приділяється увага перерахуванню кордонів - активностей, які служать входом в проект, а також тих, які не виконуватимуться в рамках даного проекту.
У різних організаціях документи такого роду називаються по-різному: технічне завдання, завдання на розробку, обґрунтування і т.д. Однак, незважаючи на відмінності в назвах, їх мета - описати ключові положення контрактного характеру. Це опис зазвичай служить додатком до контракту і основою для виділення коштів, а тому має бути розроблено з максимальною ретельністю. Оскільки успішне виконання проекту є основним завданням виконавця (будь це спеціалізована організація або внутрішній підрозділ замовника), різночитання в оцінці успішності проекту можуть призвести до тяжких репутаційних і фінансових наслідків. Тому уточнення положень таких документів і внесення необхідних доповнень, так само як узгодження уточнених і доданих місць з замовником, відноситься до найважливіших інтересам виконавця і виконується зазвичай менеджером проекту.
плани
Необхідними атрибутами планів є: власне опис необхідних дій; інформація про події, «запускають» ці дії; опис взаємної залежності дій між собою; інформація про виконавців. Календарний план (schedule), крім цього, містить інформацію про прогнозовані дати початку і закінчення дій. Найбільш поширеним видом планів є план-графік проекту в нотації Ганта і Перта.
Дослідницькі проекти, а також проекти, керовані часом (time-driven project), можуть обходитися без планів-графіків. В таких проектах планування може мати неглибокий горизонт, а плани на майбутній період фіксуватися, наприклад, в регулярних звітах.
Теорія розробки програмного забезпечення (зокрема, модель CMMI) також згадує безліч інших планів, якими повинна супроводжуватися розробка: план управління вимогами, план управління змінами, план управління ризиками, план управління конфігураціями, план тестування і т.д. На практиці в «одиночному» проекті, не носить великої складності, більшість з цих планів можуть носити самий загальний характер і орієнтуватися скоріше на правила взаємодії з замовником, ніж на опис внутрішніх операцій.
Ризики, пов'язані з відсутністю більшості планів, крім плану-графіка і плану тестування, мають значний розмір тільки для великих або критичних проектів.
Завдання виконавцям і звіти про хід робіт
Завдання (task), що видаються виконавцям, підлягають документуванню з метою виключення їх «забування» і двоякого тлумачення. Документальні форми, які використовуються для накопичення і запису завдань, на практиці використовуються рідко і зазвичай в якості джерела інформації про видані завданнях застосовуються: плани-графіки; спеціально виділені розділи в регулярних звітах; завдання, виставлені через Microsoft Outlook або через системи управління змінами (такі, як IBM ClearQuest).
Звіти про хід робіт (status report) застосовуються для інформування керівництва і замовника про статус проекту. Звіти можуть виходити як від кінцевих виконавців, так і від менеджера проекту.
протоколи
Всякий скільки-небудь складний проект немислимий без формальних та неформальних, запланованих і спонтанних обговорень, присвячених найрізноманітніших питань. Ці обговорення можуть відбуватися у формі очних зустрічей, по телефону і по листуванню. Підсумки усних обговорень доцільно фіксувати в формі протоколу, якщо прийняті рішення, які змінюють або доповнюють опис проекту; прийнято багато різноманітних рішень; висловлені нові ідеї, наприклад, технічного характеру, які можуть виявитися затребуваними в подальшому.
Звіти про результати активностей
Хід заходів, які завершуються прийняттям ключових для проекту рішень, відбивається в звітах, що подаються на розгляд особі, що приймає рішення. Основними заходами такого роду є: аналіз здійсненності, аналіз альтернатив реалізації, огляд (review) проектної документації, тестування і приймання. Протоколи цих активностей, як правило, містять відомості про час, об'єкті, рамках і характер активності, середовищі, в якій проводилася активність, досягнутих результатах і рекомендованих рішеннях.
Звіт служить відправною точкою і засобом мінімізації тривалості обговорення, так що в деяких випадках рішення може бути прийнято по листуванню. Практика показує, що при відсутності звіту обговорення носить хаотичний і безпредметний характер, непродуктивно відволікаючи час високооплачуваних співробітників.
журнали
Журнал (log) - накопичувальне перерахування тих чи інших однотипних подій або фактів, що виникають в ході проекту. Типовими об'єктами, що накопичуються в журналах, є ризики, проблеми, запити на зміни, дефекти (як документації, так і власне продукту). План-графік може замінюватися або доповнюватися «журналом завдань», в разі, якщо ці завдання носять локальний характер.
Журнали рідко оформляються у вигляді окремого документа. Журнали ризиків і проблем зазвичай є розділом в звіті про стан проекту; ведення журналів змін і дефектів організовується за допомогою систем управління змінами.
Необхідно відзначити, що ведення журналів дефектів має сенс тільки в разі, коли інспекції або тестування виробляються особою, яка не є автором перевіряється документа або вихідного коду. У більшості випадків розробник, який знайшов помилку в своєму творінні, вважатиме за краще тут же виправити її, не переймаючись якимось документуванням.
Технічні вимоги
Технічні вимоги, або вимоги до системи (system requirements specification), описують функціональність, яку повинен містити продукт, а також очікування замовника щодо продуктивності, відмовостійкості, надійності системи, середовища, в якій вона повинна працювати і т.д. Часто вимоги є частиною контрактної документації.
Виконавець зацікавлений в деталізації і фіксації вимог якомога раніше, щоб уникнути перепланування, пов'язаного зі зміною вимог, і щоб мета у вигляді закінчення проекту була ясно видно. На практиці цього не відбувається - кожен проект в ході розробки в тій чи іншій мірі піддається зміни вимог.
Технічні специфікації
Технічні специфікації (technical specification) містять опис архітектури програмного продукту і застосованих в ньому технічних рішень. Детальність і зміст цих специфікацій в основному залежить від складності предметної області, нестандартності застосованих рішень, кваліфікації розробників і розподілу завдань між ними.
Мінімальний набір технічних специфікацій містить загальний опис архітектури та інтерфейсів між компонентами, що створюються різними розробниками.
З огляду на, що підтримка зазвичай доручається менш кваліфікованим розробникам, розумним представляється такий рівень детальності технічних специфікацій, який здається злегка надмірною для співробітників, які розробляють систему. Втім, це міркування має меншу вагу в тому випадку, коли підтримка буде здійснюватися силами іншої організації, а очікування замовника на цей рахунок не сформульовані явно.
Відомості про випуск
Відомості про випуск (release note) описують фактично реалізовану функціональність і помилки, виправлені в даному випуску системи, а також різні особливості випуску: середу, в якій продукт тестувався, відхилення від вимог, невиправлених і т.д. У певному сенсі вони являють собою звітний документ, так як від кожного випуску замовник очікує певних властивостей і якості.
При визначенні детальності цього документа в першу чергу необхідно брати до уваги вимоги замовника і розуміти, чи буде замовник використовувати його для первинної оцінки якості розробки.
керівництва
Необхідність і формат подання керівництва користувача завжди диктуються замовником, і, отже, роботи по його складанню так чи інакше бюджетуються і оплачуються. Аналогічні очікування щодо інструкцій адміністратора можуть не бути сформульовані в разі, якщо адміністративну підтримку системи передбачається доручити розробникам. При оцінці необхідної детальності інструкцій в цьому випадку слід брати до уваги, що підтримка, як правило, здійснюється молодшим персоналом, який часто змінюється і не має постійного контакту з розробниками. Відсутність інструкцій ускладнює передачу знань, привносячи спотворення, а наявність в системі недокументованих особливостей рано чи пізно призводить до втрати знань, переданих «з вуст в уста», погіршуючи здатність виконавця виконувати свої зобов'язання.
Документація, методології та стандарти якості
Ніякої стандарт і ніяка модель якості не вимагають, щоб проектні документи мали ту чи іншу структуру, форму, назву або контент. Вони можуть лише припускати найбільш очевидні рішення, які, однак, аж ніяк не є обов'язковими. Вимоги стандартів і моделей полягають в тому, що інформація певного роду повинна бути зафіксована в тому чи іншому вигляді, при цьому не обов'язково в окремому документі. Залежно від розміру і специфіки проектів в загальному випадку допускається створювати єдині документи для групи проектів.
Форма і структура представлення проектної документації, найбільш повно відображають специфіку проектів, які в той же час досить зручні у використанні і не займають при роботі з нею багато часу, є унікальними для кожної організації. Розробка оптимальної форми і структури документації - одна зі складових діяльності щодо поліпшення процесів і один з предметів процесного консалтингу.
Що ж стосується відмінності «класичних», «полегшених» і agile-методик з точки зору управління документацією, видається, що це відмінність пов'язана лише з її формами, повнотою і детальністю, а також підходами до її еволюції і верифікації. Склад же документації залишається практично незмінним. Незмінним, незалежно від методології, залишається і основний набір документації, що поставляється замовнику, оскільки він багато в чому визначається його потребами і звичками, так само як і її форма і зміст.
Олександр Самбук ( [email protected] ) - генеральний директор Центру програмних рішень «Тауер» (Москва).