Этапы проектирования аис:

1. Разработка и анализ бизнес – модели

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

Метод решения: Функциональное моделирование.

Результат:

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

2. Аппаратно-технический состав создаваемой АИС.

2. Формализация бизнес - модели, разработка логической модели бизнес - процессов.

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

Метод решения: Разработка диаграммы "сущность-связь" (ER (Entity-Reationship) - CASE - диаграммы).

Результат: Разработанное информационное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.

3. Выбор лингвистического обеспечения, разработка программного обеспечения АИС.

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

Метод решения: Разработка программного кода с использованием выбранного инструментария.

Результат: Работоспособная АИС.

4. Тестирование и отладка АИС

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

Результат: Оптимальный состав и эффективное функционирование АИС.

Комплект документации: разработчика, администратора, пользователя.

5. Эксплуатация и контроль версий

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

Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС [2].

1.4 Понятие индивидуальных и типовых проектов.

В практике проектирования выделяют:

1. Индивидуальное проектирование;

2. Типовое проектирование.

При индивидуальном проектировании разработка проекта выполняется для конкретного объекта. Как правило, такое предприятие характеризуется только ему присущими особенностями. В настоящее время всё большее применение получает типовое проектирование.

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

Ключевые особенности технологии типового проектирования

• Причины применения:

• Существенно снижаются затраты на проектирование, разработку и даже на модернизацию ИС;

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

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

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

  • Схожая структура и правила управления;

  • Единые стандарты отчетности;

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

  • Единая цель существования: извлечение прибыли.

• Содержание: Процесс проектирования ИС состоит из следующих основных этапов:

  • Разбиение проекта информационной системы на отдельные составляющие (компоненты).

  • Выбор и приобретения имеющихся на рынке типовых проектных решений (тиражируемых продуктов) для каждого компонента ИС.

  • Настройка и доработка приобретенных типовых проектных решений в соответствии с требованиями конкретной предметной области.

• Условия применения:

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

Понятие, виды и особенности типовых проектных решений

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

Основные черты ТПР:

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

• Основная цель применения ТПР – уменьшение трудоемкости и стоимости проектирования и/или разработки ИС.

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

• Типовые решения бывают простыми или комбинированными. Простые ТПР охватывают только какой-либо один вид обеспечения ИС, комбинированные – два и более. Примеры простых ТПР: Классификаторы (ИО), прикладные программы общего и специального назначения (ПО), инструктирующие руководства по управлению бизнес-процессами (ОО), рекомендации по составлению ТЗ (МО) и т.п.

Требования, выдвигаемые к типовым проектным решениям:

• Возможность использования для создания новой ИС при минимальном участии разработчиков ТПР;

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

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

• Возможность адаптации к конкретным условиям проекта путем изменения параметров.

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

• Элементное проектирование

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

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

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

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

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

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

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

• Функциональная полнота;

• Минимизация внешних информационных связей;

• Параметрическая настраиваемость;

• Полная интеграция внутри ППП и более высокий (хотя и не полный) уровень интеграции с другими пакетами и отдельными программными продуктами.

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

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

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

Блок функционирования – обрабатывает исходные данные.

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

• Принцип интерпретации (поглощается самим ППП);

• Принцип генерации (на его основе специальная программа-генератор генерирует ППП, настроенный под конкретные условия).

Блок обработки параметров – интерпретирует значения параметров и переносит их непосредственно в прикладные программы.

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

Пример ППП: «1С: Предприятие».

Недостаток: недостаточный уровень совместимости различных ППП в рамках единой корпоративной ИС.

• Объектный метод

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

• Ориентированы для применения на объектах с высоким уровнем стабильности;

• Открытость архитектуры (возможность использования на различных программно-технических платформах);

• Высокий уровень масштабируемости;

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

Объектный метод по определению обеспечивает полную программную совместимость компонентов системы [4].

1.5 Состав технического задания

Техническое задание (ТЗ) используется при разработке технического проекта.

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

Структура ТЗ: общие положения, назначение и цели создания и.с., характеристика объекта автоматизации, требования к системе, состав и содержание работ по созданию системы, порядок контроля и принятия и.с., требование к составу и содержанию работ по подготовке объекта к вводу системы в действие, требования к документированию, источники разработки [1].

1.6 Состав технического проекта

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

1.Технический проект и его этапы:

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

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

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