Управління розробкою програмного забезпечення

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

Дослідження проектів, які зазнали невдачі, показали, що найбільш поширеними причинами провалів були:[2][3][4]

1. Недостатнє залучення кінцевого користувача.
2. Слабка взаємодія між замовником, розробником програмного забезпечення і користувачем.
3. Нереальні, чи незрозуміло сформульовані цілі проекту.
4. Помилковий підрахунок потрібних ресурсів.
5. Некоректно визначені системні вимоги.
6. Непоінформованість менеджера проекту про поточний стан проекту.
7. Некеровані ризики.
8. Використання надто нових, нестабільних техноногій.
9. Нездатність впоратися зі складністю проекту.
10. Слабке управління проектом.
11. Відсутність виконавчої підтримки між замовником і кінцевим користувачем.
12. Фінансові обмеження.

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

Пов'язаний в першу чергу з виробничим аспектом розробки програмного забезпечення, на відміну від технічного аспекту, такого якa інструментальне програмне забезпечення. Ці процеси існують в першу чергу для підтримки управління розробки програмного забезпечення, і, як правило, направлені у бік бізнес-рішення проблеми. Багато процесів розробки програмного забезпечення можуть бути запущені аналогічним чином до загальних процесів управління проектом. Наприклад:

• Міжособові комунікації управління та вирішення конфліктів. Активна, часта і чесна комунікація — це найбільш важливий фактор в збільшені ймовірності успіху проекту та пом'якшення проблемних проектів. Команда розробників повинна прагнути участі кінцевого користувача і заохочувати його вкладення в процесі розробки. Відсутність користувачів, що залучені до процесу, може привести до неправильного тлумачення вимог, нечутливість до потреб клієнтів і нереалістичні очікування з боку клієнта. Розробникам програмного забезпечення, користувачам, менеджерам проектів, замовникам і спонсорам проекту необхідно регулярно і часто спілкуватися. Інформація, отримана від цих дискусій, дозволяє команді проекту проаналізувати сильні і слабкі сторони, можливості та загрози і діяти відповідно до цієї інформації, щоб отримати вигоду з можливостей і звести до мінімуму загрози. Навіть погані новини можуть бути хорошими, якщо це було обговорено достатньо рано, тому що проблеми можуть бути пом'якшені, якщо вони не виявлені надто пізно. Наприклад, неформальна розмова з користувачами, членами команди, та іншими зацікавленими сторонами може часто вивести на поверхню потенційні проблеми раніше, ніж під час офіційних засідань. Всі комунікації повинні бути інтелектуально чесними і справжніми, і регулярними, критика роботи необхідна для розвитку, але якщо вона здійснюється в спокійній, шанобливій, конструктивній формі, а не у формі обвинувачень і люті. Часті випадкові розмови між розробниками і кінцевими користувачами, так як і між менеджерами та клієнтами проекту необхідні, щоб проект був актуальним, корисним і ефективним для кінцевих користувачів. Ефективне міжособове спілкування та управління конфліктами — це ключ до управління розробкою програмного забезпечення. Немає методології або стратегії покращення процесу, які б могли подолати серйозні проблеми у комунікації або неправильному управлінні міжособових конфліктів. Крім того, результати, пов'язані з такими методологіями і стратегіями, щодо поліпшення процесів, посилюються від кращої комунікації. Комунікація повинна зосередитися на тому, чи розуміє команда статут проекту і чи буде команда робити успіхи в досягненні цієї мети. Кінцеві користувачі, розробники програмного забезпечення та керівники проектів повинні часто задавати елементарні, прості питання, які допоможуть визначити проблеми, перш ніж вони гнитимуть в районі-катастроф. В той час, як участь кінцевого користувача, ефективна комунікація та команда не є достатніми для успіху, вони необхідні, щоб забезпечити хороший результат, і їх відсутність майже точно призведе до поганих результатів[3][4][5]
• Ризик-менеджмент це процес вимірювання або оцінки ризику і потім розробки стратегії управління ризиком. В цілому, стратегії, що використовуються, включають ризик для іншої сторони, уникнення ризику, зниження негативного впливу ризику і приймання всіх або деяких з наслідків конкретного ризику. Управління ризиками в управлінні розробкою програмного забезпевчення починається з Техніко-економічного обґрунтування для запуску проекту, який включає в себе аналіз витрат і вигод, а також список резервних варіантів у випадку провалу проекту, який називається називається резервний план.
  • Ризик-менеджмент включає в себе управління можливостями, що означає те ж саме, за винятком того, що потенційний результат-ризик матиме позитивний, а не негативний вплив. Хоча теоретично обробляються таким же чином, використання терміну «можливість» замість негативного терміну «ризик» допомагає зберегти команду зосередженою на можливих позитивних результатах будь-якого зафіксованого ризику у своїх проектах, таких як спін-оф проекти і безкоштовні додаткові ресурси.
