Технології проектування інтерфейсу користувача навчальних комп’ютерних систем

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

ХЕРСОНСЬКИЙ ДЕРЖАВНИЙ УНІВЕРСИТЕТ

ФАКУЛЬТЕТ ФІЗИКИ, МАТЕМАТИКИ ТА ІНФОРМАТИКИ

Випускна робота освітньо-кваліфікаційного рівня «Магістр»

Технології проектування інтерфейсу користувача навчальних комп'ютерних систем

8.080201. ІНФОРМАТИКА

Максимович Марина Богданівна

Херсон - 2011

Зміст

Перелік скорочень

Вступ

1. Концепції побудови HCI (Human-Computer Interaction)

1.1 Перспективи HCI

1.2 Класифікація електронних засобів навчального призначення

1.3 Міжнародні стандарти та процеси життєвого циклу програмної системи

1.4 Показники якості та надійності програмних засобів

Висновки до розділу 1

2. Проектування і дизайн інтерфейсу користувача

2.1 Принципи дизайну інтерфейсу користувача

2.2 Етапи створення інтерактивних прототипів

2.3 Засоби швидкого конструювання

2.4 Axure PR як інструмент візуального проектування

2.5 Інтегроване середовище розробки Silverlight Expression Blend

Висновки до розділу 2

3. Аспекти ефективного проектування інтерфейсу користувача компонентів інтегрованого дослідницького середовища «Відеоінтерпритатор 3.0»

3.1 Структура ІДС «Відеоінтерпритатор 3.0», його онтологія та артефакти інтерфейсу користувача

3.2 Створення технічного завдання для підвищення якості інтерфейсу користувача

3.3 Зручність застосування програмного забезпечення: атрибути та метрики

Висновки до розділу 3

Висновки

Список використаних джерел

Додатки

Перелік скорочень

ВНЗ - Вищий навчальний заклад

ІКТ - Інформаційно-комунікаційні технології

ІТ - Інформаційні технології

ПП - Програмний продукт

ППЗ - Педагогічний програмний засіб

ПС - Програмне середовище

ЕЗН - Електроний засіб навчання

СДН - Середовище дистанційного навчання

ІДС - Інтегроване дослідницьке середовище

ДСТУ - Державна система стандартизації України

ЖЦ - Життєвий цикл

ПЗНП - Програмний засіб навчального призначення

ПМК - Програмно-методичний комплекс

ISO - International Organization for Standardization

IEEE - Institute of Electrical and Electronics Engineers

AJAX - Asynchronous Javascript and XML

RIA - Rich Internet Application

XAML - eXtensible Application Markup Language

HTML - HyperText Markup Language

GUI - Graphical user interface

HCI - Human-Computer Interaction

CLR - Common Language Runtime

Вступ

Інформатизація освіти в Україні - один з найважливіших механізмів модернізації освітньої системи. Впровадження сучасних інформаційно-комунікаційних технологій у сферу освіти дозволить педагогам модернізувати цілі, зміст, методи, засоби й організаційні форми навчання.

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

Взаємодія між користувачем і комп'ютером відбувається в інтерфейсі.

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

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

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

У Херсонському державному університеті створено інтегроване середовище вивчення курсу «Основи алгоритмізації та програмування» WEBOAP. Основною перевагою середовища є організація самостійної роботи та поточний і підсумковий контроль знань студентів. Середовище, яке надає як викладачу, так і студентам усі можливості з ефективного вивчення курсу основ алгоритмізації та програмування.

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

Дана робота базується на програмно-методичному комплексі «Відеоінтерпретатор алгоритмів пошуку та сортування».

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

Темою дипломної роботи є «Технології проектування інтерфейсу користувача навчальних комп'ютерних систем».

Метою дипломної роботи є розробка інтерфейсу користувача інтегрованого дослідницького середовища «Відеоінтерпритатор 3.0».

Об'єктом дипломної роботи є інтерфейс користувача.

Предметом дипломної роботи є моделі інтерфейсу навчальних програм.

Гіпотеза: розроблений інтерфейс буде відповідати основним принципам дизайну інтерфейсу користувача і дозволить підвищити ефективність роботи з програмним продуктом.

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

Відповідно до мети були поставленні наступнізавдання:

· Розробка технічного завдання до продукту.

· Розробка інтерфейсу та дизайну інтегрованого дослідницького середовища Відеоінтерпритатор 3.0.

· Дослідження сучасних концепцій створення інтерфейсу користувача комп'ютерних систем.

