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

Життєвий цикл розробки додатків: мрії та реальність

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

Чим же зумовлено недовіру багатьох керівників проектів до інструментів, що дозволяє автоматизувати багато етапів роботи очолюваних ними колективів? На мою думку, тому є кілька причин. Перша їх у тому, що часто застосовувані компанією кошти погано інтегруються між собою. Розглянемо типовий приклад: для моделювання застосовується Rational Rose, для написання коду – Delphi Professional, для проектування даних – CA AllFusion Modelling Suite; засоби інтеграції цих продуктів або взагалі відсутні для цієї комбінації їх версій, або некоректно працюють з російською мовою, або просто не придбані. А в результаті діаграми прецедентів та інші моделі, створені за допомогою Rose, стають не більше ніж картинками у проектній документації, а модель даних головним чином є джерелом відповіді на запитання типу: «Навіщо це поле взагалі потрібне в тій таблиці?» І навіть такі прості частини програми, як російські еквіваленти імен полів бази даних, пишуться учасниками проекту як мінімум три рази: один раз - при документуванні моделі даних або програми, другий раз - при написанні коду інтерфейсу користувача, а третій - при створенні файлу довідкової системи та керівництва користувача.

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

Третя причина, чому засоби підтримки життєвого циклу програмного забезпечення застосовуються далеко не скрізь, де вони могли б принести користь, полягає в крайній обмеженості їх вибору. На російському ринку активно просуваються головним чином дві лінійки продуктів: інструменти IBM/Rational та інструменти Computer Associates (головним чином лінійка продуктів AllFusion Modelling Suite), багато в чому орієнтовані на певні види моделювання, а не на постійний процес синхронізації коду, бази даних та моделей.

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

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

1. Засоби управління вимогами повинні спростити створення моделі програми та моделі даних.

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

3. Значна частина документації повинна генеруватися автоматично, причому мовою тієї країни, для якої призначено цю програму.

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

5. Код, написаний вручну, не повинен зникати при зміні моделі.

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

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

8. І нарешті, всі ці дані (вимоги, код, моделі, документація) мають бути доступні учасникам проекту саме в тій мірі, якою вони необхідні їм для виконання своїх обов'язків - не більше і не менше.

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

Не запевняю вас, що всі ці побажання абсолютно неможливо здійснити за допомогою інструментів IBM/Rational або CA - технології розвиваються, з'являються нові продукти, і те, що було неможливо сьогодні, стане доступним завтра. Але, як показує практика, інтеграція цих інструментів з найбільш популярними засобами розробки, на жаль, поки що далеко не така ідеальна, як могло б здатися на перший погляд.

Продукти Borland з погляду керівника проекту

Компанія Borland є одним з найпопулярніших виробників засобів розробки: вже двадцять років її продукти користуються заслуженою любов'ю розробників. Донедавна ця компанія пропонувала головним чином широкий спектр засобів, призначених безпосередньо для творців коду додатків - Delphi, JBuilder, C++Builder, Kylix (про всі ці продукти ми неодноразово писали в нашому журналі). Однак успіх компанії на ринку багато в чому визначається тим, наскільки вона слідує тенденціям його розвитку і наскільки розуміє потреби тих, хто є споживачем її продукції (в даному випадку - компаній та відділів, що спеціалізуються на розробці додатків).

Саме тому в даний час стратегія розвитку засобів розробки Borland передбачає підтримку повного життєвого циклу додатків (Application Lifecycle Management, ALM), що включає визначення вимог, проектування, розробку, тестування, впровадження та супровід додатків. Про це свідчить торішнє придбання корпорацією Borland низки компаній - BoldSoft MDE Aktiebolag (провідного постачальника новітньої технології розробки програм Model Driven Architecture), Starbase (постачальника засобів конфігураційного управління програмними проектами), TogetherSoft Corporation (постачальника рішень у галузі проектування програмного забезпечення). За час, що минув з придбання цих підприємств, було зроблено багато роботи, у плані інтеграції цих товарів між собою. У результаті ці продукти вже задовольняють потреби керівників проектів, пов'язаних із можливістю організації ітеративної колективної розробки. Нижче ми обговоримо, що саме пропонує зараз компанія Borland керівникам та іншим учасникам проектів, пов'язаних з розробкою програмного забезпечення (багато з описаних нижче продуктів та технологій інтеграції були представлені цією компанією на конференціях, що відбулися в листопаді, для розробників у Сан-Хосі, Амстердамі та Москві) .

Управління вимогами

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

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

Для управління вимогами в арсеналі Borland є продукт Borland CaliberRM, що по суті є платформою для автоматизації процесу управління вимогами, що надає засоби відстеження змін (мал. 2).

CaliberRM інтегрується з багатьма засобами розробки виробництва як Borland, так і інших виробників (наприклад, Microsoft), аж до вбудовування списку вимог у середу розробки та генерації заготовок коду при перенесенні мишею піктограми вимоги до редактора коду. Крім того, на його основі можна створювати власні рішення – для цього існує спеціальний набір інструментів CaliberRM SDK.

Зазначимо, що цей продукт застосовується для керування вимогами не лише до програмного забезпечення, а й до інших продуктів. Так, відомі випадки його успішного застосування в автомобільній промисловості для управління вимогами до різних вузлів автомобілів (зокрема автомобілів «ягуар»). Крім того, за переконанням Джона Харрісона (Jon Harrison), менеджера, який відповідає за лінійку продуктів JBuilder, застосування CaliberRM при створенні Borland JBuilderX значно спростило процес розробки цього продукту.

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

Проектування додатків та даних

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

Для проектування додатків та даних компанією Borland пропонується продукт Borland Together (рис. 3), що є платформою для аналізу та проектування додатків, що інтегрується з різними засобами розробки як компанії Borland, так і інших виробників (зокрема, Microsoft). Зазначений продукт дозволяє здійснювати моделювання та проектування додатків та даних; при цьому ступінь його інтеграції із засобами розробки на даний момент така, що зміни моделі даних призводять до автоматичної зміни коду програми, так само як зміни в коді призводять до зміни в моделях (дана технологія інтеграції інструментів моделювання та засобів розробки отримала назву LiveSource).

