Лекція №1. Поняття вимог. Інженерія ПЗ

Які є причини провалу проекту?

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

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

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

Виявленням вимог займається аналітик; інколи у ролі аналітика виступають інші якісь спеціалісти: той самий менеджер, наприклад.

Фази розробки вимог:

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

2. Аналіз = встановлення пріоритетів, перевірка закінченості та цілісності;

3. Специфікація (створення документації);

4. Перевірка даних.

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

Першим кроком аналізу вимог є їх класифікація; потім встановлюється пріоритетність вимог. Класифікація вимог наступна: потім розкажуть.

· Бізнес-вимоги: шо се? Це вимоги, що відображають високорівневі цілі організації або замовників системи. Як правило, їх висловлюють ті, хто фінансує проект, замовники системи або ілврполірващ. Документ, що при цьому формується, містить цілі, які тре досягти і ше шось з того ж городу.

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

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

· Системні – це опис приблизних характеристик, яким повинен відповідати комп’ютер, для того щоб на ньому могло використовуватися розроблюване ПЗ.

Джерела вимог!!!!! :

1) Законодавство = це певні розпорядження, накази і тд, саме на державному рівні;

2) Нормативне забезпечення організації = це накази, установи, регламенти і тд, що фактично забезпечують роботу певної організації;

3) Представлення та очікування користувачів системи;

4) Журнали використання існуючих програмних систем;

5) Конкуруючі програмні продукти;

6) + усякі там діаграми (було шось, а ми хтю се вдосконалити).

Методи виявлення вимог:

§ Інтерв’ю, опитування та анкетування;

§ Спостереження за виробничою діяльністю (фотографування робочого місця, дня…);

§ Мозковий штурм;

§ Аналіз нормативної документації;

§ Аналіз конкурентних продуктів;

§ Аналіз статистики використання попередніх версій системи.

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

Управління вимогами – це процес виявлення, документування, аналізу, відстеження та визначення пріоритетності вимог.

Параметри якісних вимог:

ü Повнота

ü Коректність

ü Здійсненність

ü Необхідність

ü Пріоритетність

ü Недвозначність

ü Можливість перевірки

Документування вимог!!!!! Стандарт ІЕЕЕ 830 (’98 року) + наші, ’78 (єдина система програмної документації) і ‘89 (про документацію автоматизованих систем) років.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Середовища.	\|	Лекція №2. Розробка концепції вимог

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.013 сек.