Основні питання



Скачати 41,69 Kb.
Дата конвертації03.04.2017
Розмір41,69 Kb.
  • Модуль 2. Основи інженерії вимог Лекції 6-8 Загальний обсяг 6 год.
  • Вступ до програмної інженерії

Основні питання

  • Класифікація вимог до програмного забезпечення та програмних систем.
  • Специфікація вимог
  • Що означає процес формулювання вимог?

Класифікація вимог до програмного забезпечення та програмних систем.

  • Класифікація вимог до програмного забезпечення та програмних систем.
  • Специфікація вимог
  • Що означає процес формулювання вимог?

Класифікація вимог.

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

Приклад функціональних вимог для підсистеми “бронювання місць у готелі”

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

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

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

Приклад не функціональних вимог для підсистеми “бронювання місць у готелі”

    • Вимоги до продукту
      • Усі взаємодії між інтерфейсом середовища програмування та користувачем здійснюються на основі стандартної множини символів мови С++.
    • Організаційні вимоги
      • Розробка системи та супровідної документації здійснюється на основі стандарту ДСТУ-95
    • Зовнішні вимоги
      • Системні оператори не повинні мати доступу до інформації про паспортні дані, платіжні можливості осіб, що забронювали номер.

Кількісні показники для не функціональних вимог.

  • Швидкодія
    • К-ть транзакцій за секунду;
    • Час реакції на дії користувача, обновлення екрану;
  • Об'єм пам'яті
  • Складність експлуатації
    • Час навчання персоналу
    • Обсяг довідкової системи
  • Надійність
    • Проміжок часу між послідовністю помилок
    • Ймовірність виходу з ладу
  • Стійкість до збоїв
    • Час відновлення після збою;
    • Відсоток подій, що призводять до збоїв;
    • Ймовірність спотворення чи втрати даних при збоях;
  • Можливість перенесення в інші середовища
    • Відсоток машинно-залежних операторів;
    • К-ть машинно-залежних підсистем;.

Функціональні та не функціональні вимоги предметної області

  • Проблеми опису- використовується мова та позначення даної предметної області.
      • ускладнення розуміння розробниками ПЗ
  • Нові функціональні вимоги;
    • Приклад: Данні про особу, яка бронювала місця повинні вилучатися після виконання замовлення та друку платіжних документів.
  • Нові чи додаткові обмеження на виконання функцій;
    • Приклад: Користувацький інтерфейс базується на інтерфейсі 1С Бухгалтерія.
  • Вказівки на порядок проведення обчислень
    • Приклад: Нарахування оплати проводиться за формулою…

Класифікація вимог за рівнями

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

Вимоги користувачів

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

Приклади опису вимог користувачів

  • Приклад для опису вимог ПС для екологічного моніторингу
    • 3.1. Вимоги до підсистеми виведення полів концентрацій шкідливих викидів.
    • Для визначення значення концентрації шкідливих викидів у точці, користувач повинен мати можливість виводити сітку, параметри, якої задаються: крок вертикальних ліній - в метрах чи кілометрах; горизонтальних – в мг/м.куб чи мікр.г./м.куб шляхом вибору опції на панелі управління. По замовчуванню сітка не відображається. Крок сітки настроюється автоматично під розмір ділянки та рівня концентрацій.
  • У прикладі змішано різні вимоги, зокрема:
    • Важлива функціональна вимога: “Система повинна надавати можливість виведення сітки”
    • Не функціональна вимога (обмеження на функцію): “Стосовно того в яких одиницях буде вимірюватися крок горизонтальних та вертикальних ліній”
    • Нефункціональна вимога “стосується інтерфейсу - у який спосіб користувач буде вибирати режими відображення /невідображення сітки”

Приклад реалізації інтерфейсу до підсистеми виведення полів концентрацій шкідливих викидів

  • Показати сітку
  • Вибрати крок гор. ліній
  • Вибрати крок верт. ліній
  • км
  • мг/мкуб

Уточнення вимог до підсистеми виведення полів концентрацій шкідливих викидів

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

Системні вимоги

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

