Керування інженерією програмного забезпечення



Мы поможем в написании ваших работ!


Мы поможем в написании ваших работ!



Мы поможем в написании ваших работ!


ЗНАЕТЕ ЛИ ВЫ?

Керування інженерією програмного забезпечення



 

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

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

Загальні питання керування проектом містяться в ядрі знань РМВОК [14], а також у стандарті ISO/IEC 12207 - Software life cycle processes, де керування проек­том розглядається як організаційний процес ЖЦ.

Область знань, «Керування інженерією ПЗ (Software Engineering Management)» складається з таких розділів:

- організаційне керування (Organizational Management),

- керування процесом/проектом (Process/Project Management),

- інженерія вимірювання ПЗ (Software Engineering Measurement).

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

Керування проектом/процесом- це складання плану проекту, побудова графіків робіт (мережних або часових діаграм) з урахуванням наявних ресурсів, розподіл персоналу за видами робіт у проекті, виходячи з заданих термінів і варто­сті їх виконання. Для ефективного керування проектом проводиться аналіз фінансової, технічної, операційної і соціальної політики організації-розробника для вибору правильної стратегії виконання робіт і контролю плану, а також проміжних продуктів (проектних рішень, діаграм UML, алгоритмів і ін.).

У задачі керування проектом входять також уточнення вимог, перевірка їх відповідності заданим специфікаціям характеристик якості, а також верифікація функцій проекту. Процес керування базується на планових термінах, що відобра­жені мережними діаграмами PERT (Program Evaluation and Review Technique), CPM (Critical Path Method). У них указуються роботи, зв'язки між ними і час виконання.

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

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

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

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

Інженерії вимірювання - удосконалювання процесів керування проектом; оцінювання часових витрат і вартості ПЗ, їх регулювання; визначення категорій ризиків і відстеження чинників для регулярного розрахунку ймовірностей їх виникнення; перевірка заданих у вимогах показників якості окремих продуктів і проекту в цілому [9].

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

 

Процес інженерії

 

Процес інженерії - є мета рівнем, що визначає основні поняття, способи реа­лізації, оцінювання, вимірювання, дії з керування змінами й удосконалення самого процесу. Як уже згадувалася в п. 1.1.2., для оцінювання й удосконалення процесу програмної інженерії застосовується модель зрілості СММ [12], яку розроблено Інститутом програмної інженерії SEI (Software Engineering Institute) CLLIA. Ця модель встановлює рівні готовності організації-розробника ПЗ створювати задовільно, середньо, добре і дуже добре програмну продукцію. Поняття рівня готовності визначається наявністю в організації необхідних ресурсів (людських, програмних, технічних і фінансових), стандартів і методик, а також здатністю колективу створювати програмні продукти. Модель СММ має п'ять рівнів. Перший і другий рівні фіксують недостатню готовність виконувати розробку продукту. Третій - п'ятий рівні характеризують певний ступінь готовності, зрілості і здатності фахівців (а, значить, і організації) виготовляти, відповідно, середній, гарний і відмінний продукт. Чим вище рівень зрілості, тим більше вимог ставиться до процесу програмної інженерії, придатного для виконання цілей і задач утворення продукту, що задовольняє користувача.

Існують різновиди цієї моделі: СММ - SW (Software) для оцінки зрілості ПЗ, СММІ (СММ Integrated) - для обліку потреб великих державних структур в ПЗ (СІЛА), а також інші моделі, наприклад, Bootstrap - для оцінки зрілості малих і середніх комерційних компаній, стандарт ISO 15504 (Software Process Improvement and Capability) - для удосконалення процесу (наприклад, удосконалювати процес на другому рівні, щоб одержати сертифікат на третій рівень зрілості).

Концепція зрілості процесу програмної інженерії ґрунтується на процесі ПЗ (software process), широті його можливостей (software process capability), результативності (software process performance) і зрілості (software process maturity). Процес ПЗ у моделі СММ - це множина діяльностей (activities), методів (methods), практичних прийомів (practices), що використовують при розробки ПЗ шляхом планування робіт і оцінювання проміжних результатів, які приводять до кінцевого продукту високої якості.

Область знань «Процес програмної інженерії (Software Engineering Process)» складається з таких розділів:

- концепції процесу інженерії ПЗ (Software Engineering Process Concepts), інфраструктура процесу (Process Infrastructure),

- визначення процесу (Process Definition),

- оцінки процесу (Process Assessments),

- якісний аналіз процесу (Qualitative Process Analysis),

- виконання і змінювання процесу (Process Implementation and Change).

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

Інфраструктура процесумістить у собі ресурси (людські, технічні, інформаційні і програмні), стандарти, методики керування якістю, проектом і структуру колективу розробників ПЗ типу: команда, бригада, експериментальна фабрика (Experimental Factory), каркас виробництва на лінії продуктів (Framework for Product Line Practice) і ін. До основних задач інфраструктури належать керування і комунікації в колективі, інженерні методи виробництва програмного продукту й удосконалення процесу з накопиченим досвідом розробки ПЗ.

Визначення процесуґрунтується на: типах процесів і моделей (каскадна, спіральна, ітераційна й ін.); моделях ЖЦ процесів і засобів, стандартах ЖЦ ПЗ ISO/IEC 12207 і ISO/IEC 15504, IEEE std. 1074 і IEEE std. 1219; методах і нотаціях подання процесів і автоматизованих засобів їх підтримки. Основною метою процесу є підвищення якості одержуваного продукту, поліпшення різних аспектів програмної інженерії, автоматизація і удосконалення процесів.

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

Оцінки стосуються також технічних робіт у сфері програмної інженерії, керування персоналом і якості ПЗ. Для цього проводяться експериментальні дослідження середовища, збирання інформації, моделювання, класифікація отрима­них помилок і дефектів, а також статичний аналіз недоліків процесу порівняно з існуючими стандартами (наприклад, ISO/IEC 12207) і потенційних аспектів необхідності вдосконалювати процес.

Якісний аналіз процесуполягає в ідентифікації і пошуку «слабких місць» у процесі створення ПЗ на початку його функціонування і після експлуатації. Розглядаєтьсядві техніки аналізу: огляд даних і порівняння процесу з основними положеннями стандарту ISO/IEC 12207, збирання даних про якість процесів; аналіз головних причин відмов у функціонуванні ПЗ, відкіт назад від точки виникнення відхилення до точки правильної роботи системи для з'ясування причин зміни процесу. На якість результатів проекту і процесу впливають застосовувані інструменти і досвід фахівців.

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

 



Последнее изменение этой страницы: 2016-04-23; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.236.50.201 (0.005 с.)