Учебный курс. Этапы проектирования ис

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

Главной особенностью проектирования является работа с еще не существующим объектом. В этом отличие проектирования от моделирования, где объект не может не существовать.

Проектирование ИС охватывает три основные области:

Проектирование объектов данных, которые будут реализованы в базе данных;

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

Учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

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

Требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

Требуемой пропускной способности системы;

Требуемого времени реакции системы на запрос;

Безотказной работы системы;

Необходимого уровня безопасности;

Простоты эксплуатации и поддержки системы .

Технология проектирования

Технология проектирования АИС – это совокупность методов и средств проектирования АИС, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта АИС). В основу технологии проектирования лежит технологический процесс (ТП), который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий.

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

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

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

Предметом выбираемой технологии проектирования должно служить отражение взаимосвязанных процессов проектирования на всех стадиях жизненного цикла АИС .

Основные требования, предъявляемые к выбираемой технологии проектирования, следующие:

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

Технология должна максимально отражать все этапы цикла жизни проекта;

Технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта;

Технология должна способствовать росту производительности труда проектировщиков;

Технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта;

Технология должна способствовать простому ведению проектной документации.

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

Методы проектирования АИС можно классифицировать по степени использования средства автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям.

По степени автоматизации различают:

Ручное проектирование;

Компьютерное проектирование;

По степени использования типовых проектных решений различают:

Оригинальное проектирование;

Типовое проектирование;

По степени адаптивности проектных решений различаются следующие методы:

Реконструкция – адаптация проектных решений выполняется путем переработки соответствующих компонентов;

Параметризация – проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами;

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

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

Основные стадии создания автоматизированной информационной системы:

Формирование требований к АИС;

Разработка концепции АИС;

Разработка технического задания;

Разработка эскиза проекта;

Разработка технической части проекта;

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

Ввод в действие;

Сопровождение АИС .

Методология проектирования

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

Методы проектирования ИС можно классифицировать по степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям. Так, по степени автоматизации методы проектирования разделяются на:

1. Ручное, при котором проектирование компонентов ИС осуществляется без использования специальных инструментальных программных средств, а программирование - на алгоритмических языках;

2. Компьютерное, при котором производится генерация или конфигурирование (настройка) проектных решений на основе использования специальных инструментальных программных средств.

По степени использования типовых проектных решений различают следующие методы проектирования:

1. Оригинальное (индивидуальное), когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к АИС. Характеризуется тем, что все виды проектных работ ориентированы на создание индивидуальных для каждого объекта проектов, которые в максимальной степени отражают все его особенности;

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

По степени адаптивности проектных решений выделяют методы:

1. Реконструкции, когда адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей);

2. Параметризации, когда проектные решения настраиваются (генерируются) в соответствии с изменяемыми параметрами;

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

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

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

Технология проектирования определяется как совокупность трех составляющих:

Пошаговой процедуры, определяющей последовательность технологических операций проектирования;

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

Нотаций (графических и текстовых средств), используемых для описания проектируемой системы .

Сравнительная характеристика инструментов проектирования

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

Существует около 30 технологий проектирования организационно-технических систем и несколько сотен инструментов, предназначенных для автоматизации этого процесса. Поэтому, с учетом временного фактора, сравнительный анализ был ограничен четырьмя наиболее популярными на российском рынке продуктами: Bpwin/Erwin (Platinum Technology), Rational Rose (Rational Software Corporation), ARIS (Scheer AG) и Oracle Designer (Oracle Developer Suite). Справочные данные по CASE-технологиям и средствам проектирования приведены ниже по тексту и в таблице №1.

Таблица 1

Средства проектирования и их сравнительная характеристика

Критерии				Oracle Designer
Поддержка полного жизненного цикла ИС
Обеспечение целостности проекта
Независимость от платформы	+ (DoDAF, TeaF/FeaT, Zachman)	+ (ORACLE, Informix, Sybase)	+ (ORACLE, Informix, Sybase, Ingres и др.)
Одновременная групповая разработка БД и приложений

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

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

Согласно обзору передовых технологий, составленному фирмой Systems Development Inc. в 2007 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся «полочным» ПО (shelfware). В связи с этим необходимо отметить следующее:

1. CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

2. Реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

3. CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.

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

1. Широкое разнообразие качества и возможностей CASE-средств;

2. Относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

3. Широкое разнообразие в практике внедрения различных организаций;

4. Отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

5. Широкий диапазон предметных областей проектов;

6. Различная степень интеграции CASE-средств в различных проектах.

Вследствие этих сложностей доступная информация о реальных внедрениях крайне ограничена и противоречива. Она зависит от типа средств, характеристик проектов, уровня сопровождения и опыта пользователей. Некоторые аналитики полагают, что реальная выгода от использования некоторых типов CASE-средств может быть получена только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические улучшения могут привести к снижению эксплуатационных затрат.

В разряд СП попадают как относительно дешевые системы для персональных компьютеров (ПК) с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 30 различных CASE-систем, наиболее мощные из которых, так или иначе, используются практически всеми ведущими западными фирмами .

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

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми СП:

ERWin / BPWin;

Rational Rose;

Oracle Designer.

ARIS - Интегрированное средство моделирования бизнес-процессов, объединяющее разнообразные методы моделирования и анализа систем. В первую очередь, это средство описания, анализа, оптимизации и документирования бизнес-процессов, чем средство проектирования программного обеспечения.

BPWin - инструмент визуального моделирования бизнес-процессов. ERWin - средство, используемое при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность - связь».

Rational Rose - средство моделирования объектно-ориентированных информационных систем. Позволяет решать практически любые задачи в проектировании информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.

Oracle Designer - функциональное средство для описания предметной области. Входит в комплекс инструментальных средств Oracle9i Developer Suite по проектированию программных систем и баз данных, реализующих технологию CASE и собственную методологию разработки ИС компании Oracle - «CDM», позволяющих команде разработчиков провести проект, начиная от анализа бизнес-процессов через моделирование к генерации кода и получению прототипа, а в дальнейшем и окончательного продукта. Это средство имеет смысл использовать при ориентации на всю линейку продуктов Oracle, применяемую для проектирования, разработки и реализации сложной программной системы.

Анализ данных, приведенных в таблице, показывает, что из перечисленных СП только комплекс ARIS наиболее полно удовлетворяет всем критериям, принятым в качестве основных. Так, например, в комплексе Rational Rose целостность базы проектных данных и единая технология сквозного проектирования ИС обеспечивается за счет использования интерфейса Corba. Следует отметить, что каждый из двух продуктов сам по себе является одним из наиболее мощных в своем классе.

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

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

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

• предпроектное обследование;
• технико-экономическое обоснование;

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

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

ш ведение документации и др.
Данные для выбора технических средств включают в себя:

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

В результате обследования должны быть получены и отражены в пояснительной записке следующие материалы, которые затем будут использованы в процессе проектирования:

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

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

• исходные положения, характеристики и технико-экономические данные об объекте;
• обоснование цели создания ИС;
• обоснование комплекса задач, решаемых в ИС, и ДР.

Технический проект содержит материалы, дающие представление о составе и функционировании ИС, и включает в себя: ,

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

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

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

Следует обратить внимание на инструкцию для администратора БД - технического специалиста, который будет поддерживать работоспособность БД. В ней, кроме операций по архивированию, регистрации новых пользователей и т. п., обязательно должны быть описаны действия при различных сбоях в работе БД - от полного выхода из строя компьютера, где находится БД, до проблем, возникающих у пользователя при подключении БД. Кроме того, администратор обязательно должен знать структуру БД, поэтому желательно создавать ее с подробным, включая комментарии, описанием всех таблиц и их полей.
Технический и рабочий проекты включают в себя следующие собственные этапы, которые, как правило, выполняются в указанной ниже последовательности:

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

1. Основные классификации информационных систем

Несмотря на значительное количество различных информационных систем, общая классификация их по назначению достаточно узкая.
В общем можно выделить следующие направления ИС:

• операционные системы,

• ¦ АСУ - автоматизированные системы управления,

• САПР - системы автоматизированного проектирования,
• ГИС - геоинформационные системы,
• Связь и телекоммуникация, "
• Справочно-поисковые системы,
• Системы информационной безопасности,
• Системы подготовки и обработки мультимедийной информации (звука, изображения, видео),
• редакционно-издательские системы.

