1.Основы создания и функционирования информационной системы

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

Компоненты системы:

• Структура системы – множество элементов системы и и взаимосвязи между ними.

• Функция каждого элемента.

• Цели и ограничения системы и ее компонентов.

• Вход и выход каждого элемента системы.

Свойства системы:

• Делимость – представляет систему в виде самостоятельных частей, каждая из которых может рассматриваться как система.

• Целостность – указывает на согласование целей функционирования всей системы с целями функций ее подсистем и элементов.

Компоненты ИС:

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

• Обеспечивающая часть ИС – состоит из информационной, программной, математической, технической, правовой, лингвистической, эргономической и метрологической частей.

Потребительские свойства ИС:

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

 Временная обеспеченность – возможность получения нужной информации в требуемое время.

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

 Эффективность – система должна приносить пользу.

 Адаптивность – она должна приспосабливаться к частично изменившимся условиям объекта и обеспечивать устойчивое функционирование на большом интервале времени.

 Иерархичность – возможность быть составной частью системы более высокого уровня.

Характерные особенности современных крупных проектов ИС:

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

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

 Отсутствие полных аналогов.

 Необходимость интеграции существующих и вновь разрабатываемых приложений.

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

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

 Значительная временная протяженность проекта.

Проблемы, с которыми сталкивается системный аналитик:

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

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

 Чрезмерное кол-во подробных сведений о предметной области и о новой системе у аналитика.

• Непонимание спецификации системы из-за объема технических терминов заказчиком.

Основополагающие принципы создания ИС:

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

 Принцип развития – ИС создается с учетом возможности постоянного пополнения и обновления системы и видов ее обеспечений.

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

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

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

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

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

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

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

 Принцип формализации.

 Принцип концептуальной общности.

 Принцип непротиворечивости и полноты.

 Принцип независимости данных.

 Принцип структурирования данных.

 Принцип доступа конечного пользователя

2. Общая схема проектирования информационных систем и технологий.

Основные принципы создания ИС:  Управленческие.  Технические – комплексное использование вычислительной техники и программных средств, создание единой информационной базы системы, организация непосредственного общения пользователя с системой.  Организационные принцип – координация деятельности всех специалистов- разработчиков, достигаемая путем назначения специалиста по информационному обеспечению (ИО). Подходы к проектированию ИО:  Дедуктивный.  Индуктивный. Общая схема проектирования ИО: 1. Анализ, определение всех типов решений, для принятия которых необходима информация. 2. Анализ и определение типа информации, которая требуется для принятия каждого решения. 3. Агрегирование решений. Решения по которым требуется одна и та же информация, необходимо сгруппировать в одну задачу управления. 4. Проектирование процесса обработки информации. Разработка реальной системы для сбора, передачи, хранения и модификации информации. 5. Создание и воплощение системы, цель которой оценивать выдаваемую информацию и распознавать ошибки.1.2.1 Структура процесса проектирования ИС: Подходы к проектированию и сопровождению ИС:  Структурный подход требует синтезировать варианты системы из компонентов и оценивать варианты при их частичном переборе с предварительным прогнозированием характеристик компонентов.  Блочно-иерархический подход использует идеи декомпозиции сложных описаний объектов и соответственно средств их создания на иерархические уровни и аспекты, вводит понятия стиля проектирования (восходящий и нисходящий), устанавливает связь между параметрами соседних иерархических уровней. Составные части процесса создания ИС:  Иерархическая структура системы; организация их проектирования  Анализ и моделирование систем – задачи моделирования: создание моделей сложных систем, анализ свойств систем на основе анализа их моделей.  Синтез и оптимизация систем – задачи синтеза: синтез структуры проектируемых систем, выбор численных значений параметров элементов системы. Аспекты представлений о проектируемых объектах: • Аспект описания (страта) – описание системы или ее частей с некоторой оговоренной точки зрения, определяемой функциональными, физическими или иного типа отношениями между свойствами и элементами.  Функциональное описание относят к функциям системы и чаще всего представляют его функциональными схемами.  Информационное описание – основные понятия предметной области, словесное пояснение или числовые значения характеристик объектов, описание связей между этими понятиями и характеристиками.  Структурное описание характеризует составные части системы и их межсоединяния.  Процессное описание характеризует процессы функционирования (алгоритмы) и (или) технологические процессы создания системы. Так же выделяют такие аспекты проектирования систем:  Функциональный - разработка принципов действия структурных, функциональных, принципиальных схем.  Конструкторский - определение форм и пространственного расположения изделий.  Алгоритмический – разработка алгоритмов и программного обеспечения.  Технологический – разработка технологических процессов. Стадии проектирования ИС. В соответствии с ГОСТ 34.201 можно выделить следующие стадии проектирования автоматизированной информационной системы (АИС):  Предпроектная стадия включает в себя предпроектное обследование и разработку технического задания на АИС. Описание целей и задач ИС, выработка общих требований к ее созданию, разработка программ проведения обследования.  Этап проектирования связан с разработкой технического и рабочего проектов. Для решения задач ИО анализируются потоки информации, системы классификации и кодирования, формы документации, а так же исследуются СУБД. Создание необходимого программного обеспечения, подготовка на машинных носителях нормативно справочной и производственной информации для первичной загрузки базы, выпуск рабочей документации.  Этап внедрения системы включает реализацию основных мероприятий по внедрению, подбор и обучение персонала, подготовку помещений и технических средств. Стадии проектирования ИО:  Стадия концептуального проектирования, построение информационной модели предприятия, которая отражает реальные процессы формирования информационных массивов, передачи, преобразования данных, прохождение информационных потоков.  Организационная стадия, разработка план-схемы всех операций с указанием стоимости каждого этапа, сроков выполнения, ответственных лиц и результатов. Методы изучения информационных потребностей и запросов: 1. Анализ управленческой документации и документооборота применительно к каждому уровню управления и рабочему месту специалиста. Нормативно-справочные виды документов, должностные инструкции, положения о деятельности подразделений дают возможность выяснить и оценить уровень ИО. 2. Проведение социологического исследования среди потенциальных пользователей системы ИО. 3. Анализ существующих информационных связей. Построение дерева целей. Формулировка генеральной цели и ее дальнейшая декомпозиция до тех пор, пока не будут выявлены решаемые будущими пользователями задачи. Для создания БД необходимо:  Определить объем и характер информации.  Классифицировать ее массив.  Определить структуру БД.  Выбрать вид носителей информации, систему поисковых признаков.  Разработать типовые процедуры формирования основных документов и показателей.  Порядок корректировки и пополнения БД. Для постановки и решения многих задач в управлении используется информация, представленная в нескольких массивах. Анализ информационных массивов осуществляется в два этапа: обследование; построение и анализ информационной модели организации. При анализе информационных потоков нужно учитывать движение информации в следующих направлениях: по вертикали и горизонтальное направление. В целях более полного анализа документацию можно поделить на нормативно- справочную и оперативную. Методы моделирования информационных связей:  Матричное моделирование – таблица, отражающая взаимосвязи анализируемых данных, документов подразделений организации, формирующих и получающих информацию.  Метод формального описания информационных потоков – граф, вершинам которого соответствуют источники информации и ее потребители, а дугам – информационные потоки. Документирование процесса проектирования ИС. Типы документации, формируемые в процессе создания ИС: 1. Предпроектная документация включает технико- экономическое обоснование и техническое задание. 2. Проектно-сметная документация содержит краткое описание проекта; описание комплекса технических средств; план мероприятий по подготовке объекта к внедрению; описание структуры системы.

