Стадия 2. Разработка концепции ИС.

· изучение объекта автоматизации;

• проведение необходимых научно-исследовательских работ;
• разработка вариантов концепции ИС, удовлетворяющих требованиям пользовате­лей;

· оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

· разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

· разработка предварительных проектных решений по системе и ее частям;

· разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

· разработка проектных решений по системе и ее частям;

• разработка документации на ИС и ее части;
• разработка и оформление документации на поставку комплектующих изделий;

· разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация.

· разработка рабочей документации на ИС и ее части;

· разработка и адаптация программ.

Стадия 7. Ввод в действие.

· подготовка объекта автоматизации;

• подготовка персонала;
• комплектация ИС поставляемыми изделиями (программными и техническими средст­вами, программно-техническими комплексами, информационными изде­лиями);
• строительно-монтажные работы;
• пусконаладочные работы;
• проведение предварительных испытаний;
• проведение опытной эксплуатации;

· проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

· выполнение работ в соответствии с гарантийными обязательствами;

· послегарантийное обслуживание.

Oбследование- это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Мате­риалы, полученные в результате обследования, используются для:

· обоснования разработки и поэтапного внедрения систем;

• составления технического задания на разработку систем;

· разработки технического и рабочего проектов систем.

На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации.

Основная задача первого этапа обследования - оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автома­тизируемого объекта высокого уровня [8]. Эти задачи могут быть реализованы или заказчи­ком ИС самостоятельно, или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями сис­темы и бизнес-экспертами. Основная задача взаимодействия - получить полное и одно­значное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.

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

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

Ориентировочное содержание этого документа:

· ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;

• совокупность условий, при которых предполагается эксплуатировать будущую сис­тему: архитектура системы, аппаратные и программные ресурсы, условия функ­ционирования, обслуживающий персонал и пользователи системы;
• сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ре­сурсы, меры по защите информации;
• описание выполняемых системой функций;
• возможности развития системы;
• информационные объекты системы;
• интерфейсы и распределение функций между человеком и системой;
• требования к программным и информационным компонентам ПО, требования к СУБД;

· что не будет реализовано в рамках проекта.

На этапе детального анализа деятельности организации изучаются задачи, обеспе­чивающие реализацию функций управления, организационная структура, штаты и содер­жание работ по управлению предприятием, а также характер подчиненности вышестоя­щим органам управления. На этом этапе должны быть выявлены:

· инструктивно-методические и директивные материалы, на основании которых опреде­ляются состав подсистем и перечень задач;

· возможности применения новых методов решения задач.

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

· функции - информация о событиях и процессах, которые происходят в бизнесе;

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

При изучении каждой функциональной задачи управления определяются:

· наименование задачи; сроки и периодичность ее решения;

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

· потребители результатной информации по задаче.

Одной из наиболее трудоемких, хотя и хорошо формализуемых задач этого этапа яв­ляется описание документооборота организации. При обследовании документооборота со­ставляется схема маршрута движения документов, которая должна отразить:

· количество документов;

• место формирования показателей документа;
• взаимосвязь документов при их формировании;
• маршрут и длительность движения документа;
• место использования и хранения данного документа;
• внутренние и внешние информационные связи;

· объем документа в знаках.

По результатам обследования устанавливается перечень задач управления, решение которых целесообразно автоматизировать, и очередность их разработки.

На этапе обследования следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MuSCoW [9].

Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won't have - отсутствую­щие функции.

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

Реализация функций второй и третьей категорий ограничивается временными и фи­нансовыми рамками: разрабатывается то, что необходимо, а также максимально возмож­ное в порядке приоритета число функций второй и третьей категорий.

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

Модели деятельности организации создаются в двух видах:

· модель "как есть"("as-is")- отражает существующие в организации бизнес-про­цессы;

· модель "как должно быть"("to-be") - отражает необходимые изменения бизнес-процессов с учетом внедрения ИС.

На этапе анализа необходимо привлекать к работе группы тестирования для реше­ния следующих задач:

