Файл: Особенности технологии разработки ПО.pdf

Автор методики, Скотт Амблер, выделил следующие ключевые позиции Agile Unified Process:

1. Команда знает, что делает;
2. Простота превыше всего.
3. Соответствие принципам гибкой методологии разработки.
4. Сфокусированность на ценных для проекта активностях.
5. Независимость в выборе инструментов.
6. Индивидуальная настройка AUP под нужды конкретного проекта.

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

Суть Agile Data Method определяется шестью положениями:

Данные — основа создания любого приложения.

1. Проблемы с проектом — их можно обнаружить только при чётком понимании цели и концепции проекта.
2. Рабочие группы — помимо непосредственной команды разработчиков есть enterprise groups, которые поддерживают другие рабочие группы.
3. Уникальность — нет идеальной методики, под каждый проект нужно комбинировать инструменты с разных методологий.
4. Работа в команде — совместная работа гораздо эффективнее, чем поодиночке.
5. «Сладкое пятно» — поиск оптимального решения проблемы («сладкого пятна»), избегая крайностей.

Essential Unified Process (EssUP) — это разработка шведского учёного Ивара Якобсона, созданная для улучшения Rational Unified Process.

EssUP оперирует понятием практики, в которые входят:

• сценарий использования — описание поведения системы.
• итерационная разработка — создание рабочих кусков кода короткими циклами в несколько недель.
• командные практики — направленные на сплочение команды и повышение её эффективности.
• процессуальные практики — например, «Думай глобально, начинай с малого» или «Вовлекайте стейкхолдеров в бизнес-процессы».

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

Getting Real (GR) — эффективная для стартапов и начинающих команд методология, которая предлагает по максимуму использовать особенности небольших проектов и компаний: мобильность, гибкость, поиск новых решений, отсутствие жёсткой запутанной иерархии и т.д. Джейсон Фрид и Давид Ханссон, основатели компании 37signals (теперь — Basecamp), определили Getting Real как систему для решения реальных задач: максимально простую, понятную и функциональную. [15]

GR — сборная группа из десятка инструментов гибкой разработки, которые используются для минимизации:

• возможностей;
• опций и настроек;
• структуры компании;
• встреч;
• обещаний.

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

OpenUP (OUP) — независимая от инструментов методология разработки ПО без жесткой структуры, которая содержит такие практики:

• измерение скорости работы команды;
• проведение ежедневных встреч и ретроспектив по завершению итераций;
• концепция микрошагов и раннего тестирования с использованием чеклистов;
• методика гибкого моделирования (AMDD).

Практики реализуются на основе четырех принципов:

• согласование интересов и достижение общего видения во время совместной работы
• непрерывное совершенствование через постоянную обратную связь
• фокусирование на архитектуре приложения на ранних стадиях для минимизации рисков
• максимизация ценности для конечного потребителя.
• непрерывное совершенствование через постоянную обратную связь. [15]

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

Для большинства проектов хватит 4 направлений метрик:

1. Производительность — сюда относятся Velocity и WIP. Первая подойдёт не для всех проектов, так как идет измеряются количество выполненных задач в итерацию, а они неравнозначны. Метрика Work-in-Progress определяет лимит задач на разных стадиях: и чем он выше, тем хуже;
2. Прогнозирование — метрика capacity: определение количества идеальных часов, доступных в следующем спринте. Соответственно, можно понять, сколько времени есть на работу, насколько эффективно выполнение задач и как спланировать количество задач для спринта;
3. Качество — например, индекс стабильности требований, который рассчитывается по формуле = (Общее количество оригинальных бизнес-требований + Число требований, которые поменялись к этому времени + Число добавленных требований + Число убранных требований) / (общее число оригинальных требований). С помощью метрики определяется количество времени, затраченное на переделывание задач;
4. Ценности — в каждом случае просчитывается индивидуально, зависимо от формата проекта. Например, стартап AirBnb в качестве метрики, определяющую конечную ценность продукта для пользователей, выбрала количество загруженных фотографий высокого качества. С их увеличением пропорционально росло и количество потребителей.

