2.4. Содержание разделов и пунктов выпускной квалификационной работы

1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

Является обязательным для всех типов ВКР и включает 4 пункта.

1.1Характеристика объекта автоматизации

(устав, положен я, должностные инструкции и т.п.).

1.3 Формализация существующего процесса обработки данных

Обследование существующих бизнес-процессов предметной области объекта автоматизации по схеме «Как есть» – модель AS-IS, описание бизнес-процессов, анализ существующего технологического процесса обработки информации, существующей схемы документооборота (электронного). Бизнес-процесс может быть разработан, например, в среде

MS Visio [3].

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

1.4 Модель предметной области

Состав подпунктов 1.4.1 – 1.4.6 определяется руководителем ВКР описывается на уровне существующих моделей, таких как информационная, функциональная, техническая, программная, технологическая, сетевая. Для выполнения анализа объекта управления и решаемой задачи, формирования модели предметной области рекомендуется использовать методологии IDEF0, IDEF3, DFD, UML, ARIS.

1.4.1 Информационная модель

Информационная модель – модель «черного ящика», например, контекстная диаграмма по методологии IDEF0. Модель IDEF0 начинается с общего представления всей системы (контекстной диаграммы). Данная

26

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

Данная модель в том числе может быть разработана, например, в

среде AllFusion Process Modeler (рис. 1) [1].

СибАДИРис. 1. Информационная модель

Можно воспользоваться методологией диаграмм потоков данных (Data Flow Diagrams, DFD) [12] и описать внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных хранилища данных, к которым осуществляется доступ.

1.4.2 Функциональная модель

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

27

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

СибАДИМожно воспользоваться методологией диаграмм потоков данных (Data Flow Diagrams, DFD). Это удобный инструмент при построении функциональной модели TO-BE (как будет), в том числе для вновь создаваемых с стем, где модель AS-IS (как есть) не автоматизирована или только создается. Модель системы содержит контекстную диаграмму диаграммы декомпоз ц . Пример представлен на рис. 3.

Рис. 2. Функциональная модель в нотации IDEF0

28

СибАДИР с. 3. Функциональная модель в нотации DFD

Данный пункт может не описываться, если существующие бизнеспроцессы предметной о ласти о ъекта автоматизации подробно описаны по схеме «Как есть» в п.1.3.

1.4.3 Техническая модель

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

п.3.1 «Постановка задачи и требования к системе».

Таблица 3

29

1.4.4 Программная модель

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

Пр меры представлены в та л. 4 и на рис. 4.

30

СибАДИРис. 4. Программная модель

1.4.5 Технологическая модель

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

a) в виде схемы «Технологический процесс обработки информации»

(рис. 5);

б) либо с помощью методологии IDEF3 (в качестве средства реализации можно использовать Case-средство Microsoft Office Visio, Erwin Process Modeler и др.), рис. 6;

в) либо представлены описанием бизнес-процессов, например в нотации BPMN (рис. 7) [2];

г) технологический процесс можно описать в нотации ARIS EPC (Event–driven Process Chain). Основным элементом диаграммы данной нотации является событие или действие, выполняемое какими-либо

31

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

СибАДИРис. 5. Технологический процесс обработки информации

32

33

СибАДИ

Рис. 8. Пример описания технологического процесса в нотации ARIS EPC

34

1.4.6 Сетевая архитектура объекта

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

СибАДИк внешним телекоммуникациям (в частности, выход в Интернет), параметры подключен я.

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

Все рекомендуемые изменения в данной модели должны найти отражен е в п.3.7 «Проектирование топологической модели ИС».

Пр меры отражен я сетевой архитектуры модели представлены на рис. 9 – 10.

Рис. 9. Сетевая архитектура организации (пример 1)

35

Выявленные в ходе исследования проблемы помогают построить дерево проблем (причина–про лема–следствие).

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

Для построения дерева проблем могут использоваться различные инструменты:

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

37

которых предполагается осуществить в проекте, например:

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

высокая трудоемкость обработки информации (привести объемновременные параметры);

низкая оперативность, снижающая качество управления объектом;

невысокая достоверность результатов решения задачи из-за дублирования потоков информации;

38

несовершенство организации сбора и регистрации исходной информации;

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

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

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

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

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

