Технологія створення програмних продуктів (2024)

Тема 2. Планування та керування

Лекція 2. Визначення вимог та побудова планів

Лекція 2

Визначення вимог та побудова планів

2.1        Постановка завдання на розроблення ПЗ

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

Потреби (needs) – відображають проблеми бізнесу, персоналій або процесу, що повинні співвідноситися з використанням або придбанням системи.

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

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

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

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

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

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

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

Для якісного визначення вимог до ПЗ потрібно спочатку провести аналіз та сформувати їх специфікації.

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

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

Управління вимогами (Requirements Management) – діяльність, виконання якої забезпечує опис вимог, відстежування їх змін, перевірки на несуперечливість і на порушення наперед визначених правил.

Фактично задачі управління вимогами (збір, аналіз та створення формалізованих вимог на розробку, внесення змін до вимог) в проекті вирішуються бізнес-аналітиком. Стандартизовані вимоги до виконання аналізу предметної області наведені у посібнику до «Зводу знань з бізнес-аналізу» (Business Analysis Body of Knowledge, BABOK). Остання, третя, версія зводу знань вийшла у квітні 2015 р. і містить добре структуровану концептуальну модель бізнес-аналізу (BACCM, Business Analysis Core Concept Model). Ця модель  визначає шість базових концепцій:

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

Специфікація вимог користувачів (User Requirements Specification) або концепція (concept <of operation>) визначає високорівневі вимоги, часто – стратегічні цілі, для досягнення яких створюється програмна система. Важливо, що цей документ описує вимоги до системи з позицій предметної області – домену.

Специфікація системних вимог (System Requirements Specification, SyRS) – описує програмну систему в контексті системної інженерії. Зокрема високорівневі вимоги до програмного забезпечення, що містить кілька або багато взаємозв'язаних підсистем і застосувань. При цьому система може бути як цілком програмною, так і містити програмні та апаратні компоненти. У загальному випадку до складу системи може входити персонал, що виконує певні функції системи, наприклад, авторизацію виконання певних операцій з використанням програмно-апаратних підсистем.

Специфікація програмних вимог (Software Requirements Specification, SRS) встановлює основні угоди між користувачами (замовниками) і розробниками (виконавцями) стосовно того, що робитиме система і чого від неї не варто чекати. Цей документ може включати процедури перевірки створеного ПЗ  на відповідність  вимогам, що висуваються (у т.ч. плани тестування), описи характеристик стосовно якості та методів його оцінювання, питань безпеки тощо.

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

Функціональні вимоги (Functional Requirements, FR) – вимоги, що конкретизують функції, які система або її компонент повинен виконувати;

Нефункціональні вимоги (Non-Functional Requirements, NFR) – вимоги, що конкретизують уявлення по те, якою система повинна бути.

Види NFR:

1. Вимоги до інтерфейсу (Interface req)

2. Вимоги до апаратних і програмних платформ (Hardware/Software req), необхідніихдля роботи і підтримки системи

3. Вимоги щодо забезпечення якості (Operation req)

Відповідно до вимог регулюючих документів із системної інженерії ( із вріхуванням змін 2015 р.) в ході аналізу вимог мають бути сформовані два основних документа:

Специфікація вимог зацікавлених осіб (Stakeholder Requirements Specification, StRS) - документ, який фіксує вимоги зацікавлених осіб до рішення щодо забезпечення їх потреби із урахуванням роботи системи у реальному середовищі;

Специфікація системних вимог (System Requirements Specification, SyRS).

У BABOK виділяють наступні ролі зацікавлених осіб:

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

2.2        Проект із розроблення ПЗ

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

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

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

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

Проект виконується для досягнення певного результату в певні терміни і за певні гроші. Це тріо часу (time), бюджету (cost) і обсягу робіт (scope) часто називають проектним, або залізним, трикутником, оскільки при внесенні змін в один із цих елементів змінюються інші. Хоча для проекту однаковою мірою важливі всі три елементи, як правило, тільки один із них залежно від пріоритетів має найбільший вплив на інші.

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

Якість (quality) – це четвертий елемент проектного трикутника. Вона знаходиться у центрі, і будь-що зміна сторін впливає на неї.

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

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

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

2.2.1        Завдання (Tasks)

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

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

2.2.2        Фази (Summary tasks)

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

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

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

2.2.3        Тривалість (Duration) і трудовитрати (Work)

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

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

2.2.4        Залежності (Dependencies)  та зв'язки (Links)

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

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

2.2.5        Ролі (Roles) і ресурси (Resources)

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

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

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

2.2.6        Призначення (Assignments)

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

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

2.3        Основні форми планів робіт

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

На цей час доступна велика кілкість різноманітних інструментів організації проекту, які можуть працювати як оффлайн (Microsoft Project), так і онлайн (Bitrix24, Atlassian JIRA,  FreedCamp, Trello, GanttProject). Із розвитком гнучких підходів до організації проектів із розроблення програмних продуктів велику полулярність отримав канбан як метод візуального контролю та управління проектом. Одним із популярних   безкоштовних онлайн-засобів планування проекту у формі канбан є Trello.

