Методологии разработки по реферат

Обновлено: 06.07.2024

Формально методологии можно разделить на два типа – классические (монументальные, предсказуемые, где все этапы детально проектируется заранее и не допускается отклонение от первоначального плана) и их противоположность – адаптивные (гибкие, где в процессе работы допустимо и даже типично перепроектирование).
Гибкие (Agile) методологии появились в противовес классическим, детально описывающим процесс создания системы. Эти методологии представляют собой попытку достичь необходимого компромисса между слишком перегруженным процессом разработки и полным его отсутствием.

Вложенные файлы: 1 файл

реферат(Agile).docx

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ, МОЛОДЕЖИ И СПОРТА УКРАИНЫ

Донецкий национальный технический университет

Институт информатики и искусственного интеллекта

Д050103.1.01.09/344.ЛР Кафедра Программное обеспечение
интеллектуальных систем

Выполнил: ст. гр. ПОC-О9в

_________ст.пр. Золотухина О.А.

Список условных обозначений, сокращений и терминов

Adaptive Software Development (ADS) - Адаптивная разработка программного обеспечения;
Agile Project Management (APM) – Agile управление проектами;
Dynamic Systems Development Method (DSDM) – Метод динамическое развитие систем;
Extreme Programming (XP) – Экстримальное программирование;
Feature-Driven Development (FDD) – Разработка, управляемая функциональностью ;
Lean Software Development (LSD) – Бережливая разработка программного обеспечения ;
Microsoft Solutions Framework для Agile (MSF) – методология разработки программного обеспечения, предложенная корпорацией Microsoft ;
Open Unified Process (OpenUP) – экономичный унифицированный процесс, использующий принципы итеративности и инкрементальности в рамках структурированного жизненного цикла.
Pragmatic Programming (PP) – методология гибкой разработки
Scrum – методология гибкой разработки

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

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

Когда начинаешь интересоваться какие сейчас популярны методологии программирования, то очень быстро натыкаешься на очень красивое, но не понятное слово Agile

что такое Agile и с чем его едят.

Agile - это только концептуальный каркас. Своего рода абстрактный класс, от которого вы можете наследовать свой рабочий процесс и выбрать: вы хотите работать по Extreme programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. Или по нескольким сразу (SCRUM и Extreme programming прекрасно сочетаются ). Или же у вас непреодолимое желание создать свою методику, но все равно у вас есть шанс быть Agile командой (рис.1).

Рис.1 – Схема методологии Agile

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

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

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

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

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

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

Основополагающие принципы Agile-манифеста

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

В чем суть Аgile и чем хороши эти методологии?

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

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

По окончании каждой итерации команда выполняет оценку своей результативности и планирует работу на следующий этап.

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

Хорошая реакция на изменения
Регулярная обратная связь от заказчика (о том что делаем именно то что он хочет)
Стабильный и предсказуемый результат
Высокая мотивированность команды
Самоорганизация
Разделение рисков между заказчиком и командой

Рассмотрим эти пункты подробнее:

1. Хорошая реакция на изменения

В отличие от альтернативной методологии разработки — “ватерфол”, когда заказчик получает через заранее определенный срок, к примеру, через год строго то, что изначально запланировали в проекте, в Аgile изменения можно вносить по мере необходимости в процессе разработки.

2. Agile уделяет много внимания качественной обратной связи

Для того чтобы понять всю сложность взаимоотношений заказчика и разработчика, предлагаю рассмотреть следующий рисунок, который сам по себе о многом говорит (рис.2).

Рис.2 – Взаимоотношение заказчик-разработчик

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

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

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

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

Методологии Agile позволяют легко реагировать на изменения функциональных требований и приоритетов.

3. Agile обеспечивают предсказуемость

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

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

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

Например, если мы имеем следующие исходные данные:
Объем работ = 1000 единиц,
Производительность команды = 50 единиц за итерацию,
Цена итерации (сумма ставок каждого из ее членов) = 100$.
То в итоге мы получаем: (1000/50)*100=2000$.
Это означает, что изменение объема работ на 50 пунктов влечет за собой изменение стоимости конечного продукта на 100 у.е.

Рис.3 – Команда разработчиков

4. Agile позволяют использовать самоорганизацию для мотивации команды

Самоорганизация позволяет уйти от излишней структуры менеджмента.

Методология Agile предполагает наличие только представителя заказчика, который выражает интересы бизнеса.

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

5. Agile подразумевают разделение рисков между заказчиком и командой

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

Вторая схема контракта – time & material, суть которого в том, что заказчик оплачивает фактическую работу.

