Розробка вимог: уроки офшорного аутсорсингу

1. Розробка вимог - найбільш важлива стадія програмного проекту [2, 3], від її результатів багато в чому...
2. Специфіка розробки вимог в умовах офшорного аутсорсингу
3. конкретні приклади
4. Приклад 1. Протиріччя цілей замовника і підрядника
5. Приклад 2. Недостатня залученість замовника
6. Приклад 3. Суперечливі підходи до розробки вимог
7. Приклад 4. Погана ув'язка зобов'язань замовника з цілями проекту
8. Приклад 5. Розбіжності при виборі інструментальних засобів
9. Приклад 6. Проблеми комунікації
10. Приклад 7. Відмова від відповідальності
11. Приклад 8. Проблеми візування
12. Приклад 9. Інструменти, що не виправдали очікувань
13. Стратегічні фактори успіху
14. Класифікація передових методів
15. ЛІТЕРАТУРА

21.09.2006 Джіоті ​​Бхат, Мейанк Гупта, Сантос Мерфі

Розробка вимог - найбільш важлива стадія програмного проекту [2, 3], від її результатів багато в чому залежить успіх проекту в цілому.

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

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

Специфіка розробки вимог в умовах офшорного аутсорсингу

Схема на рис. 1 представляє типових учасників програмного проекту при аутсорсингу. Ми використовуємо її для опису чотири характерні особливості такого проекту в умовах офшорного аутсорсингу і їх впливу на розробку вимог.

Перша особливість полягає в тому, що підрядник зазвичай має справу з двома групами учасників в організації замовника: ІТ-відділ і бізнес-спільнота (менеджери і користувачі). Аналогічним чином замовник змушений мати справу з двома групами в організації підрядника - місцевою групою координації і офшорної групою розробників. Такий стан справ, як правило, веде до роз'єднаності між групами, які приймають рішення і виконують проект (зазвичай офшорними), і групою, яка знає потреби замовника (зазвичай місцевої). Взаємодіями між джерелом вимог (бізнес-спільнота) і постачальником рішень (підрядник) керують кілька груп. Ця обставина впливає на розробку вимог за трьома напрямками. Необхідний більш строгий процес управління змінами вимог (що збільшує непродуктивні витрати), оскільки зростає число проміжних ланок при передачі інформації і посилюється роз'єднаність між особами, що приймають рішення. Найменший відступ від цього процесу може зруйнувати єдине розуміння змін у вимогах. Сповільнюється також обговорення вимог між замовником і підрядником внаслідок постійного переміщення інформації з одного офісу в інший. Нарешті, виникає безліч ступенів формального поділу між учасниками, що знаходяться на одному і тому ж рівні організаційної відповідальності. Це може привести до зміщеним і неповним уявленням, які зменшують прозорість при зборі, обговоренні та затвердженні вимог.

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

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

Четверта особливість - комплектування робочих груп замовника і підрядника спеціально для даного проекту, що веде до численних переходах співробітників з одного підрозділу в інший [10].

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

конкретні приклади

Розберемо декілька ситуацій з довільно обраних проектів, щоб докладніше проілюструвати порушені проблеми.

Приклад 1. Протиріччя цілей замовника і підрядника

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

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

Приклад 2. Недостатня залученість замовника

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

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

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

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

Приклад 3. Суперечливі підходи до розробки вимог

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

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

Приклад 4. Погана ув'язка зобов'язань замовника з цілями проекту

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

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

Приклад 5. Розбіжності при виборі інструментальних засобів

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

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

Приклад 6. Проблеми комунікації

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

Приклад 7. Відмова від відповідальності

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

Приклад 8. Проблеми візування

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

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

Приклад 9. Інструменти, що не виправдали очікувань

Офшорна група експертів з розробки вимог була не в змозі допомогти своїй місцевій групі через неправильне вибору інструменту. Місцева група розробки вимог хотіла скористатися перевагами цілодобового робочого циклу (follow the sun model of working) і запросила у офшорних експертів макети екранів, засновані на документації за вимогами на базі сценаріїв використання. У надії на швидку оборотність вони збиралися щодня обмінюватися сценаріями використання і відповідними макетами екранів. Однак, на їхнє здивування, в першому циклі витрати часу у офшорній групи виявилися майже в три рази більше очікуваних. Провівши аналіз, ми зрозуміли, що офшорна група використовувала спеціалізований інструмент, який давав якісні результати і вимагав великих зусиль, тоді як місцева група хотіла отримати лише грубий ескіз для обговорення і узгодження вимог з бізнес-користувачами замовника.

Стратегічні фактори успіху

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

Простий аналіз першопричин (root-cause analysis) в цих дев'яти прикладах дозволяє виявити ключові стратегічні фактори успішної розробки вимог при аутсорсингу.

