Проектирование Информационных Систем – Шпаргалка

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

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

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

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

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

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

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

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

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

Электронные методологии и технологии (и поддерживающие их CASE-средства) составляют ядро комплекса согласованных инструментальных средств среды разработки ИС.

 

Методология DATARUN опирается на две модели или на два представления:

• модель организации;
• модель ИС.

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

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

 

Инструментальное средство SE Companion [27] является средой, в которой реализован электронный вариант методологии DATARUN. Оно позволяет:

• создать гипертекстовое описание методологии в виде иерархии описания стадий, этапов и операций разработки;
• создать гипертекстовое описание всех методов и методик реализации процессов ЖЦ ПО;
• выделить из гипертекстового описания иерархию процессов ЖЦ ПО для планирования и управления процессом создания ПО (иерархию работ);
• изменять гипертекстовые описания ЖЦ и методов так, как это необходимо разработчику, иными словами, производить авторизацию методологии и отслеживать эти изменения в иерархии работ, предназначенной для управления проектом;
• привязать к процессам ЖЦ инструментальные средства поддержки этих процессов и обеспечить вызов инструментальных средств из соответствующих экранов гипертекстового справочника;
• обеспечить просмотр гипертекстовых экранов описания используемых методов из инструментальных средств;
• обеспечить поддержку процесса управления разработкой, в частности, за счет взаимодействия со средством планирования работ MS Project, оценивания трудоемкости проекта, отслеживания выполнения работ, создания графиков работ, и др.

3.          Требования к информационным системам (ИС). Техническое задание.

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

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

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

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

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

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

Большинство CASE-средств основано на парадигме “методология/метод/нотация/структура/средство”.

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

Метод – систематическая процедура или технология генерации описаний компонент ПО (например, описание потоков и структур данных).

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

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

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

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

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

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

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

Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию.

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

В качестве примеров популярных CASE-средств укажем программные средства компании Computer Associates, IBM-Rational Software и Oracle:

• BPwin – моделирование бизнес-процессов;
• ERwin – моделирование баз данных и хранилищ данных;
• ERwin Examiner – проверка структуры СУБД и моделей, созданных в Erwin;
• ModelMart – среда для командной работы проектировщиков;
• Paradigm Plus – моделирование приложений и генерация объектного кода;
• Rational Rose – моделирование бизнес-процессов и компонентов приложений;
• Rational Suite AnalystStudio – пакет для аналитиков данных;
• Oracle Designer (входит в Oracle9i Developer Suite) – высокофункциональное средство проектирования программных систем и баз данных, реализующее технологию CASE и собственную методологию Oracle – CDM. Позволяет команде разработчиков полностью провести проект, начиная от анализа бизнес-процессов через моделирование к генерации кода и получению прототипа, а в дальнейшем и окончательного продукта. Сложное CASE-средство, его имеет смысл использовать при ориентации на линейку продуктов Oracle.

5.          Управление проектом. Жизненный цикл проекта.
ЖЦ ПО ИС – это непрерывный процесс, начинающийся с момента принятия решения о необходимости создания ИС и заканчивающийся в момент полного ее изъятия из эксплуатации

Основным нормативным документом, регламентирующим ЖЦ ИС, является международный стандарт ISO/IEC 12207.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

1. Основные процессы ЖЦ

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

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

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

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

2.Вспомогательные процессы ЖЦ

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

3.Организационные процессы ЖЦ

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

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

Стадии (этапы) ЖЦ

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

 

1. Реализация (рабочее проектирование, физическое проектирование, программирование). Разработка и настройка программ, наполнение базы данных, создание рабочих инструкций для персонала, оформление рабочего проекта.
2. Внедрение (тестирование, опытная эксплуатация). Комплексная отладка подсистем, обучение персонала, поэтапное внедрение ИС в Эксплуатацию по подразделениям экономического объекта, оформление акта о приемо­сдаточных испытаниях ИС.
3. Эксплуатация ИС (сопровождение, модернизация). Сбор рекламаций и статистики о функционировании ИС, исправление ошибок и недоработок, оформление требований к модернизации ИС и ее выполнение (повторение стадий 2-5).

6.          Классификация CASE-средств по уровням.

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

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

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

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

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

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

