Лекция 2

Жизненный цикл – это непрерывный процесс, который начинается с момента принятия решения о создании ИС и заканчивается моментом вывода ее из эксплуатации.

Основной нормативный документ – это ISO/JEC 12.207.

В соответствии с этим стандартом выделяют:

1. основные процессы

   1. договорной аспект

   2. аспект управления (управление разработкой, эксплуатацией)

   3. эксплуатационный аспект

   4. инженерный аспект (процесс разработки и сопровождения)

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

   1. документирование

   2. верификация

   3. аудит

   4. аттестация

   5. обеспечение и контроль качества разрабатываемой системы

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

   1. создание инфраструктуры

   2. модификация (усовершенствования)

   3. обучение персонала

Процессы разработки включают следующие процессы:

1. формирование требований к системе

2. системный анализ на этапах:

   1. as is (как есть)

   2. to be (как должно быть)

3. процесс проектирования, кодирования, тестирования, процесс интеграции компонентов

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

Выделяют 3 модели реализации ЖЦ:

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

2. модель Боэма (спиральная модель) – процесс разработки превращается в постепенное создание ряда прототипов (релизов), которые затем превращаются в конечную реальзацию

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

1. для архитектуры функциональных требований

2. для архитектуры данных

3. для архитектуры функциональных приложений

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

5. для архитектуры интеграции

Структурный подход проектирования ис

Эффективный подход к решению проблемы сложности ИС заключается в иерархической декомпозиции («разделяй и властвуй»).

Правильная декомпозиция это:

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

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

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

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

В SE существует два подхода к разработке ИС:

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

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

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

1. разделяй и властвуй

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

3. абстрагирование - выделение существенных аспектов системы и отвлечение от несущественных

4. непротиворечивость - контроль, обоснованность и согласованность элементов системы

5. структурирование данных

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

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

В настоящее время используются следующие методологии СП:

1. Иордан/Де Марко

2. Гейн/Сарсен

3. SADT (Structured Analysis Design Technique)

4. Мартин

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

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

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

Виды деятельности:

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

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

В СП используют 3 группы средств, описывающих проектируемую систему:

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

2. для структуры данных

3. для описания динамики поведения системы

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

1. для первой группы:

   1. DFD-модель (Data Flow Diagram)

   2. IDEF0 - модель SADT

2. для второй группы:

   1. ERD (Entity Relationship Diagram)

   2. IDEF1X – модель SADT

3. для третьей группы:

1. STD (State Transition Diagram) – диаграмма перехода состояний

2. IDEF3

3. IDEF0PN (Integration Definition Petri Network)

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

1. была возможность создания для ЛПО развитой информационной среды

2. эффективными функциональными приложениями (бизнес-процессами)

13.09.04.