Диссертация (1145120), страница 17
Текст из файла (страница 17)
Наконец, компаниямоказывается трудно организовать эффективное сопровождение и поддержкуDSM-решений,таккакдляэтогонужныпостоянныересурсы,обеспечивающие стабильную фоновую деятельность (исправление ошибок,реализацию новых возможностей и пр.). Менеджмент компании часто хочетзакрыть вопрос с DSM-решением — оно разработано и используется, ибольше средств на него тратить не нужно. Это приводит к тому, что DSMрешение становится legacy-системой.Отметим, что если DSM-решениесоздаётся не в ИТ-компании, а, например, в бизнес-компании или внекотором сообществе, то проблема ресурсов здесь выражается в том, чтонеобходимо организовать команду и процесс разработки.
При этом можетиметься необходимое финансирование, но этого не достаточно. Например,автор столкнулся с ситуацией, когда бизнес-компания хотела сама наладитьразработкузначительнойрешения,приразработкойэтом(10последнееоказывалосьчеловеко-лет).Выходомдовольнооказаласьорганизация субподряда ИТ-компании, опытной в таких разработках.Разработка, организованная непрофессионалами в программной инженерии,имеет очень много рисков и мало шансов быть успешно завершённой.91Риск 7: legacy-тенденции. DSM-решения, эксплуатирующиеся долгоевремя (10–20 лет и больше), часто превращаются в legacy-системы.
Этопроисходит из-за отсутствия эффективного сопровождения и развития DSMрешений, а также из-за устаревания технологий, с помощью которых онибыли созданы. Перенос DSM-решения на новые технологии оказываетсятрудоёмкой работой, так как требуется переделать не только само решение,но также и те системы, которые с его помощью были созданы и продолжаютсопровождаться. С другой стороны, для минимального сопровожденияустаревшего DSM-решения требуются люди, которые разбираются всоответствующих устаревших технологиях и согласны/способны с нимиработать (примерами таких технологий является среда разработки Delphi,СУБД Paradox).
Возникают также трудности интеграции этих решений ссовременными средствами разработки ПО. В целом надо отметить, что, содной стороны, DSM-решение способно принести большую выгоду процессуразработки ПО, с другой стороны, оно фиксирует технологии, на которыхрешение создано, и эти технологии часто переходят в создаваемое ПО (языкиразработки, базы данных, библиотеки периода исполнения).
Такая фиксацияоказывается дополнительным источником трудностей для проектов, гдеиспользуется DSM-решение (речь идёт о долгосрочных проектах и DSMрешениях, которые могут существовать десятками лет).922.4 Модель процесса разработки DSM-решения27Как было показано выше, DSM-проекты имеют специфические риски,связанные с тем, что эти проекты не являются профильными для компаний,делаются не для бизнеса, а нацелены на удовлетворение их внутреннихпотребностей. В итоге многие обычные практики разработки ПО в данномконтекстеневыполняются.Следовательно,требуютсяспециальныеруководства по разработке таких проектов, которые бы позволялиорганизовать надёжный процесс.Для этого ниже предлагается модель процесса. Согласно [181], основнаязадача модели процесса разработки ПО заключается в том, чтобы определитьпоследовательность шагов по разработке и сопровождению системы, а такжекритерии перехода от одного шага к другому.Таким образом, модельпроцесса отвечает на вопрос о том, что и как долго мы должны делать.Известны следующие модели разработки ПО: водопадная (waterfall),спиральная (spiral), итеративно-инкрементальная (iterative and incremental) идр.
(более детальный обзор моделей разработки ПО см. в [407]). Моделипроцесса, в отличие от методов (Scrum, RUP/USDP, XP и др.), а такжестандартов (различные варианты CMM, ISO-стандарты, ГОСТы РФ и пр.)фокусируются именно на динамической структуре процесса, предлагая длянеёопределённыйфункциональныйскелет.Такиемоделиобычноизлагаются кратко и лаконично: так, например, описание классическихводопадной[386]испиральной[181]моделейзанялопооднойдесятистраничной статье; реализации этих моделей для отдельных компаниймогут описываться с помощью визуальных моделей [339].
Метод разработкиПО может включать в себя модель процесса (так, например, USDP/RUP [291]и MSF [350] содержит итеративно-инкрементальную модель), а может и не27Материал данного раздела следует работам автора [46], [49], [53], [55], [315].93включать28. Кроме того, метод обычно включает в себя множество другихаспектов — модель команды, описание отдельных практик и пр., — то естьявляется более всеобъемлющим подходом к разработке.Стандарты поразработке ПО могут иметь различную направленность — например, CMMпредназначается для оценки зрелости компании по разработке ПО, а такжесодержит модель улучшения процесса. Имеются также специализированныестандарты, предназначенные для разработки документации, требований ит.д.29Существующие модели процесса не могут быть использованы безизменений в случае DSM в силу следующих причин.1. Как уже указывалось, при разработке DSM-решений имеютсяспецифические риски: внутренний характер проектов, трудности сопределением заказчика, существенное ограничение ресурсов, legacyтенденции и пр.2.
DSM-проекты обладают особенностями, отсутствующими в другихпрограммных проектах — необходимостью создания визуальногоязыка,использованиемдляразработкимногофункциональныхплатформ (DSM-платформ), ярко выраженной одновременностьюразработки и использования (то есть редко удаётся сначала закончить исдать проект, а потом начать использовать его результаты).3. DSM-проекты не являются масштабными — их команда обычносостоит из 3–5 человек, длительностьDSM-проекта составляетв28Например, широко известная «гибкая» (agile) методология XP (eXtreme Programming)[173] является набором рекомендаций-практик и не задаёт строго определённого порядкаразработки. CMM, хоть и фокусируется на процессе, но также не содержит определённоймодели процесса, лишь выделяя так называемые ключевые области (key process areas) —«острова» ключевых компетенций.
Предполагается, что и XP, и CMM могут использоваться совместно с разными моделями процессов.29Автор специально акцентировался на отличиях модели процесса от метода (методологии) и стандарта по разработке ПО потому, что часто во многих исследованиях и учебныхкурсах в области программной инженерии эти понятия неоправданно используются в качестве синонимов.94среднемоколо 1 года.
После этого уже меньшая команда производитсопровождение созданного решения.С одной стороны, модель разработки должна быть итеративной, с другойстороны, у неё должны быть этапы, чтобы максимально эффективносконцентрироватьимеющиеся (небольшие) ресурсы. В связи с этим заоснову была взята модель процесса MSF [350], которая ориентируется наразработку именно решения (не коробочного ПО и не ПО в целом) и сочетаетв себе спиральную и водопадную модели.Предлагаемая модель состоит из следующих шагов (схема моделипредставлена на рис. 2.3).1.
Выработка концепции.2. Разработка.3. Разработка и использование.4. Передача.5. Эксплуатация и сопровождение.Рассмотрим эти этапы детально.Выработка концепции. На этом этапе происходит создание и оформлениеидеи DSM-решения30, определение верхнеуровневых требований, бюджета, атакже заказчика проекта; выполняется создание команды и инфраструктурыпроекта, определяются риски.Необходимо ясно сформулировать ответ на вопрос о том, что планируетсясоздать, причём данный ответ должен допускать реализацию с разумнымизатратами и принести желаемый эффект, то есть оправдать ожидания.
Однакочасто идеи, инициирующие разработку DSM-решения, оказываются незрелыми (недоработанными) или неосуществимыми в принципе. Например,один высокопоставленный менеджер крупной компании, занимающейся Интернет-торговлей, успешно закончил курс MBA (Master of Business30Оформление идеи мы понимаем в смысле «снятия вторичных противоречий», как этоопределяет Д. Джонс [27].95Administration) и загорелся идеей описать все бизнес-процессы компании спомощью BPMN, связав каждый элемент BPMN-спецификации c соответствующим фрагментом программного кода информационной системы, используемой в компании.
Автор диссертационной работы был приглашён дляразработки соответствующего DSM-решения. Однако вместо разработки решения автор объяснил заказчику, что данная задача невыполнима, и требуется приемлемая переформулировка.Необходимо также определить верхнеуровневые требования к решению,что позволяет создать рамки проекта (project scope), которые, несмотря на«текучесть» требований (это свойственно программным разработкам), недолжны радикально видоизменяться в течение проекта. Исходя из этого,необходимо определить бюджет разработки: несмотря на возможные погрешности, такие подсчёты необходимы, так как может оказаться, что у компании нет необходимых финансов.
Требуется также учесть стоимость поддержки уже созданного решения — как с финансовой, так и с организационной точек зрения. Если же при разработке рамки проекта все-таки меняются,то есть проект превращается во что-то иное, чем было задумано в начале, тоэтот факт должен быть обсуждён со всеми заинтересованными лицами, и всвязи с ним должны быть выполнены все необходимые действия, вплоть дозакрытия проекта.
Неадекватное изменение рамок проекта приводит к реализации большого количества демо-функциональности, которая не может статьрабочим инструментом и принести реальную пользу.На этом этапе необходимо определить заказчика DSM-решения.Команда и инфраструктура DSM-проекта должны быть тщательно определены. Участники проекта могут иметь рабочие места в разных частях офисовкомпании и часто — нагрузку, которую с них никто не снимет, несмотря научастие в проекте по разработке DSM-решения. Руководитель проекта должен понять, насколько реально работать с такими сотрудниками, учитываяособенности их занятости и коммуникаций с ними.96Требуется также идентифицировать риски проекта и проработать методыпо их преодолению.ВыработкаконцепцииИдея,требования,бюджет12Спецификация поставки DSMрешенияОпределениезаказчикаСпецификацияязыка ипримеровКоманда,инфраструктура, рискиРазработка ииспользованиеПланированиеВыбор DSMплатформыОпределение дополнительнойфункциональности4РазработкаИтерации разработки3Итерации разработкиСтабилизацияПередача5ПередачаинфраструктурыЭксплуатация исопровождениеНадзор6Рис.
2.3. Модель разработки DSM-решенияПланирование — на этом этапе происходит спецификация итоговой поставки DSM-решения,разработка и формализация языка моделирования,выбор DSM-платформы и определение дополнительной функциональностирешения.Спецификация итоговой поставки важна, так как часто во внутреннихпроектах не учитываются работы по созданию соответствующей документации, по наладке и передаче инфраструктуры разработки (база данных ошибок, средства версионного контроля и пр.), созданию инсталляционных пакетов и т.д. В случае бизнес-инжиниринга важно включить в поставку метод и97процесс, ориентированные на потребности компании, для которой создаётсярешение.При разработке DSM-решения важно иметь точную спецификацию языка,а также примеры моделей (по этому вопросу много полезной информацииможно найти в работах [301], [302]). Достоинства и недостатки различныхсредств спецификации визуальных языков обсуждались выше; важно лишьотметить, что чем формальнее будут спецификации языка, тем лучше дляпроекта (идеально, если язык моделирования удаётся закрепить метамоделью, но неформальный способ, сопровождаемый хорошими примерами, особенно при создании небольших языков, также хорошо подходит; интересныйспособ создания и сопровождения визуальных языков — метамоделирование«на лету» — предложен в работе [115]).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
