Управління змінами: невже завжди повинен бути компроміс між якістю і швидкістю розробки програмного забезпечення?, Комерція, Різне, статті

Зміст



Резюме



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


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


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


Ключем до ефективного управління змінами є використання інструменту керованого процесом управління змінами, який дозволяє інтегрувати це управління змінами впродовж всього процесу розробки. Інструменти управління змінами, які регламентують і автоматизують процеси зміни, забезпечують постійне дотримання відповідних стандартів. Рішення AllFusion Change Management компанії Computer Associates International, Inc. (CA) – Це інструменти направляється процесом управління змінами, які пропонують повний спектр функцій управління змінами і інтегруються в процес розробки.


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


Якість на противагу швидкості розробки


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


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


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


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


Стикаючись з властивими процесу протиріччями між якістю і швидкістю, організації приділяють пильну увагу тим сферам, в яких ці протиріччя переважно виникають, а саме в управлінні змінами програми.


Проблеми в управлінні змінами


Оскільки розробка додатків стає все більш складною, особи, відповідальні за розробку, повинні робити більше з меншими витратами. Це показало недавнє опитування, проведене компанією CA.


В Австралії в жовтні 2002 року1 компанія CA провела опитування організацій в Австралії та Новій Зеландії з метою визначення їх потреб і проблем в управлінні змінами. Шістдесят сім чоловік з різних організацій і галузей промисловості брали участь в опитуванні, присвяченому проблемам, з якими вони стикаються в управлінні змінами, і методам їх вирішення.


В результаті опитування були чітко виявлені деякі проблеми, з якими стикаються організації-розробники ПЗ:



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


На чолі постійно наростаючою складності розробки знаходиться необхідність збільшення обсягу робіт. Від 65% опитаних їх організації вимагали частіше випускати оновлення програмного забезпечення. Майже чверть опитаних заявила, що їх просили набагато частіше випускати оновлення. Більшість респондентів вважали, що є можливість підвищити свою продуктивність розробки, і тільки 14% респондентів були повністю задоволені продуктивністю своїх груп розробників.


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


У дослідженні “Хаос”2, Проведеному Standish Group, наводяться результати проектів розробки додатків:



У дослідженні “Хаос” також повідомляється, що лише 25% проектів впроваджені успішно, 28% проектів зупинені, і в 46% проектів виникли значні проблеми з постачанням.


Очевидно, що розробка додатків не завжди завершується успішно і часто пов’язана з затримками або перевищенням бюджету. Це виливається в значне збільшення витрат на ІТ та втрачені можливості. Тому не дивно, що керуючі директори та керівники інформаційної служби прагнуть поліпшити управління змінами і тим самим поліпшити управління ризиками в розробці програмного забезпечення.


Роль управління змінами


Управління змінами включає контрольований підхід до управління розвитком програмного забезпечення, таким чином максимально скорочуючи ризик виникнення проблем з поставленим продуктом.


Один з показників правильного управління змінами – це повторювані процеси. Якщо підхід є контрольованим, його можна повторити з тими ж результатами і з більшою впевненістю в результатах проекту.


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


Враховуючи це, не дивно, що в центрі уваги опитаних знаходиться управління змінами. 40% респондентів впровадили методологію або акредитацію, і 83% респондентів вже використовують інструмент управління змінами або розглядають питання про його використання. Це співвідношення було вище у великих групах розробників.


Чи є управління змінами проблемою тільки для великих організацій-розробників?


Можна було б припустити, що розглянуті проблеми властиві тільки для великих груп розробників. Слід зауважити, що в опитуванні CA це припущення не знайшло підтвердження, і воно саме може бути частиною проблеми.


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


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


Дослідження3 організацій, в яких оцінювалася акредитація моделі зрілості процесу розробки ПЗ (Capability Maturity Model, CMM), показало, що приблизно в половині з цих 586 організацій працює менше 100 розробників, і майже в чверті з них працює менше 50 розробників, таким чином акредитація моделі CMM і взагалі приділення великої уваги методології управління змінами властиві не тільки організаціям з дуже великими групами розробників (більш докладно модель CMM обговорюється далі в цьому документі).


Направляється процесом управління змінами


В опитуванні компанії CA про управління змінами майже половина респондентів повідомила про використання інструментів управління змінами; проте вони використовували різні інструменти, при цьому багато респондентів використовували інструменти власної розробки.


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


Багато респондентів використовували інструменти або методи управління змінами, але не були задоволені своїм управлінням змінами. Ймовірно, у них були справжні причини для занепокоєння (код надходить у виробництво без належного тестування / твердження, і процеси зміни не є повторюваними). Чи означає це, що інструменти управління змінами не працюють? Ймовірно, немає. Відповідь на питання слід шукати у видах інструментів, що використовуються респондентами.