аналитик отвечает на эти модификации, изменяя соответствующие спецификации.

Кроме того, средние CASE обеспечивают возможности быстрого документирования требований и быстрого прототипирования.

Нижние (Lower) CASE являются средствами разработки ПО (при этом может использоваться до 30% спецификаций, созданных средствами среднего CASE). Они содержат системные словари и графические средства, исключающие необходимость разработки физических спецификаций. Имеются системные спецификации, которые непосредственно переводятся в программные коды разрабатываемой системы (при этом автоматически генерируется до 80-90% кодов). На эти средства возложены также функции тестирования, управления конфигурацией, формирования документации. Главными преимуществами нижних CASE являются: значительное уменьшение времени на разработку, облегчение модификаций, поддержка возможностей прототипирования (совместно со средними CASE).

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

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

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

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

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

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

В зависимости от характера обработки данных ИС делятся на информационно-поисковые и информационно-решающие

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

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

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

В зависимости от сферы применения различают следующие классы ИС.

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

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

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

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

 

8.          Компоненты интегрированного CASE-пакета.
Интегрированный CASE-пакет содержит четыре основные компоненты:

1) Средства централизованного хранения всей информации о проектируемом ПО в течении всего ЖЦ (репозитарий) zвляются основой CASE-пакета. Соответствущая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации. Репозитарий должен обеспечивать:

–    инкрементный режим при вводе описаний объектов;

–    распространение действия нового или скорректированного описания на информационное пространство всего проекта;

–    синхронизацию поступления информации от различных пользователей;

–    хранение версий проекта и его отдельных компонент;

–    сборку любой запрошенной версии;

–    контроль информации на корректность, полноту и состоятельность.

2) Средства ввода предназначены для ввода данных в репозитарий, а также для организации взаимодействия с CASE-пакетом. Эти средства должны поддерживать различные методологии и использоватьсяна всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т. д.

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

 

4) Средства вывода служат для документирования, управления проектами кодовой генерации.

Все перечисленные компоненты в совокупности должны:

–    поддерживать графические модели;

–    контролировать ошибки;

–    организовывать и поддерживать репозитарий;

–    поддерживать процесс проектирования и разработки.

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

В состав АИС входят:

-информационные ресурсы, представленные в виде БД(БЗ), хранящих данные об объектах, связь между которыми задается определенными правилами

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

-интерфейс

-персонал

-комплекс технических средств

Три метода разработки АИС: оригинальный, типовой, автоматизированный.

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

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

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

10.    CASE-средство BPwin. BPwin – разработка диаграмм IDEF3.
Для  описания  логики  взаимодействия  информационных  потоков  более подходит IDEF3— методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы  могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий  сотрудников  организации.

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

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

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

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

Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно связи стараются направить слева направо. В IDEF3 различают три типа стрелок, изображающих связи:    Старшая (Precedence) – сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется. Отношения (Relational Link) – пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок. Потоки объектов (Object Flow) – стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.

Для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки (Junction). Различают перекрестки для слияния (Fan-in Junction) и разветвления стрелок (Fan-out Junction). Перекресток не может использоваться одновременно для слияния и для разветвления. Смысл каждого типа приведен в таблице 1.7 [4].

Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. В качестве имени объекта можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок — безусловные (unconditional),  синхронные (synchronous)  и  асинхронные (asynchronous).

Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др.

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные – в виде стрелок.

BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD.

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

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

Широта – определение границ модели

Глубина – определение о какого уровня детализировать

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

• Почему этот процесс должен быть смоделирован?
• Что должна показывать модель?
• Что может получить клиент?

Виды стрелок:

Вход (не обязательна)

Управление – обязательно

Выход – обязательно

Механизмы – используемые ресурсы – не обязат

Стрелка вызова (рисуется снизу) указывает на другую модель работы

 

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

Модели жизненного цикла ПО ИС

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

Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 лишь описывает структуры процессов ЖЦ ИС, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

 

Среди известных моделей ЖЦ можно выделить следующие:

 

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

Рис.Каскадная модель ЖЦ ИС

• Итерационная модель (поэтапная модель с промежуточным контролем) (70-е – 80-е гг.). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

Рис. Поэтапная модель с промежуточным контролем

 

