Вторая задача анализа – дать описание системы, причем такое, чтобы оно было насколько возможно полным, непротиворечивым, пригодным для восприятия и модификации, измеряемым и управляемым.
На стадии анализа анализируется выбранная система из реального мира, для которой будет построена формальная модель. Анализ в основном сосредоточен на изучении поведения реальной системы, иными словами, уделяется основное внимание тому, что делает система, а не тому как она это делает.
Поведение системы можно описать с помощью сценариев, которые характеризуются точками ее устойчивых состояний. Точки обозначают хорошо видимые извне и поддающиеся проверке и измерению элементы поведения системы.
Такие точки, выявленные на стадии анализа, будем называть функциональными точками системы. В этих точках задачи наиболее просто формализуются, их синтезирование не представляет значительных трудностей с точки зрения применяемых технологий.
С точки зрения пользователя функциональная точка представляет некоторое простейшее действие системы в ответ на некоторый простейший “раздражитель”. В простейшем виде можно считать, что функциональная точка представляет отдельную бизнес- функцию конечного пользователя.
С точки зрения аналитика функциональные точки представляют собой кванты поведения системы. Таким образом, функциональные точки являются мерой сложности системы и чем их больше, тем поведение системы более сложное.
Семантика поведения системы, то есть семантика функциональных точек, задается сценариями. Каждый сценарий представляет одну функциональную точку. Первичные сценарии используются для иллюстрации ключевого поведения, вторичные – для описания поведения в исключительных ситуациях.
Если воспринимать моделируемую систему и ее внешние раздражители как совокупность сложноорганизованных обьектов, описание взаимодействия которых дает в качестве результата формальную модель, то такое восприятие отвечает системному анализу обьекта и системы управления им, названное В.М. Глушковым принципом комлексного (системного) подхода [4].
На стадии анализа целесообразно выделяють участки, наиболее пригодные для автоматизации. Начинать следует с наиболее простых участков, так как удачное начало проекта во многом предопределяет дальнейшее удачное продолжение и завершение. Такие участки характеризуются прежде всего высоким уровнем готовности персонала, подходящим техническим оснащением и заинтересованностью руководства в работе данного участка.
Считается полезным также привлекать службу качества организации (предприятия) для работы по разработке сценариев. По сути именно сравнение сценариев с реальным поведением системы определяет качество полученной модели, то есть ее адекватность системе из реального мира.
Полученные в результате анализа данные обьединяются в один формальный документ, который формулирует требования к системе, полученные в результате анализа - Техническим Задание на СЭД.
Основная задача проектирования – создание архитектуры будущей системы и разработка плана достаточного для последующей ее реализации и внедрения. Процесс проектирования целесообразно начинаеть сразу после построения некоторой приемлимой формальной модели.
На стадии проектирования описанные функциональные точки обследуются не только аналитиком, но уже и архитектором и технологом. Совместная работа этих специалистов дает архитектуру системы, описанную в проектных решениях.
При этом не следует начинать проектирование центральных узлов до окончания этапа анализа, в тоже время нельзя затягивать начало проектирования в ожидании завершении этапа анализа. Построение модели, будучи процессом итеративным, может последовательно уточнять модель поведения системы, пытаясь получить в определенном смысле идеальную, а, следовательно, в большинстве случаев недостижимую модель. Такая ситуация классифицируется практиками как паралич анализа.
При проектировании полезно закладывать возможность реализации максимального количества функциональных потребностей, выявленных при анализе. При этом целесообразно иметь несколько разных решений для одной и той же задачи. Такой подход назван В.М. Глушковым принципом функциональной избыточности [4].
Пользователи часто используют систему не совсем так, как это предусматривали разработчики. Поэтому важно, чтобы проектируемая архитектура содержала достаточные возможности адаптации. Жестко определенные функциональные возможности потенциально предопределяют последующие конфликты во время внедрения и эволюции системы. Желательно, чтобы система имела функциональный модуль, либо модули, которые прозволяют производить изменение конфигураций функционирования. Таким образом, пользователь может получить некий каркас, “обшитый” устойчивыми решениями и в последующем произвести адаптацию исходя из реалий эксплутации. Это соответствует тому, что В.М. Глушков формулирует как принцип гибкости системы [4].
Другой стороной описанной адаптивной специализации является типизация. Современное программное обеспечения изготавливается в крайне сжатые сроки с учетом ограниченных требований постановщиков. Ушли в прошлое времена, когда система годами отлаживалась до запуска в промышленную эксплуатацию. В тоже время безответственным и авантюристичным является построение серьезных и сложных систем, опираясь лишь на надежду и необоснованную уверенность в том, что они будут работать.
В рамках АСУ В.М.Глушков описал решение данной проблемы как принцип разумной типизации. Выходом является построение индивидуальных систем из модулей хорошо отлаженных промышленных систем. Это соответствует использованию крупноблочной сборки, где крупные блоки сами являются системами, либо подсистемами, используемыми в промышленной эксплуатации миллионами пользователей. Применение в качестве каркаса “доморощенной” системы приводит к получению закрытого сложноадаптируемого решения, что, в итоге, делает решение краткосрочным, что, в свою очередь, приводит к потере инвестированных в него ресурсов.
Рациональное отношение к потребляемым ресурсам требует также использования совместимых решений. Под совместимыми решениями понимается возможность взаимодействия различных уровней системы для движения информации.
На эту проблему обратил внимание В.М. Глушков в [4] и определил это как принцип единства информационной базы. Информация, которая образуется на разных уровнях системы, используется по разному для решения разных задачи. Для этого необходимо использовать интерфейсы в том смысле, как это понимается в обьектно- ориентированном проектировании. Использование множественных интерфейсов для обработки единого информационного массива позволяет удовлетворять множественные запросы пользователя и в тоже время сохранить целостность данных. Таким образом, в нашей технологии принцип В.М.Глушкова дополнен полиморфизмом представления данных, что позволяет решать современные задачи, характеризующиеся большими обьемами и слабой детерминированностью.
Одна из основных задач – создание “правильной” архитектуры будущей системы, которая обеспечит ее концептуальную целостность. Стратегическое направление обеспечивается целенаправленным тактическим движением. Архитектура должна обеспечивать баланс между стратегическим и тактическими решениями.
Идеальная архитектура в основном недостижима, но можно достаточно четко описать свойства, присущие сильной архитектуре:
- Архитектура представляет собой многоуровневую систему абстракций. На каждом уровне абстракции взаимодействуют между собой по формализованным протоколам. Абстракции имеют четкие интерфейсы для внешнего мира и основываются на хорошо продуманной реализации.
- Система абстракций имеет слабое зацепление, функциональную связность, достаточность, полноту и предельную примитивность.
- На каждом уровне интерфейс абстракций строго ограничен от реализации. Реализация может быть изменена, при это интерфейс должен остаться неизменным. Таким образом, изменяясь внутренне абстракции продолжают соответствовать внешним ожиданиям, то есть своему протоколу.
- Архитектура проста в понимании, прозрачна и приспособлена к масштабированию.
Вторая задач проектирования – разработка и согласование детального плана реализации и внедрения. В современных условиях задачи всегда реализуются в ограниченные сроки и при ограниченных ресурсах. Это связано с тем, что пользователю не нужно решение, которое займет больше времени, чем у него отведено и не нужно решение, которое потребует ресурсов больше, чем он может выделить.
Разработка плана – это процесс создания целостного и непротиворечивого документа, который может быть использован для исполнения и контроля. Фактически в плане описываются с большей или меньшей степенью детализации действия и мероприятия, которые будут реализованы на стадии реализации и внедрения.
Процесс разработки плана имеет итеративную природу и движется от первоначального черновика, содержащего грубые оценки по срокам и ресурсам, к конечному списку работ с определенными стоимостями и сроками. В процессе разработки плана получается упорядоченный список работ, который называют Иерархической Структурой Работ - ИСР (WBS – Work Breakdown Structure) [5].
Каждый элемент ИСР ставится в соответствие свойствам и ресурсам, необходимым для выполнения данного элемента. В частности, элементу соответствуют сроки, стоимость и квалификация персонала.
Поскольку ИСР является результатом декомпозиции конечного результата с точки зрения достижения цели, то список работ является конечным и полным. По сути выполнение всех работ, предусмотренных в плане означает достижение цели проекта, то есть создание СЭД.