Архитектура системы к проекту "<название_проекта>"¶

<_Этот документ должен содержать описание внутренней архитектуры системы выполняемого проекта, созданной на основе SRS (Системных Требований) данного проекта. Цель документа - представить описание внутренней модели разрабатываемого продукта. Этот документ будет в последствии выполнять роль спецификации, по которой будет осуществляться разработка продукта командой разработчиков. Весь текст данного шаблона с применением курсива, заключённый в угловые скобки, должен быть либо заменён на конкретные сведения о проекте, либо удалён_.>

• Table of contents
• Архитектура системы к проекту "<название_проекта>"
  • Введение
    • Назначение системы
    • Обоснование выбранного дизайна
  • Техническая база и существующие системы
    • Техническая база
    • Существующие системы и архитектуры
      • Дружественность к пользователю
      • Простота использования
      • Надёжность
      • Высокая производительность
      • Минимальное число ошибок
      • Безопасность
      • Полнота функциональности
      • …
      • Подсистема A
      • …
    • Параллельная обработка
    • Привязка аппаратного/программного обеспечения
    • Управление данными
    • Управление глобальными ресурсами
    • Взаимодействие с глобальным ПО
      • Завершение
      • Исключительные ситуации
    • Объектная модель
    • Динамическая модель
  • Приложение 1: Словарь терминов

Введение¶

<Общее описание разрабатываемого документа. Все документы, на которые ссылается данная SRS, как то другие документы, Интернет-ссылки, добавьте на вкладку "References". Это могут быть документы по пользовательскому интерфейсу, контракты, стандарты, требования, сценарии работы и любые другие документы. Информации должно быть достаточно, чтобы пользователь мог иметь возможность прочтения, по крайней мере, копии этих документов, включая заголовок, автора, версию, дату создания и найти исходники или место размещения этих документов.>

Назначение системы¶

<Опишите здесь, для чего предназначена эта система. Если SRS содержит достаточно приемлемое описание назначения, то лучше просто вставить ссылку на этот раздел SRS.>

Обоснование выбранного дизайна¶

<Укажите здесь кратко причины, по которым был выбран данный дизайн системы. Если есть какие-то особые причины или требования заказчика, то по возможности приложите документы с этими требованиями.>

Техническая база и существующие системы¶

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

Техническая база¶

<Опишите здесь, какие продукты, алгоритмы, технологии etc лежат в основе данной архитектуры.>

Существующие системы и архитектуры¶

<Приведите здесь примеры существующих систем, если таковые существуют. По возможности добавьте ссылки на их описание или приложите документы с их описанием.>

Предлагаемая архитектура системы
h3. Цели и соглашения технического дизайна

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

Дружественность к пользователю¶

<...>

Простота использования¶

<...>

Надёжность¶

<...>

Высокая производительность¶

<...>

Минимальное число ошибок¶

<...>

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

<...>

Полнота функциональности¶

<...>

…¶

<...>

Декомпозиция подсистем
h4. Архитектура системы

<Приведите в этом разделе сначала диаграммы самого высокого уровня (можно использовать UML, диаграммы классов etc - всё, что позволяет наиболее точно описать систему.) Сюда же желательно включить также диаграммы, описывающие структуру железа.>

Подсистема A¶

<Кратко опишите подсистему. Не называйте её "Подсистема А", а постарайтесь дать ей осмысленное название.>

…¶

<...>

Параллельная обработка¶

<...>

Привязка аппаратного/программного обеспечения¶

<...>

Управление данными¶

<...>

Управление глобальными ресурсами¶

<...>

Взаимодействие с глобальным ПО¶

<...>

Граничные условия
h4. Граничные условия

<...>

Завершение¶

<...>

Исключительные ситуации¶

<...>

Объектная модель¶

<Produce and submit these Section in electronic form using your UML modelling tool (like Borland Together).>

Динамическая модель¶

<Produce and submit these Section in electronic form using your UML modelling tool (like Borland Together). Give the important dynamic views of your project.>

Приложение 1: Словарь терминов¶

<Сюда нужно включить список специфических терминов, акронимов и аббревиатур, ежели таковые используются в этом документе. Лучше в алфавитном порядке>