Аналізуючи розвиток ринку засобів розробки за останні 10-15 років, можна відзначити загальну тенденцію усунення акцентів від технологій власне написання програм (які з початку 90-х років ознаменувалися появою RAD-інструментів - "швидка розробка додатків") до необхідності комплексного управління всім життєвим циклом програм - ALM (Application Lifecycle Management) .

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

· Визначення вимог (Requirements);

· Проектування та аналіз (Design & Analysis);

· Розробка (Development);

· Тестування (Testing);

· Розгортання та супровід (Deployment & Operations).

Кожен із цих етапів повинен ретельно відстежуватися та контролюватись. Правильно організована ALM-система дозволяє:

· Зменшити терміни виведення товарів на ринок (розробникам доводиться дбати лише про відповідність їх програм сформульованим вимогам);

· підвищити якість, гарантуючи при цьому, що програма буде відповідати потребам та очікуванням користувачів;

· Підвищити продуктивність праці (розробники отримують можливість ділитися передовим досвідом розробки та впровадження);

· прискорити розробку завдяки інтеграції інструментів;

· зменшити витрати на супровід, постійно підтримуючи відповідність між додатком та його проектною документацією;

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

Строго кажучи, саме поняття ALM, звичайно, не є чимось принципово новим, - таке розуміння проблем створення ПЗ виникло років сорок тому, на зорі формування промислових методів розробки. Однак до відносно недавнього часу основні зусилля з автоматизації завдань розробки ПЗ були спрямовані на створення інструментарію для програмування як найбільш трудомісткого етапу. І лише у 80-х роках у зв'язку з ускладненням програмних проектів ситуація стала суттєво змінюватися. У цьому різко зросла актуальність розширення функціональності засобів розробки (у широкому розумінні цього терміна) у двох основних областях: 1) автоматизація решти етапів життєвого циклу ПО і 2) інтеграція інструментів між собою.

Цими завданнями займалося багато компаній, проте безперечним лідером тут була компанія Rational, яка понад двадцять років, з моменту свого створення, спеціалізувалася на автоматизації процесів розробки програмних продуктів. Свого часу саме вона стала одним з піонерів широкого використання візуальних методів проектування програм (і практично автором мови UML, прийнятого де-факто як стандарт у цій сфері), створила загальну ALM-методологію та відповідний набір коштів. Можна сказати, що до початку нинішнього століття Rational була єдиною компанією, що мала у своєму арсеналі повний спектр продуктів для підтримки ALM (від бізнес-проектування до супроводу), за винятком одного класу інструментів - звичайних засобів написання коду. Однак у лютому 2003-го вона перестала існувати як незалежна організація і стала підрозділом корпорації IBM, який отримав назву IBM Rational.

Ще зовсім недавно Rational була практично єдиним виробником комплексних засобів розробки класу ALM, хоча конкуруючі інструменти від інших постачальників для окремих етапів створення програмного забезпечення були і є. Проте кілька років тому про намір скласти їй реальну конкуренцію публічно заявила корпорація Borland, яка завжди мала сильні позиції якраз у галузі традиційних засобів розробки додатків (Delphi, JBuilder та ін.), що фактично є основою ALM-комплексу корпорації, розширення якого йшло шляхом придбання інших компаній, які випускають аналогічні продукти. У цьому полягає важлива відмінність бізнес-моделей двох компаній, що відкриває потенційні можливості для реальної конкуренції. Після входження Rational до складу IBM компанія Borland позиціонує себе як єдиного на сьогоднішній день незалежного постачальника комплексної ALM-платформи (тобто просуванням власних ОС, мов та ін. вона не займається). У свою чергу конкуренти відзначають, що Borland поки що не сформулювала чітку методологію ALM, яка дає базу для об'єднання інструментів, які вона має.

Ще одним серйозним гравцем на полі засобів розробки є корпорація Microsoft. Поки що вона не замахується створення власної ALM-платформи; Просування в цьому напрямку йде тільки в рамках співпраці з іншими постачальниками, тими самими Rational та Borland (обидві вони стали першими учасниками Visual Studio Industry Partner). У той же час, створений Microsoft ключовий засіб розробки Visual Studio .NET постійно розширює функціональність за рахунок використання високорівневих засобів моделювання та управління проектами, у тому числі шляхом інтеграції з Microsoft Visio та Microsoft Project.

Слід зазначити, що на сьогоднішній день практично всі провідні компанії-розробники технологій і програмних продуктів (крім перерахованих вище, можна назвати Oracle, Computer Associates та ін.) мають у своєму розпорядженні розвинені технології створення ПЗ, які створювалися як власними силами, так і за рахунок придбання продуктів та технологій, створених невеликими спеціалізованими компаніями. І хоча, подібно до корпорації Microsoft, створення власної ALM-платформи ними поки що не планується, що випускаються цими компаніями CASE-засоби знаходять широке застосування на окремих етапах ЖЦ ПЗ.

Керолін Пампіно (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 принципів управління життєвим циклом, розглянутих у цій статті. Ці принципи вбудовані в інструменти та готові допомагати вам покращувати свою здатність створювати високоякісні інновації у програмному забезпеченні. Ще добре те, що необов'язково використовувати всі три інструменти, щоб отримати віддачу - їх можна використовувати як попарно, так і разом. ___________________________________________________________________________________________________________

Відомо, що багато користувачів (і, що гріха таїти, деякі 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). При цьому дана платформа, на відміну від конкуруючих з нею наборів продуктів, гарантуватиме підтримку всіх найпопулярніших засобів розробки та дозволить інтегрувати в них свої складові на рівні повної синхронізації коду з моделями, вимогами, змінами. І сподіватимемося, керівники проектів зітхнуть з полегшенням, позбавивши себе та своїх співробітників від багатьох втомливих та рутинних завдань.

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

І т.д..

"Управління життєвим циклом" зводиться до необхідності освоєння звичних для системної інженерії практик:

• управління інформацією(«потрібна інформація має бути в необхідних зацікавлених сторін вчасно, й у доступної її використання формі»),
• управління конфігурацією(«проектна інформація повинна відповідати вимогам, інформація «як побудовано» повинна відповідати проекту, у тому числі проектним обґрунтуванням, фізична система має відповідати інформації «як побудовано», а різні частини проекту при цьому повинні відповідати один одному», іноді частину цієї практики називають "управління змінами ").

СУЖЦ vs PLM

По-новому сформульована СУЖЦ не використовує PLM як обов'язковий клас програмних засобів навколо якого така система будується. У великих інженерних проектах зазвичай використовується відразу кілька (найчастіше істотно "недоосвоєних") PLM різних вендорів, і при створенні СУЖЦ йдеться зазвичай вже про їхню міжорганізаційну інтеграцію. Звичайно, при цьому вирішуються і питання, як інтегрувати в СУЖЦ інформацію та тих систем, які ще не мають зв'язку з якоюсь системою PLM розширеного підприємства. Терміном «розширене підприємство» (extended enterprise) зазвичай називають створену у вигляді системи контрактів організацію з ресурсів (людей, інструментів, матеріалів) що у конкретному інженерному проекті різних юридичних. У розширених підприємствах відповідь на питання, в яку саме PLM інтегруються дані якої саме із систем CAD/CAM/ERP/EAM/CRM/і т.д. стає нетривіальною: власникам різних підприємств не запропонуєш використовувати програмні засоби одного постачальника.

А оскільки PLM-система все-таки є програмними засобами, а "система управління" із СУЖЦ явно розуміється у тому числі як "система менеджменту", то термін СУЖЦ має на увазі явно й організаційний аспект, а не лише аспект інформаційних технологій. Тим самим було фраза " використання PLM підтримки системи управління життєвим циклом " цілком осмислена, хоча може заплутувати при дослівному перекладі у ній “PLM” російською.

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

• датацентричний репозиторій даних життєвого циклу,
• "Система документообігу" (workflow engine) для підтримки "управління",
• "портал" для перегляду вмісту репозиторію та стану документообігу.

Призначення СУЖЦ

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

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

Ідея СУЖЦ не має тим самим відношення до різноманітних «автоматизацій проектування», насамперед – до «що породжує проектування» (generative design) та «що породжує виробництво» (generative manufacturing). СУЖЦ стурбована більше не синтезом, а аналізом: виявляє та/або запобігає колізії в результатах проектування окремих підсистем, коли їх будуть збирати разом за різними технологіями:

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

Моделеорієнтований підхід

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

Модель даних може бути розроблена відповідно до якоїсь мови, наприклад:

• у термінах стандарту опису методу розробки ISO 24744),
• метамодель (у термінах консорціуму стандартизації OMG),
• модель даних/довідкові дані (у термінах стандарту інтеграції даних життєвого циклу ISO 15926).