2.3.1        План робіт у формі мережевого графіку

 

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

Переваги використання мережевого графіка при плануванні робіт полягають у такому:

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

2.3.2         План робіт у формі діаграми Ганта

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

Переваги використання діаграм Ганта при плануванні робіт полягають у такому:

2.3.3         Приклад використання мережевого графіка та діаграми Ганта

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

Перелічимо назви подій, тобто вузлів у графі, мережевого графіку:

  1. 1. Початок роботи.
  2. 2. Колектив сформований, робочі місця підготовлені.
  3. 3. Проектування ПЗ завершено.
  4. 4. Програмування завершено.
  5. 5. Комплексне налагодження завершене.
  6. 6. Обладнання закуплене.
  7. 7. Група з документування отримала опис проекту та необхідні пояснення від проектувальників.
  8. 8. Група із документування отримала опис ПЗ, розроблення проектної документації завершене.
  9. 9. Група із документування отримала всю необхідну інформацію про користувацькі інтерфейси, розроблення програмної документації завершене.
  10. 10. Група оцінки якості (Quality Assurance - QA) розробила тести.
  11. 11. Група QA оцінила проект позитивно.
  12. 12. Група QA завершила автономне тестування.
  13. 13. Група QA завершила комплексне тестування, отримала всю документацію та діючий варіант системи.
  14. 14. Перевірка якості завершена.
  15. 15. Закінчення роботи з розроблення ПЗ.

Під кожним ребром графа записана планована тривалість роботи (в тижнях).

Критичними шляхами є шляхи 1-6-2-3-4-5-9-13-14-15 та 1-6-2-3-4-5-12-13-14-15, тобто вся робота не може бути виконана швидше ніж за 18,3 тижня. Зрозуміло, що з точки зору оптимального завантаження колективу було б краще, щоб усі шляхи в графі від початку до кінця мали приблизно однакову тривалість для того, щоб якось зменшити довжину критичного шляху. Наприклад, є спокуса примусити групу QA проводити навіть початкове тестування, зменшивши навантаження на програмістів, робота яких знаходиться на критичному шляху. Але тоді важко визначити межі відповідальності, програмісти можуть для дотримання строків видавати «сирий» результат, і повернення на доопрацювання затягне проект ще більше. У реальних проектах, де робіт дуже багато, можна шляхом перерозподілу робіт покращувати мережевий графік.
 

Якщо уважно розглянути цей приклад, можна помітити, що невдало сплановані роботи між подіями 1, 2, 6. Колектив сформований за один тиждень, а робочі місця ще не готові. Група із документування має працювати на шість тижнів пізніше від проектувальників, а група QA має майже тритижневу перерву перед завершенням проектування та ін.

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

Для порівняння з мережевим графіком сформуємо діаграму Ганта для того самого прикладу.

Якщо в мережевому графіку наочно видно, як залежать роботи одна від одної, (наприклад, робота 12-13 може початися тільки після завершення робіт 5-12 і 11-12), то діаграма Ганта показує, що відбувається кожного конкретного тижня. Наприклад, видно, що група QA має перерву в роботі майже 2 тижні між роботами 11-12 (автономне тестування) та 12-13 (комплексне тестування). Саме тому керівники проектів віддають перевагу діаграмі Ганта: у кінці кожного тижня видно, які роботи проводились, що повинно закінчитися, а що розпочатися. Також на діаграмі Ганта прийнято над кожним відрізком роботи зазначати, скільки співробітників бере участь у цій роботі (на мережевому графіку це можливо, але не дуже зручно, оскільки треба зазначати ще й тривалість роботи). Ця властивість важлива для керівника проекту.

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

2.4        Керування та організація робіт

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

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

 

Коуберн так пояснює зміст цих складових:

  1. 1. Ролі (Roles) – визначення посади, що наводиться в оголошенні про роботу (наприклад, менеджер проекту, тестувальник, розробник інтерфейсу та ін.).
  2. 2. Уміння (Skills) – навички, які повинні мати претенденти на посаду.
  3. 3. Групи (Teams) – розподіл розробників за групами із визначенням їх ролей (наприклад, дизайнери, розробники документації, тестери та ін.).
  4. 4. Інструменти (Tools) – інструменти, які використовують розробники, відповідно до обраних технік та стандартів.
  5. 5. Техніки (Techniques) – техніки, які розробники використовують (наприклад, Java-програмування, моделювання варіантів використання та ін.).
  6. 6. Види діяльності (Activities) – зустрічі, відгуки, ключові точки (milestones) та інша діяльність, яку виконує або ініціює розробник.
  7. 7. Продукти (Work Products) – результат, що передають розробники або групи іншим розробникам або групам (наприклад, варіанти використання, визначення класів, визначення тестів, документація, визначення інтерфейсів та ін.).
  8. 8. Стандарти (Standards) – що дозволяється або не дозволяється для продуктів. Розрізнюють стандарти позначень, у тому числі і мови програмування, стандарти керування та прийняття рішень та  домовленості проекту. Деякі методології обирають  не всі стандарти одразу, а відкладають визначення деяких до певного етапу проекту.
  9. 9. Якість (Quality) – правила, запитання або зауваження, які необхідно відстежувати для кожного результату.

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

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

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

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

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

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

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

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

