Проектная и/или технологическая часть (архитектура проекта и особенности реализации)

3.1 Календарно-ресурсное планирование проекта

Рекомендуется в качестве базового документа для планирования и управления проектом составить и проанализировать ресурсно-календарный план в формате диаграммы Ганта или сетевого графика (оптимальный инструмент – MS Project). Особый интерес представляют события-вехи проекта, которые желательно охарактеризовать в терминах отчетных промежуточных документов и артефактов. Также рекомендуется описать критерии достижения конкретных вех.

Обязательными рабочими документами ВКР, которые также должны быть приведены в данном разделе и которые во многом могут быть получены из программы MS Project, являются:

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

- бюджет проекта.

При описании управления проектом рекомендуется использовать один из стандартов PMBOK, SWEBOK, MSF.

3.2. Информационное обеспечение ИС

3.2.1. Информационная модель и ее описание

Методика разработки информационной моделипредполагает моделирование нового варианта организации информационной системы предметной области («TO-BE»), а именно:

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

- отражение этой информации на всех типах носителей;

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

- состава исходных первичных документов и распределение их по задачам;

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

- состава файлов с первичной, условно-постоянной, промежуточной и результатной информацией;

- информационную потребность для каждой задачи комплекса;

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

- состава результатных документов для каждой задачи;

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

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

В описании информационной модели необходимо объяснить, на основе каких входных документов и какой нормативно-справочной информации происходит выполнение функций по обработке данных и формирование конкретных выходных документов.

Информационная модель строится в двух формах:

- схема данных в соответствии с ГОСТом;

- структурно-функциональная модель или диаграмма потоков данных по методологии Гейна/Сарсона, Йодана/ДеМарко. Для ее разработки целесообразно использовать CASE средства, например Design/IDEF, Power Designer, СА ERWin Process Modeler Community Edition, ARIS Express и др.

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

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

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

3.2.3 Характеристика первичных документов с нормативно-справочной и входной оперативной информацией

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

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

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

3.2.4. Характеристика базы данных

3.2.4.1. Характеристика инфологической модели БД

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

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

3.2.4.2.Характеристика даталогической модели БД

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

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

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

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

3.2.5. Характеристика результатной информации

3.2.5.1. Характеристика таблиц с результатной информацией

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

3.1.5.2. Характеристика результатных документов

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

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

3.3. Программное обеспечение задачи (комплекса задач)

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

3.3.1.Общие положения (дерево функций и сценарий диалога)

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

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

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

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

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

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

3.3.2. Структурная схема пакета (дерево вызова процедур и программ)

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

- выполняющие служебные функции;

- управляющие модули, предназначенные для загрузки меню и передачи управления другому модулю;

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

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

Если проектирование ведется с помощью языков четвертого поколения, например генераторов экранных форм, отчетов, то эту схему следует преобразовать в схему настройки, отражающей виды и состав используемых объектов проектирования по каждому виду, применяемых в этих средствах: «Форм», «Отчетов», «Запросов» и «Кнопочная форма».

3.3.3. Описание программных модулей

Описание программных модулей должно включать блок-схемы и описание блок-схем алгоритмов основных расчетных модулей (объемом не менее 500 операторов ) или настройки программных модулей (при внедрении типовых информационных систем).

3.4.Технологическое обеспечение задачи (комплекса задач)

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

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

3.5. Описание контрольного примера реализации проекта

Описание контрольного примера включает описание:

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

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

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

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

3.6. Оценка экономической эффективности проекта

3.6.1 Расчет затрат на реализацию проекта

Анализ затрат на оплату труда.

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

Анализ затрат на ресурсное обеспечение.

Наиболее существенные затраты, помимо стоимости рабочей силы:

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

- стоимость расходных материалов;

- стоимость энергии и аренды помещения.

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

3.6.2 Расчет ожидаемого экономического результата от использования результатов проекта

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

Разработанная информационная система должна рассматриваться как средство оптимизации бизнес-процессов предприятия, а ее использование (фактическое или подразумевающееся) должно оказывать существенное влияние на бизнес в моделях «TO-BE». Как правило, внедрение ИС приводит к результатам следующего вида:

- улучшение производительности процесса;

- меньшее количество ошибок;

- лучшая управляемость процесса;

- снижение себестоимости итогового продукта (результата);

- ускорение бизнес-процесса;

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

- соответствие соответствующим стандартам и правилам (в том числе лучшим практикам);

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

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

Заключение

Заключение – важнейший, наряду с введением, раздел ВКР, который обязательно внимательно изучается членами ГЭК. Оно должно показывать выполненную работу объективно и с наилучшей стороны и, при этом, быть максимально кратким.

Рекомендуется следующая формальная структура заключения:

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

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

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