LECT / Ризики

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

• дефіцит фахівців;

• нереалістичні терміни і бюджет;

• реалізація невідповідної функціональності;

• розроблення неправильного користувальницького інтерфейсу;

• перфекціонізм, непотрібна оптимізація і відточування деталей;

• безперервний потік змін;

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

• недоліки робіт, виконуваних зовнішніми (по відношенню до проекту) ресурсами;

• недостатня продуктивність роробленої системи;

• "розрив" у кваліфікації фахівців різних галузей знань.

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

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

• зміщення графіків;

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

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

• велика кількість дефектів і недоліків не дозволяють замовникові використовувати систему;

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

• зміна характеру бізнесу – ПЗ втратило актуальність;

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

• плинність кадрів.

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

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

А.Коуберн пропонує розділяти системи на чотири групи залежно від рівня можливих втрат:

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

• втрата незначної суми матеріальних ресурсів, наприклад, неправильне нарахування заробітної плати автоматизованою системою можна виправити у ручному режимі;

• матеріальні втрати не можна відшкодувати, наприклад, збій системи національного банку країни;

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

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

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

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

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

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

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

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

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

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

• надійність – стійкість до відмов, можливість відновлення, завершеність;

• ефективність – економія часу, ефективність використання;

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

• зручність для супроводу – стабільність, придатність для контролю та внесення змін;

• портативність – зручність установки, можливість заміни, сумісність.

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

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

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