Використання інструментів IBM Rational / Telelogic в рамках управління життєвим циклом розробки додатків, Комерція, Різне, статті

Введення


З точки зору компанії IBM Rational / Telelogic, спільне використання таких процесів як управління життєвим циклом додатків (Application Lifecycle Management, ALM) і розробка на основі моделей (Model-Driven Development, MDD) грає істотну роль в поліпшенні керівництва розробками, в дотриманні нормативів і правил, а також спрощення звітності в розробляє компанії.


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


Нас часто запитують, чи дійсно ми й самі користуємося тими ж інструментами, в корисності яких переконуємо інших?


Іншими словами, – наша точка зору про корисність інструментів – це всього лише рекламний хід чи ми дійсно “їмо з вами з однієї миски»?


Цей документ детально описує систему інтегрованих процесів ALM і MDD, а також використовувані технології та інструменти компанії IBM Rational / Telelogic, які застосовуються виробничої лабораторією Таї в рамках управління життєвим циклом розробки додатків для створення, збирання та випуску програмних засобів сімейства IBM Rational / Telelogic Tau.


Практика застосування MDD і ALM в компанії IBM Rational / Telelogic


Виробнича лабораторія Таu


Виробнича лабораторія Таu відповідає за розробку і підтримку цілого списку різних програмних засобів, включаючи:


•     IBM Rational / Telelogic Tau


•     IBM Rational / Telelogic Modeler


•     IBM Rational / Telelogic SDL Suite


•     IBM Rational / Telelogic TTCN Suite


•     IBM Rational / Telelogic Tester


•     IBM Rational / Telelogic DOORS®/Analyst


•     IBM Rational / Telelogic System Architect UML2 Editing Service


•     IBM Rational / Telelogic Licensing Common Component


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


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


Рис. 1. Територіальний розподіл виробничої лабораторії Таї


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


Процес розробки


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


Рис. 2. Схема процесу розробки


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


З деякою періодичністю ці планові процеси перериваються аварійним випуском “латок” (patches), які необхідні для вирішення виниклих у замовників серйозних або термінових проблем. Для роботи над цими несподівано виникаючими проблемами спеціально зарезервовано деякий час, оскільки підтримка замовників є для нас першорядна важливість.


Процес збору та селекції вимог в загальних рисах відображений на рис. 3. Вимоги різного роду збираються з багатьох джерел, аналізуються, пріорітезіруются і, нарешті, нормалізуються у вигляді списку користувацьких вимог (User Requirements Document, URD).


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


Рис. 3. Збір та селекція вимог


Після закінчення робіт над URD починається процес формування релізів. Крім менеджера по продукту, в цьому процесі беруть участь керівник проекту і архітектори. На цьому етапі первинні побажання до продукту перетворюються вже в конкретний план, детально розписує, що повинно входити в даний реліз і яким чином це буде виконуватися. Ця частина процесу зображена на рис. 4. Основним результатом цього етапу є список системних вимог (System Requirements Document, SRD).


Рис. 4. Визначення вимог


Далі SRD використовується вже як набір вхідних даних для фактичної розробки, в процесі якої плани перетворюються в закінчений продукт – новий реліз Таu. Процес випуску релізу зображений на рис. 5.


Рис. 5. Випуск релізу


Слід зауважити, що процес розробки, побудови та тестування Таu відбувається безперервно. Як тільки закінчується одна ітерація збірки, тут же починається інша, і при цьому постійно ведеться тестування продукту, щоб виключити будь-які помилки.


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


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


Процес селекції вимог


Частина даного документа більш докладно описує призначення кожного кроку процесу розробки і пояснює як при цьому використовуються продукти компанії IBM Rational / Telelogic. Загальна схема всього процесу показана на рис. 6.


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


Рис. 6. Основний робочий процес випуску продукції


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


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


Збір вимог


Запити на поліпшення і зміна продуктів сімейства Таu приходять і формуються з різних джерел:


• Регулярні конференції провідних замовників


• Рада керівників напрямків по продуктам


• Аналіз продажів


• Конкурентна інформація


• Підрозділи підтримки замовників, повідомлення про несправності


• Потреби бізнесу


• Стратегічні комерційні вимоги


• Вимоги до технології


• Товарний маркетинг, управління продуктами


• Архітектори та розробники


