ІПЗ

Лекція 5-6
Проблеми при написанні технічного завдання
- при здобутті освіти в ІТ, багато часу присвячується кодінгу і тестуванню, а
проектування вимог дуже часто ігнорується
- некоректне технічне завдання впливає на весь подальший процес
розробки
- вимоги до розробки можуть суперечити тому, що уявляв собі клієнт
- вимоги до розробки можуть бути недостатніми для опису того, що уявляв
собі клієнт
- вимоги до розробки можуть бути нечіткими, тому ми не зможемо
встановити, чи правильно розроблене наше ПЗ
- “нефункціональні вимоги”
Джерела помилок при інженерії ПЗ та ціна їх
виправлення
Джерела помилок при ІПЗ
1. Етап технічного завдання - найбільше
2. Етап проектування - трохи менше
3. Розробка - ще менше
4. Тестування - ще менше Відносна вартість виправлення помилки
1. Етап технічного завдання - 1.0
2. Етап проектування - 5.0
3. Розробка - 10.0
4. Тестування - 30.0
Процес створення технічного завдання на ПЗ
Середовище, розуміння проблеми і основні цілі -> деталізований список
вимог, що однозначно описує систему.
Простий програмний продукт для одного ПК -
запитання, на які слід відповісти
- яка апаратна платформа буде використана?
- яка операційна система буде використовуватися?
- які версії операційної системи будуть використовуватися?
- якщо ми хочемо робити ПЗ кросплатформенним, то які платформи будуть
підтримуватися?
- які формати файлів буде використовувати програма (вхід, вихід, внутрішнє
зберігання)
- чи буде програма мати графічний інтерфейс?
- чи графічний інтерфейс буде сумісний із версією ОС, яку ви використовуєте?
- чи є якісь вимоги до стандартів інтерфейсів?
- чи є якісь мінімальні та рекомендовані системні вимоги до апаратного
забезпечення?
Простий програмний продукт для одного ПК -
запитання, на які слід відповісти

- які вимоги до місця на жорсткому диску або SSD?

- чи буде ваша програма спричиняти проблеми у функціонуванні інших
програм на даному комп’ютері?
- чи є якісь програмні пакети, з якими ми маємо взаємодіяти?
- чи буде у програми онлайн-підтримка
- як ви будете постачати клієнту програмний продукт?
- чи буде ПЗ стискатися перед тим як доставляти його клієнту?
- чи потрібен окремий пакет ПЗ для того, аби встановлювати програму?
- чи потрібне буде навчання навчання персоналу?
- чи є якісь ліміти по часу розробки всередині цілого проекту?
Відслідковування виконання технічних вимог
На кожному подальшому етапі (розробка, реалізація, тестування) ми маємо
перевіряти, як конкретна вимога стосується даного етапу.
Основні поради щодо застосування технічних вимог
- абстракція даних - це ключ до того, що ваша програма буде працювати в
якнайменшій залежності від платформи
- групування технічних вимог у відповідності із компонентами програмного
забезпечення
- використовуйте повторно технічні вимоги із інших проектів
- автоматизація процесу складання технічних вимог
Use case діаграми на допомогу складанню технічних
вимог
1. Користувач певної ролі
2. Дії, які виконує даний
користувач
3. Сервіси, які забезпечують цю
дію
User stories
Роль - Дія - Результат дії

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

as (user role), I should be able to (action) so I can have (result)

Повторне використання технічного завдання
1. Узгодьте основний процес технічних вимог із клієнтом.
2. Узгодьте, чи поточна система, яку ви повторно хочете використати,
співпадає з цими вимогами.
3. Якщо такої системи немає, перегляньте, чи є у вас система, яка
відповідає МАЙЖЕ всім вимогам.
4. Якщо такої системи немає, нам потрібно виділити вимоги, які не
співпадають (або співпадають), у підсистему (при можливості)
5. Для кожної підсистеми, повторюються кроки 2-4.
6. Всі зміни та використані повторно фрагменти мають обов’язково бути
узгоджені з клієнтом.
7. Коли всі зміни погоджено, ми можемо формувати нові технічні вимоги на
основі старих.
Оцінка технічного завдання
- обов’язковість вказання платформ, пристроїв що будуть
використовуватися
- обов’язковість розподілу ролей
- відсутність протиріч між різними частинами технічного завдання
- вимоги не мають робити систему надто дорогою
- технічні вимоги завжди мають фокусуватися в першу чергу на безпеці
системи для того, щоб критичні частини системи не були вразливими.
Вимоги, що встановлюються до інтерфейсу
користувача
1. Визначаємо основні рекомендації
2. Визначаємо рекомендації, що стосуються безпосередньо нашого ПЗ.
3. Визначаємо правила розробки відповідно до цих рекомендацій
4. Дозволяємо можливі зміни до цих правил, якщо вони чітко обгрунтовані
Діаграми станів
Метрики технічних вимог
1. кількість окремих технічних вимог
2. сума всіх вимог щодо функціоналу, описаних в одній конкретній вимозі
3. відповідність нових вимог вимогам систем, які були спроектовані раніше
4. кількість інтерфейсів програми
Перегляд технічних вимог
- кількість помилок та неточностей у вимогах, що призвели до затримки у
виконанні
- кількість помилок та неточностей у вимогах, що не збільшили час
виконання та використання інших ресурсів
- відсоток технічних вимог, які ми можемо використати повторно
Структура технічних вимог
1. Вступ
2. Загальний опис системи
3. Опис поділу на підсистеми
4. Опис технічних вимог кожної із підсистем
5. Опис інтерфейсу кожної із підсистем
6. Референси
7. Пропонований графік виконання
8. Ризики та їх менеджмент
9. Підсумки