Проектирование информационных систем 3 (стр. 5 из 17)
- определяются взаимодействия организационного, элементного и функционального аспектов, то есть раскрывается способ выполнения процесса. Для этого предлагается использовать диаграммы деятельности (Activity), где отражается взаимосвязь процессов на предприятии с ERP-системой;
- определяется документооборот (или товарооборот) между организационными единицами. Документооборот описывается для каждого способа выполнения процесса. Для описания взаимодействия документов и исполнителей предлагается использовать диаграммы кооперации (Collaborations).
В целях облегчения и ускорения процесса моделирования предлагается применять шаблон модели предприятия, созданный внешним консультантом. Использование шаблона обеспечивает интеграцию созданной модели и 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. Стратегические и тактические планы и цели [предприятия], которые определяют формирование правил и процедур для внедрения требований данного Международного Стандарта;