Класифікація вимог до програмного забезпечення та програмних систем.

  • Класифікація вимог до програмного забезпечення та програмних систем.
  • Специфікація вимог
  • Що означає процес формулювання вимог?
  • Класифікація вимог до програмного забезпечення та програмних систем.
  • Специфікація вимог
  • Що означає процес формулювання вимог?

Способи специфікації системних вимог

  • Структурована природна мова
  • Мови опису програм
    • Структуровані мови, подібні до мов програмування
  • Графічні нотації
    • Діаграми, блок-схеми, описані текстом.
      • Використання UML
  • Математичні специфікації
    • Базуються на теорії скінченних автоматів та теорії множин.

Структурована природна мова

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

Приклад специфікації структурованою природною мовою

  • Функція: Внесення джерела забруднень на карту
  • Опис: Внесення додаткових джерел забруднення на існуючу карту міста. Користувач вибирає тип джерела забруднень та координати його розміщення переміщенням курсору миші по карті.
  • Вхідні дані: Тип джерела, позиція на карті, розміри СЗЗ, ідентифікатор карти
  • Джерела даних: Тип джерела, позиція на карті, задаються користувачем, розміри СЗЗ, ідентифікатор карти – з баз даних, відповідно “довідники СЗЗ” та “карти”
  • Вихідні дані: ідентифікатор карти.
  • Пункт призначення: база даних “карти”. Ідентифікатор розміщується після завершення функції.
  • Для виконання функції необхідна карта, яка визначається вхідним ідентифікатором.
  • Передумова: карта відкрита на екрані користувача.
  • Післяумова: карта не змінюється за виключенням нанесеного об'єкта.
  • Побічні ефекти : відсутні.

Документування системних вимог

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

Складові специфікації системних вимог (стандарт IEEE/ANSI 830-1993)

  • Передмова
    • Особи, для яких розробляють документ;
    • Попередні версії та зміни внесені в ПЗ
    • Обґрунтування нової версії
  • Вступ
    • Потреби в створенні системи
    • Системні функції та пояснення роботи із іншими системами
    • Пояснення, який ефект для організації після впровадження системи
  • Глосарій – опис технічних термінів документу
  • Вимоги користувачів
    • Опис сервісів (функцій), які надаються користувачу;
    • Не функціональні системні вимоги;
    • Стандарти на ПЗ та на процес створення;
  • Системна архітектура
    • Високорівневе представлення архітектури із розподілом функцій по компонентах системи із виділенням існуючих компонент
  • Системні вимоги: Функціональні та не функціональні
  • Системні моделі
    • Показують взаємодію між компонентами та зовнішнім середовищем
    • Типи: моделі потоків даних; об'єктні; моделі даних
  • Еволюція системи
    • Припущення на яких базується система
    • Зміна апаратних засобів, необхідна для реалізації системи
    • Зміна системи відповідно до потреб користувачів в майбутньому
  • Додатки
    • Опис апаратних засобів (мінімальна та максимальна конфігурація) та баз даних(логічна структура із якою працюватиме ПЗ) із якими працюватиме система

Підсумки Класифікація вимог до програмного забезпечення та програмних систем. Специфікація вимог

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

Класифікація вимог до програмного забезпечення та програмних систем.

  • Класифікація вимог до програмного забезпечення та програмних систем.
  • Специфікація вимог
  • Що означає процес формулювання вимог?
  • Класифікація вимог до програмного забезпечення та програмних систем.
  • Специфікація вимог
  • Що означає процес формулювання вимог?

Особливості процесу формулювання вимог.

  • Діючі особи процесу
    • Замовники, чи носії їх інтересів;
    • Користувачі системи (оператори, обслуговуючий персонал);
    • Розробники системи.
  • Основні етапи процесу:
    • Аналіз технічної можливості створення системи
      • Звіт про технічну можливість створення;
    • Формування та аналіз вимог;
      • Моделі системи;
    • Специфікація вимог
      • Вимоги користувачів та системні вимоги
    • Атестація вимог.
      • Документація зі специфікацією вимог.

