19. Функціональна і адміністративна організація роботи колективів для розробки програмних проектів.

Функціональні вимоги.

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

Неспеціалізована мова часто використовується для опису вимог, але при цьому є деякі незручності:

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

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

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

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

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

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

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

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

Нефункціональні вимоги.

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

· вимоги продукту, наприклад “можуть використовуватися тільки клавіатура і миша“;

· вимоги процесу, наприклад “система повинна виконувати за стандартом XXA/2002” ;

· зовнішні вимоги, наприклад “система повинна працювати з базою даних, описаною в документі YYYB/2001, і ніякі зміни в базі даних недопустимі”.

Атрофовані вимоги повинні бути кількісними, тобто повинен існувати метод перевірки виконання умов. Такі вимоги як: “зручний”, “надійний”, “ефективний” не можуть бути перевірені, отже, вони не відповідають формулюванню.

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

Можна виділяти такі вимоги до програм:

1. Правильність.

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

Загальноприйнятою є така класифікація програмних помилок:

· синтаксичні, які пов’язані з порушенням формальних граматичних правил написання програм. Синтаксичні помилки виявляються на етапі компіляції;

· помилки часу виконання.

Ці помилки знову ж-таки поділяються на такі категорії:

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

· програма не доходить до кінця. Вона працює нескінченно довго або зависає;

· програма видає неправильні результати.

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

2. Ефективність.

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

3. Надійність.

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

4. Універсальність.

Програма повинна бути розрахована на широкий діапазон вхідних даних і при можливості – на широкий спектр задач.

5. Функціональність.

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

6. Зручність у використанні.

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

7. Стандартизованість.

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

8. Переносимість.

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

9. Читабельність.

Тексти програм повинні бути максимально простими для сприйняття і розуміння людиною.

10. Модифікованість.

Програма повинна передбачати можливість для змін і доповнень.

11. Документованість.

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