Этап системного синтеза

Этап системного синтеза.

Этот процесс предполагает:

Разработку функциональной архитектуры ЭИС, которая отражает структуру выполняемых системой функций;

Разработку системной архитектуры выбранного варианта ЭИС, то есть состав обеспечивающих подсистем.

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

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

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

7. Методологии системного анализа и проектирования информационных систем

В основе деятельности по созданию программного обеспечения информационных систем лежит известное нам понятие жизненного цикла.

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

Напомним, что традиционно выделяют следующие основные этапы ЖЦ ПО:

Анализ требований;

Проектирование;

Кодирование (программирование);

Тестирование и отладка;

Эксплуатация и сопровождение.

Главная особенность разработки крупных информационных систем состоит в концентрации сложности на первых двух этапах ЖЦ (анализ требований и проектирование). Остальные этапы имеют относительно невысокую сложность и трудоемкость.

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

Рассмотри содержания этапов анализа и проектирования более подробно.

ЭТАП АНАЛИЗА

Анализ требований является первой фазой разработки программного обеспечения (ПО), на которой требования заказчика уточняются, формализуются и документируются.

Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?»

Именно этот этап определяет успех всего проекта.

Список требований к разрабатываемой системе включает:

описание выполняемых системой функций;

совокупность условий, при которых предполагается эксплуатировать будущую систему, а именно: программные и аппаратные ресурсы, предоставляемые системе; внешние условия ее функционирования; состав людей и работ, имеющих к ней отношение;

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

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

На этапе анализа определяются:

архитектура системы, ее функции, внешние условия, распределение функций между аппаратной и программной частями системы;

интерфейсы и распределение функций между человеком и системой;

требования к программным и информационным компонентам ПО, необходимые аппаратные ресурсы, требования к базам данных, физические характеристики компонентов ПО и их характеристики.

ЭТАП ПРОЕКТИРОВАНИЯ

Этот этап дает ответ на вопрос: «Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?»

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

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

Обычно этап проектирования разделяют на два подэтапа:

Проектирование архитектуры ПО, которая включает разработку структуры и интерфейсов компонентов системы, согласование функций и технических требований к компонентам, методам и стандартам проектирования;

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

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

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

методологии структурного анализа и проектирования

методологии объектно-ориентированного анализа и проектирования.

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

Хорошие модели являются основой взаимодействия участников проекта (проектировщиков и менеджеров заказчика) и гарантируют корректность архитектуры разрабатываемой системы.

7.1. Методы и средства структурного системного анализа и проектирования

Методологии структурного анализа и проектирования стремятся преодолеть сложность больших систем путем их расчленения (декомпозиции) на части («черные ящики») и иерархической организации этих черных ящиков.

Такое разбиение должно удовлетворять следующим требованиям:

Каждый черный ящик должен реализовывать единственную функцию системы;

Функция каждого ящика должна быть легко понимаема независимо от сложности ее реализации;

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

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

Второй важной идеей, лежащей в основе структурных методов является идея иерархии. Для понимания сложной системы необходимо ее отдельные части («черные ящики») организовать в виде иерархической структуры.

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

Анализ требований к разрабатываемой системе является важнейшим среди всех этапов ЖЦ. Он оказывает существенное влияние на все последующие этапы и во многих аспектах является наиболее трудной частью разработки ИС.

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

Примечание: В настоящее время известно порядка 90 разновидностей структурного системного анализа.

Методологии структурного анализа позволяют создавать единый интегрированный структурный проект (модель) ИС.

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

Методология структурного анализа и моделирования подразумевает сначала создание модели AS IS, ее анализ, выявление альтернатив, улучшение бизнес-процессов, дающее в результате модель TO BE.

Автоматизация деятельности предприятия должна вестись именно согласно модели TO BE, а не AS IS, так как последнее зачастую представляет «автоматизацию хаоса», осуществленную по принципу «все оставить как есть, только чтобы компьютеры стояли».

Иногда модели AS IS и TO BE отличаются очень существенно. В этих случаях необходима третья, «промежуточная» модель, а возможно и несколько последовательно меняющихся моделей, описывающих процесс перехода в желаемое состояние.