• Спиральная модель (80-е – 90-е гг.). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки – анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).

Рис. Спиральная модель ЖЦ ИС

12.      CASE-средство BPwin. BPwin – слияние и расщепление моделей.
Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др.

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные – в виде стрелок.

BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD.

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

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

Широта – определение границ модели

Глубина – определение о какого уровня детализировать

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

• Почему этот процесс должен быть смоделирован?
• Что должна показывать модель?
• Что может получить клиент?

Виды стрелок:

Вход (не обязательна)

Управление – обязательно

Выход – обязательно

Механизмы – используемые ресурсы – не обязат

Стрелка вызова (рисуется снизу) указывает на другую модель работы

 

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

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

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

· Обе сливаемые модели должны быть открыты в Bpwin.

· Имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова работы в модели-цели

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

· Имена контекстной работы подсоединяемой модели-источника и рабо­ты на модели-цели, к которой мы подсоединяем модель-источник, должны совпадать.

Модель-источник должна иметь по крайней мере одну диаграмму де­композиции.

Для слияния моделей нужно щелкнуть правой кнопкой мыши по работе со стрелкой вызова в модели-цели и во всплывающем меню выбрать пункт Merge Model.

 

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

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

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

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

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

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

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

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

технология должна поддерживать полный ЖЦ ПО;

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

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

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

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

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

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

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

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

стандарт проектирования;

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

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

14.      CASE-средство Erwin. Прямое и обратное проектирование в ERwin.
Процесс генерации физической схемы базы данных из логической модели данных называется прямым проектированием (Forward Engineering). Когда генерируют физическую схему, ERwin позволяет включать триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в СУБД.

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

Когда подсоединяются к базе данных, ERwin создает активное соединение в двух направлениях с системным каталогом <DB>  базы данных. Это соединение позволяет производить прямое и обратное проектирование схемы непосредственно в каталог базы данных. Не требуется запускать скрипт языка определения данных, как отдельный процесс. Аналогичным образом возможно синхронизировать изменения, вносимые в модель ERwin, непосредственно с системным каталогом. Когда производят синхронизацию, ERwin запрашивает системный каталог и сообщает о различиях, найденных между базой данных и ERwin.

ERwin Desktop поддерживает прямое и обратное проектирование для шести СУБД, ориентированных на РС – Microsoft Access, FoxPro, Clipper, dBASE III, dBASe IV, Paradox.

Обратное проектирование базы данных

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

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

ERwin позволяет произвести обратное проектирование базы данных:

· Непосредственно из системного каталога базы данных.

· Путем открытия и прочтения файла скрипта схемы SQL.

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

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

– стандарт проектирования;

– стандарт оформления проектной документации;

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

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

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

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

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

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

Стандарт оформления проектной документации должен устанавливать:

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

Стандарт интерфейса пользователя должен устанавливать:

правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

правила использования клавиатуры и мыши;

правила оформления текстов помощи;

перечень стандартных сообщений;

правила обработки реакции пользователя.

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

Основной принцип технологии “клиент-сервер” заключается в разделении функций приложения на три группы:

ввод и отображение данных (взаимодействие с пользователем);

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

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

Поэтому, в любом приложении выделяются следующие компоненты:

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

прикладной компонент

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

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

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

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

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

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

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

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

 

Проиллюстрируем преимущества структурных систем.

• Конструирование системы черных ящиков существенно упрощается.
• Облегчается тестирование таких систем.
• Имеется возможность простого реконфигурирования системы черных ящиков.
• Облегчается доступность для понимания и освоения.
• Увеличивается удобство при модификации

 

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

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

 

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

18.      Фреймы и семантические сети.
Фреймовая  модель,  или  модель  представления  знаний,  основанная   на

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

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

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

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

Формальная структура фрейма имеет вид:

f[, , …, ],

где f – имя фрейма; пара  – i-ый слот, Ni – имя слота и Vi – его значение.

Значение слота может быть представлено последовательностью

  ;…; ; ; …; ,

где Ki – имена атрибутов, характерных для данного слота; Li  –  значение этих атрибутов, характерных для данного слота;  Rj  –  различные  ссылки  на другие слоты.

