Управління життєвим циклом додатків, Комерція, Різне, статті

Стратегія і продукти компанії Borland


Зміст



Відомо, що багато користувачів (і, що гріха таїти, деякі 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. Borland CaliberRM

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

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

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

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


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

Для проектування додатків і даних компанією Borland пропонується продукт Borland Together (

Рис. 3. Borland Together Control Center

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

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


Створення коду програми – область, в якій компанія Borland спеціалізується протягом усіх 20 років свого існування. Сьогодні Borland виробляє засоби розробки для платформ Windows, Linux, Solaris, Microsoft. NET, а також для ряду мобільних платформ. Ми вже неодноразово писали про засоби розробки цієї компанії, і в даній статті повторюватися не будемо. Зазначимо лише, що останні версії засобів розробки цієї компанії (Borland С # 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 Optimizeit Profiler for Microsoft. NET

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


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

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


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

Для вирішення даної задачі можна застосовувати Borland StarTeam (

Рис. 5. Borland StarTeam

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

Замість висновку


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

Рис. 6. Життєвий цикл програм з позиції компанії Borland

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



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


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

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

Ваш отзыв

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

*

*