Для різних людей управління змінами та інструменти управління змінами можуть мати різне значення. Фактично існує три рівні інструментів управління змінами:



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


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


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


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


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


Методології розробки


Існує ряд методологій і акредитацій, які пропонують архітектуру для забезпечення якості в життєвому циклі розробки програми. Методології, включаючи модель CMM і стандарт Міжнародної організації по стандартизації ISO 9000, підкреслюють важливість чітко регламентованих процесів.


Аналогічно стандарти управління сервісом, наприклад, бібліотека інфраструктури інформаційних технологій (ITIL), вимагають використовувати кероване процесом управління змінами в рамках забезпечення кращих практичних методів сервісу.


Модель зрілості процесу розробки ПО


Модель зрілості процесу розробки ПЗ (CMM)4, Розроблена Інститутом програмної інженерії в університеті Carnegie Mellon, пропонує п’ять рівнів зрілості. Вона допомагає організаціям підвищити зрілість своїх процесів розробки ПО, і організації можуть бути оцінені та акредитовані відповідно до цими рівнями.



















Рівень 1 – початковий рівень Процес розробки ПЗ спонтанний, і регламентовані лише деякі процеси. Успіх розробки може залежати від окремих співробітників.
Рівень 2 – рівень повторюваності Створені основні процеси управління проектами для відстеження витрат, календарного плану і функціональних можливостей.
Рівень 3 – рівень регламентується Процес розробки ПЗ документований, стандартизований і інтегрований зі стандартним процесом розробки ПО організації як для операцій управління, так і для операцій розробки. У всіх проектах використовується стандартизований процес.
Рівень 4 – рівень керованості Проводиться збір докладних показників процесу розробки ПЗ та якості продукту, що дозволяє зрозуміти процес і продукти і керувати ними.
Рівень 5 – рівень оптимізується Безперервна оптимізація процесу забезпечується кількісної зворотним зв’язком від процесу і від пілотних інноваційних ідей і технологій.

У 1999 році дослідження 734 організацій5, Що оцінюються відповідно до моделі CMM, показало, що більшість організацій знаходиться на початковому рівні (43%) або рівні повторюваності (34%). Це підтверджує дані опитування компанії CA про управління змінами, згідно з яким процеси управління змінами можуть бути поліпшені в більшості організацій.


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


Підвищення якості і швидкості розробки


Якщо кероване процесом управління змінами дозволяє забезпечити послідовне дотримання низки заходів щодо забезпечення якості, і використання інструментів управління змінами регламентує цю передумову, сповільнюється при цьому робота програмістів, що прагнуть максимально прискорити запуск програмного забезпечення у виробництво?


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


Якість розробки


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


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


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


Швидкість розробки


Кероване процесом управління змінами дозволяє підвищити швидкість розробки ПО двома способами:


По-перше, процеси зміни виконуються більш ефективно, тому час проекту, витрачений на управління змінами, скорочується.


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


Ефективність процесу зміни


Дослідження, проведене CA6, Виявило ряд витрат на управління змінами, де відсутній ефективний підхід до керованого процесом управління змінами.



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


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


Дослідження показало, що ефективне рішення для керованого процесом управління змінами дозволяє знизити витрати за проектом на 30 і більше процентов6. У наступній таблиці показано, як можна скоротити частку витрат на операції управління змінами в загальних витратах по проекту за допомогою AllFusion Harvest Change Manager.
















































Завдання управління змінами Операції % Витрат за проектом
Доступ до програмного забезпечення та отримання ПО Управління різними версіями компонента ПЗ, співробітниками, які мають доступ до певних компонентів, і способами доступу 3%
Синхронізація змін у середовищі розробок Управління паралельної і спільною розробкою, що забезпечує синхронізацію всіх активних компонентів 10%
Міграція змін Управління як прямий, так і зворотного міграцією змін в життєвому циклі 6%
Управління процесом компіляції і збірки Виконувані файли або завантажувальні модулі, створені шляхом складання і зв’язування вихідних компонентів; визначення підсумкового впливу, що чиниться на кілька виконуваних файлів при зміні джерела 5%
Управління поширенням змін Підготовка додатки до генерації стрічки (tape generation) або електронною передачі і відстеження версій програми, що використовуються певними співробітниками 3%
Утвердження і дозвіл Отримання тверджень і / або письмових дозволів, наприклад, перед такими операціями, як міграція, розповсюдження 2%
Управління запитами на зміну програмного забезпечення Відстеження просування запитів на зміну 2%
Координування комунікації для узгодженості розробки та операцій Забезпечення інформаційного потоку, особливо між географічно розподіленими групами і в якості підходів до впровадження 4%
Отримання інформації про статус проекту Отримання інформації для відстеження статусу та звіту про статус 3%
Відстеження помилок і їх виправлень Управління інформацією, що надходить від групи тестування, аналітиків та персоналу центру підтримки і для них 2%

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


