3.1 Проблеми підприємств та вирішення їх ІТ-консультантами

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

По допомогу в консультаційну компанію звертаються в різних ситуаціях [2, с. 88]:

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

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

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

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

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

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

Загалом, причини, спонукаючі клієнта звернутися по допомогу до консультантів, наступні:

? керівник і його співробітники не здатні розв'язати проблему, яка з?явилася;

? нестача власних ресурсів (працівників, часу, навичків, знань) для вирішення проблем, що виникають час від часу;

? необхідність в інтенсивній допомозі на тимчасовій основі;

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

? керівник взагалі не упевнений, що проблема є, але він звертається до консультанта, щоб в цьому упевнитися і отримати незалежний погляд з боку;

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

Існують і інші ситуації, коли краще запросити консультанта. Але у будь-якому випадку загальними критеріями явля-ются :

? наявність проблеми;

? недолік тимчасових або людських ресурсів для її вирішення;

? недолік спеціальних знань або досвіду;

? висока ціна питання.

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

Перші дві групи керуються при цьому золотим правилом менеджменту, сформульованим Томасом Пітерсом: «Реформувати треба те, що працює добре, бо тут сили можуть быгь мобілізовані негайно або принаймні швидше, ніж в інших сферах».

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

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

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

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

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

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

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

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

3.2 Інформаційне забезпечення та етапи проведення ІТ-консалтингу на підприємствах за різними моделями

ІТ-консалтинг забезпечує усебічну професійну підтримку в області інформаційних технологій. Комплексний ІТ-консалтинг є одним з початкових етапів для побудови ІТ-системи підприємства.

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

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

? діаграми потоків даних в нотації Йодана/Де Мазко або Гейна-Сарсона, що забезпечують аналіз вимог і функціональне проектування інформаційних систем;

? розширення Хатлі і Уорда-Меллора для проектування систем реального часу, засновані на діаграмах переходів станів, таблицях і деревах рішень, картах і схемах потоків управління;

? діаграми «суть-зв'язок» (у нотації Чена або Баркера) або скобові діаграми Варнье-Орра для проектування структур даних, схем БД, форматів файлів як частини усього проекту;

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

Сучасні структурні методології аналізу і проектування класифікуються за наступними ознаками [14, с. 332]:

? по відношенню до шкіл - Software Engineering (SE) і Information Engineering (IE);

? по порядку побудови моделі - процедурно-орієнтовані, орієнтовані на дані і інформаційно-орієнтовані;

? за типом цільових систем - для систем реального часу (СРЧ) і для інформаційних систем (ІС).

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

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

Розробка ПЗ заснована на моделі ВХІД-ОБРОБКА-ВИХІД: дані входять в систему, обробляються або перетворяться і виходять з системи. Така модель використовується в усіх структурних методологіях. При цьому важливий порядок побудови моделі.

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

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

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

Головні відмінності інформаційних систем від систем реального часу приведені в таблиці 3.1 [18, с. 92], засобами підтримки цих особливостей і розрізняються відповідні структурні методології.

Таблиця 3.1 - Головні відмінності інформаційних систем від систем реального часу [18, с. 92]

Таблиця 3.2 [3, с. 104] класифікує найчастіше використовувані методології відповідно до вищеперелічених ознак (дані по частоті використання отримані на основі аналізу інформації по 127 CASE-пакетам).

Таблиця 3.2 - Класифікація найбільш часто використовуваних методологій [3, с. 104]

У усіх перерахованих моделях проектування інформаційних систем в різних комбінаціях використовуються приведені в таблиці 3.3 [15, с. 337] техніки структурних діаграм.

Таблиця 3.3 - Техніка структурних діаграм [15, с. 337]

Необхідно відмітити, що для проектування систем реального часу використовуються спеціальні типи структурних діаграм:

1. діаграми потоків управління;

2. діаграми переходів станів;

3. контекстні графи;

4. матриці станів/подій;

5. таблиці рішень та ін.

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

Структура підходу до розробки консалтингових проектів проходить у декілька етапів (рис. 3.1) [1, с. 49].

Рисунок 3.1 - Етапи проведення ІТ-консалтингу на підприємствах [1, с . 49]

З рис. 3.1 ми бачимо 6 етапів проведення ІТ-консалтингу на підприємствах, які далі розглянемо більш детально.

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

Першим кроком власне розробки являється попереднє вивчення завдання. Попереднє вивчення повинне відповісти на низку запитань:

? У чому недоліки існуючої ситуації?

? Які поліпшення можливі?

? На кого вплине нова система?

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

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

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

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

У рамках етапу 2 (проведення обстеження діяльності підприємства) здійснюється:

? попереднє виявлення вимог, що пред'являються до майбутньої системи;

? визначення оргштатной і топологічною структур підприємства;

? визначення переліку цільових завдань (функцій) підприємства;

? аналіз розподілу функцій по підрозділах і співробітниках;

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

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

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

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

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

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

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

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

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

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

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

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

? складання переліку автоматизованих робочих місць підприємства і способів взаємодії між ними;

