• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Моделі груп розроблювачів програмного забезпечення.

Групова ізоляція

Групова поляризація

Групова нормалізація

Групова сумісність

Соціально - психологічний клімат

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

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

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

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

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

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

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

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

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

Традиційні моделі організації колективів розробників ПЗ.

Модель бригада.

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

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

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

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

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

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

Втрата кваліфікації програміста при висуненні на керівні посади і уся зростаюча ізольованість програмістів призвели до ідеї створення моделі «Бригади головного програміста».

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

В «Бригаді головного програміста» виділяють нижче перелічені ролі.

o Головний хірург - є головним конструктором і пише найбільш важливі шматки програми. Він повинен бути компетентним у даній галузі, мати стаж роботи понад 10 років, володіти суттєвими знаннями в системних і прикладних галузях.

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

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

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

Ієрархічна модель групи

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

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

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

Читайте також:

1. I. Введення в розробку програмного забезпечення
2. III. Етапи розробки програмного забезпечення
3. Автокореляція залишків – це залежність між послідовними значеннями стохастичної складової моделі.
4. Аналіз економічноїї політики за допомогою моделі Мандела-Флемінга. Випадки вільного та фіксованого валютного курсів.
5. Аналіз програмного забезпечення з управління проектами.
6. Аналітичний підбір математичної моделі.
7. Бізнес-моделювання в системі управління розвитком підприємства. Поняття та етапи формування бізнес-моделі
8. Вибір підходу до процесу соціальної роботи зале­жить від теоретичної моделі, якої дотримуються соці­альні працівники, обраної стратегії втручання і методу соціальної роботи.
9. Види пенсійного забезпечення.
10. Види світогляду: міфологічний, релігійний та філософський (натуралістична, об’єктивно-ідеалістична, субєктивно-ідеалістичні і матеріалістичні моделі).
11. Види соціального забезпечення.
12. Визначення пріоритетів стабілізації розвитку економіки та державне управлінське забезпечення.

Переглядів: 936