Аналіз технічної можливості створення системи

  • Чи система відповідає загальним і функціональним цілям замовника та розробника?
  • Чи можливою є її реалізація із використанням існуючих технологій і не виходячи за межі розумної вартості?
  • Чи можливо об'єднати розроблювану систему із існуючими в експлуатації?
  • Аналіз технічної можливості також включає:
    • Які зміни відбудуться в організації, якщо система буде введена в дію?
    • Які існують поточні проблеми в організації і як з допомогою нової системи вони можуть бути розв'язані?
    • Яким чином система буде забезпечувати функціональні цілі?
    • Чи може бути система створена в межах технологій, які раніше використовувалися в даній організації?
    • Які джерела інформації необхідно використати для отримання відповіді на поставленні запитання?

Формування та аналіз вимог

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

Етапи формування та аналізу вимог

  • Особливості - процес є циклічним із зворотними зв'язками від одного етапу до іншого
    • Аналіз предметної області
    • Збирання вимог
    • Класифікація вимог
    • Розв'язування протиріч при формуванні вимог
    • Призначення приорітетів по вимогах
    • Перевірка повноти та не протиріч по вимогах

Основні підходи до формулювання вимог

Метод опорних точок зору

  • Особливості: Різні типи користувачів та розробників-різні точки зору, інтереси та вимоги.
  • Точки зору слід розглядати:
    • Як користувачів системи
    • Як джерело інформації про системні дані;
    • Як структуру представлень – особлива частина моделі;
    • Як отримувачів системних сервізів – визначають данні для виконання системних сервізів;
  • Переваги: Багато поглядів забезпечує базу для знаходження протиріч у вимогах.
  • Недоліки: Складність використання в процесі структурного аналізу, оскільки відсутні зв'язки між точками зору.

Зовнішні опорні точки зору (viewpoint-oriented requirements definition)

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

Метод сценаріїв

  • Особливості:
    • Спосіб доступного опису взаємодії з ПС;
    • Корисні для деталізації опису вимог;
    • Надають інформацію для деталізації різних рівнів системи.
  • Етапи:
    • Опис стану системи перед початком реалізації сценарію;
    • Опис нормального слідування подій;
    • Опис виключних подій та способів їх опрацювання;
    • Опис інших дій, які можливо виконати під час виконання сценарію;
    • Опис стану системи після завершення сценарію.
  • Варіанти описів:
    • Сценарії подій (на прикладі методу VORD);
    • Варіанти використання (на прикладі UML)

Сценарії подій (на прикладі методу VORD);

  • Особливості:
    • Кожна подія документується як сценарій;
    • Описуються: потоки, системні операції та особливі події, що можуть виникнути.
  • Використовуються такі елементи:
    • Дані, що поступають чи виходять із системи
    • Опис системних операцій
    • Інформація для управління
    • Внутрішньо системні дані
    • Особливі ситуації
    • Наступна подія після завершення сценарію
  • Pin-код
  • Запит Pin-кода
  • Запит Pin-кода
  • Підтвердження
  • Запит Pin-кода
  • Номер рахунку
  • Запит Pin-кода
  • Невірний Рin
  • Повторне введ.
  • Вибір сервісу

Варіанти використання (на прикладі UML)

  • Особливості:
    • Використовуються для опису об'єктних моделей систем;
    • Описуються: діючі особи, тобто користувачі та назви типів взаємодії.
    • Зауваження: на початкових стадіях без конкретизації потоків подій

Етнографічний метод

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

Атестація вимог.

  • Мета: Перевірка, що вимоги визначають ту систему, яка відповідає баченню замовника
  • Реалізується різними типами перевірок: достовірності; непротирічності; повноти; реальності виконання.
  • Методи атестування вимог:
    • Системний аналіз рецензентами;
    • Прототипування;
    • Генерування тестових завдань та їх аналіз
    • Автоматизований аналіз непротиріч
      • Можливе застосування, коли вимоги представлені у вигляді структурних чи формальних системних моделей.

Підсумки Особливості процесу формулювання вимог

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


База даних захищена авторським правом ©vaglivo.org 2016
звернутися до адміністрації

    Головна сторінка