СМ-Консалт
 

MDD. Общий обзор и концепция разработки, управляемой моделями

Статьи Другие статьи

Примечание. Авторы употребляют слово Solution, подчеркивая пригодность подхода к разработке программных продуктов самого разного размера и направления, включая традиционные информационные системы, интеграционные шины (как в рассматриваемом в книге примере), отдельные компоненты и т. д.

1.1 Текущее бизнес-окружение и движущие силы


Разработка информационных технологий (IT) происходит не в изоляции. Целью IT является облегчение работы в бизнесе. Потребности бизнеса и направляют разработку информационных технологий.

В настоящее время бизнес оказывает наибольшее влияние на informative technology по следующим направлениям:

  • Бизнес «по требованию». Поскольку ожидается, что бизнес будет все более приспосабливающимся и гибким, такими должны быть и системы, которые на него работают.
  • Значимость для бизнеса. Сейчас больше, чем когда-либо, IT-подразделения должны концентрироваться на том, что представляет ценность для бизнеса. Программное обеспечение должно быть нужным для бизнеса. Недостаток взаимопонимания между бизнесом и сотрудниками IT-подразделений может привести к результатам, успешным с точки зрения IT, но неприемлемым для бизнеса.
  • Контроль стоимости. Те дни, когда в IT деньги инвестировались в зависимости от убедительности обещаний, давно прошли. Теперь ГТ-подразделения работают в рамках жестких бюджетных ограничений и от вложений денег требуется отдача.
  • Увеличение сложности. Программные системы продолжают увеличиваться по масштабам и по сложности. Методы, которые хорошо подходят для маломасштабной разработки, не всегда можно перенести на проекты масштаба предприятия.
  • Наличие квалифицированных кадров. Сложность современных IT-платформ означает, что для выпуска программного обеспечения требуются специальные навыки. Многие организации борются за опытных, квалифицированных профессионалов, которые могут участвовать в их разработке. Кроме того, проекты часто зависят от ключевых специалистов и очень страдают, если такие люди покидают проект или организацию.
  • Изменение платформенного окружения. Современные приложения устанавливаются на большое количество программных платформ, и скорость изменения технологий, на которых базируются платформы, совершенно не собирается уменьшаться. Бизнес хочет пользоваться преимуществами новых возможностей промежуточного программного обеспечения, но при этом не хочет, чтобы приложения постоянно переписывались.

 


1.2 Управляемый моделями подход к разработке программного обеспечения


Разработка, управляемая моделями, — это такой стиль разработки программ, когда главными артефактами являются модели, а по ним генерируется код и другие прикладные артефакты.

Модель — это описание системы с конкретной точки зрения, которое допускает пропуск несущественных деталей, чтобы интересующие характеристики были видны наиболее отчетливо. Например, инженер-проектировщик строительных конструкций создает модель здания, с помощью которой можно определить его несущие, нагрузочные характеристики.

В MDD мы вводим дополнительный критерий, состоящий в том, что модель должна читаться машиной. Например, мы должны иметь доступ к содержимому модели в автоматическом режиме. Возможность чтения машиной — необходимая предпосылка для генерации артефактов. Диаграмма, нарисованная на доске, может удовлетворять другим критериям модели, однако до тех пор, пока мы не переведем ее в форму, доступную для машины, мы не сможем использовать ее в цепочке инструментов разработки, управляемой моделями.

Программные модели, как правило, разрабатываются на унифицированном языке моделирования (Unified Modeling Language, UML). UML — это язык для определения, визуализации и документирования программных систем. UML предоставляет нотацию и соответствующую семантику для моделей программных систем. В UML также есть стандартный метод сериализации в понимаемый машиной формат, что предоставляет возможности для автоматизации.

Примечание. Для сериализации UML-моделей и других моделей, поддерживающих стандарт Meta Object Facility (MOF)1, используется формат XML Metadata Interchange (XMI).

Примечание. Стандарт OMG, определяет общие интерфейсы и семантику для взаимодействующих метамо-делей. Он определяет также спецификацию интерфейса для управления моделями с помощью программных API.

В моделях программных систем детали технической реализации скрываются, поэтому систему можно проектировать, используя концепции предметной области приложения. Проектирование приложения, как правило, выполняется с помощью инструмента для UML-моделирования, например Rational Software Architect, с использованием концепций, значимых в предметной области.

Примечание. Также возможно моделирование с помощью языка, специфичного для предметной области. Такой подход обсуждается дальше, в подразделе 6.2.1, «IBM и MDA».

Например, при работе в области интеграции масштаба предприятия мы бы начали с моделирования дизайна приложения с использованием таких концепций, как «сообщение», «прокси» и «адаптер». Позже мы можем уточнить модель программной системы и проработать детали компонентов.

1.2.1 Модели как наброски и чертежи


Применение моделей в разработке программного обеспечения — это принятая практика (хотя, конечно, и неповсеместная). В настоящее время модели применяются, главным образом как наброски, которые передают какие-то аспекты системы, или как чертежи, подробно описывающие дизайн, который вы вручную реализуете.

Применение моделей в качестве документации и спецификаций весьма полезно, но для этого необходима строгая дисциплина, чтобы обеспечить соответствие моделей ходу реализации. Гораздо чаще оказывается, что под давлением сроков реализация обновляется без обновления моделей. Неточные модели могут оказаться большим злом, чем полное отсутствие моделей.

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

1.2.2 Точные модели позволяют осуществлять автоматизацию


В MDD модели используются не только как наброски или чертежи, но и как основные артефакты, из которых с помощью трансформаций эффективно создаются реализации. В MDD модели, ориентированные на предметную область приложения, являются основным ориентиром при разработке программных компонентов. Код и другие целевые артефакты генерируются при помощи трансформаций, разработанных с участием как экспертов по моделированию, так и экспертов в предметной области.

MDD потенциально может значительно уменьшить стоимость разработки решения, улучшить согласованность его отдельных частей и качество решения в целом. Достигается это за счет использования автоматизированных шаблонов реализации с трансформациями, которые устраняют необходимость в многократном повторении технических действий при разработке. Вместо того чтобы каждый раз вручную применять технические навыки для создания артефактов решений, можно закодировать технические навыки в трансформациях. Такой подход имеет преимущества, как в консистентности решения, так и в удобстве его поддержки. Измененную трансформацию, отражающую изменение архитектуры реализации, можно быстро использовать заново для генерации артефактов решения.

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

Опыт работы с платформами записывается прямо в трансформации, а не документируется в руководствах к проекту или, что еще хуже, не изобретается по нескольку раз за проект. Точно так же решения о реализации архитектуры записываются прямо в трансформации, а не документируются в виде архитектурных решений.

В зависимости от ситуации вы можете применять готовые трансформации, которые доступны как напрямую, так и на основе расширения. В качестве альтернативы вы можете создавать для проекта свои собственные трансформации.

1.2.3 Роль шаблонов в разработке, управляемой моделями


Шаблон (pattern) — это решение повторяющейся проблемы в конкретном контексте. Шаблоны заключают в себе время, навыки и знания разработчика, потраченные им на решение проблемы. Если шаблоны использовать многократно в разных проектах, они становятся общепризнанными практическими методами.

Программные шаблоны можно применять в пределах уровня абстракции (например, шаблоны дизайна и шаблоны реализации) и между уровнями абстракции (например, шаблоны для соответствующих элементов дизайна и кода). Вы можете комбинировать шаблоны, создавая наборы шаблонов для решения более крупных проблем, и языки шаблонов для описания наилучших типовых решений для предметной области.

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

1.2.4 Не только код


Генерация кода и других артефактов, связанных с платформой реализации, — это важная часть MDD, но автоматизация в стиле MDD делает гораздо больше. В проекте по разработке программного обеспечения должно производиться множество не относящихся к коду артефактов и многие из них могут полностью или частично создаваться на основе моделей. В приведенном ниже перечне показано несколько типичных примеров артефактов, генерируемых по моделям, но вы можете придумать и другие.

  • Документация. В организациях, которые следуют формализованному подходу к разработке, создание документации является существенной частью всей работы. Общеизвестно, что поддерживать соответствие документации и реализации сложно. Если вы используете MDD, то документы генерируются по моделям, что обеспечивает актуальность документации и делает информацию доступной в моделях, с которыми разработчик встречается ежедневно, а не только в документах, навигация по которым бывает весьма сложной. Документацию позволяют сгенерировать такие инструменты, как IBM Rational SoDA® и IBM Rational Software Architect Report Generator, или же документация генерируется при помощи трансформаций.
    Примечание. SoDA® является сокращением от IBM Rational Software Documentation Automation. Чтобы больше узнать о SoDA, обращайтесь по адресу: http://www.ibm.com/software/awdtools/soda/
  • Артефакты тестирования. Существует возможность генерировать базовые наборы тестов (например, с помощью JUnit) по информации, содержащейся в моделях.
    Примечание. Кроме того, в RSA Java-код, сгенерированный по моделям, можно применять для генерации кода тестирования компонентов (Component Test).
    Если проводить специальное моделирование тестов (например, с помощью UML Profile for Testing), то генерируется полный набор тестов. Тестирование, основанное на моделях, — это дисциплина, связанная с генерацией тестов по моделям.
  • Скрипты для сборки и размещения. Используя свой опыт, архитекторы по компоновке и размещению могут создавать трансформации, позволяющие генерировать скрипты для сборки и размещения.
  • Другие модели. Для систем используется много взаимосвязанных моделей на различных уровнях абстракции (анализ, проектирование, реализация), отражающих различные части системы (пользовательский интерфейс, бизнес-логику, системное администрирование), различные проблемы (безопасность, производительность и устойчивость) или различные задачи (тестирование, развертывание). Во многих случаях существует возможность частично создавать одну модель на основе другой, переходя, например, от модели анализа к модели дизайна или от модели приложения к модели тестирования.
  • Применение шаблонов. Шаблоны фиксируют наилучшие практические решения часто возникающих проблем. В шаблонах указываются характеристики элементов моделей и взаимосвязи между элементами. Вы можете автоматизировать шаблоны, создавая новые элементы и изменяя существующие в соответствии с шаблоном, когда шаблон применяется к модели.

 

Когда мы говорим в этой книге об MDD, мы включаем сюда, помимо генерации кода, все эти методы.


1.3 Преимущества разработки, управляемой моделями


Разработка, управляемая моделями, потенциально способна значительно улучшить современную общепринятую практику разработки программного обеспечения. Преимущества MDD следующие:

  • Повышение производительности. MDD снижает стоимость разработки программного обеспечения с помощью генерации кода и артефактов по моделям, что повышает производительность труда разработчика. Обратите внимание, что вы должны учитывать стоимость разработки (или приобретения) трансформаций, но тщательное планирование обеспечит общее снижение стоимости работ.
  • Удобство обслуживания. Технологический прогресс приводит к тому, что компоненты решений становятся тяжелым наследством технологий предыдущих платформ. MDD помогает решить эту проблему, создавая удобную для поддержки архитектуру, изменения в которую вносятся быстро и связно, что позволяет более эффективно переводить компоненты на новые технологии.
    Высокоуровневые модели остаются свободными от несущественных деталей реализации. Свобода от деталей реализации позволяет справиться с изменением базовых технологий платформ и их технической архитектуры.
    Такая гибкость также означает, что вы можете попробовать несколько разных идей, прежде чем прийти к окончательному решению. Кроме того, плохие решения легко изменить. Проекты по разработке программ часто страдают от решений, которые оказываются с течением времени ошибочными, но исправление ошибки становится слишком накладным.
  • Повторное использование унаследованных компонентов. Вы можете моделировать на UML существующие решения для платформы. Если на одной платформе было реализовано много компонентов, вы можете разработать обратные трансформации — из компонентов в UML. Тогда вы будете иметь возможность переводить компоненты на новую платформу или генерировать оболочки, чтобы к унаследованному компоненту можно было обращаться через интеграционные технологии, например через Web-службы.
  • Адаптируемость. Возможность адаптации — это ключевое требование бизнеса, и IT-системы должны поддерживать его. При использовании MDD добавление или модификация бизнес-функции становится достаточно простым делом, поскольку инвестиции в автоматизацию уже сделаны. При добавлении новой бизнес-функции вам нужно только разработать поведение, относящееся к этой новой функции. Вся остальная информация, необходимая для генерации артефактов реализации, уже заключена в трансформациях.
  • Согласованность. Ручное применение практик кодирования и архитектурных решений весьма способствует появлению ошибок. MDD содействует тому, чтобы артефакты генерировались согласованно.
  • Повторяемость. Подход MDD особенно хорош, если его применять на уровне программы или организации. Это происходит потому, что возврат на инвестиции (ROI) на разработку трансформаций увеличивается при каждом их повторном применении. Использование опробованных и протестированных трансформаций также повышает предсказуемость при разработке новых функций и уменьшает риск, поскольку архитектурные и технические проблемы были уже разрешены. Совершенствование общения с заинтересованными сторонами. В моделях опускаются детали реализации, несущественные для понимания логического функционирования системы. Следовательно, модели гораздо ближе к предметной области проблемы, что уменьшает разрыв между концепциями, понятными заинтересованным сторонам, и языком, каким выражается решение. Совершенствование процесса коммуникации способствует созданию решений, лучше соответствующих целям бизнеса.
  • Совершенствование общения при проектировании. Модели облегчают понимание и обоснования системы на уровне дизайна. Это позволяет сделать обсуждение системы более продуктивным. Тот факт, что модели являются частью определения системы, а не частью документации, означает, что модели никогда не будут устаревшими или недостоверными.
  • Фиксация опыта. Проекты и организации часто зависят от ключевых экспертов, которые регулярно создают практические решения. Если их опыт будет заключен в шаблонах и трансформациях, то их присутствие не будет обязательным, чтобы их опыт могли использовать другие участники проекта. Дополнительное преимущество, при условии, если к трансформациям прилагается достаточная документация, состоит в том, что знания организации сохраняются в шаблонах и трансформациях, если даже эксперты покинут организацию.
  • Модели как долгоживущие активы. В MDD модели — это важное достояние, в которых фиксируется то, что делают IT-системы организации. Высокоуровневые модели устойчивы к изменениям, связанным с совершенствованием платформенного уровня. Они изменяются только тогда, когда изменяются бизнес-требования.
  • Возможность отсрочки технологических решений. При использовании MDD ранняя стадия разработки приложения в основном касается моделирования. Это означает, что существует возможность отсрочить выбор конкретной технологической платформы или версии продукта до получения дополнительной информации. В предметных областях с чрезвычайно длительными циклами разработки, таких, как системы управления воздушным движением, этот момент является критическим. Платформа может вообще не существовать на момент начала разработки.

 

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


1.4 Использование Rational Software Architect для разработки, управляемой моделями


RSA — это интегрированный инструмент для проектирования и разработки, который увеличивает эффективность MDD за счет использования UML для создания приложений и служб с тщательно проработанной архитектурой. Описание RSA взято прямо из информации о продукте, которое вы можете найти в Web по адресу

http://www.ibm.com/software/awdtools/architect/swarchitect

RSA обладает следующими возможностями, особенно значимыми для MDD:

  • редактор UML 2.0 с поддержкой рефакторинга;
  • поддержка профилей UML 2.0;
  • инфраструктура шаблонов и библиотека шаблонов;
  • инфраструктура для трансформаций с примерами трансформаций.

 

Шаблоны, профили и трансформации все вместе обеспечивают возможности для настройки RSA, необходимые для того, чтобы инструмент мог поддерживать автоматизацию процесса разработки при использовании подхода MDD.

В RSA также входит инструментарий разработки для J2EE, Web и Web-служб. Другой продукт, IBM Rational Software Modeler (RSM™), включает возможности MDD, но не содержит готовых трансформаций. RSM используется в цепи инструментов MDD теми архитекторами и разработчиками, которые отвечают только за моделирование, или в тех случаях, когда выбранная платформа не поддерживается RSA.

Для тех сценариев MDD, где платформа включает поддержку J2EE и Web-служб, RSA является подходящим инструментом для архитекторов, проектировщиков и разработчиков.

В данной книге мы будем описывать работу с RSA, но помните, что Rational Software Modeler является альтернативой для тех задач, для которых не требуется инструментарий разработчика.

В следующих подразделах мы познакомим вас с возможностями поддержки MDD в RSA. Более подробно эти возможности будут рассматриваться в дальнейших главах этой книги.

1.4.1 Редактор UML 2.0


RSA включает в себя редактор, который поддерживает основные типы диаграмм UML 2.0 (рис. 1-1).


Рис. 1-1. Редактор UML 2.0 в RSA
Рис. 1-1. Редактор UML 2.0 в RSA

1.4.2 Поддержка профилей UML


Профили UML позволяют вам настраивать язык на соответствующую предметную область или метод. Профили UML предлагают набор стереотипов, которые расширяют существующие элементы UML, чтобы их можно было использовать в данном контексте. Эта техника применяется в MDD, чтобы дизайнеры могли вести моделирование с использованием концепций предметной области.

В RSA входит набор готовых UML-профилей, а также поддерживается создание новых профилей. Один из примеров профилей RSA — это Rational Unified Process® (RUP®) Analysis, который предлагает стереотипы для создания аналитических моделей с использованием подхода RUP. В профиле RUP Analysis предлагаются такие стереотипы, как Boundary, Control и Entity, как показано на рис. 1-2.


Рис. 1-2. Пример приложения в профиле RUP Analysis
Рис. 1-2. Пример приложения в профиле RUP Analysis

1.4.3 Шаблоны RSA


Шаблоны — это решения повторяющейся проблемы в конкретном контексте. RSA поддерживает автоматическое применение шаблонов к UML-моделям. Вместе с RSA поставляется набор шаблонов, включая шаблоны, созданные так называемой «бандой четырех». RSA также предоставляет инфраструктуру для шаблонов, чтобы разработчики могли создавать свои собственные шаблоны.

Одним из примеров шаблонов, имеющихся в RSA, является шаблон Interface, в котором фиксируются взаимоотношения интерфейса и класса, реализующего интерфейс. На рис. 1-3 показано применение шаблона Interface к интерфейсу ICurrentAccount и к классу Account, который его реализует.

Шаблон автоматизирует создание реализации взаимоотношений между классом и интерфейсом и добавляет в класс операции, соответствующие операциям, имеющимся в интерфейсе. Шаблон можно применить снова, если в интерфейс будут введены дополнительные операции.

Шаблоны часто применяются в сочетании с UML-профилем. При применении шаблона часто вводятся стереотипы, настраивающие элементы модели, входящие в шаблон.


Рис. 1-3. Применение образца шаблона интерфейса
Рис. 1-3. Применение образца шаблона интерфейса

1.4.4 Трансформации в RSA


Трансформации поддерживают многоуровневый, управляемый моделями подход к разработке. Они автоматизируют переходы между моделями различных уровней абстракции (например, от анализа к дизайну) и в конечном счете к коду. В RSA входит набор готовых трансформаций, включая трансформацию UML в EJB™. RSA также предоставляет соответствующую инфраструктуру, чтобы разработчики могли создавать свои собственные трансформации и дополнять уже существующие.

Примечание. За дополнительной информацией о расширении трансформаций, поставляемых с RSA, обращайтесь к следующим статьям:

«UML to C++ Transformation Extensibility in Rational Software Architect» (http://www.ibm.com/developerworks/rational/library/05/412_uml_to/),

«Extending the UML to Java transformation with Rational Software Architect» (http://www.ibm.com/developerworks/rational/library/05/802_uml/index.html).

На рис. 1-4 показано, как работает трансформация UML to EJB. При разработке модели применяется UML-профиль. Он включает стереотип Entity, который применяется в нашем примере к классу Account. Запуск трансформации (щелчок правой кнопкой мыши по модели и выбор пункта UML to EJB transformation) приводит к генерации соответствующего EJB-проекта с соответствующим модулем Entity Bean, дескрипторами размещения и т. п. В правой части рис. 1-4 показан получившийся сущностный модуль (entity bean) Account (RSA поддерживает UML-визуализацию артефактов EJB; при трансформации создается реальный Java-код).


Рис. 1-4. Трансформация LJML в EJB
Рис. 1-4. Трансформация LJML в EJB

Трансформация UML в EJB проходит по всей модели и обрабатывает все найденные сущности. Имеются дополнительные стереотипы для моделирования сессий и других концептуальных компонентов, из которых можно создавать EJB-артефакты.


1.5 Заключение


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

В гл. 2, «Общий обзор сценария», мы познакомим вас со сценарием, на котором основываются практические примеры, приведенные в ч. 2, «Реализация». Как мы уже говорили в этой главе, MDD подходит не для каждого сценария. В следующей главе мы не просто описываем сценарий, который собираемся использовать. Мы обсуждаем, как решить, нужно ли использовать MDD, как применить этот подход и почему выбранный сценарий годится для применения MDD (модная турецкая одежда).

25.02.2008

Комментарии

  • Афиша Николаев - все события твоего города
    Автор:   ·  08.10.2017 21:53:23
    Изо дня в день в Николаеве и области проводятся десятки мероприятий. Из-за отсутствия единого справочного ресурса большая часть николаевцев упускают много занимательного в собственном городе. Сайт city-afisha.com - это редчайший интернет-проект города Николаева который призван разрешить проблему информированности горожан. Портал охватывает наибольшее количество событий и мероприятий в Николаеве и области. Откуда берутся события? Очень большую часть мероприятий совершенно бесплатно добавляют сами устроители, так как они заинтересованы в потенциальных гостях. Таким образом, число охваченных событий будет быстро расти, приближаясь к максимальному. Мы вложили немало усилий как для удобства поиска мероприятий, так и для размещения сведений о них на city-afisha.com. На основной вэб страничке веб-сайта вы видите запланированные события от ближайшего к более позднему. Вы сможете подобрать в календаре интересующую дату (период дат) и выяснить о мероприятиях в этот конкретный день или найти мероприятия в интересующей категории. кинотеатры Николаев
  • знакомства с мужчинами от 40 до 50 лет
    Автор:   ·  04.10.2017 00:57:07
    Знакомства Schwabisch Hall. Сайт знакомств Schwabisch Hall бесплатно, без регистрации, для серьезных отношений.
  • Элит досуг
    Автор:   ·  14.04.2017 06:05:06
    Приветствую пользователей ресурса! Представляем досуг с элитными девушками все подробности можно узнать по мылу dosug-elitei@mail.ru
  • кумылженская знакомства
    Автор:   ·  19.02.2017 23:34:03
    сайт знакомств е1

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Вышла версия BIPULSE 6.2

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Новые статьи в библиотеке

Мифы про ГОСТ 34

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2017.
Карта сайта