09.21.12 / Повторение / 4 ОСНОВЫ АНАЛИЗА И ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

4 ОСНОВЫ АНАЛИЗА И ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

4.1. Особенности анализа и проектирования крупных систем

4.2. Документы, содержащие требования на разработку системы

4.3. Основные принципы проектирования

4.4. Классификация моделей информационной системы

Вопросы для самопроверки

4.1. Особенности анализа и проектирования крупных систем

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности разрабатываемых информационных систем. Для них характерны следующие особенности [14]:

 сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними) требует тщательного моделирования и анализа данных и процессов;

 наличие совокупности тесно взаимодействующих компонентов (подсистем);

 отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;

 необходимость интеграции существующих и вновь разрабатываемых подсистем;

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

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

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

 изменение или уточнение потребностей пользователей в процессе разработки и эксплуатации системы.

Непременным условием успешной реализации информационной системы является четкое и как можно более полное формирование требований на разработку системы, а также ее адекватное описание на стадии проектирования. Согласно [15]: «На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление – примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях».

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

4.2. Документы, содержащие требования на разработку системы

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

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

Рис. 4.1. Пример календарного плана

Как было отмечено выше, техническое задание (ТЗ) является основным документом, определяющим требования и порядок создания (развития или модернизации) системы. Несмотря на то, что согласно [9, 13] ТЗ составляется после заключения договора, нередко оно должно быть подготовлено разработчиком еще до его подписания.

Состав, содержание, правила оформления этого документа устанавливаются ГОСТ 34.602–89 «Техническое задание на создание автоматизированной системы» [3]. ТЗ, как правило, содержит следующие разделы:

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

 назначение и цели создания (развития) системы;

 характеристика объектов автоматизации;

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

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

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

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

o программное – совокупность программ и документов, предназначенных для отладки, функционирования и проверки работоспособности системы;

o техническое – совокупность всех технических средств, используемых при функционировании системы;

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

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

 состав и содержание работ по созданию системы;

 порядок контроля и приемки системы;

 требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

 требования к документированию;

 источники разработки – документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

Техническое задание может включать приложения, например:

 расчет ожидаемой эффективности системы;

 оценку научно-технического уровня системы;

 перечень основных входных и выходных форм и т. д.

Грамотно составленное ТЗ является залогом успешной реализации проекта. В некоторых организациях, обычно имевших «печальный» опыт недооценки этого важного документа, существует практика составления расширенного и более детального технического задания. Особое внимание при его подготовке следует уделить полному и точному описанию требований, полный перечень которых приведен в [3]. В противном случае разработчик может создать систему, которая не нужна заказчику или не соответствует всем его ожиданиям.

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

Требования к видам обеспечения, в отличие от предыдущих, не должны быть слишком жесткими. Они должны быть составлены разработчиком так, чтобы у него была возможность для маневра. По возможности рекомендуется эти требования декларировать без указания конкретных способов и методов решения задач, языков программирования и СУБД, технических устройств и т. п. Например, «Формирование файлов исходных данных и результатов расчета интервалов должны выполняться в достаточном объеме и форматах, необходимых для их автоматического использования в АРМ инженера-графиста ГВЦ МПС РФ». В то же время для некоторых видов обеспечения у заказчика могут быть жесткие требования по их реализации. Это может касаться математического обеспечения (например, «Расчет движения поездов должен выполняться в соответствии с действующими Правилами тяговых расчетов»), информационного обеспечения (например, «Формирование и выдача на печать Приказа начальника дороги об установлении допускаемых скоростей на перегонах должны производиться в виде типового документа») и т. д.

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

4.3. Основные принципы проектирования

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

Все наиболее распространенные методологии анализа и проектирования информационных систем при построении моделей базируются на ряде общих принципов [14, 16, 17].

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

2. Принцип иерархического упорядочения – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Этот принцип предписывает рассматривать процесс построения модели системы на разных уровнях абстрагирования и детализации в рамках фиксированных представлений. Таким образом, проектирование можно представить как поуровневый спуск от наиболее общих и абстрактных моделей системы к более частным и детальным. При разработке программного обеспечения с помощью объектно-ориентированного подхода данный принцип получил название «наследование» – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой.

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

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

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

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

7. Принцип логической независимости заключается в концентрации внимания на логическом проектировании в целях обеспечения независимости от физической реализации.

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

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

10. Принцип информационной закрытости (инкапсуляции) (англ. encapsulation – изоляция, герметизация). Согласно этому принципу содержание внутреннего устройства элементов системы должно быть скрыто друг от друга. Этот принцип предписывает обмен информацией между элементами системы только в минимально необходимом объеме и ограничение доступа к операциям и данным каждого из них.

11. Принцип полиморфизма (англ. polymorphy) – принцип построения элементов модели таким образом, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Другое определение полиморфизма – это свойство родственных элементов решать сходные по смыслу проблемы разными способами.

4.4. Классификация моделей информационной системы

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

Классифицировать модели можно по следующим признакам.

1. По строгости описания:

 неформальные – представлены в неструктурированном виде и дают общее представление о моделируемой системе. Недостаточно наглядны (особенно при сложном взаимодействии между объектами) и неприемлемы для какого-либо количественного анализа и обработки автоматическими средствами;

 формальные:

o описательные – модели, где сведения представлены с помощью специальных документов (бланки, формы, анкеты, таблицы и т. п.);

o графические – модели представляют собой схемы, чертежи, графы, диаграммы и т. д. Наиболее наглядны и получили широкое распространение при проектировании с помощью CASE-средств;

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

2. По степени физической реализации (логической независимости):

 логические – описывают состав, структуру, состояние или поведение элементов системы без привязки к конкретным языкам или средам программирования, СУБД, техническим средствам и т. д. При разработке системы это обеспечивает гибкость в выборе и быстрый переход с одной программно-аппаратной платформы на другую;

 физические – описывают элементы системы в соответствии с принятой физической реализацией этих элементов (языками программирования, СУБД, устройствами, и т. д.);

3. По степени отображения динамики происходящих процессов:

 статические – описывают состав и структуру системы;

 динамические – описывают поведение системы и/или ее отдельных элементов. Как правило, такие модели описывают порядок действий или состояния системы и переходы между ними. Другими словами, в этих моделях явно или не явно присутствует понятие времени;

4. По отображаемому аспекту:

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

 информационные – описывают состав и структуру данных (реляционных БД, классов и др.). Относятся к статическим моделям;

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

 компонентные – описывают состав и структуру программных и аппаратных средств. Относятся к статическим моделям;

 смешанные – характеризуют сразу несколько аспектов системы (например, диаграммы потоков данных отображают работы, накопители данных, подсистемы) и т. д.

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

Вопросы для самопроверки

1. Перечислите основные особенности анализа и проектирования крупных систем.

2. Дайте краткую характеристику документам, содержащим требования на разработку информационной системы.

3. Перечислите виды обеспечения информационной системы.

4. Что понимается под проектированием системы?

5. Перечислите основные принципы проектирования.

6. Дайте классификацию моделей системы по отображаемому аспекту.