намного шире, чем у проектируемой системы;соответствует разрабатываемой системе;меньше требуемой.

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

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

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

39

официальное название системы;

компания-разработчик;

класс системы и ее назначение;

технологии, используемые в системе;

особенности реализации системы (в т.ч. архитектура, форматы, используемая СУБД);

рыночная стоимость системы и др.

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

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

40

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

2.2 Анализ и выбор технологий проектирования

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

СибАДИдействиями;

и минусы в зав с мости от целей проекта, особенностей

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

Рассмотреть данный вопрос можно опираясь на два подхода к

проектирован ю с стем: структурного и объектно-ориентированного [5].

– SADT (Structured Analysis and Design Technique). Зачастую IDEF0

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

системой, или определения тре ований к проектируемой системе, наглядно отражают производимые действия системы, связи между этими

– DFD (Data Flow Diagrams) или диаграммы потоков данных, описывающие внешние по отношению к системе источники и адресаты данных, потоки и хранилища данных;

– IDEF3 (Process Flow Description) показывает связи между объектами, позволяет описать процессы, фокусируя внимание на самом процессе;

– ER (Entity–Relationship Diagrams) диаграммы "сущность–связь"

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

2) Объектно-ориентированный подход:

Основная особенность данного подхода к разработке С заключается в декомпозиции системы по объектам и сущностям. Данная технология поддерживает множество различных методологий, самая известная из которых Unified Modeling Language. UML – общепринятая нотация визуального моделирования программных систем и предоставляет средства для создания визуальных моделей посредством восьми видов диаграмм [21].

41

В UML для этапов анализа предметной области предназначены следующие виды диаграмм:

use case diagram (диаграммы прецедентов);

activity diagram (диаграммы описаний технологий, процессов, функций) описывает схемы потоков управления, а также параллельные и альтернативные потоки, аналог нотаций IDEF0 и IDEF3;

sequence diagram (диаграммы последовательностей действий)

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

СибАДИбазой данных (СУБД), БД. Анализ можно сделать с помощью таблицы (аналогичной п. 2.1).

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

нотации подходов.

При выборе методов и средств проектирования следует дать краткую

2.4 Анализ и выбор языка программирования

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

42

2.5 Обоснование проектных решений

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

Формирование целевой модели в виде дерева целей, которое может представлять собой ветвящуюся структуру разбиения целей по

СибАДИпонижающимся уровням (задача-цель-результат).

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

т.д. [19].

Рис. 13. Структура дерева целей

б) можно выбрать для построения дерева целей метод системного анализа. Например, с применением Business Studio построить стратегическую карту дерева целей в виде связанного графа (рис. 14) [3].

43

СибАДИР с. 14. Стратегическая карта дерева целей

Для построения связанного графа можно использовать и другие более простые программные продукты Mind Manager, SmartArt, MS Word, Microsoft Office Visio др.

Пример дерева целей представлен на рис. 15.

Рис. 15. Пример дерева целей

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

44

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

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

Таблица 8

Пример фрагмента таблицы анализа стратегий

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

В этом пункте и далее необходимо пользоваться ГОСТ 34.601–90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

3 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ С СТЕМЫ

3.1 Постановка задачи требования к системе

Техническое задание: общие сведения, назначение и цель создания системы, требования к системе, состав и содержание работ, требования к составу и содержанию работ по внедрению системы. При выполнении данного этапа работ студенту рекомендуется использовать ГОСТ 34.602 – 89 [9], ГОСТ 19.101 – 77 [6].

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

45

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

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

