Вступ до курсу «Технології розробки програмного забезпечення».

Інженерія вимог до програмного забезпечення

 

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

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

Область знань «Вимоги до ПЗ (Software Requirements)» складається з таких розділів:

· інженерія вимог (Requirement Engineering);

· виявлення вимог (Requirement Elicitation);

· аналіз вимог (Requirement Analysis);

· специфікація вимог (Requirement Specification);

· валідація вимог (Requirement validation);

· керування вимогами (Requirement Management).

Інженерія вимог до ПЗ – це дисципліна аналізу і документування вимог до ПЗ, що полягає в перетворенні запропонованих замовником вимог до системи на опис вимог до ПЗ і їх валідації.

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

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

Специфікація вимог до ПЗ – процес формалізованого опису функціональних і нефункціональних вимог, вимог до характеристик якості відповідно до стандарту якості ISO/IEC 9126, які будуть відпрацьовуватися на процесах ЖЦ ПЗ.

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

Керування вимогами – це керування процесами формування вимог на всіх процесах ЖЦ, а також змінами й атрибутами вимог, проведення моніторингу – відновлення джерела вимог.

 

Вступ до курсу «Технології розробки програмного забезпечення».

 

Кожна людина, яка хоч раз написала якусь програму, досить добре може уявити собі, як розробити «невелику» програму, котра вирішає зазвичай одну конкретну нескладну задачу і призначену, найчастіше, для використання однією людиною або вузькою групою людей. Прикладом такої програми може служити програма, що обчислює досить багато (але не занадто, <= 30000) знаків числа π.

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

Зазвичай складна програма має такі властивості:

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

· істотно, щоб вона була зручною у використанні. Зокрема, вона повинна включати досить повну і зрозумілу користувачам документацію, можливо, також спеціальну документацію для адміністраторів, а також набір документів для навчання роботі з програмою;

· її низька продуктивність на реальних даних призводить до значних втрат для користувачів;

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

· для виконання своїх завдань вона повинна взаємодіяти з іншими програмами та програмно-апаратними системами, працювати на різних платформах;

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

· у її розробку залучено значну кількість людей (більше 5-ти чоловік). «Велику» програму практично неможливо написати з першої спроби, з невеликими зусиллями і поодинці;

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

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

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

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

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

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

Важливо відзначити, що практично корисна складна програмна система не обов'язково є «правильною». Більшість досвідчених розробників програм і дослідників вважають, що практично значущі програмні системи завжди містять помилки. При переході від «невеликих» програм до «великих» поняття «правильної» програми стає практично безглуздим. Про програмну систему, на відміну від наведеної вище програми обчислення числа π, не можна стверджувати, що вона «правильна», тобто завжди правильно вирішує всі поставлені перед нею завдання. Цей факт пов'язаний як з практичною неможливістю повністю це довести або перевірити це, так і з тим, що сенс існування програмної системи - задоволення потреб і запитів великої кількості різних зацікавлених осіб. А ці потреби не тільки нечітко визначені, різні для різних груп користувачів і іноді суперечливі, або й значно змінюються з плином часу.

У зв'язку з цим, замість розгляду «правильних» і «неправильних» програмних систем, в силу практичної відсутності перших, розглядають «досить якісні» і «недостатньо якісні».

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

Часто програмне забезпечення (ПЗ) можна розглядати окремо від програмно-апаратної системи, куди воно входить в якості складової частини. Вивченням питань, пов'язаних з розробкою та експлуатацією програмно-апаратних систем займається системна інженерія. У її рамки потрапляє величезна кількість проблем, пов'язаних з апаратною частиною систем і забезпеченням потрібного рівня інтеграції програмної та апаратної складових.

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

Крім того, особливу увагу потрібно приділити одному з підходів до розробки складного ПО, компонентної розробки, що пропонує будувати такі системи послідовно з окремих елементів - компонентів, кожен з яких, у свою чергу, може бути розглянутий як окрема програмна система. Це дає введення в сучасні компонентні технології розробки програмних систем на основі платформ J2EE і. NET.

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

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

Протест спільноти розробників проти подібної бюрократизації розробки програм і спроб механічного використання теоретичних рекомендацій вилився в популярний зараз рух живої розробки ПЗ (Agile Software Development). Одним із прикладів «живого» процесу розробки є набір технік, відомий як екстремальне програмування (Extreme Programming, XP).