Каждый  фрейм,  как  структура  хранит  знания  о   предметной   области (фрейм–прототип),  а  при  заполнении   слотов   знаниями   превращается   в  конкретный фрейм события или явления.

Фреймы можно разделить на две группы: фреймы-описания; ролевые фреймы.

Рассмотрим пример.

Фрейм описание: [<программное обеспечение>, <программа  1С  бухгалтерия, версия 7.7>,  <программа  1С  торговля,  версия  7.7>,  <правовая  программа «Консультант +» проф.>].

Ролевой фрейм: [<заявка на продажу>, <что, установка и покупка программы 1С торговля, версия 7.7>,  <откуда,  фирма  ВМИ>,  <куда,  фирма  «Лукойл»>, <кто, курьер Иванова>, <когда, 27 октября 1998г.>].

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

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

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

Для многих предметных  областей  фреймовые  модели  являются  основным способом формализации знаний.

19.      Методология функционального моделирования SADT.
SADT модель дает полное точное и адекватное описание системы, имеющую конкретное назначение – цель модели. Цель модели – получение ответов на некоторую совокупность вопросов, т.е. сама модель  должна дать ответы на эти вопросы с заданной степенью точности. SADT модель всегда ограничивает свой субъект, т.е. модель устанавливает, что является, а что не является субъектом моделирования. Она требует, чтобы система рассматривалась с одной и с той же позиции.

Рисунок 1 Представление системы по методологии IDEF0

 

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

 

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

2.1 Базы данных и их сравнительные характеристики.

2.1.1 Классификация моделей построения баз данных

В зависимости от архитектуры СУБД делятся на локальные и распределенные СУБД. Все части локальной СУБД размещаются на одном компьютере, а распределенной на нескольких. За несколько десятилетий последовательно появлялись системы (СУБД), основанные на трех базовых моделях данных: иерархической, сетевой и реляционной. Основные определения теории баз знаний и баз данных представлены в таблице 1.

Табл.1. Основные определения

№	Термин	Определение
1	База данных (БД)	Базами данных называют электронные хранилища информации, доступ к которым осуществляется с помощью одного или нескольких компьютеров.
2	Системы управления базами данных (СУБД)	это программные средства для создания, наполнения, обновления и удаления баз данных.
3	База знаний	Базы знаний это хранилища знаний, представленных в формализованном виде.
4	Система управления базами знаний СУБЗ	это программные средства для создания, наполнения, обновления и удаления баз знаний

	Дополнения к таблице 1.
Виды знаний:ПроцедурныеДекларативные Каузальные Неточные	Знания, отвечающие на вопрос “Как решать поставленную задачу?”Знания, не содержащие в явном виде процедуры решения задач. Знания о причинно-следственных связях между объектами предметной области Знания отличающиеся неполнотой или противоречивостью.
Парадигмы решения задач В СУБД В СУБЗ	Данные + Алгоритм = Программа решения задачиЗнания + Стратегия вывода = Решение проблемы.
Модели знаний Продукционная Фреймовая Семантическая сеть	Знания представленные в формате “ЕСЛИ-ТО”Знания представленные в виде набора взаимосвязанный фреймов. Граф, вершины которого соответствуют объектам или понятиям, а дуги определяют отношения между вершинами.
Фрейм Фрейм прототип Конкретный фрейм	Структурированное описание объекта предметной области состоящее из наименования объекта (имя фрейма), атрибутов объекта (свойств, характеристик) – слоты фрейма.Это фрейм у которого значения слотов не определены.Это фрейм прототип с конкретными значениями.
Enterprise JavaBeans.	Стандарт для создания средствами языка Java пригодных для многократного использования компонентов, из которых формируются прикладные программы. Компоненты Enterprise JavaBeans облегчают разработку программ, обеспечивающих доступ к хранимой в базе данных информации.
Распараллеливание обработки запроса (Intraquery parallelism).	Использование нескольких ЦП для обработки одного запроса.
Параллельная обработка запросов (interquery parallelism)	подразумевает параллельную обработку нескольких запросов (на разных ЦП).
Уровень изоляции (Isolation level).	Установочный параметр БД, определяющий, в какой степени одновременно обратившиеся к базе данных пользователи могут оказывать влияние на работу друг друга. Как правило, используются три уровня изоляции: завершение чтения (read committed), характеризуется большим количеством одновременно обслуживаемых пользователей и низким уровнем изоляции каждого из них); в установленном порядке (serializable), небольшое число одновременно обслуживаемых пользователей, высокая степень изоляции и повторяющееся чтение (repeatable read), сочетание двух первых уровней.
Технология СОМ	COM – Component Object Model – Компонентная модель объектов, предложена корпорацией Микрософт.
Технология CORBA	CORBA – Common Object Require Broker Architecture – архитектура с брокером требуемых общих объектов, разработана независимой группой OMG.
JDBC (Java Database Connectivity).	Интерфейс взаимодействия с базами данных на языке Java. Этот стандарт, разработанный фирмой Sun Microsystems, определяет способы доступа Java-приложений к данным БД.
ODBC (Open Database Connectivity).	Открытый интерфейс взаимодействия с базами данных. Предложенный корпорацией Microsoft стандарт, регулирующий доступ Windows -приложений к базам данных. Стандарт ODBC постепенно заменяется спецификацией OLE DB.
OLAP (Online analytical processing).	Оперативный анализ данных. Этот метод обработки применяется с целью ускорения обработки запросов и предусматривает предварительный расчет часто запрашиваемых данных (например, сумм или значений счетчика).
OLE DB (Object Linking and Embedding Database).	OLE для баз данных. Новый стандарт Microsoft, регулирующий доступ приложений к базам данных. Имеет расширения для серверов OLAP и предусматривает применение специальных средств обработки мультимедийных данных.

	Дополнения к табл.2