3. Понятие консалтинга в области информационных систем и технологий.

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

1. Бизнес-консалтинг. Бизнес-анализ и реструктуризация (реинжиниринг бизнес процессов).

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

Основные этапы разработки консалтинговых проектов:

1. Анализ первичных требований и планирование работ.

2. Проведение обследования деятельности предприятия.

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

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

5. Разработка предложения по автоматизации.

6. Разработка технического проекта. На основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы.

7. Разработка новой системы или настройка существующей. Программирование модулей, их тестирование и отладка.

4.Свойства информационных систем. Принципы построения информационных систем.

Свойства системы:

• Делимость – представляет систему в виде самостоятельных частей, каждая из которых может рассматриваться как система.

• Целостность – указывает на согласование целей функционирования всей системы с целями функций ее подсистем и элементов.

Компоненты ИС:

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

• Обеспечивающая часть ИС – состоит из информационной, программной, математической, технической, правовой, лингвистической, эргономической и метрологической частей.

Потребительские свойства ИС:

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

 Временная обеспеченность – возможность получения нужной информации в требуемое время.

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

 Эффективность – система должна приносить пользу.

 Адаптивность – она должна приспосабливаться к частично изменившимся условиям объекта и обеспечивать устойчивое функционирование на большом интервале времени.

 Иерархичность – возможность быть составной частью системы более высокого уровня.

Характерные особенности современных крупных проектов ИС:

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

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

 Отсутствие полных аналогов.

 Необходимость интеграции существующих и вновь разрабатываемых приложений.

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

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

 Значительная временная протяженность проекта.

Проблемы, с которыми сталкивается системный аналитик:

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

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

 Чрезмерное кол-во подробных сведений о предметной области и о новой системе у аналитика.

• Непонимание спецификации системы из-за объема технических терминов заказчиком.

Основополагающие принципы создания ИС:

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

 Принцип развития – ИС создается с учетом возможности постоянного пополнения и обновления системы и видов ее обеспечений.

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

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

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

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

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

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

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

 Принцип формализации.

 Принцип концептуальной общности.

 Принцип непротиворечивости и полноты.

 Принцип независимости данных.

 Принцип структурирования данных.

 Принцип доступа конечного пользователя

5.Содержание и организация процесса проектирования информационных систем и технологий. Основные задачи проектирования ИС.

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

 Документ, полученный в результате проектирования, носит название проект.

 Целью проектирования является подбор технического и формирование информационного, математического, про­граммного и организационно-правового обеспечения.

Основными задачами проектирования являются:

 Оказание влияния на улучшение организации учетной, плановой и аналитической работы;

 Выбор оборудования и разработка рациональной технологии решения задач и получения результатной информации;

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

 Создание БД, обеспечивающей оптимальное использование информации, касающейся планирования, учета и анализа хозяйственной деятельности;

 Создание нормативно-справочной информации.

6.Понятие жизненного цикла программ­ного обеспечения ИС. Структура жизненного цикла программ­ного обеспечения по стандарту ISO/IEC 12207.

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

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

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

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

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

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

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

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

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

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

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

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

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

• основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

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

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

7. Модели жизненного цикла программного обеспечения.

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

 каскадная модель

 спиральная модель

 итерационная модель

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

Достоинства каскадной модели:

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

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

Недостатки каскадной модели:

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

 возврат на предыдущую стадию(ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на следующих стадиях работы над проектом)

 сложность параллельного ведения работ.

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

 сложность управления проектом Каскадная схема разработки ПО

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

Спиральная модель ЖЦДостоинства спиральной модели:

 итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика

 отдельные элементы информационной системы интегрируются в единое целое постепенно(интеграция происходит непрерывно)

 уменьшение уровня рисков

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

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

Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов: Rational Unified Process (RUP), Microsoft Solutions Framework (MSF) и Extreme Programming (XP). RUP предлагает итеративную модель разработки, вклю­чающую четыре фазы: начало, исследование, построение и внедрение. Прохождение через четыре основные фазы называется циклом разработки. Используется объектно-ориентированный анализ, объектно-ориентированное программирование. MSF сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно- ориентированного моделирования.

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

8.Каноническое проектирование.

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

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

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

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

На начальной стадии проектирования выделяют следующие этапы работ:

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

Стадия 2. Разработка концепции ИС.

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

Стадия 3. Техническое задание.

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

Стадия 4. Эскизный проект.

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

• разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

• разработка проектных решений по системе и ее частям; разработка документации на ИС и ее части;

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

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

Стадия 6. Рабочая документация.

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

• разработка и адаптация программ.

Стадия 7. Ввод в действие.

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

Стадия 8. Сопровождение ИС.

• выполнение работ в соответствии с гарантийными обязательствами;

• послегарантийное обслуживание.

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

• обоснования разработки и поэтапного внедрения систем;

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

• разработки технического и рабочего проектов систем.

На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации.

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

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

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

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

• возможности применения новых методов решения задач.

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

• функции - информация о событиях и процессах, которые происходят в бизнесе;

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

При изучении каждой функциональной задачи управления определяются:

• наименование задачи; сроки и периодичность ее решения;

• степень формализуемости задачи;

• источники информации, необходимые для решения задачи;

• показатели и их количественные характеристики;

• порядок корректировки информации;

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

• действующие средства сбора, передачи и обработки информации;

• действующие средства связи;

• принятая точность решения задачи;

• трудоемкость решения задачи;

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

• потребители результатной информации по задаче.

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

Типовое проектное решение (ТПР) — это тиражируемое (пригодное к многократному использованию) проектное решение. Выделяются следующие классы ТПР:

 Элементные ТПР – типовые решения по задаче или по отдельному виду обеспечения задачи

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

 Объектные ТПР – типовые отраслевые проекты, включающие полный набор функциональных и обеспечивающих подсистем ИС

Достоинства и недостатки ТПР:

 Элементные(библиотеки методо-ориентированных программ) + Обеспечивается применение модульного подхода к проектированию - Большие затраты времени на сопряжение разнородных элементов

 Подсистемные(пакеты прикладных программ) + Высокая степени интеграции элементов ИС + Сокращение затрат на проектирование и программирование взаимосвязанных компонентов - Адаптивность ТПР недостаточна - Проблемы в комплексировании разных функциональных подсистем

 Объектные ТПР(отраслевые проекты ИС) + Комплексирование всех компонентов ИС за счет методологического единства и информационной, программной и технической совместимости - Проблемы привязки типового проекта к конкретному объекту управления

