3. Работа в группе

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

Б) Определение, будут ли программисты программировать парами, индивидуально или эти подходы будут скомбинированы.

4. Гарантия качества

Программисты должны будут разработать:

- тесты для своего кода до написания самого кода;

- блочные тесты для своего кода;

- перед включением своего кода в исходный код всего проекта проанализировать его в отладчике;

- выполнить интеграционное тестирование своего кода до его включения в исходный код проекта;

- выполнять взаимные обзоры или инспекцию кода.

Разработка архитектуры

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

1. Организация программы: описание системы

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

2. Основные классы

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

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

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

4. Бизнес-правила

Архитектура, зависимая от специфических бизнес-правил, должна определять их

и описывать их влияние на проект системы.

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

Пользовательский интерфейс (GUI) часто проектируется на этапе выработки требований. Если это не так, его следует определить на этапе разработки архитектуры. Архитектура должна описывать главные элементы формата Web-страниц, GUI, интерфейс командной строки и т. д.

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

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

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

7. Безопасность

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

8. Производительность

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

9. Масштабируемость

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

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

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

11. Ввод-вывод

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

12. Обработка ошибок

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

13. Отказоустойчивость

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

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

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