2. Раздел «Концепция и архитектура проекта»

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

Структура раздела:

2.1 Спецификация требований к системе;

2.2. Прототип ИТ – решения (при наличии изменений в бизнес-процессах);

2.3. Системная архитектура проекта;

2.4. Обеспечение информационной безопасности;

2.5. Руководство пользователя;

2.6. Выводы по второй главе.

Подраздел «Спецификация требований к системе»

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

В IEEE Standard Glossary of Software Engineering Terminology (1990) понятие требование трактуется следующим образом:

1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;

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

3. документированное представление условий или возможностей для пунктов 1 и 2.

В настоящее время доступны различные разные способы классификации требований и шаблоны спецификации требований. Выделяют требования к продукту и процессу.

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

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

Требования к продукту разделяются по уровням. Уровни требований связаны, с одной стороны, с уровнем абстракции системы, с другой – с уровнем управления на предприятии.

Обычно выделяют три уровня требований.

На верхнем уровне представлены бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.

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

Третий уровень – функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удалён и перемещён с участка на участок.

Распространенный способ классификации требований к продукту – выделение функциональных и нефункциональных требований.

Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос «что должна делать система» в тех или иных ситуациях. Функциональные требования определяют основной «фронт работ» Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.

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

Нефункциональные требования регламентируют внутренние и внешние условия или атрибуты функционирования системы.

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

К. Вигерс выделяет следующие основные группы нефункциональных требований:

• Внешние интерфейсы (External Interfaces),

• Атрибуты качества (Quality Attributes),

• Ограничения (Constraints).

Среди внешних интерфейсов в большинстве современных ИС наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы).

Основные атрибуты качества:

• Применимость,

• Надежность,

• Производительность,

• Эксплуатационная пригодность.

Эти атрибуты достаточно хорошо раскрыты в модели FURPS (см. ниже).

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

В спецификациях Rational Unified Process (RUP) при классификации требований используется модель FURPS+.

Акроним FURPS обозначает следующие категории требований:

• Functionality (Функциональность)

• Usability (Применимость)

• Reliability (Надёжность)

• Performance (Производительность)

• Supportability (Эксплуатационная пригодность).

Символ «+» расширяет FURPS-модель, добавляя к ней:

• ограничения проекта,

• требования выполнения,

• требования к интерфейсу,

• физические требования.

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

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

• требования к лицензированию,

• требования к документированию.

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

1. Разработки IEEE:

• IEEE 1362 “Concept of Operations Document”.

• IEEE 1233 «Guide for Developing System Requirements Specifications».

• IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications»

• IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990

• IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.

2. Отечественные ГОСТ:

• ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.

• ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы

• ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

Подраздел «Прототип ИТ – решения»

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

К прототипам, проясняющим и завершающим процесс формулировки требований, относятся модели «TO – BE». Создание этих моделей является важнейшим этапом в создании системного проекта. Только на основе разработанной модели ТО-ВЕ в дальнейшем происходит создание архитектуры системы и затем окончательного варианта ИС. Если в основу автоматизации предприятия будет изначально заложена модель AS-IS, то создаваемая «новая» ИС будет выполняться по принципу «все оставить, как есть», и вместо информатизации предприятия на основе новых ИТ, произойдет (в лучшем случае) простая компьютеризация несовершенных процессов. В результате внедрение и эксплуатация такой «новой» ИС приведет к дополнительным издержкам на закупку оборудования, создание программного обеспечения и их сопровождение. Поэтому, если предполагается изменение бизнес-процессов организации после внедрения новой ИС, изменение принципов взаимодействия между заинтересованными лицами, дипломник должен в этом подразделе построить модели, описывающие предлагаемые новые бизнес-функции организации, потоки данных и информации, новую организационную структуру предприятия. Для описания новых бизнес-процессов может быть выбрана одна из нотаций структурного или объектно-ориентированного подхода, позволяющие наиболее точно и полно отразить вносимые изменения. Если для внедрения системы изменять бизнес-процессы организации нет необходимости, то этот подраздел может быть опущен.

Подраздел «Системная архитектура проекта»

В этом подразделе необходимо на основе выбранной платформы (системные требования: операционная среда, ограничения реализации и дизайна) описать системную модель ИТ - решения и на ее основе создать детальное проектное решение для пилотного участка.

Подраздел включает пункты:

2.3.1 Архитектура прикладных программ;

2.3.2 Архитектура данных;

2.3.3 Технологическая архитектура (проект инфраструктуры системы).

В пункте «Архитектура прикладных программ» описывается функциональная модель системы, включающая построенные по результатам обследования предметной области и выделенных ранее требований к системе диаграммы, отражающие схему потоков данных и иерар­хию функций и подфункций для заданного состояния, реализация которых обеспечит решение поставлен­ной задачи автоматизации (модель TO-BE). Определяются соответствующие схеме потоков данных все входные, выходные и промежуточные документы, используемые на каждом этапе технологического процесса. Определяется состав групп пользователей, их права на доступ к данным и к функциям системы.

При описании модели системы необходимо построить диаграммы структурного (DFD, IDEF3, SWIM LANE) или объектно-ориентированного (диаграммы взаимодействия (последовательности и кооперации), диаграмма деятельности, диаграмма состояний и переходов отдельных объектов и т.п.) подхода. Диаграммы размещаются в приложениях к ПЗ, а описать их следует в основной части ПЗ. Для систем реального времени, сайтов, мультимедиа проектов описывается поведение объекта ИС во времени; строятся диаграммы переходов состояний (STD) для объектов системы и модели их взаимодействия.

В пункте «Архитектура данных» описывается логика обработки информации:

• описываются структура и информационное содержание входных документов, определяются правила целостности данных, приводятся макеты входных документов;

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

• определяются инфологическая модель системы (сущности предметной области и строится диаграмма "сущность-связь" (ERD) и/или диаграмма классов);

• описывается даталогическая модель системы (физическая модель базы данных, в т.ч. описание структуры базы данных, таблицы, связи между ними, ограничения на поля с учетом особенностей СУБД). Рекомендуется в приложение вынести физическую модель данных IDEF1 (для систем, использующих реляционные базы данных);

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

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

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

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

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

Подраздел «Обеспечение информационной безопасности»

Информационная безопасность — все аспекты, связанные с определением, достижением и поддержанием конфиденциальности, целостности, доступности, неотказуемости, подотчётности, аутентичности и достоверности информации или средств её обработки.

Обеспечение информационной безопасности — это процесс обеспечения конфиденциальности, целостности и доступности информации.

Конфиденциальность: Обеспечение доступа к информации только авторизованным пользователям.

Целостность: Обеспечение достоверности и полноты информации и методов ее обработки.

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

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

В литературе предлагается следующая классификация средств защиты информации:

• Средства защиты от несанкционированного доступа (НСД):

• Средства авторизации;

• Мандатное управление доступом;

• Избирательное управление доступом;

• Управление доступом на основе ролей;

• Журналирование (так же называется Аудит).

• Системы анализа и моделирования информационных потоков (CASE-системы).

• Системы мониторинга сетей:

• Системы обнаружения и предотвращения вторжений (IDS/IPS).

• Системы предотвращения утечек конфиденциальной информации (DLP-системы).

• Анализаторы протоколов.

• Антивирусные средства.

• Межсетевые экраны.

• Криптографические средства:

• Шифрование;

• Цифровая подпись.

• Системы резервного копирования.

• Системы бесперебойного питания:

• Источники бесперебойного питания;

• Резервирование нагрузки;

• Генераторы напряжения.

• Системы аутентификации:

• Пароль;

• Ключ доступа (физический или электронный);

• Сертификат;

• Биометрия.

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

• Средства контроля доступа в помещения.

• Инструментальные средства анализа систем защиты:

• Антивирус.

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

Подраздел «Руководство пользователя»

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

Принятыми стандартами представления здесь являются листинги программ, блок-схемы, описывающие алгоритмы работы наиболее важных элементов системы, которые в явном виде выносятся в приложения к ДР.

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

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

• структуру меню;

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

• реакцию системы на события, происходящие во время диалога;

• сообщения системы и реакцию пользователя на эти сообщения во время работы системы.

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

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