Особливості процесу розробки і впровадження управлінських ІС

Тема 6. Управління процесом розробки і впровадження ІС підприємств в умовах ЗЕД

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

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

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

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

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

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

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

Ядро будь-якої інформаційної системи становить програмне забезпечення. Незважаючи на те, що програмне забезпечення має виконуватися на певній апаратній платформі, роль апаратної платформи як фізичного об’єкта, що є результатом інженерно-виробничого процесу, поступово та невпинно зменшується. В якості прикладів, що підтверджують ці твердження, можна навести наступні. По-перше, слід звернути увагу на сучасні тенденції в розробці мікропроцесорів – з появою кожного нового покоління мікропроцесорів все більшого значення набуває мікрокод, "прошитий" у них, що фактично являє собою різновид програмного забезпечення. По-друге, фахівці погоджуються, що найбільш перспективними платформами для розробки та виконання прикладних програм є Sun Java та Microsoft.NET, що являють собою цілком програмні платформи, які виступають "посередником" між кодом прикладних програм і апаратним середовищем, повністю обмежуючи доступ прикладних програм до апаратних ресурсів, на відміну від прийнятого в минулому підходу, коли операційні системи обмежували доступ лише до критично важливих апаратних ресурсів.

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

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

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

• самої програми (у вихідних текстах або в машинних кодах);

• режиму експлуатації (включає вихідні дані та кваліфікацію користувача);

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

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

Рис. 6.1. Кортеж програми

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

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

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

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

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

Найчастіше серед них відзначають такі:

• помилки в прогнозах;

• вимоги, що постійно змінюються;

• нечітко поставлені цілі і завдання проекту;

• невчасно незафіксовані або неповні проектні специфікації;

• низька якість кодування;

• недостатня взаємодія виконавця і замовника;

• порушення бюджетних і часових обмежень.

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

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

Дуже важливим питанням у характеристиці процесу розробки програмного забезпечення є безпосередній аналіз терміну "програмний виріб".

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

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

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

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

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

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

Таким чином, у сфері розробки програмного забезпечення поняття "виробничий процес" відсутнє. Поняттям, що характеризує процес створення кінцевого продукту, є поняття "процес розробки програмного забезпечення".

При цьому процес розробки програмного забезпечення включає такі взаємопов’язані етапи:

1.Проектування програмного забезпечення.

2.Кодування.

3.Компіляція.

4.Компоновка, тобто збір в одне ціле скомпільованих частин.

5.Тестування.

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

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

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

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

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

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

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

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

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

"Паспорт проекту" визначає такі ключові для проекту питання, як:

• середовище виконання проекту – апаратні вимоги, вимоги до ОС, вимоги до мережного середовища, вимоги до СУБД й інших зовнішніх по відношенню до даної системах, з якими повинні взаємодіяти отримані в результаті реалізації проекту прикладні програми;

• середовище розробки проекту – вказуються засоби автоматизованого проектування, використані мови програмування, компілятори й транслятори мов, інтегровані середовища програмування, засоби для проектування БД, у тому числі візуальні конструктори запитів і дизайнери БД, використані компоненти, що не входять у стандартну поставку середовища програмування;

• засоби створення документації – використані інструменти для генерації документації, що входить у кінцеву поставку прикладного програмного забезпечення;

• засоби створення дистрибутивів – використане середовище для генерації дистрибутиву, що поставляється кінцевому користувачу створеного у результаті реалізації проекту програмного продукту;

• середовище для тестування проекту – описуються середовище, а також інструментальні засоби, що застосовувалися для тестування проекту.

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

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

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

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

У випадку, якщо робота над проектом припиняється або відкладається на тривалий строк, використання документа "Паспорт проекту" дозволяє при необхідності відтворити актуальне середовище розробки при поверненні до робіт над проектом.

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

Також "Паспорт проекту" може бути використаний розробником при початковій підготовці свого робочого місця до роботи над конкретним проектом.

Дата добавления: 2014-01-04