Управління життєвим циклом підприємства з використанням інструментальної лінійки IBM Rational / Telelogic. IBM Rational / Telelogic DOORS. Частина 3., Комерція, Різне, статті

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

Налаштувавши і оптимізувавши за допомогою System Architect [Enterprize Architecture] ваші бізнес-процеси, а з допомогою Focal Point [Product Management] визначивши той пріоритетний список вимог, які ви припускаєте втілити в новому продукті, ви можете скористатися підходом IBM Rational / Telelogic для ALM [Application Lifecycle Management].


Замкнутий цикл виробництва інженерних систем або програмних додатків може бути представлений у вигляді послідовності етапів:



Активність на кожному з цих етапів підтримується різними інструментами лінійки IBM Rational / Telelogic, які можуть бути позиціоновані наступним чином:



Більш докладно використання та взаємодія інструментів IBM Rational / Telelogic в рамках управління життєвим циклом розробки додатків викладено в документі:


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

IBM Rational / Telelogic DOORS [Requirements Management].


Загальна назва IBM Rational / Telelogic DOORS , Під яким воно відоме у всьому світі, належить власне продукту DOORS і двом його основним опцій, які призначені для керування вимогами:



IBM Rational / Telelogic DOORS – Інструмент “відкриває” лінійку інструментів IBM Rational / Telelogic, відповідаючи, як за початковий етап збору і формулювання вимог по проекту (Requirements Management), так і за весь життєвий цикл реалізації проекту.


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


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


1. Важко працювати з великими обсягами інформації


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



2. При роботі з документами дуже важко контролювати і відслідковувати постійно вносяться зміни (особливо, якщо число службових копій досить велике), так що немає впевненості, що кожен із співробітників працює з останнім варіантом документа. Працюючи в середовищі DOORS, ви можете бути впевнені, що перед очима користувача буде завжди сама остання версія, тому що всі користувачі працюють в режимі online (Предумотрени і інші можливості). Більш того, в базі даних DOORS зберігається вся історія внесених змін – хто, коли, в яку сесію, під яким ім’ям і що саме змінював у тексті вимоги. Зберігається також інформація і про baselines і є можливість їх порівняння. Якщо буде потрібно, то всього лише натисненням пари клавіш, ви можете повернутися до будь-якої з попередніх редакцій конкретного вимоги або шуканої версії baseline.


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


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


5. При роботі з великим числом документів, та ще й чималих обсягів, буває важко пов’язати між собою різні вимоги або “блоки” інформації, які так чи інакше повинні бути пов’язані і братися до увагу при роботі – посилання на ГОСТи, закони чи постанови, прив’язка до нормативних документів або рекомендацій і т.д. Знаходиться в DOORS документ, зберігаючи стилістику і цілісність звичайного документа, відображається на екрані у вигляді набору окремих об’єктів, які за допомогою вбудованого механізму (drag & drop) лінкування – можуть бути легко пов’язані між собою як в рамках одного документа, так і в різних і незалежних документів. Працюючи з одним документом, натисканням клавіші на позначення зв’язку, ви відкриваєте інший відповідний документ і саме в потрібному місці. Це значно полегшує пошук необхідної інформації і прискорює роботу з нею. Механізм трасування та інтеграційні можливості DOORS забезпечують глибокий зв’язок між вимогами верхнього рівня (користувача) і всіма наступними документами, задіяними на різних етапах процесу виробництва ПЗ, аж до прив’язки вимоги (через системні вимоги, функціональні вимоги, діаграми, тестові модулі і т.д.) до конкретного коду, забезпечує реалізацію цієї вимоги, і результатами тестування.


6. Найчастіше деякі вимоги не враховуються “губляться” і замовник не отримує якісний продукт. Це загальна біда всіх проектів. Та ж всюдисуща статистика каже, що майже 75% загального числа проектів не реалізують всіх поставлених завдань. Для боротьби з такого роду помилками в DOORS вбудований механізм перевірки неврахованих, неперевірених і не схильних до вимог. А також механізм виявлення “підозрілих” зв’язків (suspect links). Це значно полегшує контроль за реалізацією всіх вимог проекту.


7. Ми вже давно працюємо так як звикли, наші поточні проекти знаходяться на різних стадіях і є побоювання, що при переході на нові технології, ми втратимо темпи робіт. Представляючи з себе як інтерфейс користувача – якийсь симбіоз Word і Excel, але, володіючи значно більшими можливостями, DOORS дуже легкий в освоєнні – досить 24 тижнів самостійного вивчення, щоб почати працювати з ним, вже на 6080% використовуючи закладені можливості (при необхідності можливе навчання фахівців у вас в офісі на будь-якій стадії роботи з інструментом). Нові проекти можуть починатися безпосередньо в середовищі DOORS, а для поточних передбачена проста можливість експорту-імпорту віз Word або Excel.


