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

Определение стратегии тестирования

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

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

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

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

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

Если проект небольшой, то в качестве аналитиков, проектировщиков и разработчиков могут выступать одни и те же люди. Возникает вопрос: насколько вообще актуальна передача результатов самому себе? Думаем, что актуальна. Представьте себе, что вы передаете данные кому-либо, кто мало знает о системе. Зачастую это помогает, например, найти не описанные вообще, нечетко описанные, противоречиво описанные компоненты системы.

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

Журнал проектирования

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

Такой журнал может вестись как на этапе анализа, так и на этапе разработки и тестирования.

Планирование этапа проектирования

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

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

Ранние стадии

Рассмотрение результатов анализа

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

Критические участки

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

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

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

Такие моменты могут инициировать не только изменение информационной модели, но и смену СУБД.

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

Оценка ограничений

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

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

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

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

Определение целевой архитектуры

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

Кроме определения платформы следует выяснить следующее:

Будет ли это архитектура «файл-сервер» или «клиент-сервер».
Будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО.
Будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться.
Будет ли база данных однородной, то есть будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных небудет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта).
Будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

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

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

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

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

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

В приведенном примере явно видны 3 пика активности системы, максимальный из которых приходится на 11 часов. Использован тип диаграммы с накоплением.

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

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

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

Продукты третьих фирм

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

Использование CASE-средств

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

Инфраструктура

Для проектирования и реализации необходимы аппаратные ресурсы и специальное программное обеспечение. Кроме того, требуется механизм, позволяющий контролировать создаваемую документацию и код. Эти вопросы лучше решать на ранних стадиях проектирования, а не на стадии разработки. Мы поговорим об этом ниже, в разделе «Проектирование процессов и кода». При групповой разработке вам понадобятся средства контроля согласованности кода. Если разработка идет под разными платформами (аппаратная платформа и ОС), то хорошим решением может оказаться PVCS. Для платформ Windows 98, NT, 2000 может оказаться приемлемым решение, предлагаемое Microsoft - MS Source Save. Кроме того, многие средства разработки также предоставляют возможности контроля исходного кода.

Построение модели данных

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

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

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

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

Проектирование процессов и кода

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

Отображение функций на модули

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

Интерфейсы программ

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

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

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

Интегрирование и наследование механизмов обмена данными

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

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

Определение спецификаций модулей

Это основная часть функционального проектирования. Здесь решаются следующие задачи:

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

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

КомпьютерПресс 11"2001

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

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

Основные понятия технологии проектирования

Лекция № 1

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

Лекции по предмету информационных систем (ИС)

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

· хранение

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

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

Информационная система состоит:

o источника информации,

o аппаратной части ИС,

o программной части ИС,

o потребителя информации.

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

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

управляющие
советующие

Ситуационные центры (информационно-аналитические комплексы)

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

1. Традиционные архитектурные решения основаны на использовании выделенных файл-серверов (File-server) или серверов баз данных (Client-server).

2. Корпоративные информационные системы , базируются на технологии Internet (Intranet-приложения).

3. "Хранилища данных" (DataWarehouse) - интегрированные информационные среды, включающие разнородные информационные ресурсы.

4. Архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода, которые используются для построения глобальных распределенных информационных приложений (Service Oriented architecture SOA).

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

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

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

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

Согласно статистическим данным , собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

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

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

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

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

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

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

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

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

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

На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная модель (характерна для периода 1970-1985 гг.);
спиральная модель (характерна для периода после 1986.г.).

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

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

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

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

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

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

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

Методология проектирования ИС охватывает три основные области :

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

Проектирование информационных систем всегда начинается с определения цели проекта.

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

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

Согласно современной методологии проектирования процесс создания ИС делится на следующие этапы (стадии) :

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

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

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

· схема базы данных (на основании ER-модели, разработанной на этапе анализа);

· набор спецификаций модулей системы (они строятся на базе моделей функций).

· технический проект ИС (техническое задание), эскизный проект, рабочая документация.

3. Реализация: На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основная

Г.Н. Смирнова, А.А.Сорокин, Ю.Ф. Тельнов Проектирование экономических информационных систем. Учебник. М., «Финансы и статистика»,2002

Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М., «Финансы и статистика»,2000

Маклаков С.В. Создание ИС с AllFusion Modelling Suite. М., «Диалог-МИФИ», 2003

Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование ИС. Учебное пособие. Интернет-университет, М., 2005

Дополнительная

Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. М.,СИНТЕГ, 2000

Калянов Г.Н. Структурный системный анализ.

М., Лори, 1996

Марка Д.А., МакГоуэн К. SADT – методология структурного анализа и проектирования., М., Метатехнология, 1993

Г. Буч Д. Рамбо А. Джекобсон Язык UML. Руководство пользователя, 1999

М. Фаулер К. Скотт Основы UML

Т. Кватрани Rational Rose 2000 и UML. Визуальное моделирование. Москва, 2001

Дополнительная

Колтунова Е. Требования к информационной системе и модели жизненного цикла. Carabi Solutions , www.carabisolutions.sp.ru

Автоматизированные Системы Стадии создания. ГОСТ 34.601-90 Комплекс стандартов на автоматизированные системы. ИПК издательство стандартов, М., 1997

ISO/IEC 12207:1995

Thiele D. Life cycle management using life cycle process standards. Abstract. http://www.fostas.ru/library/show_article.php? id=22

Проектирование и разработка корпоративных информационных систем. http://zeus.sai.msu.ru:7000/cfin/prcorpsys/index.sht ml.

Основные понятия

методологии проектирования ИС

1. Цели и содержание методологии проектирования ИС

2. Жизненный цикл ИС

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

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

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

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

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

Подсистемы ИС

Информационное обеспечение совокупность

единой системы

унифицированных

массивов (обычно –

Техническое

средств, предназначенных

системы и ее пользователей,

Программное

специальные программные

Организационное ро

мероприятий и

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

Математическое

математических методов,

управления системой и

Лингвистическоепр

использующихся при

программирования, я

Правовое о

определяющих со

информационных

преобразования и исполь

Этапы развития технологий проектирования ИС

1. Метод "снизу-вверх" - не создание тиражируемых продуктов, а обслуживание сотрудников конкретного учреждения. Успешно автоматизируются отдельные, важные с точки зрения руководства рабочие места. Общая же картина "автоматизированного предприятия" просматривается недостаточно хорошо, особенно в перспективе.

(«Лоскутная автоматизация»)

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

Этапы развития технологий проектирования

(продолжение)

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

Каноническое проектирование ИС

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

Стадия 1. Формирование требований к ИС .

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

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

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

Стадия 4. Эскизный проект : разработка предварительных проектных решений по системе и ее частям; разработка эскизной документации на ИС и ее части.

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

Стадия 6. Рабочая документация : разработка рабочей документации на ИС и ее части; разработка и адаптация программ.

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

Стадия 8. Сопровождение ИС : выполнение работ в соответствии с гарантийными обязательствами; послегарантийное обслуживание.

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

модель «как есть»(«as-is»)- отражает существующие в организации бизнес-процессы;
модель «как должно быть»(«to-be») — отражает необходимые изменения бизнес-процессов с учетом внедрения ИС.

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

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

Стадии: 1) Пояснительная записка 2) Функциональная и организационная структура системы 3) Постановка задач и алгоритмы решения 4) Организация информационной базы 5) Альбом форм документов 6) Система математического обеспечения 7) Принцип построения комплекса технических средств 8) Расчет экономической эффективности системы 9) Мероприятия по подготовке объекта к внедрению системы

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

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