· получения сравнительных характеристик предполагаемых к использованию аппарат­ных платформ, операционных систем, СУБД, иного окружения;

· разработки плана работ по обеспечению надежности информационной системы и ее тестирования.

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

Для автоматизации тестирования следует использовать системы отслеживания оши­бок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их по­вторное появление, контролировать скорость и эффективность исправления ошибок, ви­деть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по e-mail и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.

Результаты обследования представляют объективную основу для формирования тех­нического задания на информационную систему.

Техническое задание- это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.

При разработке технического задания необходимо решить следующие задачи:

· установить общую цель создания ИС, определить состав подсистем и функциональ­ных задач;

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

· провести предварительный расчет затрат на создание системы и определить уро­вень экономической эффективности ее внедрения.

Типовые требования к составу и содержанию технического задания приведены в таблице 3.1.

Таблица 3.1. Состав и содержание технического задания (ГОСТ 34.602- 89)
№ п\п	Раздел	Содержание

	Общие сведения	· полное наименование системы и ее условное обо­значение · шифр темы или шифр (номер) договора; · наименование предприятий разработчика и заказ­чика системы, их реквизиты · перечень документов, на основании которых соз­дается ИС · плановые сроки начала и окончания работ · сведения об источниках и порядке финансирова­ния работ · порядок оформления и предъявления заказчику результатов работ по созданию системы, ее час­тей и отдельных средств
	Назначение и цели создания (развития) системы	· вид автоматизируемой деятельности · перечень объектов, на которых предполагается использование системы · наименования и требуемые значения техниче­ских, технологических, производственно-эконо­мических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС
	Характеристика объектов автоматизации	· краткие сведения об объекте автоматизации · сведения об условиях эксплуатации и характери­стиках окружающей среды
	Требования к системе	Требования к системе в целом: · требования к структуре и функционированию сис­темы (перечень подсистем, уровни иерархии, степень централизации, способы информацион­ного обмена, режимы функционирования, взаи­модействие со смежными системами, перспек­тивы развития системы) · требования к персоналу (численность пользовате­лей, квалификация, режим работы, порядок подготовки) · показатели назначения (степень приспособляемо­сти системы к изменениям про­цессов управления и значений параметров) · требования к надежности, безопасности, эргоно­мике, транспортабельности, эксплуатации, тех­ническому обслуживанию и ремонту, защите и сохранности информации, защите от внешних воздействий, к патентной чистоте, по стандарти­зации и унификации Требования к функциям (по подсистемам): · перечень подлежащих автоматизации задач · временной регламент реализации каждой функ­ции · требования к качеству реализации каждой функ­ции, к форме представления выходной ин­формации, характеристики точности, достовер­ности выдачи результатов · перечень и критерии отказов Требования к видам обеспечения: · математическому (состав и область применения мат. моделей и методов, типовых и разрабаты­ваемых алгоритмов) · информационному (состав, структура и организа­ция данных, обмен данными между компонентами системы, информационная со­вместимость со смежными системами, исполь­зуемые классификаторы, СУБД, контроль дан­ных и ведение информационных массивов, про­цедуры придания юридической силы выходным документам) · лингвистическому (языки программирования, языки взаимодействия пользователей с систе­мой, системы кодирования, языки ввода- вы­вода) · программному (независимость программных средств от платформы, качество программных средств и способы его контроля, использование фондов алгоритмов и программ) · техническому · метрологическому · организационному (структура и функции эксплуа­тирующих подразделений, защита от ошибочных действий персонала) · методическому (состав нормативно- технической документации)
	Состав и содержание работ по созданию системы	· перечень стадий и этапов работ · сроки исполнения · состав организаций — исполнителей работ · вид и порядок экспертизы технической докумен­тации · программа обеспечения надежности · программа метрологического обеспечения
	Порядок контроля и приемки системы	· виды, состав, объем и методы испытаний сис­темы · общие требования к приемке работ по стадиям · статус приемной комиссии
	Требования к составу и со­держанию работ по подго­товке объекта автоматизации к вводу системы в действие	· преобразование входной информации к машино­читаемому виду · изменения в объекте автоматизации · сроки и порядок комплектования и обучения пер­сонала
	Требования к документиро­ванию	· перечень подлежащих разработке документов · перечень документов на машинных носителях
	Источники разработки	документы и информационные материалы, на основании которых разрабатывается ТЗ и система

