Процес програмної інженерії (Software Engineering Process)
Область знань "Процес програмної інженерії" (Software Engineering Process) може бути розглянута на двох рівнях. Перший рівень містить технічну та управлінську діяльність протягом процесів життєвого циклу програмного забезпечення, що включають придбання, розробку, супровід і виведення з експлуатації програмних систем. Другий рівень - "мета-рівень", пов'язаний з визначенням, реалізацією, оцінкою, виміром, управлінням, зміною та вдосконаленням самих процесів життєвого циклу програмного забезпечення. Перший рівень освітлений в інших областях знань SWEBOK. Другий рівень розглядається в даній галузі знань.
Прослухати
Термін "процес програмної інженерії" (software engineering process) може інтерпретуватися по-різному і це, відповідно, може призводити до певної плутанини.
• З одного боку, враховуючи специфіку оригінального терміну в англійській мові, де (з точки зору граматики) може існувати термін the software engineering process, він буде мати на увазі єдино правильний спосіб виконання завдань (performing tasks) програмної інженерії. Таке припущення свідомо відкидається SWEBOK, так як "єдино правильного" процесу бути не може. Такі стандарти, як IEEE / ISO / ГОСТ 12207 кажуть про процеси (у множині - processes), маючи на увазі що програмна інженерія містить безліч процесів, наприклад, процес розробки (Development Process) і процес конфігураційного управління (Configuration Management Process).
• Друга інтерпретація пов'язана із загальним (general) обговоренням процесів, пов'язаних із програмною інженерією. Дана точка зору відображена у назві цієї галузі знань і є однією з найбільш часто припущених при використанні терміну "процес програмної інженерії".
Нарешті, третє розуміння даного терміну може означати реальний набір дій, що вживаються в даній організації і розглядається як єдиний процес на рівні організації. Такий підхід також розглядається в даній галузі знань (та чи інша інтерпретація зазвичай залежить від контексту обговорення).
Дана область знань пов'язана з усіма елементами управління процесів життєвого циклу програмного забезпечення, в яких процедурні (управлінські) чи технологічні зміни застосовуються до вдосконалення процесу або продукту.
Процес програмної інженерії стосується не тільки великих організацій. Більше того, пов'язані з даним процесом дії можуть і повинні застосовуватися невеликими організаціями, командами та окремими фахівцями.
Мета управління процесами програмної інженерії полягає в реалізації нових та кращих процесів у реальній практиці конкретних фахівців, проектів або організації (окремих її груп підрозділів або організації в цілому).
Дана область знань не адресується безпосередньо питанням управління персоналом (human resources management, HRM). Ці теми досліджуються, наприклад, в People CMM (People Capabililty Maturity Model) і процесах системної інженерії (див. стандарти ISO 15288 "Systems Engineering - System Life Cycle Process" і IEEE 1220 "Standard for the Application and Management of the Systems Engineering Process" ).
Також, необхідно розуміти, що багато процесів програмної інженерії породжуються і тісно пов'язані з іншими дисциплінами, наприклад, управлінням (management), хоча іноді ці процеси і називають по-іншому в контексті цих дисциплін.
Малюнок 1. Область знань "Процес програмної інженерії" [SWEBOK, 2004, с.9-2, рис. 1]
1. Реалізація та зміна процесу (Process Implementation and Change)
Дана секція фокусується на організаційних змінах. Вона описує інфраструктуру, дії, моделі і практичні міркування щодо реалізації процесу і його зміни. Нижче розглядається ситуація, в якій ті чи інші процеси реалізуються вперше (наприклад, процес проведення інспекцій в проекті чи охоплення повного життєвого циклу програмного забезпечення) і де змінюються вже існуючі (використовувані) процеси. Мова піде про те, що називають еволюцією процесу (process evolution). Існуючі практики розглядаються в контексті часто необхідної модифікації. Якщо потрібні модифікації досить великі, це призводить і до необхідності зміни організаційної культури.
1.1 Інфраструктура процесу (Process Infrastructure) Ця тема охоплює знання, пов'язані з інфраструктурою процесу програмної інженерії і, великою мірою, базується на стандартах IEEE / ISO / ГОСТ 12207 "Standard for Information Technology - Software Life Cycle Processes" та ISO 15504 "Information Technology - Software Process Assessment" (відомий також як SPICE - Software Process Improvement and Capability dEtermination). Для впровадження процесів випуску необхідно володіти відповідною інфраструктурою, маючи на увазі, що ресурси (компетентний персонал, інструменти, фінансування) - доступні, а відповідальність - розподілена <по членах проектної команди та / або організаційної одиниці, в термінах структури компанії або організації, наприклад, відділу або групи>. Виконання цих завдань є хорошим індикатором того, що менеджмент <управлінський персонал проекту / організації> реально докладає зусилля з підтримки процесу програмної інженерії. Як наслідок таких зусиль можуть створюватися різні комітети та інші спеціалізовані організаційні структури та органи, в загальному випадку звані steering committee - "керуючий комітет", що володіє наглядовими функціями щодо зусиль, спрямованих на моніторинг, контроль і вироблення рекомендацій щодо підтримки та поліпшення процесу програмної інженерії . На основі таких функцій будемо надалі використовувати термін "наглядовий орган", підкреслюючи реальні завдання такої комісії і можливість як формальної, так і неформальної його організації. Наглядовииий орган є основою процесної інфраструктури у проектній команді, підрозділі або організації, в цілому. Зазвичай, виділяють два типи інфраструктури, що застосовуються на практиці Software Engineering Process Group (SEPG, звичайно, в українській мові для такої структури використовується наведена англомовна абревіатура) і Experience Factory (EF, "фабрика досвіду"). 1.1.1 Software Engineering Process Group (SEPG)
SEPG створюється як центральний орган, що приймає на себе роботу по process improvement - вдосконалення процесу (-ів). SEPG бере на себе відповідальність з безлічі питань, пов'язаних з цим завданням в термінах ініціювання <поліпшень> та підтримки <існуючого процесу і його постійного вдосконалення>. Часто SEPG формується з декількох провідних членів проектної команди (якщо, SEPG створюється в рамках проекту) або на рівні підрозділу, або всієї організації. При цьому, в більшості випадків, SEPG не включає "звільнених" фахівців і, таким чином, її члени завжди знаходяться в контексті реальних проблем, з якими стикаються при виконанні своїх "основних" обов'язків. Виключення, звичайно, складають SEPG, що формуються для досягнення певних організаційних цілей - приведення процесів у відповідність тим або іншим вимогам і, зокрема, для досягнення того чи іншого рівня зрілості CMMI, забезпечення якості в рамках ISO або SixSigma і т.п. У цих випадках SEPG зазвичай очолюється виділеним експертом (або групою) в області постановки і вдосконалення процесів.
1.1.2 Experience Factory (EF)
Концепція "фабрики досвіду" відокремлює проектну організацію (наприклад, організаційну структуру, що відповідає за розробку програмного забезпечення - ІТ-підрозділ, групу розробки або проектну команду) від організації, що відповідає за поліпшення процесу. Проектна організація, в цьому випадку, фокусується на розробці і супроводі програмного забезпечення, а EF - зайнята вдосконаленням процесу програмної інженерії. Основним завданням EF є інституалізація (впровадження в повсякденну практику) колективного досвіду та отриманих уроків в масштабах організації на основі розробки, оновлення та впровадження в проектну організацію "пакетів досвіду" - experience packages (наприклад, керівництв, моделей, курсів навчання і т.п.), <типових> "активів процесу" - process assets. Проектна організація пропонує на розгляд EF свої продукти, плани, що використовувалися при розробці, а також дані, зібрані в процесі розробки і експлуатації. Складно провести чітку грань між SEPG і EF. Швидше можна говорити про створення SEPG у формі "фабрики досвіду" у великих ІТ-підрозділах, наприклад, міжнародних компаній, або досить великих організаціях, основною діяльністю яких є створення програмного забезпечення. У цьому випадку SEPG проводить пілотне впровадження удосконалених або нових процесів в рамках одного або декількох вибраних проектів і, потім, поширює цей досвід у всій організації. Так чи інакше, віддача від SEPG / EF зазвичай помітна в проектно-орієнтованих або проектних організаціях, чия діяльність побудована у формі управління портфелем проектів (більш детальну інформацію про проектно-орієнтовані організації можна, наприклад, знайти в PMI PMBOK та інших матеріалах Project Management Institute). У загальному випадку, кажучи про інфраструктуру процесів, зазвичай використовують саме термін SEPG для обох типів організації команд, що фокусується на процесі розробки програмних систем.