Размещено на http://www.allbest.ru/

Содержание

• Введение
• 1. Современные методологические проблемы разработки и внедрения программного обеспечения ERP систем
• 1.1 Философия программного обеспечения
• 1.2 Основные концептуальные подходы к методологии разработки и внедрения программного обеспечения
• 1.3 Классификация методологий разработки и внедрения программного обеспечения
• Вывод
• 2. Исследование методологии ASAP: ее сильные и слабые стороны
• 2.1 Общее описание методологии ASAP
• 2.2 Сильные и слабые стороны методологии ASAP
• 2.3 Возможные пути решения современных проблем внедрения ERP систем с использованием методологии ASAP на отечественных предприятиях
• Вывод
• 3. Описание эксперимента по переносу дорожной карты ASAP в инструментальную среду методологической платформы RUP
• 3.1 Концепция и нотация моделирования
• 3.2 Инструментальное средство моделирования
• 3.3 Формализованное описание процесса внедрения ERP систем SAP на отечественных предприятиях
• Вывод
• Заключение
• Список использованной литературы

Введение

Сущность программного обеспечения

Сущностью программного объекта по Бруксу является конструкция, состоящая из сплетенных вместе концепций:

· наборов данных;

· взаимосвязей между элементами данных;

· алгоритмов;

· вызовов функций.

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

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

программное обеспечение методология внедрение

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

Брукс выделяет следующие неотъемлемые свойства сущности программных объектов: сложность, согласованность, изменяемость и незримость. Остановимся подробнее на каждом из этих свойств.

Сложность

Сложность программных объектов более зависит от их размеров, чем сложность любых других создаваемых человеком конструкций, поскольку никакие две их части не схожи между собой (по крайней мере, выше уровня операторов). Если они схожи, то объединяются, как правило, в одну подпрограмму, функцию, класс. В этом отношении программные системы имеют глубокое отличие от компьютеров, домов и автомобилей, где повторяющиеся элементы имеются в изобилии.

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

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

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

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

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

Согласованность

Люди, связанные с разработкой и внедрением программного обеспечения не одиноки в проблемах сложности. Физика имеет дело с объектами чрезвычайной сложности даже на уровне элементарных частиц. Но физик работает в твердой уверенности, что всему есть рациональное объяснение. Альберт Эйнштейн утверждал, что "… природа должна иметь простые объяснения, поскольку Богу не свойственны капризность и произвол …".

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

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

Изменяемость

Программные объекты постоянно подвержены изменениям. Конечно, это относится и к зданиям, автомобилям, компьютерам и т.п. Но произведенные материальные вещи редко подвергаются изменениям после изготовления. Их заменяют новые модели или существенные изменения включаются в более поздние серийные экземпляры той же модели. Но, то и другое случается значительно реже, чем модификация работающего программного обеспечения.

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

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

Все удачные программные продукты подвергаются изменениям. При этом действуют два процесса:

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

· Удачный программный продукт живет дольше обычного срока аппаратно-программной среды, для которой он первоначально был создан. Программа должна быть согласована с требованиями новой среды.

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

Незримость

Программный продукт нематериален. А геометрические абстракции являются мощным инструментом. План здания помогает архитектору и заказчику оценить пространство, возможности перемещения, виды. Становятся очевидными противоречия, можно заметить упущения. Масштабные чертежи механических деталей и объемные модели молекул, являясь абстракциями, служат той же цели. Геометрическая реальность изображается в геометрической абстракции.

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

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

Итак, мы рассмотрели основные присущие программному обеспечению свойства, то есть определили, ЧТО должно создаваться в результате разработки и внедрения программного обеспечения вообще и ERP систем в частности. Теперь рассмотрим, КАК это следует делать.

Как создавать большие программные системы в разумные сроки?

Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым. Почему эта причина неудач настолько распространена?

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

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

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

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

Рассмотрим подробнее перечисленные аспекты данной проблемы:

Во-первых, Оптимизм

Итак, первый краеугольный камень проблемы - излишний оптимизм. Все разработчики программного обеспечения - оптимисты. Сколько раз в течение часа можно услышать от одного и того же программиста: "На этот раз она точно пойдет!" или "Я только что выявил последнюю ошибку!".

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