Практична значимість: використання інтегрованого дослідницького середовища «Відеоінтерпритатор 3.0» при вивченні мов програмування Pacscal , С++, Java.

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

Апробація результатів дослідження

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

· на науковому семінарі «Програмні системи учбового та наукового призначення» (ХДУ, 2010);

· на VIІ Міжнародній науково-практичній конференції«ІКТ в освіті, дослідженнях та індустріальних додатках: Інтеграція, гармонізація та трансфер знань» (4-7 травня 2011 року).

Публікації. Всього за результатами дослідження опубліковано 3 роботи в збірниках наукових праць України (з них 1 у співавторстві).

1. Концепції побудови HCI (human-computer interaction)

1.1 Перспективи HCI

Людино-комп'ютерна взаємодія (HCI) є вивчення взаємодії між людьми (користувачів) і комп'ютерів.HCI часто розглядається як перетин комп'ютерної науки, науки про поведінку, дизайн і ряд інших дисциплін.Взаємодія між користувачами і комп'ютерами відбувається в інтерфейсі (або просто інтерфейс), який включає в себе як програмне забезпечення і аппаратние, наприклад, персонажів або об'єктів, що відображаються на програмне забезпечення на персональному комп'ютері моніторингу, що надходять від користувачів за допомогою апаратних засобів периферія, таких як клавіатури і миша, а також інші дії користувачів з великими комп'ютеризованими системами, таких як літаки та електростанції. Асоціація обчислювальної техніки визначає взаємодії людини з комп'ютером, як «дисципліна, що займаються дизайном, оцінкою та впровадженням інтерактивних комп'ютерних систем для використання людиною і з вивченням основних явищ, що її оточують». Важливим аспектом є HCI забезпечення задоволеності користувачів.

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

1.2 Класифікація електронних засобів навчального призначення

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

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

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

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

· комп'ютерні учбові середовища;

· комп'ютерні навчальні програми;

· автоматизовані навчальні системи;

· електроні підручники;

· експертно-навчальні системи;

· авторські інструментальні середовища;

· контролюючі програми;

· комп'ютерні імітатори технологічного устаткування;

· демонстраційні програми;

· навчальні функції професіональних програмних засобів. [55]

Сучасна інформаційна технологія підтримки навчального процесу - це ПМК, що забезпечує всі аспекти навчання - від подання нового матеріалу, підтримки практичної роботи, до перевірки знань учня.

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

· забезпечує практично миттєвий зворотний зв'язок;

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

· істотно заощаджує час при багаторазових звертаннях до гіпертекстових пояснень;

· дозволяє ефективно та в найбільш підходящому для конкретного індивідуума темпі, перевірити знання з конкретного розділу;

· забезпечує підтримку практичної роботи в максимально можливому обсязі. [30]

ПЗМП можуть бути як незалежними програмно-методичними комплексами, так і клієнтськими додатками, що керуються веб-сервером.

Загальні вимоги до ПЗНП

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

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

Перерахуємо основні типи вимог до ПЗНП: [43]

· педагогічні вимоги (дидактичні; методичні; обґрунтування вибору тематики учбового курсу; перевірка на педагогічну доцільність використання та ефективність використання);

· технічні вимоги;

· ергономічні вимоги;

· естетичні вимоги;

· вимоги до оформлення документації.

Розробникам ПЗ цікаві технічні вимоги. Програмно-технічні вимоги до ПЗНП визначають вимоги, що забезпечують:

· стійкість до помилкових та некоректних дій користувача;

· мінімізацію часу на дії користувача;

· ефективне використання технічних ресурсів;

· відновлення системної області пам'яті перед завершенням роботи програми;

· захист від несанкціонованих дій користувача;

· можливість ведення особистої інформації (зошит);

· відповідність функціонування ПЗНП до опису в експлуатаційній документації.

Львов М.С. у своїх працях виділяє такі загальні методологічні вимоги до програмного продукту навчального призначення:

· система інформаційної підтримки навчання має відповідати формі організації навчального процесу;

· система інформаційної підтримки має бути орієнтована на всіх учасників навчального процесу;

· система інформаційної підтримки має бути орієнтована на всі етапи навчального процесу;

· система інформаційної підтримки повинна бути предметно-орієнтованою.

Також, з точки зору розробника ПЗ, нам цікаві вимоги до інтерфейсу ПЗНП. Коротко розглянемо деякі з них.

1.3 Міжнародні стандарти та процеси життєвого циклу програмної системи