В отдельных системах могут сочетаться различные комбинации базовых. Например, АСУ магистральных газопроводов будет включать в себя и ГИС, и АСУ ТП (автоматизированную систему управления технологическими процессами), и элементы телекоммуникаций и т.п.

Несмотря на достаточно узкую классификацию по основным направлениям, внутри каждого может быть множество разновидностей.
Одно из разделений - по роду деятельности (машиностроение, торговля, строительство). Например, АСУ могут подразделяться на:

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

Или, САПР делятся на:

• САПР в строительстве,
• САПР в машиностроении,
• САПР в электронной промышленности,
• САПР в авиастроительстве и т.д.

Другое разделение соответствует назначению системы. Так, например, системы САПР могут разделяться на:

• системы подготовки чертежной документации,
• системы расчета на прочность, жесткость и устойчивость,
• системы подготовки проектно-сметной документации,
• системы подготовки документации на конкурс и т.п.

Кроме того, следует рассмотреть деление по возможности пересечения видов деятельности. При этом необходимо рассматривать системы общего и специализированного назначения. Например, такие системы разработки чертежной документации, как AutoCAD и MicroStation являются системами САПР общего назначения. Оперируя общими графическими примитивами (отрезками, дугами, размерными линиями и т.п.), пользователь может подготовить чертежную документацию для любой отрасли промышлен
ности. Наоборот, САПР ArchiCAD, speedikon, ArCON являются специализированными для строительства, и здесь пользователь оперирует не общими, а специализированными примитивами-объектами, как то: стены, окна или проемы, лестницами и т.д. С помощью этих систем можно быстрее и качественнее подготовить проектную документацию по объекту строительства, чем с помощью систем общего назначения. Однако подготовить проектную документацию для строительства корабля или самолета практически невозможно. Аналогично обстоит дело с САПР расчета на прочность. Например, системы ANSYS и NASTRAN - системы общего назначения, с их помощью можно рассчитать хоть здание, хоть самолет. А вот система ProFET amp; Stark ES ориентированна на расчет здания, с ее помощью можно быстрее и более «профильно» рассчитать здание. А вот при расчете самолета эти САПР лучше не использовать.
Заметим, что вокруг оболочки программ САПР общего назначения создаются десятки различных расширений возможностей. Многие компьютерные фирмы разрабатывают подсистемы к программам общего назначения, предоставляющие пользователю больший круг возможностей для использования общей системы в конкретной отрасли промышленности.
Вместе с тем на рынке программных продуктов существует множество различных ИС сходного назначения. Так, для автоматизации бухгалтерского учета сегодня предлагаются системы «1C», «Инфо-бухгалтер», «Парус», «Инотек НТ», «Gendalf», «Овионт информ», «Камин», «Плюс-мик- ро», «СБиС++» и многие другие. Успех той или иной системы на рынке зависит порой не только от качества программного продукта, но и от грамотно организованной маркетинговой и рекламной политики фирмы, от организации разветвленной сети дилеров и технического сопровождения. Аналогичное многообразие программных продуктов наблюдается и в других сферах деятельности человека.

Выделим следующие этапы проектирования ИС:

I. Исследование предметной области.

II. Разработка архитектуры системы.

III. Реализация проекта.

IV. Внедрение системы.V. Сопровождение системы.

I. Исследование предметной области предусматривает следующие

1. Спецификацию деятельности в предметной области.

2. Анализ деятельности в предметной области.

2.1. Структурно-логический анализ деятельности.

2.1.1. Анализ путей.

2.1.2. Анализ связности (прочности и сцепления) компонентов

предметной области.

2.2. Анализ производительности.

2.3. Экономический анализ.

II. Разработка архитектуры системы включает в себя разработку

следующих компонентов:

1. Спецификации требований к проектируемой системе.

2. Конструирование концептуальной модели предметной области.

3. Спецификации обработки данных в проектируемой системе.

4. Спецификации пользовательского интерфейса системы.

5. Спецификации деятельности в предметной области с учетом

внедрения системы.

Процесс проектирования ИС базируется на моделях представления

проектных решений (рис. 1.18).Рис. 1.18. Модели представления проектных решений

Модель классификации ориентирована на группирование объектов

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

