- •Лекція 0.Уведення в управління проектами
- •0.1.Введення до проектного менеджменту
- •0.2.Особливості програмного забезпечення як предметної сфери управління проектами інформатизації
- •0.3.«Залізний трикутник» у менеджменті програмних проектів
- •0.4.Еволюція підходів до управління проектами інформатизації
- •0.5.Основні специфічні особливості проектів з розробки програмного забезпечення
- •Лекція 1.Класифікація і оточення проектів
- •1.1.Класифікація проектів
- •1.2.Основні складові зовнішнього та внутрішнього середовища проектів інформатизації
- •1.3.Ресурси і обмежуючі фактори проектів інформатизації
- •1.4.Ролі учасників проектів інформатизації
- •1.5.Вплив зовнішніх факторів на виконання проектів інформатизації
- •Лекція 2.Життєвий цикл проекту
- •2.1.Поняття життєвого циклу програмного проекту
- •2.2.Зв’язок моделі життєвого циклу програмного проекту і підходів до управління та показників програмних проектів
- •2.3.Неструктурований життєвий цикл програмних проектів
- •2.4.Каскадна модель життєвого циклу програмних проектів
- •2.6.Модель життєвого циклу на основі розробки прототипів
- •2.7.Інкрементна модель життєвого циклу програмного проекту
- •2.8.Спіральна модель проектування
- •2.9. Ітеративна модель життєвого циклу програмного проекту
- •Лекція 3.Використання стандартів життєвих циклів інформаційних систем
- •3.1.Поняття стандартів якості і їх використання у сфері проектів інформатизації
- •3.2.Найважливіші стандарти якості і моделі процесу управління програмними проектами
- •3.3.Загальна характеристика групи стандартів sei cmm/cmmi
- •3.4.Стандарт sei sw-cmm. Стандарт sei cmmi
- •4.1.Фундаментальні принципи і проблеми оцінки економічних параметрів програмних проектів
- •4.2.Найпростіша формула розрахунку вартості проекту
- •4.3.Розрахунок трудовитрат на основі хронологічних даних
- •4.4.Одиниці оцінки розміру програмного забезпечення
- •4.5.Кількість рядків коду при оцінці розміру програмного забезпечення
- •4.6.Функціональні точки для оцінки розміру програмного забезпечення
- •4.7.Метод точок властивостей при оцінці розміру програмного забезпечення
- •4.8.Метод об’єктних точок при оцінці розміру програмного забезпечення
- •4.9.Метод побудови бліц-моделі при оцінці обсягу проекту
- •4.10.Методика Wideband Delphi при оцінці розміру програмного проекту
- •4.11.Модель cocomo для оцінки економічних параметрів програмних проектів
- •4.12.Модель cocomo II для оцінки економічних параметрів програмних проектів
- •4.13.Модель slim для оцінки економічних параметрів програмних проектів
- •Лекція 5.Сучасні методології управління програмними проектами
- •5.1.Введення до методологій управління програмними проектами
- •5.2.Загальна характеристика методології msf в управлінні програмними проектами
- •5.3.Моделі, які складають методологію msf
- •5.4.Модель проектної групи msf
- •5.5.Модель процесу msf
- •5.6.Планування з урахуванням ризиків у msf
- •5.7.Орієнтація на випуск версій продукту у msf
- •5.8.Орієнтація на продукт у msf
- •5.9.Загальна характеристика методології rup в управління програмними проектами
- •5.10.Виміри процесу розробки у методології rup
- •5.11.Статичний зміст процесу у rup
- •5.12.Життєвий цикл програмного проекту згідно з методологією rup
- •5.13.Методології швидкої розробки при управлінні програмними проектами
- •Лекція 6.Автоматизація функцій управління проектами
- •6.1.Загальна характеристика програмного інструментарію, який використовується для автоматизації управління проектами інформатизації
- •6.2.Сучасні інструменти, які використовуються учасниками програмних проектів
- •6.3.Інструментарій для планування і контролю за ходом виконання проекту
- •6.4.Засоби для оцінки економічних параметрів і ризиків програмних проектів
- •6.5.Інструментарій для контролю версій та управління змінами при виконанні програмних проектів
- •6.6.Інструментарій для управління вимогами при реалізації програмних проектів
- •6.7.Засоби забезпечення взаємодії учасників при виконанні програмних проектів
- •Лекція 7.Управління вимогами при реалізації програмних проектів
- •7.1.Основі положення управління вимогами при реалізації програмних проектів
- •7.2.Забезпечення взаємодії із замовником при реалізації програмних проектів
- •7.3.Планування, визначення пріоритетів, оцінка ризику та контроль виконання вимог
- •7.4.Управління вимогами на основі підходу до ітеративного створення версій при реалізації програмних проектів
- •7.5.Інтеграція управління вимогами у загальний процес управління програмними проектами
- •Лекція 8.Менеджмент конфігурації програмного забезпечення
- •8.1.Основні положення менеджменту конфігурації при реалізації програмних проектів
- •8.2.Контроль змін як одна із складових менеджменту конфігурацій
- •8.3.Контроль версій як одна із складових менеджменту конфігурацій
- •8.4.Контроль випусків як одна із складових менеджменту конфігурацій
- •8.5.Поняття кортежу програми, кортежу проекту та паспорту проекту при виконанні програмних проектів
- •8.6.Інструментальні засоби менеджменту конфігурацій програмного забезпечення
- •8.7.Стандартизація внутрішніх процесів при виконанні програмних проектів
- •Лекція 9.Управління персоналом при реалізації програмних проектів
- •9.1.Основні положення менеджменту персоналу при реалізації програмних проектів
- •9.2.Основні принципи розподілення ролей учасників програмного проекту
- •9.3.Забезпечення взаємодії учасників програмного проекту
- •9.4.Мотивація виконавців програмних проектів
- •9.5.Корпоративна культура при реалізації програмних проектів
- •9.6.Управління віддаленими учасниками програмних проектів
- •Лекція 10.Аутсорсинг програмних проектів
- •10.1.Основі положення аутсорсингу програмних проектів
- •10.2.Пошук замовників аутсорсингового проекту
- •10.3.Управління взаємодією із замовниками аутсорсингового проекту
- •10.4.Пошук виконавців аутсорсингового проекту
- •10.5.Управління виконавцями аутсорсингового проекту
- •Лекція 11.Безперервне поліпшення процесів виконання програмних проектів
- •11.1.Основні положення інноваційного менеджменту при виконанні програмних проектів
- •11.2.Інновації у сфері програмного забезпечення і їх вплив на параметри «залізного трикутника»
- •11.3.Безперервне поліпшення виконання програмних проектів як основна ціль проектного менеджменту
- •11.4.Забезпечення конкурентноздатності середовища розробки
- •11.5.Управління сторонніми компонентами при реалізації програмних проектів
- •Список літератури
6.7.Засоби забезпечення взаємодії учасників при виконанні програмних проектів
Інструменти забезпечення взаємодії учасників при виконанні програмних проектів – як правило, інтегровані засоби для обміну інформації.
Це наступні засоби комунікацій:
служби проведення конференцій, відео- та голосового зв’язку;
служби обміну миттєвими повідомленнями;
електронна пошта;
веб-сайти проектів;
конференції;
Wiki та ін.
Лекція 7.Управління вимогами при реалізації програмних проектів
План лекції:
Основі положення управління вимогами при реалізації програмних проектів.
Забезпечення взаємодії із замовником при реалізації програмних проектів.
Планування, визначення пріоритетів, оцінка ризику та контроль виконання вимог.
Управління вимогами на основі підходу до ітеративного створення версій при реалізації програмних проектів.
Інтеграція управління вимогами у загальний процес управління програмними проектами.
Питання, що виносяться на самостійне вивчення студентом (3,5 год.):
Управління вимогами на основі UML [8, С. 149-154 243-252, 301-312].
Управління вимогами в стандартах SEI SMM/CMMI та ISO 9000 [8, С. 419-425].
Метод FAST при визначенні вимог [7, С. 526-527]
Метод JAD при визначенні вимог [7, С. 527-532]
7.1.Основі положення управління вимогами при реалізації програмних проектів
Формулювання вимог – найважливіший етап у розробці ПЗ. Неправильно сформульовані вимоги є джерелом найдорожчих помилок у розробці ПЗ.
Важливе завдання на етапі формулювання вимог полягає у тому, щоб зрозуміти бажання і очікування замовника і перетворити їх у конкретні вимоги до продукту, який створюється, з урахуванням обмежень проекту і можливостей розробника.
Згідно з SEI CMM ціль формулювання вимог полягає у тому, щоб «встановити загальне розуміння між замовником та програмним проектом на основі вимог, які висуває замовник до програмного проекту».
Етапи формулювання вимог:
визначення вимог – розуміння бажань замовника;
аналіз та обговорення вимог – аналіз вимог та їх обговорення з метою визначення прийнятного рішення;
специфікація вимог – формулювання однозначних специфікацій рішень;
системне моделювання;
атестація вимог – перевірка специфікації;
управління вимогами.
7.2.Забезпечення взаємодії із замовником при реалізації програмних проектів
Типи вимог:
свідомі – ті, що явно називаються замовником;
несвідомі – ті, що не називаються замовником, наприклад, такі, про які він забуває.
Також вимоги бувають:
функціональні (властивості продукту) – визначають, що саме має виконувати програмний продукт;
нефункціональні – як правило, мають відношення до якості і визначають, наскільки правильно програмний продукт має виконувати те, що від нього вимагається.
Існують також архітектурні вимоги – ті, які передбачають, яким саме чином мають вирішуватися поставлені перед системою задачі.
Також бувають обмежуючи вимоги, до яких відносяться обмеження при проектуванні систем, відповідність стандартам, юридичні та організаційні питання.
При роботі із замовником важливо максимально точно визначити, що саме вимагає замовник. Інтерпретація слів замовника і переведення їх у конкретні специфікації програмного продукту є досить складною задачею.
Важливо визначати якість вимог. Якісною можна вважати таку вимогу, яку можна перевіряти. Якщо для вимоги можуть бути розроблені конкретні засоби для тестування, то це означає, що подібна вимога визначена однозначно та може бути виміряна. При цьому найважливішим фактором виступає можливість однозначного визначення того моменту, коли вимога задоволена (тобто конкретна необхідна функціональність реалізована).
При формулюванні вимог у процесі взаємодії із замовником розглядаються наступні атрибути вимог, які дозволяють досягти запланованого рівня якості:
коректність – вимога може бути підтверджена лише замовником;
придатність – вимога може бути задоволена з урахуванням існуючих проектних обмежень;
необхідність – у процесі переговорів із замовником та виконавцем визначаються функціональні можливості продукту, які є ключовими для нього;
пріоритетність – визначається пріоритет одних вимог по відношенню до інших;
однозначність – наявність лише однієї інтерпретації, визначає простоту читання і розуміння;
лаконічність – вимога має містити лише ту інформацію, яка необхідна для її виконання, уся інша інформація має міститися окремо;
можливість перевірки (тестованість, вимірюваність) – відповідність програмного продукту вимозі може бути перевірено програмою чи людиною;
завершеність – вимога сформульована таким чином, що містить усю необхідну інформацію;
відповідність – узгодженість усіх документів, які стосуються даної вимоги;
здатність до змін – можливість внесення змін до вимоги має розглядатися як допустимий і логічний процес;
трасуємість – можливість відслідковування зв’язків, вимога має явно вказувати на документ, який є джерелом для неї, а її реалізація має бути явно пов’язана із вимогою.
Важливо, щоб при визначенні вимог мова йшла про специфікації і результати, а не про те, яким чином слід їх досягати. Зокрема, бажано формулювати вимоги як відповідь на питання «які?», я не «як?». Наприклад, «Які дані має використовувати та формувати система?», «Які функції має виконувати система?» та ін.
Найважливіша і найскладніша задача – знайти спільну мову із замовником і переконатися, що замовник очікує саме те, що планує реалізувати виконавець.
