Життєвий цикл ІПП - інформаційний маркетинг - Маркетинг - Каталог статей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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