? аналіз застосовності існуючих систем управління підприємствами (передусім класів MRP і ERP) для вирішення необхідних завдань і формування рекомендацій по вибору такої системи;

? спільне із замовником ухвалення рішення про вибір конкретної системи управління підприємством або розробці власної системи;

? розробка вимог до технічних засобів;

? розробка вимог до программым засобів;

? розробка пропозицій по етапах і термінах автоматизації.

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

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

? проектування фізичної бази даних;

? побудова ієрархії функцій модулів, що підлягають програмуванню;

? оцінка витрат на реалізацію.

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

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

3.3 Перспективні моделі консалтингу в інформаційній діяльності

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

? SADT (Structured Analysis and Design Technique);

? структурного системного аналізу Гейна-Сарсона (Gane-Sarson);

? структурного аналізу і проектування Йодана/Де Мазко (Yourdon/De Marko);

? розвитку систем Джексона (Jackson);

? розвитку структурних систем Варнье-Орра (Warnier-Orr);

? аналізу і проектування систем реального часу Уорда-Меллора (Ward-Mellor) і Хатли (Hatley);

? інформаційного моделювання Мартіна (Martin).

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

Проект архітектури ідентифікує:

? головні модулі;

? маршрути зв'язку за даними і управлінням між модулями;

? основні підпрограми усередині кожного модуля;

? структури даних, специфікації форматів вхідних і вихідних файлів.

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

Зазвичай пропонується наступна послідовність кроків при проектуванні специфікацій:

1. розподіл проекту на 10-50 модулів;

2. організація ієрархії модулів;

3. визначення маршрутів даних між модулями;

4. визначення форматів зовнішніх файлів;

5. визначення способів доступу до зовнішніх файлів;

6. визначення структур даних;

7. проектування ключових алгоритмів;

8. визначення підпрограм усередині кожного модуля.

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

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

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

Висновки

Отже, після вивчення теми курсової роботи «Шляхи розвитку та основні моделі консалтингової діяльності», ми можемо зробити наступні загальні висновки:

1. В першому розділі ми з?ясували, що інформаційний консалтинг (ІК) - відносно новий вид ділових послуг на українському ринку. У сучасних умовах багато видів послуг надаються на основі інформаційних і телекомунікаційних технологій. Особливо велика їх частка при наданні консультаційних, освітніх, фінансових і страхових послуг.

Загальний перелік консалтингових послуг у сфері ІТ виглядає таким чином:

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

? аналіз інформаційних потреб користувачів і підготовка оптимальних рішень по створенню інформаційних систем і мереж;

? системний аналіз і консультування по вибору готового програмного забезпечення, надання послуг з впровадження і супроводу програмного забезпечення;

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

Проектування інформаційних систем і управління процесами має на увазі побудову моделі AS IS і подальший перехід до моделі TO-BE, що є запорукою автоматизації «правильних», вдосконалених процесів.

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

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

2. В другому розділі ми виявили, що діаграми потоків даних (DFD) є основним засобом моделювання функціональних вимог проектованої системи. З їх допомогою ці вимоги розбиваються на функціональні компоненти (процеси) і представляються у вигляді мережі, пов'язаної потоками даних. Головна мета таких засобів - продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також виявити стосунки між цими процесами. У DFD (Data Flow Diagram), модель системи визначається як ієрархія діаграм потоків даних, що описують процеси перетворення інформації від моменту її введення в систему до видачі кінцевому користувачеві.

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

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

3. В третьому розділі ми побачили, що ІТ-консалтинг забезпечує усебічну професійну підтримку в області інформаційних технологій. Комплексний ІТ-консалтинг є одним з початкових етапів для побудови ІТ-системи підприємства.

Сучасні структурні методології аналізу і проектування класифікуються за наступними ознаками:

? по відношенню до шкіл - Software Engineering (SE) і Information Engineering (IE);

? по порядку побудови моделі - процедурно-орієнтовані, орієнтовані на дані і інформаційно-орієнтовані;

? за типом цільових систем - для систем реального часу (СРЧ) і для інформаційних систем (ІС).

Структура підходу до розробки консалтингових проектів проходить у декілька етапів:

? етап 1 - аналіз первинних вимог і планування робіт;

? етапу 2 - проведення обстеження діяльності підприємства;

? етапі 3 - побудова моделей діяльності підприємства;

? етап 4 - узгодження системного проекту із замовником;

? етап 5 - вибір системного проекту на основі виявлених і узгоджених вимог;

? етап 6 - перетворення системного проекту в технічний проект (модель реалізації).

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

? SADT (Structured Analysis and Design Technique);

? структурного системного аналізу Гейна-Сарсона (Gane-Sarson);

? структурного аналізу і проектування Йодана/Де Мазко (Yourdon/De Marko);

? розвитку систем Джексона (Jackson);

? розвитку структурних систем Варнье-Орра (Warnier-Orr);

? аналізу і проектування систем реального часу Уорда-Меллора (Ward-Mellor) і Хатли (Hatley);

? інформаційного моделювання Мартіна (Martin).

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

РЕКОМЕНДАЦІЇ

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

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

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

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

ПЕРЕЛІК ПОСИЛАНЬ