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

Лекция 3. Управление жизненным циклом информационных систем

Основные понятия управления информационными проектами
Роль стандартов в жизненном цикле информационных систем
Модели жизненного цикла информационных систем

1

Основные понятия управления информационными проектами

Проектирование КИС— это процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части

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

2

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

3

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

4

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

5

Роль стандартов в жизненном цикле информационной системы

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

6

В настоящее время концепция жизненного цикла в практике использования информационных технологий/информационных систем в Российской Федерации представлена следующими стандартами:
ГОСТ Р ИСО/МЭК 12207-2010 «Информационная техно-логия. Системная и программная инженерия. Процессы жизненного цикла программных средств» (ISO/IEC/IEEE 12207:2017 System and software engineering — Software life cycle processes»);
ГОСТ Р 57193-2016 «Системная и программная инженерия. Процессы жизненного цикла систем» («ISO/IEC/IEEE 15288:2015 System and software engineering — System life cycle processes»);
ГОСТ 34.601-90 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии со-здания».

7

8

Согласно ГОСТ Р ИСО/МЭК 12207—2010 выделяются следующие критерии для процессов жизненного цикла:
1. Стандарт устанавливает структуру работ в пределах жизненного цикла программных средств. Жизненный цикл начинается от замысла или потребности, которая может быть удовлетворена программным средством полностью или частично, и завершается прекращением применения этого программного средства.
2. Архитектура ПО создаётся совокупностью процессов и взаимосвязями между этими процессами. Определение процессов жизненного цикла основывается на двух базовых принципах — связности и ответственности.
3. Принцип связности: процессы жизненного цикла являются связными и соединяются оптимальным образом, считающимся практичным и выполнимым.
4. Принцип ответственности: процесс передается под ответственность какой-либо организации или стороне в пределах жизненного цикла программного средства.

9

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

10

11

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

12

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

13

14

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

15

16

17

18

19

Модели жизненного цикла информационных систем

Для каждой модели определена область применения, преимущества и недостатки. Были выделены следующие модели:
1) каскадная модель;
2) поэтапная модель с промежуточным контролем;
3) V-образная модель;
4) эволюционного прототипирования;
5) быстрой разработки приложений;
6) инкрементная
7) спиральная.

20

21

22

23

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

24

25

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

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

26

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

27

28

29

30

31