• Управління вимогами — це процес виявлення, документування, аналізу, відстежування пріоритетів і узгодження вимог, і потім контролювання змін і спілкування з відповідними зацікавленими сторонами. Управління вимогами нової або зміненої комп'ютерної системи, які включає в себе аналіз вимог, є важливою частиною процесу програмної інженерії; в результаті цього бізнес-аналітики або розробники програмного забезпечення визначають потреби або вимоги клієнта; виявивши ці вимоги, можна проектувати рішення.
• Управління змінами це процес виявлення, документування, аналізу, визначення пріоритетів та узгодження змін Рамки (керування проектами), а потім контролювання змін і спілкування з відповідними зацікавленими сторонами. Змінити аналіз впливу нового або зміненого обсягу, який включає в себе аналіз вимог на рівні змін, є важливою частиною процесу програмної інженерії; в результаті чого бізнес-аналітики або розробник програмного забезпечення визначає змінені потреби або вимоги клієнта; виявивши ці вимоги, можна зробити ре-дизайн або змінити рішення. Теоретично, кожна зміна може вплинути на терміни і бюджет проекту програмного забезпечення, і, отже, за визначенням, кожний проект повинен включати в себе аналіз ризику і користі до затвердження.
• Керування конфігурацією — це процес виявлення і документування самої сфери, в яку програмний продукт йде, в тому числі всіх субпродуктів та змін, і дозволяє дискутувати на ці теми відповідним зацікавленим сторонам. В цілому, процеси, які використовуються, включають контроль версій і архівні угоди програмного забезпечення.
• Управління релізами це процес виявлення, документування, визначення пріоритетів та узгодження релізів програмного забезпечення, а потім контролювання графіку випуску та доведення до зацікавлених сторін. Більшість програмних проектів мають доступ до трьох програмних середовищ, в які програмне забезпечення може бути випущене; Розробка, випробування і виробництво. У дуже великих проектах, де розподіленим командам необхідно інтегрувати свою роботу, перш ніж випустити для користувачів, часто буде більше середовищ для тестування, так звані модульні тестування, системні тестування або інтеграційні тестування, до виходу на приймальне тестування.
  • Управління релізами включає Управління даними, яка поступово набирає уваги. Оскільки, очевидно, що користувачі можуть ґрунтуватися тільки на даних, які доступні їм, і «реальні» дані доступні тільки в програмному середовищі під назвою «виробництво». Для того, щоб перевірити свою роботу, програмісти часто створюють «фіктивних дані» або «заглушки даних». Традиційно, більш старі версії системи виробництва колись використовувалися для цієї мети, але, оскільки компанії все більше покладаються на зовнішніх спонсорів для розробки програмного забезпечення, дані компанії не можуть бути випущені для команди розробників. У складних середовищах, набори даних можуть бути створені так, що потім мігруватимуть через тестові середовища відповідно до графіка випробувань релізу, як і в цілому графіку випуску програмного забезпечення.

В обчисленні, термін issue являє собою одиницю роботи, яку потрібно виконати для покращення в системі. Проблемою може бути помилка, завдання, зникла документація і так далі.

Наприклад, у OpenOffice.org звикли називати їх модифіковану версію Баґзілла IssueZilla. Станом на вересень 2010 року, вони називали свою систему Issue Tracker.

Слово «issue» також використовується як синонім до слова «проблема». Проблеми виникають час від часу і важливо вирішувати їх вчасно, для того, щоб уникнути затримок під час доставки продукції.

Оскільки управління розробкою програмного забезпечення є частиною загального управління проектами, дехто вважає, що управління розробкою програмного забезпечення схоже до управління виробництва, яке може бути здійсненим будь-ким з навичками управління, але без навичок програмування. Джон С. Рейнольдс спростовує цю точку зору і стверджує, що розробка програмного забезпечення є повністю дизайнерською роботою, і порівнює менеджерів, які не вміють програмувати, до редакторів з газет, які не вміють писати.[6]

• Методологія програмування
• Управління проектами
• Програмна інженерія
• Ризик-менеджмент

• Resources on Software Project Management from Steve McConnell
• Resources on Software Project Management from Dan Galorath