Процесс разработки программного обеспечения

В разработке программного обеспечения процесс разработки программного обеспечения или жизненный цикл разработки программного обеспечения — это процесс планирования и управления разработкой программного обеспечения . Обычно это предполагает разделение работы по разработке программного обеспечения на более мелкие, параллельные или последовательные этапы или подпроцессы для улучшения проектирования и/или управления продуктом . Методология может включать предварительное определение конкретных результатов и артефактов, которые создаются и завершаются командой проекта для разработки или поддержки приложения. ^[1]

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

«Модель» жизненного цикла иногда считается более общим термином для категории методологий, а «процесс» разработки программного обеспечения - это частный случай, принятый конкретной организацией. ^{[ нужна ссылка ]} Например, многие конкретные процессы разработки программного обеспечения соответствуют спиральной модели жизненного цикла. Эта область часто рассматривается как часть жизненного цикла разработки систем .

История

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

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

Планировка и дизайн: Как только требования понятны, команда разработчиков специального программного обеспечения приступает к созданию комплексного плана проекта. В этом плане изложена дорожная карта развития, включая сроки, распределение ресурсов и результаты. На этом этапе также определяются архитектура и дизайн программного обеспечения. Элементы дизайна пользовательского интерфейса (UI) и взаимодействия с пользователем (UX) призваны обеспечить удобство использования, интуитивность и визуальную привлекательность программного обеспечения.

Разработка: После планирования и проектирования команда разработчиков начинает процесс кодирования. Этот этап включает в себя написание , тестирование и отладку программного кода. Гибкие методологии, такие как Scrum или Kanban, часто используются для обеспечения гибкости, сотрудничества и итеративной разработки. Регулярное общение между командой разработчиков и клиентом обеспечивает прозрачность и позволяет быстро получать обратную связь и вносить коррективы.

Тестирование и гарантия качества: Чтобы гарантировать надежность, производительность и безопасность программного обеспечения, проводятся строгие процессы тестирования и обеспечения качества (QA). Для выявления и исправления любых проблем или ошибок используются различные методы тестирования, включая модульное тестирование, интеграционное тестирование, системное тестирование и пользовательское приемочное тестирование. Деятельность по обеспечению качества направлена на проверку программного обеспечения на соответствие заранее определенным требованиям, гарантируя, что оно работает так, как задумано.

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

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

1970-е годы

Структурированное программирование с 1969 года.
Cap Gemini SDM , родом из PANDATA, первый английский перевод был опубликован в 1974 году. SDM означает методологию разработки системы.

1980-е годы

1990-е годы

Объектно-ориентированное программирование (ООП) появилось в начале 1960-х годов и стало доминирующим подходом к программированию в середине 1990-х годов.
Быстрая разработка приложений (RAD), с 1991 г.
Метод разработки динамических систем (DSDM), с 1994 г.
Скрам , с 1995 года.
Командный процесс разработки программного обеспечения , с 1998 года.
Rational Unified Process (RUP), поддерживается IBM с 1998 года.
Экстремальное программирование , с 1999 года.

2000-е

Agile Unified Process (AUP), поддерживаемый с 2005 года Скоттом Эмблером.
Дисциплинированная гибкая доставка (DAD) заменяет AUP.

2010-е годы

Начиная с DSDM в 1994 году, все методологии из приведенного выше списка, за исключением RUP, были гибкими методологиями, однако многие организации, особенно государственные, до сих пор используют предгибкие процессы (часто каскадные или аналогичные). Процесс разработки и качество программного обеспечения тесно взаимосвязаны; На практике наблюдались некоторые неожиданные аспекты и эффекты. ^[3]

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

Прототипирование

Прототипирование программного обеспечения — это создание прототипов, то есть неполных версий разрабатываемой программы.

Основные принципы: ^[1]

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

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

Методологии

Гибкая разработка

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

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

Модель Agile также включает в себя следующие процессы разработки программного обеспечения:

Непрерывная интеграция

