Пример с изготовлением индивидульной обуви хорош, однако надо учитывать тот факт, что современному индустриальному обществу характерны масштабные промышленные решения. Большинство обуви делается на конвейере по стандартным размерам и стандартным моделям. Этот подход позволяет уменьшить потребительскую цену, но делает обувь мене присобленной к каждому конкретному потребителю, укладывая наши ноги в прокрустово ложе стандартных размеров.
Опыт современных СЭД показывает, что системы предпочтительно строить базируясь на промышленных решениях. Причин этому много, но основная состоит в том, что для того, чтобы решения стали более или менее пригодными, им надо пройти долгое тестирование многими миллионами пользователей. Этому требованию могут удовлетворять только те системы, которые всемирно распостранены и имеют массовое использование.
Пострение СЭД на основе промышленных решений предопределяет использование разработчиком ограниченного набора функциональных возможностей. Полученные путем компоновки решения не удовлетворяют потребностям конкретного пользователя, а являются лишь апроксимацией к ним. Система модернизируется неоднократно, каждый раз приближаясь к индивидуальным требованиям. Для этого она должна быть достаточно открыта к последующей модернизации. Через несколько итераций адаптации к требованиям пользователя наступает не только привыкание персонала к системе, но и более полное удовлетворение конкретных функциоанльных потребностей. Это состояние характеризуется тем, что разработчики считают, что удовлетворили все запросы пользователей, а пользователи думают, что, наконец-то, разработчики сделали то, о чем их изначально просили.
Описанная выше адаптация является не только результатом переработки системы, но и результатом изменения обьекта автоматизации и декларируемых им задач. В.М. Глушков называет это принципом новых задач. Создание информационных систем является инновационным процессом, внедрением новых технологий. Именно использование новых технологий во многом предопределяет возникновение новых задач, которых не существовало при использовании старых технологий. Системы должны проектироваться с учетом возникновения новых задач, которые возникают исходя как из сущности новых технологий, так и расширения выполняемых функций.
Макропроцесс, в основном, обьединяет процессы в рекурсивном цикле и реализует общий эволюционный цикл доводки системы. Критерии выхода из этой рекурсии индивидуальны для каждого проекта и в основном определяются условиями договора между заказчиком и исполнителем.
Описание микропроцесса опирается на понятие “жизненный цикл” СЭД, которое служит для определения начала разработки и конца внедрения СЭД. Наиболее удобным способом представления процессов реализации СЭД есть представление совокупности процессов в виде проекта, как это определяется в стандарте PMBOK [6].
Жизненный цикл СЭД разделяют на следующие стадии: анализ, проектирование, реализация, внедрение и эволюция. В каждую из стадий входит значительное число процессов, которые обьединяются по принципу общности отношений в СЭД. При этом под процессом понимается набор действий, приносящих результат.
Каждый из процессов может как одноразовым, так и многоразовым за время реализации жизненного цикла СЭД. Это свойство определяется рекурсивной природой создания сложных систем. При этом основные процессы отличаются от дополнительных тем, что они происходят как минимум бы один раз за время жизненного цикла.
Процессы взимодействуют между собой как логичически, так и информационно. Логическое взаимодействие определяет последовательность происходящих событий, формирует устойчивую сеть взаимосвязей. Информационное взаимодействие определяет информацию, циркулирующую в системе. Можно также говорить, что процессы связаны информацией, которую они производят, так как результат или выход одного является входом для другого.
Процессы являются не детерменированными последовательными событиями, а чаще параллельными с пересекающимися активностями переменной интенсивности. Начало процессов обуславливается срабатыванием соответствующих триггеров других процессов, находящихся в логической взаимосвязи с ними. Длительность процессов может быть достаточно длительной, что приводит к их прекращению вне зависимости от достижения цели, а по факту завершения проекта.
Основная задача анализа – установить основные функцмиональные требования к создаваемой системе, которые можно выявить на первичном этапе. В последствии, на основании выявленных требований будут строится первичные сценарии поведения, то есть воспроизводится предполагаемая реакция системы на внешние раздражители.
Функциональные требования к системе вырабатывются путем совместного рассмотрения требований ключевых участников проекта (stakeholders).
Как показала практика, успешность большого проекта в основном определяется мнением об этом факте достаточно узкого круга лиц. Можно определить, что ключевые участники – это лица или организации активно вовлеченные в проект, чьи интересы могут критично повлиять на успешность проекта. Они также могут быть не активно вовлеченными, но осуществлять надзор и оказывать критичное влияние. Работу по выявлению ключевых участников важно начинать как можно раньше. Многие из участников долгое время оставаются в тени, появляясь лишь тогда, когда по их мнению дела идут не в том направлении, как они себе представляли.
Требования, формируемые путем опроса ключевых участников обычно являются противоречивыми. Конфликт интересов есть естественным состоянием любой организации при появлении нового элемента управления [7]. Наибольшую опасность представляют те ключевые участники, влияние которых недостаточно для принятия их мнения во внимание, но достаточно для торможения, а то и блокирования проекта. Нахождение копромиссного решения и определение балансов влияний есть слабоформализуемое и очень критичное звено проекта по созданию СЭД.
Разрешение этой проблемы В.М. Глушков сформулировал в [4] как принцип первого лица: система должна заказываться, разрабатываться и внедряться под непосредственным контролем первого руководителя предприятия. Практика проектов показывает, что всякая попытка передоверить решение задачи второстепенным лицам приводит к тому, что созданная система решает лишь второстепенные задачи организации. Такой результат является очевидным, так как система создается на основании анализа требований второстепенных руководителей, которые видят перед собой соответственно второстепенные цели.
В качестве первичного продукта анализа может служить созданный прототип будущей системы. Прототипы служат для раннего обнаружения “тонких мест” и неудачных решений, закладываемых в базис создаваемой системы. Гараздо лучше обнаружить это и закладываемые риски в самом начале, чем потом исправлять их в уже эксплуатирующейся системе.
При этом различают два основных вида прототипов систем – пилотного и модельного типов. Эти прототипы имеют разное предназначение и поэтому отличаются способом и целью их реализации.
Пилотный прототип является точным воспроизведением одной из функциональных частей системы. В нем используются промышленные решения, которые будут использованы в рабочей системе. Целью пилотного проекта является показать или проверить какие-то технические решения, которые являются ключевыми и в корректности реализации которых имеются сомнения.
Модельный прототип является уменьшенной копией системы или ее части. При реализации модели могут использоваться технологии, отличные от планируемых. Целью модели является получение общего представления о функционировании будушей системы и выработка понимания сути проекта у ключевых участников.
Несмотря на важность прототипа для успешности выполнения проекта в целом, очень важно, чтобы прототип не был эволюционирован в промышленную систему. К сожалению, использование прототипов в качестве промышленного решения очень распространено. Это связано с тем, что руководители, увидев прототип и в целом оценив его полезность, часто принимают решение о внедрении прототипа и прекращении дальнейшего доростоящего процесса разработки. Тем не менее, надо понимать, что прототип хоть и является наглядным (что собственно и является его основной задачей), строился совершенно не для эксплуатации. В результате, будучи успешным и экономным решением в начале, он, в большинстве случаев, потребует дальнейшей дорогостоящей модернизации, что в итоге значительно превысит первоначальную планируемыю стоимость системы. При этом становиться реальностью поговорка “скупой платит дважды” и остановка разработки скорее всего приведет как к утрате первоначальных целей, так и к потере инвестированных средств.
Вторая задача анализа – дать описание системы, причем такое, чтобы оно было насколько возможно полным, непротиворечивым, пригодным для восприятия и модификации, измеряемым и управляемым.
На стадии анализа анализируется выбранная система из реального мира, для которой будет построена формальная модель. Анализ в основном сосредоточен на изучении поведения реальной системы, иными словами, уделяется основное внимание тому, что делает система, а не тому как она это делает.
Поведение системы можно описать с помощью сценариев, которые характеризуются точками ее устойчивых состояний. Точки обозначают хорошо видимые извне и поддающиеся проверке и измерению элементы поведения системы.
Такие точки, выявленные на стадии анализа, будем называть функциональными точками системы. В этих точках задачи наиболее просто формализуются, их синтезирование не представляет значительных трудностей с точки зрения применяемых технологий.
С точки зрения пользователя функциональная точка представляет некоторое простейшее действие системы в ответ на некоторый простейший “раздражитель”. В простейшем виде можно считать, что функциональная точка представляет отдельную бизнес- функцию конечного пользователя.
С точки зрения аналитика функциональные точки представляют собой кванты поведения системы. Таким образом, функциональные точки являются мерой сложности системы и чем их больше, тем поведение системы более сложное.
Семантика поведения системы, то есть семантика функциональных точек, задается сценариями. Каждый сценарий представляет одну функциональную точку. Первичные сценарии используются для иллюстрации ключевого поведения, вторичные – для описания поведения в исключительных ситуациях.
Если воспринимать моделируемую систему и ее внешние раздражители как совокупность сложноорганизованных обьектов, описание взаимодействия которых дает в качестве результата формальную модель, то такое восприятие отвечает системному анализу обьекта и системы управления им, названное В.М. Глушковым принципом комлексного (системного) подхода [4].
Страницы: 1, 2, 3