Эскизный проект предусматривает разработку предварительных проектных реше­ний по системе и ее частям.

Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для кон­кретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей по­следовательности работ.

Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эс­кизного проектирования определяются:

· функции ИС;

• функции подсистем, их цели и ожидаемый эффект от внедрения;
• состав комплексов задач и отдельных задач;
• концепция информационной базы и ее укрупненная структура;
• функции системы управления базой данных;
• состав вычислительной системы и других технических средств;

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

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

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

На этом этапе осуществляется комплекс научно-исследовательских и эксперимен­тальных работ для выбора основных проектных решений и расчет экономической эффек­тивности системы.

Состав и содержание технического проекта приведены в таблице 3.2.

Таблица 3.2. Содержание технического проекта
№ п\п	Раздел	Содержание

	Пояснительная за­писка	· основания для разработки системы · перечень организаций разработчиков · краткая характеристика объекта с указанием основных технико-экономических показателей его функциониро­вания и связей с другими объектами · краткие сведения об основных проектных решениях по функциональной и обеспечивающим частям системы
	Функциональная и организационная структура системы	· обоснование выделяемых подсистем, их перечень и на­значение · перечень задач, решаемых в каждой подсистеме, с крат­кой характеристикой их содержания · схема информационных связей между подсистемами и между задачами в рамках каждой подсистемы
	Постановка задач и алгоритмы реше­ния	· организационно-экономическая сущность задачи (на­именование, цель решения, краткое содержание, ме­тод, периодичность и время решения задачи, способы сбора и передачи данных, связь задачи с другими за­дачами, характер использования результатов решения, в которых они используются) · экономико-математическая модель задачи (структур­ная и развернутая форма представления) · входная оперативная информация ( характеристика по­казателей, диапазон изменения, формы представле­ния) · нормативно-справочная информация ( НСИ) (содержа­ние и формы представления) · информация, хранимая для связи с другими задачами · информация, накапливаемая для последующих реше­ний данной задачи · информация по внесению изменений ( система внесе­ния изменений и перечень информации, подвергаю­щейся изменениям) · алгоритм решения задачи ( последовательность этапов расчета, схема, расчетные формулы) · контрольный пример (набор заполненных данными форм входных документов, условные документы с на­капливаемой и хранимой информацией, формы выход­ных документов, заполненные по результатам решения экономико-технической задачи и в соответствии с раз­работанным алгоритмом расчета)
	Организация ин­формационной базы	· источники поступления информации и способы ее пере­дачи · совокупность показателей, используемых в системе · состав документов, сроки и периодичность их поступле­ния · основные проектные решения по организации фонда НСИ · состав НСИ, включая перечень реквизитов, их определе­ние, диапазон изменения и перечень доку­ментов НСИ · перечень массивов НСИ, их объем, порядок и частота корректировки информации · структура фонда НСИ с описанием связи между его эле­ментами; требования к технологии создания и ве­дения фонда · методы хранения, поиска, внесения изменений и кон­троля · определение объемов и потоков информации НСИ · контрольный пример по внесению изменений в НСИ · предложения по унификации документации
	Альбом форм до­кументов
	Система математи­ческого обеспече­ния	· обоснование структуры математического обеспечения · обоснование выбора системы программирования · перечень стандартных программ
	Принцип построе­ния комплекса технических средств	· описание и обоснование схемы технологического про­цесса обработки данных · обоснование и выбор структуры комплекса техниче­ских средств и его функциональных групп · обоснование требований к разработке нестандартного оборудования · комплекс мероприятий по обеспечению надежности функционирования технических средств
	Расчет экономиче­ской эффективно­сти системы	· сводная смета затрат, связанных с эксплуатацией сис­тем · расчет годовой экономической эффективности, источни­ками которой являются оптимизация производ­ственной структуры хозяйства (объединения), сниже­ние себестоимости продукции за счет рационального использования производственных ресурсов и уменьше­ния потерь, улучшения принимаемых управленческих решений
	Мероприятия по подготовке объекта к внедрению сис­темы	· перечень организационных мероприятий по совершенст­вованию бизнес-процессов · перечень работ по внедрению системы, которые необхо­димо выполнить на стадии рабочего проектиро­вания, с указанием сроков и ответственных лиц
	Ведомость доку­ментов