8. Планові терміни закінчення проектів часто зриваються. Ви далеко не самотні в цьому. Давно пораховано, що середній проект “спізнюється” на 220% від планових показників. Правильно поставлені і увезення між собою завдання на самих ранніх етапах проекту (DOORS) і подальший контроль їх виконання (Project Management tools) значно скорочують терміни реалізації проектів. А підтримка колективної та командної роботи, яку забезпечує DOORS, ще й знижує не плановий і не контрольований витрата часу, дозволяючи керівництву компанії мати перед очима необхідну інформацію і контролювати процес виконання робіт в режимі on-line.


9. Є побоювання, що все це добре виглядає на папері, але може не виправдати передбачуваних вкладень. Численні відгуки наших користувачів, що працюють з DOORS, лише підтверджують викладені (і ще багато інших) переваги інструменту. На вашу вимогу ми готові надати і конкретні посилання використання DOORS, і звіти аналітиків, і будь-яку іншу інформацію. Крім того, існують методики розрахунку (ReturnOnInvestment), які теж підтверджують, що вкладення в DOORS – за рахунок значного підвищення ефективності праці окупаються вже через 35 місяців. DOORS може мати одну або кілька баз даних з ієрархічною схемою доступу до них і кілька опцій для роботи в офісі по локальній мережі і для роботи через WEB-інтерфейс (віддалені користувачі, замовники, розподілені команди):


DOORS – Інструмент з власною базою даних, призначений для роботи користувачів в єдиній мережі, повний функціонал;


DWA ­online робота через WEB-інтерфейс (віддалені користувачі, підрозділи, замовники), кілька обмежений (спеціально) функціонал (функціонує тільки як опція DOORS, самостійно не використовується).



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


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


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


За даними аналітиків незалежної компанії The Standish Group:



DOORS з легкістю вирішує всі ці проблеми, оскільки в нього закладені певні види аналізу (Impact analyze, Traceability analyze, Coverage analyze, Change Proposal System), що дозволяють управляти і контролювати процес реалізації вимог і внесення та відпрацювання змін на всьому життєвому циклі проекту.



В будь-який момент часу DOORS може показати:



а також допоможе:



Підтвердженням великих можливостей DOORS можуть служити висновки аналітиків різних незалежних компаній – Yphise, Standish Group, META Group, Ovum, високо оцінюють інструмент.


Так, наприклад, останній (серпень, 2006) звіт компанії Yphise “RequirementsDriven Development” позиціонує DOORS у всіх номінаціях, як безперечного лідера серед інструментів для керування вимогами:



1. Оптимізація вимог для досягнення цілей бізнесу: a) Можливість структурувати і моделювати вимоги b) Можливість збирати і підтримувати потреби замовника


2. Оптимізація масштабування проектів: a) Можливість формувати базові версії b) Можливість аналізувати та деталізувати вимоги


3. Оптимізація відносин з замовниками: a) Можливість демонструвати реалізацію вимог b) Можливість документувати угоди і домовленості


4. Підтримка розробки на основі управління вимогами: a) Можливість контролювати розробки b) Можливість контролювати процеси управління вимогами


А компанія Standish Group уже кілька років поспіль відводить DOORS лідируючу позицію ще й за ступенем охоплення ринку – більше 36% світового ринку на сьогоднішній день.


DOORS/Analyst (Add­On)


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


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



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


Пропонована користувачам опція DOORS / Analyst, що працює спільно з DOORS, дозволяє вирішити ці проблеми оскільки привносить безпосередньо в DOORS можливість моделювати вимоги, використовую нотацію мови UML 2.1.


Оскільки DOORS / Analyst ні на крок не відходить від стандарту UML 2.1, то такий підхід дозволяє згодом “збирати” різні діаграми в єдине ціле, використовуючи більш потужний засіб моделювання IBM Rational / Telelogic Tau (або третьої сторони) для перевірки та відпрацювання функціоналу создаваемогой системи, для симуляції поведінки програми або автогенерації коду.


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


http://www.interface.ru/home.asp?artId=9268.


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


Якщо у вас з’явиться бажання протестувати роботу IBM Rational / Telelogic FocalPoint на своєму робочому місці, то зверніться до нас (mail@interface.ru), і ми організуємо для вас evaluation останньої версії продукту з усіма тими опціями, які вам необхідні.
 
Читати частина 4
 

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


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

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

Ваш отзыв

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

*

*