Операция соединения (Join).	Процесс, позволяющий объединять данные из двух таблиц посредством сопоставления содержимого двух аналогичных столбцов.
SQL (Structured query language).	Язык структурированных запросов, язык S0L. Является принятым в отрасли стандартом для выполнения операций вставки, обновления, удаления и выборки данных из реляционных БД.
Хранимая процедура (Stored procedure).	Программа, которая выполняется внутри базы данных и может предпринимать сложные действия на основе информации, задаваемой пользователем. Поскольку хранимые процедуры выполняются непосредственно на сервере базы данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД.
Транзакция (Transaction).	Совокупность операций базы данных, выполнение которых не может быть прервано. Для того чтобы изменения, внесенные в БД в ходе выполнения любой из входящих в транзакцию операций, были зафиксированы в базе данных, все операции должны завершиться успешно. Все базы данных, представленные в нашем обзоре, позволяют использовать транзакции, тогда как БД для настольных систем, например Visual dBase фирмы Inprise или Microsoft Access, не предусматривают применения механизма транзакций.
Триггер (Trigger).	Программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты

 

 

21.      Методология информационного моделирования ERD.
Наиболее распространенным средством моделирования данных являются диаграммы “сущность-связь” (ERD), нотация которых была впервые введена Питером Ченом в 1976 г.

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

Диаграммы “сущность-связь” включают:

•  сущности; •  атрибуты; •  связи.

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

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

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

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

Разработка ERD включает следующие основные этапы:

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

•  Идентификация отношений между сущностями и указание типов отношений.

•  Разрешение неспецифических отношений (отношений многие-ко-многим).

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

Альтернативный ключ (Alternate Key) – потенциальный ключ, не ставший первичным. На диаграмме альтернативный ключ обозначается AK n . m , где n – порядковый номер ключа, m – порядковый номер атрибута в ключе.

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

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

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

 

 

 

 

22.      Сравнительные характеристики баз данных.

Сравнительная характеристика моделей БД

23.      Методология потоков данных DFD.
Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе.

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

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

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

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

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

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

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

1. процесс имеет два-три входных и выходных потока;
2. процесс может быть описан в виде преобразования входных данных в выходные;
3. процесс может быть описан в виде последовательного алгоритма.

 

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

Миниспецификации обработки — описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификации является полной спецификацией системы.

К преимуществам методики DFD относятся:

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

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

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

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

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

база данных – является моделью некоторой предметной области, состоящей из связанных между собой данных об объектах, их свойствах и характеристиках.

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

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

Основные понятия реляционных БД: нормализация, связи и ключи
1. Принципы нормализации:

  В каждой таблице БД не должно быть повторяющихся полей;

  В каждой таблице должен быть уникальный идентификатор (первичный ключ);

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

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

