Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
ТЕХНОЛОГІЇ ПРОЕКТУВАННЯ ІНТЕРФЕЙСУ КОРИСТУВАЧА НАВЧАЛЬНИХ КОМП’ЮТЕРНИХ СИСТЕМ
Інформація про навчальний заклад
ВУЗ:
Херсонський державний університет
Інститут:
Не вказано
Факультет:
РТ
Кафедра:
Не вказано
Інформація про роботу
Рік:
2011
Тип роботи:
Магістерська робота
Предмет:
Інформатика та обчислювальна техніка
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ,
МОЛОДІ ТА СПОРТУ УКРАЇНИ
ХЕРСОНСЬКИЙ ДЕРЖАВНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ФІЗИКИ, МАТЕМАТИКИ ТА ІНФОРМАТИКИ
ЗАТВЕРДЖУЮ
до захисту в ДЕК
Перший проректор університету
_________професор О.В. Мішуков
“___”___________ 2011 р.
МАКСИМОВИЧ МАРИНА БОГДАНІВНА (______________)
ТЕХНОЛОГІЇ ПРОЕКТУВАННЯ ІНТЕРФЕЙСУ КОРИСТУВАЧА НАВЧАЛЬНИХ КОМП’ЮТЕРНИХ СИСТЕМ
8.080201. ІНФОРМАТИКА
Випускна робота освітньо-кваліфікаційного рівня «Магістр»
ПОГОДЖЕНО
Декан факультету Науковий керівник
__________ доцент Кузьмич В.І. _______ професор Співаковський О.В “___”___________ 2011 р. “___”___________ 2011 р.
Завідувач кафедри інформатики Рецензент
______ професор Співаковський О.В __________ доцент Кузьмич В.І.
“___”___________ 2011 р. ___”___________ 2011 р.
Херсон – 2011
ЗМІСТ
Перелік скорочень…………………………………………………………..…..4
Вступ………………………………………………………………………………5
Концепції побудови HCI (Human-Computer Interaction)………………………………………………………………............8
Перспективи HCI…………………………………………………….........8
Класифікація електронних засобів навчального призначення…………8
Міжнародні стандарти та процеси життєвого циклу програмної системи…………………………………………………………………………...12
Показники якості та надійності програмних засобів……………..........20
Висновки до розділу……………………………………………………………..24
Проектування і дизайн інтерфейсу користувача………….….25
Принципи дизайну інтерфейсу користувача……………………………25
Етапи створення інтерактивних прототипів…………………………….32
Засоби швидкого конструювання……………………………………….37
Axure PR як інструмент візуального проектування…………………….38
Інтегроване середовище розробки Silverlight Expression Blend………39
Висновки до розділу……………………………………………………………..50
Аспекти ефективного проектування інтерфейсу користувача компонентів інтегрованого дослідницького середовища «Відеоінтерпритатор 3.0»……………………………………………………...51
Структура ІДС «Відеоінтерпритатор 3.0», його онтологія та артефакти інтерфейсу користувача ……………………………………………………...…51
Створення технічного завдання для підвищення якості інтерфейсу користувача……………………………………………………………………....60
Зручність застосування програмного забезпечення: атрибути та метрики…………………………………………………………………………...64
Висновки до розділу……………………………………………………………..69
Висновки………………………………………………………………………...70
Список використаних джерел…………………………………………….…..72
Додатки……………………………………………………………………….….81
Додаток А. Глосарій...…………………………………………………….…..81
Додаток Б. Питання для анкетування користувачів з метою отримання відгуку щодо зручності використання програмного забезпечення………..87
Додаток В. Ергономічні вимоги…………..………………………………….89
Додаток Г. Технічне завдання…..……………………………………………92
ПЕРЕЛІК СКОРОЧЕНЬ
ВНЗ
- Вищий навчальний заклад
ІКТ
- Інформаційно-комунікаційні технології
ІТ
- Інформаційні технології
ПП
- Програмний продукт
ППЗ
- Педагогічний програмний засіб
ПС
- Програмне середовище
ЕЗН
- Електроний засіб навчання
СДН
- Середовище дистанційного навчання
ІДС
- Інтегроване дослідницьке середовище
ДСТУ
- Державна система стандартизації України
ЖЦ
- Життєвий цикл
ПЗНП
- Програмний засіб навчального призначення
ПМК
- Програмно-методичний комплекс
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)
Перспективи HCI
Людино-комп'ютерна взаємодія (HCI) є вивчення взаємодії між людьми (користувачів) і комп'ютерів. HCI часто розглядається як перетин комп'ютерної науки, науки про поведінку, дизайн і ряд інших дисциплін. Взаємодія між користувачами і комп'ютерами відбувається в інтерфейсі (або просто інтерфейс), який включає в себе як програмне забезпечення і аппаратние, наприклад, персонажів або об'єктів, що відображаються на програмне забезпечення на персональному комп'ютері моніторингу, що надходять від користувачів за допомогою апаратних засобів периферія, таких як клавіатури і миша, а також інші дії користувачів з великими комп'ютеризованими системами, таких як літаки та електростанції. Асоціація обчислювальної техніки визначає взаємодії людини з комп'ютером, як «дисципліна, що займаються дизайном, оцінкою та впровадженням інтерактивних комп'ютерних систем для використання людиною і з вивченням основних явищ, що її оточують». Важливим аспектом є HCI забезпечення задоволеності користувачів.
Взаємодія людини і машини є важливою, тому що погано спроектовані людини-машинних інтерфейсів може призвести до багатьох несподівані проблеми.
Класифікація електронних засобів навчального призначення
Значна кількість традиційних комп'ютерних курсів математики базується на ідеях програмованого навчання, хоча й використовує сучасні апаратні та програмні можливості обчислювальної техніки та нові методи представлення знань. Найбільш розвиненою і розробленою як з методичної, так і з технічної точок зору за такого підходу виявляється лекційна частина курсу.
Комп’ютерна навчальна програма – це педагогічний програмний засіб, який забезпечує досягнення заданої дидактичної мети при навчанні.
Комп’ютерне навчальне середовище – це педагогічний програмний засіб, який забезпечує досягнення педагогічних цілей шляхом керування процесом пізнання навколишнього світу.
Педагогічні програмні засоби являють собою технологічне забезпечення навчального процесу, засноване на використанні комп’ютерних та телекомунікаційних технологій. До педагогічних програмних засобів відносяться:
комп’ютерні учбові середовища;
комп’ютерні навчальні програми;
автоматизовані навчальні системи;
електроні підручники;
експертно-навчальні системи;
авторські інструментальні середовища;
контролюючі програми;
комп’ютерні імітатори технологічного устаткування;
демонстраційні програми;
навчальні функції професіональних програмних засобів. [55]
Сучасна інформаційна технологія підтримки навчального процесу – це ПМК, що забезпечує всі аспекти навчання – від подання нового матеріалу, підтримки практичної роботи, до перевірки знань учня.
У широкому розумінні, ПЗНП являє собою комплект навчальних, контролюючих, моделюючих та інших програм, розташованих на комп’ютері, у яких реалізовано основний науковий зміст навчальної дисципліни. ПЗНП часто доповнює звичайний підручник, а особливо ефективний у тих випадках, коли він:
забезпечує практично миттєвий зворотний зв'язок;
допомагає швидко знайти необхідну інформацію (у тому числі контекстний пошук), пошук якої в звичайному підручнику ускладнений;
істотно заощаджує час при багаторазових звертаннях до гіпертекстових пояснень;
дозволяє ефективно та в найбільш підходящому для конкретного індивідуума темпі, перевірити знання з конкретного розділу;
забезпечує підтримку практичної роботи в максимально можливому обсязі. [30]
ПЗМП можуть бути як незалежними програмно-методичними комплексами, так і клієнтськими додатками, що керуються веб-сервером.
Загальні вимоги до ПЗНП
У час інформаційних технологій вже ні в кого немає сумнівів, що освіта також має піддатися інформатизації, що несе за собою зміну парадигми педагогічної науки, зміну структури та змісту освіти в цілому. Нові методи навчання, які основані на активних, самостійних формах надбання знань та роботі з інформацією, поступово кількісно витіснять демонстраційні та ілюстративно-пояснювальні методи, які широко використовуються традиційною методикою навчання, що, в свою чергу, орієнтована в основному на колективне сприйняття інформації. Паралельно цьому йде процес використання програмних засобів і систем навчального призначення (пакетів ПЗНП) для підтримки традиційних методів навчання. При цьому програмним засобам (системам), які використовуються в навчальних цілях, передаються в якійсь мірі навчальні функції традиційної методики навчання, тому кожна програма повинна будуватися відповідно до дидактичних принципів навчання, які визначають дидактичні вимоги до ППЗ. Разом з загальними методами викладання, треба враховувати специфічні особливості та методики викладання кожного навчального предмету окремо, враховуючи своєрідність та особливість відповідної науки.
Відомо, що розробка ПЗ, яке використовуються в навчальних цілях, представляє собою дуже складний процес, який потребує колективної праці не тільки вчителів, методистів, програмістів, але й психологів, гігієністів, дизайнерів. Оскільки в результаті завершення розробки продукту, ПЗНП має відповідати методичним, дидактичним, психологічним вимогам.
Перерахуємо основні типи вимог до ПЗНП: [43]
педагогічні вимоги (дидактичні; методичні; обґрунтування вибору тематики учбового курсу; перевірка на педагогічну доцільність використання та ефективність використання);
технічні вимоги;
ергономічні вимоги;
естетичні вимоги;
вимоги до оформлення документації.
Розробникам ПЗ цікаві технічні вимоги. Програмно-технічні вимоги до ПЗНП визначають вимоги, що забезпечують:
стійкість до помилкових та некоректних дій користувача;
мінімізацію часу на дії користувача;
ефективне використання технічних ресурсів;
відновлення системної області пам’яті перед завершенням роботи програми;
захист від несанкціонованих дій користувача;
можливість ведення особистої інформації (зошит);
відповідність функціонування ПЗНП до опису в експлуатаційній документації.
Львов М.С. у своїх працях виділяє такі загальні методологічні вимоги до програмного продукту навчального призначення:
система інформаційної підтримки навчання має відповідати формі організації навчального процесу;
система інформаційної підтримки має бути орієнтована на всіх учасників навчального процесу;
система інформаційної підтримки має бути орієнтована на всі етапи навчального процесу;
система інформаційної підтримки повинна бути предметно-орієнтованою.
Також, з точки зору розробника ПЗ, нам цікаві вимоги до інтерфейсу ПЗНП. Коротко розглянемо деякі з них.
Міжнародні стандарти та процеси життєвого циклу програмної системи
Галузеві та міжнародні стандарти у сфері інформаційних технологій є сумою досвіду, накопиченого експертами в інженерії програмного забезпечення (ПЗ) на основі величезної кількості проектів, що проводилися в рамках комерційних структур США, Європи і в рамках військових контрактів.Велика частина стандартів створювалася як набір критеріїв для відбору постачальників [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].
У кожному конкретному проекті з розробки програмного забезпечення на етапі планування на основі рекомендацій міжнародних стандартів визначається конкретна модель життєвого циклу ПЗ. Вибір неоптимальної моделі життєвого циклу може призвести до залучення додаткових ресурсів, виникнення непередбачених ситуацій, зриву термінів постачань і створення неконкурентоспроможного програмного забезпечення низької якості.
Показники якості та надійності програмних засобів
Відповідно до стандарту [3] модель якості ПЗ складається із двох частин:
внутрішня і зовнішня якість;
якість у використанні.
Перша частина моделі містить шість характеристик для визначення внутрішньої і зовнішньої якості, які у свою чергу підрозділяють на підхарактеристики та атрибути, що вимірюються. Друга частина моделі містить чотири характеристики якості у використанні.
Характеристики якості можуть бути застосовані для будь-якого виду ПЗ, включаючи комп'ютерні програми та дані, що прошиті у постійному запам’ятовуючому пристрої.
Характеристики та підхарактеристики є підставою для розроблення вимог до якості ПЗ. Модель якості дає можливість визначити якість ПЗ та оцінити його у процесах життєвого циклу, що включають процеси придбання, формування вимог, розроблення, використання, супроводу, забезпечення якості та аудиту, і може використовуватися розробником, покупцем, службою забезпечення якості, незалежними експертами.
Взаємодія частин моделі якості програмного забезпечення
Якість у використанні повинна включати вимоги в конкретному середовищі. Ці вимоги необхідно враховувати при оцінюванні внутрішньої та зовнішньої якості, використовуючи характеристики та підхарактеристики якості. Оцінювання ПЗ є складовою частиною процесів життєвого циклу.
Якість ПЗ може бути оцінена шляхом виміру внутрішніх атрибутів (наприклад, статичного аналізу проміжних продуктів) або виміру зовнішніх атрибутів (найчастіше виміром процесу виконання коду), або виміру атрибутів якості у використанні.
Остаточною метою оцінювання ПЗ є одержання необхідних результатів у конкретному середовищі використання (рис. 1.1). З рисунка 1.1 видно, що якість процесів (якість процесів життєвого циклу визначено у ДСТУ 3918-1999 (ISO/IEC12207) впливає на якість продукту ПЗ, а якість продукту ПЗ впливає на якість у використанні.
Рисунок 1.1 - Якість у життєвому циклі ПЗ
Таким чином, оцінювання та удосконалення процесів ЖЦ призводить до поліпшення якості ПЗ, а оцінювання та поліпшення якості ПЗ призводить до покращення якості у використанні. Подібним чином оцінювання якості у використанні може давати зворотний зв'язок щодо поліпшення ПЗ, а оцінювання ПЗ може впливати на поліпшення процесів. Відповідні внутрішні атрибути ПЗ впливають на досягнення необхідної зовнішньої якості ПЗ, а зовнішня якість впливає на досягнення необхідної якості у використанні.
Вимоги до якості ПЗ повинні включати оціночні критерії для внутрішньої якості, зовнішньої якості і якості у використанні для задоволення потреб розробників, супровідників, покупців і користувачів.
Якість програмного забезпечення та життєвий цикл
Вимоги до якості ПЗ не можуть бути повністю визначені до початку проектування.
На різних стадіях життєвого циклу ПЗ існують різні точки зору на якість ПЗ та відповідні метрики (способи виміру) якості (рис. 1.2).
Рис.1.2 Взаємозв'язок між метриками якості ПЗ
Якість у використанні (розрахункова або прогнозована) ─ це якість, що оцінюється або прогнозується для готового ПЗ на кожній стадії розроблення для кожної характеристики якості у використанні та ґрунтується на результатах вимірів внутрішньої та зовнішньої якості. Якість у використанні – це точка зору користувача на якість ПЗ під час його використання в конкретному середовищі та конкретному контексті використання. При цьому виміряються межі, у яких користувач може досягти бажаних цілей у конкретному оточенні, а не властивість самого ПЗ. Рівень якості в середовищі користувача може відрізнятися від рівня в середовищі розробника через різницю в потребах і можливостях різних користувачів, розходження апаратного та підтримуючого середовища.
Вимоги до якості у використанні повинні бути визначені за допомогою метрик якості у використанні, зовнішніх метрик та іноді внутрішніх метрик. Одержання продукту, що задовольняє потребам користувача, вимагає ітеративного підходу до розроблення ПЗ з безперервним зворотнім зв'язком.
Зовнішня якість (розрахункова або прогнозована) ─ це якість, що розраховується або прогнозується для готового ПЗ на кожній стадії розроблення для кожної характеристики якості, ґрунтуючись на результатах вимірів внутрішньої якості. Зовнішня якість є набором характеристик ПЗ із зовнішньої точки зору. Зовнішня якість вимірюється під час роботи ПЗ у оточенні, що моделюється, з використанням зовнішніх метрик.
Вимоги до зовнішньої якості визначають рівень вимог до якості із зовнішньої точки зору на продукт. Вони містять вимоги, що походять із вимог якості для користувача, включаючи вимоги до якості у використанні.
Вимоги до зовнішньої якості повинні бути:
встановлені у специфікації вимог до якості з використанням зовнішніх метрик;
перетворені у вимоги до внутрішньої якості;
використані як критерії оцінювання продукту.
Внутрішня якість ─ це набір характеристик ПЗ із внутрішньої точки зору. Внутрішня якість вимірюється та оцінюється відповідно до вимог до внутрішньої якості з використанням внутрішніх метрик. Якість може бути поліпшена у процесі написання, перегляду та тестування коду.
Вимоги до внутрішньої якості визначають рівень вимог до якості із внутрішньої точки зору на продукт. Вимоги до внутрішньої якості використовують для визначення властивостей проміжних станів продукту. Для цих цілей можуть бути використані статичні та динамічні моделі, технічна документація та код, що використовується. Вимоги до внутрішньої якості можуть бути використані для визначення стратегії подальшого розроблення та можуть бути критерієм для оцінювання і верифікації у процесі розроблення. Вимоги до внутрішньої якості можуть бути визначені кількісно з використанням внутрішніх метрик.
Якість ПЗ повинна оцінюватися з використанням моделі якості. Модель якості визначають після розроблення вимог до якості готового ПЗ та проміжного продукту і вона є сукупністю атрибутів якості ПЗ, класифікованих в ієрархічну деревоподібну структуру характеристик і підхарактеристик. Верхній рівень цієї структури складається з характеристик якості, а нижній – з атрибутів якості ПЗ. Ця ієрархія не є строгою, тому що деякі атрибути можуть входити більш ніж в одну характеристику.
Стандарт [11] надає загальноцільові моделі внутрішньої та зовнішньої якості і якості у використанні.
Висновки до розділу
Зручність застосування все більше визнається як важливий фактор якості для інтерактивних програмних систем, включаючи традиційні додатки в стилі GUI (графічного інтерфейсу користувача), веб-сайти, а також велику кількість мобільних сервісів. Незручні інтерфейси користувача – одна з головних причин виникнення проблем у роботі інтерактивних систем. Незважаючи на велику кількість окремих методів, питання визначення показників практичності досі є складним і неоднозначним.
Практичність – ключовий компонент для визначення загальної якості програмного забезпечення. Зручністьвикористання найчастіше розглядається як фактор якості з певними технічними аспектами.Також це питання знаходиться в області людино-машинної взаємодії (HCI), яка забезпечує теоретичні основи та пропонує методи длястворення якісного інтерфейсу користувача.
РОЗДІЛ 2
ПРОЕКТУВАННЯ І ДИЗАЙН ІНТЕРФЕЙСУ КОРИСТУВАЧА
Принципи дизайну інтерфейсу користувача
Повноцінна навчальна діяльність можлива за умови продуманого інтерфейсу, який має забезпечувати користувачу основні можливості навчального середовища.
Взаємодія між користувачем і комп’ютером (HCI - Human-Computer Interaction) відбувається в інтерфейсі. Основною метою HCI є покращення взаємодії між користувачем і комп’ютером, роблячи комп’ютери більш кориснішими і сприйнятливими до потреб користувачів.
Найчастіше ефективність використання всіх функцій системи й ефективність роботи самої системи визначається у більшому ступені тим, як побудований її інтерфейс. [39], [40]
Природність інтерфейсу
Природний інтерфейс — такий інтерфейс, що не потребує від користувача істотно змінювати звичні для нього способи розв’язання задачі. Це, зокрема, означає, що повідомлення і результати, що отримуються за допомогою програмного продукту, не повинні вимагати додаткових пояснень. Доцільно також зберігати систему позначень і термінологію, які використовуються в даній предметній галузі.
Використання знайомих користувачу понять і образів (метафор) забезпечує інтуїтивно зрозумілий інтерфейс при виконанні завдань.
Метафори є свого роду «містком», що зв'язує образи реального світу з тими діями і об'єктами, якими доводиться маніпулювати користувачу при його роботі на комп'ютері; вони забезпечують «пізнавання», а не «згадку». Користувачі запам'ятовують дію, пов'язану із знайомим об'єктом, легше, ніж вони запам'ятали б ім'я команди, пов'язаної з цією дією.
Узгодженість інтерфейсу
Узгодженість інтерфейсу означає використання однакових або дуже схожих метафор і способів взаємодії з користувачем і порядку роботи в різних додатках.
Узгодженість надає можливість користувачам переносити наявні знання на нові завдання, освоювати нові аспекти швидше, і завдяки цьому фокусувати увагу на задачу, що вирішується, а не витрачати час на з'ясування відмінностей у використовуванні тих або інших елементів управління, команд і т.д. Забезпечуючи спадкоємність одержаних раніше знань і навичок, узгодженість робить інтерфейс зрозумілим і передбачуваним.
Узгодженість важлива для всіх аспектів інтерфейсу, включаючи імена команд, візуальне представлення інформації і поведінку інтерактивних елементів.
Узгодженість в межах продукту
Одна і та ж команда повинна виконувати одні і ті ж функції, де б вона не зустрілася, причому однаково.
Узгодженість в межах робочого середовища
Підтримуючи узгодженість з інтерфейсом, що надається операційною системою (наприклад, ОС Windows), програмний продукт може «спиратися» на ті знання і навички користувача, які він одержав раніше при роботі з іншими ПП.
Узгодженість у використовуванні метафор
Якщо поведінка деякого програмного об'єкту виходить за рамки того, що звичайно мається на увазі під відповідною йому метафорою, у користувача можуть виникнути труднощі при роботі з таким об'єктом. Наприклад, якщо для програмного об'єкту Корзина визначити операцію Запуск, то для з'ясування її значення користувачу, швидше за все, знадобиться стороння допомога.
Дружність інтерфейсу
Користувачі звичайно вивчають особливості роботи з новим програмним продуктом методом
14.06.2013 12:06-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора