1. із шляхів вирішення цього завдання полягає в наданні розробникам безкоштовного інструментарію для управління...
2. архітектура
3. компоненти системи
4. проектний портал
5. Інтеграційна середовище та модуль управління методологією
6. Модуль управління вимогами
7. Модуль управління роботами
8. Модуль управління помилками та змінами
9. Модуль конфігураційного управління
10. Модуль управління тестуванням
11. Управління вимогами в NAT
12. Wiki - платформа управління вимогами

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

Система Naumen Agile Tools (NAT) створюється в рамках Федеральної цільової науково-технічної програми «Дослідження і розробки за пріоритетними напрямами розвитку науки і техніки», розрахованої на 2002-2006 роки ( www.fcntp.ru ). NAT не конкурує з комерційними інструментами розробки. Завдання системи полягає у формуванні первісної технології та культури виробництва програмного забезпечення. Надалі компанія-розробник зможе свідомо обирати більш спеціалізований інструментарій. Крім того, безкоштовна, відкрита і функціонально повна система NAT може виявитися корисною при навчанні студентів технологіям промислової розробки програмного забезпечення.

проект NAT

NAT - система автоматизації процесів компаній, що розробляють програмне забезпечення ділового призначення, але ще не мають достатнього досвіду і розвиненою технології виробництва. Орієнтація на розробку програм ділового призначення визначило акцент на «швидкі» (agile) технології і досить прості методології управління, доступні початківцям колективам. Ключовим в системі є модуль управління вимогами, одне із завдань якого - трасування вимог на всіх етапах розробки (облік і контроль їх взаємозв'язків, до виконуваних робіт, кодом, релізами, тестами і т.п.). Для виконання цих завдань необхідна інтеграція модулів, керуючих усіма етапами розробки. Можливість трасування - найважливіша вимога управління якістю розробки в CMMI.

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

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

Крім того, реалізований перший варіант наскрізного управління вимогами, роботами і кодом. Отримано прототип управління вимогами на основі технологій wiki.

архітектура

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

Модульна структура

Система NAT (рис. 1) охоплює управління вимогами (розробка, взаємна ув'язка і контроль над станом вимог), роботами (проектне управління кодуванням, створенням тестів, тестуванням, документуванням), конфігураційне управління (управління версіями коду, тестів, документації, конфігураціями, релізами ), управління тестуванням (планування та розробка тестів, тестування, облік і контроль над результатами тестів), помилками і змінами.

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

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

Базовий процес розробки

Базовий процес розробки полягає в налаштуванні процесного сервісу інтеграційного середовища ( Мал. 2 ). При цьому можна задати будь-яку методологію і будь-яку модель розробки.

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

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

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

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

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

Основні сутності і зв'язку

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

1. Проекти створюються в модулі «Проектний портал» і реєструються в довіднику.
2. На основі проектів в модулі «Управління вимогами» розробляються системи вимог. Самі вимоги, їх зв'язку між собою і з проектами реєструються в довіднику.
3. На основі вимог в модулі «Управління роботами» створюються завдання. Разом з їх зв'язками і вимогами вони реєструються в довіднику.
4. Відповідно до запланованих завдань в модулі «Конфігураційне управління» створюються версії модулів програмного забезпечення, що, які реєструються в довіднику.
5. На основі версій модулів в модулі «Управління роботами» фіксуються звіти про трудовитратах, які реєструються в довіднику разом зі зв'язками з версіями і завданнями.
6. Відповідно до завдань в модулі «Тести? Рова? Ня» розробляються тести. Вони реєструються в довіднику. Залежно від типу тесту реєструються зв'язку тестів з модулями і пакетами вимог.
7. У модулі «Управління помилками і змінами» формуються запити. Вони реєструються в довіднику.
8. Відповідно до запитів на зміни в модулі «Управління вимогами» розробляються пакети змін вимог. Вони реєструються в довіднику разом зі зв'язками із запитами на зміни.
9. На основі запитів на виправлення помилок в модулі «Управління роботами» плануються роботи. Вони реєструються в довіднику разом зі зв'язками із запитами на виправлення помилок.

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

компоненти системи

Багато компонентів NAT є продуктами, які виконують окремі функції ( Мал. 4 ). Компоненти були відібрані на основі дослідження продуктів категорії Open Source. Надалі планується вести постійний моніторинг продуктів і при наявності належних підстав замінювати версії або компоненти. Серед компонентів - і оригінальні розробки компанії Naumen, в тому числі модуль управління вимогами NAT RM, інтеграційна середовище та модуль управління методологією Naumen Kernel, проектний портал NAT PRG. Крім того, в рамках проекту розробляються продукти, що забезпечують адаптацію інтегрованих компонетов до інтеграційної середовищі.

При відборі компонентів до них висувалися такі вимоги, як стабільність роботи, перспективність, тип ліцензування, підтримка певних методологій розробки (насамперед, гнучких) і стандартів (переважно ISO 9001 і CMMI), наявність достатньої технічної бази та інтеграційних можливостей (якісний API, розрахований на багато користувачів і многопроектной режими роботи, підтримка BPEL, IDE Eclipse, C ++, Java 1.4, JDK 1.4, використання стандартів HTML 4.0, CSS, JavaScript 1.0, JSP, серверів Tomcat 5.x, Apache, СУБД PostgreSQL і FireBird).

проектний портал

Основна вимога до проектного порталу - підтримка стандарту JSR 168 на портлет. Вони дозволяють істотно збільшити швидкість розробки додатків, додаткових модулів і позбавляють від необхідності вивчати код самого порталу. Дослідження показали, що вибір відкритих компонентів для порталу вельми обмежений. Були розглянуті системи JBoss Portal, eXo Platform, LifeRay, JetSpeed. Найкращим був визнаний JBoss Portal, але і він не цілком задовольняє загальним вимогам, в тому числі до функціональності і технічній базі. Тому на даному етапі проекту прийнято рішення про самостійну розробку проектного порталу під робочою назвою NAT PRG.

Інтеграційна середовище та модуль управління методологією

Управління методологією розглядається в двох аспектах. Перший аспект - управління ролями, процесами і посилальними інформаційними зв'язками; другий - управління номенклатурою і форматами документів, атрибутами сутностей. Інтеграційну середу і модуль управління методологією слід розглядати як пов'язану підсистему, що включає в себе компоненти наступних типів: сервісна шина, сервіс процессной інтеграції та відповідні засоби управління, сервіс посилальної інтеграції ( «довідник») і відповідні засоби управління, засоби управління внутрішніми налаштуваннями модулів NAT, пов'язаними з методологією проектів.

Основною вимогою до сервісної шині є підтримка стандарту Java Business Integration 1.0 (JSR-208). Підключення сервісів по протоколу SOAP 1.1 через HTTP, а систем обміну повідомленнями - по інтерфейсу JMS. Від неї чекають виконання трансформації XML через XSLT, динамічної маршрутизації повідомлень (XPath, XQuery), підключення зовнішньої BPEL-середовища для управління процесами. Нарешті, сервісна шина повинна мати засоби управління по протоколу JMX або специфікаціям WS-Management, відстежувати невідправлені повідомлення і ініціювати їх повторну доставку, підтримувати аудит обміну повідомленнями між компонентами, ведення протоколів подій.

В ході досліджень були розглянуті сім відкритих продуктів для побудови сервісних шин (ServiceMix, Open ESB, ObjectWeb Petals, Mule ESB, ObjectWeb Celtix, Mule JBI, Apache Synapse) і 11 комерційних. Найбільш функціонально повними серед відкритих продуктів визнані Mule ESB і ServiceMix. Як компонент системи обраний ServiceMix, оскільки він, зокрема, повністю реалізує стандарт JBI.

Основною вимогою до засобів управління процесами є реалізація стандарту BPEL (зокрема, BPEL4WS 1.1) і стандарту JBI для підключення до сервісної шині. Були досліджені шість відкритих продуктів, що реалізують BPEL (Active BPEL Engine, Apache Agila, Bexee BPEL Execution, Eclipse ALF, eMAXX MOBE, Process eXecution Engine PXE). Як компонент NAT обраний PXE як найбільш функціональний, що відповідає стандарту JBI і має засоби управління, достатні для реалізації відповідного підмодуля управління методологією.

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

Модуль управління вимогами

Основна вимога до модуля управління вимогами - ведення взаємопов'язаних систем вимог протягом усього проекту, ув'язка вимог з роботами, релізами, тестами і т.п., а також трасування вимог і контроль за їх станом на основі станів пов'язаних сутностей. В ході досліджень були розглянуті дев'ять відкритих продуктів управління вимогами (Ophelia DRES, Essential Management, RegSimile, OpenShore, Report Requirement Documenter, Rambutan, Jeremia, Enager, RAVE), але, як з'ясувалося, жоден з них не придатний в якості компонента системи NAT . Вирішено самостійно розробити модуль під робочою назвою NAT RM.

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

Модуль управління роботами

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

В ході аналізу були розглянуті 35 відкритих продуктів. Як компонент управління роботами обраний XPlanner, який вирішено вдосконалити для виконання вимог до системи NAT.

Модуль управління помилками та змінами

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

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

Модуль конфігураційного управління

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

У проекті NAT до подмодулей управління версіями пред'являються такі додаткові вимоги: наявність централізованого сховища кодів; транзакційна атомарность операцій з репозиторієм, що гарантує його постійно стабільний стан; відстеження порядкової історії файлів. Ми проаналізували 33 відкритих продукту для управління кодом, і явним лідером виявився Subversion, який і був прийнятий як компонент NAT. При сприятливих умовах Bazaar-NG і GIT теж можуть виявитися кращими.

Специфічним вимогою до модуля управління релізами і конфігураціями є підтримка повного циклу випуску релізу, в тому числі компіляції додатка, створення документації і повністю скомплектованих дистрибутивів, розміщення додатка на сервері і генерації звітів про роботу системи. Ми розглянули 24 відкритих продукту і вибрали Apache Maven 2, Apache Ant і Continuum. Як компонент NAT, службовця для управління релізами, обраний Apache Maven 2. У майбутньому, при включенні в NAT функцій автоматичної і безперервної збірки, для цієї мети передбачається використовувати систему Continuum.

Модуль управління тестуванням

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

Були проаналізовані особливості 33 відкритих продуктів. Сформовано набір з восьми продуктів для використання в якості компонентів NAT: модульне тестування - Junit; перевірка коду - Checkstlye; інтеграційне тестування - MockCreator; тестування Java GUI - Abbot; тестування Web GUI - Jameleon; тестування навантаження - Jmeter; профілювання та аналіз покриття коду - Eclipse TPTP; генерація даних - TestGen.

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

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

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

Wiki - платформа управління вимогами

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

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

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

Проте модуль управління вимогами на базі wiki цілком можна розглядати як «легкий» варіант для початкового застосування. Для промислової реалізації буде створено модуль на основі Naumen Kernel - відкритої платформи для розробки бізнес-додатків. Він включає в себе стандартний Web-сервер, встановлену на ньому wiki-платформу MoinMoin і пакет макросів для управління вимогами. Запуск системи зводиться до створення початкової сторінки з викликом інсталяційного макросу, який формує необхідну сукупність вкладених wiki-сторінок. Після цього система готова до роботи.

Олексій Сівенцев ( [email protected] ) - технічний директор проекту Naumen Agile Tools, компанія Naumen (Москва).