• Раніше відкладені вимоги


Одним з найбільш очевидних джерел надходження нових вимог є підрозділи підтримки замовників (Customer Support). Тут всі вхідні запити розкладаються по двом “кошиках”: повідомлення про знайдені дефекти йдуть в одну корзину, а запити на поліпшення, що містять побажання про нові функції або удосконаленні вже існуючих, – в іншу.


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


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


Рада керівників напрямків по продуктам існує з тією ж метою, але його єдина відмінність лише в тому, що він є внутрішньою структурою компанії IBM Rational / Telelogic і на зустрічах ради думками обмінюється вищий керуючий персонал компанії. Робота цих двох груп забезпечує користувачам продукту Таu переважне право голосу в процесі його розробки.


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


• Взаємодія з активними фахівцями з продажу


• Аналізі тенденцій ринку


• Визначенні нових ринкових потреб


• Вивченні конкурентного середовища


• Загальних стандартах, встановлюваних різними стандартизирующими органами та державними організаціями


• Корпоративному стратегічному напрямку, визначеному виконавчим органам компанії IBM Rational / Telelogic.


Поява на ринку нових технологій, – наприклад, нової платформи Vista або нової робочої середовища Java ЇЇ 5, – часто також обертається новими вимогами до продукту.


Всі ці різного роду вимоги з будь-яких джерел збираються, фіксуються й обробляються в інструменті, який носить назву IBM Rational / TelelogicFocalPoint. Приклад вікна Focal Point для введення вимоги зображений на рис. 7.


Рис. 7. Запис вимог в Focal Point


Члени Ради керівників і менеджери по продукту Таu добре знайомі з Focal Point і широко використовують це рішення для управління продуктом і портфелем продуктів, а також для пріоритезації певних характеристик Таu і вимог до нього.


Пріоритезація функціоналу


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


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


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


Рис. 8. Попарно пріоритезація вимог в Focal Point


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


Рис. 9. Демонстрація зважених результатів пріоритезації вимог в Focal Point


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


Створення та ведення списку користувацьких вимог


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


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


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


Приклад відображення для користувача вимог до Таu для одного з конкретних релізів наведено на рис. 10.


Рис. 10. Відображення URD в DOORS


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


Процес формування релізу і проектне планування


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


Результати цих попередніх досліджень зберігаються в IBM Rational / Telelogic Synergy – системі управління конфігурацією – і автоматично реплікуються на внутрішній веб-сайт проекту (детальніше про це далі).


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


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


На рис. 11 приведена найпростіша модель, як складова частина попередніх досліджень такого роду.


Рис. 11. Моделювання в Таї для попередніх досліджень


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


Набір системних вимог, віднесених до певного релізу, утворює SRD (System Requirements Document).


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


В результаті такого мозкового штурму з’являється “підсумковий” SRD проекту. Слід зауважити, що зазвичай в подальшому процесі розробки і сам SRD зазнає змін, але даний процес управляється вже окремо. (Приклад SRD представлений на рис. 16).


Відповідно до підсумковим SRD розробляється план і графік випуску релізу (рис. 12).


Рис. 12. Графік випуску релізу


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


Рис. 13. Домашня сторінка проекту


Тепер звернімо увагу на структуру виробничої лабораторії.


Загальне уявлення про підрозділи лабораторії Таu та їх призначення можна отримати з рис. 14.


Рис. 14. Структура виробничої лабораторії Таї


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


Розробка програмного забезпечення


Розробка продукту Таu протікає в рамках технологічного процесу, який зберігається і контролюється IBM Rational / TelelogicChange– Рішенням для управління змінами, – розробленим компанією IBM Rational / Telelogic.


Відправною точкою цього процесу є формування, – виходячи із системних вимог, – запитів на зміни (Change Requests, CR), в яких формулюється і визначається що саме має бути розроблено. CR також використовується для контролю за поточним статусним станом зміни.


Найбільш важливі стану процесу управління змінами зображені на рис. 15.



Рис. 15. Процес змін


Як видно, процес складається з п’яти основних станів (статусів), властивих будь-якому запиту на змінення:


• Entered (Поступив)


• Confirmed (Підтверджено)


• Implementation (Виконується)


• Fixed (Вирішено)


• Verified (Перевірений)


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


Цей життєвий цикл управління змінами єдиний і для всіх інших виробничих лабораторій компанії IBM Rational / Telelogic, які використовують Change.


Управління дефектами


Коли з другої лінії підтримки користувачам (від інженерів, що приймають дзвінки в Центрі підтримки компанііIBM Rational / Telelogic) надходить інформація про передбачуваний дефект, то з неї відразу ж формується запит, якому тут же присвоюється статус “Вступив”.


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


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


Перед тим, як прийняти рішення про переведення CR в розряд “Виконується”, обов’язково прораховуються можливі ризики і витрати. Крім можливої ​​затримки випуску поточного релізу, до уваги береться і безліч інших факторів, які можуть впливати на це рішення, наприклад, – значимість зміни, вплив зміни на інші модулі, які теж треба буде редагувати, чи доведеться оновлювати формат зберігання даних, чи існує ймовірність втрати даних і т.д.


Тому чим ближче дата випуску поточного релізу, тим менше шансів, що CR буде в ньому реалізований. Швидше за все цей CR буде або переведений в розряд “Відкладений” і чекати свого часу, або буде реалізований тільки в наступному релізі, розробка якого зазвичай ведеться паралельно з поточним.


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


Запити на поліпшення і новий функціонал


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


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


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


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


Puc. 16. Відображення SRD в DOORS


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


Рис. 17. Відображення списку запитів в Change


І хоча наведений вище журнал (звіт) відбиває інформацію лише “верхнього” рівня, але при необхідності по кожному конкретному CR може бути отримана і більш детальна інформація, наприклад, – посилання на вихідне системне вимога, скрипт вхідного повідомлення (дзвінок, mail), коментарі про конференції користувачів і багато чого іншого (см рис. 18).


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


Puc. 18. Детальна інформація про CR “e Change


Створення завдань на розробку


Слідом за перекладом CR в статус “Виконується”, формується завдання на розробку, виконання якої перебуває під повним контролем IBM Rational / Telelogic Synergy – Рішення для управління конфігурацією.


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


Процес реалізації CR можна відстежувати в Change (див. рис. 19).


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


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


Рис. 19. Завдання в Change


Можливість працювати і відстежувати зміни вищеописаним способом значно полегшує ведення паралельної розробки. Якщо, наприклад, який-небудь CR потребує термінової виправлення цієї (patch), то для вирішення цієї проблеми менеджер збірки формує нову задачу (task),-створюючи відгалуження від основного процесу розробки, – яка потім автоматично “підтягне” в збірку всі необхідні файли.


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


В якості додаткового переваги ця технологія надає нам можливість автоматично виконувати аналіз наскрізної трасування. Якщо код знаходиться у файлі, який прив’язаний до задачі (task), а вона, в свою чергу, залінкована з CR, і при цьому CR може бути простежений до системного вимоги, яке пов’язане з призначеним для користувача вимогою (і можливо, навіть з самого початку зареєстрованим зверненням користувача по телефону в Центр підтримки), то такий ланцюжок дозволяє знайти всі артефакти, що вийшли з користувацького вимоги або запиту в процесі розробки.


Цикл розробки


Фактично, на цикл розробки припадає три стану CR:


• Implementation {Виконується), під час якого розробляються код і моделі


• FixReadyForReview (Рішення готове до розгляду), коли реалізація CR виконана і чекає перевірки і схвалення архітектора


• Fixed (Вирішено), який говорить тестувальника, що реалізація CR схвалена групою розробників і CR готовий до тестування


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


Слід зауважити, що на цих останніх стадіях розробки статус “Рішення готове до розгляду” повинен бути присутнім і використовуватися в обов’язковому порядку – CR не може з розряду “Виконується” відразу перестрибнути в розряд “Вирішено”. Такий підхід дає деяку впевненість в тому, що в останній момент нічого не буде зруйновано випадковою помилкою.


Важливим моментом є той факт, що на стадії розробки єдиний доступ до коду – як виконання поставленого завдання – можливий виключно через завдання (task) в Synergy (див. рис. 20). Як тільки виконання завдання завершується, відповідні коди фіксуються і версії файлів автоматично проходять операцію check-in, щоб потім включитися в процес наступної інтеграційної збірки.


Рис. 20. Вікно Synergy – завдання (tasks), запити (CR), проекти, файли


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