Галузеві та міжнародні стандарти у сфері інформаційних технологій є сумою досвіду, накопиченого експертами в інженерії програмного забезпечення (ПЗ) на основі величезної кількості проектів, що проводилися в рамках комерційних структур США, Європи і в рамках військових контрактів.Велика частина стандартів створювалася як набір критеріїв для відбору постачальників [1] програмного забезпечення для Міністерства оборони США, і це завдання вони вирішують досить успішно.Стандарти містять опис вироблених на основі реальних проектів підходів до побудови складних програмних систем.

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

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

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

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

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

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

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

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

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

ISO / IEC 12207:2008 System and software engineering - Software life cycle processes [1]. Розробка систем і програмного забезпечення - процеси життєвого циклу програмного забезпечення.Стандарт визначає загальну структуру життєвого циклу ПЗ у вигляді трирівневої моделі, елементами якої є процеси, види діяльності, завдання. Процеси об'єднані в чотири групи: основні процеси, що підтримують процеси, організаційні процеси, адаптація.

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

ISO / IEC 15288:2008 System and software engineering - System life cycle processes [2]. Розробка систем і програмного забезпечення - процеси життєвого циклу систем. Стандарт націлений на розгляд програмно-апаратної системи в цілому. Пропонує схожу схему визначення структури життєвого циклу ПЗ у вигляді набору груп процесів, де кожен процес описується набором результатів, і кожен результат досягається за допомогою набору різних видів діяльності.

Ефективність розробки ПЗ в цілому залежить від точності та коректності формулювання вимог до програмного продукту. Правила роботи з вимогами до ПЗ і більш загальними системними вимогами до програмно-апаратної системи в цілому визначаються наступними двома стандартами IEEE:

IEEE 830-1998 Recommended practice for software requirements specifications [3]. Описує структуру документів для фіксації вимог до ПЗ, визначає характеристики, якими повинен володіти правильно складений набір вимог (коректність, однозначність, повнота, несуперечність, впорядкованість і т.д.).

IEEE 1233-1998 Guide for developing system requirements specifications [4].Описує правила побудови вимог для програмно-апаратних систем в цілому, визначає необхідні властивості й атрибути набору вимог. Розробка вимог включає визначення, організацію, подання та модифікацію вимог.

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

IEEE 1016-1998 Recommended Practice for Software Design Descriptions [5]. Стандарт робить акцент на принципах побудови архітектури, а не на наборі структур, які лежать в її основі.

ISO / IEC 42010 IEEE Std 1471-2000 System and software engineering - Recommended practice for architectural description of software-intensive systems [6]. Архітектура може мати кілька подань, що відображають структуру ПЗ з різних точок зору. Стандарт рекомендує для кожного подання фіксувати відображені в ньому погляди і інтереси, причини, що обумовлюють необхідність такого розгляду системи, невідповідності між елементами одного подання або між різними уявленнями, а також різну службову інформацію.

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

ISO 9001:2000 Quality management systems - Requirements [8].Системи управління якістю - вимоги. Цей стандарт визначає загальні правила забезпечення якості результатів у всіх процесах життєвого циклу виробу.

ISO / IEC 90003:2004 Software engineering - Guidelines for the application of ISO 9001:2000 tocomputer software [9]. Розробка програмного забезпечення - керівні положення щодо застосування стандарту ISO 9001:2000 до програмного забезпечення. Цей стандарт конкретизує положення ISO 9001 для розробки програмного забезпечення з упором на забезпечення якості при процесі проектування.Він також визначає певний набір технік і процедур, які рекомендується застосовувати для контролю і забезпечення якості розроблюваних програм.

ISO / IEC TR 90005:2008 Software engineering - Guidelines for the application of ISO 9001:2000 to system life cycle processes [10]. Розробка програмного забезпечення - керівні положення щодо застосування стандарту ISO 9001:2000 до процесів життєвого циклу програмних систем. Цей стандарт конкретизує положення щодо застосування ISO 9001:2000 для придбання, постачання, розробки, застосування та супроводження програмних систем.Він не додає і не змінює вимоги ISO 9001:2000. ISO / IEC TR 90005:2008 використовує ISO / IEC 15288 як відправну точку для формування вимог забезпечення якості при проектуванні програмних систем.

