М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

- греки організовують речі, римляни - людей, варвари організовують «що-небудь»;

- у греків методології неформальні, у римлян - формальні, у варварів - відсутні;

- греки пишуть програми, римляни управляють проектами, варвари «стрибають» кодуючи;

- греки мотивуються «підручною» проблемою, римляни - груповими цілями, варвари - героями;

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

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

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

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

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

- греки - інтуїтивні, римляни - логіки, варвари - імпульсні;

- греки надають увагу субстанції, римляни - формі, варвари - лініям коду;

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

Нині для оцінювання культури персоналу розроблено кодекс стики інженера програмного забезпечення, а для оцінювання рівня зрілості культури організацій використовується широко відома модель, розроблена в SEI. Capability Maturity Model (СММ) і її подаль­ ший розвиток СММ1 (Integrity).

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

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

До моделей СММ належать три: СММ - модель зрілості підприємств, Р-СММ - модель зрілості персоналу, СММ1 -інтегрована модель зрілості підприємств.

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

Рис. 2.2. Шкала зрілості

На шкалі Humphrey була побудована модель СММ. Вона була розроблена як механізм для вибору субпідрядників, що виконують проекти Міністерства оборони США. Зараз ця модель використовується для аналогічних цілей ряду компаній.

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

На рис. 2.3 показано схему моделі, яка визначає п'ять рівнів зрілості організації: початковий, повторюваний, визначуваний, керований, оптимізований. Кожен рівень (окрім першого) має безліч процесів (ключові області), що асоціюються з ним. Ці процеси визначають цілі, які повинні бути досягнуті організацією, щоб її зрілість відповідала певному рівню. Кожна мета досягається конкретними діями процесу. Організація може не виконувати всіх дій про­цесу, але вона повинна продемонструвати, що всі цілі ключових областей досягнуті на даному і всіх попередніх рівнях. Пропуск рівнів, що знаходяться нижче в шкалі СММ, не допускається, оскіль­ки області нижніх рівнів забезпечують цілі в галузях вищих рівнів,

Рис. 2.3. Модель CM SEI

Початковий рівень - зрілість організації ґрунтується на фольк­лорі та індивідуальних здібностях персоналу. Досвід передається тільки шляхом тренінгу, стандарти не враховуються; розмір, витра­ти й інші характеристики проекту не оцінюються. Успіх проекту залежить від менеджера і окремих програмістів («героїв»). Менеджер зазвичай не бачить, що відбувається всередині проекту, Харак­теристики цього рівня такі: хаос, недисциплінованість, непередбачуваність, анархія. 11а цьому рівні немає областей ключових процесів. Робота буде зроблена, коли вона буде зроблена.

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

- управління вимогами - спрямовано так: на управління змінами у вимогах шляхом реалізації відповідних планів і дій;

- планування проекту - зорієнтовано на оцінювання і планування проекту;

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

- управління субпідрядниками - забезпечує керування і регулювання відносин з субпідрядниками;

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

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

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

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

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

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

- управління інтеграцією - організація забезпечує вибір і налаштування процесів для конкретного проекту зі стандартного процесу;