Параметрически-ориентированное проектирование включает следующие этапы: Определение критериев оценки годности пакетов прикладных программ(ППП) Анализ и оценка доступных ППП по сформулированным критериям Выбор и закупка наиболее подходящего пакета Настройка параметров(доработка) закупленного ППП Модельно-ориентированное проектирование предполагает построение модели объекта автоматизации с использованием специального программного инструментария(например, SAP Business Engineering Workbench(BEW), BAAN Enterprise Modeler). Также создание системы возможно на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом. Репозиторий содержит базовую(ссылочную) модель ИС, типовые(референтные) модели определенных классов ИС, модели конкретных ИС предприятий Базовая модель ИС содержит описание бизнес функций, процессов, объектов, правил, а также описание орг. структуры, которые поддерживаются программными модулями типовой ИС  Типовые модели описывают конфигурации ИС для определенных отраслей или типов производства  Модель конкретного предприятия стоится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса(SAP Business Engineering Workbench)Реализация типового проекта предусматривает выполнение следующих операций:  Установку глобальных параметров системы  Задание структуры объекта автоматизации  Определение структуры основных данных Задание перечня реализуемых функций и процессов  Описание интерфейсов  Описание отчетов  Настройку авторизации доступа  Настройку системы архивирования

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

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

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

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

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

• Горизонтальная структура делится на три профиля:

• Организационно-функциональный – в нем сосредоточены функции организационного управления, поддерживаемые системой, составляющие их управленческие функции, а так же управленческие задачи, на которые распадаются управленческие функции. Чтобы этот верхний профиль не распался, иерархию функций организационного управления в ИС «связывают» соответствующим прикладным уровнем, которые представляет собой совокупность специального программно обеспечения следующей подчиненности: • управленческие задачи -> функциональные задачи; • управленческие функции -> функциональные комплексы задач. • организационные функции -> управленческие функциональные комплексы: • Технологический – его образуют следующие информационные технологи: предметные, проблемные, функциональные.

Устойчивости этого профиля поддерживают программные решения в следующей подчиненности: • предметные технологии -> технологические решения;

• проблемные технологии -> программно-технические решения;

• функциональные технологии -> операции обработки информации.

• Системно-техническая среда

11. Профиль информационной системы. Категории и виды профилей ИС. Принципы построения и структура профиля ИС. Типовые технологические решения.

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

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

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

• Профиль средств защиты информации.

• Профиль инструментальных средств, встроенных в ИС.Так же рассматривают вспомогательные профили:

• Профили процессов жизненного цикла прикладного ПО ИС (по стандарту ISO 12207).

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

• Профили инфраструктуры проекта данной ИС.EAI средства – комбинация процессов, программных средств, стандартов и аппаратуры, обеспечивающие «бесшовную» интеграцию приложений в пределах одной ИС или нескольких ИС уровня одного предприятия

12. Формирование и применение профилей информационных систем. Спецификации функций компонентов ИС. Структура полного профиля ИС. Способы интеграции приложений.

Категории и виды профилей ИС (в зависимости от сферы распространения): • Профили конкретных ИС, определяющие стандартизированные проектные решения в пределах проекта данной ИС, и имеющие статус документации проекта в части нормативных требований или статус стандарта предприятия. • Профили группы типовых, тиражируемых ИС, предназначенных для определенной области применения, имеющие статус отраслевого стандарта для этой области или статус стандарта организации, разрабатывающей и поставляющие такие ИС. • Стратегические профили дл определенной области применения ИС, определяющие ориентацию информатизации этой области на долгосрочный период, например, профили переносимости приложений между разными ИС в этой области.Функциональные профили, составляющие структуру полного профиля ИС: • Профиль приложения ИС, содержащий спецификации архитектуры и структуры подсистем ИС, программных интерфейсов взаимодействия между ними, форматов обмена данными и общих требований к прикладному ПО. • Профиль среды ИС, содержащий спецификации интерфейсов прикладного программирования, функций ПО промежуточного слоя, СУБД, пользовательских интерфейсов, операционных систем и требований к техническим средствам, а так де протоколов телекоммуникационной среды. • Профиль средств системного и сетевого администрирования. • Профиль средств защиты информации. • Профиль инструментальных средств, встроенных в ИС.Так же рассматривают вспомогательные профили: • Профили процессов жизненного цикла прикладного ПО ИС (по стандарту ISO 12207). • Профили обеспечения качества прикладных программных средств ИС. • Профили инфраструктуры проекта данной ИС.EAI средства – комбинация процессов, программных средств, стандартов и аппаратуры, обеспечивающие «бесшовную» интеграцию приложений в пределах одной ИС или нескольких ИС уровня одного предприятия

В рамках реализации EAI рассматривают такие способы интеграции приложений:

• 1. Интеграция бизнес-процессов предприятия. Непосредственное взаимодействие приложений поддерживающих бизнес-объекты и бизнес-функции.

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

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

• 4. Интеграция платформ.

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

13.Информационное обеспечение процесса проектирования. Основные требования к информационному обеспечению.

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

Основные требования к информационному обеспечению:

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

• Возможность хранения и поиска информации.

• Достаточный объем хранилищ информации; компактность хранимой информации и минимальное изнашивание носителей информации.

• Достаточное быстродействие системы.

• Возможность быстрого внесения изменений и корректировки информации.

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

Информация по виду представления:

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

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

• Фактографическая информация – числовые и буквенные справочные данные о материалах, ценах, комплектующих изделиях, о спроектированных объектах и т.д. В настоящее время различают два вида автоматизированных информационных систем – банки данных и информационно-поисковые системы (ИПС).

14.Подходы к организации и планированию процесса проектирования информационных систем. Требования к информационной системе. Методологии бизнес-анализа. Подход SWOT. Подход VCM. Подход BPR. Подход ISA.

Уровни требований предъявляемых к ИС:

• Бизнес-требования – формируются топ- менеджерами или акционерами предприятия.

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

• Функциональные требования.

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

• Специалисты по проектированию ИС – постановка задачи, определение рамок проекта.

• Представители заказчика – постановка задачи, определение рамок проекта, контроль работы, приемка результатов.

• Группа проектировщиков – разработка архитектуры, проектирование подсистем.

• Программисты – разработка программного кода.

• Тестировщики – составление тест-плана, тестовых сценариев.

• Менеджер проекта – планирование и контроль исполнения работ.

Методологии бизнес-анализа : • Модели преследующие цель анализа и улучшения организационной системы (SWOT, VCM, BPR, ISA).

• Модели общего назначения (глава 6).

• Модели, специально разработанные для использования при автоматизации. SWOT – (сильные стороны, слабые стороны, возможности, угрозы).

Этапы:

• Определяются цели, которые организация перед собой ставит.

• Определяются внутренние сильные и слабые стороны организации, выделяются приоритеты.

• Определяются внешние возможности и угрозы – неуправляемые внешние факторы.

