Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Роль процесса Управления Требованиями при разработке сложных программных систем. Практика применения методологии IBM RUP и инструмента IBM Rational RequisitePro

Автор: Новичков Александр

О данном материале

Данная статья состоит из ТРЕХ частей, которые будут постепенно, по мере написания, добавляться к этой странице.

Часть 1 — общие характеристика процесса и инструмента

Введение

При разработке программных систем главной задачей является определения требований к системе. Правильно определенные требования являются гарантией того, что система будет удовлетворять требованиям заинтересованных в ее разработке лиц. Требования к системе включают функциональные и нефункциональные требования. Для больших систем количество этих требований может быть огромным. К тому же требования могут изменяться. Для работы с требованиями и документами, в которых они отражаются, отслеживанием их изменений разработан программный продукт IBM Rational RequisitePro.

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

Определение требований

Требование — это любое условие, которому должна соответствовать разрабатываемая система или программное средство. Таким требованием может быть и возможность, которой система должна обладать, и ограничения на ее производительность или пользовательский интерфейс, и нормативные требования, которым она должна удовлетворять. Управление требованиями – необходимое условие успешной разработки ПО.
Сбор всех требований, которые предъявляются к разрабатываемым ПО, и управление ими – это весьма сложная задача.

Сложность задачи управления требованиями

Среди главных причин этой сложности можно выделить следующие:

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

Почему требованиями надо управлять

Типичные причины срыва сроков и бюджетов проектов

• не удалось полностью выявить требования заказчиков;
• требования не были четко сформулированы;
• не удалось отследить изменения требований.

Устранение ошибки в требованиях на стадии сопровождения готового ПО обходится в 200 раз дороже, чем на стадии спецификации требований

В результате ошибки в требованиях, выявляемые на поздних фазах проекта, «съедают» 30 — 40% общей стоимости бюджета проекта.

Данный график демонстрирует стоимость внесения изменений в разрабатываемое ПО в зависимости от фазы жизненного цикла

Откуда берутся ошибки в требованиях

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

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

В таких условиях трудно отслеживать влияние изменившихся требований на другие.

• требования разнообразны по значимости (обязательность, риск, важность, стабильность);
• требования связаны между собой и с другими проектными артефактами;
• они часто относятся к нескольким функциональным областям сразу;
• требования изменяются в процессе жизненного цикла создания ПО.

Часть 1 - общие характеристика процесса и инструмента

Место процесса Управления Требованиями в жизненном цикле по IBM Rational Unified Process

Уже привычная читателям диаграмма. Управление требованиями (Requirements) поддерживается на протяжении всего жизненного цикла разработки ПО

Диаграмма процесса в нотации UML. Подробное описание видов деятельности, ролей и документов данного процесса читайте во второй части данной статьи

Содержание процесса Управления Требованиями 

Процесс управления требованиями включает в себя:

• разработку плана управления требованиями;
• разработку концепции к разрабатываемой Системе;
• построение и детализацию модели сценариев использования разрабатываемой Системы.

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

При разработке плана управления требованиями определяются:

• типы требований и их атрибуты, которые будут использоваться в проекте;
• правила трассирования требований с учетом возможностей инструментальных средств управления требованиями;
• правила контроля доступа к требованиям, их атрибутам и документам репозитория;
• правила взаимодействия участников разработки при внесении изменений в требования

В процессе разработки концепции к Системе:

• идентифицируются потенциальные пользователи Системы;
• определяются границы Системы (интерфейсы с внешними системами);
• идентифицируются ограничения, накладываемые на Систему;
• определяются технические характеристики Системы.
  

В процессе построения и детализации модели сценариев использования и требований к Системе:

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

Для эффективного управления требованиями необходимо:

1. Проанализировать проблему. Сформулировать ее совместно с заинтересованными лицами. Определить границы в рамках, которых решается проблема, и ограничения, накладываемые на ее решение;
2. Определить потребности заинтересованных лиц. Результатом определения потребностей заинтересованных лиц является описание их потребностей в различной форме;
3. Описать Систему. Результатом описания является ее описание на естественном языке и в графике с использованием моделей;
4. Управлять проектом. Определить ресурсы для управления (время, люди, финансы);
5. Управлять изменяющимися требованиями. Управление требованиями включает отслеживание истории изменений требований, установление связей между требованиями, поддержку различных версий требований.
   

Что такое атрибуты требований? 

Каждый тип требования должен иметь уникальный набор атрибутов, связанных с требованиями. Например, атрибутами запроса заинтересованного лица могут быть Приоритет, Статус, Тип запроса и т.д. Каждый из атрибутов может иметь одно или несколько состояний. Например, атрибут Приоритет может имеет три состояния: Высокий, Средний и Низкий.

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

Атрибуты сопровождают каждое требование. В процессе управления требованиями атрибуты могут видоизменяться. Например, атрибут "Статус реализации" будет изменяться по ходу реализации данного требования

Что такое иерархия требований? 

Количество требований к разрабатываемому ПО часто бывает очень велико и может составить несколько тысяч. Как выявление, так и последующая работа с таким массивом неструктурированных требований оказывается весьма сложной. В связи с этим выявление требований обычно осуществляется в несколько этапов. Сначала выявляются наиболее абстрактные требования. Затем они все более и более уточняются и детализируются, пока уровень описания требований не станет достаточным для дальнейшей разработки. Аналогию иерархии можно сравнить с обычным иерархическим планом – требование высокого порядка детализируется до уровня проверяемого требования, которое потом берется за основу при тестировании, впрочем, не только при тестировании.

Давайте посмотрим, как можно иерархию применить на практике: скажем, есть некий заказчик, в результате работы с которым, на первом этапе появились некоторые требования – это верхнеуровневые требования – это концепция, которая позволяет оценить чего же хочет заказчик, но не совсем понятно подрядчику как вести разработку и как проверять результат. Соответственно рекомендуется вот это верхнеуровневое требование «дробить» на мелкие до тех пор, пока не будет достигнут контролируемый уровень.

Это одно преимущество. Второе заключается в документировании. Как правило с заказчиком подписываю некий документ на работ (как правило, в России это Техническое задание по 34 или 19 ГОСТам), а вот потом начинается работа по созданию системы (водопад, RUP – не важно). Всегда возникает проблема поддержки документов проектных, эксплуатационных и иных в соответствии с версией изделия в проекте… и тд. И здесь очень легко можно запутаться: какая версия последняя документа? Что мы подписали? Requisite Pro решает эту проблему раз и навсегда, так как позволяет хранить версии требований и определять какое из них когда изменилось.

И самое главное – при формировании документа для согласования с заказчиком – можно собирать не все требования (не всю детальность), а лишь те, которые находятся наверху, что позволяет согласовывать документ с заказчиком в привычном ему формате, а самим работать по методологии RUP!

Иерархия и трассировка - основы Requisite Pro

Какие бывают типы требовании? 

Типы требований соответствуют различным уровням абстракции и целям представления требований
Типы требований, используемые при разработке конкретной Системе, определяются в Плане Управления Требованиями.
Рекомендуется использование следующих типов требований:

Что такое трассировка? 

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

Целями прослеживания связей между требованиями и элементами проекта являются:

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

Примерами связей между требованиями могут являться, например, связи между следующими типами требований: тип свойство Системы обуславливает сценарии использования и дополнительные требования «traces to».
Между двумя требованиями может существовать связь зависимость: «обуславливает» (is traced to), «зависит от» (traсed from).
Путь А требование «добавить команду в меню»;
В – протестировать команду в меню.
Связь между А и B следующая А «обуславливает» B A is traced to B;
Связь между B и А следующая: В «зависит от» A, B is traсed from A.
Между требованиями существуют прямые и не прямые зависимости.
Пример не прямой зависимости:
Связь между А и B следующая А «обуславливает» B;
Связь между B и C следующая B «обуславливает» C;
Связь между А и C - не прямая зависимость.
RequisitePro поддерживает не прямые зависимости между требованиями. Но их нельзя модифицировать непосредственно. То есть связь между А и С нельзя изменять непосредственно.

Примеры связей «trace to» (обуславливает) между
потребностями заказчика, функциями программного продукта
и требованиями к программному обеспечению

Связь наследования (generalization) используется, чтобы показать отношения между требованием типом и требованием подтипом. Требования подтипа имеют дополнительные атрибуты в отличие от требования типа.

Трассировка. На рисунке показана связь между требованиями разных типов. Зачеркнутые стрелки демонстрируют то, что изменение данного требование повлечет изменение другого

Важно: трассировка позволит оценить стоимость требуемых изменений!

Не секрет, что заказчик (не важно какой внутренний или внешний) может поменять требования по тем или иным причинам. Зачастую причины «иные», нежели чем «те». Для проекта важно оценить: какие требования влияют на это требование и как данное требование влияет на другие. Requisite Pro позволяет очень легко получить матрицу, в которой видно, как повлечет за собой изменение того или иного требования.

Кто работает с инструментом?

В своей работе RequisitPro могут использовать:

• архитекторы;
• менеджеры проекта;
• бизнес аналитики;
• системные аналитики;
• любой разработчик требований;
• тестовые аналитики и тестировщики;
• рецензенты требований.

Использование RequisitePro для управления требованиями

Снизить трудоемкость процесса и повысить качество управления требованиями позволяет IBM Rational RequisitePro.

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

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

RequisitePro позволяет легко выбирать требования из текстовых документов (в формате MS Word). Выделение требований из текста документов может производиться вручную или автоматически по структуре документа (например, каждый абзац - требование) или по ключевым словам (только предложения, содержащие слово «должна»).

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

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

Администрирование RequisitePro

RequisitePro позволяет использовать для работы с требованиями различные типы документов: описания сценариев использования, нефункциональные требования, концепцию (Vision) и другие. При необходимости можно создавать собственные типы документов, требований и определять набор атрибутов для описания этих требований (типовыми атрибутами требований являются, например, приоритет, сложность реализации и статус). Можно, например, разрабатывать шаблоны документов, соответствующих требованиям ГОСТ 34 или ГОСТ 19.
RequisitePro поддерживает групповую работу с требованиями. Разработчики могут быть разбиты на несколько групп, и для каждой группы могут быть назначены различные права на создание, редактирование и просмотр требований.
Для хранения требований RequisitePro может использовать различные СУБД в зависимости от объема требований и числа участников разработки: MS Access, MS SQL Server или Oracle. Это обеспечивает возможность масштабирования от использования RequisitePro в группах из нескольких разработчиков до самых крупных проектов.

Дискуссии

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

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

Дискуссии можно открыть как по требованию так и по проекту. Удобствоо связанно с тем, что открывается коллективная работа над требованиями - их читают, вносят предложения... итд. И вся информация о дискуссиях остается в истории к каждому требованию, чтобы всегда можно было видеть откуда "растут ноги"

Хранение истории изменений

Еще одна важная функция - хранение ревизии изменений формулировок требований. Требования подвержены изменениям. Requisite Pro хранит всю информацию связанную с изменениями требований. Для каждой ревизии предусмотрено авторство и комментарий для аннотирования собственных действий.

Работа через Интернет

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

Связь между процессами и инструментами 

Процесс Управления Изменениями и Конфигурациями. Инструменты IBM Rational 

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

Интеграция RequisitePro и ClearCase позволяет хранить документы и их шаблоны в едином репозитории проекта. При этом поддерживается версионность хранимых данных и работа с базовыми линиями.

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

Процессы бизнес-моделирования и анализа и проектирования. Инструменты Rational Rose (Rational XDE) 

В процессе бизнес-моделирования определяются бизнес-правила, модель бизнес-сценариев и модель бизнес-объектов, включая модель прикладной области и организационный контекст системы.
Процесс анализ и проектирование получает на свой вход основные материалы (модель сценария использования и Глоссарий проекта) из процесса управления требованиями. Недостатки в модели сценариев использования могут быть обнаружены в течение анализа и проектирование; тогда генерируются запросы на изменения , обработка которых приводит к модификации модели сценариев использования.

Интеграция RequisitePro и Rational Rose или Rational XDE позволяет создавать и хранить в RequisitePro описания сценариев использования, представленных на диаграммах модели, разработанной в Rational Rose. Возможно как редактирование атрибутов, так и переход к модели непосредственно из RequisitePro и наоборот. В результате проектировщики получают простой и быстрый доступ к тексту требований во время разработки из реализации в Rational Rose. А аналитики могут использовать возможности Rational Rose для того, чтобы нарисовать диаграмму, поясняющую ход выполнения сценария использования.

Процесс тестирования. Инструмент

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

Интеграция RequisitePro и TestManager позволяет устанавливать соответствие между требованиями, размеченными в RequisitePro, и тестами в TestManager, предназначеными для проверки их выполнения.
Как говорилось в начале данного материала – одна из задач Управления Требованиями – довести детализацию требований до уровня проверяемых требований. При этом обеспечивается непротиворечивое понимание пункта он ассоциируется с планам тестирования.

Процесс документирования. Инструмент

Интеграция RequisitePro и SoDA позволяет автоматически формировать различные документы, содержащие требования к разрабатываемым ПС, а также отчеты, отражающие ход работы с требованиями (новые или измененные требования и т.п.). На данную тему есть 2 статьи (Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational и Формирование проектной документации с использованием IBM Rational SoDA. Практика использования. Часть 1 )

Процесс управления проектами. Инструмент реализации MS Project 

В процессе управления проектом проводится планирование проекта и планирование каждой итерации (план итерации). Модель сценариев использования и план управления требованиями - это важные исходные материалы для планирования итераций.

Интеграция управляет зависимостью между требованиями в проектах RequisitePro и задачами в графиках работ Microsoft Project. Интеграция позволяет создавать задачи из требований и установки связей между требованиями и задачами

Двусторонняя синхронизация позволяет оперативно (по заданному расписанию) обновлять проектные данные.

Интеграция с MS Word 

Документ с требованиями есть спецификация требований. Каждый документ с требованиями относится к определенному типу документов. Когда создается документ с требованиями, RequisitePro присоединяет его к БД. Документы создаются в формате MS Word.

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

Для работы с документами необходимо:

определить некоторые типы документов, которые будут использоваться как шаблоны для создаваемых в дальнейшем фактических документов:

• сопоставить типы документов с шаблонами;
• присоединить заданный по умолчанию тип требования к вновь созданному типу документа;
• ознакомиться со свойствами контроля и фиксации изменений в проекте.

27.01.2008

Комментарии

• хороший совет будет сделанdvd
  Автор:   ·  28.02.2012 01:25:20
  ищу девушку microsoft operating systems Мы Вас приглашаем на ресурс киркоров марина Безгранично талантливый артист хаус Блондинки эротическое видео бесплатно
• хороший совет будет сделанdv
  Автор:   ·  27.02.2012 00:09:04
  помощь в получении кредита "Лоу-Кик" Сайт о тайском боксе и муай тай. Рейтинги бойцов, фото, видео и многое другое как заработать в интернете Торренты без регистрации готовые задачи по теоретической механике тарг с.м Качесвенное эротическое видео в онлайне
• wKwrTJHtKWg
  Автор: 92rYH9 nrzknpbgbqff  ·  25.02.2012 20:31:34
  92rYH9 nrzknpbgbqff
• хороший совет будет сделанdCX
  Автор:   ·  25.02.2012 09:10:06
  Ваш семейный журнал 24.at.ua Хлебопечки Мохаммед Али, Валерий Попенченко, Джо Луис, Рей Леонард, Джо Фрезер, Макс Бэр, Николай Королев и др. майки с надписями защита прав потребителей возврат товара
• хороший совет будет сделанd
  Автор:   ·  22.02.2012 23:45:51
  купить землю в севастополе Кому интересна тема 'Риэлторские технологии: как правильно составить рекламное объявление ' советую зайти сюда Общение родителей с детьми пластиковые панели панели под кирпич
• хороший совет будет сделан
  Автор:   ·  20.02.2012 00:57:17
  powerpoint 2003 У нас Мазин скачать бесплатно, форум. При соблюдении рекомендаций по уходу халат из бамбука надолго сохранит форму и внешний вид. воронеж расписание пролетарий Я объявляю войну торрент
• CHJwkuRfQUcRwtSzXBD
  Автор: fF00y1 , [url=http://ezlwkfwmfcrd.com/]ezlwkfwmfcrd[/url], [link=http://ctkvepcpviwx.com/]ctkvepcpviwx[/link], http://pwbwsazgrzgw.com/  ·  19.02.2012 17:45:51
  fF00y1 , [url=http://ezlwkfwmfcrd.com/]ezlwkfwmfcrd[/url], [link=http://ctkvepcpviwx.com/]ctkvepcpviwx[/link], http://pwbwsazgrzgw.com/
• FMYpUpWQFMRERfZfwr
  Автор: oqRwMF tldtmdlzxlxm  ·  19.02.2012 12:57:49
  oqRwMF tldtmdlzxlxm
• cNvIGFakHJyKEW
  Автор: That's a celevr answer to a tricky question  ·  18.02.2012 04:52:45
  That's a celevr answer to a tricky question
• AZvYCFlhRYnui
  Автор: God, I feel like I souhld be takin notes! Great work  ·  16.02.2012 18:40:57
  God, I feel like I souhld be takin notes! Great work
• skachat tolko luchee
  Автор:   ·  07.02.2012 19:32:41
  Клип на песню Сергея Наговицына закрытая школа 3 сезон смотреть бесплатно все серии онлайн смотреть закрытая школа 2 сезон Автомобиль пилот от Honda превосходно оптимизирован под дороги России. Отыскать хонда пилот характеристики вы сможете на страницах нашего веб-сайта. купить Шевроле Орландо
• fghfghthjg
  Автор:   ·  05.02.2012 18:20:01
  Аполлон 18 смотреть онлайн интерны доктор быков Вы можете сами придумать оригинальный выкуп на свадьбе друга или подруги. торренты скачать бесплатно видеорегистратор бровары
• sdfsdfe
  Автор:   ·  01.02.2012 02:46:44
  Версия для смартфона skype android 1 6 за одну минуту. Фильм Однажды в ирландии регистрация компаний за рубежом смотреть бесплатно кино онлайн 2011 плагины для joomla 1.5
• sdfx
  Автор:   ·  25.12.2011 19:07:22
  гриполис играть водяная скважина jotul kiev огнестойкие сейфы платья длинные вечерние
• 
  Автор:   ·  11.08.2011 12:15:05
  Some time before, I really needed to buy a good car for my firm but I didn't earn enough money and couldn't buy anything. Thank God my sister adviced to try to take the loans from trustworthy creditors. Thence, I acted that and was satisfied with my car loan.
• связь требований и удовлетворенности заказчика
  Автор: Козлов Дмитрий  ·  28.05.2008 14:52:54
  В процессе жизненного цикла проекта требования создаются и меняются. Возникает вопрос: до какого момента продолжается проект, до выполнения требований, или до удовлетворенности заказчика? И как ограничить хотелки заказчика, не оставив его в результате с продуктом, который ему не нужен?

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

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

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"