Баррі Боемом були сформульовані 10 основних ризків розроблення ПЗ:

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

Кент Бек (Kent Beck), батько методології eXtreme Programming, називає ризики основними проблемами розроблення програмного забезпечення, до яких він відносить:

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

Цікаві поради наведені в роботі Фредеріка Брукса (Frederick Brooks), що наголошує на тому, що при правильній організації добре підготованого колективу можна зменшити вірогідність зривів роботи та спрогнозувати їх появу заздалегідь, але якщо зрив вже стався – тільки особистий досвід та інтуїція керівника допоможуть знайти шлях вирішення проблем з мінімальними втратами.

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

Останнім часом велика увага приділяється забезпеченню легкості комунікацій в команді. Для організації взаємодії в проекті компанії застосовують як системи організації проектів (Microsoft Project, Bitrix24, Atlassian JIRA,  FreedCamp, Trello, GanttProject), так і месенджери, наприклад Slack, Viber, Telegram.

Також на стиль керування впливають ті стандарти, яких потрібно дотримуватися під час розроблення ПЗ. Ці стандарти можуть бути міжнародними, як ISO 12207, регіональними, як нормативні документи серії ГОСТ 34.х та 36.х, або стандартами підприємства, як наприклад, Oracle Unified Method  - стандарт компанії Оракл.

2.5        Забезпечення якості ПЗ

Якість програмного забезпечення (Software quality) асоціація IEEE визначає  як ступінь відповідності програмного забезпечення встановленій комбінації властивостей. У Міжнародному стандарті якості ISO 9000:2007 це поняття визначається як сукупність характеристик ПЗ, які забезпечують встановлені та очікуваі вимоги.

До характеристик якості ПЗ  відносять:

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

При виконанні цих заходів для кожного продукту перевіряються:

У 80-х рр. ХХ ст. розмір проектів із створення програмних систем зріс настільки, що вручну стало неможливо тестувати ПЗ, тому  активно стали розроблятися засоби автоматизації процесу тестування. Через дестиліття поняття якості ПЗ розширилося настільки, що було виділено окремий вид діяльності при створенні ПЗ – забезпечення якості (Quality Assurance, QA). На цей час автоматизоване тестування значно поширене, а засоби автоматизованого тестування часто вбудовані у середовище програмування.

Для виконання заходів забезпечення якості ПЗ розробники часто використовують спеціальні групи контролю якості, які мають назву QA. Група QA всередині компанії фактично виконує роль вимогливого користувача. У деяких компаніях заборонено неформальне спілкування між групою розробників та групою тестувальників. Від відповідальності групи QA залежить успіх продукту. Якщо ПЗ не сподобалося, з будь-яких причин користувачам продукт назавжди втрачає репутацію і споживача.

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

Фактично від того, на скільки якісно виконані початкові етапи розроблення ПЗ залежить його вартість. З метою підвищення якості розроблення та уникнення ризиків, пов’язаних із нечіткими або постійно змінюваними вимогами, і була створена методологія XP (eXtreme Programming).

Тестування (Software Testing) – діяльність, що виконується для оцінювання та поліпшення якості ПЗ. Ця діяльність базується на виявленні дефектів і проблем програмного забезпечення. Тестування ПЗ включає в себе діяльність із планування робіт (Test Management), проектування тестів (Test Design), виконнання тестування (Test Execution) та аналізу отриманих результатів (Test Analysis).

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

Для планування потрібно мати уявлення про потрібні обсяги тестування. У роботі наведені важливі статистичні дані щодо тестування:

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

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

Види тестування можна класифікувати за різними показниками:

1. За рівнем знання системи:

2. За об’єктом тестування:

3. За часом виконання тестування:

4. За ступенем ізольованості компонентів:

5. За ступенем автоматизації:

6. За ступенем підготовленості до тестування:

7. За ознакою позитивності сценаріїв:

Тестування, як і будь-який процес, повино мати методи оцінки якості тестування. Одним із способів є спосіб, якому в програму спеціально вставляється певна кількість помилок. Після проведення тестування оцінюється, скільки таких помилок було знайдено. Частка знайдених помилок показує якість тестування і допомагає оцінити, що обсяг робіт потрібно виконати для повного усунення проблем.

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

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

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

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

Дані з бази даних помилок дозволяють приймати рішення про можливість випуску програмного продукту (помилки з важливістю "crash" або з пріоритетом "highest/high" не дозволяють поставляти ПЗ). Якщо ПЗ обов’язково потрібно поставити замовнику, а часу на виправлення помилок немає, за домовленістю можна відкинути функції, які виконуються із помилками. 

Тема 2. Планування та керування Лекція 3. Керування та забезпечення якості
© 2023 СумДУ
created with Lectur'EDbeta