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

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

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

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

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

Идеальная архитектура в основном недостижима, но можно достаточно четко описать свойства, присущие сильной архитектуре:

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

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

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

- Архитектура проста в понимании, прозрачна и приспособлена к масштабированию.

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

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

Процесс разработки плана имеет итеративную природу и движется от первоначального черновика, содержащего грубые оценки по срокам и ресурсам, к конечному списку работ с определенными стоимостями и сроками. В процессе разработки плана получается упорядоченный список работ, который называют Иерархической Структурой Работ - ИСР (WBS – Work Breakdown Structure) [5].

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

Поскольку ИСР является результатом декомпозиции конечного результата с точки зрения достижения цели, то список работ является конечным и полным. По сути выполнение всех работ, предусмотренных в плане означает достижение цели проекта, то есть создание СЭД.

3.2.3. Реализация

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

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

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

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

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

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

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

3.2.4. Внедрение

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

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

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

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

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

3.2.5. Эволюция

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