• Определяются практические приоритетные цели на среднесрочный период. VCL – модель цепочек ценностей. Цель анализа цепочек найти слабые звенья. Изначально выделяют основную производственную цепочку, далее из других выделяют например поддерживающую деятельность. BPR – реинжиниринг бизнес-процессов. Основная идея: фирма должна сосредоточиться на бизнес-процессах как таковых. Иерархичность должна быть резко уменьшена, горизонтальные связи расширены и созданы в привязке к конечному результату на основе производственных цепочек. Реинжиниринг захватывает как собственно производство, так и снабжение, сбыт, маркетинг, управление внешними финансовыми потоками. ISA – архитектура информационных систем. Заключается в обращении с шестью одинаковыми по форме вопросами к пяти основным участникам разработки ИС. Поэтому подход известен как подход «5*6».

15.Оценка стоимости информационной системы. Краткое сравнение методов оценки стоимости. Модели оценки трудоемкости разработки информацион­ных систем.

Оценка стоимости информационной системы определяется в целях:  Принятия решения о целесообразности проекта

 Сравнения вариантов автоматизации в процессе выбора

 Планирование расходов на проект автоматизации

 Контроля фактических расходов на проект автоматизации Оценка стоимости ИС осуществляется с помощью моделей(рис 4.1)

Для оценки стоимости ИС используются следующие методы:

 Алгоритмические модели (вычисление оценки стоимости в виде функций некоторого числа параметров, представляющих основные стоимостные факторы)  Экспертные оценки(обсуждение группой экспертов)

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

 Оценивание методом “ сверху-вниз ” (полная оценка стоимости проекта выводится по глобальным характеристикам ИС, затем она распределяется между различными компонентами)

 Оценивание методом “ снизу-вверх ” (сперва оценивается работа по каждому компоненту, а затем результаты суммируются в оценку всей работы) Достоинства и недостатки оценивания стоимости программных систем(таб.4.1)

Модели оценки трудоемкости разработки ИС(МОТР ИС). Кроме условных методов, рассмотренных ранее существуют четыре основные МОТР ИС:

 IFPUG FPA

 MK II FPA

 COCOMO II (Constructive Cost Model)

 МОТР ИС, утвержденные Госкомтруда в 1986 году

Одной из наиболее известных является конструктивная модель стоимости(COCOMO), в 1999 году её сменила COCOMO II. Она устанавливает соответствие между размером системы в тысячах условных строк кода и “ классом(естественный, полуинтегрированный, “ встроенных систем ”)” проекта, с одной стороны, и трудоёмкостью разработки с другой.

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

 Тип модели и доступность репозиториев

 Учет факторов размера системы

 Непрерывная зависимость от сложности проекта

 Учет функциональной сложности

 Учет нефункциональных требований к системе

 Поддержка различных жизненных циклов и разбиения по стадиям жизненного цикла и др

16.Проектное управление: модели и методы принятия решений. Объект проектного управления. Основы проектного управления.

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

 Согласование целей проекта со всеми заинтересованными сторонами

 Тщательный подбор команды проекта

 Распределение ответственности между руководителями отдельных направлений

 Планирование основных совещаний и их целей

 Четкий контроль хода выполнения проекта

 Регулярная проверка управляющим проектом выполнения сметы и выдача предупреждений в случае опасности перерасхода средств

 Отклонение нецелесообразных изменений проекта при сохранении необходимой гибкости

 Открытое обсуждение проблем участниками проекта

 Безотлагательное решение проблем сегодня

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

Основными процессами управления проектами в соответствии с требованиями международной ассоциации PMI(Project manager institute) являются:

 Инициация проекта(Анализ целесообразности, описание результатов проекта)

 Планирование проекта(Планирование целей, стоимостные оценки, расписание работ, разработка плана проекта)

 Исполнение проекта(исполнение плана проекта, подтверждение целей и качества проекта, выбор поставщиков)

 Управление изменениями(управление качеством, отчетность о выполнении, управление рисками)

 Завершение проекта(административное завершение проекта, закрытие контрактов)

Деятельность как объект управления рассматривается в следующих случаях:

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

 достижение целей деятельности связано с последовательно- параллельным выполнением всех элементов этой деятельности;

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

 продолжительность и стоимость деятельности явно зависит от организации всего комплекса работ.

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

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

Сетевое планирование и управление включают три основных этапа:

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

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

 Оперативное управление Применяются сетевой и календарный графики для составления отчетов о ходе выполнения работ

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

 как действие — разработка чертежа, изготовление детали, заливка фундамента бетоном, изучение конъюнктуры рынка;

 процесс — старение отливок, выдерживание вина, трав­ление плат;

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

 действительной, т.е. требующей затрат времени;

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

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

17.Структурное планирование. Календарное планирование. Оперативное управление.

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

Сетевое планирование и управление включают три основных этапа:

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

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

 Оперативное управление Применяются сетевой и календарный графики для составления отчетов о ходе выполнения работ

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

 как действие — разработка чертежа, изготовление детали, заливка фундамента бетоном, изучение конъюнктуры рынка;

 процесс — старение отливок, выдерживание вина, трав­ление плат;

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

 действительной, т.е. требующей затрат времени;

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

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

18.Методика оптимизации сетевой модели по критерию «минимум исполнителей».

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

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

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

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

 на графике привязки над каждой работой написать ко­личество ее исполнителей;

 подсчитать количество работающих в каждый день ис­полнителей и отложить на графике загрузки

19.Методика оптимизации сетевых моделей по критерию «время — затраты».

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

Важными параметрами работы (i, j) при проведении данного вида оптимизации являются:

 коэффициент нарастания затрат: который показывает затраты денежных средств, необходимые для сокращения длительности работы (i, j) на один день;

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

Этапы оптимизации сетевых моделей по критерию “ время- затраты ” :

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

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

3. Рассматривается возможность сокращения продолжительности проекта

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

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

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

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

3. Причиной окончания оптимизации являются:

 Исчерпание ограниченных денежных средств

 Исчерпан запас времени сокращения

20.Методы оценки эффективности проектирования информационных систем. Показатели эффективности проектирования информационных систем.

21.Методы проектирования информационных систем.

Основные компоненты методологии построения ИС:

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

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

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

Подходы к определению методов проектирования ИС (Клещев Н.Т., Романов А.А.):

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

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

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

Метод характеризуется:

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

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

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

- учетом физических и информационных связей между элементами ИС. - учетом взаимосвязей создаваемой ИС с внешней средой.

 Объектные методы обеспечивают единую концепцию для:

- предпроектного анализа (объектный анализ) – выявление объектов предметной области и установление взаимосвязей меду ними.

- проектирования (объектное проектирование) – методы опираются на декомпозицию объекта, декларированное описание объектов классами, на пошаговое программирование и использование механизма наследования.

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