Рис.4 – Разделение рисков между заказчиком и командой

Это приводит к тому, что разработчик не стремится брать на себя ответственность за результат, а просто не спеша выполняет порученные ему задачи. Как следствие, исполнителю, по сути, безразлично, в правильном ли направлении ведется разработка. Заказчик заплатит и за время, потраченное на разработку в неверном ключе, и за переделывание неудовлетворительных результатов.

Visual Studio включает в себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный отладчик может работать как отладчик уровня исходного кода, так и отладчик машинного уровня. Остальные встраиваемые инструменты включают в себя редактор форм для упрощения создания графического интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы данных. Visual Studio позволяет создавать и подключать сторонние дополнения (плагины) для расширения функциональности практически на каждом уровне, включая добавление поддержки систем контроля версий исходного кода (как, например, Subversion и Visual SourceSafe), добавление новых наборов инструментов (например, для редактирования и визуального проектирования кода на предметно-ориентированных языках программирования) или инструментов для прочих аспектов процесса разработки программного обеспечения (например, клиент Team Explorer для работы с Team Foundation Server).

Общие сведения. Историческая справка

Microsoft Visual C++ - интерактивная среда программирования на языке Visual C++, расширении языка C++, разработанном и реализованном фирмой Microsoft. Язык Visual C++ в составе всех версий Visual Studio и ныне остается наиболее популярным и широко используемым языком программирования в мире;
Visual Basic - объектно-ориентированное расширение языка BASIC, разработанное и реализованное фирмой Microsoft, которое сразу начало активно использоваться программистами всего мира, так как сочетало в себе простоту языка BASIC с новейшими объектно-ориентированными расширениями. Многие коллеги- программисты еще в начале 1990-х гг. рассказывали об удобстве Visual Basic и предпочитали именно на нем разрабатывать программы управления GUI;
Microsoft Visual FoxPro - интерактивная среда программирования на языке Visual FoxPro - объектно-ориентированном языке с элементами процедурного программирования, разработанном под названием FoxBase первоначально небольшой фирмой Fox Software. Привлекательной чертой этого языка для многих пользователей стали возможности обращения непосредственно из программы на этом языке к базам данных, основанных на языке SQL, в частности, программирование SQL-запросов на языке FoxPro;
Microsoft Visual SourceSafe - разработанная фирмой Microsoft система управления версиями исходных кодов, впоследствии интегрированная со средой Visual Studio.

Даже в столь ранней версии среда Visual Studio обрела весьма широкую популярность. Например, фирма Sun Microsystems, которая в том же 1995 г. выпустила новый язык и технологию программирования Java, - в качестве основы для реализации своих платформно-независимых Java-библиотек Abstract Windows Toolkit (AWT) для поддержки разработки GUI для платформы Windows использовала именно среду Visual Studio и реализованный в ней язык Visual C++.7

Интегрированная среда разработки Microsoft Visual Studio

Рис. 2.1 - Интегрированная среда разработки, в которой установлены общие параметры разработки
Расположение окон инструментов и других элементов интегрированной среды разработки может изменяться в зависимости от примененных параметров и настроек, выполняемых пользователем в процессе работы. Параметры можно изменить с помощью средства ImportandExportSettingsWizard.Выбрав параметр Сбросить все параметры, можно изменить язык программирования по умолчанию.15

Можно легко перемещать и закреплять окна с помощью визуального направляющего ромба или временно скрывать окна с помощью функции автоскрытия. Дополнительные сведения см. в разделе Практическое руководство. Размещение и закрепление окон.

Интегрированную среду разработки можно автоматизировать и расширить с помощью модели автоматизации Visual Studio.

Система проекта

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

SolutionExplorer выводит на экран решения, содержащиеся в них проекты и элементы этих проектов. В обозревателе решений можно открывать файлы для редактирования, добавлять новые файлы в проект и просматривать свойства решений, проектов и элементов. На рис. 2.2 представлен обозреватель решений. 15

Рис. 2.2 - Обозреватель решений
Редакторы и конструкторы

Выбор используемых редакторов и конструкторов зависти от типа создаваемого файла или документа. Редактор текста - это основной текстовый процессор интегрированной среды разработки, а редактор кода - основной редактор исходного кода. Другие редакторы, такие как редактор таблиц CSS, конструктор HTML и конструктор веб-страниц, совместно используют целый ряд возможностей редактора кода, но обладают и дополнительными средствами, связанными с поддерживаемыми ими типами кода или разметки. В редакторах и конструкторах, как правило, используется два представления: графическое представление конструктора и представление связанного кода или исходного кода. Представление конструктора позволяет определить расположение элементов управления и других объектов пользовательского интерфейса или веб-страницы. Элементы управления можно легко перемещать изпанель элементов и располагать в рабочей области конструирования. На рис. 2.3 представлен конструктор веб-страниц, представление конструктора. 15

