Файл: R_3.doc

У результаті проведення зовнішньої інспекції можуть бути прийняті такі рішення:

1. етап завершено без зауважень;

2. етап завершено із зауваженнями, виправлення яких може бути здійснено оперативно;

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

3.3. Проектування взаємодії
користувача з програмним виробом

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

Реалізація цих властивостей може бути досягнена при виконанні таких груп правил: правила мінімізації помилок користувача; правила виявлення помилок користувача; правила мінімізації складності програмного виробу.

Правила мінімізації помилок користувача

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

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

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

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

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

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

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

---

Правила виявлення помилок користувача

1. Система має приймати будь-які дані. Якщо введені дані є неприпустимими, то система повинна обов’язково повідомити про це користувача, щоб він не прийняв рішення на основі недостовірної інформації.

2. Користувачеві має надаватись можливість перевірки введених даних ще до початку їх обробки.

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

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

5. Там, де особливо важлива підвищена вірогідність результатів обробки, слід використовувати надлишок даних для викриття помилки.

Правила мінімізації складності програмного виробу

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

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

3.4. Структурне подання даних

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

Канонічними ці структури називають тому, що вони відповідають трьом основним конструкціям структурного програмування: лінійна послідовність операторів, функцій або процедур; розподільна конструкція (альтернативна чи конструкція вибору); циклічна конструкція.

Пояснення до структури послідовність:

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

<Інформаційна база даних>:: =<Оперативні дані >,

<Регламентні дані>,

<НСІ>,

<Облікові дані>

<Запис>:: = таб.номер,

прізвище,

рік народження,

стать,

---

соц.група

Функціональним аналогом цієї структури є лінійна послідовність операторів, функцій чи процедур. Це означає: якщо на черговому рівні опису структури інформаційну сукупність подано як послідовність, то в алгоритмі обробки цієї сукупності НЕ може з’явитися цикл або конструкція вибору, а ТІЛЬКИ лінійна послідовність.

Пояснення до структури вибір:

вибір — це сукупність альтернативних елементів. Наприклад: <Запис неплоского файла>:: =<Запис 1 типу>

| <Запис 2 типу>

Функціональним аналогом цієї структури є розподільна конструкція: альтернативна або конструкція вибору .

Пояснення до структури повторення:

повторення — це сукупність однорідних (подібних) елементів, що впорядковані за певним правилом. Наприклад: <Вектор>:: =<Елемент>*

<Плоский файл>:: =<Запис >*

Функціональним аналогом цієї структури є циклічна кон­струкція.

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

К онтрольні питання

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

2. Чому стадії технічного завдання приділяється особлива увага?

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

4. Мета додержання правил проектування інтерфейсу.

5. О сновні структури даних та їх функціональні аналоги.

---