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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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