Саме такий перехід до структурних моделей, що існують вже на ранніх стадіях проектування і називається «Системною інженерією на основі моделей» (MBSE, model-based systems engineering). Знімати колізії за допомогою комп'ютерної обробки даних стає можливим вже на ранніх стадіях життєвого циклу, ще до появи повноцінних 3D моделей конструкції.

СУЖЦ має:

• забезпечувати механізм передачі даних з однієї програми CAD/CAM/ERP/PM/EAM/і т.д. в інше- причому в електронному структурованому вигляді, а не у вигляді "пачки електронного паперу". Передача даних з однієї інженерної інформаційної системи (з чітким розумінням звідки, куди, коли, що, навіщо, як) - це частина функціональності, що забезпечується СУЖЦ. Тим самим СУЖЦ повинна підтримувати workflow (хід робіт, який частково виконується людьми, а частково комп'ютерними системами).
• контролювати версії, тобто надавати функцію управління конфігурацією - як моделей, і фізичних елементів системи. СУЖЦ підтримує таксономію вимог різного рівня та надає засоби для перевірки колізії різнорівневих проектних рішень та їх обґрунтувань із цими вимогами. У ході інженерної розробки будь-який опис системи, будь-яка її модель змінюються і доповнюються багаторазово, і існують тому безліч альтернативних версій різного ступеня правильності, і різною мірою відповідних один одному. СУЖЦ має гарантувати, що з поточної роботи використовується лише правильне поєднання цих версій.

Архітектура СУЖЦ

Архітектурних рішень для СУЖЦ може бути безліч, одна й та сама функція може бути підтримана різними конструкціями та механізмами роботи. Можна виділити три види архітектури:

1. Традиційні спроби створити СУЖЦ- Це забезпечити найважливіші передачі даних за принципом "крапка-крапка" між різними додатками. При цьому може бути використана якась спеціалізована система підтримки workflow (BPM engine, «движок управління бізнес-процесами»), або система обробки подій (complex event processing engine). На жаль, обсяг роботи із забезпечення обмінів «точка-точка» виявляється просто грандіозним: щоразу потрібні фахівці, які розібралися в обох системах, що зв'язуються, і методі передачі інформації.
2. Використання стандарту інтеграції даних ЖЦ ISO 15926 за методом ISO 15926 outside, коли для кожного інженерного додатка розробляється адаптер в нейтральне уявлення, що відповідає стандарту. Тим самим, всі дані отримують можливість зустрітися в якомусь додатку і колізія між ними може бути виявлена ​​- але для програми потрібно розробити лише один адаптер передачі даних, а не декілька таких адаптерів (за кількістю інших програм, з якими потрібно забезпечити зв'язок).
3. PLM(Teamcenter, ENOVIA, SPF, NET Platform і т.д.) - використовується стандартизована архітектура, за тим лише винятком, що використовується в кожній з цих PLM модель даних менш універсальна в плані відображення будь-якої предметної області інжинірингу, а також не є нейтральним і доступним усім форматом. Так що використання ISO 15926 як базове уявлення при передачі даних у СУЖЦ можна вважати подальшим розвитком ідей, за фактом реалізованих у сучасних PLM.

По архітектурі управління конфігурацією, СУЖЦ можна розділити на три види:

• «репозиторій»(Актуальне зберігання всіх даних проекту в одному репозиторії СУЖЦ, куди копіюються дані звідти, де вони були розроблені),
• «Регістр»(СУЖЦ підтримує список адрес даних життєвого циклу в численних репозиторіях інших САПР, систем інженерного моделювання, PLM, ERP і т.д.),
• «гібридна архітектура»-- коли частина даних копіюється до центрального репозиторію СУЖЦ, а частина даних доступна з інших місць за посиланнями.

Архітектора СУЖЦ має також описувати:

• «портал»(у тому числі «веб-портал»), його функціях та спосіб реалізації. Сама наявність порталу дозволяє заспокоїти топ-менеджерів, демонструючи відсутність колізій. До архітектурних рішень щодо «порталу СУЖЦ» висуваються специфічні вимоги.
• алгоритми перевірки цілісності/несуперечності данихжиттєвого циклу, а також опис роботи цих алгоритмів:
  • стандартний модуль в окремому додатку, що працює над даними в репозиторії цього додатка - чи це САПР або PLM;
  • спеціально розроблений для СУЖЦ програмний засіб перевірки колізій, що має доступ до даних різних додатків, що знаходяться у центральному репозиторії СУЖЦ;
  • спеціально розроблений програмний засіб, що звертається через інтернет захищеним каналом до різних сховищ даних, що знаходяться в різних організаціях;
  • спеціально запрограмовані перевірки з контролем колізій під час завантаження різних інженерних наборів даних до центрального репозиторію СУЖЦ;
  • комбінація з усіх перерахованих методів – різних для різних типів колізій; і т.д.
• спосіб взаємодії користувачів СУЖЦ(інженерів-проектантів, закупників, монтажників, менеджерів проекту споруди тощо), і як саме програмне забезпечення СУЖЦ підтримує цю взаємодію способом, що запобігає появі колізій. Стандарти системної інженерії (зокрема стандарт практик системної інженерії ISO 15288) вимагають вибору виду життєвого циклу для інженерії складних об'єктів та вказівки того, які варіанти практик системної інженерії будуть використані. Модель життєвого циклу одна із основних артефактів, які є для організаційних домовленостей з координації робіт розширеної організації інженерного проекту. Скоординовані роботи під час колаборативної розробки (collaborative engineering) – це запорука малого числа проектних колізій. Як саме підтримає модель життєвого циклу СУЖЦ? Так, системи PLM зазвичай не знаходять місце моделям життєвого циклу, і особливо моделям організації. Тому для СУЖЦ потрібно шукати інші рішення щодо програмної підтримки цих моделей.
• Організаційний аспект початку використання СУЖЦ. Перехід до використання СУЖЦ може викликати істотну зміну у структурі і навіть кадровому складі інжинірингової компанії: не всіх землекопів беруть до екскаваторників, не всіх візників беруть у таксисти.

Головне для СУЖЦ – наскільки запропоноване рішення сприяє ранньому виявленню, а то й запобіганню колізії. Якщо мова заходить про щось інше (змістовний вибір виду життєвого циклу відповідно до профілю ризику проекту, управління старінням, управління вартістю і реформа кошторисної системи, освоєння axiomatic design, споруда з поставками «точно вчасно», що породжує проектування і спорудження, а також багато-багато інше, також вкрай корисне-сучасне-цікаве), то це питання інших систем, інших проектів, інших методів, інших підходів. СУЖЦ повинна добре робити свою справу, а не погано вирішувати величезний набір чужих завдань, що довільно обираються.

У архітектора СУЖЦ цим два основні завдання:

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

Критерії вибору архітектурного рішення для СУЖЦ

1. Якість виконання СУЖЦ свого основного призначення: виявлення та запобігання колізіямГоловний критерій: наскільки може бути прискорено перебіг інженерних робіт за рахунок прискорення виявлення або запобігання колізіям при використанні запропонованої архітектури СУЖЦ? А якщо час робіт не може бути скорочений, то наскільки за той самий час можна збільшити обсяг робіт під час використання тих самих ресурсів? Рекомендуються такі методології:
   • Теорія обмежень Голдратта(TOC, theory of constraints) – архітектура повинна зазначати, які системні обмеження вона знімає на критичному ресурсному шляху інженерного проекту (не плутати з критичним шляхом).
   • ROI(return on investments) для інвестицій у СУЖЦ на стадії оформлення результату змістовного розгляду архітектур-кандидатів.
   Важливо вибрати межі розгляду: загальна швидкість виконання інжинірингового проекту може бути виміряна тільки на межі аналізованої організаційної системи. Кордони якоїсь однієї юрособи можуть не збігатися з межами розширеного підприємства, що здійснює масштабний інженерний проект, а підприємство, що бере участь лише на одній стадії життєвого циклу, може неправильно оцінити свою корисність і критичність для повного життєвого циклу системи і неправильно вибрати спосіб своєї інтеграції в СУЖЦ. Тоді може з'ясуватися, що створення СУЖЦ не впливає на загальні терміни та бюджети проекту, бо найнеприємніші колізії продовжать являти себе неадресованими новою СУЖЦ.
2. Можливість прийняття інкрементального життєвого циклу розробки СУЖЦІнкрементальним в ISO 15288 називається такий життєвий цикл, у якому функціональність користувачеві видається не відразу вся, а постадійно - а й вкладення у розробку також відбуваються не одномоментно, а постадійно. Звичайно, при цьому потрібно враховувати закон спадної корисності: кожен інкремент СУЖЦ (кожен новий тип колізій, що виявляються заздалегідь) обходиться дорожче, а користі від нього все менше, поки розробка СУЖЦ, що триває багато років, не згасне сама собою. Якщо з'ясовується, що для якоїсь із запропонованих архітектур потрібно одномоментно вкласти у створення СУЖЦ багато грошей, але користь можна буде отримати одразу у розмірі 100% і лише за п'ять років "під ключ", то це погана архітектура. Якщо з'ясовується, що можна розробити і ввести в експлуатацію якесь компактне ядро ​​СУЖЦ, і далі багато однотипних модулів для різних типів колізій зі зрозумілим механізмом їх розробки (наприклад, заснованим на використанні ISO 15926), то це дуже добре. Йдеться не так про те, щоб застосовувати «гнучку розробку» (agile methodologies), як передбачити модульну архітектуру СУЖЦ і запропонувати план реалізації пріоретизованого списку модулів – спочатку найнасущніших, потім менш насущних, тощо. Не плутати з ICM (incremental commitment model), хоча сенс тут такий самий: краще та архітектура, при якій можна отримати якусь розстрочку платежів за систему, а потрібну функціональність отримувати якомога раніше – щоб користь отримати (хоча б маленьку) раніше, а платити за пізню користь пізніше.
3. Принципова фінансова та інтелектуальна можливість освоїти та підтримувати технологіюЯкщо порахувати витрати не тільки на власне СУЖЦ, а й на всю потрібну для здійснення проекту кадрову та іншу інфраструктуру, то треба зрозуміти, скільки цих вкладень в освіту, комп'ютери та організаційні зусилля залишиться платнику та власнику СУЖЦ, а скільки осяде зовні – у численних контракторів які, звичайно, будуть вдячні спочатку за отримання ними «стипендії» на освоєння нової технології, а потім за супровід створеної ними системи. Нове зазвичай вкрай затратно, і не тому що воно саме дорого коштує, а тому що викликає лавину змін, які вони викликають. Саме цей пункт у мене враховує повну вартість володіння СУЖЦ, і цей же пункт включає розгляд повного життєвого циклу вже не інженерної системи з колізіями, що її запобігають, але самій СУЖЦ.
4. Масштабованість архітектури СУЖЦЦей критерій є актуальним для великих інженерних проектів. Оскільки ви хочете, щоб системою користувалися всі тисячі співробітників розширеної організації, вона повинна швидко зростати до цих масштабів. Наскільки "пілот" чи "полігон" СУЖЦ зможуть швидко зрости без принципових архітектурних змін? Швидше за все вони вирости не зможуть. Тому архітектурно потрібен не "пілот" або "полігон", а одразу "перша черга". Вимога критерію масштабування тісно перетинається з вимогою критерію інкрементальності, але зачіпає трохи інший аспект - не стільки розтяжка створення СУЖЦ за часом, скільки можливість розтяжки за обсягом, що накривається. Досвід показує, що на тестових обсягах проектних даних справляються всі системи, а ось на промислових – не справляються. Як нелінійно зростатиме вартість апаратури та програмних засобів при зростанні обсягів/швидкості? Як довго відпрацьовуватимуть регламенти, коли з'ясується, що через якесь робоче місце проходить більша кількість даних, чим може бути осмислено переглянуто однією людиною? Погана масштабованість може підстерігати не тільки з технічного боку архітектури програмно-апаратного рішення, але і фінансової його архітектури. Так, невелика ціна на ліцензію на кожне робоче місце СУЖЦ, або навіть невелика ціна на кожне нове з'єднання на сервері-репозитарії можуть перетворити більш-менш симпатичне рішення для десяти робочих місць на абсолютно фінансово непідйомне для цільової тисячі робочих місць.
5. Можливість враховувати неминучі організаційні проблемиу тому числі ставлення до улюблених успадкованих (legacy) систем у розширеній організації. Як багато запропонована централізована чи розподілена архітектура вимагатиме "віддавати функцій іншим підрозділам", "віддавати наших даних" і взагалі чогось "віддавати" порівняно з поточною ситуацією без СУЖЦ? Мейнфрейми масово програли змагання міні-комп'ютерам, а ті – персональним. Назад (до централізованих систем, який неминуче представляється СУЖЦ) шляху майже немає, бо всі дані лежать в окремих додатках, і витягти ці дані в нові системи є найскладнішим організаційним завданням. Як влаштована архітектура СУЖЦ: вона замінює поточні успадковані інженерні програми, вона надбудовується над поточною IT-інфраструктурою, вона встановлюється "дарма" різним службам? Скільки організаційних/менеджерських/консультаційних зусиль потрібно для того, щоб "пропхати" нову технологію? Скільки людей звільнити, скільки знайти та прийняти нових фахівців? Цей критерій організаційної прийнятності тісно пов'язані як з централізацією/децентралізацією, але й розглядом системи мотивації у розширеному підприємстві, тобто. оцінка архітектури СУЖЦ за цим критерієм далеко за межі вузького розгляду лише СУЖЦ, але вимагає ретельного аналізу принципів побудови розширеної організації – до перегляду принципів, які у основі контрактів, якими вона створена. Але це і є суть системного підходу: будь-яка цільова система (в даному випадку - СУЖЦ) розглядається насамперед не "вглиб, з яких частин", а "назовні, частина чого" - не її конструкція та механізм роботи цікаві насамперед, а підтримувана СУЖЦ функція запобігання колізіям у зовнішній надсистемі - і ціна, яку зовнішня надсистема готова платити за цю нову функцію. Тому можливі архітектури СУЖЦ і розглядаються насамперед не з точки зору "пристойних використовуваних технологій, наприклад, від постачальника програмних засобів XYZ" (це за замовчуванням: всі запропоновані варіанти архітектури зазвичай пристойні технологічно, інакше вони не варіанти!), а з точки зору вищеописаних п'яти критеріїв.

Функції СУЖЦ

1. Запобігання колізіям
   1. Управління конфігурацією
      1. Ідентифікація (класифікації, кодування)
      2. Облік конфігурації (всі можливі baseline - ConOp, Architecture, design, as built), у тому числі передача даних до репозиторій СУЖЦ, у тому числі підтримка workflow змін, у тому числі підтримка паралельного інжинірингу (робота в умовах неповних baseline)
      3. Версіонування (включаючи forks)
   2. Відсутність ручного переведення даних (передача вхідних і вихідних даних між вже наявними острівцями автоматизації, включаючи передачу даних з острівців "підйому в цифру" старих проектних напрацювань)
   3. Конфігурація НСІ
   4. Система підтримки колаборативного інжинірингу (відео-конференції, віддалені проектні сесії тощо – можливо, не та, яка використовується для створення самої системи СУЖЦ)
2. Виявлення колізій
   1. Підтримка регістру перевірених видів колізій та відповідних регістру технологій перевірки
   2. Передача даних для перевірки колізій між острівцями автоматизації (без складання в репозиторії СУЖЦ, але засобами інтеграційної технології СУЖЦ)
   3. Прогін workflow перевірки різних видів колізій
      1. у репозиторії СУЖЦ
      2. над репозиторії, але засобами інтеграційної технології СУЖЦ
   4. Запуск прогону workflow усунення знайденої колізії (розсилка повідомлень про колізії, бо прогін workflow усунення – не турбота СУЖЦ)
   5. Підтримка актуального списку неусунених колізій
3. Розвиток(тут СУЖЦ сприймається як автопоетична система, бо «інкрементальність реалізації» входить у найважливіших властивостей самої СУЖЦ -- отже це функція самої СУЖЦ, а чи не функція забезпечує системи для СУЖЦ)
   1. Забезпечення комунікації щодо розвитку СУЖЦ
      1. Планування робіт розвитку СУЖЦ (roadmap, розробка плану заходів)
      2. Функціонування проектного офісу СУЖЦ,
      3. Веде регістр видів перевірок колізій (сам регістр "хотелок" і roadmap реалізації перевірок)
      4. Орг-технічне моделювання (Enterprise Architecture) для СУЖЦ
      5. Інфраструктура комунікації розробників СУЖЦ (інтернет-конференції, відеозв'язок, управління знаннями тощо - можливо, не та, яка використовується в ході колаборативного інжинірингу з використанням СУЖЦ)
   2. Єдиність технології інтеграції даних (наприклад, технологія ISO 15926)
      1. Використання нейтральної моделі даних
         1. Підтримка бібліотеки довідкових даних
         2. Розробка довідкових даних
      2. Технологія підтримки адаптерів до нейтральної моделі даних
   3. Єдиність технології інтеграції workflow/BPM (у масштабах розширеного підприємства)
4. Безпека даних(У масштабах інформаційних систем, що працюють в рамках СУЖЦ)
   1. Забезпечення єдності доступу (один логін та пароль до всіх інформаційних систем, що беруть участь у workflow)
   2. Управління правами доступу до елементів даних
   3. Резервне копіювання