Якість програмного забезпечення регламентується групою стандартів ISO 9126. У стандартах якість ПЗ визначено у вигляді всієї сукупності характеристик, що дозволяють задовольнити потреби всіх зацікавлених осіб. При розгляді якості ПЗ розрізняються поняття внутрішнього якості, пов'язаного з характеристиками самого ПЗ, без урахування його поведінки, зовнішньої якості, що характеризує ПЗ з точки зору його поведінки в системі, і якість ПЗ при використанні в різних сценаріях роботи. Крім того, на створення якісного ПЗ істотно впливає якість технологічних процесів його розробки, про що згадувалося раніше.

Стандарт ISO 9126 пропонує використовувати для опису якості ПЗ багаторівневу модель показників якості. На верхньому рівні виділено 6 основних характеристик якості ПЗ. Кожна характеристика описується за допомогою набору атрибутів, що дозволяють оцінити цю характеристику. Для кожного атрибута визначається набір метрик, що дозволяють оцінити цей атрибут. Для кожної метрики визначається набір оціночних елементів, що дозволяють оцінити цю метрику. Побудова моделі якості дозволяє системно описати вимоги до програмного забезпечення, визначаючи, які властивості ПЗ за даною характеристикою хочуть бачити зацікавлені сторони. Показники якості, закріплені в стандартах, не вичерпують повністю поняття якості ПЗ. У залежності від призначення програмного забезпечення перелік показників якості може бути розширений або звужений в рамках проекту по розробці конкретного ПЗ.

ISO / IEC 9126-1:2001 Software engineering - Product quality - Part 1: Quality model [11]. Визначає набір характеристик та атрибутів якості програмного забезпечення.

ISO / IEC 9126-2:2003 Software engineering - Product quality - Part 2: External metrics [12].

ISO / IEC 9126-3:2003 Software engineering - Product quality - Part 3: Internal metrics [13].

ISO / IEC 9126-4:2004 Software engineering - Product quality - Part 4: Quality in use metrics [14].

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

ISO / IEC 25051:2006 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing [15]. Розробка програмного забезпечення - Оцінка та вимоги якості до програмного забезпечення - Вимоги для якості готового комерційного програмного продукту та інструкцій для випробування. Визначає вимоги якості до програмних продуктів і до документації з тестування. Регламентує зміст документації з тестування, яка повинна включати план тестування, опис використовуваних методів тестування, опис наборів тестів і результатів тестування. Цей стандарт у 2006 році прийшов на зміну ISO / IEC 12119:1994.

IEEE 829-1998 Standard for Software Test Documentation [16].Описує базовий набір документів для тестування програмного забезпечення. Стандарт також визначає форму і зміст тестових документів.

IEEE 829-2008 Standard for Software and System Test Documentation [17].Стандарт застосовується до програмних систем.

IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing [18]. Описує організацію модульного тестування

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

ISO / IEC 14598-1:1999 Information technology - Software product evaluation - Part 1: General overview [19].

ISO / IEC 14598-2:2000 Software engineering - Product evaluation - Part 2: Planning and management [20].

ISO / IEC 14598-3:2000 Software engineering - Product evaluation - Part 3: Process for developers [21].

ISO / IEC 14598-4:1999 Software engineering - Product evaluation - Part 4: Process for acquirers [22].

ISO / IEC 14598-5:1998 Information technology - Software product evaluation - Part 5: Process for evaluators [23].

ISO / IEC 14598-6:2001 Software engineering - Product evaluation - Part 6: Documentation of evaluation modules [24].

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

1.4 Показники якості та надійності програмних засобів

Відповідно до стандарту [3] модель якості ПЗ складається із двох частин:

· внутрішня і зовнішня якість;

· якість у використанні.

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

Характеристики якості можуть бути застосовані для будь-якого виду ПЗ, включаючи комп'ютерні програми та дані, що прошиті у постійному запам'ятовуючому пристрої.

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

Взаємодія частин моделі якості програмного забезпечення

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

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