Загальні цілі. Аналіз першопричин в прикладах 1 і 9 показує, що продуктивність розробки вимог падає, якщо учасники не прагнуть до спільної мети. Як зазначається в роботі [10], справжнє співробітництво, що передбачає взаємну відповідальність і узгодженість зусиль, вимагає спільного бачення. У реченні авторів [11] з управління конфліктами і погодженням точок зору їх учасників також підкреслюється важливість спільної мети.

Загальна культура. Культура відіграє важливу роль в успіху будь-якої колективної діяльності. Аналіз прикладу 2 демонструє брак культурної спільності між учасниками проекту. В основній роботі [8] ідентифікуються ключові чинники, що обумовлюють культурні відмінності між індивідуумами. Останні дослідження [4,5,12] зачіпають культурні норми, цінності, мову і неявне знання, які також впливають на поведінку учасників.

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

Загальна відповідальність. Розробка вимог - найбільш заплутана частина процесу розробки ПО, кожен з етапів якої, будь то планування, збір вихідних даних, документування, аналіз, обговорення, узгодження або перевірка, залежить від безлічі радикально несхожих зацікавлених осіб. При розробці вимог в кожному акті взаємодії між замовником і підрядником розподіл відповідальності відбувається по-своєму. Приклади 4 і 7 показують недолік загальної відповідальності як першопричину всіх проблем. Цей висновок знаходиться в згоді з іншими дослідженнями [5, 13].

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

Класифікація передових методів

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

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

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

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

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

ЛІТЕРАТУРА

1. P. Iyengar, Application Development Is More Global than Ever, publication G00124025, Gartner, 2004; www.gartner.com/resources/124000/124025/application_dev.pdf .
2. I. Sommerville, G. Kotonya, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 1998..
3. L. Maciaszek, Requirements Analysis and Systems Design: Developing Information Systems with UML, Addison-Wesley, 2001..
4. DE Damian, D. Zowghi, The Impact of Stakeholders 'Geographical Distribution on Managing Requirements in a Multi-site Organization, Proc. 10th Anniversary IEEE Joint Int'l Conf. Requirements Eng. (RE 02), IEEE CS Press, 2002.
5. J. Hanisch, BJ Corbitt, Requirements Engineering during Global Software Development: Some Impediments to the Requirements Engineering Process: A Case Study, Proc. 12th European Conf. Information Systems (ECIS 04), 2004.
6. L. Lopes et al., Requirements Specification in Distributed Software Development - A Process Proposal, Proc. 38th Hawaii Int'l Conf. System Sciences (HICSS 05), IEEE CS Press, 2005f.
7. H. Edwards, V. Sindhar, Analysis of Software Requirements Engineering Exercises in a Global Virtual Team Setup, "J. Global Information Management, vol. 13, no. 2, 2005.
8. G. Hofstede, Cultures and Organization: Software of the Mind, McGraw-Hill, 1991.
9. E. Carmel, Global Software Teams, Prentice Hall, 1999..
10. G. Pare, L. Dube, Virtual Teams: An Exploratory Study of Key Challenges and Strategies, Proc. 20th Int'l Conf. Information Systems (ICIS 99), ACM Press, 1999..
11. P. Darke, G. Shanks, Stakeholder Viewpoints in Requirements Definition: A Framework for Understanding Viewpoint Development Approaches, Requirements Eng., Vol 1, 1996..
12. R. Prikladnicki et al., Requirements Management in Global Software Development: Preliminary Findings from a Case Study in a SWCMM Context, Proc. 2nd Int'l Workshop Global Software Development, IEEE CS Press, 2003.
13. D. Damian et al., "Requirements Meets Awareness: Awareness Needs in GSD," Proc. 2nd Int'l Workshop Global Software Development, IEEE CS Press, 2003.
14. L. Dube and G. Pare, "Global Virtual Teams," Comm. ACM, vol. 44, no. 12, 2001..
15. JA Hrones, Jr., BC Jedrey, Jr., D. Zaaf, Defining Global Requirements with Distributed QFD, ACM Trans., Vol. 5, no. 4, 1993.
16. D. Damian and Eberlein, "The Effects of Communication Media on Group Performance in RE," Proc. 4th Int'l Conf. Requirements Eng. (ICRE 00), IEEE CS Press, 2000..

Джіоті ​​Бхат ( [email protected] ) - фахівець з управління бізнес-процесами в лабораторії Infosys Software Engineering and Technology Labs. Мейанк Гупта ( [email protected] ) - головний архітектор компанії Infosys Technologies, фахівець з інженерних питань та управління бізнесом. Сантос Мерфі ( [email protected] ) - консультант групи InFlux Business Process Consulting в лабораторії Infosys Software Engineering and Technology Labs.

JM Bhat, M. Gupta, SN Murthy, Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing, IEEE Software, Sept / Oct 2006. IEEE Computer Society, 2006, All rights reserved. Reprinted with permission.