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

Спиральная модель (представлена на рисунке 4) была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.

Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков (используется с разрешения автора):

1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. “Разрыв” в квалификации специалистов разных областей знаний.

Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму
(используется с разрешения автора)
[Boehm, 1988]

Сам Барри Боэм так характеризует спиральную модель разработки (используется с разрешения автора):

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

Спиральная модель обладает рядом преимуществ:

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

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

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

Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта. Это достигается явно определенными работами по анализу рисков, проверке различных характеристик создаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше на каждом “цикле” процесса разработки.

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

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

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

Описывая созданную спиральную модель, Боэм обращает внимание на то, что обладая явными преимуществами по сравнению с другими взглядами на жизненный цикл, необходимо уточнить, детализировать шаги, т.е. циклы спиральной модели для обеспечения целостного контекста для всех лиц, вовлеченных в проект (Боэм это формулирует так: “ Needforfurtherelaborationofspiralmodelsteps. In general, the spiral model process steps need further elaboration to ensure that all software development participants are operating in a consistent context.”). Организация ролей (ответственности членов проектной команды), детализация этапов жизненного цикла и процессов, определение активов (артефактов), значимых на разных этапах проекта, практики анализа и предупреждения рисков – все это вопросы уже конкретного процессного фреймворка или, как принято говорить, методологии разработки.

Действительно, детализация процессов, ролей и активов – вопрос методологии. Однако, рассматривая (спиральная) модель разработки, являясь концептуальным взглядом на создание продукта, требует, как и в любом проекте, определения ключевых контрольных точек проекта - milestones. Это, в большой степени, связано с попыткой ответить на вопрос “где мы?”. Вопрос, особенно актуальный для менеджеров и лидеров проектов, отслеживающих ход их выполнения и планирующих дальнейшие работы.

В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели и, в частности, построенного на его основе подхода MBASE - Model-Based (System) Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых характеристик или практик, обеспечивающих успешное применение спиральной модели:

1. Параллельное, а не последовательное определение артефактов (активов) проекта
2. Согласие в том, что на каждом цикле уделяется внимание::
• целям и ограничениям, важным для заказчика
• альтернативам организации процесса и технологических решений, закладываемых в продукт
• идентификации и разрешению рисков
• оценки со стороны заинтересованных лиц (в первую очередь заказчика)
• достижению согласия в том, что можно и необходимо двигаться дальше
3. Использование соображений, связанных с рисками, для определения уровня усилий, необходимого для каждой работы на всех циклах спирали.
4. Использование соображений, связанных с рисками, для определения уровня детализации каждого артефакта, создаваемого на всех циклах спирали.
5. Управление жизненным циклом в контексте обязательств всех заинтересованных лиц на основе трех контрольных точек:
• Life Cycle Objectives (LCO)
• Life Cycle Architecture (LCA)
• Initial Operational Capability (IOC)
6. Уделение специального внимания проектным работам и артефактам создаваемой системы (включая непосредственно разрабатываемое программное обеспечение, ее окружение, а также эксплуатационные характеристики) и жизненного цикла (разработки и использования).

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

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

• Concept of Operations (COO) – концепция <использования> системы;
• Life Cycle Objectives (LCO) – цели и содержание жизненного цикла;
• Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
• Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации;
• FinalOperationalCapability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Таким образом, мы приходим к возможному современному взгляду (см., например, представление спиральной модели в [Фатрелл, Шафер и Шафер, 2003, с.159]) на итеративный и инкрементальный – эволюционный жизненный цикл в форме спиральной модели, изображенной на рисунке 5.

Рисунок 5. Обновленная спиральная модель c контрольными точками проекта.
(данное представление создано Сергеем Орликом
на основе оригинальной модели Боэма и ее модификациях)

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

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

• Rational Unified Process (RUP)
• Enterprise Unified Process (EUP)
• Microsoft Solutions Framework (MSF) в обоих представлениях: MSF for Agile и MSF for CMMI (анонсированная изначально как “MSF Formal”)
• Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), SCRUM,...).

Дополнительная библиография

[Ambler, 2004] - Scott W. Ambler. One Piece at a Time.
Software Development Magazine, December 2004.
http://www.sdmagazine.com/

