Спиральная модель жизненного цикла

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РФ

ФГБОУ ВО Уральский государственный экономический университет

Кафедра бизнес-информатики

Реферативное сообщение по дисциплине «Управление жизненным циклом информационных систем»

СПИРАЛЬНАЯ МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА

Направление: Бизнес-информатика

Исполнители:

Харитонов Д., Жданов В.

Группа: БИ-16-1

Екатеринбург, 2019

Содержание

• Введение
• 1. Жизненный цикл АИС
• 1.1 Понятие, структура и этапы жизненного цикла
• 1.2 Модели жизненного цикла АИС
• 2. Спиральная модель жизненного цикла
• 3. Сильные и слабые стороны спиральной модели
• 4. Распространение спиральной модели ЖЦ
• Заключение
• Список источников
• Приложение

Введение

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

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

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

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

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

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

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

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

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

1.1 Понятие, структура и этапы жизненного цикла

Жизненный цикл автоматизированных информационных систем - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации [8].

Основным нормативным документом, регламентирующим ЖЦ, является международный стандарт ISO/IEC 12207:1995 - «Информационные технологии - Процессы жизненного цикла программ» (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electro technical Commission -Международная комиссия по электротехнике).

Структура ЖЦпо стандарту ISO/IEC 12207 базируется на трех группах процессов (Рисунок 1):

Рисунок 1 - Структурная схема терминов

- основные процессы ЖЦ (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

- организационные процессы(управление проектами, создание инфраструктуры проекта, улучшение самого ЖЦ, обучение) [4].

Стадии жизненного цикла информационной системы [12]:

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

? сбор материалов для проектирования;

? анализ материалов и разработка документации, обязательно дается технико-экономическое обоснование с техническим заданием на проектирование ИС.

2. Проектирование:

2.1 предварительное проектирование;

? выбор проектных решений по аспектам разработки ИС;

? описание реальных компонент ИС;

? оформление и утверждение технического проекта (ТП).

2.2 детальное проектирование:

? выбор или разработка математических методов или алгоритмов программ;

? корректировка структур БД;

? создание документации на доставку и установку программных продуктов;

? выбор комплекса технических средств с документацией на ее установку.

2.3 разработка техно-рабочего проекта ИС (ТРП).

2.4 разработка методологии реализации функций управления с помощью ИС и описанием регламента действий аппарата управления.

3. Разработка ИС:

? получение и установка технических и программных средств;

? тестирование и доводка программного комплекса;

? разработка инструкций по эксплуатации программно-технических средств.

4. Ввод ИС в эксплуатацию:

? ввод технических средств;

? ввод программных средств;

? обучение и сертификация персонала;

? опытная эксплуатация;

? сдача и подписание актов приемки-сдачи работ.

5. Эксплуатация ИС:

? повседневная эксплуатация;

? общее сопровождение всего проекта.

6. Вывод из эксплуатации ИС

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

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

К настоящему времени наибольшее распространение получили следующие модели (стратегии) жизненного цикла [5]:

? каскадная модель - предлагает переход на следующие этапы после полного осуществления работ по предыдущему этапу. Модель демонстрирует классический подход в любых прикладных областях (Рис. 2);

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

? спиральная модель - данная модель делает упор на начальные этапы анализа и проектирования. Эта модель представляет собой итерационный процесс разработки, где каждая итерация (цикл), представляет собой законченный цикл разработки, приводящий к выпуску версии изделия (версии проекта ИС), который совершенствуется от итерации к итерации, чтобы стать значимой информационной системой [1]. При этом каждый виток спирали соответствует поэтапной модели создания информационной системы (Рисунок 4).

Рисунок 2 - Каскадная модель

Рисунок 3 - Итерационная модель

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



Рисунок 4 - Спиральная модель

2. Спиральная модель жизненного цикла

Спиральная модель была предложена Барри Боэмом профессором инженерии программного обеспечения в 1986 году и по масштабам того времени стала прорывом в понимании природы разработки ПО [3].

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

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

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

Для лучшего понимая механизма разработки рассмотрим схему (Рисунок 5):

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

Четыре главные фазы это:



Рисунок 5 - Подробная схема спиральной модели

1. Определение целей, альтернатив, ограничений, или фаза планирования. С этой стадии начинается работа над проектом. Команда разработчиков формулирует цели проекта, основные требования (такие как, например, Business Requirement Specifications, или BRS, System Requirement Specifications, или SRS), возможный дизайн и т.д. На последующих спиралях требования формируются согласно отзывам, полученным от заказчика [1]. Именно поэтому постоянная коммуникация между заказчиком и командой крайне важна.

2. Анализ, определение и разрешение рисков является одной из самых значимых стадий разработки. В данном контексте, риски -- это возможные события и состояния проекта, препятствующие достижению командой разработчиков поставленных целей. Существует довольно обширный диапазон возможных рисков, от тривиальных и легко преодолимых, до крайне серьезных. Главной задачей для команды разработчиков является выявление всех возможных рисков и присвоение им определенного уровня приоритета на основе их значимости [3]. Следующим шагом является разработка возможных стратегий преодоления этих рисков. В итоге этих действий возможны изменения в последующих стадиях разработки. В качестве результата работы на этом этапе создается прототип.

3. Фаза разработки. На этом этапе происходит разработка и последующее тестирование продукта. Во время первой итерации, когда общие требования еще не так четко сформулированы, разрабатывается так называемый концепция будущего продукта (Proof Of Concept), которая необходима для получения отзыва заказчика. На последующих витках спирали рабочие версии продукта, или билды (builds), отправляются заказчику [10]. Это позволяет получить более детальный отзыв и четче сформулировать требования.

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

Спиральную модель часто называют метамоделью, поскольку в ней используются два подхода: каскадная модель и модель прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого программного продукта [2]. Создание прототипов осуществляется за несколько итераций, или витков спирали. Но крайне важно понимать, что спиральная модель не является простой последовательностью этапов разработки, следующих каскадной модели. На самом деле, спиральная модель является довольно гибкой. Стоит помнить, что схема, приведенная выше содержит определенные упрощения. Может показаться, что все стадии следуют одной спиральной последовательности. Но реальный жизненный цикл ПО более гибкий, чем это изображено на схеме. Существует даже возможность вернуться к предыдущим фазам в случае необходимости пересмотра принятых решений [6].

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

3. Сильные и слабые стороны спиральной модели

У любой модели разработки ПО есть свои сильные и слабые стороны. В этом отношении спиральная модель не является исключением. Давайте рассмотрим ее основные достоинства и недостатки.

Достоинства:

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

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

3. Изменения могут быть внесены на поздних стадиях разработки;

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

5. Строгий контроль над документацией, как результат постоянного анализа рисков [11].

Недостатки:

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

2. Большое количество промежуточных стадий разработки. Как следствие -- большой объем документации;

3. На самых ранних стадиях дата завершения работы над проектом может быть неизвестна, что также усложняет контроль над процессом разработки [11].

4. Распространение спиральной модели ЖЦ

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

Рисунок 6 - Улучшенная спиральная модель с указанием вспомогательных процессов.

В отличии от ранее рассмотренной спиральной модели эта модель использует каскадный подход на завершающих этапах разработки программного продукта [5].

Использование спиральной модели целесообразно, если существует хотя бы одна из следующих причин:

? целесообразно создание прототипа;

? организация обладает навыками, требуемыми для адаптации модели;

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

? требования слишком сложные; проект очень большой.

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

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

- когда организация обладает навыками, требуемыми для адаптации модели;

- для проектов, выполнение которых сопряжено со средней и высокой степенью риска;

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

- когда речь идет о применении новой технологии и когда необходимо протестировать базовые концепции;

- при разработке новой функции или новой серии продуктов;

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

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

- в случае больших проектов;

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

- при выполнении затянувшихся проектов, которые могут вызывать раздражение у менеджеров и заказчиков [9];

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

- с целью демонстрации качества и достижения целей за короткий период времени;

- когда в процесс вовлекаются новые технологии, такие как впервые применяемые объектно-ориентированные принципы;

- при разработке систем, требующих большого объема вычислений, таких как систем, обеспечивающих принятие решений;

- при выполнении бизнес-проектов, а также проектов в области аэрокосмической промышленности, обороны и инжиниринга, где использование спиральной модели уже получило популярность [7].

информационный программный спиральный цикл

Заключение

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

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

Список источников

1. Richard W. Selby.Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Management, and Research.-- John Wiley & Sons, 2007-06-04.-- 834с.

2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2000. - 352с.

3. Гагарина Л.Г. Основы технологии и разработки программных продуктов: Учебник - М ФОРУМ - ИНФРА - М. 2006.

4. Канер С., Фолк Д., Кен Нгуен Е. Тестирование программного обеспечения: Пер. с англ. - Киев: ДиаСофт, 2000. - 544с.

5. Семенов М.И. Трубилин И.Т., Лойко В.И. Барановская Т.П. Архитектура компьютерных систем и сетей Учебное пособие - М Финансы и статистика, 2004. - 320с.

6. Советов Б.Я. Цеханковский В.В. Информационные технологии - М Высшая школа, 2003.

7. Соммервилл И. Инженерия программного обеспечения. - М.: СПБ.: Киев: Изд. дом «Вильямс», 2002. - 624.

8. Фридман А.Л. Основы объектно-ориентированной разработки программных систем. - М.: Финансы и статистика, 2000. - 200с.

9. Информатика: Учебник под редакцией Макаровой Н.В. - М.:Финансы и статистика., 2005. - 480с.

10. Официальный сайт xbsoftware.ru

11. Официальный сайт qalight.com.ua

12. Официальный сайт studfiles.net

13. Официальный сайт studopedia.org

Приложение 1

Спиральная модель на примере GanttPRO

В качестве примера применения на практике спиральной модели, рассмотрим GanttPRO -- приложение для удобного управления проектами и задачами.

Команда разработчиков XBSoftware применяла принципы спиральной модели, а также принципы Scrum. Например, были выбраны более короткие периоды релизов с целью более частого получения отзывов. Также был создан довольно детальный план того, что должно быть реализовано на самой первой итерации. Прочие требования были задокументированы в бэклоге или дорожной карте.

Основными задачами, с которыми столкнулась команда разработчиков GanttPRO были:

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

- Необходимость анализа и управления рисками являлась важной стадией спиральной модели

- Возможность возникновения достаточно большого количества новых рисков на протяжении процесса разработки

- Возможное увеличение затрат, вызванное долгим периодом планирования и дальнейшего дизайна, разработки и внедрения

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

Процесс разработки состоял из следующих стадий:

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

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

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

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

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

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

Приложение 2

Сравнительная таблица моделей жизненного цикла

Размещено на Allbest.ru

...