Подходы к определению методов проектирования ИС (Прозоров А.А.):  OMT , ИС представляется в виде трех взаимосвязанных моделей: - объектная модель – определяет статические аспекты системы, в основном связанные с данными. - динамическая модель – описывает работу отдельных частей системы. - функциональная модель – описывает взаимодействие отдельных частей системы, возникающее в процессе ее работы. IDEF, состоит из следующих частей: - IDEF0 – метод и нотация описания бизнес-процессов. - IDEF1 – метод и нотация описания взаимосвязей между информационными потоками. - IDEF1X – метод и нотация разработки реляционных БД. - IDEF3 – метод и нотация описания технологических процессов. - IDEF5 – метод и нотация описания онтологических исследований. COMET, основные этапы метода: - этап моделирования функциональных требований – сбор и классификация требований к системе, сама система рассматривается как черный ящик. - этап аналитического моделирования – выполняется в терминах сущностной модели, основное внимание уделяется предметной области. - этап архитектурного (имитационного) моделирования – выполняется объектная и временная декомпозиция сущностной модели, формулируются базовые критерии разбиения системы на составные части. - этап программного моделирования – программная реализация имитационной модели. Статическое представление имитационной модели детализируется до атрибутов и операций классов, а так же до законченных иерархий. Динамическое представление детализируется до полного описания активных составляющих, какими являются задачи, проектируются интерфейсы для обмена сообщениями

22.Методология создания информационных систем.

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

Основные задачи методологии:

 Обеспечение создания ИС, отвечающих предъявляемым к ним требованиям по автоматизации деловых процессов и целям и задачам организации.

 Гарантирование создание системы с заданным качеством в заданные сроки и в рамках бюджета.

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

 Обеспечение создания ИС, отвечающих требованиям открытости, переносимости и масштабируемости.

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

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

23. Основные составляющие методологии. Итерационная спиральная модель жизненного цикла ИС. Комплекс развивающихся систем согласованных моделей. Методология анализа ИС на основе бизнес-процессов.

Рассмотрена методология, принадлежащая ко второму классу, предложенная Паронджановым С.Д., её фундамент составляет:  Итерационная спиральная модель жизненного цикла ИС.  Комплекс развивающихся систем согласованных моделей.  Методология анализа ИС на основе бизнес- процессов.  Методология проектирования от данных.5.3.1 Итерационная спиральная модель жизненного цикла ИС. Процесс создания ИС представляет собой процесс построения и последовательного преобразования согласованных моделей на всех этапах жизненного цикла

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

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

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

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

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

24.Методы проектирования архитектур информационных систем.

Проектирование архитектуры:

Структурная методология.

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

 Метод восходящего проектирования – в первую очередь определяются вспомогательные подсистем.

 Метод расширения ядра – основное внимание уделяется выявлению множества подсистем, а не определению функций всей системы в целом.

Объектно-ориентированная методология.

 Метод проектирования предметных областей – выделение предметной области системы с точки зрения пользователя.

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

Структурная методология включает следующие основные методы проектирования модулей: • - диаграммы «сущность-связь». • - структурные карты. • - диаграммы деятельности. • - диаграммы Варнье-Орра. • - диаграммы переходов состояний. • - блок-схемы. • - псевдокод.

Объектно-ориентированная методология включает такие методы: • - диаграммы кооперации. • - диаграммы компонентов. • - диаграммы развертывания.

Методы анализа и построения спецификаций:

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

Объектно-ориентированная методология включает такие методы: • - КОК-карты (класс – ответственность – кооперация). • - диаграммы вариантов использования. • - диаграммы классов. • - диаграммы состояний. • - диаграммы деятельности. • - диаграммы последовательности

25.Подходы к ведению анализа и проектирования. Структурный анализ в проектировании ИС. Классификация структурных методологии. Методология функционального моделирования.

Структурная методология. Три подхода на основе порядка построения модели: 1) Процедурно-ориентированные подходы – первично проектирование функциональных компонентов. 2) Подходы, ориентированные на данные – первичны входные и выходные данные, а функциональные компоненты вторичны. 3) Информационно-ориентированные подходы – отличается от предыдущей, что работа ведется с неиерархическими структурами данных.Выделяют два класса целевых систем:  Информационные системы (управляемые данными) – работают с большим объемом входных данных сложной структуры.  Системы реального времени (управляемые событиями) – работаю с малым количеством входных данных простой структуры.Группы средств моделирования: - диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между ними, например, диаграммы потоков данных и функционального моделирования. - диаграммы, моделирующие данные и их отношения, например, диаграммы «сущьность-связь».Объектно-ориентированная методология. Основные подходы: 1) Подход на основе языка UML. Состоит из четырех основных фаз, причем работа с диаграммами ведется в основном на второй и третьей фазах. На второй фазе, исследования, создается модель предметной области. На третьей фазе, построения, продолжается итеративная работа с диаграммами классов и деятельности. К ним добавляются типы диаграмм, которые определяют взаимодействие: диаграммы последовательности, диаграммы кооперации. В случае сложного поведения системы разрабатывается еще одна группа диаграмм – диаграммы состояний.1) Подход Шлеер-Меллора использует три группы средств для создания модели предметной области: - информационное моделирование – для определения отношений между данными (диаграмма классов). - моделирование состояний – для определения зависящего от времени поведения системы ( диаграмма состояний). - моделирование процессов – для определения функций которая система должна выполнять (диаграмма деятельности, диаграмма последовательности). Для анализа больших предметных областей используются диаграммы, по смыслу близкие к следующим диаграммам языка UML: диаграммы кооперации, компонентов, развертывания.Подход предлагает механизм поддержки моделей состояний. Для этого вводятся четыре архитектурных класса: - переход, описывающий каждый переход для всех моделей состояний в программе. - конечная модель состояний, связывающая все экземпляры перехода, которые составляют одну модель состояний. - активный экземпляр. Это абстрактный класс, из которого все экземпляры, имеющие модель состояний, наследуют их текущее состояние. - таймер, обеспечивающий механизм работы таймеров на основе аппаратных средств, доступных для хранения следа времени.1) Подход Град и Буча. 2) Подход Джеймса Рамбо. 3) Подход Ивара Якобсона.6.2 Структурный подход к проектированию ИС. Сущность структурного подхода к разработке ИС в ее декомпозиции (разбиении) на автоматизированные функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, подразделяемые на задачи и т.д. Разбиение продолжается вплоть до конкретных процедур. При этом система сохраняет целостное представление.6.2.1 Структурный анализ в проектировании ИС. Проблемы, с которыми сталкивается системный аналитик а так же основные принципы анализа систем рассмотрены в первой главе. В структурном анализе применяются в основном две группы средств, отражающие функции, выполняемые системой, и отношения между ними. Каждой группе средств соответствуют определенные виды моделей (диаграмм), самые распространенные:  SADT-модели и соответствующие функциональные диаграммы.  DFD-диаграммы потоков данных.  ERD-диаграммы «сущьность-связь».

6.2.2 Классификация структурных методологий. Современные структурные методологии анализа и проектирования классифицируются по следующим признакам: - Отношению к школам – Software Engineering (SE) и Information Engineering (IE). - Порядку построения модели – процедурно- ориентированные, ориентированные на данные и информационно-ориентированные. - Типу целевых систем – для систем реального времени и для информационных систем

