Постановка завдання
Під час перших зустрічей щодо замовлення на розроблення ПЗ замовник дуже приблизно уявляє, що йому потрібно. Як правило, він надає кілька сторінок тексту завдання і одразу просить оцінити час виконання замовлення та його вартість. Без чіткого визначення процесів, для автоматизації яких буде використовуватись ПЗ, неможливо навіть приблизно оцінити обсяг робіт. Приблизна оцінка з мінімумом вхідної інформації може призвести до помилки в кілька разів, що негативно відіб’ється на точності визначення строків виконання та вартості робіт.
Потреби (needs) – відображають проблеми бізнесу, персоналій або процесу, що повинні співвідноситися з використанням або придбанням системи [13].
Щоб тримати уявлення про можливі обсяги робіт, потрібно пропонувати замовнику надати або розробити технічне завдання. Завдяки цьому системні аналітики зможуть розібратися в задачі, за допомогою інструментальних засобів виконати декомпозицію системи на компоненти, приблизно визначити обсяги цих компонентів і відповідно час їх реалізації. Ця початкова стадія ЖЦ ПЗ є “оцінкою здійсненності”.
Постановка завдання – найбільш творча частина ЖЦ ПЗ. Потрібно описати поведінку розроблюваної системи. Ця система отримує якісь сигнали з її оточення, тому треба описати поведінку оточення, але оточення само залежить і змінюється під впливом системи, її сигналів, особливо аварійних.
Вирішують це протиріччя ітераційно, поетапно уточнюючи поведінку як системи, так і її оточення. Для відповідальних систем замовник може запропонувати розробити імітаційну модель системи та оточення, що є досить складною.У поставленому завданні замовник визначає вимоги до створюваної системи, які повинні задовольняти потреби користувачів і бути зрозумілими для розробників.
Вимога (Requirement) – умова або можливість, що визначена користувачем для вирішення проблеми або досягнення мети, та якій повинна відповідати або якою повинна володіти система чи її компонент, щоб задовольняти умови контракту, стандарту, специфікації або іншого формально репрезентованого документа [14]. Вимоги поділяються на:
вимоги користувача (User Requirements) – описують цілі/задачі користувачів системи, які повинні досягатися/виконуватися користувачами за допомогою створюваної програмної системи [13];
функціональні вимоги (Functional Requirements) – вимоги, що конкретизують функції, які система або її компонент повинен виконувати [14];
програмні вимоги (Software Requirements) – вимоги до створюваної системи, зрозумілі користувачами (замовниками) і розробниками (виконавцями) стосовно того, що робитиме система і чого від неї не варто чекати.
Досвід показує, що оцінка складності системи, що є сумою оцінок її компонентів, отриманих у результаті декомпозиції, значно точніша, ніж первісна оцінка системи в цілому. Використання засобів формалізації результатів аналізу для їх документального оформлення також підвищує якість початкового опису вимог до системи.
Коли говорять про “формалізацію постановки завдання”, мають на увазі розроблення послідовності моделей, кожна з яких описує систему та її оточення з різних точок зору із поступовою деталізацією. Важливо, щоб усі уявлення про систему, отримані в різних моделях, збиралися в єдиному репозитарії (деякій спеціалізованій базі даних). Цей репозитарій полегшить наскрізне проектування, при якому кожна наступна модель використовує результати попередньої і ніяк їм не суперечить. Відповідно всі можливі перевірки повинні бути наскрізними.
Для якісного визначення вимог до ПЗ потрібно спочатку провести аналіз та сформувати їх специфікації.
Аналіз вимог (Requirements Analysis) – трансформація інформації, отриманої від користувачів (та інших зацікавлених осіб) у чітко та однозначно визначені програмні вимоги, що передаються інженерам для реалізації у програмному коді. Аналіз вимог включає:
- виявлення і розв’язання конфліктів між вимогами;
- визначення меж задачі, що вирішується створюваним програмним забезпеченням; у загальному випадку – визначення меж (Scope) і змісту програмного проекту;
- деталізацію системних вимог для встановлення програмних вимог.
Специфікація (Specification) – документ, що в закінченій, точній і перевіреній формі описує вимоги, проект, поведінку або інші характеристики компонента або системи, а також процедури, спрямовані на визначення того, чи задовольняються описані характеристики [14]. Для опису комплексних проектів (у частині вимог) використовують три основні специфікації:
- визначення системи (System Definition), або специфікація вимог користувачів (User Requirements Specification);
- системних вимог (System Requirements);
- програмних вимог (Software Requirements).
Специфікація програмних вимог (Software Requirements Specification – SRS) встановлює основні угоди між користувачами (замовниками) і розробниками (виконавцями) стосовно того, що робитиме система і чого від неї не варто чекати. Цей документ може включати процедури перевірки створеного ПЗ на відповідність вимогам, що висуваються (у т.ч. плани тестування), описи характеристик стосовно якості та методів його оцінювання, питань безпеки тощо [13].
Специфікація вимог користувачів (User Requirements Specification) або концепція (concept <of operation>) визначає високорівневі вимоги, часто – стратегічні цілі, для досягнення яких створюється програмна система. Важливо, що цей документ описує вимоги до системи з позицій предметної області – домену [13].
Специфікація системних вимог (System Requirements) – описує програмну систему в контексті системної інженерії. Зокрема високорівневі вимоги до програмного забезпечення, що містить кілька або багато взаємозв’язаних підсистем і застосувань. При цьому система може бути як цілком програмною, так і містити програмні та апаратні компоненти. У загальному випадку до складу системи може входити персонал, що виконує певні функції системи, наприклад, авторизацію виконання певних операцій з використанням програмно- апаратних підсистем [13].
При постановці завдання потрібно, щоб програмні вимоги були зрозумілі, зв’язки між ними прозорі, а зміст специфікації не допускав різночитань та інтерпретацій, через які програмний продукт не буде відповідати потребам зацікавлених осіб. Тому потрібні інструменти управління вимогами.
Управління вимогами (Requirements Management) – діяльність, виконання якої забезпечує опис вимог, відстежування їх змін, перевірки на несуперечливість і на порушення наперед визначених правил [14].
Від вхідної інформації про майбутній програмний продукт залежить те, яку методологію буде обрано в проекті з розроблення ПЗ. Методологій багато: і дуже формалізованих, і тих, що дають творчу свободу програмістам. Вибір методології обумовлюється досвідом керівника групи розробників та умовами, які встановлюють замовники до документування етапів робіт. У роботі [5] методології розроблення ПЗ класифікуються за кількістю виконавців та критичністю проекту. Чим більше виконавців та/або вища критичність, тим більш формальна та регульована методика потрібна.
Розроблення ПЗ як проектна діяльність
Діяльність під час розроблення ПЗ, як і будь-що, складається з виконання операцій і проектів. Ті й інші мають багато спільного, наприклад, виконуються людьми та на їх виконання виділяються обмежені ресурси.
Головна відмінність операцій від проектів полягає в тому, що операції виконуються постійно і повторюються, тоді як проект тимчасовий і унікальний. Виходячи з цього, проект визначається як тимчасове зусилля, розпочате для створення унікального продукту чи послуги. «Тимчасове» означає, що кожен проект має точно визначені дати початку та закінчення. Говорячи про унікальність продукту, ми маємо на увазі, що вони мають помітні відмінності від усіх аналогічних продуктів або послуг. Таким чином, розроблення ПЗ відповідає визначенню проекту і для організації цього процесу можна застосовувати методи та інструментарій управління проектами. Наприклад, розроблення веб-сайту є проектом, тоді як підтримка його впродовж тривалого часу – це операційна діяльність.
У кожного проекту є чітко визначені початок і кінець. Кінець проекту настає разом із досягненням усіх його цілей або коли стає зрозумілим, що ці цілі не будуть або не можуть бути досягнуті. Тимчасовість не означає короткостроковість проекту – розроблення складної програмної системи може тривати кілька років, хоча, як правило проекти мають обмежені часові рамки для створення ПЗ, оскільки сприятлива для них ситуація на ринку складається на обмежений час. Крім того, проектна команда після його закінчення розпадається, а її члени переходять в інші проекти.
Проект дуже часто плутають із програмою, тобто координованим управлінням групою проектів всередині однієї організації. Управління відразу декількома проектами скоординоване для того, щоб отримати вигоду, яку неможливо одержати від окремого управління кожним із них.
Проект виконується для досягнення певного результату в певні терміни і за певні гроші. Це тріо часу (time), бюджету(cost) і обсягу робіт (scope) часто називають проектним, або залізним, трикутником (рис. 8) [15], оскільки при внесенні змін в один із цих елементів змінюються інші. Хоча для проекту однаковою мірою важливі всі три елементи, як правило, тільки один із них залежно від пріоритетів має найбільший вплив на інші.
Рисунок 7 – Проектний трикутник
Те, як зміни у плані впливають на інші сторони трикутника, залежить від обставин і специфіки проекту. У деяких випадках зменшення терміну збільшує вартість, а в інших – зменшує.
Якість (quality) – це четвертий елемент проектного трикутника. Вона знаходиться у центрі, і будь-що зміна сторін впливає на неї.
Наприклад, якщо керівникові вдалося знайти додатковий час у розкладі, то можна збільшити обсяг робіт, додавши завдання і збільшивши тривалість проекту. Ці додаткові завдання і час дозволяють домогтися більш високого рівня якості проекту і виробленого продукту.
Якщо ж потрібно знизити витрати, щоб вкластися в бюджет, можливо, знадобиться зменшити обсяг робіт, прибравши деякі із завдань або зменшивши їх тривалість. Зі зменшеним обсягом робіт у проекті буде менше шансів вийти нанеобхідний рівень якості, тому зниження витрат може призвести до погіршення якості проекту.
План проекту складається для того, щоб визначити, за допомогою яких робіт буде досягатися результат проекту, які люди й устаткування потрібні для виконання цих робіт і в що час ці люди й устаткування будуть зайняті роботою в проекті. Тому проектний план містить три основні елементи: завдання, ресурси і призначення.
Завдання (Tasks)
Завданням є робота, здійснювана у рамках проекту для досягнення певного результату. Наприклад, у проекті створення програми для автоматизації формування документації підприємства завданням буде Створення шаблонів. Оскільки, як правило, проект містить багато завдань, то для зручності відстеження плану їх об’єднують у групи, або фази. Сукупність фаз проекту називається його життєвим циклом.
Фази (Summary tasks)
Фаза проекту складається з одного або кількох завдань, у результаті виконання яких досягається один або кілька основних результатів проекту. Таким чином, результати, досягнуті завдяки виконанню кожної із задач, що входять у фазу, формують її результат. Фази можуть складатися як із завдань, так і з інших фаз.
Якщо для досягнення результатів завдання потрібно виконати тільки її, то для досягнення результату фази потрібно виконати групу інших завдань.
При плануванні робіт потрібно пам’ятати, що чим детальніше буде план проекту, тим точніше він буде відповідати реальній ситуації. У тих випадках, де це можливо, варто розбивати великі завдання на підзадачі (перетворювати завдання в фази). Формальними критеріями, які показують, що завдання можна розбити на підзадачі, є тривалість (завдання рідко тривають довше 2-3 днів) і велике число задіяних виконавців (як правило, якщо над вирішенням завдання працюють більше 2-3 осіб, то кожен вирішує свою власну задачу, яку можна окремо врахувати у плані проекту).
Завершальні завдання
Завдання, у результаті виконання яких досягаються проміжні цілі, називаються завершальними завданнями.
Тривалість (Duration) і трудовитрати (Work)
Тривалість завдання – це період робочого часу, що необхідний для того, щоб виконати її.
Тривалість може не відповідати трудовитратам співробітника, що займається завданням. Тривалість відповідає часу, через що буде отриманий результат задачі, а трудовитрати– часу, витраченому співробітниками на отримання результату.
Залежності (Dependencies) та зв’язки (Links)
Завдання у плані проекту взаємозв’язані. Наприклад, часто одна задача не може початися, поки не закінчена інша (тестування модуля не може початися раніше написання його коду).
На плані проекту залежності позначаються за допомогою зв’язків. Обидва ці терміни – залежність і зв’язок – використовуються з одним і тим самим змістом і позначають логіку, певну послідовність робіт у плані проекту.
Ролі (Roles) і ресурси (Resources)
Під ресурсами розуміють співробітників та обладнання, які необхідні для виконання проектних завдань.
Кожен співробітник, що бере участь у проекті, отримує певну роль відповідно до своєї кваліфікації, вимог проекту та регламентів, що діють в організації. Наприклад, в одному проекті співробітник може виступати в ролі архітектора додатків, а в іншому той самий працівник може бути задіяний у ролі програміста.
При складанні списку ресурсів часто використовується рольове планування. Наприклад, спочатку визначається, що для виконання робіт потрібні три програмісти і один менеджер, а потім, коли план проекту затверджений, вибираються конкретні співробітники для участі в цих ролях.
Призначення (Assignments)
Призначення – це зв’язок певної задачі і ресурсів, необхідних для її виконання. При цьому на одну задачу можуть бути призначені декілька ресурсів, як матеріальних, так і нематеріальних.
Призначення об’єднують у плані ресурси і завдання, роблячи план цілісним. Завдяки призначенням вирішується цілий ряд завдань планування. По-перше, визначаються відповідальні за виконання завдань. По-друге, коли визначені завдання, за які відповідає ресурс, можна розрахувати загальний обсяг часу, що витрачається ним на проект, а отже, його вартість для проекту. По-третє, визначивши вартість участі всіх ресурсів у проекті, можна підрахувати його загальну вартість. Нарешті, призначаючи ресурси на завдання, можна скорочувати термін виконання робіт, виділяючи на них більше ресурсів і тим самим скорочуючи загальну тривалість проекту.