Понятие и классификация методов типового проектирования
Методы типового проектирования ИС предполагают создание системы из готовых покупных типовых элементов (типовых проектных решений). Для этого проектируемую ИС декомпозируют на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.), для которых подбираются и закупаются типовые проектные решения. Закупленные типовые элементы, как правило, включающие программные продукты, настраиваются на особенности конкретного предприятия или дорабатываются в соответствии с требованиями проблемной области.
Типовое проектное решение(ТПР) - проектное решение, представленное в виде проектной документации, включая программные модули, пригодное к многократному использованию. В качестве проектного решения могут выступать как отдельные компоненты ИС (программные модули, функциональные задачи, АРМы, локальные БД, ЛВС), так и взаимосвязанные комплексы компонентов (функциональных и обеспечивающих подсистем, ИС в целом). Типовые проектные решения также называют тиражируемыми продуктами.
В зависимости от уровня декомпозиции системы различают элементный, подсистемный и объектный методы типового проектирования.
Элементный метод подразумевает использование типового решения по задаче или по отдельному виду обеспечения задачи:
· информационному: БД, файлы;
· программному: ОС, СУБД, ЯП;
· техническому;
· математическому: математические методы;
· организационному: методические материалы по работе персонала.
Сущность элементного метода – в комплектации ИС из множества ТПР по отдельным разрозненным задачам.
Достоинство элементного метода типового проектирования ИС связано с применением модульного подхода к проектированию и документированию ИС.
Недостатки - большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости ТПР, а также плохая адаптивность (настраиваемость) элементов к особенностям предприятия. Большие затраты времени на доработку и комплексирование ТПР отдельных элементов сопоставимы со временем ручного оригинального проектирования ИС.
Подсистемный метод типового проектирования ИС подразумевает типизацию отдельных подсистем, которые обеспечивают функциональную полноту, минимизацию внешних информационных связей, параметрическую настраиваемость, альтернативность схем в пределах значений входных параметров. При этом достигается более высокая степень интеграции типовых элементов ИС.
ТПР для функциональных подсистем реализуются в виде ППП, которые позволяют осуществлять:
· модульное проектирование;
· параметрическую настройку программных компонентов на различные объекты управления;
· сокращение затрат на проектирование и программирование взаимосвязанных компонентов;
· хорошее документирование отображаемых процессов обработки информации.
Однако, при построении единой, корпоративной ИС возникают проблемы в комплексировании ППП разных функциональных подсистем, особенно в случае использования ППП нескольких производителей программного обеспечения, для которых, как правило, характерна их информационная, программная и техническая несовместимость между собой.
В качестве примеров широко распространенных функциональных ППП можно назвать: lC «Предприятие» (автоматизация бухгалтерского учета, расчета заработной платы, складского учета), «Фолио - Склад» (автоматизация складских операций), Project Expert (бизнес-планирование), ИНЭК (финансовый анализ) и др.
Объектный метод подразумевает использование типового проекта для объектов управления определенной отрасли, включающего набор функциональных и обеспечивающих подсистем ИС. Современные типовые проекты отличаются:
· открытостью архитектуры, позволяющей устанавливать проекты на разных программно-технических платформах;
· масштабируемостью, допускающей конфигурацию переменного числа рабочих мест;
· конфигурируемостью, позволяющей выбирать подмножество компонентов, которые необходимы для конкретной проблемной области и параметрически настраиваются на особенности объекта управления.
Преимущество объектного метода перед подсистемным методом заключается в комплексируемости всех компонентов за счет методологического единства, а также информационной, программной и технической совместимости компонентов.
Case-средства для моделирования деловых процессов. Этапы построения модели IDEF0.
CASE-средства (от Computer Aided Software/System Engineering) позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE-средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций. Применимы практически во всех сферах деятельности. Результат применения CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.
На данный момент наиболее распространенными являются case-средства таких разработчиков:
· Erwin (Erwin Business Process; Erwin Data Modeler);
· IBM Rational Software (Rational Software Modeler; Rational Software Architect);
· Oracle (Oracle Designer).
Выделяют следующие группы CASE средств:
· CASE средства верхнего уровня. Эти CASE средства ориентированы на начальные этапы построения информационной системы. Они связаны с анализом и планированием. CASE средства верхнего уровня обеспечивают стратегическое планирование, расстановку целей, задач и приоритетов, а также графическое представление необходимой информации. Все CASE средства верхнего уровня содержат графические инструменты построения диаграмм, таких как диаграммы сущность-связь (ER диаграммы), диаграммы потока данных (DFD), структурные схемы, деревья решений и пр.
· CASE средства нижнего уровня. Эти CASE средства больше сфокусированы на последних этапах разработки информационной системы – проектирование, разработка программного кода, тестирование и внедрение. CASE средства нижнего уровня зависят от данных, которые предоставляют средства верхнего уровня. Они используются разработчиками приложений и помогают создать информационную систему, однако не являются полноценными инструментами разработки программного обеспечения.
· Интегрированные CASE средства (I – CASE). Эти CASE средства охватывают полный жизненный цикл разработки информационной системы. Они позволяют обмениваться данными между инструментами верхнего и нижнего уровня и являются своего рода «мостом» между CASE средствами верхнего и нижнего уровней.
Для моделирования и оптимизации бизнес процессов применяются CASE средства верхнего уровня и интегрированные CASE средства. Они позволяют повысить качество моделей бизнес процессов за счет автоматического контроля, дают возможность оценить ожидаемый результат, ускоряют процесс проектирования, обеспечивают возможности по изменению и обновлению моделей.
Основными характеристиками CASE средств, важными с точки зрения моделирования и оптимизации бизнес процессов, являются следующие:
· Наличие графического интерфейса;
· Наличие репозитория. Репозиторий это общая база данных, которая содержит описание элементов процессов и отношений между ними;
· Гибкость применения;
· Возможность коллективной работы;
· Построение прототипов;
· Построение отчетов.
Выбор CASE средств для анализа и моделирования процессов зависит от многих факторов – финансовых возможностей, функциональных характеристик, подготовки персонала, применяемых информационно-технических средств и пр. Приводить исчерпывающий состав этих факторов не имеет смысла, т.к. в ситуации выбора для каждого конкретного случая этот состав будет изменяться. Тем не менее, можно определить набор «базовых» факторов, на основании которых определяются критерии по выбору CASE средств.
К таким «базовым» факторам можно отнести следующие:
· Цели моделирования и анализа процессов;
· Удобство для пользователей;
· Применение стандартных методологий;
· Удобство эксплуатации;
· Трудоемкость;
· Субъективность.