перечень необходимых экранных форм;краткая характеристика результатов (названия результатных

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

краткая характеристика системы ведения файлов в базе данных (требования защиты целостности секретности);

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

периодичность решения задачи.

3.2 Информационное обеспечение задачи

При описании подпунктов данного пункта ВКР необходимо хорошо понимать структуру информационного обеспечения системы (рис. 16).

46

СибАДИР с. 16. Информационное обеспечение

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

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

наименование кодируемого множества объектов (например, кодов подразделений, табельных номеров и т.д.);

значность кода;система кодирования (серийная, порядковая, комбинированная);

система классификации (иерархическая, многоаспектная или отсутствует);

вид классификатора (международный, отраслевой, общесистемный т.п.).

Таблица 9

Пример описания классификаторов

47

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

Исходя из данной классификации, дать характеристику входной и выходной информации в п. 2.1 и 2.2.

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

пункте проводится проектирование такой входной информации.

3.2.2 Характеристика выходной информации

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

3.2.3 Концептуальная информационная модель системы

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

48

учета принятой модели БД и синтаксиса целевой СУБД. Часто на такой модели отображаются только имена сущностей (таблиц) без указания их атрибутов.

Последовательность шагов при концептуальном проектировании: Выделение сущностей. Первый шаг в построении концептуальной

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

для сущностей. Если у связи имеются атрибуты, то это указывает на тот факт, что связь является сущностью. Самый простой способ определения атрибутов – после идентификации сущности или связи задать себе вопрос: «Какую информацию тре уется хранить о …?». Существенно помочь в определении атрибутов могут различные бумажные и электронные формы и документы, используемые в организации при решении задачи. Это могут быть формы, содержащие как исходную информацию, так и результаты обработки данных.

Определение связей. Наиболее характерными типами связей между сущностями являются:

Среди них выделяются только те связи, которые необходимы для удовлетворения требований к разработке БД.

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

Суперкласс – сущность, включающая в себя подклассы.

49

3.3 Модель процесса обработки данных

Выполняется с учетом выбранных методов и средств проектирования в п. 2.2 «Анализ и выбор технологий проектирования», где был обоснован выбор методов и средств проектирования. На основании сделанного обоснования необходимо применить для построения модели процесса обработки данных предметной области соответствующую методологию

(IDEF0, IDEF3, DFD, UML или ARIS).

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

3.4 Математ ческое и алгоритмическое обеспечение

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

систем). Математическое обеспечение является составной частью программного обеспечения ИС.

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

В данном пункте должно быть приведено формальное описание задачи, математических методов и моделей, представлена методика расчета в изучаемом автоматизированном комплексе, т.е. проведена формализация этих процессов. При построении блок-схем обработки данных воспользоваться ГОСТ 19.701 – 90. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения [7].

50

3.5 Проектирование базы данных

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

Концептуальное (инфологическое) проектирование – построение семантической модели предметной области, то есть информационной

модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных.

СибАДИдисплея, окна, панели, кнопки и др., каждый из которых может также состоять (содержать в себе) из прочих интерфейсных элементов.

Конкретный в д содержание концептуальной модели базы данных

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

Лог ческое (даталогическое) проектирование – создание схемы базы

данных на основе конкретной модели данных.

Физ ческое проект рование – создание схемы базы данных для

СУБД при ф з ческом проектировании включает выбор решений, связанных с ф з ческой средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.

Инструменты для создания ER-моделей: ARIS, Erwin, Microsoft Visio,

Rational Rose и др.[14].

3.6 Проектирование интерфейса информационной системы

Интерфейс ИС – это совокупность элементов С, таких как экран

1) Задача – при проектировании ИС разработать понятный, удобный, дружественный интерфейс.

Пользовательский интерфейс должен объединять в себе все элементы компоненты программы, которые способны оказывать влияние на

взаимодействие пользователя с ИС. К этим элементам относятся:экран, который видит пользователь;набор задач пользователя, которые он решает при помощи

системы;элементы управления системой;

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

средства отображения информации, отображаемая информация и форматы;

устройства и технологии ввода данных;

51

диалоги, взаимодействие и транзакции между пользователем и компьютером;

обратная связь с пользователем;

поддержка принятия решений в конкретной предметной области;

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

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

Например, прототипы интерфейсных компонентов ИС могут быть

СибАДИреализованы с помощью UIML (User Interface Markup Language) — это дочерний язык XML, который служит для описания пользовательского интерфейса пр ложен й. В качестве инструмента может быть выбран

Microsoft Visual Studio в виде XAML для создания WPF приложений, Microsoft Visio [13, 23].

3.7 Проект рование сетевой архитектуры информационной системы

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

Пункт может отсутствовать если:

 в существующую топологическую модель объекта автоматизации не вносятся изменения;

 проектируется однопользовательская ИС или АРМ, взаимодействие с которыми посредством СЭД отсутствует;

 в ВКР ведется разра отка математической и прикладной модели для задачи автоматизации.

Модель объектов и групп объектов в составе сетевой архитектуры ИС зависит от «связанности» (простой или сложной).

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