и важность тех или иных свойств этих объектов.

Модель декомпозиции ориентирована на описание систем, способных

выполнять действия над данными. Различают виды декомпозиции действий

на основе:

Состава выходных данных;

Входных данных;

Представлений о промежуточных результатах;

Представлений о фазах обработки;

Представлений об альтернативных действиях.

Модели потоков отражают движение различных видов носителей

(материальных, финансовых, информационных и др.).

Модель данных предметной области ориентирована на описание

структуры информационных объектов, их функциональных взаимосвязей,

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

Модель классов определяет систему классификации информации о

предметной области, основанную на семантическом анализе. Среди важных

характеристик модели классов можно выделить отношения наследования,

включения или использования. В основе лежит объектно-ориентированный

подход, основой которого является представление о предметной области как

совокупности взаимодействующих друг с другом объектов, рассматриваемых

как экземпляр определенного класса. Классы образуют иерархию на основе

наследования. Объектно-ориентированный подход содержится в

современных языках высокого уровня Smalltalk, Object Pascal, C++, Java.

Модель пользовательского интерфейса ориентирована на описание

взаимодействий пользователей с проектируемой системой, состава форм

представления и команд управления заданиями.

Модели логики ориентированы на описание потока управления

(последовательности выполнения) операторов программной системы и

действий пользователей.

Для отображения результатов проектирования на различных этапах

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

1. Схемы первичной классификации.

2. Схемы вторичной классификации.

3. Схемы детализации.

4. Схемы спецификации функциональных возможностей.

5. Схемы локальных моделей данных.

6. Схемы потоков.

7. Диаграммы переходов.

8. Схемы спецификации пользовательского интерфейса.9. Схемы распределенной обработки данных.

10. Структурированные карты объектов.

Схема классификации описывает многомерную одноуровневую

классификацию одного элемента. Каждый признак (основание)

классификации имеет глобальный идентификатор и имя:

саt.<ид. признака классификации>–<имя признака классификации>.

Дуги на схеме классификации помечаются соответствующими

элементами типа cat.

По способу формирования будем различать первичные и вторичные

варианты оснований классификации.

Первичные основания характеризуют, как правило, наличие различных

существенных отличительных свойств у каждого подкласса

рассматриваемого класса элементов.

Вторичные основания классификации элемента формируются в

соответствии с основаниями классификации элементов, которые сильно

связаны с данным элементом.

Схемы потоков являются средством более детальной спецификации

функциональных или организационных элементов. В соответствии с типами

потоков будем различать схемы:

Материальных потоков;

Финансовых потоков;

Информационных потоков;

Потоков событий;

Отражающие сразу несколько типов потоков.

Правила конструирования схем потоков следующие:

Вся схема строится для одного исходного функционального или

организационного элемента;

Каждый функциональный и организационный элементы

спецификации должны иметь уникальный идентификатор;

Каждый поток должен иметь тип, уникальный идентификатор и,

возможно, спецификацию;

Каждый поток, кроме потока событий, должен связывать

накопитель соответствующего вида и функциональный элемент, или такие

элементы должны быть специфицированы в организационных элементах,

связанных потоком;

Накопителями информационных потоков в зависимости от их

вида являются базы данных (информационные объекты) или папки

документов:

Накопителями финансовых потоков являются счета

бухгалтерского учета;

Накопителями материальных потоков являются места

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

своем составе накопитель документов и накопитель финансовых средств с

идентификатором этого элемента.

Этапы проектирования автоматизированных информационных систем. К проектированию АИС непосредственное отношение имеют два направления деятельности: 1) собственно проектирование АИС конкретных предприятий (отраслей) на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки; 2) проектирование упомянутых компонентов АИС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных информационных систем.

Сущность первого направления может быть выражена словами “системная интеграция”. Разработчик АИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в сотрудничестве со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся на разработке проектов АИС(например, Price Waterhouse, Jet Info, Consistent Software и др.).

