- чіткими організаційними цілями;
- зобов'язанням менеджменту вести організацію до досягнення встановлених цілей;
- середовищем, яке дає змогу кожному розробникові вдосконалювати і ефективно застосовувати свої знання і навички;
- вимірюваннями, що дають змогу добирати ефективні процеси. Будь-яка «здорова» культура повинна містити три істотні компоненти:
- персональне зобов'язання кожного розробника створювати якісні продукти шляхом систематичного застосування передового досвіду інженерії програмного забезпечення;
- зобов'язання менеджерів усіх, рівнів забезпечувати середовище, в якому якість програмного забезпечення (у всіх його аспектах) є фундаментальною концепцією і кожен розробник може реалізовувати цю концепцію;
- зобов'язаній всіх членів організації постійно вдосконалювати процеси, в яких воли беруть участь і продукти, які вони створюють.
На рис. 2.1 показано, як культура інженерії програмного забезпечення пов'язана з цілями, пріоритетами і технічною практикою розробки програмного забезпечення [25]. Культура інженерії програмного забезпечення визначає якісний рівень дій, процесів і технічних можливостей організації, задає проектні цілі і можливості організації. Рівень проектних цілей залежить від того технічного досвіду, який нагромоджено в організації. Чим більший цей досвід, тим вищі проектні цілі і тим краще відповідне програмне забезпечення здатна створювати організація. Технічний досвід, очевидно, впливає на загальну культуру організації і чим він більший, тим вища культура (А). Культура організації є, з одного боку, основою для діяльності кожного розробника, а з іншого - культура організацій буде тим вища, чим вища культура кожного розробника (В). Нарешті, культура інженерії програмного забезпечення допомагає встановлювати пріоритети менеджменту. Очевидно, вищі пріоритети менеджменту визначають (підсилюють) загальну культуру організації (С).
Рис. 2.1. Зв'язок культури з організацією
Сьогодні відомо декілька моделей культур організацій. Найвідоміші з них: Константіноса та Де Грака. Модель Константіноса розглядає чотири організаційні парадигми:
- закрита - характеризується стабільністю, секретністю, незначною гнучкістю, низхідним процесом прийняття рішень, неінноваційністю, авторитарністю;
- відкрита - характеризується інноваційністю, співпрацею, переговорністю, адаптивністю, колективним ухваленням рішень, ви рішенням проблем;
- синхронна - характеризується гармонійністю, рівністю, ефективністю, консерватизмом у змінах, координативністю, непрактичністю керівництва;
- випадкова - характеризується незалежністю ініціатив, творчістю і винахідливістю, індивідуальністю, нестабільністю, автономністю, неформальністю.
Модель Де Грака розглядає дві організаційні парадигми, які називаються римським і грецьким шляхами розвитку організацій (табл. 2.1), Де Грак вказує, що римський шлях характерний для старих, крупних і консервативних організацій, а грецький - для нових, середніх і малих мобільних організацій (ательє).
Таблиця 2.1
Римський шиях Грецький шлях — використовують структурні методи; — використовують об'ектно-оріентовані методи; — застосовують більше формалізмів; — Застосовують менше формалізмів; —Створюють крупкі програми; - застосовують
CASE- інструменти; — створюють малі програми; — проекти повністю керовані; — застосовують окремі інструменти; — створюють максимум документації; — проекти частково керовані; — налаштовані управляти проектами — створюють мінімум документації; — налаштовані писати програми
Р. Гласс (R.Gluss) додає «варварську» культуру для найменш цивілізованих, малих програмних ательє, порівнюючи її з грецькою і римською культурами таким чином:
- греки організовують речі, римляни - людей, варвари організовують «що-небудь»;
- у греків методології неформальні, у римлян - формальні, у варварів - відсутні;
- греки пишуть програми, римляни управляють проектами, варвари «стрибають» кодуючи;
- греки мотивуються «підручною» проблемою, римляни - груповими цілями, варвари - героями;
- греки мінімізують документацію, римляни максимізують її, варвари гордяться її відсутністю;
- греки працюють у маленьких групах, римляни - у великих, варвари - поодинці;
- греки використовують речі як інструменти, римляни - людей, варвари взагалі не використовують інструментів;
- греки - демократи, римляни - імперіалісти, варвари - анархісти;
- греки - емпірично-індуктивні, римляни - аналітично-дедуктивні, варвари - емоційні;
- греки - інтуїтивні, римляни - логіки, варвари - імпульсні;
- греки надають увагу субстанції, римляни - формі, варвари - лініям коду;
- греки роблять речі, римляни планують речі, варвари руйнують речі.
Нині для оцінювання культури персоналу розроблено кодекс стики інженера програмного забезпечення, а для оцінювання рівня зрілості культури організацій використовується широко відома модель, розроблена в SEI. Capability Maturity Model (СММ) і її подаль ший розвиток СММ1 (Integrity).
2.2. Моделі зрілості процесів, що відбуваються на підприємстві
Процес програмного забезпечення - це фундаментальний компонент культури організації. Зрілість процесу програмного забезпечених визначається як ступінь, за якого можна стверджувати, що процес явно визначуваний, керований, вимірюваний, контрольований і ефективний.
На сьогодні відомо декілька моделей зрілості процесів, що відбуваються на підприємстві, що розробляє програмне забезпечення.
2.2.1. Моделі зрілості можливостей (СММ)До моделей СММ належать три: СММ - модель зрілості підприємств, Р-СММ - модель зрілості персоналу, СММ1 - інтегрована модель зрілості підприємств.
На рис. 2.2 показано три шкали, що описують зрілість організацій у виробництві якісного програмного забезпечення.
Автор шкали Метафора рівня Рівні Епохи - Анархія Фольклор Методологія Метрики ІІнженерія
Weinberg Шаблони Забутий Мінливий Рутинний Керований Передбачуваний Узгодженнй
Humphrey Рівні - Початковий Повторюваний Визначений Керований Опти-мізо-ваний
Рис. 2.2. Шкала зрілості
На шкалі Humphrey була побудована модель СММ. Вона була розроблена як механізм для вибору субпідрядників, що виконують проекти Міністерства оборони США. Зараз ця модель використовується для аналогічних цілей ряду компаній.
Модель СММ забезпечує засоби для оцінювання можливостей організації створювати якісне програмне забезпечення. Окрім цього модель надає рекомендації, які повинні бути реалізовані в організації, щоб підвищити її можливості для виробництва якісного програмного забезпечення.
На рис. 2.3 показано схему моделі, яка визначає п'ять рівнів зрілості організації: початковий, повторюваний, визначуваний, керований, оптимізований. Кожен рівень (окрім першого) має безліч процесів (ключові області), що асоціюються з ним. Ці процеси визначають цілі, які повинні бути досягнуті організацією, щоб її зрілість відповідала певному рівню. Кожна мета досягається конкретними діями процесу. Організація може не виконувати всіх дій процесу, але вона повинна продемонструвати, що всі цілі ключових областей досягнуті на даному і всіх попередніх рівнях. Пропуск рівнів, що знаходяться нижче в шкалі СММ, не допускається, оскільки області нижніх рівнів забезпечують цілі в галузях вищих рівнів,
Рис. 2.3. Модель CM SEI
Початковий рівень - зрілість організації ґрунтується на фольклорі та індивідуальних здібностях персоналу. Досвід передається тільки шляхом тренінгу, стандарти не враховуються; розмір, витрати й інші характеристики проекту не оцінюються. Успіх проекту залежить від менеджера і окремих програмістів («героїв»). Менеджер зазвичай не бачить, що відбувається всередині проекту, Характеристики цього рівня такі: хаос, недисциплінованість, непередбачуваність, анархія. 11а цьому рівні немає областей ключових процесів. Робота буде зроблена, коли вона буде зроблена.
