Принцип повторного використання при проектуванні ПЗ

Потрібно багаторазово використовувати внутрішні та зовнішні компоненти і принципи поведінки системи, свідомо підтримуючи постійне (повторне) використання елементів інтерфейсу. Це сприяє зменшенню об’єму інформації, яку потрібно запам’ятовувати користувачам і про яку необхідно думати знову кожного разу.

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

Правила Якоба Нільсена

Якоб Нільсен, прибічник простих і вигідних з економічної точки зору підходів до практичності, створив один з кращих наборів евристичних правил практичності, а потім зайнявся дослідженнями в сфері застосування різних правил для пояснення актуальних проблем практичності, які виникають в реально існуючих системах. Загальне число спеціальних евристичних правил дорівнює 101. Нижче перераховані десять правил Нільсена, пояснюючих 95% найбільш серйозних із цих проблем:

1. Зорове сприйняття/вказівка, а не запам'ятовування/набір на клавіатурі.

2. Несуперечність (схожі дії реалізуються схожим чином).

3. Своєчасний і продуманий зворотний зв'язок.

4. Яскраво виражений набір дій.

5.Можливість відміни дій.

6. Близька користувачеві концептуальна модель.

7. Підтвердження введених даних.

8. Запобігання можливих помилок.

9. Чітко виражений вибір дій.

10. Немодальна взаємодія.

На додаток до цих десяти правил існують ще п'ять, які пояснюють усі проблеми незалежно від ступеня їх серйозності:

1. Спілкування з користувачем повинне вестися на його мові.

2. Естетична цілісність (простий дизайн).

3. Скорочений клавішний набір і прискорений доступ до команд.

4. Домовленості, що мають практичний сенс.

5. Допомога у виявленні і виправленні помилок.

Життєвий цикл ПЗ

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

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

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

Проектування - це початковий етап в розробці програмного продукту (додатку). На цій стадіїі визначається загальна концепція програмного продукту, додатку. Якщо проект у своїй основі неякісний, згодом важко буде що-небудь кардинально змінити в кращу сторону.

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

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

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

Основна мета випробувань – визначити, наскільки повно розроблений програмний продукт (в першу чергу, його інтерфейс) відповідає потребам і очікуванням користувача. У зв'язку з цим основним напрямом випробувань додатка є оцінка його "споживчих властивостей". Така оцінка повинна проводитися, починаючи з початкових етапів розробки. Основою для проведення оцінки повинні слугувати дані про те, як користувачі зазвичай виконують ту роботу, яку повинен автоматизувати розроблений програмний продукт.

Поиск по сайту: