Диссертация (1145120), страница 18
Текст из файла (страница 18)
Но важно также, чтобы язык былодобрен будущими пользователями (или их представителями). В связи с этимочень важны примеры моделей, выполненных с помощью нового языка. Приразработке DSM-решений автор диссертационной работы старается придерживаться следующего правила: если до начала разработки не готовы содержательные, объёмные и максимально корректные примеры, то разработкурешения начинать рано. Часто оказывается, что «дьявол кроется в мелочах»:язык ясен в общих чертах, но отдельные детали не стыкуются, и в связи сэтим оказывается, что концепция всего DSM-решения не готова.
Это становится понятно при разработке и анализе примеров.Необходимо убедитьсядо начала разработки в том, что язык устойчив: впоследствии его отдельныедетали могут меняться и уточняться, но целиком он переделываться уже недолжен. В случае большой вероятности масштабных переделок языка не следует начинать разработку решения [301]. В случае нестабильности и большого количества неточностей в языке следует продолжить разработку примерови прочие предварительные изыскания.Выбор подходящей DSM-платформы важен по следующим причинам.Платформа должна быть перспективной с точки зренияразвития и сопро98вождения производителем, чтобы DSM-решение через некоторое время непревратилось в legacy-систему31. Платформа должна быть удобна для будущих пользователей.
Например, в области бизнес-инжиниринга часто используется Microsoft, так как с этим продуктом потенциальные пользователи, какправило, знакомы. Наконец, платформа должна быть обеспечена специалистами, имеющими возможность выполнять с её помощью разработку и поддержку решения. Например, использование в России средств Eclipse Modeling Project [233] существенно ограничено в связи с недостатком соответствующих экспертов. Обратный пример — выбор EAM-инструмента ARIS в российских проектах часто связан с большим количеством специалистов, знакомых с этим инструментом (в связи с широким распространением в последниегоды этого продукта на российском рынке).Проектирование дополнительного функционала DSM-пакета не менееважно, чем определение языка моделирования.
Во-первых, требуется тщательно рассмотреть вопросы качества моделей — требуются ли дополнительные средства для этого и какова цена ошибок в моделях, какие средстваи методы должны быть использованы/реализованы. Во-вторых, необходимоопределиться с версионированием моделей и, в частности, с требованиями кпроцедуре слияния, если она требуется. В-третьих, необходимо решить вопросы работы с большими моделями — специфицировать средства декомпозиции и навигации, средства создания отчётов (в частности, Web-отчётов),средства поддержки дисциплины/процесса разработки/сопровождения моделей.
В-четвертых, необходимо проработать вопросы интеграции DSMрешения с окружением. Кроме того, функциональность, предоставляемая30Legacy-системами обычно называют программные приложения, которые давно работают в компании и ценны для неё, но которые сильно устарели технологически [352],например, не интегрированы с Интернетом. В силу ценности таких приложений для компании их нельзя просто демонтировать, так как они содержат собранную в течение долгого времени информацию о компании и её бизнес-процессах [185]. В связи с этим используется реинжиниринг таких систем.99DSM-платформами, также может оказаться недостаточной и требовать переделки — например, генераторы кода или генераторы отчётов.Разработку DSM-решения целесообразно проводить итеративно.
Приэтом в качестве образца предлагается выбрать итерацию (sprint) методаScrum [276], [390], [391]. В качестве владельца продукта должен выступатьзаказчик или его представитель, наделённый нужными полномочиями. В качестве Scrum-мастера может выступать руководитель проекта. У него оказывается много организаторских функций, так как ему нужно удерживать команду проекта в рабочем состоянии, не давая членам команды сильно отвлекаться на другие проекты и организуя надлежащим образом их работу, а также поддерживать конструктивные отношения с владельцем продукта и пользователями.
Велика роль руководителя проекта при демонстрации результатов работы пользователям, а также при составлении требований на следующую итерацию. Он также является буфером между пользователями и командой (часто пользователи, особенно на этапе «Разработка и использование»имеют много пожеланий). В целом роль руководителя DSM-проекта вполнесоответствует Scrum — хранить и организовывать эффективную работу, неснимая при этом ответственности с разработчиков.Команда DSM-проекта должна быть Scum-командой ещё и в том смысле,что её члены очень активны, производительны и готовы выполнять разныеработы — всё это важно, поскольку DSM-проект является инновационным.Требуется повышенная заинтересованность в успешном результате, открытость и терпение при работе с пользователями, понимание трудностей с финансированием проекта, если они возникают.На этом этапе важно создать первую стабильную версию решения, которую пользователи смогут начать применять.
Это не означает конца разработки — далее она будет происходить параллельно с использованием продукта.Такой подход согласуется с опытом автора, поскольку обычно от DSMпроекта с нетерпением ждут результатов. При этом пользователи оказывают100ся источником дополнительных требований, что очень важно для успешности DSM-решения. Однако решение передаётся пользователям после того,как выполнены основные инфраструктурные работы и реализована первая исамая необходимая функциональность, а также после проведения необходимого тестирования. Всю эту деятельность назовём стабилизацией решения.Переход к стабилизации означает, что решение уже достаточно зрелое и небудет кардинально меняться, но лишь будет наращиваться функционально.При этом важно следующее. Во-первых, структура пользовательских данных(прежде всего, формат хранения модели) не должна сильно меняться, а еслиона все же меняется, то должны быть предусмотрены специальные средствадля миграции данных, созданных пользователями при использовании решения [32].
Во-вторых, должны быть решены вопросы распространения новыхверсий решения, то есть должен быть создан инсталляционный пакет. Приэтом часто бывает, что решение должно функционировать независимо отсреды разработки — например, если оно разрабатывается на базе MicrosoftVisio и Visual Studio, то оно должно функционировать без Microsoft VisualStudio (такое требование было выдвинуто при разработке решения, описанного в [72]) или, если оно создано в среде Eclipse и с помощью GMF, то может потребоваться, чтобы оно работало без Eclipse. Создание и тестированиеавтономных инсталляционных пакетов часто оказывается непростой задачей.Требуется заметить, что иногда, если решение небольшое и круг пользователей невелик, то инсталляционного пакета не требуется.Количество итераций на этом этапе может быть разным, в зависимости отсложности решения.
Следует отметить, что итерации могут быть организованы по-разному: от небольших, длиной в 2–3 недели, с демонстрацией результатов пользователям и владельцу продукта в конце, до итераций длиной в несколько месяцев, осуществляемых в рамках специальных договоров или дополнительных соглашений (в случае, если в проекте используется внешняякоманда). Возможны комбинированные варианты.101Разработка и использование — на этом этапе проводится дальнейшая итеративная разработка решения с одновременным использованием. Это не является ещё сопровождением, так как работы выполняются всей командойразработчиков.Пользователи могут начинать использование решения через пилотныйпроект, как это описывается в [301]. Сначала осуществляется развёртка решения на вычислительных ресурсах пользователей (решения в области программной инженерии являются простыми с точки зрения развёртки и администрирования, но в области бизнес-инжиниринга это не так).
Далее разработчики/пользователи внедряют решение в какой-нибудь некритичный производственный проект. При этом пользователи, как правило, находят многоошибок и недоработок, которые делают эксплуатацию решения крайне затруднительной. Пилотный проект снимает риск разного понимания важныхчерт решения разработчиками и пользователями — часто эта разница имеетместо. Наличие предыдущих итераций и вовлеченность пользователей в процесс разработки должны снять риск того, что пользователи при пилотномвнедрении отвергнут решение. По результатам пилотного внедрения формулируется обратная связь, которая передаётся разработчикам и реализуется врамках следующей итерации.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
