Предварительные условия, связанные с определением проблемы

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

Предварительные условия, связанные с выработкой требований

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

Важность явного набора требований обусловлена несколькими причинами.

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

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

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

 Адекватное определение требований - одно из важнейших условий успеха проекта.

Стабильность требований

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

3.1.2 Архитектура

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

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

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

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

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

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

 Архитектура должна определять основные компоненты программы. В зависимости от размера программы её компонентами могут быть отдельные классы или подсистемы, состоящие из нескольких классов. Каждый компонент является классом или набором классов/методов, которые в совокупности реализуют высокоуровневые функции программы, такие как взаимодействие с пользователем, отображение Web-странцы, интерпретация команд, инкапсуляция бизнес-правил и доступ к данным. За каждую функцию приложения, указанную в требованиях, должен отвечать хотя бы один компонент. Если функцию реализуют несколько компонентов, они должны сотрудничать, а не конфликтовать.

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

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

 Список типичных разделов архитектуры:

• Основные классы

• Организация данных

• Бизнес правила (и бизнес процессы)

• Пользовательский интерфейс

• Управление ресурсами

• Безопасность

• Взаимодействие с другими системами

• Интернационализация/локализация

• Обработка ошибок

• Возможность реализации архитектуры

• Готовые компоненты

• Повторное использование кода

• Стратегия внесения изменений

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

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

В архитектуре должны быть обоснованы важнейшие принятые решения.

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