Методи і технічні засоби ергономіки
Информация - Психология
Другие материалы по предмету Психология
? людини роботою, а також функціонування системи. Коли занадто зростає робоче навантаження, система автоматично приймає на себе велику її частину, щоб визволити користувача [19].
Розглядаючи питання про те, які методи розподілу функцій корисні і відповідають системі "людина-ЕОМ", П.Т.Кідд [20] звертається до перших робіт у цій області і, зокрема, до статті А.Чапаніса [21].
А.Чапаніс указує на ряд питань, що часто ігноруються при розподілі функцій:
1) загальні порівняння людини і машини найчастіше невірні; наприклад, хоча компютер краще виконує обчислення, це не причина завжди використовувати його в цих цілях;
2) не завжди важливо вирішувати, який компонент зробить конкретну роботу краще; цілком достатнім може бути використання адекватного компонента;
3) загальні порівняння людей і машин не вказують шляхів пошуку компромісу.
А.Чапаніс указує також на ряд інших важливих моментів. По-перше, розподіл функцій у людино-машинних системах частково визначається соціальними й економічними цінностями, що у різних країнах можуть розрізнятися. Тому проектування, ефективне в одній країні, може не спрацьовувати в іншій. По-друге, розподіл функцій повинен постійно переоцінюватися, оскільки технологія безупинно міняється і те, що неможливо сьогодні, цілком може бути прийнятним у найближчому майбутньому. По-третє, багато утруднень при розподілі функцій обумовлені інженерною невизначеністю. Інженери часто змінюють проект і іноді діють при цьому методом проб і помилок.
А.Чапаніс рекомендує, щоб при розподілі функцій спочатку готувалися повні і детальні специфікації. За цим повинний випливати аналіз усіх функцій системи. Потім можна провести спробний розподіл функцій, Після цього повинна піти оцінка всього набору функцій, розподілених людям, щоб переконатися, що немає їхні перевантаження або недовантаження.
Аналізуючи ці рекомендації, П.Т.Кідд висловлює припущення, що, видимо, є ряд моментів, що роблять саму ідею формального розподілу функцій нереалістичної в ситуації проектування.
По-перше, як видно з досвіду проектування, написати повну і детальну специфікацію майже неможливо. Деякі обмеження і цілі важко сформулювати і найчастіше не можна ясно виразити, поки не побудована модель або макет системи. Коли специфікація написана і представлена клієнтові, він, імовірно, її прийме. А коли система буде побудована, він, імовірно, скаже, що це але те, чого він хотів або очікував. Причина включається в тім, що деякі мети й обмеження існують у неявному виді і стають явними тільки тоді., коли ціль не досягнута або порушені обмеження. Це одна з причин, чому програмне забезпечення (ПО) часто виявляється неадекватним або невідповідним.
По-друге, проектування не є упорядкованим процесом, що рівномірно йде від специфікацій до втілення. У ньому дуже багато ітерацій, і він набагато складніше, ніж його часто зображують у простих лінійних моделях. По ходу проектування специфікації також часто міняються, коли зясовується, що щось не підходить або хтось пропонує кращу ідею. Звичайно, ці зміни підлягають формальному контролеві, але все рівно проектна специфікація не буде статичним документом.
По-третє, проектування процес багато в чому підсвідомий і творчий. Ідеї приходять людям зненацька, раптом. Тоді вони вивчаються й обговорюються. Починаються якісь експерименти. Ідея модифікується і т.д. Під час цього творчого процесу рішення по розподілі функцій приймаються скоріше неявно, чим явно.
По-четверте, інновації в технології частіше починаються в дослідницькій лабораторії. Цей процес може направлятися цікавістю (наприклад, що б можна зробити з технологією експертних систем?). Деякі наукові ідеї можуть втілитися в продукті, що потім куплять клієнти і додадуть них до існуючих систем.
По-пяте, навіть коли на початку є зелена вулиця, апаратні і програмні засоби часто купуються "з полки", у непристосованому виді. Отже, контроль за розподілом функцій обмежений, оскільки детальне проектування ведеться насправді третьою стороною.
По-шосте, при розподілі функцій визначається тільки, що будуть робити людина і машина. При цьому нічого не говориться про те, як машина працює. Сучасною мовою це значить, що розподіл функцій майже не впливає ні на архітектуру компютерів, ні на особливості програмного забезпечення.
По-сьоме, при розподілі функцій нічого не говориться про цілях системи, а від них часто в першу чергу залежить, що буде вимагатися від людини. Так, наприклад, щоб автоматизувати планування роботи цеху, можна використовувати інформаційну систему в режимі генерації і, можливо, у реальному масштабі часу. Або можна використовувати таку систему пасивно, щоб допомогти користувачеві зрозуміти особливості планувальних алгоритмів і правил. Якщо як мету проектувальник вибирає інформаційну систему для автоматичного планування, він тим самим накладає обмеження на дії, очікувані від людей. У методах розподілу функцій цей факт ніяк не відбитий, і можна сказати, що вони передбачають вторинні, більш детальні рішення про розподіл і спираються на основні проектувальні рішення, уже прийняті проектувальником системи задовго до того, як у процесі проектування встає питання про розподіл функцій.
Нарешті, проектування скоріше мистецтво, чим наука. У ньому змішалися формальні і неформальні методи, аналізи, математика, а також елементи суджень і досвіду. Частіше проектувальник знає, що для досягнення заданого результату йо