52

Р с. 17. Сетевая архитектура информационной системы

3.8 Проектирование технологического процесса обработки информации

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

4 РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ

4.1 Разработка интерфейсной части системы

Создание пользовательского интерфейса, который обеспечит

4.2 Разработка информационного обеспечения

Если в ходе анализа предметной области и проектирования информационной системы выявилась необходимость элементов структуры ИС (внемашинной и внутримашинной информационной базы), например, таких как входные и выходные документы, справочники, классификаторы, то в ВКР необходимо представить выполненные решения.

53

4.3 Разработка базы данных (программного обеспечения)

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

моделью.

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

При разработке ПО рекомендуется рассмотреть (представить в

приложении) фрагменты листинга, контрольный пример.

4.4 Разработка математической модели обработки данных

В данном пункте рекомендуется рассмотреть задачу точки зрения

в информационной системе

В данном пункте следует рассмотреть вопросы: основные угрозы информационной безопасности; мероприятия по физической безопасности; мероприятия по безопасности программного обеспечения; методы и способы защиты ИС, мероприятия по безопасности обрабатываемой

информации.

При анализе системы и имеющихся в ней методов и средств информационной безопасности (ИБ) и защиты информации (ЗИ)

необходимо отразить:

а) существующую в компании политику безопасности (нормативно-

б) существующие программные и аппаратные средств Б и ЗИ, их использование в организации (привести перечень используемых средств, отразив их назначение, параметры и возможности);

в) порядок реализации системы обеспечения ИБ и ЗИ (кто этим занимается, кто отвечает, структура);

54

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

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

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

СибАДИпользовании программным и аппаратным обеспечением и так далее).

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

4* ВНЕДРЕНИЕ И СОПРОВОЖДЕНИЕ ИНФОРМАЦИОННОЙ ТЕМЫ

4.1 Технолог ческ й процесс обработки информации

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

4.2 Организация защиты информации в информационной системе

Описание аналогично п. 4.6 с упором на организационные мероприятия по этой части проекта.

4.3 Организационное обеспечение внедряемой информационной системы

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

5 КАЛЕНДАРНО-РЕСУРСНОЕ ПЛАНИРОВАН Е ПРОЕКТА, АНАЛИЗ БЮДЖЕТНЫХ ОГРАНИЧЕНИЙ И РИСКОВ

5.1 Календарный и ресурсный план проекта

Календарно-ресурсное планирование проекта представляет собой организационно-экономическую часть ВКР. Все пункты данного раздела необходимо выполнить с помощью пакета программ Microsoft Office Project. Основное описание пакета можно найти на электронном ресурсе

55

«MS Project: Самоучитель по Microsoft Project http://lrn.no- ip.info/other/books/Book-Microsoft-Project_cleaned_html_in_pdf.pdf [15].

Диаграмма Ганта и графики загруженности ресурсов:

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

ресурсное планирование – разработка ресурсной модели

56

СибАДИприведение в соответствие объемов стоимостей работ, запланированных на определенный период времени и финансовых затрат, запланированных на тот же период.

5.2 Анализ и оптимизация проекта

Чтобы разработанный календарный план можно было использовать в

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

«Диаграмма Ганта с отслеживанием». В этом представлении критические работы отображаются красным цветом, а некритические – синим. Сокращая продолжительность критических работ, можно сократить продолжительность всего проекта.

Стоимостная оптимизация. Стоимость проекта является одним из

основных критериев оптимизации. Целями ее являются:

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

Ресурсная оптимизация, т.е. выравнивание ресурсов. В процессе ресурсного выравнивания можно проделать следующие операции:

увеличить количество доступных ресурсов (диалоговое окно Сведения о ресурсе/Доступность ресурса);

изменить степень загрузки ресурсов и их количество на работах (окно Сведения о работе/Ресурсы);

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

Для выполнения названных процедур прежде всего необходимо выявить перегруженные ресурсы.

57

5.3 Разработка мероприятий по управлению рисками проекта

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

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

5.4 Отслеж ван е результатов проекта

Сравнение фактического и базового плана проекта, анализ отклонений (Project Monitoring and Control), определение причин и описание мер (корректирующих воздействий), принятых для минимизации влияния данных отклонений на срок завершения всего проекта.