К метрикам применимы те же правила, что и к другим Agile-инструментам. [15]

Нет единственно верной или нужной проекту метрики. Их нужно постоянно пересматривать, отбрасывать устаревшие и добавлять новые по мере необходимости. Она должна быть понятна и доступна всей всей команде, не превращаться в самоцель. Метрика ради метрики — плохое решение.

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

1. Agile подойдет для всех проектов.

Самое упорное заблуждение. Ни один метод Agile не добавит сам по себе ценности продукту и не смотивирует команду.

2. Agile против документации.

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

3. Agile и планирование несовместимы.

Опровержением этого мифа служат дневные планирования с 10-минутными стэндапами, итерационное планирование каждые две недели, спринт-встречи и т.д.

4. Agile требует много переделывания (re-work).

В гибкой методологии разработки ПО переделывание проявляется в двух формах: переделывание требований (пользователи понимают, что им действительно нужно) и программного обеспечения (команды разработчиков находят улучшенные способы написать и спроектировать приложение). Но с этим приходится сталкиваться и в других методиках! Более того, для уменьшения негативного влияния rework и нужна итерационная модель, которая является особенностью Agile. [15]

Плюсы использования Agile следующие:

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

Минусы:

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

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

ЗАКЛЮЧЕНИЕ

В рамках работы решены следующие задачи:

• раскрыто понятие «программное обеспечение»;
• изучены основные принципы проектирования программного обеспечения;
• проанализированы этапы создания программного продукта;
• рассмотрены модели жизненного цикла;
• изучены гибкие методологии.

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Богданов В. Управление проектами. Корпоративная система – шаг за шагом. — Манн, Иванов и Фербер (МИФ), 2012. — 241 с.
2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. — Финансы и статистика, 2005. — 544 с.
3. Вольфсон Б. Гибкое управление проектами и продуктами. — Питер, 2016. — 160 с.
4. Джефф Паттон Пользовательские истории. Искусство гибкой разработки ПО. — Питер, 2014. — 400 с.
5. Джефф Сазерленд Scrum. Революционный метод управления проектами. — Манн, Иванов и Фербер (МИФ), 2014. — 320 с.
6. Дженнифер Дэвис, Кэтрин Дэниелс Философия DevOps. Искусство управления IT. — Питер, 2016. — 610 с.
7. Мартин Клеппман Высоконагруженные приложения. Программирование, масштабирование, поддержка. — Питер, 2017. — 640 с.
8. Эндрю Стеллман, Дженнифер Грин Постигая Agile. — Манн, Иванов и Фербер (МИФ), 2015. — 650 с.
9. Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong, Richard Turner The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software. — Addison-Wesley Professional, 2014. — 336 p.
10. Chris Sims, Hillary Louise Johnson Scrum: a Breathtakingly Brief and Agile Introduction. — Dymaxicon, 2012. — 54 p.
11. John Ousterhout A Philosophy of Software Design. — Yaknyam Press, 2018. — 190 p.
12. Joyce Farrell Programming Logic & Design, Comprehensive. — Cengage Learning, 2017. — 656 p.
13. Life-Prog [Электронный ресурс] Основные понятия. Программный продукт Режим доступа: https://life-prog.ru/2_13687_osnovnie-ponyatiya-programmniy-produkt.html Дата обращения (19.01.2019)
14. Технология программирования [Электронный ресурс] Технология разработки программного обеспечения. Режим доступа: http://www.tehprog.ru/index.php_page=lecture12.html Дата обращения (19.01.2019)
15. WorkSection [Электронный ресурс] Методология Agile. Матерь драконов или всех гибких методологий. Режим доступа: https://worksection.com/blog/agile.html Дата обращения (19.01.2019)