Непрерывная интеграция — это практика объединения всех рабочих копий разработчиков в общую основную линию несколько раз в день. ^[4]Грэди Буч впервые назвал и предложил КИ в своем методе 1991 года . ^[5] хотя он и не выступал за интеграцию несколько раз в день. Экстремальное программирование (XP) приняло концепцию CI и выступало за интеграцию чаще одного раза в день — возможно, даже десятки раз в день.

Постепенное развитие

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

Существует три основных варианта поэтапного развития: ^[1]

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

Быстрая разработка приложений

Модель быстрой разработки приложений (RAD)

Быстрая разработка приложений (RAD) — это методология разработки программного обеспечения, которая благоприятствует итеративной разработке и быстрому созданию прототипов вместо большого объема предварительного планирования. «Планирование» программного обеспечения, разработанного с использованием RAD, чередуется с написанием самого программного обеспечения. Отсутствие тщательного предварительного планирования обычно позволяет писать программное обеспечение намного быстрее и упрощает изменение требований.

Процесс быстрой разработки начинается с разработки предварительных моделей данных и моделей бизнес-процессов с использованием структурированных методов . На следующем этапе требования проверяются с помощью прототипирования, что в конечном итоге позволяет уточнить модели данных и процессов. Эти этапы повторяются итеративно; Результатом дальнейшей разработки является «объединенное заявление бизнес-требований и технического проекта, которое будет использоваться для создания новых систем». ^[6]

Этот термин был впервые использован для описания процесса разработки программного обеспечения, введенного Джеймсом Мартином в 1991 году. По словам Уиттена (2003), это слияние различных структурированных методов управляемых данными , особенно разработки информационных технологий, , с методами прототипирования для ускорения разработки программных систем. . ^[6]

Основными принципами быстрой разработки приложений являются: ^[1]

Ключевой целью является быстрая разработка и поставка высококачественной системы при относительно низких инвестиционных затратах.
Попытки снизить присущий проекту риск путем разбиения проекта на более мелкие сегменты и обеспечения большей простоты внесения изменений в процессе разработки.
Нацелен на быстрое создание высококачественных систем, в первую очередь посредством итеративного прототипирования (на любой стадии разработки), активного участия пользователей и компьютеризированных инструментов разработки. Эти инструменты могут включать в себя конструкторы графического пользовательского интерфейса (GUI), инструменты автоматизированной разработки программного обеспечения (CASE), системы управления базами данных (СУБД), языки программирования четвертого поколения , генераторы кода и объектно-ориентированные методы.
Основной упор делается на удовлетворение потребностей бизнеса, тогда как технологическое или инженерное совершенство имеет меньшее значение.
Управление проектом включает в себя определение приоритетов разработки и определение сроков поставки или «временных рамок». Если проект начинает отставать, акцент делается на сокращении требований, чтобы соответствовать временным рамкам, а не на увеличении сроков.
Обычно включает в себя совместную разработку приложений (JAD), где пользователи активно участвуют в проектировании системы посредством достижения консенсуса либо на структурированных семинарах, либо при помощи электронного взаимодействия.
Активное участие пользователей является обязательным.
Итеративно создает производственное программное обеспечение, а не одноразовый прототип.
Создает документацию, необходимую для облегчения будущей разработки и обслуживания.
В эту структуру можно встроить стандартные методы системного анализа и проектирования.

Развитие водопада

Водопадная модель представляет собой последовательный подход к развитию, при котором развитие рассматривается как неуклонно нисходящее (как водопад) через несколько этапов, обычно:

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

Первое формальное описание метода часто цитируется как статья, опубликованная Уинстоном В. Ройсом. ^[7] в 1970 году, хотя Ройс не использовал в этой статье термин «водопад». Ройс представил эту модель как пример ошибочной, неработающей модели. ^[8]

Основные принципы: ^[1]

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

Водопадная модель — это традиционный инженерный подход, применяемый к разработке программного обеспечения. Строгий каскадный подход не поощряет повторное посещение и пересмотр любого предыдущего этапа после его завершения. ^{[ по мнению кого? ]} Эта «негибкость» чистой каскадной модели была источником критики со стороны сторонников других, более «гибких» моделей. Его широко обвиняли в том, что несколько крупномасштабных государственных проектов превысили бюджет, с течением времени и иногда не смогли выполнить требования из-за большого предварительного подхода к проектированию. ^{[ по мнению кого? ]} За исключением случаев, когда это требуется по контракту, каскадная модель была в значительной степени заменена более гибкими и универсальными методологиями, разработанными специально для разработки программного обеспечения. ^{[ по мнению кого? ]} См. Критика водопадной модели .

Спиральное развитие

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

Основные принципы: ^[1]

Основное внимание уделяется оценке рисков и минимизации рисков проекта путем разбиения проекта на более мелкие сегменты и обеспечения большей простоты внесения изменений в процессе разработки, а также предоставления возможности оценить риски и взвесить возможность продолжения проекта на протяжении всего жизненного цикла.
«Каждый цикл включает в себя выполнение одной и той же последовательности шагов для каждой части продукта и для каждого уровня его разработки, от общего концептуального документа до кодирования каждой отдельной программы». ^[9]
Каждое путешествие по спирали пересекает четыре основных квадранта: (1) определяет цели, альтернативы и ограничения итерации и (2) оценивает альтернативы; Выявлять и устранять риски; (3) разработать и проверить результаты итерации; и (4) спланировать следующую итерацию. ^[10]
Начинайте каждый цикл с определения заинтересованных сторон и их «условий победы» и заканчивайте каждый цикл анализом и принятием обязательств. ^[11]

Формируйтесь

Shape Up — это подход к разработке программного обеспечения, представленный Basecamp в 2018 году. Это набор принципов и методов, разработанных внутри компании Basecamp для решения проблемы, когда проекты затягиваются без четкого завершения. Его основная целевая аудитория — удаленные команды. В Shape Up нет оценки и отслеживания скорости, бэклогов или спринтов, в отличие от водопада , Agile или Scrum . Вместо этого эти концепции заменяются аппетитом, ставками и циклами. По состоянию на 2022 год, помимо Basecamp, известные организации, принявшие Shape Up, включают UserVoice и Block. ^[12]^[13]

Передовые методологии

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

Разработка, основанная на поведении , и управление бизнес-процессами. ^[14]
Модель хаоса . Главное правило всегда сначала решает самую важную проблему.
Методика поэтапного финансирования – итеративный подход
Облегченная методология — общий термин для методов, которые имеют лишь несколько правил и практик.
Метод структурированного системного анализа и проектирования — конкретная версия водопада
Медленное программирование, как часть более крупного «Медленного движения» , предполагает тщательную и постепенную работу без (или минимального) ограничения времени. Медленное программирование направлено на то, чтобы избежать ошибок и слишком быстрых графиков выпуска.
V-Model (разработка программного обеспечения) — расширение водопадной модели.
Unified Process (UP) — это методология итеративной разработки программного обеспечения, основанная на унифицированном языке моделирования (UML). UP разделяет разработку программного обеспечения на четыре этапа, каждый из которых состоит из одной или нескольких исполняемых итераций программного обеспечения на данном этапе разработки: создание, разработка, создание и рекомендации.

Метамодели процессов

Некоторые « модели процессов » представляют собой абстрактные описания для оценки, сравнения и улучшения конкретного процесса, принятого в организации.

