Лекція №3. Процеси призначення системи

Група процесів призначення системи є мостом між визначенням концепції і встановленням вимог до програмного забезпечення. Складається з таких підпроцесів:

1) Аналіз функцій – вхідні дані = рекомендації та сформульовані потреби, отримані на етапі вивчення концепції; вихідні дані = функціональний опис системи. Сформульовані потреби та рекомендації повинні бути проаналізовані з метою визначення функцій усієї системи. Як тільки функції визначаються, вони відображаються або описуються у документі під назвою «функціональний опис системи» і використовується при розробці системної архітектури та при визначені функцій програмного і апаратного забезпечення.

2) Розробка системної архітектури – вхідні дані = формулювання потреб і функціональний опис системи; вихідні дані = системна архітектура. Сформульовані вимоги (потреби) і функціональний опис системи повинні бути перетворені у системну архітектуру з використанням стандартів, інструментів та методологій, що встановлюються організацією.

3) Декомпозиція системних вимог – вхідні дані = функціональний опис системи та системна архітектура; вихідні дані = функціональні вимоги до розроблюваного ПЗ (ІЕЕЕ1253).

До групи процесів імпортування програмного забезпечення (ІЕЕЕ1062) відносяться:

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

2) Оцінка джерел імпорту – вхідні дані = вимоги до ПЗ, що імпортується; вихідні дані = виділені джерела імпорту. Доступні джерела мають бути оцінені відносно відповідності доступного ПЗ певним вимогам, наявності, термінам та якості джерела.

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

4) Імпорт ПЗ – вхідні дані = виділені джерела імпорту ПЗ та виділена методи; вихідні дані = імпортоване ПЗ та його документація.

Лекція №4. Процеси встановлення вимог. Загальний зміст специфікації вимог до програмного забезпечення

Серед процесів встановлення вимог виділяють:

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

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

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

Зміст специфікації вимог до ПЗ

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

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

Основні питання, що розглядаються:

ü Функціональні можливості системи

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

ü Робочі характеристики системи: швидкодія та доступність

ü Атрибути системи: захищеність системи, зручність для користувачів різних груп

ü Можливі проектні обмеження, що накладаються на систему

Основні переваги використання специфікації вимог наступні: для замовника це є точний опис того, що він хоче отримати; а для розробника це є однозначне тлумачення і розуміння того, що хоче отримати замовник

Мета створення специфікації вимог – надати замовнику та іншим учасникам проекту ряд переваг:

1) Створити основу для угоди між замовником та розробником про набір функцій, які повинна виконувати система

2) Оптимізувати обсяг робіт з розробки системи (специфікація ця змушує учасників проекту строго розглянути усі вимоги перед тим як приступати до виконання, і скорочує витрати на повторні проектування, кодування та тестування)

3) Забезпечити основу для оцінки витрат та планів

4) Забезпечити основу для контролю якості розроблюваного продукту

5) Полегшити розгортання та тиражування системи

Характеристики правильно складеної специфікації вимог до ПЗ = специфікація ця має бути:

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

· Однозначною = якщо кожна викладена у ній вимога інтерпретується однозначно

· Повною = якщо специфікація включає наступні елементи:

1) Усі існуючі вимоги, незалежно від того чи відносяться вони до функціональних, не функціональних і т.д.

2) Визначення, позначення і посилання на усі малюнки, таблиці і схеми, та визначення усіх термінів та одиниць виміру

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

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

· Упорядкованою за її значимістю та стійкістю = коли кожна вимога у специфікаціє має ідентифікатор, що вказує значимість конкретної вимоги. Як правило усі вимоги до ПЗ не є важливими у рівній мірі: деякі вимоги можуть бути необхідними, а деякі – бажаними.

· Перевіряємою = коли кожну вимогу можна перевірити

· Модифікованою = якщо її структура та стиль такі, що будь-які зміни вимог можуть бути виконані легко, повністю і несуперечливим чином при збереженні відповідної структури та стилю

· Відслідковуваною = коли чітко простежуються джерела кожної з її вимог

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

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

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

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