2. Виды логической связи.

Связь устанавливается между двумя общими полями (столбцами) двух таблиц. Существуют связи с отношением «один-к-одному», «один-ко-многим» и «многие-ко-многим».

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

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

Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов:

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

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

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

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

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

Преимущества:

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

•    Объектная модель естественна, поскольку ориентированна на человеческое восприятие мира.

Недостаток – высокие начальные затраты. Этот подход не дает немедленной отдачи.

25.      Состав функциональной модели. Типы связей между функциями.
Функциональная  модель  в  стандарте IDEF0  должна  представлять  собой  набор функциональных  блоков,  связанных  дугами.  Дуги  могут  быть  четырех  типов – «вход», «выход», «управление» и «механизм». Каждый функциональный должен блок содержать имя,  которое  является  не  чем  иным  как  формулировкой  функции.  Соответственно, построение  функциональной  модели  состоит  из  прорисовки  функциональных  блоков, установке связей между ними посредством дуг и формулировании функций.

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

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

Следует разделять процессы предприятия и организационную структуру предприятия. Они не всегда соответствуют друг другу. Функциональную модель процессов не следует строить, принимая за основу  организационную структуру предприятия.

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

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

Язык UML предназначен для решения следующих задач:

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

2. Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области.

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

4. Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП.

5. Способствовать распространению объектных технологий и соответствующих понятий ООАП.

6. Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

Общая структура языка UML

С самой общей точки зрения описание языка UML состоит из двух взаимодействующих частей, таких как:

Семантика языка UML. Представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.

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

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

Мета-метамодель

Метамодель

Модель

Объекты пользователя

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

Сущности в UML

В UML определены четыре типа сущностей: структурные, поведенческие, группирующие и аннотационные.

Сущности являются основными объектно-ориентированными элементами языка, с помощью которых создаются модели.

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

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

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

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре – это пакет.

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

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

 

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

Основные преимущества IDEF1

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

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

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

Концепции моделирования IDEF1

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

Терминология и семантика IDEF1

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

1) Устойчивость. Информация, имеющая отношение к той или иной сущности постоянно накапливается.

2) Уникальность. Любая сущность может быть однозначно идентифицирована из другой сущности.

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

 

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

Зависимость (dependency) – это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.

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

Обобщение (generalization) – это отношение, при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (предка). При этом, в соответствии с принципами объектно-ориентированного программирования, потомок (child) наследует структуру и поведение своего предка (parent).

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

• между интерфейсами и реализующими их классами или компонентами;
• между прецедентами и реализующими их кооперациями.

29. Программные средства поддержки жизненного цикла ПО.

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

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

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

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

Разработка ИС работы по созданию информационного ПО и его компонентов

Эксплуатация включает в себя работы по внедрению компонентов ИС в эксплуатацию.

Сопровождение включает в себя техническую поддержку ИС.

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

Организационные процессы ЖЦ

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

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

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

Стадии (этапы) ЖЦ

Суть ЖЦ разработки ИС в различных подходах одинакова и сводится к выполнению следующих стадий:

1. Планирование и анализ требований (предпроектная стадия) -системный анализ. Исследование и анализ существующей ИС, определение требований к создаваемой ИС, оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ) на разработку ИС.
2. Проектирование (техническое проектирование, логическое проектирование). Разработка в соответствии со сформулированными требованиями состава автоматизируемых функций (функциональная архитектура) и состава обеспечивающих подсистем (системная архитектура), оформление технического проекта ИС.
3. Реализация (рабочее проектирование, физическое проектирование, программирование). Разработка и настройка программ, наполнение базы данных, создание рабочих инструкций для персонала, и.др
4. Внедрение (тестирование, опытная эксплуатация). Комплексная отладка подсистем, обучение персонала, поэтапное внедрение ИС в Эксплуатацию по подразделениям экономического объекта, оформление акта о приемо­сдаточных испытаниях ИС.
5. Эксплуатация ИС (сопровождение, модернизация). исправление ошибок и недоработок.

Модели жизненного цикла ПО ИС

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

Рис.Каскадная модель ЖЦ ИС

• Итерационная модель (поэтапная модель с промежуточным контролем)