О мастерской и мастерстве

Полезно договариваться о понятиях. Тем более, когда они по большей части хаотически проникают из User guides или White Papers через сленг и дурные переводы.

Слово Shop в терминах IT Shop или IS Shop, встречающихся в англоязычных публикациях, можно перевести и как "магазин", и как "мастерская". Но есть принципиальная разница между этими вариантами.

Когда вы попадаете в Магазин средств создания информационно-управляющих систем (ИУС), вам предлагают огромный выбор СУБД, средств программирования, прикладных программ, услуг по их установке и настройке, обучению и т.д. Но все купить нельзя, да и не нужно, даже если вы - фирма-разработчик. Надо обустроить свою Мастерскую, а это - другое дело.

Для малых предприятий,

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

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

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

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

Для средних проектов

и предприятий дело обстоит сложнее. Больше решается задач, задействовано больше технологий основного производства и видов рабочих мест пользователей ИУС. Растет штат мастеров и число их проблем - проблем самого проектирования. Соответственно в Мастерской должны появляться новые инструменты, но какие именно?

Вот несколько вопросов. Должна ли применяться единая СУБД? Надо ли начинать использовать объектные СУБД? Нужна ли CASE-система? Если да, то какая и с какой целью: анализ предприятия, моделирование ИУС, генерация программ? Целесообразно ли ограничиться единственной CASE-системой и методикой проектирования?

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

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

К таким особым инструментам относятся CASE-системы, другие средства моделирования предприятий и их ИУС. Чтобы посмотреть, как обстоит дело с использованием таких средств, обратимся к обзору Мириам Уильямсон.

Этот обзор, скорее всего, основан на опросе, проведенном среди более крупных предприятий, чем организации, представленные в исследовании Рошель Гарнер. В ответах появляются <тяжелые> пакеты комплексной автоматизации предприятий, в список СУБД входят DB2 и Oracle. Но если мы посмотрим, как рынок СШA голосует за средства разработки, то увидим нечто удивительное. Есть много запросов на VisualBasic и Visual C++, затем - по убывающей - на PowerBuilder и Oracle Developer/2000, но совсем нет запросов на какие-либо средства моделирования, на ERwin/BPwin, Oracle Designer/2000 или на другие CASE-системы, будь то интегрированные или класса Upper-CASE, легкие <рисовалки> или Rational Rose. Можно предположить, что это является результатом влияния массовой профессиональной культуры, которая и в США в большой степени опирается на "прямое" программирование.

Однако уже в проектах среднего масштаба (а это обычно 20-40 участников) средства моделирования необходимы. Основные причины известны и многократно описаны. Выделим только три момента, относящихся к развитию ИУС:

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

Если не пользоваться средствами моделирования, управление развитием ИУС теряется, убытки труднопрогнозируемы. Почему же CASE-системы не используются повсеместно?

Мастера особой квалификации -

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

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

Часто рассматривается и навязывается мастерам дилемма: либо использовать модели структурного подхода, либо работать с "новыми", объектными типами моделей и новыми инструментами. (Правда, о новизне можно говорить только в кавычках. В связи с этим приятно видеть в данных Уильямсон среди востребованных языков старый добрый Smalltalk.) Но предложенный выбор некорректен. Более того, неверно считать универсальным правило: "выбрали систему моделирования, изучили приложенную к нему методику и делаем на них все наши проекты".

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

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

Очень часто можно обойтись одной CASE-системой и одной методикой. Но часто опытный специалист чувствует, что эта методика или CASE-система начинают <жать>. Правда, полностью оценить последствия может только мастер высокого класса, который знает, какие беды подстерегают ИУС через месяц, полгода и год после начала эксплуатации, чем эти беды можно ослабить и что для этого надо делать на стадиях анализа и проектирования. Одно это - признак мастера высшего класса.

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

Одно из следствий: решение типа "посадим двадцать дешевых студентов или дюжину специалистов средней квалификации, зато недорогих" приводит к результату-дешевке!

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

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

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

Мастер в этих условиях должен:

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

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

Предупреждение

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

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

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

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

Результаты такого подхода

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

Профессионалы и фирмы, достигшие такого уровня мастерства, выгодно отличаются от множества других, условный пример которых таков: фирма, продающая CASE-ABC, работает именно на CASE-ABC и по методике ABC, фирма, продающая CASE-XYZ, работает на CASE-XYZ, - и т.д. Если выберешь первую фирму из-за ее опыта в создании сетей, то должен тем самым принимать и CASE-ABC с соответствующей методикой проектирования, а это может быть совсем ни к чему.

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

О мастерстве высшего класса и мастерской

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