Диссертация (1145120), страница 16
Текст из файла (страница 16)
Нонеобходимо конкретизировать множество конкретных задач, при наличиикоторых можно будет говорить о полноценном внедрении визуальногомоделирования в этой ситуации. Например, какого рода информация должнабыть открыта (доступна), идёт ли речь о представлении информации или ометоде разработки, требуется ли сопровождение этих моделей и т.д. Все этизадачи должны быть тщательно идентифицированы, иначе внедрение средстввизуального моделирования не будет эффективным. Однако на практикеданная работа часто не выполняется.
При разработке DSM-решения, с однойстороны, данная работа выполняется в рамках разработки требований, сдругой стороны, ясности в этом вопросе оказывается больше в силунеобходимости создавать специальный программный продукт.Подмножествотщательностандартноговыбраноиязыкасогласовано.моделированияСледуетизбегатьдолжнобытьхаотическогоиспользования всех возможных видов диаграмм используемого стандартногоязыка.Крометого,выбранноеподмножествоязыкаможетбытьмодифицировано. В качестве примера можно указать изменённую нотациюдиаграмм компонент, созданную автором и использованную им длясоставлениядокументациикопределённомупроекту[71].Пример,85созданный с использованием этой нотации, представлен на рис.
2.2. В этомпримере на диаграммах компонент появились дополнительные группы,которые также могут иметь интерфейсы. Это означает, что соответствующиеинтерфейсы имеют все компоненты, которые входят в эти группы. Группыиспользованы для уменьшения количества сущностей (интерфейсов и линийк ним/от них). Кроме того, компоненты разделены на несколько видов —программныекомпоненты(обычныекомпонентыUML),аппаратныекомпоненты (изображаются серым цветом), вспомогательные компоненты(изображаются простым прямоугольником).Рис. 2.2.
Пример изменённой нотации диаграммы компонент UML86Метод и процесс — описание целей и способов моделирования, включаязадание различных ролей участников этого процесса. Следуя IDEF0 [281],можно выделить роли автора и эксперта, но ролей может быть и больше.Кроме того, для каждой роли нужно описать её функции относительномоделирования.Настроенный инструмент моделирования — соглашения о том, какойфункционал стандартного инструмента моделирования следует использовать,а также создание дополнительных настроек, шаблонов и пр.Методика может быть формализована по-разному, но ясное видение повсем обозначенным направлением необходимо иметь. Важно, что при этомстандартное средство может настраиваться, но разработкой полноценногоDSM-решения эта настройка не является.
При этом отличие такой методикиот DSM-решения заключается ещё и в том, что количество используемыхвидов диаграмм может быть велико (поскольку в этом случае разрабатыватьредакторы не нужно), средства формальной обработки (генераторы кода,валидаторы, генераторы отчётов и пр.) используются не столь активно,уровень формализации и строгости метода и процесса существенно ниже.Визуальные модели используются для коммуникаций — например, междуархитекторами и разработчиками, — и включаются в документацию.872.3 Модель рисков DSM-проектовОстановимсянаспецифичныхрискахDSM-проектов26. Будемрассматривать разработку таких проектов как в области программнойинженерии, так и в смежных областях (бизнес-инжиниринге, образовании ит.д.). Необходимо отметить, что часть представленных рисков являютсяобычными для разработки любого ПО, однако в данном случае они имеютсвою специфику.Риск № 1: ясная и проработанная идея DSM-решения.
Перед началом разработки необходимо ответить на вопрос о том, какие задачи (проблемы) и вкакой организационно-технологической среде должно решать DSM-решение.Процент новых DSM-решений значителен — как правило, компания или сообщество создают DSM-решение впервые. В связи с этим имеется большойриск начать создавать неосуществимый проект. Часто менеджеры компаний,имея достаточно полномочий, инициируют в рамках DSM-проектов реализацию некоторых своих идей, которые исходно являются незрелыми. Особенноактуальна эта проблема в бизнес-информатике — в этом случае важно, чтобыв коллективе инициаторов DSM-решения были ИТ-специалисты, которыесмогли бы направить инновационный поток в реалистичное русло.
Если инновационное мечтательство своевременно не разрешается ясной постановкойзадачи, то успешное завершение проекта становится маловероятным. Целесообразно отложить начало проекта до завершения формирования основныхидей. Второй вариант этой проблемы — отсутствие идеи вообще: вместо неёмогут присутствовать политические или маркетинговые соображения.Например, DSM-пакет нужен в контексте создания средства по бизнесинжинирингу, поскольку в таких пакетах принято иметь визуальные средства. Однако, это не является идеей: идею и проработанный проект функциональности DSM-решения в этом случае необходимо создать. Иначе великавероятность разработать, например, демо-решение, которое будет работать26Материал данного раздела следует работам автора [49], [53], [55], [315].88на небольших примерах, но в реальной практике окажется неприменимым,поскольку никто не задумывался о его использовании в «боевом» режиме.Риск № 2: сложности в разработке визуального языка. Модели, длясоздания и использования которых предназначается DSM-решение, должныбыть удобны конкретным людям.
В [302] отмечалось, что часто в DSMпроектах создаются визуальные языки, которыми могут пользоваться толькосамиавторы.Создателиквалификацией,существеннопользователей;винструментальныеитогеDSM-решений,какпревышающейоказывается,абстракцииобладаютправило,квалификациючтообладаютбудущихпредложенныечрезмернымимиколичествомвозможностей, непонятны и сложны. Кроме того, пользователи с трудомпонимают метамодели, с помощью которых, как правило, выполняютсяспецификации визуальных языков, что затрудняет обсуждение языкашироким кругом заинтересованных лиц в процессе его разработки. С другойстороны, создание документов и примеров является трудоёмкой задачей, иавторы DSM-решения часто не делают этого (или делают несвоевременно).Риск № 3: определение заказчика DSM-решения.
При разработке обычногоИТ-проекта заказчик очевиден — это тот, кто платит за систему и собираетсяеё определённым образом использовать. Заказчик имеет ряд обязательств поотношению к проекту, в частности, он обеспечивает ресурсы и исходнуюблагоприятную атмосферу для полноценного взаимодействия разработчикови будущих пользователей. Он также организует процесс сбора требований ииной информации, необходимой для проекта.
Существует много подходовдля налаживания взаимодействия с заказчиком (см., например, [173], [350]), иэто взаимодействие помогает разработке. DSM-проект является внутренним,он финансируется непосредственно самой компанией, и часто заказчикаопределить непросто — нет ответственного лица, а есть много людей, причастных к проекту, и все они имеют разные ожидания. Часто вокруг такихпроектов много политических или инновационных «игр» (в первом случае89люди интригуют, во втором пытаются реализовать экзотические идеи).
Витоге оказывается трудно удерживать приоритеты разработки. Важно, чтобызаказчик был и у него имелись необходимые административные полномочия— как для обеспечения разработки, так и для внедрения созданного решения.Лучше всего, когда заказчик лично заинтересован в проекте, например, желает использовать успех проекта для роста по служебной лестнице.Риск № 4: работа с требованиями. В начале DSM-проекта бывает многоэнтузиазма, планов и часто, как указывалось в [301], «team and managementlosing their heads». То есть у людей, вовлечённых в DSM-проект, ослабеваетчувствореальности:разработчикимечтают,наконец,реализовать«правильную» систему, пользователи желают разрешить с помощью DSMрешения все свои накопившиеся проблемы, менеджмент компании планируетудовлетворение своих собственных интересов. При этом все эти люди частоне могут/не хотят уделить должного внимания работе с техническимзаданием к решению.
Кроме того, в процессе разработки часто возникаютновые требования, и фокус продукта склонен изменяться. В связи с этимнеобходимо иметь исходный ясныйответ на вопрос о том, чторазрабатывается в DSM-проекте (то есть хорошо определённые требования).Данный ответ не должен меняться, несмотря на вариативность требований. Ксожалению, внутренняя разработка часто выполняется хаотично.Риск 5: конфигурационное управление. Проблемы конфигурационногоуправления [277], в основном, уже решённые в современной индустрии,автор часто встречал в DSM-проектах: потерянные исходные кодыотдельных модулей, отсутствие инсталляционных пакетов и распространениерешения в виде разрозненных бинарных файлов и т.д. Часто причиной этихтрудностей оказываются сложностис финансированием DSM-проекта, атакже ненадлежащим образом организованное сопровождение решения.Риск № 6: управление ресурсами.
Как правило, бюджет внутреннихпроектов ограничен — обычно компании, за небольшим исключением, не90могут себе позволить тратить значительные ресурсы на решение внутреннихзадач. В частности, не хватает соответствующего персонала: квалификацияработников в DSM-проектах должна быть высокой, а такие работники, какправило,занятывосновномпроизводственномпроцессе.В[301]указывалось, что по этой причине в DSM-проекты часто привлекаютстудентов и практикантов, что плохо сказывается на качестве DSM-решения.Кроме того, текущие бизнес-приоритеты компании и её проектов могутсущественно отвлекать членов команды от DSM-проекта. Финансированиепроекта может также приостанавливаться, так как если компания начинаетиспытывать финансовые затруднения, то закрывает финансирование сначалаблаготворительным, а потом внутренним проектам.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
