stringtranslate.com

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

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

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

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

История

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

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

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

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

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

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

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

1970-е
1980-е
1990-е
2000-е
2010-е

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

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

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

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

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

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

Методологии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Водопадное развитие

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

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

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

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

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

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

Спиральная модель (Бём, 1988)

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

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

Приведи себя в форму

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

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

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

Процесс метамоделей

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

На практике

Три основных подхода, применяемых к структурам методологии разработки программного обеспечения

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

Смотрите также

Ссылки

  1. ^ abcdefg "Выбор подхода к развитию" (PDF) . Центры Medicare и Medicaid Services (CMS) Office of Information Service . Министерство здравоохранения и социальных служб США (HHS). 27 марта 2008 г. [Первоначальный выпуск: 17 февраля 2005 г.]. Архивировано из оригинала (PDF) 20 июня 2012 г. . Получено 27 октября 2008 г. .
  2. ^ ab Джеффри Эллиотт (2004). Глобальные информационные технологии в бизнесе: комплексный системный подход . Pearson Education. стр. 87.
  3. ^ Сурьянараяна, Гириш (2015). «Процесс разработки программного обеспечения против качества проектирования: перетягивание каната?». IEEE Software . 32 (4): 7–11. doi : 10.1109/MS.2015.87 .
  4. ^ Пол М. Дюваль; Стив Матьяс; Эндрю Гловер (2007). Непрерывная интеграция: улучшение качества программного обеспечения и снижение риска . Addison-Wesley Professional . ISBN 978-0-321-33638-5.
  5. ^ Booch, Grady (1991). Объектно-ориентированное проектирование: с приложениями. Benjamin Cummings . стр. 209. ISBN 9780805300918. Получено 18 августа 2014 г. .
  6. ^ ab Whitten, Jeffrey L. ; Lonnie D. Bentley , Kevin C. Dittman . (2003). Системный анализ и методы проектирования . 6-е издание. ISBN 0-256-19906-X . 
  7. ^ Маркус Рерих. «Wasserfallmodell > Entstehungskontext». Institut für Gestaltungs- und Wirkungsforschung, TU-Wien (на немецком языке) . Проверено 28 ноября 2007 г.
  8. ^ Конрад Вайзерт. «Методология водопада: такого понятия нет!». Архивировано из оригинала 2 августа 2022 г.
  9. ^ Барри Бём (август 1986 г.). «Спиральная модель разработки и улучшения программного обеспечения». Заметки по программной инженерии ACM SIGSOFT . 11 (4). Ассоциация вычислительной техники : 14–24. doi : 10.1145/12944.12948. S2CID  1781829.
  10. ^ Ричард Х. Тайер; Барри В. Бём (1986). Учебное пособие: управление проектами по программной инженерии . Издательство Computer Society Press IEEE. С. 130.
  11. ^ Барри В. Бём (2000). Оценка стоимости программного обеспечения с помощью Cocomo II: Том 1 .
  12. ^ "Предисловие Джейсона Фрида | Shape Up". basecamp.com . Получено 11 сентября 2022 г. .
  13. ^ "Является ли Shape Up просто красивой теорией?". Curious Lab . Получено 12 сентября 2022 г.
  14. ^ Любке, Даниэль; ван Лессен, Таммо (2016). «Моделирование тестовых случаев в BPMN для разработки на основе поведения». IEEE Software . 33 (5): 15–21. doi :10.1109/MS.2016.117. S2CID  14539297.

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

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