Студопедия
Новини освіти і науки:
МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах


РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання


ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ"


ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ


Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків


Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні


Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах


Гендерна антидискримінаційна експертиза може зробити нас моральними рабами


ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ


ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів



Швидка розробка програм (rapid application development, RAD)

Швидкою розробкою програм називаються методи швидкого прототипування або отримання готових застосувань. Вони отримані з комп'ютерних методів бачення. Термін RAD використовується іноді як синонім мов/середовищ розробки нового покоління (4GL). Приклади RAD-інструментів: Borland Delphi RAD Pack, IBM Visual Age (для Small Talk), Microsoft Access Developer’s Toolkit, Microsoft Visual FoxPro Professional, Visual Studio FoxPro, PowerBuilder Desktop, Power++ та інші.

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

3. Дизайн інтерфейсу

З точки зору користувача, інтерфейс програми є дуже важливим, і його функціональність може визначити думку користувача про продукт.

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

Малюнок 7.4.1. Створення посилання на індекс.

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

Розробка інтерфейсу стала легшою останніми роками, оскільки з'явилися багато графічних інструментів для цього. Також існують системи з управлінням інтерфейсом, наприклад, Zapp Factory, Visual Basic. Візуальні інструменти дають можливість інтерактивно розробляти діалоги, вікна, меню, порозрядні карти відображення інформації і ікони. Вони дозволяють визначити реакцію системи у відповідь на якісь події, наприклад, зроблені користувачем (вибір запису в меню, переміщення курсора над певними областями і т.д.), легке і швидке генерування графічного проекту, программного або інших кодів.

Організація взаємодії з користувачами

Спілкування з користувачем здійснюється:

· через командний рядок,

· через графічне середовище.

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

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

Середовище вікон легке для освоєння новачками і середньо навченими користувачами. Воно дозволяє незалежне, зручне вивчення програми, без потреби в знанні семантики текстових команд.

Типові способи взаємодії користувача з системою такі:

· командний рядок

· вибір умови

· клавішні комбінації швидкого виклику

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

· вибір в діалозі

· навігація мишею

Введення і читання даних здійснюється користувачем через:

· введення параметрів в командний рядок

· введення даних у відповідь на системний запит

· введення даних в діалозі

системою через:

· відображення інформації в діалозі

· показ звіту і/або друк

· графічне представлення даних

Інтерфейс може бути розроблений вже на етапі формулювання вимог.

Дизайн інтерфейсу

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

Правила дизайну:

Правило 1. Мітки повинні знаходиться біля або зверху редагованих полів.

Правило 2. Такі поля, як OK або Cancel, повинні знаходиться з правого боку.

Правило 3. Переклади повинні бути змістовними.

Правило 4. Діалогові вікна повинні відповідати потоку даних між користувачем і системою.

Малюнок 7.4.2. Редагування об'єкту "дохід від одного джерела".

 

Правило 5. Для команд, які часто використовуються, потрібно використовувати клавіатуру для прискорення запуску користувачем.

Правило 6. Ми повинні пам'ятати про надсилання підтверджень користувачеві. У випадку з об'ємними командами користувач повинен інформуватися про виконання йому команди. Зображення може бути виконане у формі текстової інформації, відсотків виконання команди, "термометра".

Правило 7. У системи повинна бути проста обробка помилок. Помилка повинна бути показана, а правильні дані повинні використовуватися для виконання наступного завдання.

Правило 8.У системи повинна бути операція "відміна". У найпростішому випадку система повертається до останньої операції. У складніших - до попередньої.

Правило 9. Система повинна дозволяти користувачеві контролювати роботу. Користувачі не люблять операцій, що ініціюються без їх відома. Такі операції не повинні робитися системою, а реакція на команди Esc, Ctr+C, Break… повинна бути дуже швидкою.

Правило 10. Інтерфейс не повинен використовувати дуже багато пам'яті, яка виділена користувачу. Він повинен відображати основну інформацію про виконуване завдання і про стадію завдання.

Правило 11. Зв'язані операції повинні бути об'єднані в один діалог. Якщо це неможливо, операції повинні бути розділені таким чином, щоб зв'язані діалоги були доступні.


Малюнок 7.4.3. Групування полів. Два функціонально рівних рішення.

Правило 12. Потрібно дотримуватися правила Міллера. Правило Міллера 7+/-2 говорить, що людина може зосередитися на 5-9 елементах. Правило повинне застосовуватися при проектуванні меню, підменю, діалогових полів і т.д. Правило може бути реалізоване шляхом декомпозиції інтерфейсу і його подальшим угрупуванням в об'єднані групи.

4. Структуровані схеми/діаграми

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


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

  1. Cisco Packet Tracer - Знайомство з програмою. Інтерфейс
  2. I. Введення в розробку програмного забезпечення
  3. II. Вимоги до складання паспорта бюджетної програми
  4. II. Із програм для 11 класу
  5. II.1 Програмне забезпечення
  6. III. Етапи розробки програмного забезпечення
  7. III. Навчально-програмний етап.
  8. III. Програма
  9. III. Програма
  10. Theme: application of a rule of the lever in двухкомпонентных systems of knitting materials. System Al2O3-SiO2., Na2O-SiO2
  11. Алгоритм створення тренінгової програми
  12. Аналіз програм на етапі їх експлуатації




Переглядів: 1102

<== попередня сторінка | наступна сторінка ==>
Малюнок 7.2.1. Етап проектування. | Прапори потоку даних

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

  

© studopedia.com.ua При використанні або копіюванні матеріалів пряме посилання на сайт обов'язкове.


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