Методичні вказівки до виконання самостійних робіт з дисципліни: «проектний практикум»



Сторінка5/5
Дата конвертації16.03.2017
Розмір3.38 Mb.
ТипМетодичні вказівки
1   2   3   4   5

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


Початок:
Цілі:

1. Зрозуміти межі проекту.

2. Розробити економічне обгрунтування.

3. Домогтися угоди між зацікавленими сторонами для подальшого просування проекту.


Віха: LCO (LifeCycle Objective) віха життєвого циклу.
Проектування:
Цілі:

1. Звести до мінімуму головні технічні ризики.

2. Створити базову архітектуру.

3. Зрозуміти у скільки обійдеться побудова системи.



Віха: LCA (LifeCycle Architecture) віха архітектури життєвого циклу.
Побудова:
Мета - Побудова першої версії продукту.

Віха: IOC (Initial Operational Capacity) віха початкової функціональної

готовності.
Впровадження:
Мета - Створення остаточної версії продукту і відправлення замовнику.

Віха: PR (Production Release) віха готового продукту.

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




4. Статична структура RUP. Роді. Завдання. Артефакти. Процеси, Робочі процеси.
Статична структура - опис логічного групування елементів процесу (завдання, роль, артефакти) у головні дисципліни процесу.

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

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

1. Кроки для роздумів (визначення суті завдання, формулювання результату).

2. Виконувані кроки (створення та модифікація деяких артефактів).

3. Перевірочні кроки (оцінка результату за певним критерієм).

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

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

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

