Використання компонент

Ітеративна розробка

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

2 Управління вимогами

Завжди пам'ятати вимоги встановлені користувачами.

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

4 Візуальне моделювання

Використовуйте діаграми щоб представити всі основні компоненти, користувачів, та їх взаємодії. «UML», скорочено від Unified Modeling Language, є інструментом що може зробити це завдання більш здійсненним.

5 Перевірка якості

Завжди робіть тестування більшої частини проекту в будь-який момент часу. Тестування стає важчим з розростанням проекту, та воно має бути постійним фактором в будь-якому створенні програмного продукту.

6 Контроль змін

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

Класифікація вимог до системи FURPS

Класифікація вимог до системи FURPS+ була розроблена Робертом Грейді (Robert Grady) з Hewlett-Packard і запропонована в 1992 році.

Ідеологія FURPS – Functionality, Usability, Reliability, Performance, Supportability, тобто функціональність, юзабіліті, надійність, продуктивність, підтримування.

Скорочення FURPS розшифровується так:

1. F unctionality, функціональність

2. U sability, зручність використання

3. R eliability, надійність

4. P erformance, продуктивність

5. S upportability, підтримування

6. + Необхідно пам'ятати про такі можливі обмеження, як:

6.1 обмеження проектування, design

6.2 обмеження розробки, implementation

6.3 обмеження на інтерфейси, interface

6.4 фізичні обмеження, physical

Якщо застосувати до цієї класифікації популярний поділ вимог на функціональні та нефункціональні, то до останніх слід віднести всі перераховані вище групи крім першої, тобто URPS +.

Тепер давайте розглянемо кожну групу вимог докладніше.

Рисунок – Класифікація вимог до системи (детальна)

F. Функціональні вимоги

Функціональні вимоги містять основні властивості / функції системи. Однак не всі вони обов'язково будуть ставитися до предметної області системи.

– Журналювання, аuditing – інструменти відстеження дій користувачів і системи шляхом запису в журнал безпеки конкретних типів подій.

– Ліцензування, licensing – кошти для відстеження, придбання, установки та контролю над використанням ліцензій.

– Локалізація, localization – засоби підтримки різних природних мов.

– Пошта, mail – служби відправки та отримання повідомлень.

– Допомога, online help – можливість надавати підтримку користувачів в реальному часі (наприклад, «Необхідна система online-допомоги»).

– Друк, printing – кошти для друку документів.

– Звітність, reporting – інструменти створення і отримання звітів.

– Безпека, security – засоби захисту доступу до певних ресурсів інформації.

– Управління системою, system management – інструменти, що дозволяють керувати програмами в розподіленому середовищі.

– Технологічний процес, workflow – підтримка документообігу, включаючи процеси перевірки, візування та затвердження.

U. Зручність використання

До зручності використання належать наступні види вимог:

– естетика і логічність користувальницького інтерфейсу,

– захист від людського фактора;

– експлуатаційна документація, її склад (керівництва користувачів, адміністраторів та ін), галузеві і державних стандарти оформлення;

– кваліфікація користувачів і їх навчання;

– довідкова інформація в системі.

R. Надійність

Надійності включає такі характеристики системи, як:

– збої:

· допустима частота / періодичність збоїв;

· середній час збоїв і їх серйозність;

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

– передбачуваність поведінки;

– час готовності системи до роботи, режим роботи або час доступності системи (наприклад, «Система повинна бути доступна 24 години на добу 7 днів на тиждень»);

– точність обчислень.

P. Продуктивність

Продуктивність системи складають такі характеристики:

– швидкість роботи, час відгуку системи;

– результативність / ефективність;

– пропускна здатність, включаючи загальну і допустима кількість одночасно працюючих користувачів, кількість призначених для користувача запитів, число звернень системи до БД і обсяг запитуваних / переданих даних в одиницю часу;

– час, необхідний на відновлення – швидкість відновлення (необхідно відрізняти цю характеристику P / продуктивності від характеристик R / надійності «можливість відновлення» і «час доступності»);

– час, необхідний для запуску і завершення роботи – швидкість запуску і завершення;

– споживання ресурсів.

S. Підтримувані

До підтримки відносяться можливості:

– тестування;

– розширення – нарощування додаткового функціоналу системи;

– масштабування – тиражування, наприклад, у філіях / підрозділах організації;

– адаптації / пристосування до використання в заданій середовищі, в т.ч. шляхом попередньої настройки;

– конфігурування – оперативної, регулярної налаштування, перевизначення параметрів;

– сумісності;

– супроводження, підтримки працездатності: виправлення помилок, оновлення даних, частота архівації та резервного копіювання;

– сервісного обслуговування та ремонту, їх зручність;

– установки;

– локалізації (наприклад, «Продукт буде підтримувати декілька природних мов»),

– портативність,

– відповідність міжнародним стандартам.

+. Обмеження

Розглянута класифікація виділяє наступні 4 групи обмежень:

1) Обмеження проектування:

– обмеження на технології (наприклад, «Зберігання необхідно реалізувати за допомогою реляційної БД»);

– процес («RUP»),

– засоби розробки («діаграми повинні створюватися в MS Visio, документація – в MS Word»),

– інші.

2) Обмеження реалізації, розробки, побудова, написання програмного коду:

– стандарти розробки,

– стандарти якості ПЗ, в т.ч. коду,

– мови програмування (наприклад, «Вся бізнес-логіка повинна бути реалізована на мові Visual Basic»),

– засоби розробки (наприклад, «В якості СУБД повинна бути використана Oracle 10»),

– ресурсні обмеження,

– ліцензійні обмеження,

– обмеження на технічне (апаратне) забезпечення,

– інші.

3) Вимоги до інтерфейсів – обмеження (наприклад, на формати, протоколи) накладаються необхідністю взаємодії з іншими системами:

– формати даних,

– протоколи взаємодії,

– зовнішні системи,

– інші.

4) Фізичні обмеження, що накладаються на технічні (апаратні) засоби і оточення системи:

– форма,

– розмір,

– вагу,

– температурний режим,

– вологість,

– обмеження на вібрацію,

– інші.

5) Інші обмеження

При розробці системи можуть накладатися й інші обмеження, в частості, юридичні:

– міжнародні угоди: одиниці вимірювання, мови,

– авторське право,

– угоди про ліцензування,

– законодавство,

– галузеві стандарти.

Дата добавления: 2014-01-11