Глава посвящена необходимости соблюдения предварительных условий перед непосредственным написанием кода.
Исходя из различных исследований, ошибки, которые были допущены до этапа кодирования, обычно очень сильно влияют на продолжительность и бюджет проекта, так как чем позже эти ошибки обнаружены, тем сложнее их исправить. В этом смысле выгодно отличаются гибкие методологии, реализующие различные варианты итеративной разработки, поскольку на каждой итерации происходит уточнение требований и шанс на обнаружение ошибки повышается.
Вообще эти самые предварительные условия состоят из трёх следующих этапов:
Эта формулировка должна быть полностью понятна пользователю и не должна содержать технический деталей или способа решения проблемы, только саму проблему.
Выработка требований - отдельная сложная наука. В данной главе в основном приводится список критериев, по которым мы можем определить насколько хорошо эти требования были выработаны. Требования описывают систему с точки зрения пользователя - что должно получаться на выходе, когда мы подаём определённые данные на вход, какова должна быть надёжность системы, каковы предельно допустимые показатели производительности и т.д. Если если эти требования не сформулированы, то программисты и архитекторы не могут до конца понять, чего от них хотят.
При создании архитектуры нужно определить основной костяк разрабатываемой системы - выделить основные компоненты, продумать схему хранения данных, если они должны храниться, продумать возможности для расширения(обеспечить точки роста). Также сюда относится определение слоя, в котором будут храниться бизнес-правила + вопросы безопасности, производительности, взаимодействия с другими системами, I18n, обработки ошибок, отказоустойчивости. В общем к хорошей архитектуре выдвигается достаточно много требований. Также приводится чеклист, который позволяет оценить, насколько хороша разработанная архитектура.
В гибких методологиях, насколько я знаю, все эти этапы выполняются на каждой итерации, что обеспечивает стабильность разработки при изменении хотелок пользователей. Ещё где-то в начале главы есть клёвая табличка, в которой описывается, какие техники чаще всего применяются для разработки различных видов ПО - в общем и целом получается, что для разработки бизнес-приложений выгоднее применять не очень формальную итеративную разработку, а при создании систем от которых зависят человеческие жизни, необходимо подходить ко всему с большей долей формальности и возможно будет более выгодным линейный подход(waterfall).
Исходя из различных исследований, ошибки, которые были допущены до этапа кодирования, обычно очень сильно влияют на продолжительность и бюджет проекта, так как чем позже эти ошибки обнаружены, тем сложнее их исправить. В этом смысле выгодно отличаются гибкие методологии, реализующие различные варианты итеративной разработки, поскольку на каждой итерации происходит уточнение требований и шанс на обнаружение ошибки повышается.
Вообще эти самые предварительные условия состоят из трёх следующих этапов:
- Определение проблемы
- Выработка требований
- Создание архитектуры
Эта формулировка должна быть полностью понятна пользователю и не должна содержать технический деталей или способа решения проблемы, только саму проблему.
Выработка требований - отдельная сложная наука. В данной главе в основном приводится список критериев, по которым мы можем определить насколько хорошо эти требования были выработаны. Требования описывают систему с точки зрения пользователя - что должно получаться на выходе, когда мы подаём определённые данные на вход, какова должна быть надёжность системы, каковы предельно допустимые показатели производительности и т.д. Если если эти требования не сформулированы, то программисты и архитекторы не могут до конца понять, чего от них хотят.
При создании архитектуры нужно определить основной костяк разрабатываемой системы - выделить основные компоненты, продумать схему хранения данных, если они должны храниться, продумать возможности для расширения(обеспечить точки роста). Также сюда относится определение слоя, в котором будут храниться бизнес-правила + вопросы безопасности, производительности, взаимодействия с другими системами, I18n, обработки ошибок, отказоустойчивости. В общем к хорошей архитектуре выдвигается достаточно много требований. Также приводится чеклист, который позволяет оценить, насколько хороша разработанная архитектура.
В гибких методологиях, насколько я знаю, все эти этапы выполняются на каждой итерации, что обеспечивает стабильность разработки при изменении хотелок пользователей. Ещё где-то в начале главы есть клёвая табличка, в которой описывается, какие техники чаще всего применяются для разработки различных видов ПО - в общем и целом получается, что для разработки бизнес-приложений выгоднее применять не очень формальную итеративную разработку, а при создании систем от которых зависят человеческие жизни, необходимо подходить ко всему с большей долей формальности и возможно будет более выгодным линейный подход(waterfall).
Комментариев нет:
Отправить комментарий