ISO/IEC 12207 — это международный стандарт, описывающий метод выбора, внедрения и мониторинга жизненного цикла программного обеспечения.
( CMMI Интеграция модели зрелости возможностей ) является одной из ведущих моделей и основана на передовом опыте. Независимые оценки оценивают организации по тому, насколько хорошо они следуют установленным процессам, а не по качеству этих процессов или производимого программного обеспечения. CMMI заменил CMM .
ISO 9000 описывает стандарты формально организованного процесса производства продукции, а также методы управления и мониторинга прогресса. Хотя стандарт изначально был создан для производственного сектора, стандарты ISO 9000 применялись и к разработке программного обеспечения. Как и CMMI, сертификация по ISO 9000 не гарантирует качество конечного результата, а лишь соблюдение формализованных бизнес-процессов.
ISO/IEC 15504 Информационные технологии. Оценка процессов, также известная как «Определение возможностей улучшения процессов программного обеспечения» (SPICE), представляет собой «структуру для оценки процессов программного обеспечения». Целью настоящего стандарта является установление четкой модели для сравнения процессов. SPICE используется так же, как CMMI. Он моделирует процессы управления, контроля, направления и мониторинга разработки программного обеспечения. Затем эта модель используется для измерения того, что фактически делает организация-разработчик или проектная группа во время разработки программного обеспечения. Эта информация анализируется для выявления слабых мест и стимулирования улучшений. Он также определяет сильные стороны, которые можно продолжить или интегрировать в обычную практику этой организации или команды.
ISO/IEC 24744 Разработка программного обеспечения — метамодель для методологий разработки — это метамодель на основе типов мощности для методологий разработки программного обеспечения.
Методология мягких систем – общий метод совершенствования процессов управления.
Метод инженерии – общий метод улучшения процессов информационной системы.

На практике

За прошедшие годы появилось множество таких рамок, каждая из которых имеет свои признанные сильные и слабые стороны. Одна методологическая основа разработки программного обеспечения не обязательно подходит для использования во всех проектах. Каждая из доступных методологических рамок лучше всего подходит для конкретных типов проектов с учетом различных технических, организационных, проектных и командных соображений. ^[1]

См. также

Жизненный цикл разработки систем
Компьютерная разработка программного обеспечения (некоторые из этих инструментов поддерживают определенные методологии)
Список философий разработки программного обеспечения
Краткое описание разработки программного обеспечения
Управление программными проектами
Разработка программного обеспечения
Оценка усилий по разработке программного обеспечения
Жизненный цикл выпуска программного обеспечения
Проектирование сверху вниз и снизу вверх # Информатика

Ссылки

^ Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г «Выбор подхода к разработке» (PDF) . Офис информационной службы центров Medicare и Medicaid Services (CMS) . Министерство здравоохранения и социальных служб США (HHS). 27 марта 2008 г. [Первоначальный выпуск: 17 февраля 2005 г.]. Архивировано из оригинала (PDF) 20 июня 2012 года . Проверено 27 октября 2008 г.
^ Перейти обратно: ^а ^б Джеффри Эллиотт (2004). Глобальные информационные технологии бизнеса: интегрированный системный подход . Пирсон Образование. п. 87.
^ Сурьянараяна, Гириш (2015). «Процесс разработки и качество дизайна: перетягивание каната?» . Программное обеспечение IEEE . 32 (4): 7–11. дои : 10.1109/MS.2015.87 .
^ Пол М. Дюваль; Стив Матьяс; Эндрю Гловер (2007). Непрерывная интеграция: повышение качества программного обеспечения и снижение рисков . Аддисон-Уэсли Профессионал . ISBN 978-0-321-33638-5 .
^ Буч, Грейди (1991). Объектно-ориентированное проектирование: с приложениями . Бенджамин Каммингс . п. 209. ИСБН 9780805300918 . Проверено 18 августа 2014 г.
^ Перейти обратно: ^а ^б Уиттен, Джеффри Л .; Лонни Д. Бентли , Кевин С. Диттман . (2003). Системный анализ и методы проектирования . 6-е издание. ISBN 0-256-19906-X .
^ Маркус Рерих. «Модель водопада > контекст создания» . Институт проектирования и исследования воздействия Венского технического университета (на немецком языке) . Проверено 28 ноября 2007 г.
^ Конрад Вайсерт. «Методология водопада: такого не бывает!» . Архивировано из оригинала 2 августа 2022 года.
^ Барри Бём (август 1986 г.). «Спиральная модель разработки и улучшения программного обеспечения» . Заметки по разработке программного обеспечения ACM SIGSOFT . 11 (4). Ассоциация вычислительной техники : 14–24. дои : 10.1145/12944.12948 . S2CID 1781829 .
^ Ричард Х. Тайер; Барри В. Бём (1986). Учебное пособие: Управление проектами в области разработки программного обеспечения . Издательство компьютерного общества IEEE. п. 130.
^ Барри В. Бём (2000). Оценка стоимости программного обеспечения с помощью Cocomo II: Том 1 .
^ «Предисловие Джейсона Фрида | Придайте форму» . basecamp.com . Проверено 11 сентября 2022 г.
^ «Является ли Shape Up просто хорошей теорией?» . Любопытная лаборатория . Проверено 12 сентября 2022 г.
^ Любке, Даниэль; ван Лессен, Таммо (2016). «Моделирование тестовых примеров в BPMN для разработки, основанной на поведении». Программное обеспечение IEEE . 33 (5): 15–21. дои : 10.1109/MS.2016.117 . S2CID 14539297 .

