Понятие проектирования и проекта ИС. Свойства проекта ИС.
С точки зрения теории принятия решений процесс проектирования ЭИС – это процесс принятия проектно – конструкторских решений, направленных на получение описания системы (проекта ЭИС), удовлетворяющего требованиям заказчика.
Под проектом ЭИС будем понимать проектно-конструкторскую и технологическую документацию, в которой представлено описание проектных решений по созданию и эксплуатации ЭИС в конкретной программно-технической среде.
Под проектированием ЭИС понимается процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в соответствии с ГОСТом в проект ЭИС. С этой точки зрения проектирование ЭИС сводится к последовательной формализации проектных решений на различных стадиях жизненного цикла ЭИС: планирования и анализа требований, технического и рабочего проектирования, внедрения и эксплуатации ЭИС.
Объектами проектирования ЭИС являются отдельные элементы или их комплексы функциональных и обеспечивающих частей. Так, функциональными элементами в соответствии с традиционной декомпозицией выступают задачи, комплексы задач и функции управления. В составе обеспечивающей части ЭИС объектами проектирования служат элементы и их комплексы информационного, программного и технического обеспечения системы.
В качестве субъекта проектирования ЭИС выступают коллективы специалистов, которые осуществляют проектную деятельность, как правило, в составе специализированной (проектной) организации, и организация-заказчик, для которой необходимо разработать ЭИС.
Масштабы разрабатываемых систем определяют состав и количество участников процесса проектирования. При большом объеме и жестких сроках выполнения проектных работ в разработке системы могут принимать участие несколько проектных коллективов (организаций-разработчиков). В этом случае выделяется головная организация, которая координирует деятельность всех организаций-соисполнителей.
Возможен вариант, при котором функции заказчика и разработчика совмещаются, то есть ЭИС проектируется собственными силами.
Свойства проекта:
Проект всегда имеет четко определенную цель, которая выражается в получении некоторого результата. Достижение этого результата означает успешное завершение и окончание проекта. Например, для проекта строительства здания результатом является само здание, принятое в эксплуатацию.
Проект имеет четко очерченное начало, которое совпадает с началом первой работы, направленной на достижение поставленной цели. Начало может задаваться директивно, либо рассчитываться в результате составления плана работ по проекту.
Проект имеет четко очерченный конец, который совпадает с концом последней работы, направленной на получение заданного результата. Как и начало, конец проекта может задаваться директивно, или рассчитываться при составлении плана работ..
Проект исполняется командой, в состав которой входит руководитель проекта, менеджеры, исполнители. Помимо основной команды в нем могут участвовать сторонние исполнители, команды и организации, которые привлекаются на временной основе для выполнения отдельных работ.
При реализации проекта используются материальные ресурсы. Их номенклатура и количество определяются характером проекта и входящих в него работ. Так при строительстве дома используются песок, щебень, цемент, кирпич и т.п.
Проект имеет бюджет. Стоимость проекта складывается из стоимости израсходованных материальных ресурсов, затрат по оплате труда реализующей его команды и прочих расходов, связанных с особенностями конкретных видов работ.
Проект имеет ограничения трех видов:
· Ограничения по бюджету устанавливают предельную стоимость всего проекта или отдельных видов работ.
· Ограничения по времени задают предельные сроки окончания либо всего проекта, либо некоторых работ.
· Ограничения по ресурсам определяются ограниченным составом команды или графиками поступления материальных ресурсов.
Модель Дж.Захмана.
Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем.
В своей работе Дж. Захман определил Архитектуру предприятия как "набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)".
Для удобства описания Захман предложил так называемую Модель архитектуры предприятия.
В то время, когда были опубликованы работы Захмана, традиционным подходом при формировании описания системы являлось использование концепции "жизненного цикла", включающего такие этапы, как планирование, анализ, проектирование, разработка, документирование, внедрение и промышленная эксплуатация. На каждом из этих этапов рассматриваются вопросы, связанные как с функциями системы, так и с данными. Захман предложил вместо традиционного подхода, связанного с рассмотрением отдельных аспектов работы системы как бы в различные моменты времени, использовать рассмотрение системы с различных перспектив.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов, которая приведена на рисунке 8.2. Заметим, что в модели именно пять строк, просто отображенная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Перспективы (строки в таблице) могут, в частном случае, соответствовать различному уровню управления предприятием, если речь идет об архитектуре предприятия или использования информационной системы.
На каждом из этих уровней участники, вообще говоря, рассматривают одни и те же категории вопросов, соответствующих столбцам в таблице, – только с различным уровнем абстракции и детализации. В содержание этих колонок входят:
· используемые данные (что?)
· процессы и функции (как?)
· места выполнения этих процессов (где?)
· организации и персоналии–участники (кто?)
· управляющие события (когда?)
· цели и ограничения, определяющие работу системы (зачем?)
Основные правила заполнения таблицы следующие:
· каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы ("базис");
· порядок следования колонок несущественен;
· каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);
· базовые модели для каждой из колонок являются уникальными;
· соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
· заполнение клеток должно проводиться последовательно "сверху вниз", попытка пропуска одного из рядов является, скорее, "шаманством" (в том плане, что нельзя создать хорошо работающую систему, "перепрыгнув" определенные уровни ее описания на этапе проектирования).
Строки:
Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк.
Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.
Третий уровень (логическая модель) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы HelpDesk.
Колонки:
Первая колонка отвечает на вопрос "ЧТО?" и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы "сущности-связи" (E-R диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п.
Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям.
Далее колонка (вопрос "ГДЕ?") определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов. На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, – будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня (так называемое "middleware"), используемых для интеграции различных компонент информационной системы между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети.
Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли (в RUP используются диаграммы событий и описание вариантов использования), требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы.
Пятая колонка отвечает на вопрос "КОГДА?" и определяет временные характеристики бизнес-процессов и работы системы. Опять-таки детализация осуществляется сверху вниз, начиная от календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2). На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы.
Последняя колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию.
Понятие функциональной подсистемы. Классы и содержание подсистем. Методы выделения функциональных подсистем.
Функциональная подсистема ЭИС представляет собой комплекс экономических задач с высокой степенью информационных обменов (связей) между задачами. При этом под задачей будем понимать некоторый процесс обработки информации с четко определенным множеством входной и выходной информации (например, начисление сдельной заработной платы, учет прихода материалов, оформление заказа на закупку и т.д.).
Состав функциональных подсистем во многом определяется особенностями экономической системы, ее отраслевой принадлежности, формой собственности, размером, характером деятельности предприятия.
Функциональные подсистемы ЭИС могут строиться по различным принципам:
1. предметному;
2. функциональному;
3. проблемному;
4. смешанному (предметно-функциональному).
По предметному принципу:
• управление сбытом готовой продукции;
• управление производством;
• управление материально-техническим снабжением;
• управление финансами;
• управление персоналом.
При этом в подсистемах рассматривается решение задач на всех уровнях управления(стратегическом, тактическом и оперативном), обеспечивая интеграцию информационных потоков по вертикали (что это значит…?).
• «Техническая подготовка производства» (Цель: сокращение сроков подготовки и выпуска новой продукции, модернизация освоенной продукции, минимизация материальных, трудовых и финансовых затрат на их выпуск)
По функциональному принципу (пример такой ЭИС- «Галактика»):
• планирование;
• регулирование (оперативное управление);
• учет;
• анализ.
Пример:
• «Перспективное развитие» (Цель: прогнозирование и стратегическое планирование финансово-хозяйственной деятельности предприятия на ближайшую и отдаленную перспективу)
• «Технико-экономическое планирование» (Цель: формирование годовых производственных программ на основе использования экономико-математических методов, позволяющих увязывать прогнозируемый объем сбыта продукции с имеющимися производственными мощностями, материальным, трудовыми и финансовыми ресурсами, а также распределение годовой производственной программы по плановым периодам)
• «Бухгалтерский учет и анализ хозяйственной деятельности» (Цель: повышение оперативности и достоверности учетной информации, расширение и усиление аналитических и контрольных функций учета.)
По проблемному принципу:
Проблемный принцип формирования подсистем отражает необходимость гибкого и оперативного принятия управленческих решений по отдельным проблемам в рамках СППР, например, решение задач бизнес-планирования, управления проектами. Такие подсистемы могут реализовываться в виде локальных информационных систем, импортирующих данные из корпоративной информационной системы (например, система бизнес-планирования на основе ППП Project-Expert) или в виде специальных подсистем в рамках корпоративной ЭИС (например, информационной системы руководителя).
По смешанному (предметно-функциональному) принципу:
На практике чаще всего применяется смешанный предметно-функциональный подход, согласно которому построение функциональной структуры ЭИС – это разделение ее на подсистемы по характеру хозяйственной деятельности, которое должно соответствовать структуре объекта и системы управления, а также характеру выполняемых функций управления. Используя этот подход, можно выделить следующий типовой набор функциональных подсистем в общей структуре ЭИС предприятия:
Функциональный принцип:
- перспективное развитие (ПР);
- технико-экономическое планирование (ТЭП);
- бухгалтерский учет и анализ хозяйственной деятельности (БУАХД);
Предметный принцип (подсистемы управления ресурсами):
- техническая подготовка производства (ТПП);
- управление основным производством (УОП);
- управление вспомогательным производством (УВП);
- управление качеством продукции (УКП);
- управление материально-техническим снабжением (УМТС);
- управление реализацией и сбытом готовой продукции (УС);
- управление кадрами (УК).
Подсистемы, построенные по функциональному принципу, охватывают все виды хозяйственной деятельности предприятия (производство, снабжение, сбыт, персонал, финансы). Подсистемы, построенные по предметному принципу, относятся в основном к оперативному уровню управления ресурсами.