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

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

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

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

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

1 – Планирование разработки ИС;

2 – Определение требований к системе;

14 – сбор и анализ требований к с-ме;

3 – Концептуальное планирование БД;

4 – Логическое проектирование БД;

5 – Физическое проектирование БД;

6 – Проектирование БД;

7 – Выбор целевой СУБД;

8 – Разработка приложений;

9 – Реализация;

10 – Создание прототипов;

11 – Конвертирование и загрузка существующих

данных;

12 – Тестирование

13 – Эксплуатация и сопровождение

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

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

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

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

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

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

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

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

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

Физическое проектирование. Создается описание реализации БД на запоминающих устройствах с указанием способов хранения и методов доступа к данным. Для реляционной модели этот этап включает следующее: создание набора таблиц и ограничений для них; определение методов доступа к данным и разработка средств защиты проектируемой с-мы.

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

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

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

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

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

1 – Планирование разработки ИС;

2 – Определение требований к системе;

14 – сбор и анализ требований к с-ме;

3 – Концептуальное планирование БД;

4 – Логическое проектирование БД;

5 – Физическое проектирование БД;

6 – Проектирование БД;

7 – Выбор целевой СУБД;

8 – Разработка приложений;

9 – Реализация;

10 – Создание прототипов;

11 – Конвертирование и загрузка существующих

данных;

12 – Тестирование

13 – Эксплуатация и сопровождение

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

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

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

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

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

Стратегии тестирования:

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

2. восходящая. Тестирование начинается с модуля самого нижнего уровня.

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

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

Эксплуатация и сопровождение включает в себя:

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

2. сопровождение и модернизация приложения. Это может включать в себя как консультации по работе приложения, так и доработку ИС.

Требования. Место в ЖЦ разработки ИС

Получить заказ можно двумя способами:

1. Заключить договор. Такое возможно только на работы до 100 тыс. на остальное должны проводиться конкурсы.

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

Формулирование требований – это этап, который определяет кто что и в каком объеме будет делать.

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

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

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

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

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

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

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

Для проектной системной спецификации пользователи – это все что выше, кроме конечных пользователей.

На этапе формирования заявки формируются только первые 2 требования, исполнитель уже предложит спецификацию.

 

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

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

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

5. Нефункциональные требования

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

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

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

Классификация НеФТ:

1. Требования к продукту

1.1 требования к эксплуатации

1.2 требования к эффективности

1.2.1 требования к производительности

1.2.2 требования к памяти

1.3 требования к надежности

1.3 требования к переносимости

2. организационные требования

2.1 выходные требования

2.2 требования на реализацию

2.3 требования на стандарты

3. внешние требования

3.1 требования на взаимодейсвтие

3.2 этические требования

3.3 юридические требования

3.3.1 требования о сохранении конфиденциальности

3.3.2 требования по технике безопасности

 

6. Пользовательские требования.

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

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

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

Могут возникнуть проблемы:

1. отсутствие четкости изложения (лаконично!)

2. смешение требований

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

 

7. Системные требования.

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

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

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

1. естественный язык

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

3. язык описания программ (псевдоязык) (язык программирования)

4. графические нотации(блок-схема, IDEF0-схема)

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

Описание модели лучше представлять в математической модели.

Описание системы в множественном виде:

S=<B,P,V>

P=<{I}, {O}, F>

I=…

8. Разработка требований

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

Различают четыре основных этапа процесса разработки требований:

- анализ технической осуществимости создания системы,

- формирование и анализ требований,

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

- аттестация этих требований.

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

1. Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика?

2. Можно ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости?

3. Можно ли объдинить систему с другими системами, которые уже эксплуатируются?

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

1. Что произойдет с организацией, если система не будет введена в эксплуатацию?

2. Какие текущие проблемы существуют в организации и как новая система поможет их решить?

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

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

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

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

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

· На требования к системе могут влиять политические факторы.

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

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

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

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

Процесс формирования и анализа требований проходит через ряд этапов:

· Анализ предметной области. Аналитики должны изучить предметную область, где бу­дет эксплуатироваться система.

· Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.

· Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требовании.

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

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

· Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

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

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

1. Проверка правильности требований.

2. Проверка на непротиворечивость.

3. Проверка на полноту.

4. Проверка на выполнимость.

Существует ряд методов аттестации требований:

1. Обзор требований.

2. Прототипирование.

3. Генерация тестовых сценариев.

