• 2.1                      Керування та організація робіт
• 2.2                      Забезпечення якості ПЗ

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

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

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

 

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

1. Ролі (Roles) – визначення посади, що наводиться в оголошенні про роботу (наприклад, менеджер проекту, тестувальник, розробник інтерфейсу та ін.).

2. Уміння (Skills) – навички, які повинні мати претенденти на посаду.

3. Групи (Teams) – розподіл розробників за групами із визначенням їх ролей (наприклад, дизайнери, розробники документації, тестери та ін.).

4. Інструменти (Tools) – інструменти, які використовують розробники, відповідно до обраних технік та стандартів.

5. Техніки (Techniques) – техніки, які розробники використовують (наприклад, Java-програмування, моделювання варіантів використання та ін.).

6. Види діяльності (Activities) – зустрічі, відгуки, ключові точки (milestones) та інша діяльність, яку виконує або ініціює розробник.

7. Продукти (Work Products) – результат, що передають розробники або групи іншим розробникам або групам (наприклад, варіанти використання, визначення класів, визначення тестів, документація, визначення інтерфейсів та ін.).

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

9. Якість (Quality) – правила, запитання або зауваження, які необхідно відстежувати для кожного результату.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• на 1000 рядків коду програміст у середньому робить 100 помилок, 70% з яких усуваються на стадії налагодження коду;
• при системному тестуванні у відділі контролю якості на ліквідацію однієї помилки потрібно від чотирьох до шістнадцяти годин;
• для усунення помилки, що була виявлена у ході експлуатації, потрібно від 33 до 88 годин.

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

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

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

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

• чорний ящик (Black-box testing) – без перегляду програмного коду;
• білий ящик (White-box testing) –  тестування із вивченням коду програми;
• сірий ящик (Gray-box testing) – тестування із частковим вивченням коду програми.

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

• функціональне (Functional testing) – перевірка виконання заданих функцій;
• тестування продуктивності (Performance testing) – перевірка стабільності роботи програми або її частини при заданому навантаженні (Load testing), при перевантаженні (Stress testing) та тривалому середньому навантаженні (Stability testing);
• юзабіліті-тестування (Usability testing) – перевірка ергономічності ПЗ;
• перевірка інтерфейсу користувача (UI testing);
• перевірка безпеки (Security testing) – тестування роботи системи з точки зору безпеки інформації;
• тестування сумісноті (Compatibility testing) – нефункціональне тестування, метою якого є перевірка коректної роботи ПЗ у певному оточенні.

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

• альфа-тестування (Alpha testing) – перевірка роботи ПЗ перед передачею в експлуатацію силами компанії-розробника;
  • півгодинне тестування (Smoke testing) – коротка перевірка функцій системи, як правило, один тест для кожної функції;
  • тестування нової функціональності (New feature testing);
  • регресійне тестуванн (Regression testing) – перевірка роботи вже протестованих модулів;
  • тестування під час передачі ПЗ (Acceptance testing);
• бета-тестування (Beta testing) – тестування ПЗ сторонніми силами перед випуском продукту.

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

• компонентне тестування (Component / Unit testing) – перевірка коректності окремого модуля або компонента системи;
• інтеграційне тестування (Integration testing) – перевірка роботи модулів, об’єднаних у групу;
• системне тестування (System / end-to-end testing) – перевірка роботи зібраного ПЗ з метою встановлення відповідності очікуваним функціям.

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

• ручне тестування (Manual testing);
• автоматизоване тестуванняя (Automated testing);
• напівавтоаматизоване тестування (Semiautomated testing).

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

• формальне тестування (Formal testing) – тестування відповідно до плану, встановлених процедур;
• інтуїтивне тестування (Ad hoc testing) – тестування без попереднього плану дозволяє на раніх стадіях виявляти помилки.

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

• перевірка позитивних сценаріїв (Positive testing);
• перевірка негативних сценаріїв (Negative testing).

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

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

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

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

• хто знайшов помилку,коли;
• опис помилки;
• модуль, у якому була знайдена помилка;
• версія продукту;
• статус помилки:

• open: знайдена;
• fixed: виправлена;
• can't reproduce: неможливо повторити;
• by design: помилка проектування;
• wont fix: не помилка;
• postponed: зараз виправити важко, буде виправлена у наступній версії;
• regression: виправлена помилка з’явилася знову;

• важливість (severity) помилки:

• сrash: повна втрата даних;
• major problem: програма частково не працює, часткова втрата даних;
• minor problem: програма працює не так, як очікувалось, але дані не втрачаються;
• trivial: зараз не потрібно виправляти;

• пріоритет помилки:

• highest: не можна поставити продукт із такою помилкою, не можна перейти до наступної версії;
• high: поставити не можна, але можна перейти до наступної версії;
• medium: помилка буде виправлена;
• low: косметичні поліпшення – помилка залишиється до наступної версії.

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

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