Методология SADT разработана Дугласом. На ее основе разработана методология IDEF0, которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий). Основные элементы концепции основаны на следующих концепциях: 1. Графическое представление блочного моделирования. 2. Строгость и точность.Правила SADT включают: - ограничение количества блоков на каждом уровне декомпозиции (3-6). - связность диаграмм (номера блоков), уникальность меток наименований (отсутствие повторяющихся имен). - синтаксические правила для графики, разделение входов и управлений (правило определения роли данных). - исключение влияния организационной структуры на функциональную модель.Состав функциональной модели. Состоит из диаграмм, фрагментов текста и глоссария, имеющих ссылки друг на друга. Главный компонент диаграмма, все функции ИС и интерфейсы на них представлены как блоки и дуги

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

26.*Методология описания и моделирования процессов. Моделирование потоков данных (процессов). Спецификации управления.

Метод описания процессов IDEF3. Это методология описания процессов, рассматривающая последовательность их выполнения и причинно-следственные связи между ситуациями и событиями для структурного представления знаний о системе, а так же описания изменения состояний объектов, являющихся составной частью описываемых процессов. IDEF3 предоставляет инструментарий для наглядного исследования и моделирования сценариев выполнения процессов. Фиксирует следующую информацию о процессе: - объекты, которые участвуют при выполнении процесса. - роли, которые выполняют эти объекты. - отношения между работами в ходе выполнения сценария процесса. - состояния и изменения, которым подвергаются объекты. - время выполнения и контрольные точки синхронизации работ. - ресурсы, необходимые для выполнения работ.Описание IDEF3. В стандарте IDEF3 существует два типа диаграмм, представляющих описание одного и того же сценария технологического процесса в разных ракурсах.  Диаграммы описания последовательности выполнения процессов (Process Flow Description Diagrams, PFDD).  Сеть изменений объектных состояний (Object State Transition Network, OSTN). Основные элементы диаграмм описания последовательности процессов. Графические элементы, которые включают диаграммы процесса, включают модуль полей поведения (UOB), связей старшинства, перекрестков, объектов ссылки и примечаний.Функциональный элемент (UOB). Состоит из имени процесса, который отражает всевозможные ситуации которые могут произойти в моделируемой системе (процессы, функции, действия, акты, события, сценарии, процедуры, операции, решения); номера идентификатора, назначаемого последовательно; ссылки – либо на элемент модели IDEF0, либо на конкретных исполнителей.Элемент связи. Используются для обозначения отношений между элементами UOB. Для отображения временной последовательности используются связи старшинства и относительные связи. Для описания специфических отношений используются сдерживаемые связи старшинства. Номера стрелок содержат префикс «L» и номер. Связи старшинства. Выражают временные отношения старшинства между элементами диаграммы. При этом первый элемент должен завершиться, прежде чем начнет выполняться второй.

Сдерживаемые связи старшинства. В дополнение к семантике запуска связей простого старшинства указывают: - элементу А должен предшествовать элемент В. - элементу В должен предшествовать элемент А. Относительные связи. Указывают, что между элементами диаграммы описания процесса существуют отношения неопределенного типа.Связь «поток объектов». Означает, что между UOB-элементы происходит передача объекта (ов), причем первый элемент должен завершиться прежде, чем начнется второй. Перекресток. Отображают логику отношений между множеством событий и временную синхронизацию активизации элементов. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. В PFDD-диаграмме перекрестки нумеруются и имеют префикс «J».Типы перекрестков. - & - логический И. - О – логический ИЛИ. - Х – логический перекресток НЕЭКВИВАЛЕНТНОСТИ. Разделение на синхронные и асинхронные позволяют учитывать в диаграммах описания процессов синхронизацию времени активизации. График запуска – визуальное отображение временной последовательности выполнения UOB-элементов.Использование перекрестка «Асинхронный AND»: Возможный график запуска:Элемент «референт». Это элемент ссылки, расширяющие границы понимания диаграммы и упрощают конструкцию описания. Предназначены для: - обращения к предварительно определенному UOB-элементу без дублирования его определения. - передачи управления или организации возвратных циклов. - организации связи между OSTN и PFDD объектами диаграмм.Виды референтов. Определено два вида по способу запуска: - «запустить и продолжить» - указывает, что он референт должен лишь запуститься раньше, чем выполнение элемента IDEF3, вызывающего элемент «референт», будет завершено. - «запустить и ждать» - референт должен запуститься и завершиться. Использование референта «запустить и продолжить». Если используется референт, который имеет тип UOB, SCENARIO, GO-TO, то на выходе такого элемента не может использоваться стрелка старшинства.UOB-референт. Если референт UOB используется в диаграмме PFDD, то во время выполнения вызывающего UOB-элемента осуществляется запуск соответствующего UOB- элемента. Если UOB- референт приложен к стрелке связывающей элементы OSTN диаграммы, то выполнение UOB- элемента должно начаться прежде, чем начнет изменяться состояние объекта. SCENARIO-референт. Если референт используется в диаграмме PFDD, то во время выполнения вызывающего UOB-элемента осуществляется запуск вызванного сценария. Если референт приложен к стрелке связывающей элементы OSTN диаграммы, то выполнение UOB-элемента должно начаться прежде, чем начнет изменяться состояние объекта.Использование референта «запустить и ждать». Элемент может являться источником для связи старшинства. Особенностью является невозможность использования GO-TO- референта. Элемент «примечание». Может быть приложен к UOB-элементу, перекрестку, связи , референту. Предназначен для: - идентификации и подчеркивания участия специфических объектов или отношений, связанных с элементом UOB, связью или переходом. - присоединения примеров, объектов и т.д. - отображения специальных условий, уточнения соединения или ограничения, связанных с элементами диаграмм. Идентификация примечания состоит их номера элемента, для которого делается примечание, и номера примечания с префиксом N (J1/N1).Декомпозиция процесса. Процесс создания иерархически организованной совокупности диаграмм, детализирующих определенный элемент. Результатом является описание, которое представляет собой дробление родительского элемента на меньшие и более частные операции или функции – элементы потомки. Так же включает и синтез.6.2.5 Моделирование потоков данных (процессов). В основе данной методологии (Gane/Sarson) лежит построение модели анализируемой ИС – проектируемой или реально существующей. Определяется как иерархия диаграмм потоков данных (DFD), описывающая асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Основные процессы определяют диаграммы верхних уровней иерархии (контекстные), детализирующиеся при помощи диаграмм нижнего уровня. Основными компонентами ДПД являются: внешние сущности, системы (подсистемы), процессы, накопители данных, потоки данных.Внешние сущности. Материальный предмет или физическое лицо, представляющее собой источник или приемник информации. Находится за пределами анализируемой ИС, но при необходимости может вноситься в ее границы. Системы и подсистемы.Процессы. Представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Накопители данных. Абстрактное устройство для хранения информации. Идентифицируется буквой «D» и произвольным числом. В общем случае является прообразом будущей базы данных.Потоки данных. Определяет информацию, передаваемую через некоторое соединение от источника к приемнику.Иерархия диаграмм потоков данных (ДПД). Первым шагом при построении иерархии диаграмм ДПД является построение контекстных диаграмм. Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем как между собой, так и с внешними входными и выходными потоками данных и внешними объектами. Далее модель следует проверить на полноту исходных данных об объектах системы и на изолированность объектов. При детализации должны выполняться следующие правила: - правило балансировки – детализирующая диаграмма в качестве внешних источников/приемников данных только те компоненты, с которыми имеет информационную связь детализируемая подсистема на родительской диаграмме. - правило нумерации – должна поддерживаться иерархическая нумерация, например, процессы, детализирующие процесс с номеров 12, получают номера 12.1, 12.2, 12.3 и т.д.Решение о завершении детализации процесса и использовании миниспецификации (описание логики процесса) применяется аналитиком исходя из следующих критериев: - наличие у процесса относительно небольшого количества входных/выходных потоков данных (2-3); возможности описания преобразования данных процессом в виде последовательного алгоритма. - выполнение процессом единственной логической функции преобразования входной информации в выходную; применение спецификации небольшого объема (20-30 строк). При построении иерархии ДПД переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации, так же может указываться тип данных (непрерывные, дискретные).Контекстная диаграмма верхнего уровня определяет границы модели, и как правило имеет звездообразную топологию.6.2.6 Спецификации управления. Спецификации управления предназначены для моделирования и документирования аспектов систем, зависящих от времени совершения события или реакции на событие. Для этой цели обычно используются диаграммы переходов состояний (STD). Они состоят из следующих объектов: Состояние – может рассматриваться как условие устойчивости для системы. Имя состояния должно отражать реальную ситуацию, в котором находится система, например, НАГРЕВАНИЕ, ОХЛАЖДЕНИЕ и т.д. Начальное состояние – STD имеет только одно начальное состояние, соответствующе состоянию системы после ее инсталляции. Переход – определяет перемещение моделируемой системы из одного состояния в другое. Событие состоит из управляющего потока (сигнала), возникающего при выполнении некоторого условия (КНОПКА НАЖАТА). Если в условии участвует входной управляющий поток управляющего процесса предка, то имя потока должно быть заключено в кавычки («ПАРОЛЬ» = 777). Кроме условия, с переходом может быть связанно действие или ряд действий, если оно необходимо для выходного управляющего потока, то его имя должно заключиться в кавычки («ВВЕДЕННАЯ КАРТА» - TRUE).Применяются два способа построения STD. Первый способ заключается в идентификации всевозможных переходов и дальнейшем исследовании всех небессмысленных связей между ними. По второму способу сначала строится начальное состояние, потом следующие за ним и т.д. В ситуации, когда число состояний и (или) переходов велико, для проектирования спецификаций управления используются таблицы и матрицы перехода

