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

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Software development process" – news · newspapers · books · scholar · JSTOR (December 2010) (Learn how and when to remove this message)

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

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

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

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

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

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

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

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

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

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

1970-е

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

1980-е

• Метод структурного системного анализа и проектирования (SSADM) с 1980 года
• Анализ информационных требований/Методология мягких систем

1990-е

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

2000-е

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

2010-е

• Масштабируемая гибкая структура (SAFe)
• Масштабный Scrum (LeSS)
• DevOps

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

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

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

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

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

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

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

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

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

• Метод разработки динамических систем (DSDM)
• Канбан
• Скрам
• Бережливая разработка программного обеспечения

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

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

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

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

Быстрая разработка приложений (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-модель (разработка ПО) — расширение каскадной модели
• Unified Process (UP) — это итеративная методология разработки программного обеспечения, основанная на Unified Modeling Language (UML). UP организует разработку программного обеспечения в четыре фазы, каждая из которых состоит из одной или нескольких исполняемых итераций программного обеспечения на данном этапе разработки: начало, разработка, построение и рекомендации.

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

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

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

На Викискладе есть медиафайлы по теме «Методология разработки программного обеспечения» .

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