System architecture

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

Определение Agile стало популярным в контексте "Manifesto for Agile Software Development". Принципы и подходы описанные в этом манифесте были подкреплены широким спектром методик разработки программного обеспечения, таких как Scrum и Kanban.

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

Итак, основные ценности гибкой разработки, описанные в Манифесте: - Люди и взаимодействие превыше процессов и инструментов - Рабочее программное обеспечение превыше полной документации - Взаимодействие с клиентами важнее обсуждения контракта - Реакция на изменения важнее следования планам

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

Принципы гибкой разработки: 1. Удовлетворенность клиента ранней 

2. Изменения требований приветствуются, даже на поздних этапах разработки

3. Поставки рабочего софта происходят часто (недели, а не месяцы)

4. Тесное, ежедневное сотрудничество между бизнесом и разработкой

5. Проекты строятся вокруг мотивированных доверенных членов команды

6. Личное общение - лучшая форма коммуникации. Совместное размещение - идеально  

7. Рабочий софт - лучшая мера прогресса

8. Устойчивая разработка, спосообная поддерживать постоянный темп

9. Постоянное стремление к техническому совершенству и хорошей архитектуре

10. Простота - исскуство максимизации количества НЕ сделанной работы. Необходимость

11. Лучшие архитектурные решения, требования и дизайн создают самоорганизованные команды

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

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

- System and software requirements: captured in a product requirements document - Analysis: resulting in models, schema, and business rules - Design: resulting in the software architecture - Coding: the development, proving, and integration of software - Testing: the systematic discovery and debugging of defects - Operations: the installation, migration, support, and maintenance of complete systems

Часто бывает что первые два пункта путают и стремяться обьединить в один. Чего категорически делать нельзя. System and software requirements говорит ЧТО должно быть сделано и какие возможности должны быть предоставлены конечным пользователям чтобы выполнить все обязательства по контрактам между разработчиком и стейкхолдорами. И, главное, ЧТО должно быть предоставлено пользователям для решения их изначальных задач и целей.

Analysis в свою очередь описывает какими методами и средствами будет обеспечиваться выполнение договоренности. Новые изменения в системе могут изменять среду и отношения между людьми поэтому важнейшей частью является выявление всех заинтересованных лиц и разрешение конфликтов между требованиях. Также важно убедиться что все стейкхолдеры отчетливо понимают и принимают изменения в системе. Основные методы улучшения и анализа требований: - Визуализация. Использование иструментов которые помогут визуально отобразить (или симулировать) конечный продукт - Последовательные шаблоны. Создание набора шаблонов чтобы показать пошаговое использование продукта и документировать требования - Документирование зависимостей. Связывание зависимостей в требованиях проекта что позволяет легко отслеживать изменения

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

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

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

Распределение времени обычное для проектов которые используют waterfall: - От 20% до 40% на выявление требований и их анализ - От 30% до 40% на реализацию - Оставшееся время тратится на процесс тестирования, установку и поддержку