27.Сравнительный анализ структурных методологий. Объектно-ориентированные методологии Объектно-ориентированный анализ.

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

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

6.3 Объектно-ориентированные методологии.

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

- инкапсуляция – свойство, при котором объекты содержат описания атрибутов и действий одновременно.

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

- полиморфизм – свойство объектов, при котором действия с одинаковыми именами вызывают различное поведение для различных объектов.

6.3.1 Объектно-ориентированный анализ (ООА). Методология предложена Йорденом для проектирования больших систем. ООА состоит из пяти главных шагов и соответствующих им компонентов: схемы предметной области, схемы объектов, схемы структуры, схемы атрибутов, схемы методов. Схема предметной области. Содержит описание ее различных частей и взаимодействий между ними, и позволяет разделить предметную область на такие части, в которых содержатся однотипные объекты. Все части предметной области пронумерованы и связанны между собой. Схема объектов. Каждому объекту на схемах соответствует графический элемент. В верхней части указывается - имя, в средней - атрибуты, в нижней – методы. Выбор набора базовых объектов во многом определяет структуру и качество всего проекта. Схема структуры. Описание структуры предполагает определение отношений наследования двух типов: отношение вида «является» обозначаются простыми соединительными линиями; вида «состоит из» - линиями со стрелками. Схема атрибутов. Графическая схема атрибутов повторяет схему структуры, но для каждого объекта указываются его атрибуты. Схема методов. Графическая схема методов повторяет схему атрибутов, но для каждого объекта указывается его методы поведения

28.Универсальный язык моделирования.

UML – это универсальный язык моделирования, разработанный в фирме Rational Software. Пакеты как средство работы с большими проектами. Пакеты представляют собой универсальное средство для группирования элементов моделей. Пакеты могут вкладываться друг в друга и могут содержать пакеты или элементы моделей.Рекомендации по составлению пакетов и классов в них: 1) Каждый пакет должен быть максимально независим от других пакетов, все связи должны быть локализованы и сведены к минимуму. 2) Структура пакетов должна отражать структуру предметной области. 3) Каждый пакет должен содержать классы, однотипные с точки зрения предметной области. 4) Желательно, иерархия наследования начиналась с одного базового объекта в каждом пакете, допустимо два, три, но не более. 5) Базовый объект в каждом пакете – это следующий принципиальный момент после самих пакетов.

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

