3.Два способа перехода от модели as-is к модели to-be. (35)
Переход от модели AS-IS к модели TO-BE осуществляется следующими двумя способами.
Совершенствованием технологий производства на основе оценки их эффективности. При этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников («легкий» реинжиниринг).
Радикальное изменение технологий и переосмысление бизнес-процессов («жесткий» реинжиниринг).
Построенные модели имеют самостоятельное практическое значение.
4.Решения начальных этапов проектирования информационной системы (36)
На начальных этапах процесса проектирования должны быть приняты принципиальные решения, во многом определяющие этот процесс, а также качество и трудоемкость разработки. К таким решениям относят:
выбор архитектуры программного обеспечения;
выбор типа пользовательского интерфейса и технологии работы с документами;
выбор подхода к разработке (структурного, объектного и т.п.);
выбор языка и среды программирования.
Другими словами, эти решения определяют, что проектируется, с какими потребительскими характеристиками, как и какими средствами.
Часть решений может быть определена в техническом задании, образовав группу технологических требований, остальные, должны быть приняты как можно раньше, так как представляют собой исходные данные для процесса проектирования.
5.Методология структурного анализа sadt и стандарт моделирования бизнес-процессов idef0. (44)
В начале 90-х годов в США на основе SADT был принят стандарт моделирования бизнес-процессов IDEFO (http://www.idef.com), который является независимым от частных организаций стандартом и получил чрезвычайно широкое распространение, он принят в качестве стандарта в нескольких международных организациях, в том числе в НАТО и МВФ.
Основная идея методологии SADT – построение древовидной функциональной модели предприятия. Сначала функциональность предприятия (Activity) описывается в целом, без подробностей. Такое описание называется контекстной диаграммой. В этом случае взаимодействие с окружающим миром описывается в терминах
Control
Activity
Mechanism
Input (Вход) – материал, данные, информация или объекты, которые используются или преобразуются работой для получения результата (выхода).
Допускается, что работа может не иметь ни одной стрелки входа. Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может, служить то, перерабатывается /изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет – управление.
Result – материал или информация, которые производятся работой. Основной результат деятельности функции, конечный продукт. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла.
Control (управление) – бизнес-правила, стратегии, процедуры или стандарты, которыми руководствуется функция (работа).Управление влияет на работу, но не преобразуется работой. Если цель работы будет связана с изменением процедуры или стратегии, то такая процедура или стратегия будет для работы входом.
Mechanism (механизм) – все необходимые ресурсы, необходимые для реализации функции. IT – ресурсы, которые выполняют работу (ОС, среда разработки, библиотеки повторно используемых компонент, языки программирования, СУБД, персонал и т.д.)
Activity (работа) – обозначает поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Все работы должны быть названы и определены. Имя работы должно быть выражено сочетанием отглагольного существительного, обозначающего процесс, например: «Прием, заказа», «Оформление заказа», «Оплата заказа» и т.д. При создании новой функциональной модели создается контекстная диаграмма с единственной работой, изображающей систему в целом.