Рис. 2.4 - Конструктор веб-страниц, представление исходного кода

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

Рис. 2.5 - Конструктор веб-страниц, представление с разделением
Средства построения и отладки

В среде Visual Studio предусмотрен мощный набор средств построения и отладки. Благодаря конфигурациям построения можно выбирать компоненты для построения, исключать компоненты, которые не требуется включать в построение, а также определять, как будут построены выбранные проекты и для какой платформы. Конфигурации построений доступны как для решений, так и для проектов. 3

При построении начинается процесс отладки. Построение приложений позволяет обнаруживать ошибки времени компиляции. К этим ошибкам могут относиться неверный синтаксис, ошибки в зарезервированных словах и несовпадения типов. Эти типы ошибок отображаются в Окно выходных данных. 3

На рис. 2.6 представлено окно вывода со сведениями о построении.

Рис. 2.6 - Окно вывода со сведениями о построении
После завершения построения приложения можно использовать отладчик для обнаружения и устранения таких проблем, как логические и семантические ошибки, обнаруженные во время выполнения. В режиме приостановки выполнения можно просматривать локальные переменные и другие связанные данные, используя такие средства, как Окна переменных и Окно памяти. На рис. 2.7, 2.8 представлены форма VisualBasic в режиме приостановки выполнения и окна средств отладки.

Рис. 2.7 - Форма VisualBasic в режиме приостановки выполнения

В Visual Studio предусмотрены две различные стратегии развертывания: ClickOnce и установщик Windows.При использовании развертывания ClickOnce осуществляется публикация приложения в некоторое централизованное расположение, и пользователь устанавливает или запускает приложение из этого расположения. При развертывании с помощью установщика Windows приложение упаковывается в файл setup.exe, который распространяется среди пользователей; затем пользователи устанавливают приложения с помощью этого файла. 2

Технология ClickOnce позволяет быстро выполнять развертывание приложений с помощью средства мастер публикации. На рис. 2.9 представлен мастер публикации.

Рис. 2.9 - Мастер публикации
Установщик Windows обеспечивает более гибкие возможности развертывания приложений. С помощью целого ряда редакторов, таких как редактор настраиваемых действий и редактор пользовательского интерфейса, можно настроить установщик Windows в соответствии с конкретными потребностями развертывания. Для создания базового файла установки используется Редактор файловой системы, чтобы указать набор развертываемых элементов. На рис. 2.10 представлен редактор файловой системы.

Рис. 2.10 - Редактор файловой системы

Документация по продукту

Вызов справки возможен двумя способами: во-первых, нажатием клавиши F1 в интерфейсе IDE и, во-вторых, щелчком Документации Visual Studio в меню Справка. Документация справки отобразится в окне веб-браузера. Можно использовать локальную версию справки или открывать разделы справки на веб-узле MSDNOnline и других ресурсах Интернета. На рис. 2.11 представлена справка в окне браузера. 8

Рис. 2.11 - Справка в окне браузера

Поддерживаемые технологии и языки программирования

Интерфейс и простейшее приложение в среде разработки Microsoft Visual Studio

Например, переименовать окно MainWindow в более информативное имя.

Последний элемент пользовательского интерфейса - это элемент управления Button (Кнопка) – добавляется аналогично RadioButton. В представлении XAML нужно изменить значение атрибута Content (Содержимое) c Content=”Button” на Content=”Display”, а затем сохранить изменения.

Редактируемое окно проекта будет похоже на рис. 4.20.

Рис. 4.20 - Окончательный вид пользовательского интерфейса
В области конструктора дважды щёлкните по кнопке Display.

Откроется файл Greetings.xaml.vb (или Greetings.xaml.cs) с курсором, помещённым вобработчик события Button_Click.

if (RadioButton1.IsChecked == true)

Основные достоинства и недостатки Microsoft Visual Studio

Ниже перечислены основные преимущества IDE-среды Visual Studio.

Поддержка множества языков при разработке. Visual Studio позволяет писать код на своем языке или любых других предпочитаемых языках, используя все время один и тот же интерфейс (IDE). Более того, Visual Studio также еще позволяет создавать Web-страницы на разных языках, но помещать их все в одно и то же Web-приложение. Единственным ограничением является то, что в каждой Web-странице можно использовать только какой-то один язык (очевидно, что в противном случае проблем при компиляции было бы просто не избежать).