5* РАСЧЕТ СОВОКУПНОЙ СТОИМОСТИ ВЛАДЕНИЯ ИТ-РЕШЕНИЕМ

5.1 Инструменты для оценки эффективности Т-проекта при внедрении ИС

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

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

5.2 Финансовая модель проекта

В данном пункте ВКР строится финансовая модель проекта, в которой выполняются следующие расчеты:

58

5.2.1 Расчет себестоимости программного продукта

Калькуляция на разработку программного решения включает следующие статьи:

– основная заработная плата разработчиков;

– дополнительная заработная плата разработчиков;

– отчисления в различные бюджетные и внебюджетные фонды;

– расходы на приобретение дополнительных средств вычислительной техники и программного обеспечения;

– прочие прямые расходы;

– накладные (косвенные) расходы.

5.2.2 Основная дополнительная заработная плата разработчиков

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

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

Трудоемкость выполнения отдельных видов работ определяется через минимальные ai и максимальные bi затраты времени, необходимые

для выполнения отдельных этапов работ.

По этим величинам оценивается ожидаемое значение трудоемкости ti и стандартное отклонение Di по следующим формулам:

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

Расчетные величины трудоемкости и стандартные отклонения по всем видам работ приведены в табл. 16.

59

где t измеряется в месяцах.

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

60

где t измеряется в чел.-день, а Ф – действительный фонд времени одного специалиста за планируемый период разработки программы (ч).

Расчет покажет, сколько IT-специалистов должно быть в команде разработчиков (должности этих специалистов можно указать).

В табл. 17 представлено распределение трудоемкости по стадиям разработки и исполнителям.

8 – длительность рабочего дня в часах; 21 – число рабочих дней в месяце. Фонд дополнительной оплаты труда планируется посредством

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

Коэффициент дополнительной заработной платы (%) в среднем по предприятию (согласно данным бухгалтерии) от основной заработной платы рассчитывается по нижеприведенной формуле:

61

5.2.3 Внебюджетные фонды и расходы на приобретение дополнительных средств ВТ и ПО

Сумма отчислений во внебюджетные фонды составляет (руб.) от суммы основной и дополнительной заработной платы:

созданием продукции, которые можно учесть в расходах только в периоде реализации продукции (работ, услуг) п. 2 ст. 318 НК РФ. К прямым расходам при разработке программного решения можно отнести:

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

Расходы на техническое и программное обеспечение

Заработная плата штатным и внештатным сотрудникам

Прочие прямые расходы

62

5.2.5 Прочие накладные расходы

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

Накладные расходы (руб.) вычисляются в долях к основной

5.3 Качественный анализ проекта

Для оценки эффективности проекта будут использованы следующие показатели:

1) прирост производительности труда;

2) сравнительная экономия численности работников предприятия;

3) годовая экономия по фонду заработной платы;

4) годовая экономия по отчислениям на социальные нужды;

5) годовой экономический эффект;

6) фактический срок окупаемости.

Определим прирост производительности труда (%):

где Б1 и Б2 – трудоемкость до и после внедрения мероприятия (чел.-ч). Определим сравнительную экономию численности работников

предприятия (чел.):

63

где Ч0 – количество человек (ставок), работающих над решением задачи предметной области до внедрения мероприятий.

Рассчитаем годовую экономию по фонду заработной платы (тыс.руб.):

где Зср – среднегодовая заработная плата одного работника (основная и дополнительная) до внедрения мероприятия (руб.).

Рис. 20. Пример диаграммы распределения затрат по этапам разработки

64

5.4 Расчет экономической эффективности внедрения программного продукта

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

Для оценки эффективности проекта будут использованы следующие показатели:

1) пр рост про звод тельности труда;

2) сравн тельная экономия численности работников предприятия;

3) годовая эконом я по фонду заработной платы; 4) годовая эконом я по отчислениям на социальные нужды; 5) годовой эконом ческий эффект; 6) факт ческ й срок окупаемости.

В табл. 22 представлены исходные данные для расчета годового экономического эффекта.

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

65

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

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

2) При написании работы недопустимо использование устаревших данных и нормативных материалов.

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

В зависимости от типа ВКР, особенностей разрабатываемого проектного решения и характера рассматриваемых вопросов общий объем

66