Интерфейсы. Предназначены для спецификации внешнего вида операций для классов. Отношения между классами. Двуместная связь – отношение между двумя классами. Изображается сплошной линией, конец которой соединенный с классом, называется ролью.Множественность роли определяет количество экземпляров классов, участвующих в отношении. Пример: 1, 1..* , * , 0. Сортировка роли определяет тип упорядочения элементов для множественности более чем один. Значения: упорядочены, неупорядочены. Символ агрегации – это ромб, находящийся между линией и классом. Обозначает что класс, вблизи которого он изображен, является накопителем для класса, на другом конце связи. Ели ромб залит черным цветом, то это усиленная агрегация, называемая композиция.Квалификатор – это один или несколько атрибутов, значения которых обеспечивают идентификацию экземпляров класса по данной связи. Множественность указанная для роли, при наличии квалификатора указывает на количество экземпляров класса, выбираемых одним значением квалификатора. Имя роли - произвольный идентификатор, конкретизирующий роль связи для одного из классов, указывается на линии вблизи класса. Класс, описывающий связь. Связь между классами так же может обладать свойствами присущими некоему классу. Ассоциированный класс изображается прямоугольником и связывается с отношением, для которого он задан, штриховой линией.N-местная связь – связь между тремя и более классами. Обозначается ромбом, соединенным линиями с классами. Композиция. Сборка. Описывают включения классов друг в друга. Пример:  сборка – элементы входят в хэш-таблицу и образуют ее. Таблица имеет собственную логику и структуру. Может не содержать ни одного элемента. В то же время элементы могут существовать изолированно от таблицы.  композиция – здание образуется набором внутренних помещений. Они не могут существовать друг без друга и вне друг друга. Обобщение – отношение между общим и уточняющим элементом, показывается как линия со стрелкой.Зависимость – обозначает любую зависимость между любыми элементами модели, изображается штриховой линией с направлением. Диаграммы использования предназначены для отображения внешнего функционирования проектируемой системы и ее взаимодействия с внешним миром пользователей. Включает следующие элементы:  Внешние пользователи (actors) – воздействия которые передают или получают информацию для системы, т.е. физические объекты разной природы.  Блоки использования (use case) – группы функций системы, которые объединяются в единое целое для внешнего пользователя.  Связи между блоками использования и внешними пользователями. Виды связей:  Взаимодействие (сплошная линия).  Расширение – дополнение функций одного блока функциями другого (линия со стрелкой помеченная словом «extends»).  Использование (линия со стрелкой помеченная словом «uses»). Являются весьма популярным средством благодаря простой формулировке требований ориентированной на пользователя.Диаграмма последовательностей. Предназначена для отображения временных зависимостей, возникающих в процессе общения между объектами. Изображается как график. По вертикали – время, по горизонтали – объекты, состоящие из элементов: - объект – прямоугольник с записанным в нем именем объекта. - линии жизни объекта – штрихпунктирная линия, выходящая из объекта и расположенная вдоль оси времени. - активации – тонкий вертикальный прямоугольник, обозначающий период активной жизни объекта. - вызова метода поведения объекта (сообщение) – стрелка между активациями объектов с именем действия. - текстовых пометок.Диаграмма сотрудничества. Предназначена для описания методов взаимодействия между объектами. Сотрудничество представляет набор объектов, которые вызывают методы поведения дру друга. Диаграмма сотрудничества описывает статическую структуру объектов, участвующих в реализации поведения. Диаграмма состояний представляет конечный автомат и показывает последовательность состояний объекта, через которые он проходит во время своего существования под воздействием внешних событий. Состояния. Состояния автомата соответствуют состояниям объектов, в которых объект удовлетворяет некоторому условию, выполняет некоторое действие или ожидает события. Каждому событию может соответствовать вложенный автомат. Изображается прямоугольником со скошенными краями, состоящим из двух частей, в первой указывается имя, во второй отображается внутреннее действие, выполняемое в ответ на определенные события.События. Любое действие, имеющее значение с точки зрения смены состояний автомата. Виды событий: - условие становится истинным. - прием внешнего сигнала от одного объекта к другому. - запрос на выполнение метода объекта. - истечение заданного периода времени. Простые переходы между состояниями. Простой переход из состояния 1 в состояние 2 показывает, что объект, находящийся в состоянии 1, перейдет в состояние 2 выполнит определенные действия, когда произойдет предопределенное событие и будут истинными специфицированные условия. Составные переходы между событиями. Предназначены для отражения операций распараллеливания и синхронизации. Может иметь несколько входных и выходных состояний. После выполнения составного перехода все его выходные состояния становятся активными, а выходные наоборот.Вложенные автоматы. Если состоянию соответствует вложенный автомат, то после выполнения действия entry для состояния начинает работать вложенный автомат. Когда достигается одно из конечных состояний вложенного автомата, то состояние считается законченным, выполняются действия по выходу (exit), и автомат готов к смене состояния под воздействием внешних воздействий. Одному состоянию может соответствовать либо одни вложенный автомат, либо несколько конкурирующих. Диаграммы действия. Показывают поток управления, внутренний для операции, в противоположность показу реакции на внешние события (как в диаграмме состояний). Действия. Показывает выполнение некоторой неделимой операции. Условия. Предназначены для обозначения возможности условной передачи управления в соответствии со значением некоторого логического выражения. Переходы. Имеют тот же смысл, что и в автомате диаграммы состояний. Но не помечаются никаким событием и имеют условие только для специальных состояний «условие».

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

29.Виды документации, формируемой в процессе создания ИС. Предпроектная документация. Техническая документация, Проектно-сметная документация. Организаци­онно-распорядительная документация.

Предпроектная. На данной стадии формируются два основных документа: технико-экономическое обоснование (ТЭО) и техническое задание (ТЗ) на создание системы.

2. Проектирование. На данной стадии формируются документы: технический проект (ТП) и рабочий проект (РП). Иногда их объединяют в единый документ – технорабочий проект (ТРП).

3. Внедрение в опытную и промышленную эксплуатацию. Здесь формируются документы: акт о сдаче в опытную эксплуатацию комплекса задач и акт о сдаче в промышленную эксплуатацию системы.

30.Техническое задание (структура, назначение, основные разделы).

Техническое задание — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования Таблица 5.1. Структура ТЗ
№	Раздел
1	Общие положения
2	Назначение и цели создания (развития) системы
3	Характеристика объекта автоматизации
4	Требования к системе
5	Состав и содержание работ по созданию системы
6	Порядок контроля и приемки системы
7	Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8	Требования к документированию
9	Источники разработки

18.1. Общие положения

1. Полное наименование системы и ее условное обозначение;

2. шифр темы или шифр (номер) договора;

3. наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

4. перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

5. плановые сроки начала и окончания работы по созданию системы;

6. сведения об источниках и порядке финансирования работ;

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

8. состав используемой нормативно-технической документации;

9. определения, обозначения, сокращения

18.1.1. Полное наименование системы и ее условное обозначение

Полное наименование системы: Единая автоматизированная система учета кадров всех государственных предприятий "АС Кадры".

Краткое наименование системы: АС Кадры.

18.1.2. Шифр темы или шифр (номер) договора

Шифр темы: АИС-КА-ФА-07.

Номер контракта: №1/11-11-11-001 от 11.11.2008.

18.1.3. Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты

Заказчиком системы является Федеральное агентство "Государственные Кадры".

Адрес заказчика: 111000 г. Москва, Красная площадь, д.1.

Разработчиком системы является ООО "Софт".

Адрес разработчика: 222000 г. Москва, Лубянка, д.1.

18.1.4. Перечень документов, на основании которых создается система, кем и когда утверждены эти документы

Основанием для разработки АС "Кадры" являются следующие документы и нормативные акты:

• Государственный контракт №1/11-11-11-001 от 11.11.2008 года на выполнение работ по выполнению первого этапа работ по созданию Единой автоматизированной системы учета кадров всех государственных предприятий "АС Кадры";

• Федеральный закон от 01 июля 2006 г. N 555-ФЗ "Управление государственными кадрами";

• Постановление Правительства РФ от 01 января 2005 г. N 11.11 "О федеральной целевой программе "Электронные кадры (2002 - 2009 годы)";

• Концепция информатизации федерального агентства "Государственные кадры" на 2000-2010 годы.

18.1.5. Плановые сроки начала и окончания работы по созданию системы

Плановый срок начала работ по созданию Единой автоматизированной системы учета кадров всех государственных предприятий "АС Кадры" - 01 апреля 2009 года.

Плановый срок окончания работ по созданию Единой автоматизированной системы учета кадров всех государственных предприятий "АС Кадры" - 15 декабря 2009 года.

18.1.6. Сведения об источниках и порядке финансирования работ

Источником финансирования является бюджет Российской Федерации.

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

18.1.7. Порядок оформления и предъявления заказчику результатов работ

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

Порядок предъявления системы, ее испытаний и окончательной приемки определен в п.6 настоящего ТЗ. Совместно с предъявлением системы производится сдача разработанного Исполнителем комплекта документации согласно п.8 настоящего ТЗ.