Шпаргалка по "Информационным системам в экономике"

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

 

   Модели  ИС.

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

   К настоящему времени наибольшее распространение  получили следующие две основные модели ЖЦ:

6. Каскадная модель ИС (70-85 г.г.);

7. Спиральная модель ИС (86-90 г.г.).

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

   Положительные стороны применения каскадного подхода  заключаются в следующем [2]:

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

   

   Рис. 1.1. Каскадная схема  разработки ПО

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

   

   Рис. 1.2. Реальный процесс  разработки ПО по каскадной схеме

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

   Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

   

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

8. Этапы проектирования экономических  информационных систем.

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

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

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

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

   3. проектирование;

   4. изготовление;

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

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

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

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

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

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

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

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

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

   финансовых  и трудовых ресурсов;

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

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

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

   Главным содержанием этой фазы является разработка технического предложения

   переговоры  с заказчиком о заключении контракта. Общее содержание работ этой фазы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Разработка

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

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

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

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

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

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

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

   новых контрактах. Основные виды работ:

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

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

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

   4. сопровождение, поддержка, сервисное  обслуживание;

   5. оценка результатов проекта и подготовка итоговых документов;

   6. разрешение конфликтных ситуаций  и закрытие работ по проекту;

   7. накопление опытных данных для  последующих проектов, анализ опыта,  состояния, определение направлений  развития.

9. Исследование  предметной области (ПО). Модель «сущность-связь».

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

   Одной из наиболее популярных семантических  моделей данных является модель «сущность-связь" (часто называемая также ER-моделью — по первым буквам английских слов Entity (сущность) и Relation (связь)).

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

   Для моделирования структуры данных используются ER-диаграммы (диаграммы  «сущность-связь»), которые в наглядной  форме представляют связи между сущностями. В соответствии с этим ER-диаграммы получили распространение в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Наиболее распространенными являются диаграммы, выполненные в соответствии со стандартом 1DEF1X, который используют наиболее популярные CASE-системы (в частности, ERwin, Design/IDEF, Power Designer). Основными понятиями ER-диаграммы являются сущность, связь и атрибут.

   Сущность

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

   1. иметь уникальный идентификатор;

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

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