Макетирование информационных систем

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

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

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

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

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

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

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

В связи с этим в другой смешанной методологии [79], напротив, предполагается, что этап структурированного анализа предшествует этапу макетирования. Но дальнейшая стратегия проектирования, по существу, совпадает с традиционной методологией, и если на более поздней стадии проекта потребуется внести изменения, то преимущества макетирования будут минимальными.

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

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