8.Вимоги

Вимоги - це

- твердження про функції та обмеження ПЗ

- властивості, які повинно мати ПЗ, щоб представляти цінність для користувачів

- специфікація того, що і як має бути реалізовано

Згідно міжнародних стандартів вимоги мають містити опис:

- умов чи можливостей, які необхідні користувачу для того, щоб розв’язати поставлені проблеми або досягти мету;

- функцій та обмежень, яким повинно задовольняти ПЗ для виконання договору із замовником на розробку ;

- положень та регламенту використаних стандартів, що відображаються у специфікаціях та інших документах;

- документованого представлення умов на проектування.

Вимоги до ПЗ складаються з:

- вимог користувачів (user requirements);

- системних вимог (system requirements);

- нефункціональних вимог (non-functional requirements);

- функціональних вимог (functional requirements).

Вимоги користувачів – базуються на цілях та задачах, які розроблюване ПЗ дозволить розв’язувати. Представляються за допомогою варіантів використання, сценаріїв, таблиць “подія – відгук” та інш.

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

Стандарт IEEE 1233 є одним із визнаних керівництв з розробки системних вимог.

Не функціональні вимоги (Non-Functional Requirements)

- Бизнес-правила (Business Rules) – визначають обмеження, які залежать від предметної області та властивостей автоматизованого об’єкта.

- Зовнішні інтерфейси (External Interfaces)

- Атрибути якості (Quality Attributes) – описують додаткові характеристики продукту в різних «вимірах», важливих для розробників та/або користувачів.

- Обмеження (Constraints) – формулювання умов, модифікуючих вимоги чи набори вимог, звужуючи вибір можливіх рішень з їх реалізації.

Функціональні вимоги (Functional Requirements)

- Бізнес-вимоги (Business Requirements) – визначають цілі організації чи клієнта.

- Вимоги користувача (User Requirements) – описують цілі/задачі користувачів системи, які повинні досягатися/виконуватися користувачем за допомогою створеної системи.

- Функціональні вимоги (Functional Requirements) – це представлення бізнес-вимог та вимог користувачів в термінах програми.

Все про тестування:

У термінології професіоналів тестування (програмного й деякого апаратного забезпечення), фрази «тестування білого ящика» і «тестування чорного ящика» відносяться до того, чи має розробник тестів доступ до вихідного коду ПЗ, що тестується, або ж тестування виконується через інтерфейс користувача або прикладний програмний інтерфейс, наданий модулем, що тестується. При тестуванні білого ящика (англ. white-box testing, також говорять — прозорого ящика), розробник тесту має доступ до вихідного коду й може писати код, що пов'язаний з бібліотеками ПЗ, що тестується. Це типово для юніт-тестування (англ. unit testing), при якому тестуються тільки окремі частини системи. Воно забезпечує те, що компоненти конструкції — працездатні й стійкі до певного ступеня.

При тестуванні чорного ящика (англ. black-box testing), тестер має доступ до ПЗ тільки через ті ж інтерфейси, що й замовник або користувач, або через зовнішні інтерфейси, що дозволяють іншому комп'ютеру або іншому процесу підключитися до системи для тестування. Наприклад, модуль, що тестується, може віртуально натискати клавіші або кнопки миші в програмі, що тестується, за допомогою механізму взаємодії процесів, із упевненістю в тім, що ці події викликають той же відгук, що й реальні натискання клавіш і кнопок миші.

Якщо «альфа-» і «бета-тестування» відносяться до стадій до випуску продукту (а також, неявно, до обсягу співтовариства, що тестує, й обмеженням на методи тестування), тестування «білого ящика» і «чорного ящика» має відношення до способів, якими тестер досягає мети.

Бета-тестування в цілому обмежено технікою чорного ящика (хоча постійна частина тестерів звичайно продовжує тестування білого ящика паралельно бета-тестуванню). Таким чином, термін «бета-тестування» може вказувати на стан програми (ближче до випуску чим «альфа»), або може вказувати на деяку групу тестерів і процес, що виконується цією групою. Отже, тестер може продовжувати роботу з тестування білого ящика, хоча ПЗ вже «у беті» (стадія), але в цьому випадку він не є частиною «бета-тестування» (групи/процесу).

19.Інструментальні засоби розробки ПЗ – це програмні комплекси, що допомагають у розробці ПЗ на кожному етапі розробки. Їх багато, і перераховувати їх назви немає сенсу. Варто лише привести, що вони роблять на кожному етапі розробки.

1. Аналіз вимог

1.1. Вести глосарій системи, що розробляється (визначення основних використовуваних понять);

1.2. Описувати цілі створення та приклади використання системи;

1.3. Опис особливостей застосування системи;

1.4. Точки зору на систему (різні робочі місця мають різну точку зору);

1.5. Групувати вимоги на класи (чи сумісні, виконувані такі вимоги?);

1.6. Проводити аналіз вимог;

2. Проектування

2.1. IDEF

2.1.1. IРозробка в DEF0 анотації

2.1.2. IРозробка в DEF3 анотації

2.2. UML

2.2.1. Проектування потоків/процесів

2.2.2. Проектування даних

3. Розробка

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

4. Тестування та оцінка якості

4.1. Модульне тестування

4.2. Відлагодження

5. Документування

Дані засоби дозволяють вести список помилок та відстежувати їх стан: Вбудовані в StarTeam та Team Foundation Server продукт корпорації Microsoft, який являється комплексним рішенням, об'єднуючим в собі систему керування версіями, збором даних, побудовою звітів, відстежуванням статусів та змін у проекті. Призначені для сумісної роботи над проектом.

6. Впровадження (Колективна розробка та управління проектом)

Системи управління версіями

6.1. Subversion

6.2. Merant PVCS Version Manager

6.3. Microsoft Visual SourceSafe

Системи управління змінами

6.4. Borland StarTeam

6.5. IBM/Rationa

Системи управління проектом

Microsoft Project