Диссертация (1148239), страница 22
Текст из файла (страница 22)
О схожих результатах говорит и ряд других работ [56, 82, 84, 110,116, 124, 139, 144, 152].Также зачастую оказывалось, что высшее руководство сильно переоцениваетиспользование CASE-сред в своих компаниях: например, в [114] описываетсяорганизация, в которой данные, представленные вице-президентом компании, былизавышены более, чем в шесть раз относительно показаний непосредственныхруководителей команд разработчиков. Авторы данного исследования утверждают,что подобная ситуация типична для большинства из рассматриваемых ими 87компаний. По их мнению, это объясняется тем, что компании тратят большиесредства на внедрение CASE-средств большей частью по инициативе высшегоруководства, и, если эти инструменты не находят популярности у разработчиков,136менеджерам нижнего и среднего звена приходится скрывать реальное положениевещей.Рассмотрим причины подобной непопулярности CASE-инструментов средиразработчиков.Введение в производственный процесс любой новой технологии требуетпервоначальныхвложенийи/илипониженияпродуктивностиработыиз-заадаптации этой технологии10.
По мнению ряда авторов [58, 68, 104, 161], именно этоявляетсяпричинойнеудачвнедрениябольшинстваCASE-инструментов,покрывающих весь процесс разработки ПО. Пытаясь использовать сложныеинструменты, меняющие большую часть устоявшихся в компании процессов,разработчикиразочаровываютсярезультатамипервыхпилотныхпроектов,выполненных с использованием новых технологий, и со временем отказываются отних [125, 152]. В [105] дается следующая оценка при попытке внедрения CASEинструментов: только вслед за падением продуктивности на 50% на протяжениишести месяцев и возвращением на привычный уровень в последующие шестьмесяцев можно ожидать от 30 до 50% роста производительности трударазработчиков.
Разумеется, далеко не все компании готовы на подобные вложения вдолгосрочную перспективу с учетом высокой конкуренции в области разработки ПО[58, 143, 149].Стоимость внедрения CASE-средств в производственный процесс — еще однаиз главных причин, по которой компании отказывались от использования CASEсредств [58, 93, 144, 152, 161]. Цена самих инструментов (хоть и немалая — поданным [93], на начало 1990-х годов в пределах от $500 до $10000 в зависимости отсостава инструментария) была лишь небольшой частью от общей стоимостивнедрения этих инструментов. Существенная часть приходилась на обучение, насоответствующее аппаратное обеспечение, а также на потери производительности на10Кривая обучаемости, URL: http://en.wikipedia.org/wiki/Learning_curve (дата обращения: 18.04.2015)137время пилотных проектов, апробации новых программных средств и подстройкисуществующих процессов.
По оценкам [93], внедрение CASE-средств стоит длякомпании порядка $18000 в год на одного разработчика. В [144] приводится похожаяоценка — $22000. О сложности и серьезных затратах (как временных, так иматериальных) на внедрение CASE-инструментов в процесс разработки ПО такжепишут [82] и [125].Ситуация усугублялась тем, что большинство CASE-инструментариев былидовольноплохо документированы ипредоставляли крайне малоилинепредоставляли вовсе информации о том, как их использовать для разработки ПО[125, 128, 149]. Предполагалось, что пользователи будут знакомы с методологией,которую поддерживает тот или иной инструментарий.организаций,приобретавшихCASE-инструменты,вПри этом многие изсилудороговизнынепредоставляли своим сотрудникам специального обучения по использованиювнедряемых инструментов [162], что заставляло разработчиков разбираться с нимисамостоятельно, еще больше понижая их продуктивность на время адаптацииинструментов.Довольно очевидно, что невозможно создать универсальное инструментальноесредство, которое бы оптимально подходило для разработки произвольного ПО влюбой компании, купившей это средство.
Так или иначе компаниям приходитсяприспосабливать инструменты под особенности своих процессов, создаваемыхпрограмм, разработчиков и клиентов [58]. Однако, большинство инструментариевпродавалось в жестко заданной готовой конфигурации и почти никак не умелинастраиваться на реалии использующих их людей — например, заменитьвстроенный текстовый редактор на уже имеющийся у разработчика привычный емуредактор или быть в состоянии адаптироваться к изменениям в процессе разработки,на который ориентирован данный инструмент [92, 125]. Тратя крупные суммы денегна внедрение какой-либо технологии, компании часто попадали в состояние138зависимости от поставщика11, в котором не могли сменить используемыеинструменты без существенных затрат, и уже им приходилось подстраиваться подприобретенные инструменты, а не наоборот.
Ряд более сложных сред разработки,основанных на моделях поддерживаемых ими процессов (метамоделях) [99],позволял конфигурировать инструмент для поддержки изменений в процессе,однако это было доступно лишь для экспертов. Для рядовых пользователей процессразработки выглядит как взаимодействие человеческих ресурсов и программныхсредств, вовлеченных в ряд работ [92].
Имея понятные и наглядные (например,диаграммные) средства описания взаимодействия этих сущностей, можно было быэффективно настраивать CASE-среду под изменения в имеющихся в компаниипроцессах.Ряд исследований [153, 169] отмечает, что при использовании CASE-средствпроисходит существенное перераспределение работ и обязанностей — разработчикиначинают выполнять другие действия, чем когда разработка происходила безиспользованияCASE-инструментов.Кпримеру,поданным[114],прииспользовании CASE-средств в два раза больше времени уходит на фазу анализа ипроектирования, чем без использования этих инструментов. Далеко не все людиодинаково реагируют на подобную смену акцентов: люди, которые склоняются кформальным методологиям, более охотно используют CASE-инструменты, чем те,кто таким методологиям предпочитает не следовать.
Этот фактор оказался довольносущественным, поскольку многие организации оказались совершенно не готовыиспользовать CASE-среды из-за незрелости внедряемых в этих компаниях процессовразработки [125]. Резкая попытка жестко формализовать и автоматизировать процессу многих разработчиков вызывает естественное сопротивление и нежеланиеиспользовать новые непривычные средства. Также введение формальных процессовплохо воспринимается разработчиками, предпочитающими работать автономно11Зависимость от поставщика, URL: http://en.wikipedia.org/wiki/Vendor_lock-in (дата обращения: 18.04.2015)139относительно остальных членов команды (а это в той или иной степени верно длязначительной части разработчиков [109, 113]).Многие инструменты, используемые в 1990-х годах, ставили своей целью лишьрешение определенного ряда задач и не претендовали на поддержку всего процессаразработки [58, 125, 147, 154].
В результате для автоматизации всех этаповразработки ПО приходилось использовать несколько различных инструментариев,чаще всего плохо или вовсе не интегрируемых друг с другом. Это также приводило кнедовольству инежеланию применять данные инструменты на практике.Практически все авторы, рассуждающие на эту тему, приходят к выводу, чтоинструментальная среда должна быть целостной и поддерживать как можно большеэтапов разработки, в то же время давая возможность гибко настраивать себя подконкретные нужды пользователей.Помимо экономических и организационных причин непопулярности CASEинструментов среди разработчиков в 1980-1990-х годах существует также рядпричин технических, среди которых отмечают ориентированность на определеннуюплатформуиоперационнуюсистему[92],слабоеразвитиесредствконфигурационного управления [147] и обратного проектирования [92, 147],отсутствие средств командной разработки (как при синхронном, так и асинхронномвзаимодействии) [77, 87, 147, 157], однако наиболее значимым в этой области рядавторов выделяет неудобство использования CASE-средств [56, 78, 79, 87, 92, 100,114, 147].Так, [92] отмечает ориентированность имеющихся на рынке инструментов натехники и процессы, а не на их пользователя.
По мнению автора, инструментыдолжны уметь настраиваться на уровень пользователя — больше помогать новичкам(разного рода подсказками, помощниками и мастерами) и давать большевозможностей экспертам, показывать разным группам пользователей разный наборэлементов управления, по-разному представлять доступный функционал: например,140разделять сложные операции на несколько более простых или скрывать рядопераций для новичков, давать дополнительные возможности (например, средстваметамоделирования) для экспертов. Это позволит сократить временные иматериальные затраты на обучение, сделает инструменты доступными болееширокому кругу пользователей. Также, по мнению [56] и [92], инструменты должныдавать своим пользователям немедленную пользу от их использования, а не толькобыть рассчитанными на долгосрочную перспективу в рамках всей компании —повышение качества создаваемого ПО, сокращение времени разработки и т.п.В работе [100] отмечается слишком сильная ориентированность имеющихсяCASE-сред на процессы и методологии разработки, излишняя их формальность.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
