2.1. Життєвий цикл програмного продукту

Після закінчення майже двох десятків років активного використання комп'ютерних технологій Міністерство оборони США прийшло до висновку, що основною причиною невдач великих інформаційних проектів є методологія їхньої реалізації (точніше, її відсутність). Від неприємних сюрпризів не могли врятувати ні досвідчені менеджери, ні вичерпне тестування, ні застосування CASE-засобів. Кожна нова виявлена помилка змушувала майже цілком переглядати проект. І навіть якщо зрештою вдавалося одержати прийнятний результат, при надходженні наступного замовлення картина повторювалася. Усвідомлення зазначеної обставини змусило Міністерство оборони США зробити крок у напрямку стандартизації процесів розробки програмних систем. Перший стандарт був затверджений у 1985 році, ав 1994-1996 роках був розроблений і прийнятий новий, значно більш детальний і глибокий стандарт - MІ-STD-498. Він являє собою комплект із трьох документів загальним обсягом ококло 600 сторінок і встановлює термінологію, процеси, задачі й об'єкти, використовувані при розробці і супроводі проектів програмних систем. Основні положення цього військового стандарту погоджені з міжнародним стандартом ІSO/ІEC 12207:1995 ("Процеси життєвого циклу програмних засобів"), але разом з тим є більш конкретними і наближеними до практики.

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

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

17

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

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

o область застосування системи;

o вимоги користувача (замовника) до функціональних можливостей сис

теми, до рівня її безпеки і захищеності;

o эргономические вимоги і вимоги до рівня кваліфікації користувачів;

o ступінь документованості системи;

o організація супроводу і т.д.

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

Нижче приведене "вільний виклад" змісту стандартів щодо основних етапів розробки програмного продукту, і хоча в жодному зі знайомих авторам стандартів не фігурує поняття UCD-технології, її духом пронизаний кожний з них.

ПРОЕКТУВАННЯ

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

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

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

18

ПРОТОТИПИРОВАНИЕ

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

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

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

ІСПИТ ПРОГРАМНОГО ПРОДУКТУ

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

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

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

19

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

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

ПОВТОРНЕ ВИКОНАННЯ ЕТАПІВ РОЗРОБКИ

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

ОЦІНКА СПОЖИВЧИХ ВЛАСТИВОСТЕЙ ДОДАТКА В 11РОЦЕССЕ РОЗРОБКИ

Як було зазначено вище, основна мета іспитів - визначити, наскільки пол-но розроблений додаток (у першу чергу, його інтерфейс) відповідає потреб-ностям і чеканням користувача. У зв'язку з цим основним напрямком испы-таний додатка є оцінка його "споживчих властивостей" (Usabіlіty). Така оцінка повинна проводитися, починаючи із самих ранніх етапів розробки. Основою для проведення оцінки повинні служити дані про те, як користувачі звичайно виконують ту роботу, що покликано автоматизувати створюваний додаток. У міру того, як розробка просувається, оцінка споживчих властивостей додатка повинна постійно уточнюватися. Чим частіше і коректніше буде проводитися оцінка, тим вище буде якість розробки.

ТЕХНІКА ПРОВЕДЕННЯ ІСПИТІВ СПОЖИВЧИХ ВЛАСТИВОСТЕЙ ДОДАТКА

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

20

ние для реєстрації результатів іспитів. Проте , навіть звичайні "офис-ные інструменти" (магнітофон, секундомір і записна книжка) можуть принести істотну користь. Використовувані тести не повинні бути "усеохоплюючими". Значно більш корисні швидкі ітеративні тести, орієнтовані на дослідження конкретних проблем; практика показує, що при такому підході 6-10 учасників іспитів можуть ідентифікувати 80 - 90 відсотків основних проблем розробки.

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

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

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

АЛЬТЕРНАТИВНИЙ ПІДХІД ДО ПРОВЕДЕННЯ ІСПИТІВ ДОДАТКА

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

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

На розробку продукту впливають багато додаткових факторів. J lanpmіep, маркетингові розуміння можуть зажадати скорочення термінів раз-работки, чи порівняльні оцінки з аналогічними продуктами можуть змусити

21

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

o Кожна додаткова характеристика потенційно впливає на поводження,

складність, стійкість, експлуатацію і витрати по супроводу создавае

мого ПО.

o Після виходу у світло офіційної версії продукту сутужніше усунути пробле

ми, що залишилися невирішеними на стадії розробки, оскільки користувачі можуть

пристосуватися, чи навіть "підкоритися" наявним недолікам вашого ПО.

o Простота користувальницького інтерфейсу - це далеко не те ж саме, що його

спрощенство. Щоб зробити щось простим у використанні, часто потрібно

прикласти багато сил і створити дуже складний виріб з погляду його внут

ренней організації.

o Доробки програмного коду з метою розширення функціональних віз

можностей ПО зовсім не обов'язково будуть мати пропорційний поклади

тельный ефект із погляду інтерфейсу користувача. Наприклад, якщо основ

ная завдання користувача полягає у виборі єдиного об'єкта, те надаючи

йому можливість одночасного вибору декількох об'єктів, ви тільки вус

ложняете йому роботу.