4. Автоматизированный анализ непротиворечивости.

 

9. Управление требованиями (и управление изменениями требований)

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

С точки зрения разработки требования можно разделить на два класса:

1. Постоянные требования.

2. Изменяемые требования.

Планирование управления требованиями

1. Идентификация требований.

2. Управление процессом внесения изменений.

3. Стратегия оперативного контроля.

- Информация об источнике требования

- Информация о требованиях

- Информация о структуре системы

4. Поддержка CASE-средств.

Процесс управления изменениями состоит из трех основных этапов:

1. Анализ проблем изменения спецификации.

2. Анализ изменений и расчет их стоимости.

3. Реализация изменений.

 

 

Модели систем

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

Модели могут представить систему в различных аспектах:

· Внешнее представление, когда моделируется окружение или рабочая среда системы.

· Описание поведения системы, когда моделируется ее поведение.

· Описание структуры системы, когда моделируется системная архитектура или структуры данных, обрабатываемых системой.

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

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

· Модель обработки данных. Диаграммы потоков данных показывают последователь­ность обработки данных в системе.

· Композиционная модель. Диаграммы "сущность-связь" показывают, как системные сущности составляются из других сущностей.

· Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система.

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

· Модель "стимул-ответ". Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние событи

 

Модели системного окружения

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

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

Пример модели окружения

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

 

Поведенческие модели

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

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

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

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

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

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

 

 

Объектные модели.

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

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

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

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

Класс объектов - это абстракция множества объектов, которые определяются общими атрибутами и сервисами (операциями).

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

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

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

 

Репозиторий

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

Плюсы

· Эффективность

· Централизация средств управления данными

· Прозрачность модели совместного использования

Минусы

· Все подсистемы должны быть согласованы с моделью репозитория данных

· Проблема распределённого хранения репозитория

· Сложность перевода уже существующих систем на эту модель

· Одинаковые требования безопасности ко всем подсистемам

Клиент—сервер

Модель клиент—сервер — это модель распределённой системы, в которой показано распределение данных и процессов между несколькими процессорами. Модель включает три основных компонента:

· Набор серверов, предоставляющих сервисы другим подсистемам

· Набор клиентов, которые вызывают эти сервисы

· Сеть, посредством которой клиенты получают доступ к сервисам

Плюсы

· Простота добавления новых серверов

· Простота обновления сервисов

Минусы

· Высокие требования к пропускной способности сети

Абстрактная машина

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

Плюсы

· Пошаговое развитие системы

· Кросс-платформенность

Минусы

· Сложная структура

 

 

 

Централизованное управление

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

1. Модель вызова-возврата — применима только в последовательных системах и реализует передачу управления "сверху-вниз"

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

Модель потоков данных

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

 

Распределенные БД

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

Особенности: каждый узел обладает своими собственными СУБД. Может иметь собственные базы данных, локальных пользователей, клиентские станции и т.д.

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

Пусть имеется отношение (со схемой) r(R). Существует несколько способов хранения такого отношения в распределенной базе:

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

2. фрагментация. Отношение распределяется на основе фрагментации, то есть делится на фрагменты, каждый из которых должен содержать достаточно информации, для восстановления общего отношения. Фрагментация может быть либо горизонтальной (отношение делится на несколько подмножеств, каждый кортеж общего базового отношения принадлежит хотя бы одному фрагменту. Фрагмент определяется как r₁=σ_θ(r). Восстановление r= Uⁿ_i=1 r_i) и вертикальной (декомпозиция, при которой формируется множество наборов атрибутов таким образом, чтобы общая схема отношения получалась путем объединения этих атрибутов, фрагмент определяется r_j=П_Rj(r), а общее отношение устанавливается как r=r₁ r₂ … r_k

a х b – декартово произведение

a b – натуральное произведение

a b – тетта соединение

3. смешанный.

 

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

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

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

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

1 – Планирование разработки ИС;

2 – Определение требований к системе;

14 – сбор и анализ требований к с-ме;

3 – Концептуальное планирование БД;

4 – Логическое проектирование БД;

5 – Физическое проектирование БД;

6 – Проектирование БД;

7 – Выбор целевой СУБД;

8 – Разработка приложений;

9 – Реализация;

10 – Создание прототипов;

11 – Конвертирование и загрузка существующих

данных;

12 – Тестирование

13 – Эксплуатация и сопровождение

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

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

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

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

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

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

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

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

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