Глубокий оптимизм разработчиков заслуживает отдельного изучения. Дороти Сэйерс (Dorothy Sayers) в своей книге "Разум творца" ("The Mind of the Maker") выделяет в творческой деятельности три стадии:

1. Замысел;

2. Реализация;

3. Взаимодействие.

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

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

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

Реализация, таким образом, требует сил и времени как из-за физического материала, так и ввиду неадекватности основополагающих идей. Большую часть затруднений при реализации человеку свойственно объяснять недостатками физического материала, поскольку он "чужд" ему - в отличие от идей, которыми он гордится.

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

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

Следовательно, оптимизм разработчиков необоснован и не имеет оправдания.

Во-вторых, Человеко-месяц

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

"… использование человеко-месяца как единицы измерения объема работы является опасным заблуждением …" (Ф. Брукс)

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

Размещено на http://www.allbest.ru/

Рисунок 2. Зависимость времени от числа занятых - полностью разделимая задача

Если задачу нельзя разбить на независимые части, поскольку существуют ограничения на последовательность выполнения этапов, то увеличение затрат не оказывает влияния на исполнение графика (рис.3):

Размещено на http://www.allbest.ru/

Рисунок 3. Зависимость времени от числа занятых - неразделимая задача

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

Для задач, которые могут быть разбиты на части, но требуют обмена данными между подзадачами, затраты на обмен данными должны быть добавлены к общему объему необходимых работ. Поэтому наилучший достижимый результат оказывается несколько хуже, чем простое соответствие числа занятых и количества месяцев (рис.4):

Размещено на http://www.allbest.ru/

Рисунок 4. Зависимость времени от числа занятых - разделимая задача, требующая обмена данными

Дополнительная нагрузка состоит из двух частей:

· обучение;

· обмен данными.

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

Намного хуже дело обстоит с обменом данными. Для трех работников требуется втрое больше попарного общения, чем для двух, для четырех - вшестеро (таб.1):

Таблица 1. Зависимость количества каналов попарного общения от количества занятых

К одиннадцати занятым, количество каналов попарного общения пятикратно превышает количество занятых! И далее число каналов растет нелинейно.

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

Размещено на http://www.allbest.ru/

Рисунок 5. Зависимость времени от числа занятых - задача со сложными взаимосвязями

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

В-третьих, Робость в оценках

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

· ждать еще;

· съесть омлет сырым.

Тот же выбор стоит и перед заказчиком программного обеспечения.

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

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

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

В-четвертых, Тушим пламя бензином

Что делают, когда важный программный проект начинает отставать от графика? Естественно, добавляют людей. Как рассмотрено ранее и отображено на рисунках 2 - 5, это не всегда помогает. В случае разработки и внедрения больших ERP систем, ситуация в большинстве случаев складывается, как на рисунке 5.

Джерри Огдин в своей статье "Монгольские орды против суперпрограммиста" приводит множество подробных расчетов на конкретных примерах, в которых показывает, как добавление новых сотрудников к командам, отстающим от проектного графика, приводит в скором времени к растущей, как снежный ком потребности в новых сотрудниках. Именно эту ситуацию доктор Брукс называет "тушить пламя бензином".

Подводя итоги анализа основных факторов наиболее частой причины провала программных проектов, Фредерик Брукс формулирует свой Закон Брукса:

"Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше".

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

Итак, рассмотрев, чего нужно опасаться и чего делать не стоит при разработке и внедрении программного обеспечения, перейдем к поиску ответа на вопрос: "КАК следует это делать?".

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

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

Общепризнано, что идеальная численность небольшой активной команды - 10 человек. Такая команда может быть эталоном управляемости и производительности. Но что делать, если требуется разработка и внедрение действительно большой системы, требующей временных затрат, скажем, в 5000 человеко-лет. Эффект, получаемый от снижения потерь производительности, растворится в таком большом проекте. Команде из 10 человек не завершить его в разумные сроки.

Исходя из этого, мы можем сформулировать главное противоречие процесса разработки и внедрения программного обеспечения: "маленькой команде потребуется слишком много времени для реализации действительно крупного проекта".

