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

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

      2.20 Методология SADT

.

      Методология функционального моделирования SADT (Structured Analysis and Design Technique) - одна из самых известных методологий анализа и проектирования систем, введенная в 1973 г. Дугласом Россом (Ross).

На ее основе разработана, в частности, известная  методология IDEF0 (Icam DEFinition).

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

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

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

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

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

      В настоящее время успешно используются практически все известные методологии  структурного анализа и проектирования, однако наибольшее распространение получили методологии SADT (Structured Analysis and Design Technique), структурного системного анализа Гейна-Сарсона (Gane-Sarson), структурного анализа и проектирования Йодана/Де Марко (Yourdon/De Marko), развития систем Джексона (Jackson), развития структурных систем Варнье-Орра (Warnier-Orr), анализа и проектирования систем реального времени Уорда-Меллора (Ward-Mellor) и Хатли (Hatley), информационного моделирования Мартина (Martin).

Диаграмма примера создана в «Visio 2000».  
 

      2.21 BРwin

.

Использование BРwin в консалтинговых проектах.

КомпьютерПресс 1'2002, Максим Сычевский. 
 

 
 
 
 
 

     2.22 Декомпозиция

. 

 
 
 
 

      2.23 Диаграмма потоков данных

.

Диаграмма потоков данных (DFD). 

 
 

      2.24 Иерархическая структура

.

      2.25 Сравнительный анализ SADT-моделей  и потоковых моделей

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

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

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

      Соотношение применения этих двух разновидностей структурного анализа в существующих CASE-средствах составляет по материалам CASE Consulting Group 90% для DFD и 10% для SADT. По данным автора, основанным на анализе 127 существующих CASE-пакетов, это соотношение выглядит как 94% к 3%, соответственно. Оставшиеся 3% CASE-средств используют методологии, не относящиеся ни к одной из перечисленных разновидностей. Представляется очевидным, что соотношение такого же порядка справедливо и для цифр распространенности рассматриваемых методологий на практике. 

      2.26 Модели процессов проектирования.

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

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

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

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

      Участие системотехников, программистов на всех этапах анализа, залог успешной реализации проекта информатизации бизнес – процессов.

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

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

      2.27 Основные этапы.

Традиционно выделяются следующие основные этапы жизненного цикла (ЖЦ) программного обеспечения:

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

 

      2.28 Модели проектирования.

Классические  модели проектирования информационных систем:

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

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

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

      2.29 «Водопад». 

 
 

      2.30 Этапы.

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

Проектирование – модель данных, экранные формы, выбор среды, архитектура, структура и разработка тестов…

Тестирование – контроль соответствия поставленной задачи и достижения целей.  

      2.31 Организация проектной деятельности.

Стандарты уровня предприятия и проекта. В  стандартах явно предусмотрены работы по постановке проектной деятельности и управлению ею. В ISO/IEC 15288 такими являются:

1. Процесс «Управление предприятием» (внедрение стандарта на основе стратегии предприятия);
2. Процесс «Управление процессами ЖЦС»;
3. Процесс «Управление ресурсами для 1 и 2».

Для процесса «Управление предприятием» предусмотрены  следующие цель и результаты.

      Цель  процесса:

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

      Результаты  процесса:

1. Стратегические и тактические планы и цели [предприятия], которые определяют формирование правил и процедур для внедрения требований данного Международного Стандарта;
2. Правила и процедуры для «управления ЖЦС», включая управление качеством, гарантии и контроль, в соответствии с ISO 9001;
3. Роли, ответственность и права (власть), способствующие эффективному управлению ЖЦС.

 

      2.32 Задачи стандартов.

Стандарты определяют процессы, которые должны в практике работы предприятия отвечать, в частности, на такие вопросы:

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

     Узнать  про используемые стандарты предприятия, можно, поинтересовавшись о последних  результатах внедрения ИС. 

Новый объем процессов ЖЦ системы определяется стандартом EIA 632. 

 

Объем процессов ЖЦ системы по новому стандарту EIA 632 («От старого к новому, от системного проектирования к полному  проектированию систем») 

      2.33 Заключение

.

Итак:

1. Модель бизнеса (предприятия), с использованием математических моделей …
2. Модель проектирования, как процесса.
3. Модели процессов, например, линейное планирование, …
4. Модели данных (иерархическая, файловая, реляционная, объектная, объектно-реляционная, … ).
5. Архитектура системы …

 

     Цель лабораторных и курсовой работ - реализация выбранных бизнес–процессов и набора бизнес – правил.