[Ambler, 2005] - Scott W. Ambler, John Nalbone, Michael J. Vizdos. The Enterprise Unified Process: Extending the Rational Unified Process.
Prentice Hall PTR (ISBN 0-13-191451-0) 2005

[APM PMBoK, 2000] - Project Management Body of Knowledge. Fourth Edition.
Association of Project Management, 2000.
http://www.apm.org.uk/

[Boehm, 1988] – Barry W. Boehm. A Spiral Model of Software Development and Enhancement, Computer, May 1988, pp. 61-72.
http://www.computer.org/computer/homepage/misc/Boehm/index.htm

[Boehm, 2000] – Barry W. Boehm. Spiral Development: Experience, Principles, and Refinements. Spiral Experience Workshop, February 9, 2000 / Special Report
CMU/SEI-2000-SR-008, July, 2000.
http://www.sei.cmu.edu/cbs/spiral2000/Boehm

[Chaos, 2004] – CHAOS Research Results. 2004 Third Quarter Research Report.
The Standish Group International, Inc., 2004.

[CMMI 1.1, 2002] - Capability Maturity Model Integration, Version 1.1. [CMMI 1.1, 2002] - Capability Maturity Model Integration, Version 1.1. CMMISM for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1).
Software Engineering Institute (SEI), Carnegie Mellon University (CMU), 2002.
http://www.sei.cmu.edu/cmmi/

[DeMarco, 1999] – The Paradox of Software Architecture and Design”, Stevens Prize Lecture, August, 1999.
[E-Gov, 2002] – E-Gov Enterprise Architecture Guidance (Common Reference Model), FEA Working Group (Draft), July 25, 2002].
http://www.feapmo.gov/resources/E-Gov_Guidance_Final_Draft_v2.0.pdf

[Fred Brooks, 1987] – Классическая статья Фреда Брукса (Frederick P. Brooks, Jr.), заставившая по-новому взглянуть индустрию программного обеспечения на самою себя. - No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, April, 1987.
http://www.computer.org/computer/homepage/misc/Brooks/

[PMBOK US DoD Ext, 2003] - U.S. Department of Defense (DoD) Extension to: A Guide to the Project Management Body of Knowledge (PMBOK Guide). First Edition, Version 1.0. PMI Standard.
The Defense Acquisition University (DAU), June, 2003.
http://www.dau.mil/pubs/gdbkspmbok.asp

[PMI PMBOK, 2000] – A Guide to the Project Management Body of Knowledge. (PMBOK® Guide). Second Edition.
Project Management Institute, Inc., 2000.
http://www.pmi.org/

[PMI PMBOK3, 2004] – A Guide to the Project Management Body of Knowledge. (PMBOK® Guide). Third Edition.
Project Management Institute, Inc., 2004.
http://www.pmi.org/

[PMI PMBOK3, 2004, Рус] – Руководство к Своду знаний по управлению проектами. (Руководство PMBOK®). Третье издание. Издание на русском языке.
Project Management Institute, Inc., 2004.
http://www.pmi.org/

[PMI WBS, 2001] - Practice Standard for Work Breakdown Structures.
Project Management Institute, Inc., 2001.
http://www.pmi.org/

[SE, 2004] - Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering. A Volume of the Computing Curricula Series.
The Joint Task Force on Computing Curricula, IEEE Computer Society, Association for Computing Machinery, August 23, 2004.
http://sites.computer.org/ccse/

[SWEBOK, 2004] - Guide to Software Engineering Base of Knowledge (SWEBOK).
IEEE Computer Society, 2004.
http://www.swebok.org/

[TOGAF, 2003] – The Open Group Architecture Framework (TOGAF). Version 8.1
The Open Group, 2003.
http://www.opengroup.org/architecture/togaf8/index8.htm

[Zachman] – The Zachman Framework for Enterprise Architecture, John A. Zachman, ZIFA - Zachman Institute for Framework Advancement.
http://www.zifa.com