Меньше кода для написания. Для создания большинства приложений требуется приличное количество стандартного стереотипного кода, и Web-страницы ASP. NET тому не исключение. Например, добавление Web-элемента управления, присоединение обработчиков событий и корректировка форматирования требует установки в разметке страницы ряда деталей. В Visual Studio такие детали устанавливаются автоматически. 12

Интуитивный стиль кодирования. По умолчанию Visual Studio форматирует код по мере его ввода, автоматически вставляя необходимые отступы и применяя цветовое кодирование для выделения элементов типа комментариев. Такие незначительные отличия делают код более удобным для чтения и менее подверженным ошибкам. Применяемые Visual Studio автоматически параметры форматирования можно даже настраивать, что очень удобно в случаях, когда разработчик предпочитает другой стиль размещения скобок (например, стиль K&R, при котором открывающая скобка размещается на той же строке, что и объявление, которому она предшествует).

Более высокая скорость разработки. Многие из функциональных возможностей Visual Studio направлены на то, чтобы помогать разработчику делать свою работу как можно быстрее. Удобные функции, вроде функции IntelliSense (которая умеет перехватывать ошибки и предлагать правильные варианты), функции поиска и замены (которая позволяет отыскивать ключевые слова как в одном файле, так и во всем проекте) и функции автоматического добавления и удаления комментариев (которая может временно скрывать блоки кода), позволяют разработчику работать быстро и эффективно. 12

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

Visual Studio также имеет и множество других функций: возможность управления проектом; встроенная функция управления исходным кодом; возможность рефакторизации кода; мощная модель расширяемости. Более того, в случае использования Visual Studio 2008 Team System разработчик получает расширенные возможности для модульного тестирования, совместной работы и управления версиями кода (что значительно больше того, что предлагается в более простых инструментах вроде Visual SourceSafe).

В качестве недостатка можно отметить невозможность отладчика (Microsoft Visual Studio Debugger) отслеживать в коде режима ядра. Отладка в Windows в режиме ядра в общем случае выполняется при использовании WinDbg, KD или SoftICE.

Заключение

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

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

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

Разработка программного обеспечения состоит из следующих этапов:

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

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

• проектирование – сбор модели данных.

• реализация: разработка продукта по требованиям, взаимодействие всей команды для достижения конечной цели, один из самых насыщенных этапов цикла разработки.

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

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

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

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

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

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

(или гибкая модель разработки ПО)

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

Agile Model имеет два отдельных гибких подхода:

Поскольку данная модель выделилась из Agile, она состоит из того же, что и Agile model. В таком подходе в команде часто появляется Scrum-мастер, который обеспечивает непрерывную работу все команды, создавая для нее все условия: поддерживая мотивацию, организовывая процедуры, фасилитирует митинги. Также на проекте появляется роль Product Owner – человек, который руководит разработкой, следит за продуктом, как BA, выступает главным звеном между миссией клиента и результатом команды.

Такая система подойдет проектам до десяти человек. Но мы бы не назвали подход эффективным, потому как требования обычно неизвестны на 50%, все постоянно меняется, так как изменения можно вносить на любом этапе разработки: весьма трудно понять затраты на разработку.

Данный подтип разработки отличается своей визуализацией жизненного цикла. Команда ориентируется на выполнение задач, которые сдаются индивидуально: задача должна пройти через все колонки – To do, In progress, Code review, In testing, Done (колонки могут быть изменены в индивидуальном порядке). Цель каждого участника команды – уменьшать количество задач в первой колонке. Данный наглядный подход позволяет понять, где возникла проблема – бутылочное горлышко, а также просто видеть организацию всего проекта.

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

RAD

(известная как rapid application development, быстрая разработка приложений, инкрементальная модель)

Spiral

Данная модель направлена на анализ оценки рисков. И отлично подойдет там, где нет права на ошибку. Также ее удобно использовать для введения новых линеек продукта и проведения исследований. Выглядит эта модель, как спираль, так как начинает оценивать риски сначала на локальных программах, пытаясь предотвратить риски, далее переходит на новый виток спирали, перенаправляясь к работе с более комплексными тасками. Чаще всего мы проходим такие этапы, как: планирование, анализ рисков, конструирование, оценку результата – так, если он удовлетворяет, мы переходим на новый виток.

Подход разумнее использовать на больших и дорогих проектах.

Extreme Programming

(экстремальное программирование, XP)

