Использование Agile-подхода к созданию программного обеспечения

АННОТАЦИЯ

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

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

ABSTRACT

Businesses now operate in a global, rapidly changing environment. They must respond to new opportunities and markets, changing economic conditions, and the emergence of competitive products and services. Software is part of almost all business operations, so new software is quickly developed to take advantage of new opportunities and respond to competitive pressures. This is why fast development and delivery are now often the most important for demand-is-demand software systems.

The article discusses the Agile approach - these are small ways of growth and, as a rule, gradual development methods, in which new releases of the system are created and provided to customers every two or three weeks.

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

Keywords: system, software, security, Agile approach, fast methods, specification.

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

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

Некоторое время признавалась необходимость ускоренного развития системы и процессов, способных удовлетворить изменяющиеся требования. IBM ввела постепенную разработку в 1980-х годах. Введение так называемых языков четвертого поколения, а также идея быстрой разработки и доставки программного обеспечения были поддержаны в 80-х годах (Martin, 1981). Тем не менее, эта концепция действительно возникла в конце 1990-х годов с помощью быстрых подходов, таких как DSDM (Stapleton, 1997), Scrum (Schwaber and Beedle, 2001) и экстремальное программирование.

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

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

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

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

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

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

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

Пожалуй, самый популярный Agile-подход – экстремальное программирование (Bec, 1999; Bec, 2000). Другие быстрые подходы включают Scrum (Con, 2009; Schwaber, 2004; Schwaber & Beedle, 2001), Crystal (Cockburn, 2001; Cockburn, 2004), Adaptive Software Development (Highsmith, 2000), DSDM (Stapleton, 1997; Stapleton, 2003), “Feature Driven Development” (Palmer & felsing, 2002). Успех этих методов привел к слиянию с традиционными методами разработки, основанными на системном моделировании, что привело к концепции моделирования Agile (Ambler and Jeff, 2002).

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

Таблица 1.

Принципы подхода Agile.

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

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

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

На практике реализация принципов Agile-подхода иногда приводит к следующим трудностям:

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

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

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

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

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

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

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

Список литературы:

1. Ambler, S. W. and Jeffries, R. (2002). Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. New York: John Wiley & Sons.
2. Arisholm, E., Gallis, H., Dyba, T. and Sjoberg, D. I. K. (2007). ‘Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise’. IEEE Trans. on Software Eng., 33 (2), 65–86.
3. Astels, D. (2003). Test Driven Development: A Practical Guide. Upper Saddle River, NJ: Prentice Hall.
4. Rustamov  Kh.Sh.,  Khayriyev  F.N.  E-LEARNING  METHODOLOGEIS  AND FEATURES// Проблемы науки и образования, 2020. №9(57). С.67-72.
5. Khazratov F., Kh J. METHODS OF CREATION AND ORGANIZATION OF WORK //TECHNOLOGY FOR CREATING AUTO-NAVIGATION MAPS [Электронный ресурс]: URL: http://www. jcreview. com.
6. Khayriyev F. N. Using modern information technoligies in the lesson //International Journal of Psychosocial Rehabilitation. – 2020. – №. 5. – С. 3727-3734.
7. Атаева Г. И., Минич Л. С. СОЗДАНИЕ ВЫВОДА СКРИПТА PYTHON //  Вестник  науки  и  образования.  2021.  №1-2  (104).  URL: https://cyberleninka.ru/article/n/sozdanie-vyvoda-skripta-python