Внешние ссылки

Выбор подхода к разработке на cms.hhs.gov.
Герхард Фишер, «Программные технологии XXI века: от повторного использования программного обеспечения к совместному проектированию программного обеспечения» , 2001 г.

[CMS08-1] Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г «Выбор подхода к разработке» (PDF) . Офис информационной службы центров Medicare и Medicaid Services (CMS) . Министерство здравоохранения и социальных служб США (HHS). 27 марта 2008 г. [Первоначальный выпуск: 17 февраля 2005 г.]. Архивировано из оригинала (PDF) 20 июня 2012 года . Проверено 27 октября 2008 г.

[Ell04-2] Перейти обратно: ^а ^б Джеффри Эллиотт (2004). Глобальные информационные технологии бизнеса: интегрированный системный подход . Пирсон Образование. п. 87.

[ieeesw-3] Сурьянараяна, Гириш (2015). «Процесс разработки и качество дизайна: перетягивание каната?» . Программное обеспечение IEEE . 32 (4): 7–11. дои : 10.1109/MS.2015.87 .

[CI0-4] Пол М. Дюваль; Стив Матьяс; Эндрю Гловер (2007). Непрерывная интеграция: повышение качества программного обеспечения и снижение рисков . Аддисон-Уэсли Профессионал . ISBN 978-0-321-33638-5 .

[5] Буч, Грейди (1991). Объектно-ориентированное проектирование: с приложениями . Бенджамин Каммингс . п. 209. ИСБН 9780805300918 . Проверено 18 августа 2014 г.

[WBD04-6] Перейти обратно: ^а ^б Уиттен, Джеффри Л .; Лонни Д. Бентли , Кевин С. Диттман . (2003). Системный анализ и методы проектирования . 6-е издание. ISBN 0-256-19906-X .

[7] Маркус Рерих. «Модель водопада > контекст создания» . Институт проектирования и исследования воздействия Венского технического университета (на немецком языке) . Проверено 28 ноября 2007 г.

[8] Конрад Вайсерт. «Методология водопада: такого не бывает!» . Архивировано из оригинала 2 августа 2022 года.

[BB86-9] Барри Бём (август 1986 г.). «Спиральная модель разработки и улучшения программного обеспечения» . Заметки по разработке программного обеспечения ACM SIGSOFT . 11 (4). Ассоциация вычислительной техники : 14–24. дои : 10.1145/12944.12948 . S2CID 1781829 .

[RT-BB86-10] Ричард Х. Тайер; Барри В. Бём (1986). Учебное пособие: Управление проектами в области разработки программного обеспечения . Издательство компьютерного общества IEEE. п. 130.

[11] Барри В. Бём (2000). Оценка стоимости программного обеспечения с помощью Cocomo II: Том 1 .

[12] «Предисловие Джейсона Фрида | Придайте форму» . basecamp.com . Проверено 11 сентября 2022 г.

[13] «Является ли Shape Up просто хорошей теорией?» . Любопытная лаборатория . Проверено 12 сентября 2022 г.

[ieeeswbdd-14] Любке, Даниэль; ван Лессен, Таммо (2016). «Моделирование тестовых примеров в BPMN для разработки, основанной на поведении». Программное обеспечение IEEE . 33 (5): 15–21. дои : 10.1109/MS.2016.117 . S2CID 14539297 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]