Остаточною метою оцінювання ПЗ є одержання необхідних результатів у конкретному середовищі використання (рис. 1.1). З рисунка 1.1 видно, що якість процесів (якість процесів життєвого циклу визначено у ДСТУ 3918-1999 (ISO/IEC12207) впливає на якість продукту ПЗ, а якість продукту ПЗ впливає на якість у використанні.

Рисунок 1.1 - Якість у життєвому циклі ПЗ

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

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

Якість програмного забезпечення та життєвий цикл

Вимоги до якості ПЗ не можуть бути повністю визначені до початку проектування.

На різних стадіях життєвого циклу ПЗ існують різні точки зору на якість ПЗ та відповідні метрики (способи виміру) якості (рис. 1.2).

Рис.1.2 Взаємозв'язок між метриками якості ПЗ

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

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

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

Вимоги до зовнішньої якості визначають рівень вимог до якості із зовнішньої точки зору на продукт. Вони містять вимоги, що походять із вимог якості для користувача, включаючи вимоги до якості у використанні.

Вимоги до зовнішньої якості повинні бути:

· встановлені у специфікації вимог до якості з використанням зовнішніх метрик;

· перетворені у вимоги до внутрішньої якості;

· використані як критерії оцінювання продукту.

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

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

Якість ПЗ повинна оцінюватися з використанням моделі якості. Модель якості визначають після розроблення вимог до якості готового ПЗ та проміжного продукту і вона є сукупністю атрибутів якості ПЗ, класифікованих в ієрархічну деревоподібну структуру характеристик і підхарактеристик. Верхній рівень цієї структури складається з характеристик якості, а нижній - з атрибутів якості ПЗ. Ця ієрархія не є строгою, тому що деякі атрибути можуть входити більш ніж в одну характеристику.

Стандарт [11] надає загальноцільові моделі внутрішньої та зовнішньої якості і якості у використанні.

Висновки до розділу 1

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

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

2. Проектування і дизайн інтерфейсу користувача

2.1 Принципи дизайну інтерфейсу користувача

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

Взаємодія між користувачем і комп'ютером (HCI - Human-Computer Interaction) відбувається в інтерфейсі. Основною метою HCI є покращення взаємодії між користувачем і комп'ютером, роблячи комп'ютери більш кориснішими і сприйнятливими до потреб користувачів.

Найчастіше ефективність використання всіх функцій системи й ефективність роботи самої системи визначається у більшому ступені тим, як побудований її інтерфейс. [39], [40]

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

Використання знайомих користувачу понять і образів (метафор) забезпечує інтуїтивно зрозумілий інтерфейс при виконанні завдань.

Метафори є свого роду «містком», що зв'язує образи реального світу з тими діями і об'єктами, якими доводиться маніпулювати користувачу при його роботі на комп'ютері; вони забезпечують «пізнавання», а не «згадку». Користувачі запам'ятовують дію, пов'язану із знайомим об'єктом, легше, ніж вони запам'ятали б ім'я команди, пов'язаної з цією дією.

Узгодженість інтерфейсу означає використання однакових або дуже схожих метафор і способів взаємодії з користувачем і порядку роботи в різних додатках.

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

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

Узгодженість в межах продукту

Одна і та ж команда повинна виконувати одні і ті ж функції, де б вона не зустрілася, причому однаково.

Узгодженість в межах робочого середовища

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

Узгодженість у використовуванні метафор

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

Дружність інтерфейсу

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

Навіть за наявності добре спроектованого інтерфейсу користувачі можуть робити ті або інші помилки. Ці помилки можуть бути як «фізичного» типу (випадковий вибір неправильної команди або даних), так і «логічного» (ухвалення неправильного рішення на вибір команди або даних). Ефективний інтерфейс повинен запобігати ситуаціям, які, ймовірно закінчаться помилками. Він також повинен уміти адаптуватися до потенційних помилок користувача і полегшувати йому процес усунення наслідків таких помилок.

Принцип «зворотнього зв'язку»

Програмний продукт повинен забезпечувати зворотній зв'язок для дій користувача. Кожна дія користувача повинна одержувати візуальне, а іноді і звукове підтвердження того, що програмне забезпечення сприйняло введену команду; при цьому вид реакції, по можливості, повинен враховувати природу виконаної дії.

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

Простота інтерфейсу

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

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

Естетична привабливість

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

Золотий перетин - це сама комфортна для ока пропорція, форма, в основі побудови якої лежить поєднання симетрії і золотого перетину, сприяє найкращому зоровому сприйняттю і появі відчуття краси і гармонії.[55]

У математиці пропорцією називають рівність двох відносин: a: b = с: d.

Відрізок прямій АВ можна розділити точкою С на дві частини наступними способами:

· на дві рівні частини АВ: АС = АВ: ВС;

· на дві нерівні частини в будь-якому відношенні (такі частини пропорції не утворюють);

· таким чином, коли АВ: ВС = ВС: АС.

Останнє і є золотий розподіл або розподіл відрізка в крайньому і середньому відношенні.

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

а: b = b: с чи з: b = b: а.

Відрізки золотої пропорції виражаються нескінченним ірраціональним дробом 0,618 ..., якщо з прийняти за одиницю, а = 0,382. Відношення ж відрізків а і b складає 1,618.

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

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

Золотий перетин не є штучним явищем. Воно дуже широко поширене в природі: золотий перетин можна знайти в пропорціях тіл багатьох рослин і тварин, а також морських раковин і пташиних яєць. Але найбільш вражаючий приклад "застосування" природою принципу золотого перетину - людське тіло. Воно цілком і його частини (обличчя, руки, кисті рук і т. п.) наскрізь пронизані пропорцією 1,618.

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

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

Гаманець Міллера

Цей принцип названий так на честь вченого-психолога Г.А. Міллера, який досліджував короткотривалу пам'ять, перевіряючи висновки, зроблені раніше його колегою, Г. Еббінгаузом. Еббінгауз намагався з'ясувати, скільки інформації може запам'ятати людина без будь-яких спеціальних мнемонічних прийомів. Виявилося, що ємність пам'яті обмежена сім'ю цифрами, сім'ю літерами або назвами семи предметів. Це "магічне число" сім, що служить свого роду міркою пам'яті, і було перевірено Міллером, який показав, що пам'ять дійсно в середньому не може зберігати більше семи елементів; в залежності від складності елементів це число може коливатися в межах від п'яти до дев'яти.

Якщо необхідно протягом короткого часу зберегти інформацію, що включає більше семи елементів, мозок майже несвідомо групує цю інформацію таким чином, щоб число запам'ятовуються елементів не перевищувало гранично допустимого. Наприклад, номер банківського рахунку 30637402710, що складається з одинадцяти елементів, буде, швидше за все, запам'ятовуватися як 30 63 740 27 жовтня, тобто як п'ять числових елементів, або вісім слів (тридцять, шістдесят, три, сімсот, сорок, двадцять, сім, десять).

Застосовуючи принцип гаманця Міллера в дизайні інтерфейсів, слід групувати елементи в програмі (кнопки на панелях інструментів, пункти меню, закладки, опції на цих закладках і т. п.) з урахуванням цього правила-тобто не більше семи в групі, в крайньому випадку - дев'яти. Погляньте, наприклад, на головне вікно програми-словника ABBYY Lingvo 6.0: чотирнадцять кнопок на верхній панелі, між якими немає жодного роздільника, сприймаються набагато гірше, ніж кнопки на панелі внизу, які розділені на групи.

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

Принцип угруповання

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

Бритва Оккама або KISS

Філософський принцип, що носить назву "Бритва Оккама", говорить: "Не множити сутності без потреби". Або, як кажуть американці, KISS ("Keep It Simple, Stupid" - "He ускладнюй, телепень").

Мовою інтерфейсів це означає, що:

· будь-яка задача повинна вирішуватися мінімальним числом дій;

· логіка цих дій повинна бути очевидною для користувача;

· руху курсору і навіть очей користувача повинні бути оптимізовані.

Розумне запозичення

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

2.2 Етапи створення інтерактивних прототипів

Етап I. Передпроектний аналіз

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

Етап II. Збір вимог

На наступному етапі ми готуємо докладний перелік функціональності (user stories). Він дозволяє врахувати всі функціональні вимоги і краще зрозуміти особливості майбутньої системи. На його основі ми робимо висновок, які з функцій вимагають цілого процесу, які - просто окремої сторінки, а яким буде досить простої кнопки. Орієнтуючись на складених раніше персонажів, ми оновлюємо карту сайту і складаємо схему навігації. Після цього рисуються діаграмми переходів між сторінками - вони об'єднують сторінки системи в рамках конкретних процесів. Тепер ми знаємо, як користувачі будуть працювати з продуктом в цілому і як саме виконувати конкретні завдання. Етап триває близько 4 днів

Етап III. Проектування інтерфейсу

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

Етап IV. Дизайн інтерфейсу

Завершальним етапом стає візуальний дизайн інтерфейсу. Спершу на основі пари ключових сторінок ми відпрацьовуємо креативну концепцію. Після того як загальна стилістика схвалена клієнтом, малюються дизайн-макети ключових сторінок системи. На цьому етапі продукт знаходить зовнішній вигляд - до цього ми займалися його суттю і принципами роботи. Для проектів, які планують активно розвиватися, ми також готуємо керівництво за стилем інтерфейсу (style guide).Він описує принципи візуального оформлення продукту і дозволить зберегти його цілісність у процесі доопрацювань. Роботи з цього етапу тривають 1-2 тижні.

...