Программные документы по фазам жизненного цикла. Лекция 3

1.

Лекция 3.
Программные документы по
фазам жизненного цикла
1. Методологические основы проектирования ИC.
2. Жизненный цикл информационной системы.
3. Модели жизненного цикла ИС.
4. Каскадная модель жизненного цикла.
5. Итеративные или инкрементальные модели.
6. Спиральная модель жизненного цикла.
7. Состав программных документов по фазам жизненного
цикла

2.

Методологические основы
проектирования ИC

3.

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

4.

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

5.

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

6.

7.

Проектирование ИС охватывает три основные
области:
1. проектирование объектов данных, которые
будут реализованы в базе данных (БД);
2. проектирование программ, экранных форм,
отчетов, которые будут обеспечивать выполнение
запросов к данным;
3. учет конкретной среды или технологии, а
именно: топологии сети, конфигурации аппаратных
средств, используемой архитектуры (файл- сервер
или клиент-сервер), параллельной обработки,
распределенной обработки данных и т.п.

8.

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

9.

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

10.

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

11.

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

12.

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

13.

Жизненный цикл
информационной
системы

14.

Жизненный цикл ИС в общем случае начинается
в момент принятия решения о ее создании и
заканчивается в момент выведения ее из
эксплуатации.
Существует несколько вариантов жизненного
цикла ИС, подразделяемого на различные стадии,
например:
• ГОСТ 34.601-90
• ISO/IEC 12207:1995
• Rational Unified Process (RUP)
• Microsoft Solution Framework (MSF)
• и др.).

15.

Жизненный цикл ИС в общем случае начинается
в момент принятия решения о ее создании и
заканчивается в момент выведения ее из
эксплуатации.
Существует несколько вариантов жизненного
цикла ИС, подразделяемого на различные стадии
(например, ГОСТ 34.601-90, ISO/IEC 12207:1995.
Rational Unified Process (RUP), Microsoft Solution
Framework (MSF) и др.).

16.

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

17.

Предпроектная
стадия
• Обследование объекта и обоснование
необходимости создания ИС
• Формирование требований пользователя к ИС
Стадия
проектирования
• Разработка эскизного проекта
• Разработка рабочего проекта
Стадия
разработки
• Разработка приложений
• Тестирование
• Подготовка рабочей документации
Стадия внедрения
• Опытная эксплуатация
• Обучение пользователей
Стадия
промышленной
эксплуатации
• Эксплуатация и сопровождение
Стадия
модернизации
(утилизации)
• Внесение изменений или выведение из
эксплуатации и утилизация

18.

19.

20.

21.

22.

23.

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

24.

Жизненный цикл проекта — это совсем не то
же самое, что жизненный цикл продукта.
Есть различные методы разработки, которые
по-разному смотрят на практики жизненного цикла
проекта.
Надо помнить, что есть фазы (стадии) жизни
системы и есть практики работы, и все эти циклы поразному с этим работают.

25.

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

26.

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

27.

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

28.

2. Проектирование и разработка ИС.
Создается организационная и функциональная
структура управления. Проектируется
функциональное обеспечение (подсистемы и
комплексы задач) и обеспечивающие
(техническое, математическое, программное,
правовое, информационное) компонентов. Далее
указанные компоненты разрабатываются.
3. Внедрение ИС. Занимает длительное время,
разбивается на опытную и промышленную
эксплуатацию.
4. Сопровождение и развитие ИС. Наиболее
длительный этап в ЖЦ. В процессе эксплуатации
осуществляется регистрация ошибок, проводится
экспертиза проектных решений, формируются
требования к модификации ИС.

29.

Модели жизненного
цикла ИС

30.

Существующие модели жизненного цикла
определяют порядок исполнения этапов в ходе
разработки, а также критерии перехода от этапа к
этапу.
1. Каскадная модель жизненного цикла.
2. Итеративные или инкрементальные модели.
3. Спиральная модель жизненного цикла.

31.

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

32.

Waterfall (каскадный)

33.

34.

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

35.

36.

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

37.

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

38.

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

39.

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

40.

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

41.

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

42.

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

43.

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

44.

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

45.

3. Incremental
(итеративный/инкрементальный)

46.

47.

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

48.

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

49.

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

50.

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

51.

Spiral (спиральный)

52.

Автор: Барри Боэм (Barry Boehm)
модифицировал каскадную модель: разделил
практики деятельности и стадии жизни системы.
Есть фазы:
• одна фаза концептуального проектирования
• фаза разработки системы
• фаза совершенствования системы
• фаза расширения
• фазы эксплуатации.
На всех этих фазах применяются одни и те же
практики (общение с заказчиками, планирование,
анализ рисков и т. д).

53.

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

54.

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

55.

56.

Основные работы, выполняемыми на стадиях и
этапах разработки и внедрения АИС:
I стадия — предпроектное обследование:
1-й этап — Изучение экономического объекта. Дается
полная характеристика предприятия: основная
деятельность, основные фонды, контрагенты,
материально-техническая база, т.д.
2-й этап — сбор материалов для проектирования —
формирование требований, изучение объекта
проектирования, разработка и выбор варианта
концепции системы;
3-й этап — анализ материалов и формирование
документации — создание и утверждение техникоэкономического обоснования и технического задания
на проектирование системы на основе анализа
материалов обследования, собранных на первом
этапе.

57.

II стадия — проектирование:
1-й этап — техническое проектирование, где
ведется поиск наиболее рациональных проектных
решений по всем аспектам разработки, создаются и
описываются все компоненты системы, а результаты
работы отражаются в техническом проекте;
2-й этап — рабочее проектирование, в процессе
которого осуществляется разработка и доводка
программ, корректировка структур баз данных,
создание документации на поставку, установку
технических средств и инструкций по их
эксплуатации, подготовка для каждого пользователя
системы обширного инструкционного материла,
оформленного в виде должностных инструкций
исполнителям-специалистам, реализующим свои
профессиональные функции с использованием
технических средств управления. Технический и
рабочий проекты могут объединяться в единый
документ — технорабочий проект.

58.

III стадия — ввод системы в действие:
1-й этап — подготовка к внедрению — установка и
ввод в эксплуатацию технических средств, загрузка баз
данных и опытная эксплуатация программ, обучение
персонала;
2-й этап — проведение опытных испытаний всех
компонентов системы перед передачей в промышленную
эксплуатацию, обучение персонала;
3-й этап (завершающая стадия создания АИС и АИТ) —
сдача в промышленную эксплуатацию; оформляется
актами приема-сдачи работ.
IV стадия — промышленная эксплуатация —
кроме повседневного функционирования включает
сопровождение программных средств и всего проекта,
оперативное обслуживание и администрирование баз
данных.

59.

Состав программных
документов по фазам
жизненного цикла

60.

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

61.

Эксплуатация
• программный код;
• тесты и тестовые прогоны программы;
• требования, процедуры и условия сертификации
продукта.

62.

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