4. Вимірювання щодо процесів і продуктів (Process and Product Measurement)

Через те, що додаток кількісних оцінок до програмної інженерії може бути досить складним, зокрема, в термінах моделювання або методів аналізу, існує ряд фундаментальних аспектів вимірювань в програмної інженерії, що лежать в основі багатьох більш детальних вимірювань і процесів аналізу. Більш того, результати зусиль щодо вдосконалення процесів і продуктів можуть бути оцінені тільки в тому випадку, якщо встановлені кількісні характеристики заданих параметрів <процесів і продуктів> для заданих віх або, більш точно (так як вимірювання, все ж виходять за рамки віх конкретних проектів, якщо, звичайно, сама SPI-діяльність не позиціонує як проект, що, звичайно, можливо), так званих "базових ліній" (baseline *).

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

Вимірювання можуть проводитися для підтримки ініціювання реалізації та зміни процесів і для оцінки результатів таких робіт. Також, вимірювання можуть виконуватись і щодо самих продуктів. Ключові поняття, терміни і методи вимірювань в додатку до програмного забезпечення визначені в стандарті ISO 15939 "Software Engineering - Software Measurement Process" та міжнародному словнику метрології ISO. ISO 15939 також визначає стандартний процес для вимірювання характеристик процесів і продуктів. Необхідно відзначити, що в літературі зустрічаються деякі термінологічні відмінності, наприклад, термін "метрика" (metric) часто використовується замість терміна "вимір" (measure) **.

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

4.1 Вимірювання щодо процесів (Process Measurement)

Використовуваний тут термін "process measurement" - "виміру щодо процесу" передбачає збір, аналіз та інтерпретацію кількісної інформації про процес. Вимірювання використовуються для ідентифікації сильних і слабких сторін процесу (strenghts and weaknessess) і для оцінки процесу після того, як він реалізований і / або змінений.

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

Рисунок 2. Зв'язок між процесом і його результатами (або "виходом процесу" - process outcome).

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

Хоча певні зусилля можуть спрямовуватися на вирішення питань використання відповідного інструментарію, головний ресурс, який потрібний в управлінні - персонал. Як результат, найбільш важливі метрики стосуються оцінки продуктивності команд і процесів (наприклад, може використовуватися оцінка функціональних точок, вироблених на одиницю трудовитрат * - "person-effort"), а також асоційованого з цим рівня досвіду в програмній інженерії в цілому і в окремих технологіях зокрема.

* Трудовитрати найчастіше визначаються як "людино-година", "людино-день" або "людино-місяць"; тут корисно звернутися до ювілейного другого видання класичної праці Фреда Брукса "Міфічний людино-місяць" [Брукс, 1995].

Результати процесу можуть, наприклад, оцінюватися щодо якості продукту (як число збоїв на тисячу рядків коду - KLOC, Kilo-Lines of Code або на функціональну точку - FP, Function Point), супроводження (зусилля, необхідні для реалізації певного типу змін), продуктивність (LOC, Lines Of

Code або FP за людино-місяць), час виведення продукції на ринок (time-to-market) або ступінь задоволеності споживачів (за вимірюваннями результатів опитувань користувачів). Метод оцінки зв'язку між процесом і його "виходом" (результатом) залежить від конкретного контексту, наприклад, масштабів (розмірів) організації. У загальному випадку, ми фокусуємося на результатах процесу. Однак, для досягнення заданих результатів (наприклад, у термінах більш високої якості, кращої супроводженості , більшої задоволеності користувачів) ми повинні впровадити відповідні процеси. Звичайно, не тільки процеси безпосередньо впливають на результат <проекту>. Існують і інші фактори, які відіграють не менш важливу роль, наприклад, можливості інструментів і потенціал, знання і досвід фахівців. Коли оцінюється вплив зміни процесів, такі фактори повинні враховуватися (наприклад, спроба впровадження розвинених процесів програмної інженерії при відсутності ресурсів або в непідготовленому організаційному середовищі фактично призведе до краху таких ініціатив). Крім того, важлива ступінь інституалізації процесів (process institualization або process fidelity - проходження заданим процесам як повсякденна практика роботи). Фактор інституалізації в більшості випадків пояснює, чому "хороші" процеси не призводять до бажаного результату, коли процеси повністю або частково залишаються лише на папері.