І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації - страница 35

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 

Формує  спільне бачення/рамки проекту.

Організовує роботу з вимогами замовника.

Розвиває сфери застосування в бізнесі.

Формує очікування замовника. Визначає      компроміси між параметрами "можливості продукту / час / ресурси". Організовує маркетинг та PR. Розробляє, підтримує і виконує план комунікацій

Управління програмою

Досягнення результату в рамках проектних обмежень

Управління проек­том.

Вироблення архі­тектури рішення. Контроль виробничого процесу. Адміністративні служби

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

Проводить в життя важливі ком­промісні рішення.

Розробляє, підтримує і виконує зве­дений план і календарний графік проекту


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

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

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

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

Керівник команди (Team Leader) - здійснює технічне керівництво командою в процесі виконання проекту.

Архітектор (Architect) - відповідає за проектування архітектури системи, погоджує розвиток робіт, пов'язаних із проектом.

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

Експерт предметної сфери (Domain Expert) - відповідає за вив­чення сфери застосування, підтримує спрямованість проекту на вирішення завдань даної сфери.

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

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

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

Тестувальник (Tester) - перевіряє функціональність, якість і ефективність продукту. Будує і виконує тести для кожної фази розвитку проекту.

Бібліотекар (Librarian) - відповідає за створення і ведення спільної бібліотеки проекту, яка містить всі проектні робочі продукти, а також за відповідність робочих продуктів стандартам.

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

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

архітектор проекту;

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

керівники команд розробки підсистем;

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

експерт предметної сфери.

14.8. Внутрішні організаційні структури проектної групи

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

потенціал колективу розробників;

обсяг і складність розроблювальних проектів;

технологія проектування системи;

модель життєвого циклу системи.

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

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

Адміністративний керівник у групі здійснює, як правило, наступні функції:

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

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

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

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

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

Головний фахівець виконує наступні функції:

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

виконує разом з аналітиками декомпозицію системи;контролює терміни проектування і повноту проектної документації;

несе відповідальність за розробку проекту у всіх аспектах.

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

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

Аналітики і програмісти здійснюють безпосередньо розробку частин проекту.

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

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

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

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

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

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

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

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

При цьому виділяються наступні групи фахівців:

група системного аналізу і проектування;

група реалізації (група програмування);

група тестування;

адміністративна група.

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

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

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

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

14.9. Організаційні форми реінжинірингу бізнес-процесів

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

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

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

2.   Спільна робота користувачів (власників бізнес-процесів) і груп (ко­манд) реінжинірингу з визначення змісту перепроектованих бізнес-процесів.

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

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

5.   Відволікання учасників груп реінжинірингу від основної роботи на період реінжинірингу бізнес-процесів.

6.   Контроль з боку груп реінжинірингу реалізації і впровадження сфор­мованого проекту.

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

8.   Безупинне планування і контроль робіт з реінжинірингу бізнес-процесів з боку адміністрації підприємства.

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


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

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

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

їхня участь у реінжинірингу бізнес-процесів;

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

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

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

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

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

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 


Похожие статьи

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

І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Практикум з навчальної дисципліни основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Робоча програма навчальної дисципліни Проектування інформаційних систем

І О Ушакова - Робоча програма навчальної дисципліни системний аналіз для студентів напряму підготовки 6 050101 комп'ютерні науки