WikiSort.ru - Программирование

ПОИСК ПО САЙТУ | о проекте
Разработка программного обеспечения
Процесс разработки ПО
Ключевые процессы
Анализ  Проектирование  Программирование  Документирование  Тестирование
Модели
Итеративная  Спиральная  Каскадная  V-Model  Dual Vee Model
Методологии
Agile (XP, Lean, Scrum, FDD и др.)  Cleanroom  OpenUP  RAD  RUP  MSF  DSDM  TDD  BDD
Сопутствующие дисциплины
Конфигурационное управление  Управление проектами  Управление требованиями  Обеспечение качества

Процесс разработки программного обеспечения (англ. software development process, software process) — структура, согласно которой построена разработка программного обеспечения (ПО)[источник не указан 638 дней].

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

Шаги процесса

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

Модели процесса

Водопадная (каскадная, последовательная) модель

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

Этапы проекта в соответствии с каскадной моделью:

  1. Формирование требований;
  2. Проектирование;
  3. Реализация;
  4. Тестирование;
  5. Внедрение;
  6. Эксплуатация и сопровождение.

Преимущества:

  • Полная и согласованная документация на каждом этапе;
  • Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы[1]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем[2].

Итерационная модель

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью[3].

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и того же смысла разными словами со слегка разных точек зрения[2].

По выражению Т. Гилба, «эволюция — приём, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»[3].

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже»[2].

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

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

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

  • риск превышения сроков и стоимости проекта;
  • необходимость выполнения ещё одной итерации;
  • степень полноты и точности понимания требований к системе;
  • целесообразность прекращения проекта.

Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID[2].

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

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

В сегодняшней спиральной модели определён следующий общий набор контрольных точек[4]:

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

Примечания

  1. Брукс Ф. Мифический человеко-месяц или как создаются программные системы : пер. с англ. / Ф. Брукс. — Санкт-Петербург : Символ-Плюс, 1999. — 304 с.: ил.
  2. 1 2 3 4 Мирошниченко Е. А. Технологии программирования: учебное пособие / Е. А. Мирошниченко. — 2-е изд., испр. и доп. — Томск: Изд-во Томского политехнического университета, 2008. — 128 с.
  3. 1 2 Ларман К. Итеративная и инкрементальная разработка: краткая история / К. Ларман, В. Базили // Открытые системы. — 2003.— N 9.
  4. Орлик С. Введение в программную инженерию и управление жизненным циклом ПО.

Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".

Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.

Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .




Текст в блоке "Читать" взят с сайта "Википедия" и доступен по лицензии Creative Commons Attribution-ShareAlike; в отдельных случаях могут действовать дополнительные условия.

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

2019-2024
WikiSort.ru - проект по пересортировке и дополнению контента Википедии