В завершение стадии технического проектирования производится разработка доку­ментации на поставку серийно выпускаемых изделий для комплектования ИС, а также оп­ределяются технические требования и составляются ТЗ на разработку изделий, не изго­товляемых серийно.

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

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

В зависимости от взаимосвязей частей ИС и объекта автоматизации испытания могут быть автономные или комплексные. Автономные испытания охватывают части системы. Их проводят по мере готовности частей системы к сдаче в опытную эксплуатацию. Комплекс­ные испытания проводят для групп взаимосвязанных частей или для системы в целом.

Для планирования проведения всех видов испытаний разрабатывается документ "Программа и методика испытаний". Разработчик документа устанавливается в договоре или ТЗ. В качестве приложения в документ могут включаться тесты или контрольные при­меры.

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

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

Приемочные испытания проводят для определения соответствия системы техни­ческому заданию, оценки качества опытной эксплуатации и решения вопроса о возможно­сти приемки системы в постоянную эксплуатацию.

Типовое проектирование ИС

Методы типового проектирования ИС достаточно подробно рассмотрены в литера­туре [10]. В данной книге приведены основные определения и представлено задание для разработки проекта ИС методом типового проектирования (кейс "Проектирование ИС предприятия оптовой торговли лекарственными препаратами").

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

Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократ­ному использованию) проектное решение.

Принятая классификация ТПР основана на уровне декомпозиции системы. Выделя­ются следующие классы ТПР:

· элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, орга­низационному);

• подсистемные ТПР - в качестве элементов типизации выступают отдельные подсис­темы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;

· объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.

Основные особенности различных классов ТПР приведены в таблице 3.3.

Таблица 3.3. Достоинства и недостатки ТПР
Класс ТПР Реали­зация ТПР	Достоинства	Недостатки

Элементные ТПР Библиотеки методо-ориентированных программ	· обеспечивается применение модульного подхода к проек­тированию и документирова­нию ИС	· большие затраты вре­мени на сопряжение разнородных элементов вследствие информаци­онной, программной и технической несовмес­тимости · большие затраты вре­мени на доработкуТПР отдельных элементов
Подсистемные ТПР Пакеты прикладных программ	· достигается высокая степень интеграции элементов ИС · позволяют осуществлять: мо­дульное проектирование; па­раметрическую настройку программных компонентов на различные объекты управле­ния · обеспечивают: сокращение за­трат на проектирование и программирование взаимо­связанных компонентов; хо­рошее документирование отображаемых процессов об­работки информации	· адаптивность ТПР недос­таточна с позиции не­прерывного инжиниринга деловых процессов · возникают проблемы в комплексировании раз­ных функциональных подсистем, особенно в случае использования решений нескольких производителей про­граммного обеспечения
Объектные ТПР От­раслевые проекты ИС	· комплексирование всех ком­понентов ИС за счет методо­логического единства и ин­формационной, программной и технической совместимости · открытость архитектуры — по­зволяет устанавливатьТПР на разных программно-тех­нических платформах · масштабируемость — допус­кает конфигурацию ИС для переменного числа рабочих мест · конфигурируемость — позво­ляет выбирать необходимое подмножество компонентов	· проблемы привязки типо­вого проекта к кон­кретному объекту управ­ления, что вызывает в некоторых случаях даже необходимость измене­ния организационно-экономической струк­туры объекта автомати­зации

Для реализации типового проектирования используются два подхода: параметриче­ски-ориентированное и модельно-ориентированное проектирование.

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

Критерии оценки ППП делятся на следующие группы:

· назначение и возможности пакета;

• отличительные признаки и свойства пакета;
• требования к техническим и программным средствам;
• документация пакета;
• факторы финансового порядка;
• особенности установки пакета;
• особенности эксплуатации пакета;
• помощь поставщика по внедрению и поддержанию пакета;
• оценка качества пакета и опыт его использования;

· перспективы развития пакета.

Внутри каждой группы критериев выделяется некоторое подмножество частных по­казателей, детализирующих каждый из десяти выделенных аспектов анализа выбираемых ППП. Достаточно полный перечень показателей можно найти в литературе [10].

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

Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.

Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия.

Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программ­ного обеспечения. Таким образом, модельно-ориентированное проектирование ИС пред­полагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продук­том и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.

Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) мо­дели определенных классов ИС, модели конкретных ИС предприятий.

Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые под­держиваются программными модулями типовой ИС.

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

Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в ре­зультате экспертного опроса (SAP Business Engineering Workbench).

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

Бизнес-правила определяют условия корректности совместного применения различ­ных компонентов ИС и используются для поддержания целостности создаваемой системы.

Модель бизнес-функций представляет собой иерархическую декомпозицию функ­циональной деятельности предприятия (подробное описание см. в разделе "Анализ и мо­делирование функциональной области внедрения ИС").

Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций (подробное описание см. в разделе "Спецификация функ­циональных требований к ИС"). Для отображения процессов используется модель управ­ления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов по­зволяет выполнить настройку программных модулей - приложений информационной сис­темы в соответствии с характерными особенностями конкретного предприятия.

Модели бизнес-объектов используются для интеграции приложений, поддерживаю­щих исполнение различных бизнес-процессов (подробное описание см. в разделе "Этапы проектирования ИС с применением UML").

Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС").

Внедрение типовой информационной системы начинается с анализа требований к конкретной ИС, которые выявляются на основе результатов предпроектного обследования объекта автоматизации (см. раздел "Анализ и моделирование функциональной области внедрения ИС"). Для оценки соответствия этим требованиям программных продуктов мо­жет использоваться описанная выше методика оценки ППП. После выбора программного продукта на базе имеющихся в нем референтных моделей строится предварительная мо­дель ИС, в которой отражаются все особенности реализации ИС для конкретного предпри­ятия. Предварительная модель является основой для выбора типовой модели системы и определения перечня компонентов, которые будут реализованы с использованием других программных средств или потребуют разработки с помощью имеющихся в составе типовой ИС инструментальных средств (например, ABAP в SAP, Tools в BAAN).

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

· установку глобальных параметров системы;

• задание структуры объекта автоматизации;
• определение структуры основных данных;
• задание перечня реализуемых функций и процессов;
• описание интерфейсов;
• описание отчетов;
• настройку авторизации доступа;
• настройку системы архивирования.

Лекция 4. Анализ и моделирование функциональной области внедрения ИС: Ос­новные понятия организационного бизнес-моделирования. Миссия компании, дерево целей и стратегии их дос­тижения. Статическое описание компании: бизнес-потенциал компании, функционал компании, зоны ответст­венности менеджмента. Динамическое описание компании. Процессные потоковые модели. Модели структур данных. Полная бизнес-модель компании. Шаблоны организационного бизнес-моделирования. Построение орга­низационно-функциональной структуры компании. Этапы разработки Положения об организационно-функцио­нальной структуре компании. Информационные технологии организационного моделирования.

Полная бизнес-модель компании

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

Рис. 4.1. Обобщенная схема организационного бизнес- моделирования

Миссия согласно [ISO-15704] -это

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

Миссия компании по удовлетворению социально-знач