 | Эта статья поднимает множество проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалить эти сообщения-шаблоны ) ( Узнайте, как и когда удалить этот шаблон сообщения )
|
| Разработка программного обеспечения |
|---|
| Активность ядер |
| Парадигмы и модели |
| Методологии и рамки |
| Вспомогательные дисциплины |
|
| Практики |
|
| Инструменты |
|
| Стандарты и свод знаний |
|
| Глоссарии |
|
| Контуры |
|
В программной инженерии , процесс разработки программного обеспечения представляет собой процесс разделения разработки программного обеспечения работы на отдельные фазы , чтобы улучшить дизайн , управление продуктом и управление проектами . Он также известен как жизненный цикл разработки программного обеспечения ( SDLC ). Методология может включать предварительное определение конкретных результатов и артефактов, которые создаются и завершаются командой проекта для разработки или сопровождения приложения. [1]
Большинство современных процессов разработки можно смутно назвать гибкими . Другие методологии включают водопад , прототипирование , итеративную и инкрементную разработку , спиральную разработку , быструю разработку приложений и экстремальное программирование .
«Модель» жизненного цикла иногда считается более общим термином для категории методологий, а «процесс» разработки программного обеспечения - более конкретным термином, относящимся к конкретному процессу, выбранному конкретной организацией. [ необходима цитата ] Например, существует множество конкретных процессов разработки программного обеспечения, которые соответствуют спиральной модели жизненного цикла. Сфера деятельности часто рассматривается как часть жизненного цикла разработки системы .
История [ править ]
Фреймворк методологии разработки программного обеспечения (также известный как SDM) появился только в 1960-х годах. Согласно Эллиотту (2004) , жизненный цикл разработки систем (SDLC) можно рассматривать как самую старую формализованную методологическую основу для построения информационных систем . Основная идея SDLC заключалась в том, чтобы «продолжить разработку информационных систем очень продуманным, структурированным и методичным образом, требуя, чтобы каждый этап жизненного цикла - от зарождения идеи до доставки окончательной системы - выполнялся. осуществляется жестко и последовательно » [2] в контексте применяемой структуры. Основной целью этой методологической основы в 1960-х годах была «разработка крупномасштабных функциональных бизнес-систем.в эпоху крупных бизнес-конгломератов. Информационные системы деятельности вращалась вокруг тяжелой обработки данных и номер хруст процедуры». [2]
Методологии, процессы и структуры варьируются от конкретных упреждающих шагов, которые могут использоваться организацией непосредственно в повседневной работе, до гибких структур, которые организация использует для создания настраиваемого набора шагов, адаптированного к потребностям конкретного проекта или группа. В некоторых случаях «спонсорская» или «обслуживающая» организация распространяет официальный набор документов, описывающих процесс. Конкретные примеры включают:
- 1970-е годы
- Структурированное программирование с 1969 г.
- Cap Gemini SDM , первоначально от PANDATA, первый перевод на английский был опубликован в 1974 году. SDM означает методологию разработки системы
- 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)
- Крупномасштабная шкала (LeSS)
- DevOps
Примечательно, что с момента DSDM в 1994 году все методологии из приведенного выше списка, за исключением RUP, были гибкими методологиями, однако многие организации, особенно правительства, по-прежнему используют процессы pre-agile (часто каскадные или аналогичные). Программный процесс и качество программного обеспечения тесно взаимосвязаны; некоторые неожиданные грани и эффекты наблюдались на практике [3]
Среди них есть еще один процесс разработки программного обеспечения с открытым исходным кодом . Принятие этих лучших практик, известных и установленных процессов в рамках компании называется внутренним источником .
Прототипирование [ править ]
Создание прототипов программного обеспечения - это создание прототипов, то есть неполных версий разрабатываемой программы.
Основные принципы: [1]
- Прототипирование - это не отдельная полная методология разработки, а, скорее, подход к опробованию определенных функций в контексте полной методологии (такой как инкрементальная, спиральная или быстрая разработка приложений (RAD)).
- Попытки снизить неотъемлемый проектный риск, разбивая проект на более мелкие сегменты и обеспечивая большую простоту изменения в процессе разработки.
- Клиент участвует на протяжении всего процесса разработки, что увеличивает вероятность принятия клиентом окончательной реализации.
- Хотя некоторые прототипы разрабатываются с расчетом на то, что они будут отброшены, в некоторых случаях возможно эволюционировать от прототипа к рабочей системе.
Чтобы избежать решения неправильных проблем, необходимо базовое понимание фундаментальной бизнес-проблемы, но это верно для всех программных методологий.
Методологии [ править ]
Гибкая разработка [ править ]
«Гибкая разработка программного обеспечения» относится к группе методологий разработки программного обеспечения, основанных на итеративной разработке, где требования и решения развиваются в результате сотрудничества между самоорганизующимися кросс-функциональными группами. Этот термин был введен в обращение в 2001 году, когда был сформулирован Agile Manifesto .
Гибкая разработка программного обеспечения использует итеративную разработку в качестве основы, но отстаивает более легкую и более ориентированную на людей точку зрения, чем традиционные подходы. Agile-процессы в основном включают в себя итерацию и постоянную обратную связь, которые они обеспечивают для последовательного улучшения и доставки программной системы.
Гибкая модель также включает следующие процессы разработки программного обеспечения: [4]
- Метод разработки динамических систем (DSDM)
- Канбан
- Scrum
- Кристалл
- Atern
- Бережливое развитие
Непрерывная интеграция [ править ]
Непрерывная интеграция - это практика объединения всех рабочих копий разработчика в общую магистраль несколько раз в день. [5] Грэди Буч впервые назвал и предложил КИ в своем методе 1991 г. [6], хотя он не выступал за интеграцию несколько раз в день. Экстремальное программирование (XP) приняло концепцию CI и действительно выступало за интеграцию более одного раза в день - возможно, до десятков раз в день.
Постепенное развитие [ править ]
Для комбинирования линейных и итерационных методологий разработки систем приемлемы различные методы, основная цель каждого из которых состоит в том, чтобы снизить присущий проекту риск за счет разделения проекта на более мелкие сегменты и обеспечения большей простоты внесения изменений в процессе разработки.
Существует три основных варианта инкрементальной разработки: [1]
- Выполняется серия мини-водопадов, где все фазы водопада завершаются для небольшой части системы перед переходом к следующему этапу, или
- Общие требования определяются до перехода к эволюционной разработке отдельных этапов системы с помощью мини-водопада.
- Первоначальная концепция программного обеспечения, анализ требований и дизайн архитектуры и ядра системы определяются с помощью Waterfall, после чего следует инкрементная реализация, которая завершается установкой окончательной версии, работающей системы.
Быстрая разработка приложений [ править ]
Быстрая разработка приложений (RAD) - это методология разработки программного обеспечения, которая способствует итеративной разработке и быстрому созданию прототипов вместо большого объема предварительного планирования. «Планирование» программного обеспечения, разработанного с использованием RAD, чередуется с написанием самого программного обеспечения. Отсутствие тщательного предварительного планирования обычно позволяет писать программное обеспечение намного быстрее и упрощает изменение требований.
Быстрый процесс развития начинается с разработки предварительных моделей данных и моделей бизнес - процессов с использованием структурированных методов . На следующем этапе требования проверяются с помощью прототипирования, чтобы в конечном итоге уточнить модели данных и процессов. Эти этапы повторяются итеративно; Дальнейшее развитие приводит к «объединению бизнес-требований и технического проекта, которые будут использоваться для создания новых систем». [7]
Этот термин впервые был использован для описания процесса разработки программного обеспечения, введенного Джеймсом Мартином в 1991 году. По словам Уиттена (2003), это слияние различных структурированных методов , особенно информационных технологий , управляемых данными , с методами прототипирования для ускорения разработки программных систем. . [7]
Основные принципы быстрой разработки приложений: [1]
- Ключевой целью является быстрая разработка и поставка высококачественной системы при относительно низких инвестиционных затратах.
- Попытки снизить неотъемлемый проектный риск, разбивая проект на более мелкие сегменты и обеспечивая большую простоту изменения в процессе разработки.
- Нацелен на быстрое создание высококачественных систем, прежде всего с помощью итеративного прототипирования (на любой стадии разработки), активного участия пользователей и компьютеризированных инструментов разработки. Эти инструменты могут включать в себя построители графического интерфейса пользователя (GUI), инструменты компьютерной разработки программного обеспечения (CASE), системы управления базами данных (СУБД), языки программирования четвертого поколения , генераторы кода и объектно-ориентированные методы.
- Основной упор делается на удовлетворение бизнес-потребностей, в то время как технологическое или инженерное совершенство имеет меньшее значение.
- Управление проектом включает приоритезацию разработки и определение сроков поставки или «временных рамок». Если проект начинает отставать, упор делается на сокращении требований, чтобы соответствовать срокам, а не на увеличении сроков.
- Обычно включает совместное проектирование приложений (JAD), в котором пользователи активно участвуют в проектировании системы , путем достижения консенсуса либо на структурированных семинарах, либо посредством электронного взаимодействия.
- Активное участие пользователя обязательно.
- Производственное программное обеспечение создается итеративно, в отличие от одноразового прототипа.
- Создает документацию, необходимую для облегчения дальнейшего развития и обслуживания.
- В эту структуру можно вписать стандартные методы системного анализа и проектирования.
Спиральное развитие [ править ]
В 1988 году Барри Бем опубликовал формальную «спиральную модель» разработки программных систем, которая сочетает в себе некоторые ключевые аспекты водопадной модели и методологий быстрого прототипирования в попытке объединить преимущества нисходящей и восходящей концепций. В нем сделан акцент на ключевой области, которая, по мнению многих, игнорировалась другими методологиями: преднамеренный итеративный анализ рисков, особенно подходящий для крупномасштабных сложных систем.
Основные принципы: [1]
- Основное внимание уделяется оценке рисков и минимизации рисков проекта путем разбиения проекта на более мелкие сегменты и обеспечения большей простоты внесения изменений в процессе разработки, а также предоставления возможности оценить риски и взвесить рассмотрение продолжения проекта на протяжении всего жизненного цикла.
- «Каждый цикл включает в себя продвижение через одну и ту же последовательность шагов для каждой части продукта и для каждого из уровней его проработки, от общей концепции работы документа до кодирования каждой отдельной программы». [8]
- Каждое путешествие по спирали проходит через четыре основных квадранта: (1) определение целей, альтернатив и ограничений итерации; (2) оценивать альтернативы; Выявление и устранение рисков; (3) разработать и проверить результаты итерации; и (4) спланировать следующую итерацию. [9]
- Начинайте каждый цикл с определения заинтересованных сторон и их «условий победы» и заканчивайте каждый цикл обзором и приверженностью. [10]
Развитие водопада [ править ]
Модель водопада - это последовательный подход к разработке, в котором развитие рассматривается как неуклонно нисходящее (как водопад) через несколько этапов, обычно:
- Анализ требований, результатом которого является спецификация требований к программному обеспечению
- Разработка программного обеспечения
- Выполнение
- Тестирование
- Интеграция , если есть несколько подсистем
- Развертывание (или установка )
- Обслуживание
Первое формальное описание метода часто цитируется как статья, опубликованная Уинстоном У. Ройсом [11] в 1970 году, хотя Ройс не использовал термин «водопад» в этой статье. Ройс представил эту модель как пример ошибочной, неработающей модели. [12]
Основные принципы: [1]
- Проект разделен на последовательные фазы, при этом между фазами допускается некоторое перекрытие и обратная связь.
- Акцент делается на планирование, графики работы, контрольные даты, бюджеты и одновременное внедрение всей системы.
- На протяжении всего жизненного цикла проекта поддерживается жесткий контроль с помощью обширной письменной документации, формальных проверок и утверждения / утверждения пользователем и руководством информационных технологий, происходящих в конце большинства этапов перед началом следующего этапа. Письменная документация - явный результат каждого этапа.
Модель водопада - это традиционный инженерный подход, применяемый к разработке программного обеспечения. Строгий водопадный подход не рекомендует пересматривать и пересматривать любой предыдущий этап после его завершения. [ согласно кому? ] Эта «негибкость» чистой модели водопада вызвала критику со стороны сторонников других, более «гибких» моделей. Его широко обвиняли в нескольких крупномасштабных государственных проектах, выходящих за рамки бюджета, с течением времени, а иногда и неспособных выполнить требования из-за подхода Big Design Up Front . [ согласно кому? ]За исключением случаев, когда это требуется по контракту, водопадная модель в значительной степени заменена более гибкими и универсальными методологиями, разработанными специально для разработки программного обеспечения. [ согласно кому? ] См. « Критика модели водопада» .
Другое [ править ]
Другие методологии разработки программного обеспечения высокого уровня включают:
- Поведенческая разработка и управление бизнес-процессами [13]
- Модель хаоса . Главное правило - всегда решать самую важную проблему первым.
- Методология инкрементного финансирования - итеративный подход
- Облегченная методология - общий термин для методов, которые имеют всего несколько правил и практик.
- Метод анализа и проектирования структурированных систем - конкретная версия водопада
- Медленное программирование, как часть более широкого медленного движения , делает упор на тщательную и постепенную работу без (или минимального) давления времени. Медленное программирование направлено на избежание ошибок и слишком быстрых графиков выпуска.
- V-Model (разработка программного обеспечения) - расширение модели водопада
- Unified Process (UP) - это структура методологии итеративной разработки программного обеспечения, основанная на Unified Modeling Language (UML). UP разделяет разработку программного обеспечения на четыре этапа, каждый из которых состоит из одной или нескольких исполняемых итераций программного обеспечения на данном этапе разработки: начало, разработка, создание и руководство. Существует множество инструментов и продуктов, облегчающих внедрение UP. Одна из наиболее популярных версий UP - Rational Unified Process (RUP).
Мета-модели процессов [ править ]
Некоторые « модели процессов » представляют собой абстрактные описания для оценки, сравнения и улучшения конкретного процесса, принятого организацией.
- ISO / IEC 12207 - это международный стандарт, описывающий метод выбора, внедрения и мониторинга жизненного цикла программного обеспечения.
- Capability Maturity Model Integration (CMMI) является одной из ведущих моделей и на основе передового опыта. Независимая оценка оценивает организации по тому, насколько хорошо они следуют определенным процессам, а не по качеству этих процессов или производимого программного обеспечения. CMMI заменил CMM .
- ISO 9000 описывает стандарты для формально организованного процесса производства продукта, а также методы управления и мониторинга прогресса. Хотя стандарт изначально был создан для производственного сектора, стандарты ISO 9000 применялись и к разработке программного обеспечения. Как и CMMI, сертификация по ISO 9000 не гарантирует качества конечного результата, а только соблюдение формализованных бизнес-процессов.
- ISO / IEC 15504 Информационные технологии - Оценка процесса, также известная как определение возможностей улучшения программного обеспечения (SPICE), представляет собой «основу для оценки программных процессов». Этот стандарт нацелен на установление четкой модели для сравнения процессов. SPICE используется так же, как CMMI. Он моделирует процессы для управления, контроля, руководства и мониторинга разработки программного обеспечения. Затем эта модель используется для измерения того, что на самом деле делает организация-разработчик или команда проекта во время разработки программного обеспечения. Эта информация анализируется для выявления слабых мест и стимулирования улучшений. Он также определяет сильные стороны, которые можно продолжить или интегрировать в общую практику этой организации или команды.
- ISO / IEC 24744 « Программная инженерия - Метамодель для методологий разработки» - это метамодель на основе powertype для методологий разработки программного обеспечения.
- SPEM 2.0 от Object Management Group
- Методология мягких систем - общий метод улучшения процессов управления
- Методология - общий метод улучшения процессов информационной системы
На практике [ править ]
С годами появилось множество таких структур, каждая из которых имеет свои сильные и слабые стороны. Одна структура методологии разработки программного обеспечения не обязательно подходит для использования во всех проектах. Каждая из доступных методологических структур лучше всего подходит для конкретных типов проектов, основанных на различных технических, организационных, проектных и командных соображениях. [1]
Организации, занимающиеся разработкой программного обеспечения, применяют методологии процессов, чтобы упростить процесс разработки. Иногда подрядчикам могут потребоваться используемые методики, например, оборонная промышленность США , которая требует рейтинга на основе моделей процессов для заключения контрактов. Международным стандартом для описания метода выбора, реализации и мониторинга жизненного цикла программного обеспечения является ISO / IEC 12207 .
Многолетняя цель заключалась в том, чтобы найти повторяемые, предсказуемые процессы, улучшающие производительность и качество. Некоторые пытаются систематизировать или формализовать, казалось бы, непослушную задачу разработки программного обеспечения. Другие применяют методы управления проектами для разработки программного обеспечения. Большое количество программных проектов не оправдывает своих ожиданий с точки зрения функциональности, стоимости или графика поставки - см. Список неудачных и сверхбюджетных заказных программных проектов для некоторых примечательных примеров.
Организации могут создать группу процессов разработки программного обеспечения (SEPG), которая является центром совершенствования процессов. Эта группа, состоящая из линейных практиков, обладающих различными навыками, находится в центре совместных усилий всех сотрудников организации, участвующих в улучшении процессов разработки программного обеспечения.
Конкретная команда разработчиков может также согласиться программирования деталей окружающей среды, например, какие интегрированные среды разработки используется, и один или несколько доминирующих парадигм программирования , стиль программирования правил или выбор конкретных программных библиотек или рамок программного обеспечения . Эти детали обычно не продиктованы выбором модели или общей методологии.
См. Также [ править ]
- Жизненный цикл разработки систем
- Компьютерная разработка программного обеспечения (некоторые из этих инструментов поддерживают определенные методологии)
- Список философий разработки программного обеспечения
- Очерк программной инженерии
- Открыть
- Управление проектом
- Разработка программного обеспечения
- Оценка усилий по разработке программного обеспечения
- Жизненный цикл выпуска программного обеспечения
- Дизайн сверху вниз и снизу вверх # Информатика
Ссылки [ править ]
- ^ a b c d e f g Информационная служба Центров Medicare и Medicaid Services (CMS) (2008 г.). Выбор подхода к разработке . Веб-статья. Министерство здравоохранения и социальных служб США (HHS). Повторная проверка: 27 марта 2008 г. Проверено 27 октября 2008 г.
- ^ a b Джеффри Эллиотт (2004) Глобальные информационные технологии для бизнеса: комплексный системный подход . Pearson Education. стр.87.
- ^ Сурьянараяна, Гириш (2015). «Программный процесс против качества дизайна: перетягивание каната?». Программное обеспечение IEEE . 32 (4): 7–11. DOI : 10.1109 / MS.2015.87 .
- ^ «процесс разработки программного обеспечения» .
- ^ «Непрерывная интеграция» .
- ^ Буча, Грейди (1991). Объектно-ориентированный дизайн: с приложениями . Бенджамин Каммингс . п. 209. ISBN 9780805300918. Проверено 18 августа 2014 .
- ^ a b Уиттен, Джеффри Л .; Лонни Д. Бентли , Кевин С. Диттман . (2003). Системный анализ и методы проектирования . 6-е издание. ISBN 0-256-19906-X .
- ^ Барри Бем (1996)., "Спиральная модель разработки и улучшения программного обеспечения ". В: ACM SIGSOFT Software Engineering Notes (ACM) 11 (4): 14-24, август 1986 г.
- ^ Ричард Х. Тайер, Барри У. Бём (1986). Учебное пособие: управление проектами программной инженерии . Компьютерное общество Издательство IEEE. стр.130
- ^ Barry W. Бем (2000). Оценка стоимости программного обеспечения с помощью Cocomo II: Том 1 .
- ^ Wasserfallmodell> Entstehungskontext , Маркус Рерих, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Доступ онлайн 28 ноября 2007 г.
- ^ Конрад Вайзерт, Методология водопада: такого не бывает!
- ^ Любке, Даниэль; ван Лессен, Таммо (2016). «Моделирование тестовых примеров в BPMN для разработки, управляемой поведением». Программное обеспечение IEEE . 33 (5): 15–21. DOI : 10.1109 / MS.2016.117 . S2CID 14539297 .
Внешние ссылки [ править ]
 | Викискладе есть медиафайлы, связанные с методологией разработки программного обеспечения . |
- Выбор подхода к разработке на cms.hhs.gov.
- Герхард Фишер, "Программные технологии 21 века: от повторного использования программного обеспечения до совместного проектирования программного обеспечения" , 2001 г.
- Карта метро Agile-практик в Agile Alliance
| vтеПрограммная инженерия | |||||||
|---|---|---|---|---|---|---|---|
| Поля |
| ||||||
| Концепции |
| ||||||
| Ориентации |
| ||||||
| Модели |
| ||||||
| Инженеры- программисты |
| ||||||
| Связанные поля |
| ||||||
| |||||||
Категория
Commons