Рубрики

Свежие записи

Аналитическая модель системы интегрированных программных комплексов на базе IBM Rational RequisitePro

GD Star Rating
loading...
GD Star Rating
loading...




Сегодня любая компания, предоставляющая сервис на рынке IT-услуг, рано или поздно сталкивается с необходимостью сопровождения множества информационных систем, в разной степени интегрированных между собой. Естественно, среднестатистическая организация не имеет возможности разрабатывать собственное программное обеспечение для покрытия всех потребностей бизнеса, его закупают, причём, скорее всего, у разных разработчиков. Далее, от специфики задач бизнеса можно выстроить прямую зависимость к зрелости программного комплекса, разработанного для её решения. Если рассматривать такие типичные задачи, как ведение бухгалтерского учёта, управление кадрами, создание внутреннего сервиса электронной почты в организациях, то можно с уверенностью сказать, что на сегодня на рынке имеется ряд качественных и законченных решений от мировых лидеров производства программного обеспечения, которые совершенствуются, в том числе, и в силу наличия прямой конкуренции.

Зайдуллин Рустам, управление «ТатАСУнефть» ОАО «Татнефть» Новичков Александр, ООО СМ-Консалт

Сложнее ситуация обстоит с решениями для менее распространённых задач, имеющих куда большую специфику и большее количество своих нюансов в каждой организации сектора. На деле это оборачивается тем, что для создания IT-инфраструктуры закупается ряд решений от совершенно разных производителей. Зачастую, решения не являются собственно программными продуктами (Программный продукт — это совокупности отдельных программных средств, их документации, гарантий качества, рекламных материалов, мер по обучению пользователей, распространению и сопровождению готового программного обеспечения), а представляют собой программные комплексы, разработанные для собственных нужд. Вполне возможно, что в этом случае при разработке основной целью ставилось оперативное создание функционирующего решения, решающего поставленную задачу, в определённой мере в ущерб архитектуре, производительности и документированию. Сама по себе эксплуатация разнородного программного обеспечения проблема не большая. Хотя у различных производителей представления об удобном пользовательском интерфейсе разнятся, и в итоге конечный пользователь работает с концептуально разными интерфейсами. Настоящие трудности возникают при интеграции решений в единую информационную среду, с созданием интерфейсов между ними и последующим сопровождением этой системы. Описанное в статье решение помогает сделать процесс сопровождения более предсказуемым и прозрачным, а так же, следовательно, и более управляемым. Развивающаяся система, составные части которой тоже, в свою очередь, развиваются или изменяются независимо друг от друга, очень легко и просто может стать неуправляемой и непредсказуемой. Изменения, выполняемые в рамках развития или сопровождения системы в одном из её компонентов, часто могут «аукнуться» там, где, казалось бы, никто этого не ожидал. Так как мы говорим об организации (или подразделении), не начинающей некий проект с нуля, а действующей в сложившихся к определённому моменту времени обстоятельствах, то у неё, скорее всего, уже нет возможности создать целостную концепцию развития всей системы, достаточно детальную и реалистичную для того, чтобы наложить на неё процесс развития. Бизнес требует решения своих задач здесь и сейчас, и если не удовлетворять его требования – найдутся другие, кто сделает это. Выход из этой ситуации – описать с необходимым уровнем детализации уже имеющуюся систему с её компонентами, определить связи между ними (Рисунок 1), и далее использовать эту модель для анализа предполагаемых изменений. При определении детализации описания возникает дилемма: создать достаточно детальное описание всех компонентов, затратив на этом этапе больше ресурсов, или ограничиться определением влияние модулей компонентов системы на другие компоненты (Рисунок 2). В первом случае процесс анализа влияния предполагаемых изменений становится более оперативно выполняемой работой. Во втором – выигрыш в ресурсах на начальной стадии. В дальнейшем же, при обнаружении влияния изменений на компонент, к анализу привлекается эксперт этого компонента

Рисунок 1 – Определение зависимостей модулей компонентов системы

С другой стороны, будь даже модель заранее описана с глубоким уровнем детализации, привлекать экспертов компонентов, на которые обнаружено влияние всё равно придётся. Есть рациональное зерно в том, чтобы изначально не ставить целью создание детального описания. Но опять же, при возникновении необходимости оперативного изменения системы нужных ресурсов может не оказаться, и с этой точки зрения, то, что можно сделать заранее – лучше сделать заранее. Окончательный выбор скорее зависит от сложившегося в организации стиля работы, взаимоотношений между специалистами и других факторов, главное, что это решение должно быть принято, доведено до всех лиц, которых оно затрагивает, и дальнейшая работа должна вестись согласно этому решению.

Рисунок 2 – Определение связей модулей компонента с другими компонентами системы

Было бы довольно проблематично реализовать на практике описанную систему без использования специализированного инструментария. Описание компонентов можно было бы выполнить в виде стандартизованных документов, указать в них ссылки на связанные элементы, но дальнейшее использование этих документов, и, в частности, отслеживание влияния изменений на зависимые элементы вручную, представляется совершенно не рациональным действием. Более того, «плоские» документы не дают возможности фильтровать информацию, отсеять излишние в определённом случае данные, выделить по заданным критериям нужные. В итоге эффективность реализации на базе обычных документов достаточно низкая.

Рисунок 3 – Форма Requisite Pro

Реализацию такого инструмента для анализа изменений мы выполняем на базе продукта IBM Rational Requisite Pro. Приведённые выше иллюстрации – примеры форм RequisitePro для описываемой схемы. Данный продукт позволяет создать логически и иерархически структурированную среду в соответствии с поставленной задачей, определить связи между объектами среды, просматривать информацию под нужным ракурсом посредством настраиваемых представлений и, что самое главное, при изменении описания одного из объектов, даст знать, на какие объекты это повлияет (Рисунок 3). Для структуризации характеристик информационных систем можно использовать разбивку описания на заголовочную часть и подсистемы в виде отдельных сущностей (по аналогии с типами требований). Для выделения отдельных параметров можно так же определить атрибуты (Рисунок 4). В дальнейшем это даст возможность сортировать и фильтровать информацию по этим параметрам.

Рисунок 4 – Выделенные атрибуты

Кроме всего вышесказанного, Requisite Pro так же позволяет создать и получать необходимые отчёты, а с помощью дополнительного инструмента IBM Rational SoDA – и в привычном формате документов MS Word. Об авторах: Зайдуллин Рустам работает в области информационных технологий с 2005 года. Имеет опыт адаптации и внедрения RUP и инструментальных средств IBM Rational. Имеет следующие сертификаты: IBM Certified Solution Designer — IBM Rational Unified Process V7.0, IBM Certified Specialist — Rational Requirements Management w/Use Cases v2003, IBM Certified Administrator — IBM Rational ClearCase for Windows. Является ведущим инженером группы контроля качества процессов разработки программного обеспечения управления «ТатАСУнефть» ОАО «Татнефть».

Новичков Александр — работает в области информационных технологий с 1994 года. Является руководителем отдела консалтинга и внедрения IBM Rational. Участвовал более чем в 20 успешных проектах внедрения IBM Rational в таких организациях как Банк внешней торговли, ОАО «Татнефть», Национальный банк «ТРАСТ», Банк «Русский стандарт», ОАО «Иркут Авиа», ЗАО «АйТи», ЗАО «Аплана», Сбербанк России, Центральный банк Российской Федерации, ОАО «Русский алюминий» и многих других. Имеет более 30 публикаций научных и научно-популярных материалов. Является сертифицированным специалистом по следующим продуктам IBM Rational: ClearCase for Windows, ClearQuest for Windows и UCM Essentials. За время работы в консалтинге им обучено более 500 специалистов ведущих IT-компаний России и СНГ. Является руководителем отдела внедрения и консалтинга в компании СМ-Консалт (www.cmcons.com). Связаться с ним можно по адресу rational.tools.info@gmail.com

Аналитическая модель системы интегрированных программных комплексов на базе IBM Rational RequisitePro, 10.0 out of 10 based on 1 rating

Связные и просто интересные записи:

Метки:ibm, rational, requisite pro, use-case, требования, управление

2 comments to Аналитическая модель системы интегрированных программных комплексов на базе IBM Rational RequisitePro

  • Честно говоря Rational уже давно упустила свой рынок, отхватив большую его часть. Нынешние попытки IBM реанимировать свои продукты, например, через Jazz пока вряд ли можно назвать удачными.

    Мы решили отказаться от их продуктов в пользу DEVPROM, современного и недорого инструмента управления жизненным циклом продуктов. Кстати, возможность поддержки большого количества программных проектов реализуется при использовании «Облака проектов», интегрированного DEVPROM.

    GD Star Rating
    loading...
    GD Star Rating
    loading...
  • О потере всего рынка трудно говорить… Речь идет о потере сегмента low-lewel, где находятся небольшие команды разработчиков. Да, этот сегмент давно утерян для IBM. Тут вопросов нет.
    На рынке крупных компаний дело обстоит по-другому.

    А новое инструментальное средство при наличии правильной методологии — вызывает только положительные эмоции :)
    Я посмотрю данный продукт и сделаю собственные выводы

    GD Star Rating
    loading...
    GD Star Rating
    loading...

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam protection by WP Captcha-Free