stringtranslate.com

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

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

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

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

История

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

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

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

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

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

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

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

1970-е годы
1980-е годы
1990-е годы
2000-е

2010-е годы

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

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

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

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

Основными принципами являются: [1]

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

Методологии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основными принципами являются: [1]

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

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

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

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

Основными принципами являются: [1]

Подтянуться

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

Циклы

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

Формирование

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

Перед началом цикла заинтересованные стороны проводят стол для ставок, на котором просматриваются предложения. Для каждой подачи принимается решение: либо сделать ставку на нее, либо отказаться от нее. [16]

Аппетит

Способ, которым Shape Up определяет, сколько времени выделяется на проект, диаметрально противоположен другим методологиям. Shape Up начинается с аппетита (например, 6 недель) и заканчивается разработкой решения, которое можно реализовать в рамках этого ограничения. Аппетит становится жестким сроком для строителей проекта. [17]

Здание

Shape Up — это двухканальная система, в которой формовщики и строители работают параллельно. Работа, формируемая в текущем цикле, может быть передана дизайнерам и инженерам для реализации в будущем цикле.

Признавая техническую неопределенность, связанную со строительством, прогресс отслеживается с помощью диаграммы, которая визуализирует метафору холма, метко названную диаграммой холма. На этапе подъема строители все еще отрабатывают свой подход, а на этапе спуска неизвестные устраняются. Разработчики активно и асинхронно сообщают о прогрессе самостоятельно, используя интерактивную онлайн-графику в Basecamp или Jira , перемещая фокус со статусов «выполнено» или «не выполнено» на неизвестные или решенные проблемы. Использование диаграммы холмов заменяет процесс сообщения линейных статусов в Scrum или Kanban Standup. [18] [19]

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

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

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

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

На практике

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

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

Организации , занимающиеся разработкой программного обеспечения, внедряют методологии процессов, чтобы облегчить процесс разработки. Иногда подрядчикам может потребоваться применение методологий, примером может служить оборонная промышленность США , которая требует рейтинга, основанного на моделях процессов, для получения контрактов. Международным стандартом для описания метода выбора, внедрения и мониторинга жизненного цикла программного обеспечения является ISO/IEC 12207 .

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

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

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

Жизненный цикл разработки программного обеспечения (SDLC)

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

Рекомендации

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

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

На Wikimedia Commons есть средства массовой информации, связанные с методологией разработки программного обеспечения .