Такого роду звіти відображають повну трасування: вимоги в SRD – файли, що містять вихідні код, в який вносилися зміни, – автоматично збираються базові версії (baselines) продукту, в яких з’являється реалізоване зміна.


Puc. 21. Звіт про діяльність групи


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


Моделювання, код, специфікації


Для розробки більшості своїх продуктів виробнича лабораторія Таї використовує мову C + +. З метою забезпечення сумісності розробок з різними платформами в лабораторії прийнятий при нці п платформо-незалежного програмування. Основний використовуваної середовищем розробки є Microsoft Visual Studio 2005.


У багатьох випадках – і це особливо актуально, якщо мова йде про об’єктної моделі, – код автоматично генерується безпосередньо з UML ® за допомогою IBM Rational / TelelogicTau, до складу якого входить кодо-генератор C + +.


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


Наприклад, всі програмні інтерфейси API продукту згенеровані з UML, включаючи TCL, C + + і COM API. Крім цього, генерація коду задіюється і в тих опціях Таu, які орієнтовані на роботу з станами, наприклад, при запуску опції Model Verifier для перевірки правильності функціонування створюваної моделі.


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


Всі можливі уявлення (види) моделей в Таu, включаючи й елементи графічної нотації самого UML, створюються за допомогою UML-моделей, як це показано для одного з випадків на рис. 22.


Рис. 22. Об’єктна модель в Таї


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


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


В Таu включені і багато інших уявлення, наприклад, підтримують DoDAF, SysML або деякі інші уявлення, характерні для мови Java або різних технологій на основі XML – наприклад, схеми або мова опису Веб-сервісів (WSDL). Ці уявлення вже вбудовані в Таu, поставляються з продуктом і надалі їх можна кастомизировать для задоволення конкретних потреб користувачів.


У нашій виробничої лабораторії Таu також використовується і для візуалізації існуючого або знову створюваного коду з метою подальшого аналізу та документування. В цьому випадку проводиться реінжиніринг коду C + + і файлів Microsoft SLN, в результаті якого створюються діаграми, що відображають взаємозв’язки різного роду. На рис. 23 показано кілька діаграм, отриманих прямим реінжинірингом коду C + +.


Рис. 23. Код C + +, візуалізований у вигляді діаграми класів


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


Рис. 24. Діаграма станів


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


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


Випуск продукту, тестування, управління релізами


Збірки (builds) ведуться безперервно для всіх підтримуваних платформ, включаючи Windows, Solaris і Linux. Процес складання управляється з Synergy.


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



Puc. 25. Повідомлення про статус зборки


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


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


Puc. 26. Результати складання


В журналі збірки також міститься інформація про те, які завдання (tasks) були виконані в складі кожної конкретної збірки. Ця інформація, зокрема, вельми корисна для тестувальників, оскільки підказує їм, які функції вже готові до перевірки (див. рис. 27).


Puc. 27. Список завершених завдань конкретної збірки


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


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


Рис. 28. Результати тестування


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


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


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


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


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


Після формування фінальної версія релізу, в заздалегідь призначений день він вивантажується на Веб-сайт підтримки (https :/ / support. Telelogic. Com) і стає доступним для використання. Велика частина відносяться до релізу документів – коментарів, документації, описів вирішених проблем, можливих обмежень використання – генеруються автоматично, виходячи з даних, що зберігаються в Change.


Висновок


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


Для забезпечення необхідного рівня автоматизації розробки виробнича лабораторія Таї використовує цілий ряд рішень, що включають в себе в тому числі і продукти IBM Rational / Telelogic:


•     Таu для розробки на основі моделей, генерації коду і документації;


•     FocalPoint для управління та пріоритезації розробляється функціоналу;


•     DOORS для керування вимогами;


•     Changeдля контролю за змінами;


•     Synergy для управління конфігурацією і складанням;


•     Logiscope для дотримання стандартів якості коду, получеія метрик коду та звітності.


Спільне використання MDD (Model-Driven Development) і ALM (Application Lifecycle Management) дозволяє компанії IBM Rational / Telelogic, – підтримуючи високу продуктивність і ефективність, – розробляти та підтримувати цілу лінійку продуктів, чудово зарекомендували себе на ринку в різних індустріях.

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


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

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

Ваш отзыв

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

*

*