1. Опис ролі ( «хто робить?")

2. Опис артефакту ( «що робить?)

3. Опис робочого процесу ( «коли робить?")

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

Дисципліна - Високорівневий робочий процес. Дисципліна розділяється на деталі робочого процесу - робочі процеси всередині дисципліни.

Дисципліни:

1. Бізнес-моделювання - призначена для:

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

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

• Для визначення деяких системних вимог.

2. Управління вимогами - призначена для:

• Визначення функцій системи між усіма зацікавленими особами (користувачами, розробниками, замовниками);

• Визначення меж системи;

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

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

3. Аналіз і проектування - призначена для:

• Побудови дизайну системи на підставі вимог до системи;

• Розробки архітектури системи;

• Підготовки дизайну впровадження системи.

4. Реалізація - призначена для:

• Визначення структури та організації вихідних кодів системи, розбитих на окремі рівні реалізації;

• Для реалізації класів і об'єктів в термінах компонентів (вихідні двійкові і виконавчі файли);

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

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

5. Впровадження - призначена для:

• Для опису всіх дій, пов'язаних з доступністю кінцевого продукту для користувачів.

6. Тестування - призначена для:

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

• Пошук і реєстрація дефектів;

• Демонстрація достовірності зроблених на етапі проектування та збору вимог припущень (архітектурних рішень).

7. Управління проектом - призначена для:

• Забезпечення розробки інструкцій з планування, підбору персоналу, виконання, і контролю проектів (моніторингу прогресу ітеративного проекту та метрик);

• Забезпечення управління ризиками.

8. Управління змінами - призначена для:

• Контролю змін;

• Підтримання цілісності продукту і складових його артефактів.

Додаткові елементи процесу:

1. Інструкції - правила, рекомендації для виконання завдань, кроків і поводження з артефактами.

2. Шаблони - для різних артефактів.

3. Інструкції з використання інструментальних засобів розробки.

4. Основні концепції, визначення та принципи (Concepts).

5. Roadmaps - графічні діаграми.
6. RUP як технологічний продукт». "Дух" RUP.
RUP - технологічний продукт, що надає настроювану технологічну основу для програмної інженерії.
RUP пропонує повну технологічну базу, що складається з:

1. Практичні методи у формі фаз, ролей, завдань, артефактів і робочих процесів.

2. Розвинена система допомоги.

3. Засоби конфігурування.

4. Засоби створення власних процесів.

5. Спільноти користувачів.

Фундаментальні принципи, що відображають суть «духу RUP»:

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

2. Забезпечте виконання вимог замовників (реалізується за допомогою документування вимог зрозумілою мовою для замовників та ітеративною розробкою).

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

4. Пристосовуйтесь до змін від самого початку (Вартість змін підвищується в міру розробки проекту. Рішення - використання засобів контролю за версіями з самого початку проекту).

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

6. Будуйте систему з компонентів (Це дозволить зробити систему більш стійкою до змін, повторно використовувати компоненти і знизити вартість обслуговування системи).

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

8. Зробіть якість способом життя, а не ідеєю, що запізнилася (Реалізується за допомогою використання раннього тестування та автоматизації тестів, використання концепції «Якість від дизайну»).
7. Бізнес-Моделювання Концепції.
Бізнес-Моделювання:

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

Цілі:

1. Розуміння структури та динаміки організації, в якій система буде розгорнута.



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

3. Гарантування загального розуміння організації клієнтами, кінцевими користувачами, і розробниками.

4. Отримання вимог системи необхідних для підтримки організації.

Концепції:

1. Облік витрат за видами діяльності (вимірювання вартості та продуктивності дій, ресурсів та об'єктів витрат).

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

3. Бізнес-моделі (узагальнені рішення, здійснені й застосовані в контексті проблеми, що усувають притаманні проблеми).

4. Розвиток електронної комерції (використання технології на основі моделі для швидкого і керованого розвитку)

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

6. Масштабування бізнес-моделювання (застосування бізнес-моделювання повинне мати різні можливості залежно від контексту і потреб).


8. Управління вимогами. Концепції. Управління вимогами:
Розуміння визначення і можливостей проблеми, яку ми намагаємося вирішити даною системою.

Цілі:


1. Встановлення та підтримка угоди з клієнтами та іншими зацікавленими особами про діяльність системи.

2. Забезпечення розробників системи кращим розумінням вимог системи.

3. Визначення меж системи.

4. Забезпечення основи планування технічного утримування ітерацій.

5. Забезпечення основи для оцінки вартості і часу для розробки системи.

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

Концепції:

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

2. Вимоги (умови або можливості, яким система повинна відповідати).

3. Трасування (можливість простежити проектний елемент по відношенню до інших проектних елементів, особливо пов'язаного з вимогами).

4. Види вимог (різні рівні абстракцій і цілей наших вимог).

5. Огляд прецедентів використання (Архітектурне подання для забезпечення підстав для планування технічного змісту ітерацій).

6. Користувацько-центроване проектування (визначення користувачів і залучення їх до проекту).
9. Аналіз і проектування. Концепції.
Аналіз і проектування:

Цілі:


1. Перетворення вимог в проект майбутньої системи;

2. Розвиток зрозумілої архітектури для системи;

3. Адаптація проекту до вибраного оточення реалізації.

Концепції:

1. Механізми аналізу (зразок, що становить спільне рішення загальної проблеми)

2. Паралелізм (прагнення до походження об'єктів в певний час у системі)

3. Огляд впровадження (архітектурне уявлення, що забезпечує засади розуміння фізичного розподілу системи паралельно набору обробки вузлів)

4. Механізми проектування та реалізації (МП - обробка відповідного МР, МР - обробка відповідного МП)

5. Модель розподілу (опис архітектури системи)

6. Події і сигнали (моделювання появи взаємодії, яка може викликати перехід з одного стану в інший)

7. Ієрархічне подання (Представлення впорядкованих груп функціонального»

8. Логічний огляд (архітектурне уявлення, що забезпечує засади розуміння: структури та організації проекту системи)

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

10. Представлення графічного інтерфейсу користувача

11. Представлення інтерфейсу до зовнішніх систем

12. Архітектура ГО (концепція найвищого рівня системи в її навколишньому середовищі)

13. Проектування "тестування наперед"

14. Моделі веб-архітектури.


10. Реалізація. Концепції.
Цілі:

1. Визначення структури та організації вихідних кодів системи, розбитих на окремі рівні реалізації.

2. Для реалізації класів і об'єктів в термінах компонентів (вихідні двійкові і виконавчі файли).

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

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

Концепції:

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

2. Тестування розробника (Розподіл тестування за категоріями діяльності).

3. Робочий простір розробки та інтеграції (Створення просторів для розробників, що діють разом і паралельно).

4. Огляд реалізації (Охоплення архітектурних рішень зроблених для реалізації).

5. Відображення проектування в код.

6. Інтеграція ПО (Об'єднання окремих компонентів в єдине ціле).


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

Ціль 1: Зрозуміти, що створювати.

1. Узгодити високорівневу Концепцію, що включає в себе:

• Можливості та переваги проекту;

• Проблеми, які вирішуються проектом;

• Хто є кінцевим користувачем;

• Що буде робити продукт на найвищому рівні (вираження у формі високорівневих властивостей або огляду ключових use case-ів);

• Деякі. Найбільш сцттєві нефункціональні вимоги: ОС, БД, надійність, масштабованість, якість і т.д.



2. Створити широке, але неглибокий опис системи:

• Визначити та коротко описати акторів (типові користувачі, інші системи, з якими взаємодіє проект);

• Визначити та коротко описати use case-и (які актори будуть взаємодіяти з системою).

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

• Функціональність є ключовою для програми або використовується ключові інтерфейси системи. Архітектор визначає такі use case-и шляхом аналізу стратегії резервування управління, ризиків, стратегій безпеки даних;

• Функціональність обов'язково повинна бути реалізована (вона визначає суть системи);

• Функціональність охоплює область архітектури, яка не охоплюється жодним критичним use case-ом.

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

• Які інші подібні системи створювали і які технології та архітектуру використовували? Яка була вартість?

•  Існуюча архітектура наявної системи є задовільною чи її треба розвивати?

•  Які технології будемо використовувати, чи є, ризики пов'язані з цим?

• Які програмні компоненти потрібні, чи можна їх придбати, чи можна їх буде використовувати в іншому проекті, вартість, ризики?

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

Ціль 5: Вирішити якого процесу дотримуватися і які use-case-и використовувати. Обов'язково слід спростити процес, щоб мінімізувати непотрібні накладні витрати.

Ітерації:

Як правило одна, але може знадобитися і більше за умов

• Якщо проект великий і команді важко зрозуміти межі системи;

• Система не має аналогів.

Якщо ітерацій більше однієї, то перша концентрується на цілях 1-3 (що створювати?), а решта на 4-5 (як створювати?).
12. Фаза Початок: Віха цілей життєвого циклу. Стани основних артефактів.
Рецензія для даної віхи включас оцінку наступних моментів:

згода зацікавлених сторін:

1. В питаннях оцінки меж проекту та первісної оцінки його термінів розробки \ вартості.

2. В тому, що зафіксовано вірний набір вимог.

3. В тому, що термін, вартість, пріоритети, ризики і процес розробки прийнятні.

4. В тому, що первісні ризики виявлені та існує стратегія боротьби з кожним з них.

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

Артефакти:

1. Концепція (Vision) - задокументовані основні вимоги, функції та головні обмеження.

2. Економічне обгрунтування (Business Case) - визначено і узгоджено.

3. Список ризиків (Risk List) - виявлені первинні ризики.

4. План Розробки ПЗ (SDP) - визначені цілі та тривалості початкових етапів розробки. Запропоновано вимоги до основних ресурсів.

5. Словник (Glossary). Визначено основні терміни.

6. Модель варіантів використання (Use-case Model) - визначено основні дійові особи і use-case-и. Докладний опис та послідовність дій тільки для критичних use-case-іn.


13. Фаза Проектування: цілі та ітерації.
Ціль - вибір і створення основи архітектури системи, яка повинна забезпечити стабільний фундамент для основної маси робіт з проектування та реалізації у Фазі Проектування.

Ціль 1: Більш глибоко зрозуміти вимоги:

1. Описати більшість use-case-ів.

2. Створити прототип для користувача інтерфейсу для головних use case-ів, щоб продемонструвати реалізовані use case-ами функції.

3. Оновлення глосарію.

Ціль 2: Спроектувати, реалізувати та провірити базову архітектуру:

1. Вибрати найбільш важливі блоки системи і їх інтерфейси (їх необхідно створити, купити чи можна використовувати повторно).

2. Описати взаємодію блоків.

3. Реалізувати і протестувати прототип архітектури, перевірити, чи зняті головні технологічні ризики, перевірити продуктивність, масштабованість, вартість.

а. Спроектувати критичні архітектурно-значущі use case-u, найбільш, складні і ризиковані і ті, які утворюються до ще не охоплених частин системи.

б. При цьому реалізувати потрібно 1-2 сценарія use case-ів. Реалізувати потрібно стільки прецедентів, скільки необхідно для зменшення пов'язаних з ними ризиків.

в. Об'єднати готові класи в пакети з метою локалізації зміни у відповідності з шарами і конфігуруванням продукту.

м. Необхідно забезпечити архітектурне охоплення:

• Спроектувати БД.

• Описати архітектуру часу (процеси, потоки і т.д.).

• Визначити архітектурні механізми (типові вирішення проблем, які часто зустрічаються).

• Реалізувати критичні сценарії і протестувати (в області продуктивності та навантаження).

• Інтегрувати компоненти.

Ціль 3: Знизити існуючі ризики і дати більш точну оцінку термінів розробки і вартості.

Ціль 4: Уточнити прецедент розробки і встановити середовище розробки. Прецедент розробки - конкретний процес, який використовується в роботі організації - настройка KUJP під вимоги проекту.

Для цього:

1. Вибір і установка інструментів і засобів.

2. Підготовка апаратного забезпечення.

3. Поставити базу під контроль конфігурацій.

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

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

2. Визначте, реалізуйте і протестуйте невеликий початковий набір архітектупних механізмів.

3. Виконайте попередній логічний дизайн БД.

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

5. Тестуйте стільки, скільки потрібно, щоб підтвердити зменшення архітектурних ризиків.



2 ітерація:

1. Виправити все, що було не в порядку в 1 ітерації.

2. Спроектувати, реалізувати, протестувати важливі з архітектурної точки зору сценарії,які залишилися.

3. Опрацювати і реалізувати паралельне виконання, процеси, потоки і фізичний розподіл.

4. Визначте, реалізуйте і протестуйте архітектурні механізми, що залишилися.

5. Створіть і реалізуйте чорнову версію БД,



6. Докладно розпишіть другу половину use case-ів цієї фази.

7. Протестуйте, оцініть і вдоскональте архітектуру так, щоб вона виступила в ролі основи, тобто стабільного базису,


14. Фаза Проектування: Віха архітектури життєвого циклу. Стани основних артефактів.
Віха архітектури життєвого циклу. Оцінка:

1. Чи є концепція і вимоги проекту стабільними?

2. Чи є стабільною архітектура?

3. Чи перевірено основні підходи, які будуть використовуватися при тестуванні й оцінці системи?

4. Чи показало тестування виконуваної архітектури, що боротьба з основними ризиками призвела до їх усунення?

5. Чи є плани на Побудову достатньо детальними?

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

7. Чи прийнятна різниця запланованих і поточних витрат?



Артефакти:

1. Створено один або більше прототипів для дослідження критичних функціональностей.

2. Список ризиків (Risk List) - оновлено, додано ризики, пов'язані з архітектурою.

3. Development Case - повністю визначене оточення для фази побудови.

4. Інструменти (Tools) - все ПЗ для розробки встановлено.

5. Архітектура ПЗ (Software Architecture Document) - створена базова версія для значущих use-case-ів.

6. Модель проектованої системи (Design Model) та Модель даних (Data Model) - створені базові версії.

7. Концепція (Vision) - уточнено з використанням нової інформації,

8. План розробки ПЗ (SDP) - уточнено з використанням майбутніх фаз побудови та впровадження

9. Словник (Glossary) - визначено основні терміни

10. Модель варіантів використання (Use Case Model) - готова на 80%

11. Набір тестів (Test Suite), Архітектура Автоматичного Тестування (Test Automation Architecture) - побудовані базові версії для перевірки кожного використовуваного випуску (build) або прототипу.
15. Фаза Побудова: цілі та ітерації.
Фаза Побудови - це економічно ефективна розробка кінцевого продукту, тобто працездатної версії системи, яка може бути представлена користувачам.

Цілі:


Ціль 1: Зниження вартості і та встановлення паралелізму в роботі команд розробників.

1. Організація навколо архітектури:

2. Управління версіями:

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

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

• необхідність приховати зміни, внесені однією командою від іншої;

• управління доступом до змін;

Планування ітерації:

3. Зміцнення архітектури:

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

• гарантія того, що інтереси не будуть довільно мінятися

4. Безперервний прогрес:

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

• чіткі, досяжні цілі;

• постійні демонстрації та тестування коду;

• безперервна інтеграція.

Ціль 2: Розробити ітеративним методом остаточний продукт, готовий для представлення користувачу.

1. Описати прецеденти використання, що залишилися та інші вимоги.

2. Завершити проектування.

3. Спроектувати БД - невелике доопрацювання чорновий структури.

4. Реалізувати код і провести модульне тестування,

5. Провести інтеграцію та системне тестування.

6. Раннє впровадження ї зворотній зв'язок.

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

8. Підготовка до остаточного впровадження:

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

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

• підготовка до запуску (упаковка, маркетинг).



Ітерації

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



Технологія KANBAN

Я збираюся написати кілька статей про нову методологію гнучкої розробки Канбан (Kanban Development) з метою підготовки до Scandinavian Agile Conference 2009, де я буду робити одна з доповідей (до речі, заодно запрошую всіх на конференцію).

Сьогодні публікую першу зі статей.

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

Також я хотів би зібрати якомога більше питань і сумнівів в коментарях, щоб відповісти на них в наступних статтях, так що пишіть все, що вам незрозуміло, або що ще ви хотіли б дізнатися про Канбан.

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

Для початку напишу про походження терміна Канбан.

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

Термін Канбан має дослівний переклад: "Кан" означає видимий, візуальний, і "бан" означає картка або дошка.

На заводах Тойота картки Канбан використовуються повсюдно для того, щоб не захаращувати склади і робочі місця заздалегідь створеними запчастинами. Наприклад, уявіть, що ви ставите двері на Тойоти Королли. У вас біля робочого місця знаходиться пачка з 10 дверей. Ви їх ставите одну за одною на нові машини і, коли в пачці залишається 5 дверей, то ви знаєте, що пора замовити нові двері. Ви берете картку Канбан, пишете на ній замовлення на 10 дверей і відносите її тому, хто робить двері. Ви знаєте, що він їх зробить як раз до того моменту, як у вас закінчаться залишилися 5 дверей. І саме так і відбувається - коли ви ставите останні двері, прибуває пачка з 10 нових дверей. І так постійно - ви замовляєте нові двері тільки тоді, коли вони вам потрібні.

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

Основне завдання карт Канбан в цій системі - це зменшувати кількість «виконується в даний момент роботи» (work in progress).

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

Цей метод Бережливого виробництва (Lean manufacturing) був придуманий в Тойоті і зараз багато виробничі компанії по всьому світу його впроваджують або вже впровадили.

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

А що ж таке Канбан розробка стосовно ПО, і чим вона відрізняється від інших гнучких методологій, буть то SCRUM або XP?

По-перше, потрібно відразу зрозуміти, що Канбан - це не конкретний процес, а система цінностей. Як, втім, і SCRUM з XP. Це означає, що ніхто вам не скаже що і як робити по кроках.

По-друге, весь Канбан можна описати однією простою фразою - «Зменшення виконується в даний момент роботи (work in progress)».

По-третє, Канбан - це навіть ще більш «гнучка» методологія, ніж SCRUM і XP. Це означає, що вона не підійде всім командам і для всіх проектів. І це також означає, що команда повинна бути ще більш готовою до гнучкої роботі, ніж навіть команди, що використовують SCRUM і XP.

Різниця між Канбан і SCRUM:

- У Канбан немає таймбоксов ні на що (ні на завдання, ні на спринти)

- У Канбан завдання більше і їх менше

- У Канбан оцінки термінів на задачу опціональні або взагалі їх немає

- У Канбан «швидкість роботи команди» відсутня і вважається тільки середній час на повну реалізацію завдання

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

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

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

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

Наприклад, загальновідома проблема SCRUM - це великі витрати від обговорень, зустрічей і великі втрати часу на стиках спринтів (коли як мінімум день йде на закриття одного спринту, а потім день на відкриття нового. І якщо спринт - 2 тижні, то 2 дні з 2 тижнів - це 20%, чертовски багато). У підсумку мало не 30-40% часу при застосуванні SCRUM витрачається на підтримання самого процесу - На щоденні мітинги, на 5% workshop, на спринт ретроспектив і т.п. 30%!

Канбан розробка відрізняється від SCRUM в першу чергу орієнтацією на завдання. Якщо в SCRUM основна орієнтація команди - це успішне виконання спринтів (треба визнати, що це так), то в Канбан на першому місці завдання.

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

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

Команда для роботи використовує Канбан-дошку. Наприклад, вона може виглядати так (взяв тут):

Стовпці зліва направо:

Цілі проекту:

Необов'язковий, але корисний стовпець. Сюди можна помістити високорівневі цілі проекту, щоб команда їх бачила і все про них знали. Наприклад, «Збільшити швидкість роботи на 20%» або «Додати підтримку Windows 7».

Черга завдань:

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

Опрацювання дизайну:

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

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

Розробка:

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

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

Тестування:

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

Деплоймент:

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

Закінчено:

Сюди стікер потрапляє тільки тоді, коли всі роботи по завданню закінчені повністю.

У будь-якій роботі трапляються термінові завдання. Заплановані чи ні, але такі, які треба зробити прямо зараз. Для таких можна виділити спеціальне місце (на картинці відзначено, як «Expedite»). У Expedite можна помістити одну строкову завдання і команда повинна почати її виконувати негайно і завершити якомога швидше. Але може бути тільки одна така задача! Якщо з'являється ще одна - вона повинна бути додана в «Черга завдань».

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

Наприклад, якщо ви маєте 8 програмістів в команді, то в рядок «Розробка» ви можете помістити цифру 4. Це означає, що одночасно програмісти будуть робити не більше 4-х завдань, а значить у них буде багато причин для спілкування та обміну досвідом. Якщо ви поставите туди цифру 2, то 8 програмістів, займаються двома завданнями, можуть занудьгувати або втрачати занадто багато часу на обговореннях. Якщо поставити 8, то кожен буде займатися своїм завданням і деякі завдання будуть затримуватися на дошці надовго, а адже головне завдання Канбан - це зменшення часу проходження завдання від початку до стадії готовності.

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

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

Хороша перевірка для ММФ - це питання собі «А став би я писати про цю фічу в блозі компанії?». Якщо ні - це не ММФ.

Що нового і корисного дає така дошка з лімітами?

По-перше, зменшення числа паралельно виконуваних завдань сильно зменшує час виконання кожної окремої задачі. Немає потреби перемикати контекст між завданнями, відстежувати різні сутності, планувати їх і т.д. - Робиться тільки те, що потрібно. Немає потреби влаштовувати спринт планінги та 5% воркшопи, т.к. планування вже зроблено в стовпці «чергу завдань», а детальне опрацювання завдання починається ТІЛЬКИ тоді, коли задача починає виконуватися.

По-друге, відразу видно затики. Наприклад, якщо тестери не справляються з тестуванням, то вони дуже скоро заповнять весь свій стовпець і програмісти, закінчивши нове завдання, вже не зможуть перемістити її в стовпець тестування, тому що він заповнений. Що робити? Тут час згадати, що «ми - команда» і вирішити цю проблему. Наприклад, програмісти можуть допомогти тестерам завершити одну із завдань тестування і тільки тоді пересунути нове завдання на звільнилося. Це дозволить виконати обидва завдання швидше.

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

Весь Канбан можна описати всього трьома основними правилами:

1. Візуалізуйте виробництво

- Розділіть роботу на завдання, кожне завдання напишіть на картці і помістіть на стіну або дошку.

- Використовуйте названі стовпці, щоб показати положення завдання у виробництві.

2. Обмежуйте WIP (work in progress або роботу, виконувану одночасно) на кожному етапі виробництва.

3. Вимірюйте час циклу (середній час на виконання одного завдання) і оптимізуйте постійно процес, щоб зменшити цей час.

Всього 3 правила!

Наприклад, в SCRUM - 9 базових правил. У XP - 13, а в класичному RUP - аж понад 120. Відчуйте різницю.

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

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

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

Канбан представляє собою, ручний метод планування, що забезпечує на кожній виробничій ділянці випуск рівно стільки комплектуючих виробів, скільки потрібно на наступній стадії виробництва. Відновлення виробництва відбувається лише тоді, коли на наступних технологічних операціях готівковий запас деталей і вузлів закінчується. Канбан можна визначити як стимулятор попиту або як витягають систему планування на відміну від підштовхує, якими є, наприклад, системи МRР і МАР. При Канбан основним спонукує суб'єктом є той, хто використовує кінцевий продукт, а початок всьому визначає кінцевий випуск, під який підлаштовуються все попередні етапи виробництва. При використанні систем МRР і МАР цим суб'єктом є виробничий відділ, який на основі прогнозованого попиту на кінцеву продукцію розробляє календарні плани для кожного з виробничих дільниць. Якщо при системах МRР і МАР планування потреби в матеріалах на кожному етапі виробництва здійснюється від першого до останнього етапу, то при Канбан має місце зворотний порядок. Інформація йде від кінцевої точки безпосереднього виробництва до попереднього ділянці роботи. Таким чином, кожен крок виробництва ретельно узгоджується і постачання матеріалів, деталей і вузлів від одного виконавця до іншого здійснюється в потрібний час. Усунення буферних складів і посилення по парних зв'язків наступних один за одним виконавців збільшують стабільність виробничого процесу.

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

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

При системі Канбан час зміни інструменту і налагодження устаткування повинно бути зведене до мінімуму. Без чітко налагодженої системи зміни інструменту не може бути й мови про впровадження Канбан.

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

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

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

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

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

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

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

Канбан дозволяє без використання будь-яких глибоких теоретичних підходів або математичних методів контролювати динаміку трьох сфер діяльності: закупівля - виробництво - продаж. Короткий інтервал оперативного управління дає можливість здійснювати ефективний контроль за виконанням місячного плану, дотриманням раціональних пропорцій між виробництвом, постачанням та запасами та ін Канбан вимагає оптимальної комунікації між усіма учасниками виробничого процесу. З цією метою використовується спеціальна мнемотехніческіе символіка, що ідентифікує різні виробничі визначення, характеристики й умови.
РЕКОМЕНДОВАНА ЛІТЕРАТУРА:

1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.

2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.

3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.

4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.

5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем

6. ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом
Змістовий модуль 4. Процеси управління якістю програмного забезпечення
Модель CMMI

Модель Технологічної Зрілості (Capability Maturity Model Integrated, CMMI) описує шкалу з п'яти рівнів зрілості, заснованих на тому, наскільки послідовна компанія або організація в проходженні загальним повторюваним процесам при виконаємо своєї роботи. Нижній рівень шкали описує компанії без повторюваних процесів, де більша частина роботи хаотична і сумбурна. Верхній рівень описує компанії, які використовують певні і повторювані процеси, збирають метрики для безперервного поліпшення своїх процесів, а також на регулярній основі шукають творчі методи, що дозволяють працювати краще.

Перша версія моделі CMM розроблялася з 1984 по 1987 рік Уотс Хамфрі (Watts Humphrey) та Інститутом Програмної Інженерії (Software Engineering Institute, SEI). SEI є підрозділом Університету Карнегі-Меллона (Піттсбург, США). Робота спонсорувалася і продовжує спонсоруватиметься Міністерством Оборони США, яке шукало можливості порівнювати і оцінювати численних підрядників, які виконували роботи (в першу чергу, розробку програмного забезпечення) за гроші оборонного бюджету.

У наступні роки було розроблено кілька різних моделей CMM, які в 200 році були об'єднані в одну інтегровану модель CMMI ("I" якраз і означає "Integrated"). Хоча SEI продовжує покращувати і розширювати зміст, а також спектр додатків різних моделей технологічної зрілості, основним орієнтиром для більшості компаній як і раніше залишається CMMI.




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

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

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

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

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

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

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

Ви можете використовувати модель CMMI в якості керівництва при впровадженні загальних процесів. При цьому не розраховуйте почати з рівня 1 і протягом року "сплигнути" на рівень 5. Шкала CMMI - це подорож. Більшість компаній тільки збираються почати рух до рівня 2. Проте, навіть такий короткий стрибок не є безболісним. У багатьох відносинах, впровадження загальних процесів управління проектами - найбільш складна частина шляху. Багато організації саме на цьому етапі сходять з дистанції через небажання частини персоналу слідувати загальним процесам. Якщо ж Ви змогли досягти рівня 2, то свідомість організації змінюється настільки, що перехід до рівня 3 дається значно легше.

Узагальнюючи, можна підсумувати, що багато компаній бачать реальну цінність для бізнесу, одержувану від якісних багаторазово використовуваних по всій організації процесів. Модель Технологічної Зрілості надає підхід, в рамках якого компанії можуть виміряти себе за стандартною шкалою від 1 до 5. Більшість компаній сьогодні знаходяться на рівні 1 і хотіли б досягти рівня 2. Більшість керівників і більшість організацій усвідомлюють, що їм слід було б мати загальні повторювані процеси. Однак, на шляху перетворень завжди стоїть хворобливість. Вона пов'язана з будь-якою спробою зміни культури в організації, коли людей просять змінити порядок, в якому вони виконують свою роботу. Тим не менш, ця болючість коштує тих значних вигод, яких Ваша компанія досягає, якщо їй вистачає сил залишатися зосередженою на перервах до тих пір, поки культурні зміни не набудуть чинності.

«Модель зрілості ОУП» встановлює вісім рівнів досконалості застосування процесів управління проектами, встановленими РМI в керівництві РМВОК *. При використанні даної моделі ОУП повинен відібрати десять найважливіших стратегічних проектів, завершених організацією протягом останніх 12 місяців. У їх число не повинні включатися перервані проекроекти. Кожен проект має бути проаналізований на відповідність вимогам, пред'явленим до нього з усіх аспектів управління, наведеними в додатку А, з метою оцінки якості його виконання.

Темпи виконання проектів також оцінюються, на основі трьох рівневого підходу до швидкості виконання - високий, середній і низький. Якщо проект реалізований за час, на 5 і більше відсотків менша встановленого графікою, то швидкість виконання такого проекту вважають високою. Якщо ж тривалість проекту виявилася більш, ніж на 5% вище планової, то швидкість його виконання вважають низькою. Коли відхилення тривалості виконання проекту від планового знаходиться в межах ± 5%, то темпи виконання такого проекту вважають середніми.

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

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

Якщо оцінки рівня зрілості по п'яти і більше аспектам управління всіма проектами виявляються нижче «середнього», то це означає, що рівень зрілості ОУП, що знаходиться на рівні II моделі, також повинен бути визнаний нижче середнього. Для ОУП, що досяг рівня VI і вище, рівні зрілості з усіх аспектів управління повинні бути не нижче «високого». В іншому випадку, рівень зрілості такого ОУП не може бути визнаний високим. Точно також, для ОУП, що досягли рівня IV і V, оцінки рівнів зрілості за всіма дев'яти аспектам управління проектами повинні бути не нижче «середнього».

Порівнянність оцінок рівнів зрілості ОУП, що проводяться щорічно, залежить від стійкості застосовуваних критеріїв для оцінки окремих аспектів управління проектами, встановлених РМВОК *, які, як очікується, не повинні часто змінюватися.

запропонованого підхід до оцінки зрілості ОУП є простим і легким для застосування. Такі оцінки повинні проводитися регулярно, з періодичністю від 12 до 18 місяців, бажано, із залученням зовнішніх аудиторів. Доцільно, щоб ОУП доводив інформацію про результати оцінки до всіх керівників і виконавців проектів з тим, щоб вони краще розуміли необхідні і достатні умови для виконання вимог до вихідних результатами проектів.

ОПИС МОДЕЛІ ЗРІЛОСТІ ОУП

РІВЕНЬ I - ВИЗНАЧЕННЯ ЦІЛЕЙ І ЗАВДАНЬ ОУП

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

ЯК ПЕРЕЙТИ НА РІВЕНЬ II

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

РІВЕНЬ II - ОУП ОРГАНІЗОВАНИЙ

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

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

ЯК ПЕРЕЙТИ НА НАСТУПНИЙ РІВЕНЬ

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

РІВЕНЬ III - шляхів ефективнішого ВИКОНАННЯ ПРОЕКТІВ

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

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

ЯК ПЕРЕЙТИ НА НАСТУПНИЙ РІВЕНЬ

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

РІВЕНЬ IV-управління портфелем

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

РІВЕНЬ V - завоювати визнання КЕРІВНИКІВ І ВИКОНАВЦІВ ПРОЕКТІВ

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

РІВЕНЬ VI - ОУП ДОМІГСЯ ДОТРИМАННЯ ГРАФІКІВ ПРОЕКТІВ УСІМА ВИКОНАВЦЯМИ


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

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

РІВЕНЬ VII - ЗАБЕЗПЕЧЕНА ув'язці РОЗПОДІЛУ ВИКОНАВЦІВ З ВМІСТОМ ПОРТФЕЛЯ ПРОЕКТІВ, ОРГАНІЗАЦІЯ МАЄ МОЖЛИВІСТЬ ВИКОНУВАТИ ЗА РІК БІЛЬШЕ; ЧИСЛО ПРОЕКТІВ

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

РІВЕНЬ VIII - повне охоплення ОРГАНІЗАЦІЇ ПОСЛУГАМИ ОУП

При даному рівні зрілості для ОУП настає час «безтурботного існування». До цього моменту ніхто не ставить під сумнів корисність офісу як для організації в цілому, так і для кожного її співробітника. Організації, в яких існують настільки зрілі ОУП, відрізняють наступні спільні риси. Організація досягає всіх цілей, поставлених на черговий фінансовий рік. Більше 95% проектів завершується, як мінімум, своєчасно, а приблизно 10% з них - з випередженням термінів. Інтенсивність використання всіх ресурсів стабільна, продуктивність праці виконавців виросла. Організація здатна виконувати більше число проектів без залучення додаткових ресурсів. Всім зацікавленим сторонам відомо, наскільки співвідносяться один з одним цілі організації, проекти, ресурси і активи, і вони згодні з такими співвідношеннями. Рада з управління проектами активно перерозподіляє кошти, що опинилися зайвими в бюджетах окремих проектів. Постачальники і підрядчики в частині управління проектами нічим не відрізняються від самої організації.

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

Стандарт SPICE

У 1991 році Міжнародна організація по стандартизації ініціювала роботу зі створення єдиного стандарту оцінки програмних процесів. Стандарт отримав ім'я SPICE (скорочення від Software Process Improvement and Capability dEtermination - визначення можливостей і поліпшення процесу створення програмного забезпечення). Офіційно стандарт називається «ISO / IEC 15504: Information Technology - Software Process Assessment» і на даний момент існує в якості робочої версії, останній випуск який відбувся у травні 1998 року.

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

Отже, стандарт SPICE успадкував багато рис більш ранніх стандартів, в тому числі і вже згадуваних ISO 9001 і СММ. Для цього довелося вдатися до підвищення рівня деталізації стандарту. Наслідком такого грунтовного підходу є великий обсяг стандарту: документація до нього містить близько 500 сторінок!



Найбільше SPICE нагадує СММ. Точно так само, як і в СММ, основним завданням організації є постійне поліпшення процесу розробки ПЗ. Крім того, в SPICE теж використовується схема з різними рівнями можливостей (в SPICE визначено 6 різних рівнів), але ці рівні застосовуються не тільки до організації в цілому, а й до окремо взятих процесам. У табл. 1 наведені список рівнів здібностей моделі SPICE і характерні для них процедури управління. Відзначимо, що на даний момент не існує російського перекладу стандарту SPICE, тому використані терміни не є загальноприйнятими або офіційно зареєстрованими.

Отже, стандарт SPICE успадкував багато рис більш ранніх стандартів, в тому числі і вже згадуваних ISO 9001 і СММ. Для цього довелося вдатися до підвищення рівня деталізації стандарту. Наслідком такого грунтовного підходу є великий обсяг стандарту: документація до нього містить близько 500 сторінок!

Найбільше SPICE нагадує СММ. Точно так само, як і в СММ, основним завданням організації є постійне поліпшення процесу розробки ПЗ. Крім того, в SPICE теж використовується схема з різними рівнями можливостей (в SPICE визначено 6 різних рівнів), але ці рівні застосовуються не тільки до організації в цілому, а й до окремо взятих процесам. У табл. 1 наведені список рівнів здібностей моделі SPICE і характерні для них процедури управління. Відзначимо, що на даний момент не існує російського перекладу стандарту SPICE, тому використані терміни не є загальноприйнятими або офіційно зареєстрованими.

Рівні Назва

Рівень 0 Процес не виконується

Рівень 1 Що Здійснюється процес

1.1 Вимірювання продуктивності процесу

Рівень 2 Керований процес

2.1 Управління продуктивністю

2.2 Управління виробництвом товарів

Рівень 3 Встановлений процес

3.1 Документування процесу

3.2 Відстеження ресурсів процесу

Рівень 4 Передбачуваний процес

4.1 Вимірювання процесу

4.2 Управління процесом

Рівень 5 Оптимізуючий процес

5.1 Зміна процесу

5.2 Постійне вдосконалення

Таким чином, процеси в моделі SPICE можуть бути представлені таким чином (рис. 3).



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



Під час оцінки та покращення якості процесів виконуються наступні завдання (рис. 4):

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

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

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

Скажемо кілька рядків про структуру документації по стандарту SPICE. Набір документів по SPICE складається з 9 частин. Перша частина «Введення і основні концепції» і дев'ята частина «Словник» носять чисто інформаційний характер. Найважливішим елементом SPICE є найбільша частина документів, а саме: частини з другої по шосту. Наприклад, друга частина стандарту містить так звану еталонну модель (reference model), яка описує процеси. Практично, це модель процесів з ISO 12297, хоча, на жаль, ці моделі не повністю ідентичні. Результати оцінки процесів за допомогою SPICE виглядають досить складно і тому вимагають деякого спрощення для розуміння непідготовленою людиною (наприклад, таке спрощення було зроблено при створенні рис. 3).

Інші частини стандарту - сьома і восьма - присвячені відповідно, поліпшенню процесу і визначенню можливостей процесу.

Одним з важливих переваг SPICE є його відкритість і вільне поширення. На відміну від більшості інших стандартів, повний текст SPICE можна отримати на офіційному сайті SPICE: http://www.sqi.gu.edu.au/spice.

У табл. 2 коротко сформульовані переваги SPICE в порівнянні з ISO 9001.




SPICE надає більш повний набір засобів щодо забезпечення якості та поліпшенню процесів, ніж ISO 9001. Тому для забезпечення якості процесів розробки ПЗ ми рекомендуємо використовувати саме SPICE. Це допоможе організації помітно поліпшити існуючі процеси, а потім при необхідності отримати і сертифікат ISO 9001. Накопичений досвід вирішення проблеми якості за такою схемою відображений у статті [6] (зокрема, в ній сформульований набір мінімальних вимог до різним процесам в організації відповідно до моделі SPICE, достатній для отримання сертифікату ISO 9001).

Використовувати SPICE можна і в невеликих компаніях - про це свідчать результати роботи проекту SPIRE, в рамках якого проводилося впровадження процесів поліпшення якості в малих (менше 50 чоловік) компаніях з різних країн Європи. Як показав досвід, і при невеликих фінансових вкладеннях в дрібних компаніях можна добитися істотного збільшення продуктивності праці і поліпшення якості виробничих продуктів. Результати досліджень, проведених в рамках проекту SPIRE, можна знайти за адресою: http://www.cse.dsu.ie/spire.

У зв'язку зі своєю відкритістю стандарт SPICE популярний і по ньому існує багато вільно доступних матеріалів. Наприклад, на офіційному сайті SPICE будь-яка організація може зареєструватися для участі в SPICE Trials (пробних застосуваннях). На сайті групи користувачів SPICE (див. http://www.iese.fhg.de/SPICE) зібрано велику кількість інформації про сам стандарті, доступних ресурсах і його застосуванні на практиці. З серпня 1999 року виходить журнал SPICE.World, цілком присвячений SPICE (існує електронна версія цього журналу - див http://www.spiceworld.htm).

У Росії стандарт SPICE поки ще робить тільки перші кроки. У жовтні 1997 року в Санкт-Петербурзі відбувся перший семінар, присвячевячений SPICE. Його організатором виступили фінські компанії SEC Oy і STTF Oy. З тих пір семінари з SPICE в Санкт-Петербурзі проводяться цими компаніями не рідше двох разів на рік.

Ідеологія і модель створення мобільних програмних засобів викладена в документі IEEE 1003.0 - POSIX Guide - посібник з POSIX оточенню відкритих систем (OSE), яке деталізує для користувачів модель комплексу стандартів POSIX, а також взаємодіючих з ними стандартів де-юре і де-факто і специфікацій , необхідних для створення переносимих додатків. Модель відображає принципи побудови інтерфейсів прикладних програм з платформою - операційною системою, через яку здійснюється взаємодія з компонентами зовнішнього оточення. Прикладні програми безпосередньо не взаємодіють із зовнішнім оточенням, а пов'язані з ним тільки через операційну систему.

Таким чином, визначальними є два інтерфейсу між трьома базовими компонентами: між прикладними програмами і платформою - операційною системою (API) та між платформою і зовнішнім оточенням (EEI). Визначено загальні функції - послуги платформи для цих взаємодій. Зовнішнє оточення включає компоненти людино-машинного взаємодії з користувачами, компоненти інформаційної взаємодії із зовнішніми пристроями ЕОМ і з компонентами, що забезпечують комунікацію. Ці інтерфейси і послуги більш детально повинні бути формалізовані відповідними приватними стандартами POSIX. Документ включає також загальні принципи і керівництво з формування та опису складних узгоджених профілів і щодо забезпечення несуперечності їх інтерфейсів із зовнішнім оточенням. Поняття профіль відповідно до ISO 10000 і IEEE 1003.0, визначає документ, який наказує склад, комплектацію, взаємозв'язок і застосування декількох стандартів де-юре і де-факто із зазначенням параметрів і директив, необхідних для побудови складних інформаційних систем або при реалізації спеціальних функцій інформаційних технологій.

Деталізація інтерфейсів починається в стандарті IEEE 1003.1 - Інтерфейси систем прикладних програм (мова Сі) System Application program interface (API) (C language), в якому уточнюється. концепція переносимості та принципи її забезпечення шляхом уніфікації інтерфейсів прикладних програм з операційними системами. Допрацьована версія концептуального стандарту затверджена Міжнародною організацією зі стандартизації (ISO 9945-1) і анотована нижче. Основні команди управління і сервісні програми, що забезпечують переносимість, викладені в стандарті IEEE 1003.2 (Shell and utilities), який послужив базою однойменного стандарту ISO 9945-2. Таким чином, ці два стандарти є основними в нормативній базі, що підтримує перенесення програм в операційній середовищі [7, 8, 9].

Розвиток і конкретизація методів і засобів, що забезпечують мобільність прикладних програм, викладається в сукупності з 18, що підтримують стандартів групи POSIX IEEE 1003.3 20, зміст яких викладено нижче. Розробка стандартів організована за фазами: IEEE - SC22 - JTC1 - ISO [10,11], кожна з яких тривалість півроку - рік. Фазу розробки та затвердження цими організаціями кожного з них в даний момент важко встановити і реально діють як міжнародні стандарти тільки два зазначених вище. Решта стандарти анотовані далі в позитивної формі як завершені розробки, однак деякі з них не вийшли зі стадії первинних проектів IEEE. У 1991 році робоча група IEEE POSIX спільно з ISO/JTC1/SC22/WG15 підготувала план - графік робіт поцим стандартам до 1998 року. За всіма стандартами можливі і поки проводяться доповнення і зміни. У стандартах POSIX (IEEE 1003.5 ; -9 ; -16 ; -19; 20) конкретизуються інтерфейси прикладних програм , що розробляються на стандартизованих мовах програмування: Сі (ISO 9899), Ада (ISO 8652), Фортран (ISO 1359, 7846). У базових стандартах згадуються деякі особливості інтерфейсів додатків на мовах програмування Паскаль (ISO 7185), Кобол (ISO 1989). Рекомендується застосування мов у вигляді сучасних модернізованих і додаткових версій і використання для трансляції програм компіляторів, атестованих авторитетними міжнародними організаціями.

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

в які входять групи стандартів [12, 13] :

- Підтримуючі безпосередню взаємодію прикладних програм з користувачами і регламентують інтерфейси з віртуальними терміналами та графічні системи;

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

- Регламентують телекомунікацію і обмін даними на верхніх рівнях еталонної моделі ВОС;

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

П'ять стандартів POSIX присвячені профілям прикладного оточення, що взаємодіє з операційним середовищем. Вони базуються на активному використанні міжнародного стандарту з таксономії профілів (ISO 1000-1,2,3), стандартів взаємозв'язку відкритих систем комунікації (OSI), а також безлічі інших стандартів де-юре і де-факто. Основи профілів представлені в документі IEEE

1003.18, в якому викладені профілі інтерфейсів додатків в інтерактивних, розподілених, багатокористувацьких прикладних платформах. Стандарти IEEE 1003.11; -13; і -14 формалізують профілі взаємодії відповідно для діалогової обробки завдань, для інформаційних систем реального часу і для мультипроцесорних обчислювальних систем.

NIST розробив комплект атестаційних тестів і забезпечує тестування в акредитованих на відповідність POSIX випробувальних лабораторіях, а також видає сертифікати перевірки. Каталог перевірених програмних засобів публікується в спеціальному виданні.
РЕКОМЕНДОВАНА ЛІТЕРАТУРА:

1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.

2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.

3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.

4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.

5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем



6. ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом
Каталог: download -> version
version -> Захист навколишнього середовища від забруднення мийними засобами
version -> «Валеологічне виховання дітей дошкільного віку, як фактор формування здорового способу життя»
version -> Виписка з навчального плану
version -> Методичні рекомендації щодо викладання уроків для стійкого розвитку «Моя щаслива планета» розділ Система уроків-зустрічей для 3 класу курсу за вибором «Моя щаслива планета»
version -> Затверджую директор Зіньківської спеціалізованої школи І-ІІІ ст.№2 Л. В. Литус
version -> Наказ №526 " Про затвердження Науково-методичних рекомендацій щодо оцінювання навчальних досягнень учнів та оформлення сторінок класних журналів загальноосвітніх
version -> Методичні рекомендації Донецьк  2006 ббк 64. 9 (ІІ) 722 ш 30
version -> Вимоги до оформлення посібника
version -> Програма бібліотечно-бібліографічних знань для учнів 1-11 класів


Поділіться з Вашими друзьями:
1   2   3   4   5




База даних захищена авторським правом ©uchika.in.ua 2020
звернутися до адміністрації

    Головна сторінка