Borland Together може застосовуватися як засіб, що поєднує завдання, пов'язані з керуванням вимогами та моделюванням, із завданнями, пов'язаними з розробкою та тестуванням, і дозволяє зрозуміти, у чому повинна полягати реалізація вимог до продукту.

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

Створення коду програми — область, де компанія Borland спеціалізується протягом усіх 20 років свого існування. Сьогодні Borland виробляє засоби розробки для платформ Windows, Linux, Solaris, Microsoft .NET, а також для мобільних платформ. Ми вже неодноразово писали про засоби розробки цієї компанії, і в цій статті не будемо повторюватися. Зазначимо лише, що останні версії засобів розробки цієї компанії (Borland C#Builder, Borland C++BuilderX, Borland JBuilderX), а також очікувана невдовзі нова версія одного з найпопулярніших у нашій країні засобів розробки, Borland Delphi 8 для Microsoft .NET Framework , дозволяють здійснити тісну інтеграцію засобів моделювання Together та засобів управління вимогами CaliberRM зі своїми середовищами розробки. Про Delphi 8 ми обов'язково розповімо в окремій статті у наступному номері нашого журналу.

Тестування та оптимізація

Тестування – абсолютно необхідна складова створення якісного програмного забезпечення. Саме на цьому етапі перевіряється, чи задовольняє додаток сформульованим вимогам до нього, а код програми (а нерідко і в моделі, і в бази даних) вносяться відповідні зміни. На етапі тестування зазвичай потрібне застосування засобів аналізу та оптимізації продуктивності додатків, і для цієї мети застосовується Borland Optimizeit Profiler. Сьогодні цей продукт поряд з цим інтегрується в середу розробки останніх версій засобів розробки Borland, а також серед Microsoft Visual Studio .NET (рис. 4).

Впровадження

Впровадження програмного забезпечення - одна з найважливіших складових успіху проекту. Воно має здійснюватися таким чином, щоб на етапі дослідної експлуатації продукту в нього можна було вносити зміни без серйозних витрат та втрат, легко збільшувати кількість користувачів без зниження надійності. Оскільки в даний час впровадження додатків відбувається в умовах застосування компаніями різних технологій і платформ та експлуатації певної кількості наявних додатків, при впровадженні може виявитися важливою здатність здійснення інтеграції нового додатка з успадкованими системами. Для цієї мети компанією Borland пропонується ряд технологій міжплатформної інтеграції (таких як Borland Janeva, що дозволяють здійснити інтеграцію.NET-додатків з програмами, що базуються на технологіях CORBA та J2EE).

Управління змінами

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

Для вирішення цього завдання можна застосовувати Borland StarTeam (рис. 5) — масштабований засіб управління конфігураціями програмного забезпечення, яке зберігає в централізованому репозитарії всі необхідні дані та оптимізує взаємодію співробітників, відповідальних за виконання різних завдань. Цей продукт надає команді учасників проекту різноманітні засоби для публікації вимог, управління завданнями, планування, роботи, обговорення змін, контролю версій, організації документообігу.

Особливостями даного продукту є тісна інтеграція з іншими продуктами Borland, підтримка розподілених команд розробників, що взаємодіють через Інтернет, наявність кількох типів клієнтських інтерфейсів (у тому числі Web-інтерфейсу та Windows-інтерфейсу), підтримка багатьох платформ та операційних систем, наявність StarTeam Software Development Kit (SDK), що представляє собою прикладні програмні інтерфейси для створення рішень на базі StarTeam, засоби захисту даних на стороні клієнта та сервера, засоби доступу до репозитарій Merant PVCS Version Manager і Microsoft Visual SourceSafe, засоби інтеграції з Microsoft Project, засоби візуального представлення даних, створення звітів та підтримки прийняття рішень.

Замість ув'язнення

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

Управління життєвим циклом програм (Application Lifecycle Management, ALM) швидко розвивається. Це перспективний підхід до поліпшення процесу створення програмного забезпечення (ПЗ). Однак "традиційний" процес ALM не здатний повністю розкрити свій потенціал у отриманні прибутку для організації. Чому? Тому що виробники агресивно проштовхують на ринок обмежені наскрізні рішення для ALM, які мають на меті прив'язати замовників до закритих технологічних платформ. Незабаром клієнти виявляють, що ці рішення не інтегруються з існуючими процесами, засобами і платформами для розробки. На жаль, це залишає колективи розробників наодинці з розрізненими процесами та мішаниною даних ALM, що у свою чергу не дає їм повністю реалізувати можливості ALM.

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

Передбачувана розробка ПЗ: місія нездійсненна?

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

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

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

1 Такі основні тенденції у галузі, як прискорене впровадження середовища покращення процесів CMM/CMMI та розширення використання моделей розробки із залученням сторонніх ресурсів, тісно пов'язані з цим очевидним перетворенням галузі розробки ПЗ.

Поява ALM

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

Вимірюваність	Можливість визначення систем заходів для оцінки якості, продуктивності, прогресу та ризику.
	Аналіз цих метрик та створення звітів у процесі виконання проекту.
Узгодження	Узгодження бізнес-спеціалізації та пріоритетів у галузі ІТ.
	Узгодження результатів проекту з очікуваннями кінцевих користувачів.
Дисципліна	Відповідність визначення, розгортання та відстеження програмним процесам.
	Підвищення суворості процесу змін в управлінні та прогнозування їх наслідків.

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

Промисловість ALM

Спочатку одними з небагатьох новаторів, які зрозуміли важливість тенденції до ALM та змінили свої стратегії випуску продуктів у бік явної її підтримки, були Borlandі IBM Rational. Відреагувавши на очевидні можливості, до концепції ALM, що перемогла, приєдналися й інші компанії: Microsoft, IBM Rational / Telelogic, Mercury і Serena. Сьогодні ALM - це тенденція і зростаюча індустрія, визнана аналітиками. Виробники рішень ALM надають різні засоби та технології для підтримки процесу розробки ПЗ. Ці засоби виходять далеко за межі традиційних інструментів для підвищення продуктивності окремого розробника. Вони спрямовані на надання методик та інструментів, орієнтованих на колективну роботу зі створення ПЗ. Щоб створити життєздатне рішення для ALM, виробники повинні враховувати потреби "розширеної" групи розробників ПЗ та включати у свої продукти ролі, які беруть участь у більш широкому процесі.

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

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

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

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

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

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

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

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

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

Технологія ALM, за загальним визнанням, стала великим кроком у розвитку індустрії засобів розробки додатків та її замовників. Цікаво, що останній звіт "Chaos report" від Standish Group показує, що рівень невдало завершених проектів створення ПЗ за минуле десятиліття знизився вдвічі. Це поліпшення можна віднести частково і на рахунок ALM. Проте глибше дослідження потреб замовників показує, що, незважаючи на очевидні переваги ALM, повний потенціал цієї технології реалізувати, як і раніше, важко. Для цього необхідно змінити фундаментальний підхід, який використовується для інтеграції процесів та засобів, задіяних у життєвому циклі ПЗ.

Потенціал ALM для бізнесу переважно не реалізований

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

Корпоративне середовище ІТ: проблема гетерогенності

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

Міграція з монолітних спеціалізованих програм, що працюють на мейнфреймах, на нові засоби розробки для корпоративних розподілених платформ, а саме J2EE та .NET.

Міграція з пакетованих корпоративних програм, створених на базі застарілих архітектур, до таких середовищ виконання процесів та композитних програм, як SAP NetWeaver і Oracle Fusion.

Використання для певних потреб спеціалізованих платформ. Це, наприклад, мови сценаріїв для веб-додатків з використанням баз даних (PHP, Ruby тощо), або платформи для розробки програм з різноманітними функціями роботи з Інтернетом та мультимедіа (наприклад, Adobe® Flash®/Flex™).

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

Буде розумно припустити, особливо щодо корпорацій середнього та великого розміру, що в найближчому майбутньому кожне корпоративне ІТ-середовище буде включати хоча б три з перерахованих платформ для розгортання: мейнфрейм, розподілене середовище (J2EE або .NET) і система для автоматизації бізнес -процесів (SAP чи Oracle). Також схоже (і це стає все очевиднішим), що деякі організації розгортають ПЗ і на платформу J2EE, і на .NET. 2

Конфліктуючі програми

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

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

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

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

o Гібриди J2EE/.NET, які використовують можливості та інтерфейс користувача.NET на стороні клієнта. На стороні сервера вони використовують масштабованість, керованість та безпеку технології J2EE. Цей архітектурний шаблон особливо часто зустрічається у фінансовій вертикалі. Він використовується для високопродуктивних торгових платформ, оскільки на Уолл-Стріт Windows це стандарт де-факто для настільних комп'ютерів.

o Гібриди Flash/J2EE. Вони об'єднують можливості Adobe Flash як платформу для потокового відео та багатофункціональних Інтернет-додатків з перевагами технології J2EE для серверів. Це дозволяє досягати високого ступеня масштабованості та реалізувати інтерфейс із широкими можливостями роботи з мультимедіа.

Скорочення витрат за розробку. Організації намагаються знизити витрати на розробку ПЗ та його розгортання, комбінуючи інструменти та програми як з відкритим вихідним кодом, так і з власної розробки. У зв'язку з цим варто згадати зростаючу популярність комплекту LAMP (Linux, Apache, MySQL, PHP) і його ширше застосування в організаціях.

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

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

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

2 Такі основні тенденції у галузі, як прискорене впровадження середовища покращення процесів CMM/CMMI та розширення використання моделей розробки із залученням сторонніх ресурсів, тісно пов'язані з цим очевидним перетворенням галузі розробки ПЗ. Звіт IDC Insight з використання J2EE та .NET Стіва Макклура (Steve McClure) затверджує наступне. 10,4% поточних користувачів.NET очікують, що протягом найближчих 12 місяців вони використовуватимуть і J2EE/J2ME; 11,9% користувачів J2EE/J2ME очікує, що протягом найближчих 12 місяців вони будуть залучені до розробки .NET.

Гетерогенність ІТ: найбільша проблема для ALM

Коротко кажучи, багато організацій в галузі ІТ розглядають гетерогенність як єдину альтернативу, оскільки з нею пов'язуються багато переваг для бізнесу. Дуже часто колективи розробників використовують різноманітні засоби, які не призначені для спільної роботи. Єдиного виробника, який постачає кошти для всіх необхідних дій у контексті одного програмного проекту, немає. Більше того, не існує і єдиного виробника, який міг би повністю охопити три основні домени: підтримку та модернізацію застарілих систем, розширення та налаштування пакетованих додатків, а також розробку нових розподілених додатків. Тому дуже ймовірно, що організації продовжать використовувати в рамках одного проекту та в різних технологічних доменах розрізнені засоби розробки. Через це найбільшою проблемою застосування ALM стає гетерогенність засобів розробки. Нагадаємо, що ALM прагне домогтися передбачуваності та цілісності процесу виробництва ПЗ за допомогою автоматизованої вимірності, узгодження та дисципліни. Однак у середовищі з високим ступенем гетерогенності цих якостей процесу виробництва ПЗ набагато важче досягти.

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

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

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

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

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

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

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

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

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

Подолання гетерогенності: останній рубіж ALM

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

Переваги Open ALM

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

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

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

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

організаційної культури та вимог до термінів виведення товарів ринку.

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

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

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

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

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

Управління портфелем проектів (Project Portfolio Management, PPM).Кошти та автоматизовані процеси для управління розробкою всієї стратегії створення ПЗ, а також для управління виконанням портфеля проектів з розробки ПЗ.

Визначення вимог та управління ними (Requirements Definition and Management, RDM).Набір коштів та кращих методик, які забезпечують наступне: вимоги до проекту точні та повні, їх можна ефективно відстежити аж до бізнес-цілей, і вони оптимально охоплені тестами ПЗ.

Управління якістю у життєвому циклі (Lifecycle Quality Management, LQM).Порядок та засоби для управління визначенням та вимірюванням якості на всіх етапах створення ПЗ. Ці засоби призначені для виявлення та запобігання проблемам з якістю на ранніх стадіях проекту, коли вартість їх виправлення відносно невелика. Також групи контролю якості повинні бути впевнені, що їх тести є повними та ґрунтуються на вимогах кінцевих користувачів.

Управління змінами (Change Management, CM).Інфраструктура та засоби, які допомагають передбачити наслідки змін. Вони також допомагають керувати ресурсами та діями, пов'язаними зі змінами під час життєвого циклу, як у багатовузлових, так і в одновузлових моделях.

Рішення Borland Open ALM

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

Архітектура рішення Borland Open ALM

Відкрита бізнес-аналітика для ALM

Відкрита бізнес-аналітика для ALM (Open Business Intelligence for ALM, OBI4ALM) заснована на стандартній інфраструктурі та додатках для збільшення вимірності прогресу, підвищення якості роботи або будь-якої іншої спеціальної метрики програмних проектів у гетерогенному середовищі розробки програм. OBI4ALM надає інфраструктуру для непомітного розподіленого збору даних, а також зіставлення та аналізу метрик із будь-якого засобу розробки додатків, який зареєстровано для цього. Видобуючи визначені метрики з джерел даних, інфраструктура OBI4ALM поєднує різнорідну інформацію, розкидану по всьому циклу створення програмного забезпечення. Така консолідація дає великі можливості. Наприклад, можна створити агреговане уявлення метрик проекту та визначити нові метрики проекту, які поєднують у собі кілька метрик нижчого рівня. Інфраструктура OBI4ALM використовує сховище даних. Це сховище містить поточну та історичну інформацію, зібрану з тих інструментів, які беруть участь у різних стадіях процесу створення ПЗ. При цьому використовується структура, яка оптимізована для виконання запитів та аналізу даних. Програми OBI4ALM можуть перетворювати зібрані метрики на інформацію, придатну для прийняття рішень на її основі. Таким чином, забезпечується підтримка прийняття рішень та раннього повідомлення про проблеми.

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

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

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

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

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

Відкрите управління процесом для ALM (Open Process Management for ALM, OPM4ALM) надає компоненти інфраструктури та набір додатків, які використовуються для моделювання, розгортання та впровадження різноманітних програмних процесів у гетерогенному середовищі розробки додатків. OPM4ALM йде набагато далі забезпечення керівництва та розподілу завдань між учасниками процесу. Цей метод також використовує рівень автоматизації процесу, який є основним "клеєм" для інтеграції клієнтської сторони, серверної сторони та методики відповідно до правил, зафіксованих у моделях процесів. З цього погляду інтеграція між засобами розробки програм насправді забезпечується процесами нижчого рівня. Це є фундаментальною основою для ефективної роботи колективу.

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

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

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

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

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

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

Відкритий контроль для ALM

Наскрізний контроль процесів підтримує багато важливих переваг ALM. Ось деякі з них: це важливий інструмент для реалізації розробки на основі бізнес-вимог, розробки та тестування на базі вимог та точного аналізу наслідків внесених змін. Відкритий контроль ALM (Open Traceability for ALM, OT4ALM) надає інфраструктуру для створення та класифікації зв'язків між ресурсами, створеними в процесі створення ПЗ. Також створюється гнучкий графік зв'язків пов'язаних ресурсів. При цьому немає значення, в яких інструментальних засобах ці ресурси розташовуються. Також ця технологія надає засоби для навігації по діаграмі зв'язків між ресурсами, а також для створення оптимальних запитів та для отримання даних, які в цій діаграмі містяться.

OT4ALM надає програми, які перетворюють зібрані дані в інформацію для прийняття рішень.

Автоматизоване планування, аналіз наслідків змін, точні передбачення витрат та бюджету.

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

Аналізатор повторного використання – дозволяє багаторазово використовувати цілі дерева ресурсів (від вимог та моделей до програмного коду та тестів) замість простого повторного використання модулів програмного коду.

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

Загальна інфраструктура платформ

Інфраструктура Open ALM містить два компоненти, які використовуються у всіх галузях рішення.

Метамодель ALM.Загальна мова для опису програмних процесів, зв'язків між ресурсами процесів (можливість контролю) та одиницями виміру (метриками). Метамодель ALM надає багатофункціональну концептуальну модель домену створення ПЗ. Це необхідно для опису стандартного словника, який має розуміти всі сумісні з Open ALM інструментальні засоби. Таке розуміння забезпечить ефективну взаємодію у рамках платформи Open ALM.

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

Дорога до Open ALM

Протягом наступних 24 місяців компанія Borland все більше розширюватиме інфраструктуру, програми та інструментальні засоби, які складають її платформу Open ALM. Компанія Borland також має намір доповнити цей продукт широким набором програм професійних послуг, призначених для прискорення розгортання та успіху корпоративних реалізацій Open ALM. Деякі переваги Open ALM замовники можуть скористатися вже сьогодні. Організації, які прагнуть покращити якість та вдосконалити процеси управління змінами та проектами, вважають поточне рішення Borland дуже привабливим. Це рішення забезпечує підтримку з високим ступенем автоматизації та інтеграції для чотирьох важливих областей процесів розробки програм:

Управління портфелем проектів (PPM);

Визначення вимог та управління ними (RDM);

Управління життєвим циклом додатків (LQM);

Керування змінами (CM).

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

Чому Borland?

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

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

На противагу цьому підходу компанія Borland завжди наполягала на підтримці стандартів Java та J2EE, та пропонувала сильну та інтегровану підтримку платформи, мов та засобів розробки Microsoft. Borland продовжує явно розширювати рішення Microsoft для ALM. Компанія Borland вклала значні кошти на підтримку новітніх технологій Microsoft. Наприклад, продукт CaliberRM, який є першим повністю інтегрованим рішенням для управління вимогами для Team System, рекомендований компанією Microsoft для розширення базової функціональності управління вимогами, що надається інструментальним засобом VSTS. Borland продовжить розширювати спільну роботу платформ Java та .NET. Планується надати додаткові можливості, наприклад, генерацію коду з UML C# і підтримку Microsoft Domain Specific Languages ​​(альтернатива Microsoft для заміни UML).

Рух у бік відкритого вихідного коду також пов'язане з проблемами, які створює гетерогенність для ALM. Мета кількох ініціатив Eclipse (Application Lifecycle Framework (ALF), Corona та Eclipse Process Framework (EPF)) схожа на цілі Borland Open ALM. Хоча Borland розуміє мотиви, що рухають цими проектами, компанія вважає їхній підхід недостатнім. І ALF і Corona намагаються надати лише компоненти інфраструктури Open ALM. Проте Open ALM є ціліснішим підходом. Цей підхід також дозволяє клієнтам отримувати вигоду для бізнесу з готових інфраструктур завдяки набору додаткових програм. У своєму русі до Open ALM Borland йде далі за інших виробників рішень ALM. Нещодавно компанія розширила свої горизонти та прагне охопити додаткові домени розробки додатків. Також Borland шукає найкращий підхід до підтримки проектів розробки пакетованих додатків на платформах SAP NetWeaver і Oracle Fusion.

Висновок

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

Borland починає створювати інфраструктуру, програми та відповідні засоби розробки для Open ALM. Тому замовники вперше матимуть можливість повністю використовувати можливості ALM. Вони зможуть скористатися перевагами цілісного, керованого та вимірного процесу створення ПЗ.

Керолін Пампіно (Carolyn Pampino, IBM)
На основі програм: Rational Team Concert Beta 3, Rational Quality Manager Beta 3, Beta 3

Огляд

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

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

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

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

Планування у реальному часі

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

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

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

Рис. 1. Оновлення витраченого часу з елемента робіт підтримує точність планів

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

Рис. 2. На поданні запланованого часу видно, коли в одних учасників команди роботи більше, ніж в інших

Рис. 3. Подання електронної дошки завдань може бути використане гнучкими командами, рознесеними територіально

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

Зображення нижче демонструє план випуску (Release Plan) у Rational Team Concert з посиланнями на пов'язаний з ним журнал пропозицій (Product Backlog), колекції вимог у Rational Requirements Composer та план тестування у Rational Quality Manager.

Рис. 5. З плануванням пов'язані колекції вимог та плани тестування

Рішення IBM Rational для спільного управління життєвим циклом включає повністю інтегроване планування реального часу.

Трасування життєвого циклу

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

Рішення для УЖЦ, яке дозволяє здійснювати трасування між артефактами життєвого циклу, допомагає командам отримувати відповіді на складні питання щодо статусу їхнього проекту. Створення зв'язків між артефактами дозволяє командам легше відповідати такі питання, як: " На які вимоги впливають дефекти?" та "Які елементи робіт готові до тестування?"

Рис. 6. Важливі питання, на які відповідає рішення для УЖЦ

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

Нижче наведено типові дії, які варто або не варто робити, пов'язані з трасуванням:

Дії, яких слід уникати
Уникайте рішень зі складним інтерфейсом, що демотивує користувачів створювати зв'язки між артефактами. Не перестарайтеся у створенні трасувальних зв'язків або виконанні трасування просто заради трасування.	Використовуйте рішення, яке надає можливість легко створювати і підтримувати трасувальні зв'язки за допомогою простого, універсального інтерфейсу користувача, щоб нікому не доводилося перемикатися на інші інструменти тільки для того, щоб зв'язати між собою два артефакти. Визначте кілька значущих питань, на які ви хочете відповідати, і визначте відповідні стратегії зі створення зв'язків. Спробуйте реалізувати одну і переконайтеся, що ви досягли успіху перед тим, як перейти до наступного.
Намагайтеся не створювати звітів, які швидко старіють та рішень для трасування, які не сприяють розумінню завершеності проекту.	Користуйтеся системою, яка надає запити, звіти та подання, які дають змогу оцінювати ступінь завершеності проекту та приймати повністю обґрунтовані рішення, що базуються на зв'язках між артефактами. Ви також повинні бачити трасування прямо з плану. Приклади запитів, які допомагають виявляти прогалини: "елементи плану без вимог" та "елементи плану без тестових наборів". Запити, які допомагають оцінити завершеність: "елементи плану з не пройденими тестами", "дефекти, що блокують тест" та "вимоги з відкритими дефектами".
Уникайте використання рішень, які не беруть до уваги наявність зовнішніх нормативних вимог та аудитів.	Інвестуйте в рішення, що включає можливість створення трасувальних зв'язків, які легко підтримувати і на основі яких легко створювати звіти.
Уникайте використання не інтегрованих проектних баз даних, розробки власних інтеграцій на основі пропрієтарних API та спроб об'єднати незв'язаний набір інструментів. Не використовуйте рішення, які не мають відкритих інтерфейсів для створення пов'язаних даних. Не вибирайте репозиторії УЖЦ із пропрієтарними інтеграціями.	Інтегруйте ваші міжфункціональні команди, вибираючи рішення з відкритими сервісами побудови зв'язків між даними у всьому життєвому циклі. Вибирайте рішення, яке реалізує відкриті інтерфейси за допомогою відкритих сервісів (OSLC) для побудови зв'язків між даними у життєвому циклі. Вибирайте постачальника продуктів, який розуміє та підтримує важкі завдання інтеграції під час управління життєвим циклом. Інвестуйте в інструменти, для яких визначено довгострокові плани з інтеграції, оскільки це полегшить створення зв'язків та трасування під час виконання проекту. Вибирайте масштабоване рішення за допомогою відкритих і гнучких інтеграцій, щоб воно вирішувало ваші завдання і в майбутньому. Часи змінюються, з'являються нові продукти, і ваше рішення для УЖЦ має розвиватись надалі.

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

Рис. 7. План випуску, що охоплює розробку, вимоги та тестування

Коли встановлені трасування, рішення IBM Rational для спільного керування життєвим циклом (IBM Rational Collaborative Lifecycle Management) автоматично створює на їх основі трасувальні зв'язки з дефектами, що виявляються під час проведення тестування. На зображенні нижче показаний дефект із створеними для нього трасувальними зв'язками. При додаванні дефекту в ході тестування автоматично створюються трасувальні зв'язки дефекту з результатами тесту, тестовим набором, планом тестування, елементом плану та вимогою.

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

Взаємодія у контексті

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

Також інструменти для взаємодії допомагають командам фокусуватись на тому, що важливо. Команди повинні знаходити будь-які можливості для автоматизації ручних та не творчих завдань. Хороше рішення для УЖЦ включає автоматизацію для складання та виконання тестів, але також має включати автоматизацію створення звітів про стан та доступ до інформації. Інформаційні панелі проекту та персональні інформаційні панелі відіграють важливу роль у автоматичному постачанні команди необхідною інформацією, забезпечуючи прозорість роботи команди та доступ до актуальних даних за допомогою командних звітів та запитів. Добре спроектований інтерфейс користувача автоматизує доступ до інформації, доставляючи інформацію користувачам безпосередньо і не змушуючи їх "міняти контекст", переключаючись на роботу з іншим додатком. У такій формі автоматизація безпосередньо сприяє кращій взаємодії.

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

Зображення нижче демонструє набір інформаційних панелей з віджетами, що містять інформацію з Rational Team Concert, Rational Requirements Composer та Rational Quality Manager. Дані на інформаційних панелях відображають актуальний статус проекту.

Рис. 9. Інформаційні панелі з даними з різних джерел забезпечують прозорість робіт для всіх функціональних команд

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

Рис. 10. Міні-панель доступна з будь-якої точки інтерфейсу користувача

Наступне зображення демонструє персональну міні-панель у Rational Team Concert. На цій панелі є віджет, що відображає зміни вимог Rational Requirements Composer . Це приклад міні-панелі з інформацією із різних джерел. При наведенні мишки на вимогу з'являється перегляд з інформацією про статус вимоги Requirements Composer. Користувачі, яким потрібний швидкий доступ до інформації, швидко звикнуть до міні-панелям.

Бізнес-аналітика для розробки

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

Згідно з Кейперсом Джонсом (Capers Jones 1), проекти, в яких практики вимірювань широко використовуються, досягають значно більших успіхів, ніж ті, в яких подібні практики не використовуються.

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

Наприклад, три наведені нижче метрики використовуються менш ніж у 50% організацій з досліджень Кейперса Джонса:

• Метрики якості 45%
• Метрики продуктивності 30%
• Метрики готовності 15%

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

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

Рис. 13. Інформаційна панель зі звітами та метриками для вимірювання покращень

Інформаційні панелі та звіти – ключова складова рішення для УЖЦ, яка відповідає за вимірювання та реагування на поточний прогрес команди.

Безперервне покращення процесу розробки

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

Дії, яких слід уникати
Не варто нехтувати якістю процесу або ставитись до нього як до зайвого навантаження.	Усвідомте, що безперервне покращення допоможе вашій команді запозичити найкращі практики, створити робочий ритм та зменшити непередбачені проблеми.
Не піддавайтесь спокусі покращити все й одразу. Не намагайтеся надто точно визначити процес за один раз.	Використовуйте поступові покращення, безперервно модифікуючи плани та інформаційні панелі, вирішуючи проблеми команди, які виходять з поточного статусу проекту. Використовуйте підхід, який допоможе вам почати покращення з вашої поточної ситуації.
Уникайте ситуації, коли процес після визначення записується на жорсткий диск і більше ніколи не проглядається.	Прагніть до проривних покращень, переймаючи найкращі практики у вигляді специфікацій процесів, шаблонів та автоматизації, які кілька команд можуть використовувати в одному інструменті.
Уникайте надто жорсткого контролю процесу.	Заохочуйте членів команди брати участь у покращенні процесу, обравши систему, що полегшує безперервне покращення та щось, що можна робити за допомогою інструменту, який використовують усі.
Не визначайте покращень процесу, не бачачи кінцевого результату.	Коли ви визначаєте покращення процесу, відображайте результати покращень на інформаційних панелях.
Не варто очікувати, що з першого разу зробите все правильно.	Слід розуміти, що завжди є ґрунт для подальших покращень. Тому необхідно безперервно переглядати покращення та визначати наступний їх набір. Команди, які хочуть покращити свою здатність досягати цілей якості, використовують Rational Quality Manager, в якому є інтеграції з Rational Team Concert і Rational Requirements Composer. IBM Rational Quality Manager допомагає організаціям оптимізувати якість у проекті шляхом надання єдиного центру для управління тестуванням, який забезпечує інтегровану підтримку життєвого циклу практично для будь-якої цільової платформи та типу тестування. Він реалізує настроюване рішення, засноване на ролях, для планування тестування, створення та виконання тестів, а також для контролю послідовності робіт, управління та наскрізного трасування. Використання цих продуктів спільно дозволяє команді впровадити 5 принципів управління життєвим циклом, розглянутих у цій статті. Ці принципи вбудовані в інструменти та готові допомагати вам покращувати свою здатність створювати високоякісні інновації у програмному забезпеченні. Ще добре те, що необов'язково використовувати всі три інструменти, щоб отримати віддачу – їх можна використовувати як попарно, так і всі разом. ___________________________________________________________________________________________________________

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

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

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

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

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

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

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

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

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

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

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

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

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

Експерт у галузі ІТ Д. Чеппел застерігає від спрощеного погляду на ALM, яке часто ототожнюють лише з життєвим циклом розробки програмного забезпечення (Software Development LifeCycle, SDLC): ініціацією, ітеративним циклом розробки, випуском релізу продукту та впровадженням. Дисципліна ALM охоплює ширше коло завдань, розглядаючи всі аспекти існування такого корпоративного ресурсу, як програми. За визначенням Д. Чеппела, життєвий цикл додатку включає у собі всі етапи, у яких організація однак вкладає кошти на цей ресурс - від вихідної ідеї програмного рішення до утилізації що відслужило свій термін ПО .

Гранично деталізують це визначення в НР – за версією компанії, цикл становить лише один із етапів повноцінної моделі.

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

Аналіз потреб бізнесу

Пріоритетність та інвестиції

Уор4длення ШШДоїШ „Моніторинг програм

Вдосконалення

Планування

Керівні рішення

Виправлення

помилок

Моніторинг

налаштування

життєвий ЦИКЛ програми

Практики

Відповідність

вимогам

Повторне

ілопкюваніс

Ініціація

терації розробки

Доставка

Виведення з експлуатації

Випуск

недріння

Рис. 3.14. Модель ALM

Д. Чеппел розгортає картину життєвого циклу в лінійну, виділяючи три основні області ALM: керівництво (governance), розробка (development) та експлуатація (operations). Відповідні цим областям процеси протікають, перекриваючись, від зародження ідеї нового додатка чи модернізації існуючого етапу його розгортання і до завершення функціонування.

Керівництво в ALM реалізується протягом усього життєвого циклу програми і включає всі процеси і процедури, які відносяться до прийняття рішень і управління проектом. Головне завдання тут – забезпечення відповідності докладання тим чи іншим цілям бізнесу, що визначає важливість цього компонента ALM. До процесів керівництва, Д. Чеппел відносить розробку детальної інвестиційної пропозиції (бізнес-кейс, що містить аналіз витрат, вигод та ризиків, пов'язаних з майбутнім додатком), що передує стадії розробки; управління розробкою за допомогою методів та засобів управління проектами та портфелями (Project Portfolio Management, PPM); управління працюючим додатком у межах управління портфелем додатків підприємства (Application Portfolio Management, АРМ).

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

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

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

До розширеного списку ролей учасників процесів ALM та завдань, які повинні підтримуватися відповідним інструментарієм, входять:

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

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

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

Спочатку одними з небагатьох новаторів, які зрозуміли важливість ALM і змінили свої стратегії випуску продуктів у бік її підтримки, були Borland і IBM Rational. Відреагувавши на очевидні можливості, до концепції ALM, що перемогла, приєдналися й інші компанії: Microsoft, Telelogic, Mercury, Serena, Compuware, CollabNet і Mercury. Сьогодні ALM - це тенденція і зростаюча індустрія, визнана аналітиками. Виробники рішень ALM надають різні засоби та технології для підтримки процесу розробки ПЗ. Ці засоби виходять далеко за межі традиційних інструментів для підвищення продуктивності окремого розробника. Вони спрямовані на надання методик та інструментів, орієнтованих на колективну роботу зі створення ПЗ. Щоб створити життєздатне рішення для ALM, виробники повинні враховувати потреби розширеної групи розробників ПЗ та включати у свої продукти ролі, які беруть участь у ширшому процесі.

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

Сьогодні виникають нові вимоги до ALM, і визначальну роль цьому грає широке поширення швидких (agile) методів розробки. Кілька років тому автор однієї з найвідоміших швидких методик Scrum Д. Сазерленд заявив про майбутню тотальну адаптацію ідей швидкої розробки. Це здавалося перебільшенням, але прогноз виявився вірним. За даними спільного дослідження аналітиків Capgemini Group та підрозділу HP Software&Solutions, у 2010 р. понад 60% компаній вже використовували або планували використовувати розробку в стилі agile, а серед учасників опитування Forrester лише 6% зізналися, що поки що тільки придивляються до швидких методів, усі А решта застосовують їх тією чи іншою мірою, причому 39% вважають свої реалізації цілком зрілими.

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

Усвідомлення гостроти проблеми та тенденція пошуку засобів її вирішення навіть породили новий термін DevOps, що застосовується для позначення концепцій та технологій покращення взаємодії між розробкою та експлуатацією. Основні надії на реалізацію цих ідей аналітики покладають на ALM-середовища нового покоління, які насправді, а не теоретично забезпечать інтеграцію ключових етапів життєвого циклу додатків. Створювані програми сьогодні у багатьох випадках композитні та інтегрують на сервісних принципах компоненти, реалізовані різними мовами програмування для різних платформ, а також код зовнішніх систем та успадковані рішення. Для керування їх життєвим циклом середовище ALM має підтримувати різні середовища розробки та платформи виконання (наприклад, NET та J2EE), а також забезпечувати можливість контролю вихідного коду, ліцензування та статусу розробки зовнішніх компонентів програми.

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

Лінійка продуктів Rational для підтримки різних етапів життєвого циклу програмного забезпечення завжди виділялася широтою і фокусом на інтегрованість модулів між собою. Аналітики Butler Group оцінили комплекс рішень IBM Rational Software and Systems Delivery як найбільш повний з представлених на ринку спектру реалізованих компонентів ALM. Цей комплекс включає в себе продукти для управління портфелями проектів, проектування та розробки на базі моделей, управління вимогами, управління конфігураціями та змінами, управління якістю, управління складаннями та релізами; оркестрування процесів життєвого циклу ПЗ та забезпечення звітності та документації з цих процесів. Слово Systems у назві з'явилося після придбання компанії Telclogic, рішення якої орієнтовані на підтримку процесів системної інженерії та тепер інтегровані у портфель Rational. Їх включення в ALM-середовище IBM відображає тенденцію зближення процесів розробки ПЗ та систем та формування для них єдиного середовища управління життєвим циклом.

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

Ядром Jazz є платформа Jazz Foundation, що об'єднує сервер Jazz Team Server та низку додаткових модулів інтеграції. Jazz Team Server демонструє новий ALM підхід до інтеграції компонентів для різних етапів життєвого циклу (рис. 3.15, ). Якщо традиційно така інтеграція базувалася на точковому зв'язку між окремими продуктами, то Jazz реалізована відкрита розподілена сервісна архітектура на базі стандарту REST, яка забезпечує просте взаємодію інструментальних компонентів між собою (своєрідного ALM Web). Інтерфейс RESTful дозволяє представляти у вигляді сервісів дані та функціональність різноманітних модулів. Використання підходу на базі стандартів Web забезпечує хорошу масштабованість Jazz, роблячи платформу універсальним рішенням, здатним підтримувати завдання ALM у невеликих командах та у великих колективах розробників.

Project and Team Structure

Event Notification

Jazz Team Server

j * ;

Requirements Items and relationships IlJ Event history,

Use " cases ...... Item history trends

Builds Source code. Test-cases Test results

				Visual Studio
Client Platform		Client Platform		Client Platform

Security and Access

Рис. 3.15. Інтегрована корпоративна платформа управління життєвим циклом додатків

Jazz Foundation надає загальні всім компонентів ALM сервіси, дозволяють реалізувати ключові можливості сучасного середовища управління життєвим циклом додатків. Це, наприклад, послуги спільної роботи, що забезпечують взаємодію різних учасників команди в процесі вирішення спільних завдань, що підтримують взаємозв'язки між різними етапами життєвого циклу і при цьому враховують контекст кожної конкретної ролі в ALM. Інструменти співпраці на базі Jazz використовують засоби миттєвих повідомлень, засоби організації тривалих обговорень, механізми вікі та інші популярні можливості Web 2.0. При цьому всі взаємодії між членами команди розглядаються як проектні ресурси, що зберігаються у зв'язку з тими артефактами, які стали джерелом цих взаємодій (наприклад, дефектами або тестовими прикладами).

Сервіси Jazz Foundation також дозволяють визначати та виконувати процеси відповідно до різних методик, включаючи Rational Unified Process та різні варіанти швидкої розробки. Для цього надаються засоби нотифікації про події, підтримка зв'язку членів команди у виконанні певних потоків робіт, завдання та перевірка виконання правил, автоматизація базових завдань, організація потоків робіт із використанням інструментарію для різних етапів життєвого циклу. Велика увага приділяється забезпеченню прозорості процесів життєвого циклу та керівництву процесами, для чого вводяться точні процесні метрики за статусом, проблемами та ризиками проекту та надаються інструментальні панелі для їх відстеження, у тому числі у реальному часі, на різних рівнях, від окремих учасників процесів до команди та рівня управління портфелями. Серед інших сервісів Jazz Foundation можна назвати пошукові механізми, засоби безпеки, рольовий доступ, розподілений репозиторій всім ресурсів розробки.

Платформа Jazz забезпечує інтеграцію із середовищем розробки Eclipse, надаючи ряд уявлень та проекцій. Деякими компонентами Jazz також підтримуються веб-клієнти. Платформою Jazz надаються два значних уявлення для Eclipse: Team Central і Team Artifacts. Обидва уявлення служать для збору інформації та можуть доповнюватися компонентами платформи Jazz. Розробляючи Eclipse, деякі компоненти платформи Jazz дозволяють користувачам звертатися до сервера Jazz безпосередньо з веб-браузера .

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

З найбільш яскравих новинок у сімействі Rational, створених спеціально для роботи на базі Jazz, - система Rational Team Conceit (RTC), що є комплексом продуктів для організації спільної роботи та автоматизації процесів життєвого циклу ПЗ, повністю побудований в архітектурі Jazz. IBM Rational Team Concert є повноцінним середовищем, призначеним для організації розробки інформаційних систем у мультипроектному оточенні, в якому бере участь безліч розробників. Інструмент дозволяє об'єднати зусилля фахівців у галузі розробки, організувати їх ефективну взаємодію та зберегти найвищий рівень контролю над усією проектною діяльністю на всьому протязі проекту.

Система RTC реалізує управління конфігураціями ПЗ, управління завданнями та складаннями, а також планування ітерацій та звітність за проектом, забезпечує визначення різних типів процесів розробки та інтегрується з іншими продуктами Rational для підтримки повного життєвого циклу ПЗ. У 2009 р. IBM також випустила Rational Quality Manager (портал для управління тестуванням на базі Jazz) та інструмент управління ефективністю Rational Insight, реалізований для платформи Jazz з використанням аналітичних технологій Cognos та призначений для завдань високорівневого управління портфелями проектів розробки.

Широкі можливості в області інтеграції IBM Rational Team Concert роблять цей інструмент абсолютно унікальним. Серед існуючих інтеграцій слід зазначити таке.

• 1. Інтеграцію з IBM Rational Requirements Composer у рамках спільної розробки додатків (Collaborative application lifecycle management, або CALM), яка дозволяє пов'язувати робочі завдання з вимогами, породженими або зміненими на основі цих завдань, і навпаки, вимоги із завданнями, створеними для планування робіт щодо реалізації цих вимог.
• 2. Інтеграцію з IBM Rational Quality Manager в рамках спільної розробки додатків (Collaborative application lifecycle management), на основі чого стає можливим організувати дефект-трекінг за результатами виконаних тестів під час тестування програмних продуктів, що випускаються.
• 3. Інтеграцію з IBM Rational ClearQuest для синхронізації робочих завдань та запитів на зміни, визначені в класичному засобі управління розробкою IBM Rational ClearQuest.
• 4. Інтеграцію з IBM Rational ClearCase для синхронізації артефактів версійного та конфігураційного управління між двома зазначеними засобами.

Відкрита архітектура Jazz Integration Architecture, що лежить в основі IBM Rational Team Concert, дозволяє вести додаткову розробку нових механізмів інтеграції з іншими системами, які можуть бути розгорнуті та активно використовуватися в організації. Одним із варіантів інтеграції з цими системами може бути використання продукту RTC Email Reader від компанії «Фінеко Софт», який забезпечує синхронізацію робочих завдань IBM Rational Team Concert відповідно до email-повідомлень наперед визначеного формату. При цьому можлива зворотна синхронізація завдяки вбудованій підсистемі оповіщень IBM Rational Team Concert.

Треба також відзначити, що управління версіями та конфігураціями на базі IBM Rational Team Concert може бути організоване практично в будь-якому проекті, навіть якщо середовище розробки (IDE) не має безпосередньої інтеграції з цим інструментом. Це стає можливим завдяки спільному використанню "товстого клієнта" IBM Rational Team Concert та неінтегрованого IDE. Так, якщо для Eclipse IDE, IBM Rational Software Architect, IBM Rational Application Developer та Microsoft Visual Studio такі інтеграції існують, то вже, наприклад, з Delphi доведеться додатково використовувати "товстий клієнт" IBM Rational Team Conceit, що не становить великих труднощів.