Extreme Programming считается неформальным подходом разработки ПО, где каждый разработчик – профессионал своего дела. Если же отношение меняется, то внедрять методологию бесполезно. Разработка продукта ведется короткими итерациями. Экстремальность подхода в том, что применяется первое простое решение, что создает большой риск. В методологии практикуется парное программирование и групповая разработка. Целью такой методологии является создать с заказчиком максимально доверительные отношения и значительно сократить срок разработки продукта.

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

Lean

(бережливая разработка ПО)

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

В Lean есть семь принципов, которые помогают достичь цели:

• Decide as late as possible;

• Deliver as fast as possible;

• Enpower the team;

• Build integrity in;

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

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

1. Этапы жизненного цикла ПО

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

Жизненный цикл разработки программного обеспечения от английского Software Development Life Cycle, SDLC — это условная схема, которая содержит в себе все этапы, через которые ПО проходит от формирования в виде идеи до последних дней своей работы, что еще раз подтверждает вышесказанное: разработка приложения не прекращается даже после его релиза.

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

Основные модели разработки ПО

Идея, сбор и анализ требований для ее осуществления.
Дизайн и проектирование.
Реализация и программирование.
Тестирование и отладка.
Внедрение и эксплуатация.
Сопровождение и поддержка.

Остановимся на каждом из них подробнее.

Идея, сбор и анализ требований для ее осуществления

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

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

Дизайн и проектирование

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

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

Реализация и программирование

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

Тестирование и отладка

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

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

Внедрение и эксплуатация

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

Сопровождение и поддержка

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

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

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

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

2. Основные модели разработки ПО

Методология разработки ПО — это система, которая определяет порядок и сроки выполнения задач внутри этапов жизненного цикла, методы оценки и контроля. Бюджет и сроки выполнения проекта и метод разработки связаны и зависят друг от друга.

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

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

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

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

Преимущества каскадной модели

Простое управление разработкой при наличии четко сформулированной документации.
Стоимость и сроки известны на начальном этапе.
Низкая вероятность ошибок в небольших проектах.
Тестирование могут проводить люди с более низкой квалификацией из-за наличия подробной документации .

Недостатки каскадной модели

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

V-образная модель (разработка через тестирование)

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

Соответственно, V-образная модель также подходит для небольших и средних по объемам проектов, где вся документация четко прописана и требуется определенный уровень качества (высокий). Это могут быть приложения безопасности, наблюдения за тяжелобольными пациентами, ПО для атомных электростанций и так далее.

Преимущества V-образной модели

Тестирование проходит на всех этапах разработки.
Вероятность ошибок сводится к минимуму.

Недостатки V-образной модели

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

Incremental Model (инкрементная модель)

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

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

Преимущества инкрементной модели

Есть возможность раннего выхода на рынок, чтобы посмотреть реакцию пользователей.
Базовая версия ПО стоит дешевле. Модули можно доделывать по мере появления денег, либо не делать вовсе за ненадобностью. Самые рискованные идеи можно отложить на потом.
Исправление ошибок обходится дешевле.

Недостатки инкрементной модели

RAD (быстрая разработка)

RAD Model (Rapid Application Development model) — это модель быстрой разработки приложений. Это своего рода ответвление инкрементной модели, так как процесс создания ПО происходит таким же образом с единственным исключением — над проектом работает сразу несколько команд. То есть в один момент времени параллельно существует несколько мини-проектов в одном большом проекте, которые интегрируются в рабочий прототип по мере готовности.

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

Iterative Model (итеративная модель)

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

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

Преимущества итеративной модели

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

Недостатки итеративной модели

Spiral Model (спиральная модель)

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

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

3. Что такое Agile и Lean: принципы разработки ПО

На основе семейства итеративных моделей также был придуман сверхпопулярный ныне гибкий подход к разработке ПО — Agile. И это, скорее, действительно подход, а не отдельная методология, потому что внутри проекта, который ведется по Agile, на разных этапах могут применяться и каскадные, и итерационные модели.

В основе подхода стоит разбиение разработки на множество отдельных задач, которые разные специалисты могут выполнять практически независимо друг от друга. Ежедневно проходят встречи команды (Scrum), где обсуждается текущий прогресс. Разработка при этом делится на этапы — так называемые спринты (Sprint), в ходе которых команда должна достигнуть определенного результата полностью закончить дизайн, показать базовую версию продукта и так далее .

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

Преимущества гибкой модели

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

Недостатки гибкой модели

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

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

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

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

В заключение, чтобы еще больше углубиться в эту большую тему, можно посмотреть это подробное видео:

Читайте также: