Разработка системной архитектуры

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

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

Основные элементы этой методологии основываются на следующих концепциях:

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

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

Правила SADT включают:

· ограничение количества блоков на каждом уровне декомпозиции (3-6 блоков);

· связность диаграмм (номера блоков);

· уникальность меток и наименований (отсутствие повторяющихся имен);

· синтаксические правила для графики (блоков и дуг);

· разделение входов и управлений (правило определения роли данных);

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

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

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

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

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

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

 

Рис 2.1. Диаграмма IDF0 до внедрения.

 

Ниже приставлена декомпозиция (рисунок 2.2.) выше описанной диаграммы нулевого уровня. Данная диаграмма представляет пять промежуточных процессов служащих для учета и регистрации заказов. Ниже они перечислены:

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

· регистрация информации о заказчике и контрагенте – Вносится в базу данных реквизиты заказчика и контр агента менеджером проекта;

· составление договора – менеджер составляет договор в соответствии с согласованными работами;

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

· предоставление штату программистов информации о работах принятых на выполнения.

 

 

Рис 2.2. Диаграмма IDF1 до внедрения.

 

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

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

Рис 2.3. Диаграмма IDF1 после внедрения.

После внедрения диаграмма IDF1 в декомпозиции (рисунок 2.4.) были внесены некоторые изменения:

Добавился новый под процесс «Составление отчетной документации» на котором средствами информационной системы генерируется отчетная документация;

Программный модуль принимает участие в составлении договора;

К выходной информации добавлена отчетная документация из процесса «Составление отчетной документации»;

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