Інформаційний маркетинг (2002)

Якщо 10 років тому повний життєвий цикл продукту в середньому становив 8—12 років, то в наш час — лише 2—4 роки. У зв’язку із цим інформаційна структура повинна прогнозувати конкурентоспроможність і задавати її показники в момент проектування інформаційного продукту з великим запасом, тоді як розроблення продукту з високою конкурентоспроможністю потребує тривалого терміну і великих витрат. Отже, при проектуванні нового продукту інформаційна структура повинна забезпечити оптимальне поєднання переваг швидкого виходу на ринок з низькими темпами морального старіння.

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

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

надійність поставок; технічні інструкції;

ремонт устаткування, коригування програм та актуалізацію БД;

надання знижок;

простоту вступу в контакт.

Сервісне обслуговування стало закономірним, усвідомленим підприємцями, етапом ЖЦ продукту, оскільки подовжує його.

Як відомо, головна ціль програмної інженерії — досягнення високої економічної ефективності. Для цього необхідне глибоке розуміння всіх процесів, пов’язаних з кожною фазою життєвого циклу продукту. Побудова його моделі — крок до пізнання цих закономірностей. У самому загальному вигляді модель ЖЦ продукту може бути описана трьома послідовними фазами.

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

Друга фаза — власно створення ІС та впровадження її — може бути побудована по-різному залежно від прийнятої моделі життєвого циклу. Головну роль протягом цієї фази відіграє організація-розробник.

Третя фаза — перехід системи після впровадження у повне розпорядження замовника або організації-користувача, інтереси якої він представляє; розробник здійснює супроводження системи. У процесі супроводу розробник усуває всі помилки, виявлені після впровадження, здійснює адаптацію ІС з урахуванням умов експлуатації, що змінилися, на вимогу замовника доопрацьовує її з метою підвищення якості функціонування. Правильно організований супровід значною мірою уповільнює моральне старіння програмного забезпечення ІС, термін служби якого може в два-три рази перевищувати строк морального старіння ЕОМ.

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

каскадна модель;

спіральна модель;

метод швидкого прототипу;

метод послідовного нарощування функцій;

модель, заснована на повторному використанні компонентів;

модель, заснована на автоматизованому синтезі програм.

Каскадна модель характеризується чіткою впорядкованістю таких стадій створення і впровадження АС:

визначення вимог;

розроблення технічного завдання;

планування розробки;

проектування;

реалізація;

збирання системи;

супроводження;

уточнення вимог.

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

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

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

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

Метод швидкого прототипу передбачає розроблення в стислі строки діючого макета частини автоматизованої системи, найбільш критичної до змін вимог користувачів, а також проведення тестувальної експлуатації макета до розроблення повномасштабного зразка. Звичайно насамперед прототипуванню підлягає інтерфейс користувача з майбутньою системою. Це дає змогу залучити кінцевих користувачів до активної співпраці на ранній стадії розроблення АС і таким чином уникнути доопрацювань закінченої системи (що коштують дорого), як це часто трапляється при використанні каскадної моделі. Основне призначення прототипування — полегшити виявлення всіх вимог користувачів. Тому, як правило, прототип після розроблення технічного завдання більше не використовують і далі модель життєвого циклу збігається з каскадною. Такий підхід, зокрема, реалізовано в британській технології SSADM. Передбачена британським стандартом розробка діючого прототипу ще більше пом’якшує недоліки каскадної моделі.

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

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

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

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

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

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

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

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