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

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

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

В книге Венчковского Л.Б. [2] хорошо показана история смещения акцентов при разработке сложных программных систем.

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

В начале 70-х годов в связи с разработкой сложных программных систем наиболее известные специалисты-практики в области программотехники пришли к выводу о необходимости установления строгого и формального порядка в разработке программ. Уже в 1972 г. Дейкстра утверждал, что "программы должны с самого начала правильно составляться, а не просто отлаживаться до тех пор, пока они не станут правильными". В результате работ Вирта, Дейкстры, Иодана, Хоара и др. в 70-е годы постепенно сложилась методология, получившая название структурного программирования. Это понятие впервые ввел Дейкстра в 1970 г., и вначале оно касалось только формы программы и процесса ее кодирования. Был принят ряд соглашений, регламентировавших создание структурных программ:
1. Полное или частичное исключение операторов GO TO.
2. Программирование только с использованием трех базовых структур: последовательности, выбора и цикла.
3. Применение соглашений структурного кодирования при написании программ на конкретном языке программирования.

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

В конце 70-х годов было установлено, что большинство проблем при разработке программного обеспечения возникают из-за неточных и неполных исходных требований заказчика, а также из-за неправильного их понимания программистом-разработчиком. Для решения этих проблем была предложена структурная методология анализа потоков данных в создаваемой автоматизированной системе, на основе которой удалось более точно и полно описывать требования к программному изделию и более строго и формализовано описывать требования пользователя. Было разработано несколько подходов к анализу, наиболее известный из них представлен в работах Гейна и Сарсона. Одновременно начали развиваться структурные методы, связанные с использованием технологии баз данных, пришедшей на смену файловой технологии обработки данных. Структурные методы легли в основу моделирования структур баз данных; многие идеи были заложены в работах Кодда по нормализации реляционных баз данных.

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

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

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

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

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

Принцип абстракции представляет собой выделение некоторых важных свойств исследуемого объекта и игнорирование несущественных (для данного этапа). Абстракция позволяет нам представить рассматриваемую проблему, исключая из анализа второстепенные детали, окружающие существо проблемы. Используя этот принцип, разработчик может рассматривать систему на разных уровнях детализации. Первый, самый верхний уровень, показывает самый упрощенный общий взгляд на выполняемые системой функции, нижний - самый детальный. Абстракция - мощное средство разработки программ. Алгоритм является абстракцией программы, и запись алгоритма с разной степенью детальности соответствует абстракции разного уровня [2].

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

И так далее!.. До тех пор, пока системный аналитик не скажет себе Стой!. Дело в том, что на определенном этапе диаграммы уже не нужны и даже вредны (!) для анализа. Попытка отображения элементарных процессов на диаграмме только усложняет их. Диаграмма становится сложнее, чем сам процесс. Пример такой вредной диаграммы взят из книги Калянова Г.Н. Основы консалтинга [3]. По его замыслу, следующая диаграмма должна отображать структуру подхода к разработке консалтинговых проектов.

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

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

Этап	Результат
1. Анализ первичных требований
2. Обследование деятельности	ДПД верхнего уровня
3. Построение моделей деятельности	модель как есть модель как должно быть
4. Разработка системного проекта	системный проект
5. Предложения по автоматизации	решение о разработке новой системы или внедрении существующей
Если требуется разработать новую систему, тогда
6. Разработка технического проекта	технический проект
7. Разработка новой системы	автоматизированная система
Иначе
8. Разработка проекта на внедрение	проект на внедрение
9. Настройка системы класса MFP или ERP	внедренная автоматизированная система
КонецЕсли

Такая форма представления выглядит гораздо проще. Конечно, если сравнивать ее с диаграммой, то там все было красивее и интереснее, но структурный естественный язык понимать легче. Кроме того, в такой форме представления заметны некоторые недостатки, скрывающиеся на диаграмме. В частности, нет результата этапа №1. Этап №3 содержит два результата. Этап №6 и этап №9 приводят к разным результатам. Я бы посоветовал после этапа №7 все равно делать этап №8, невзирая на решение этапа №5, так как разработанная новая система обязательно требует внедрения, что включает в себя обучение сотрудников, перенос данных из существующих систем, этап опытной эксплуатации и т.д.

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

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

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

"Принеси то, не знаю что" или принцип прототипа

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

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

Человек - существо особое, и подход к нему нужен особый. Раньше происходило так: проектируешь систему, вроде бы все учел, ничего не забыл. Отдаешь проект программистам - они его героически программируют. Начинаешь устанавливать программу на компьютеры пользователей и только теперь (!) они говорят, что здесь не хватает нужного им поля, без которого они просто себе жизни не представляют. Для пользователя это всего лишь дополнительное поле, а для тебя зачастую это перепроектирование и перепрограммирование значительной части системы. А когда таких полей набирается десяток, то жить уже совсем не хочется. Зря потраченное время, зря потраченные деньги заказчика, недовольные пользователи, недовольные разработчики - всем плохо!

Давайте подумаем, как этого можно было избежать. Капризный пользователь говорит так: Откуда я знаю, что я хочу, если я не знаю, что я получу? Дайте мне что-нибудь пощупать, а я скажу, правильно это или нет. Так давайте дадим ему что-нибудь пощупать, поиграться, сделаем для него макет будущей системы - прототип №1. На пользователей это производит какое-то особое гипнотическое действие, потому что они уже сейчас начинают замечать такие недочеты, которые пришлось бы очень долго и дорого исправлять, если бы они были замечены после реализации. Мы учитываем все замечания пользователей и предлагаем им новый макет - прототип №2, более приближенный к будущей системе. Цикл повторяется… В итоге мы приходим к согласованному варианту системы, который можно с чистой совестью отдавать программистам на полную реализацию. Пользователи довольны - они получили то, что хотели. Разработчики довольны - им не придется переделывать свою работу и воевать с заказчиком. Деньги потрачены не зря - заказчик тоже доволен. Всем хорошо!

Два сценария, которые мы рассмотрели в несколько упрощенной форме демонстрируют разницу между каскадной и спиральной моделями жизненного цикла автоматизированной системы. Эта разница замечательно описана Вендровым А.М. [3].

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

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

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

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

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

Рассмотрим, какие бывают прототипы, позволяющие подключить пользователя к разработке системы.
Первым видом прототипов является модель как должно быть в виде иерархии DFD- и IDEF-диаграмм. Это позволяет представить всю систему в графическом виде, доступном для понимания пользователями. Из таких диаграмм становится понятна общая архитектура системы.

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

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

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

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

Литература

1. Калянов Г.Н. Основы консалтинга
   
2. Венчковский Л.Б. Разработка сложных программных изделий
   
3. Вендров А.М. CASE-технологии