Разработчики больших программных систем постоянно сталкиваются с этой дилеммой. Для эффективности и концептуальной целостности предпочтительнее, чтобы проектирование и создание системы осуществили несколько светлых голов. Однако для больших систем необходим значительный контингент разработчиков, чтобы продукт мог увидеть свет вовремя. КАК можно примирить эти два желания?

Ответ на этот вопрос тесно связан с третьим главным вопросом КТО? Кто та команда разработчиков, которая сможет разрешить данное противоречие?

Операционная бригада

Известный американский ученый в области компьютерной техники и программного обеспечения, посвятивший множество работ методикам его разработки и внедрения, Харлан Миллз в 1971 году в своем докладе "Chief programmer teams, principles, and procedures" высказал революционную в то время идею, которая заключалась в следующем. Рассмотренное выше противоречие можно разрешить путем формирования достаточного для большой системы количества обособленных малых (около 10 человек) производительных и активных команд наподобие хирургической бригады. Общий проект должен разбиваться на крупные минимально связанные задачи, целиком поручаемые той или иной бригаде. При этом не каждый участник бригады будет врезаться в задачу, но резать будет один (Хирург), а остальные оказывать ему всевозможную поддержку, повышая его производительность и плодотворность. При такой организации немного голов заняты проектированием и разработкой, и в тоже время множество сотрудников работают "на подхвате". Будет ли такая организация работать? Кто играет роль анестезиологов и операционных сестер в группе разработчиков и как осуществляется разделение труда? Миллз делит свою бригаду на следующие роли:

Хирург

В докладе Миллза автор называет эту роль "Главный программист" (Chief programmer).

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

Второй Хирург

Это второе "я" Хирурга.

Он может выполнять любую работу Хирурга, но менее опытен. Его главная задача - участвовать в проектировании, где он должен думать, анализировать, обсуждать и оценивать. Хирург испытывает на нем свои идеи, но не связан его предложениями. Часто Второй Хирург представляет свою бригаду при обсуждении с другими группами функций и интерфейсов. Он хорошо знает весь код программы Хирурга. Он исследует возможности альтернативных стратегий проектирования. Он подстраховывает на случай какой-либо беды с Хирургом. Он может даже заниматься написанием кода, но не несет ответственности за него в целом или за какую-либо его часть.

Администратор

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

Редактор

Обязанность разработки документации лежит на Хирурге. Чтобы она была максимально понятна, он должен писать ее сам. Это относится к описаниям, предназначенным как для внешнего, так и для внутреннего использования. Задача редактора - взять созданный Хирургом черновик или запись под диктовку, критически переработать, снабдить ссылками и библиографией, проработать несколько версий и обеспечить публикацию.

Два секретаря

Администратору и Редактору нужны Секретари.

Секретарь Администратора обрабатывает переписку, связанную с проектом, а также документы, не относящиеся к продукту.

Секретарь Редактора обрабатывает документацию по разрабатываемому и внедряемому продукту.

Делопроизводитель

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

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

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

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

В современной команде львиная доля этих обязанностей может быть выполнена с помощью CASE-средств. Наиболее яркий пример - системы управления изменениями.

Инструментальщик

В процессе разработки и внедрения программного обеспечения, особенно больших систем, команде постоянно требуются как аппаратные, так и программные ресурсы и сервисы. И доступ к ним должен осуществляться с безусловной быстротой и надежностью. Только Хирург может решать, удовлетворяют ли его имеющиеся ресурсы и работа сервисов. Ему необходим Инструментальщик, ответственный за обеспечение доступа к ресурсам и сервисам, а также за создание, поддержку и обновление специальных инструментов. Сегодня это могут быть интегрированные среды быстрой разработки, средства коллективной работы, системы управления требованиями и изменениями, службы удаленного доступа к элементам процесса и т.д. У каждой команды должен быть свой инструментальщик, независимо от качества и надежности имеющихся централизованных служб. Он обязан обеспечивать необходимым или желаемым инструментом своего Хирурга, но не другие бригады. Инструментальщик занимает важное место в организации среды разработки и внедрения программного обеспечения.