Второе направление в большей мере относится к области разработкиматематического и программного обеспечения для реализации функций АИС - моделей, методов, алгоритмов, программ на базе знания системотехники, методов анализа и синтеза проектных решений, технологий программирования, операционных систем и т. п. В каждом классе АИС (АСУ, САПР, ГИС и т. д.) имеются фирмы, специализирующиеся на разработке программных (а иногда и программно-аппаратных) систем. Каждая из них рекламирует свою технологию создания АИС и придерживается стратегии либо тотального поставщика, либо открытости и расширения системы приложениями и дополнениями третьих фирм.

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

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

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

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

Результаты анализа - техническое предложение и бизнес-план создания АИС -представляются заказчику для окончательного согласования.

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

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

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

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

Особое место в ряду проектных задач занимает разработка проекта корпоративной вычислительной сети, поскольку техническое обеспечение АИС имеет сетевую структуру.

Если АИС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования выделенного канала в большинстве случаев оказывается неприемлемым из-за высокой цены. Естественно, что при этом, прежде всего, рассматривается возможность использования услуг Internet. Именно через Internet могут взаимодействовать предприятия, работающие по технологии CALS (Computer Acquisition Life-Cycle System). Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.

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

I этап - предпроектный (обследование, составление отчета, технико-экономического обоснования и технического задания);

II этап - проектный (составление технического и рабочего проектов);

III этап - внедрение (подготовка к внедрению, проведение опытных испытаний и сдача в программную эксплуатацию);

IV этап - анализ функционирования (выявление проблем, внесение изменений в проектные решения и существующие АИС и АИТ).

Рис.1.

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

К методам изучения и анализа состояния экономического объекта и его системы управления относятся:

устный и письменный опрос;

письменное анкетирование;

наблюдение, измерение, оценка;

групповое обсуждение;

анализ задач;

анализ производственных, управленческих и информационных процессов.

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

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

Проектирование технических процессов включает проектирование паролей, программ, сценариев диалога пользователя с ПВМ, включая проектирование иерархических организованных меню и "окон”. Меню содержит перечень блоков, модулей и программы. Каждый модуль выполняет определенную функцию. Разрабатывается структура меню и сцена диалога человека с машиной. Если привлекаются готовые пакеты прикладных программ, то в них обязательно должно быть руководство пользователю к эксплуатации и комплект машинных программ на дискетах.

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

В процессе постановки задачи раскрываются:

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

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

описание результатной информации (перечень, формы представления, пользователи, структурные единицы информации, способы контроля);

описание алгоритма решения задачи (последовательности выполнения арифметических и логических операций).

В настоящее время почти все АИС децентрализованные, поэтому важно участие пользователя на пред проектной стадии, при постановке и внедрении задач, анализе функционирования АИТ.

Проектирование информационных систем

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

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

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

 информационные связи - подразделения обмениваются информацией (документами, факсами, письменными и устными распоряжениями и т. п.);

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

Общность структуры разных предприятий позволяет сформулировать некоторые единые принципы построения корпоративных информационных систем.

В общем случае процесс разработки информационной системы может быть рассмотрен с двух точек зрения:

 в терминах основных потоков работ: исполнители, действия, последовательность действий и т. п.;

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

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

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

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

Можно выделить следующие основные отличительные признаки проекта как объекта управления:

 изменчивость - целенаправленный перевод системы из существующего в некоторое

желаемое состояние, описываемое в терминах целей проекта;

 ограниченность конечной цели;

 ограниченность продолжительности;

 ограниченность бюджета;

 ограниченность требуемых ресурсов;

 новизна для предприятия, для которого реализуется проект;

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

 правовое и организационное обеспечение - создание специфической организационной структуры на время реализации проекта.

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

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

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

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта принято разделять на фазы (стадии, этапы).

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

Можно выделить следующие фазы развития информационной системы:

 формирование концепции;

 разработка технического задания;

 проектирование;

 изготовление;

 ввод системы в эксплуатацию.

Рассмотрим каждую из них более подробно.

Вторую и частично третью фазы принято называть фазами системного проектирования, а последние две (иногда сюда включают и фазу проектирования) - фазами реализации.

Концептуальная фаза

 формирование идеи, постановку целей;

формирование ключевой команды проекта;

 изучение мотивации и требований заказчика и других участников;

 сбор исходных данных и анализ существующего состояния;

 определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов;

 сравнительную оценку альтернатив;

 представление предложений, их экспертизу и утверждение.

