Лекція 3.Вдосконалення процесу проектування ПЗ

Визначення. Вдосконалення процесу (software process improvement) – це діяльність по зміні існуючого процесу (як поточного, в рамках одного проекту, так і стандартного, для всієї компанії) з метою поліпшення якості створюваних продуктів і/або зниження ціни і часу їх розробки. Причини актуальності цієї діяльності для компаній-виробників ПО полягає в наступному.

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

2. Спостерігається швидке зростання компаній і їх вихід на нові ринки, що вимагає нової організації робіт.

3. Має місце висока конкуренція, яка вимагає пошуку ефективніших, економічніших способів розробки.

Що і яким чином можна покращувати.

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

2. Поліпшення окремих управлінських і інженерних практик – тестування, управління вимогами і ін.

3. Повна, комплексна перебудова всіх процесів в проекті, департаменті, компанії (у відповідності, наприклад, з CMMI).

4. Сертифікація компанії (CMM/CMMI, ISO 9000 і ін.).

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

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

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

Pull/Push стратегії. У контексті впровадження інновацій у виробничі процеси бизнес-компаний (не обов'язково компаній по створенню ПО) існують дві наступні парадигми.

1. Organization pull – інновації націлені на вирішення конкретних проблем компанії.

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

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

Приклад використання стратегії technology push – перехід компанії із засобів структурної розробки на объектно-ориентрованные. Ще один приклад використання тієї ж стратегії – впровадження стандартів якості ISO 9000 або CMMI. У обох цих випадку компанія не вирішує якусь одну проблему або ряд проблем – вона хоче радикально змінити ситуацію, вийти на нові рубежі і так далі

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

Використання стратегії organization pull менш ризиковано, зміни, що вносяться нею, в процес менш глобальні, локальніші. Але і вигод такі інновації приносять менше, в порівнянні з вдалими впровадженнями відповідно до стратегії technology push.

Необхідно також відзначити, що існують проблеми, які неможливо усунути точковими переробками процесу, тобто необхідно застосовувати стратегію technology push. Приведемо процес супроводу і розвитку сімейства програмних продуктів, що як приклад зайшов в безвихідь, – компанія терпить великі збитки, супроводжуючи вже поставлені продукти, інструментальні засоби проекту безнадійно застаріли і знаходяться в жалюгідному стані, менеджмент засмучений, всі спроби керівництва змінити процес натрапляють на нерозуміння колективу, сварки і конфлікти. Можливо, що у такому разі без "революції" не обійтися.

Еще одно различие обеих стратегий: в случае с organization pull, как правило, возврат инвестиций от внедрения происходит быстрее, чем в случае с technology push.