Скорочення числа дефектів


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


Численні дослідження показали, що в організаціях, що впровадили поліпшення процесу розробки ПО на основі моделі CMM, знизилося число дефектів, і підвищилася загальна продуктивність.


Докладне дослідження7 13 організацій, що впровадили у себе поліпшення процесу розробки ПО на основі моделі CMM, показало середньорічне зниження числа дефектів після випуску ПО на 39% (підвищення якості), середньорічне скорочення часу до появи продукту на ринку на 19% і середнє підвищення продуктивності на 35%.


Інше дослідження8, В якому взяли участь 807 організацій, що впровадили модель CMM, показало, що при переході організації з одного рівня моделі CMM на інший спостерігається зниження числа дефектів і підвищення продуктивності. Дослідження показало зниження числа дефектів на 50% при переході з першого на другий рівень моделі CMM (управління проектами функціонує) і ще на 20% при переході на третій рівень (процеси зміни регламентовані і функціонують). Аналогічно продуктивність підвищилася на 30% при переході з першого на другий рівень моделі CMM і ще на 20% при переході на третій рівень.


Дотримання графіка робіт


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


Продемонстрована точність графіка робіт за проектом дозволяє організаціям-розробникам ПО отримати конкурентну перевагу, а також більше довіряти своїм групам розробників.


AllFusion Change and Configuration Management


Рішення для управління змінами AllFusion компанії CA – це інструменти керованого процесом управління змінами, інтегруючі управління змінами з процесом розробки.


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


Управління змінами AllFusion (ca.com / allfusion /) пропонує інструменти для мейнфреймів, розподілених та гетерогенних середовищ розробки додатків, і складається з наступних програмних продуктів:



У наборі програм AllFusion Change Management Suite є ряд додаткових інструментів для:



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


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


Коли поставлена ​​мета підвищити якість і швидкість розробки ПЗ, дуже важливо, щоб інструменти управління змінами були повністю інтегровані з процесом (всі функції управління змінами в одному інструменті), а не розташовувалися поверх цього процесу. AllFusion – це комплексне, повністю інтегроване рішення, також пропонує інтеграцію з багатьма популярними інструментами розробки, включаючи WebSphere Studio і Visual Studio .NET. Крім того, інструменти Unicenter ServicePlus Service Desk і Unicenter Software Delivery компанії CA дозволяють інтегрувати управління змінами з більш широким корпоративним системним адмініструванням, пропонуючи комплексне і повне управління життєвим циклом продукту.


Контролюючи складність процесу розробки шляхом управління змінами і спрощення процесу зміни, рішення для управління змінами AllFusion підвищують ефективність ІТ та максимально збільшують цінність бізнесу.


Висновок


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


До кращих практичним методам управління змінами (містяться в таких методологіях, як CMM та ISO) відноситься управління процесами розробки ПЗ, що дозволяє послідовно дотримуватися відповідних процедури, перевірки та баланси.


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


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


У короткостроковій перспективі підхід до змін, що інтегрується з процесом розробки та автоматизує завдання по зміні, дозволяє скоротити час на управління змінами. Оскільки інструменти керованого процесом управління змінами, наприклад AllFusion Change Management Suite компанії CA, інтегруються з процесом розробки, а не знаходяться поверх нього як окремі операції, вони дозволяють знизити витрати на розробку і, тому, підвищують швидкість і якість розробки як в короткостроковій, так і в довгостроковій перспективі.


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


Примітки


1 Computer Associates, Industry Survey-Change Management (Опитування про управління змінами), жовтень 2002 року.
2 Standish Group, The Chaos Report (Дослідження “Хаос”), 2002 рік.
3 Mark C. Paulk, Charles V. Webber, Bill Curtis and Mary Beth Chrissis, The Capability Maturity Model: Guidelines for Improving the Software Process (Модель зрілості процесу розробки програмного забезпечення: рекомендації щодо поліпшення процесу розробки програмного забезпечення), 1995 рік.
4 Інститут програмної інженерії, Університет Carnegie Mellon, Process Maturity Profile of the Software Community 1999 Update (Профіль зрілості процесу за версією спільноти програмного забезпечення 1999 р. (нова редакція)), серпень 1999 року.
5 Інститут програмної інженерії, Список організацій, що відповідають рівню 5.
6 Computer Associates, Контролінг витрат на розробку додатків за допомогою управління змінами і конфігурацією, 2003 рік.
7 Computer Associates, Контролінг витрат на розробку додатків за допомогою управління змінами і конфігурацією, 2003 рік.
8 James Herbsleb, Anita Carleton, and others, Benefits of a CMM-Based Software Process Improvement: Initial Results, Software Engineering Institute (Переваги поліпшення процесу розробки ПО на основі моделі CMM: початкові результати, Інститут програмної інженерії), серпень 1994 року.


Додаткова інформація



Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*