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

Страницы:
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 

включаючи вирішення усіх виниклих суперечок;

адміністративним   завершенням   -   підготовкою,    збором і

перерозподілом інформації, необхідної для формального завершення

проекту.

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

14.4. Зовнішні структури організації робіт із проектування ІС

Структури організації робіт із проектування мають бути розглянуті на двох рівнях: зовнішньому і внутрішньому.

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

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

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

масштаби розробки ІС;

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

різні фактори старіння зазначених елементів;

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

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

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

колективний характер праці багатьох фахівців різної кваліфікації.

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

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

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

визначає склад завдань для автоматизації;

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

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

Замовник виконує наступні функції:

формує вимоги до системи і її частин;

видає технічне завдання, фінансує розробку ІС;

забезпечує проведення комплексу заходів щодо її створення;

проводить упровадження і прийом проекту ІС.

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

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

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

розробляє ІС за технічним завданням замовника;

бере участь у впровадженні;здійснює здачу проекту замовнику; здійснює авторський супровід проекту.

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

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

Якщо замовлення має невеликі розміри за вартістю і за тривалістю робіт, то приймають схему, в якій в одній особі виступають замовник, розробник і оператор (рис. 70).

 

 

 

 

 

Користувач>?

О


ю о

Q. Ю

 

 

 

 

 

 

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

Переваги даної структури:

мінімальна кількість організацій-учасників процесу; мінімальні терміни і вартість розробки. Недоліки:

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

недосягнення високого професійного рівня розробників.

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

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

3. У тому випадку, якщо замовник - велика організація, що курирує розробку кількох проектів ІС, застосовують наступну структуру (рис. 72).

 

Вхідні дані для обробки

 

 

Користувач

 

 

 

 

 

 

ОператорЗамовник


Експлуатаційна документаціяРозробник

Рис. 72. Структура організації робіт при повному поділі

функцій сторін

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

Переваги даної структури:

більш високий ступінь спеціалізації працівників, отже, більш високий професійний рівень;

можливість організації контролю за термінами і якістю виконання робіт.

14.5. Організаційні форми управління проектами

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

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

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

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

Форми управління, застосовувані в організаціях-розробниках ІС, залежать від виконуваних робіт. Як правило, в організаціях-розробниках виконуються роботи, пов'язані з проектуванням ІС, з підтримкою і супроводом ІС.

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

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

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

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

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

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

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

14.6. Поділ праці у проектних колективах

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

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

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

д.).

Поділ праці в колективі розробників ІС на основі поопераційного принципу, як правило, складний з огляду на наступні фактори:

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

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

відсутність об'єктивних критеріїв нормування праці фахівців;

низький ступінь стандартизації й уніфікації компонентів ІС.

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

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

 

14.7. Функціональні ролі в колективі розробників

Функції, що виконуються розробниками, в проекті підрозділяються на:

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

виробничі, які безпосередньо пов'язані з цими завданнями.

У концепції Microsoft Solution Framework визначено шість рольових кластерів, які відповідним чином структурують проектні функції розробників (рис. 73). Вони відповідальні за різні сфери компетенціїтобто функ-ціональної спеціалізації (functional areas) і пов'язані з ними цілі і зав-дання (табл. 28).

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


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

 

Таблиця 28

 

Характеристика рольових кластерів проектної групи MSF

 

Рольовий кластер

Мета

Область компетенції

Функції

1

2

3

4

Управління продуктом

Задоволення замовників

Маркетинг. Бізнес-віддача (бізнес-пріоритети). Подання інтересів замовника. Планування про­дукту

Виступає в ролі представника замовника.

Страницы:
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 комп'ютерні науки