[Амблер, 2002] – Скотт Амблер. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки.
Wiley (ISBN 0-471-20282-7), 2002 - Scott W. Ambler, Agile Modeling: Effective Practices for Extreme Programming, 2002; перевод и издание на русском языке: ЗАО Издательский дом “Питер” (ISBN 5-94723-545-5), 2005

[Арчибальд, 2003] – Рассел Д. Арчибальд. Управление высоко-технологичными программами и проектами. Издание третье, переработанное и дополненное.
John Wiley & Sons, Inc. (ISBN 0-471-26557-8) 1976 – Russel D. Archibald, 2003; перевод и издание на русском языке: АйТи (ISBN 5-98453-002-3) - ДМК Пресс (ISBN 5-94074-214-9) 2004.

[Арчибальд, 2005] – Рассел Д. Арчибальд. Искусство управления проектами: состояние и перспективы. Возможности и уровень зрелости организации в управлении проектами.
Информационно-аналитический журнал “Управление проектами”, N1 (1), март 2005, стр. 14-23.
http://www.pmmagazine.ru

[Брукс, 1995] – Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы. 2-е издание, юбилейное.
Addison-Wesley Longman, Inc. (ISBN 0-201-83595-9), 1995.
Издательство Символ-Плюс (ISBN 5-93286-005-7), 2000, 2005.

[Вигерс, 2003] – Карл И. Вигерс. Разработка требований к программному обеспечению.
Издательско-торговый дом “Русская редакция”, перевод на русский язык второй редакции книги – Microsoft Corporation (ISBN 5-7502-0240-2), 2004.
Оригинальное издание на английском языке: Software Requirements. Second Edition.
Karl E. Wiegers, Microsoft Press (ISBN 0-7356-1879-8), 2003.

[Грей и Ларсон, 2003] – Клиффорд Ф. Грей, Эрик У. Ларсон. Управление проектами: Практическое русководство.
Издательство “Дело и Сервис” (ISBN 5-8018-0152-9), 2003.
The McGraw-Hill Companies, Inc. (ISBN 0-07-365812-X), 2000.

[ГОСТ 12207, 1999] – Информационная технология. Процессы Жизненного Цикла Программных Средств. ГОСТ Р ИСО/МЭК 12207-99, Государственный Стандарт Российской Федерации, 1999.
Госстандарт России, Москва, 2000.

[ГОСТ 34, 1990] – Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Термины и определения. ГОСТ 34.003-90, Государственный Стандарт Российской Федерации, 1999.
Госстандарт России, Москва, 1990.

[Кантор, 2002] – Марри Кантор. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения.
Издательский дом “Вильямс” (ISBN 5-8459-0294-0), 2002.
Addison Wesley (ISBN 0-2017-0044-1), 2002.

[СОВНЕТ НТК, 2000] - Национальные требования к компетентности специалистов по Управлению Проектами (НТК).
Ассоциация по Управлению Проектами СОВНЕТ, 2000.
http://www.sovnet.ru/ntk2000/index.php

[Соммервилл, 2000] – Иан Соммервилл. Инженерия программного обеспечения. 6-е издание.
Издательский дом “Вильямс” (ISBN 5-8459-0330-0), 2002.
Addison Wesley (ISBN 0-201-39815-X), 2001.

[Товб А., Ципес Г., 2003] – А.С. Товб, Г.Л. Ципес. Управление проектами: стандарты, методы, опыт. Второе издание.
Товб А.С., Ципес Г.Л., 2003 – ЗАО “Олимп-Бизнес” (ISBN 5-9693-0038-1) 2003, 2005.

[Фатрелл, Шафер и Шафер, 2003] – Роберт Т. Фатрелл, Дональд Ф. Шафер, Линда И. Шафер. Управление программными проектами: достижение оптимального качества при минимуме затрат.
Издательский дом “Вильямс” (ISBN 5-8459-0413-7), 2003.
Addison-Wesley Publishing Company, Inc. (ISBN 0-13-091297-2), 2002.

[Фаулер, 2004] – Мартин Фаулер. UML. Основы. Краткое руководство по стандартному языку объектного моделирования. 3-е издание.
Издательство “Символ-Плюс” (ISBN 5-93286-060-X), Санкт-Петербург, 2004.

Дата добавления: 2014-10-22