Разработка технического предложения

 разработка основного содержания проекта, базовой структуры проекта;

 разработка и утверждение технического задания;

 планирование, декомпозиция базовой структурной модели проекта;

 составление сметы и бюджета проекта, определение потребности в ресурсах;

 разработка календарных планов и укрупненных графиков работ;

 подписание контракта с заказчиком;

 ввод в действие средств коммуникации участников проекта и контроля за хо дом работ.

Проектирование

На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характерные работы этой фазы:

 выполнение базовых проектных работ;

 разработка частных технических заданий;

 выполнение концептуального проектирования;

 составление технических спецификаций и инструкций;

 представление проектной разработки, экспертиза и утверждение.

Разработка

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

 выполнение работ по разработке программного обеспечения;

 выполнение подготовки к внедрению системы;

 контроль и регулирование основных показателей проекта.

Ввод системы в эксплуатацию

На этой фазе проводятся испытания, опытная эксплуатация системы в реальных условиях,

ведутся переговоры о результатах выполнения проекта и о возможных новых контрактах. Основные виды работ:

 комплексные испытания;

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

Существует международный стандарт, регламентирующий жизненный цикл ин формационных систем - ISO/IEC 12207.

ISO - International Organization of Standardization (международная организация по стандартизации). IEC- International Electrotechnical Commission (международная комиссия по электротехнике).

Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы.

Согласно данному стандарту структура жизненного цикла основывается на трех группах процессов:

 основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

 организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).

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

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

 обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям по автоматизации деловых процессов;

 гарантия создания системы с заданными параметрами в течение заданного времени в рамках оговоренного заранее бюджета;

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

 обеспечение создания корпоративных информационных систем, отвечающих требованиям открытости, переносимости и масштабируемости;

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

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

Технология проектирования может быть представлена как совокупность трех составляющих:

 заданной последовательности выполнения технологических операций проектирования;

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

 графических и текстовых средств (нотаций), используемых для описания проектируемой системы.

Каждая технологическая операция должна обеспечиваться следующими материальными и информационными ресурсами:

 данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;

 методическими материалами, инструкциями, нормативами и стандартами;

 программными и техническими средствами;

 исполнителями.

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

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

 поддерживать полный жизненный цикл информационной системы;

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

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

 технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

 обеспечивать минимальное время получения работоспособной системы;

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

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

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

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

Понятие профиля информационной системы

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

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

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

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

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

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

Обычно рассматривают две группы профилей :

 регламентирующие архитектуру и структуру информационной системы;

 регламентирующие процессы проектирования, разработки, применения, сопровождения и развития системы.

В зависимости от области применения профили могут иметь разные категории и соответственно разные статусы утверждения:

 профили конкретной информационной системы, определяющие стандартизованные проектные решения в пределах данного проекта;

 профили информационной системы, предназначенные для решения некоторого класса прикладных задач.

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

Принципы формирования профиля информационной системы

Использование профилей информационных систем призвано решить следующие задачи:

 снижение трудоемкости проектов;

 повышение качества компонентов информационной системы;

 обеспечение расширяемости и масштабируемости разрабатываемых систем;

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

 обеспечение переносимости прикладного программного обеспечения.

В зависимости от того, какие из указанных задач являются наиболее приоритетными, производится выбор стандартов и документов для формирования профиля.

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

 существует множество международных и национальных стандартов, которые не

полностью и неравномерно удовлетворяют потребности в стандартизации объектов и процессов создания и применения сложных информационных систем;

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

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

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

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

Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на две составляющие: приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют.

Между приложениями и средой определяются стандартизованные интерфейсы - Application Program Interface (API), которые являются необходимой частью про филей любой открытой системы.

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

Таким образом, профили информационной системы с иерархической структурой могут включать в себя:

 стандартизованные описания функций, выполняемых данной системой;

 функции взаимодействия системы с внешней для нее средой;

 стандартизованные интерфейсы между приложениями и средой информационной системы;

 профили отдельных функциональных компонентов, входящих в систему. Для эффективного использования конкретного профиля необходимо:

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

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

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

 формализовать профиль в соответствии с его категорией, включая стандарты, различные варианты нормативных документов и дополнительные параметры, которые непосредственно связаны с профилем;

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

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

Структура профилей информационных систем

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

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