3.3 Рекомендации по реализации проектного решения

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

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

На Рис.54, 55 показаны примеры диаграмм анализа разрывов для архитектуры приложений и технологической архитектуры. Заметим, что решения о добавлении, удалении, оставлении элементов неизменными принимаются на основании взаимосвязей между слоями.

Рис. 54. Анализ разрывов в архитектуре приложений

Рис.55. Анализ разрывов в технологической архитектуре

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

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

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

Рис.56. Пример модели «как будет» с указанием произведенных изменений

В рамках пункта «Синтез схемы миграции от исходного к целевому состоянию» строится диаграмма реализации перехода к целевому состоянию (см. пример на Рис.57).

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

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

Рис.57.Схема планирования миграции (перехода от исходной к целевой архитектуре)

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

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

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

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

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

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

В приведенном примере выбран один из методов черного ящика "по классам эквивалентности - отказы" (таблица 1).

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