Проектирование приложений и информационных систем

1.

Кафедра информационных систем
Проектирование приложении и информационных систем
ТЕМА ЛЕКЦИИ
Лекция № 2
2 академический час
Бидахмет Жанар
(ФИО преподавателя)
[email protected]
(Электронная почта преподавателя )
1

2.

ПЛАН ЛЕКЦИИ
1. Понятие жизненного цикла ПО И
2. Процессы жизненного цикла: основные,
вспомогательные, организационные.
3. Модели жизненного цикла: каскадная, м
одель с промежуточным контролем, спир
альная.
4. Стадии жизненного цикла ПО ИС.
2

3.

ГЛОССАРИЙ:
1. CASE-технологии - обладают графическими средствами дл
я проектирования и документирования модели информационно
й системы
2. Unified Modeling Language (UML) - Унифицированный язык
моделирования. Первая версия UML появилась в январе 1997
года. Язык UML предназначен для моделирования различных к
лассов систем и их программного обеспечения. Нотация испол
ьзует объектно-ориентированные методы. Моделирование в д
анной нотации позволяет последовательно пройти концептуал
ьный, логический и физический уровни моделирования систем.
- стандарт на процессы и организацию жизненного цикла. Р3. I
SO/IEC 12207:1995 аспространяется на все виды заказного ПО
. Стандарт не содержит описания фаз, стадий и этапов
3

4.

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

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

В структуру ЖЦ следует включать следующие группы процессов:
Договорные процессы:
приобретение (внутренние решения или решения внешнего постав
щика);
поставка (внутренние решения или решения внешнего поставщика).
Процессы предприятия:
управление окружающей средой предприятия;
инвестиционное управление;
управление ЖЦ ИС;
управление ресурсами;
управление качеством.
13

14.

ание проекта;
оекта;
проекта;
ие рисками;
ие конфигурацией;
ие информационными потоками;
решений.
14

15.

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

16.

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

17.

Таблица 2.2. Стадии создания систем (ISO/IEC 15288)
№ п/
Стадия
п
1
Формирование концепции
Описание
Анализ потребностей, выбор конце
пции и проектных решений
2
Разработка
Проектирование системы
3
Реализация
Изготовление системы
4
Эксплуатация
5
Поддержка
6
Снятие с эксплуатации
Ввод в эксплуатацию и использова
ние системы
Обеспечение функционирования си
стемы
Прекращение использования, демо
нтаж, архивирование системы

18.

Rational Unified Process (RUP) предлагает итеративную мод
ель разработки, включающую четыре фазы: начало, исследование,
построение и внедрение.
Каждая фаза может быть разбита на этапы (итерации), в р
езультате которых выпускается версия для внутреннего или внешне
го использования. Прохождение через четыре основные фазы назы
вается циклом разработки, каждый цикл завершается генерацией ве
рсии системы. Если после этого работа над проектом не прекращае
тся, то полученный продукт продолжает развиваться и снова минует
те же фазы. Суть работы в рамках RUP - это создание и сопровожде
ние моделей на базе UML

19.

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

20.

CASE-технологии можно классифицировать по функциональной на
правленности на
-средства моделирования предметной области
-- средства анализа и проектирования
-- технологии проектирования схем баз данных
-- средства разработки приложений
-- технологии реинжиниринга программного кода и схем баз данных
В настоящий момент на рынке программного обеспечения н
асчитывается более 300 различных CASE-средств. Наиболее извес
тными являются BPwin, ERwin, Rational Rose.

21.

CASE-технологии можно классифицировать по функциональной на
правленности на
-средства моделирования предметной области
-- средства анализа и проектирования
-- технологии проектирования схем баз данных
-- средства разработки приложений
-- технологии реинжиниринга программного кода и схем баз данных
В настоящий момент на рынке программного обеспечения н
асчитывается более 300 различных CASE-средств. Наиболее извес
тными являются BPwin, ERwin, Rational Rose.

22.

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

23.

UML - это язык для визуализации, специфицирования, конструирова
ния и документирования артефактов программной системы (общий
обзор UML приведен в главе 2). Унифицированный язык моделиров
ания имеет хорошо определенные синтаксис и семантику; наиболее
заметная часть синтаксиса этого языка - его графическая нотация.
Диаграммы прецедентов представляют собой один из пяти типов ди
аграмм, применяемых в UML для моделирования динамических асп
ектов системы.
Диаграммой прецедентов, или использования (Use case diagram), н
азывается диаграмма, на которой показана совокупность прецедент
ов и актеров, а также отношения между ними.

24.

Прецеденты. В UML поведение моделируется с помощью прецеде
нтов, специфируемых в отрыве от реализации. Прецедент - это опи
сание множества последовательностей действий (включая их вариа
нты), которые выполняются системой для того, чтобы актер получил
результат, имеющий для него определенное значение. Это определ
ение включает в себя несколько важных пунктов.
1. Прецедент описывает множество последовательностей, каждая и
з которых представляет взаимодействие сущностей, находящихся в
не системы (ее актеров), с системой как таковой и ее ключевыми аб
стракциями.
2. Прецедент представляет функциональные требования к системе
в целом. Например, основной прецедент в работе банка - это обраб
отка займов.
3. Прецеденты предполагают взаимодействие актеров и системы. А
ктер представляет собой логически связанное множество ролей, кот
орые играют пользователи прецедентов во время взаимодействия с
ними.

25.

Вопросы для самоподготовки:
1. Понятие жизненного цикла ПО И
С?
2. Процессы жизненного цикла? ос
новные, вспомогательные, организ
ационные.
3. Модели жизненного цикла?
25

26.

Литература и ссылки на интерне
т
р е с у р с ы :
1. Леффингуал, Дин, Ундри, Дон. Прин
ципы работы с требованиями к ПО. Уни
фицированный подход. М., 2002г.
2. У. Боггс, М. Боггс. UML, Rational Rose
. М., ЛОРИ, 2000 г.
Сэм Канер и др. Тестирования програ
ммного обеспечения. Киев, 2000 г.
26