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

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

Представьте, что ваша кредитная карта внезапно перестает работать, потому что она не поддерживается последней версией программного обеспечения, развернутой вчера!

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

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

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

О содержании конструкторской документации мы уже говорили. Теперь пришло время сказать несколько слов о стиле .

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

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

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

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

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

Этот вводный раздел поможет читателю определить, полезен ли ему этот документ.

Включите в документ следующие разделы:

1. Начните с раздела Обзор , который поможет читателю решить, полезен ли ему этот документ
2. Глоссарий терминов и сокращений : очень полезно, когда аудитория является новой или имеет смешанный набор навыков
3. Приложения : этот раздел защищает обычного читателя от неинтересных подробностей, которые могут не иметь к нему прямого отношения
4. Таблица ссылок для документов, на которые ссылаются при подготовке проекта решения, таких как документ бизнес-требований (BRD). Это, вероятно, гораздо важнее, чем кажется, поскольку создает основу, на которой строится текущий дизайн. Кроме того, это поможет запустить правильный процесс управления изменениями в случае изменения спецификаций.

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

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

Неясные требования являются причиной №1 неудач ИТ-проектов . Убедитесь, что вы четко обозначили, что входит в сферу охвата, а что нет. Пересматривайте область видимости только в случае крайней необходимости, чтобы предотвратить ее расползание.

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

LLD должен четко определять границы того, что входит в сферу действия, а что нет.

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

1. Создание однозначного соответствия между проектом и требованиями в BRD
2. Создание макетов новых экранов
3. Включить раздел, выходящий за рамки. Это один из способов избежать бесплатной работы!
4. Выполнить полный анализ воздействия и включить все возможные последствия
5. Четко указать все технические решения, принятые при проектировании системы

Программное обеспечение — сложный бизнес, и LDD должен попытаться распутать как можно больше этой сложности.

Используйте приведенные ниже вопросы, чтобы определить, достаточно ли ясен LDD.

1. Какие предположения были сделаны при проектировании?
2. Какие важные решения были приняты и как были сделаны выводы?
3. Налагает ли дизайн какие-либо ограничения на будущая эволюция продукта?
4. Имеется ли  достаточно информации  (текст, визуализации, таблицы, диаграммы, технологические процессы), чтобы помочь усвоить более сложные идеи?
5. Каковы предпосылки для каждой задачи?
6. Остались открытые вопросы ?
7. Что ожидается от различных заинтересованных сторон (внутренних и внешних)?
8. Будут ли предлагаемые изменения создавать какие-либо обозримые проблемы интеграции в экосистему?
9. Повлияет ли изменение на другие функции (функции, данные, отчеты, взаимодействие с пользователем) или изменит его ?
10. Как будут затронуты другие группы (например, службы поддержки и эксплуатации)   ?
11. Можно ли спокойно реализовать проект, если дизайнер в отпуске на пару недель?
12. Были ли  риски, связанные с бюджетом, сроками, доступностью услуг и качеством обслуживания клиентов,  правильно сведены в таблицу и разработаны меры по их снижению?

6. 4 Будьте точны

Точность сама по себе является наградой.

Анонимный

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

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

Кроме того, недостаточно быть точным; вам нужно быть точным.

Это может привести только к откладыванию проектных решений на этап разработки и необходимости проектирования на лету.

Чтобы проиллюстрировать это, рассмотрим утверждение «Возраст человека составляет от 0 до 200 лет». Это довольно точно, но не очень точно. Гораздо более уместным было бы выражение: «Возраст этого человека 70+ или – 5 лет».

6. 4.2 Как это сделать

Вот три шага, которые сделают ваши документы более понятными:

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

Имея четкую позицию по каждому вопросу, не будет путей отступления, когда что-то пойдет не так. Эта стратегия гарантирует приверженность каждого.

Лучший способ оценить ясность и полноту — получить отзывы от сотрудников и заинтересованных сторон. Этого можно достичь путем организации сеансов, на которых дизайн может быть «оспорен» и изучены альтернативные пути.

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

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

Хороший тест на полноту может быть таким: если автор решит уйти в двухнедельный отпуск, сможет ли работа возобновиться бесперебойно и эффективно за все время ее отсутствия?

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

Создайте документ, который будет легко читать целевой аудитории. Тесты на удобочитаемость (Флеша-Кинкейда) измеряют, насколько простым или сложным является отрывок.

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

Следующий список должен помочь вашему читателю без труда просмотреть документ.

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

Используйте приведенные ниже темы в качестве основы для шаблона документа Solution Design:

• Обзор или введение :
  • Его может легко прочитать и понять любой.
  • Позволяет читателю определить, полезен/доступен ли ему этот документ.
• Обзор существующих функций:
  • Предоставляет контекст и справочную информацию, связывая новые требования с существующими через внешние ссылки.
• Детали требования:
  • Разбивка бизнес-требований с комментариями и обсуждениями.
  • Требования высокого уровня должны сопоставляться с BRD. Низкоуровневые требования должны соответствовать спецификациям компонентов.
  • Помогает определить, какие требования уже выполнены, исключены или требуют дальнейшего уточнения.
• Допущения и предпосылки:
  • Это неотъемлемая часть процесса проектирования. Его цель состоит в том, чтобы убедиться, что всем понятны основы дизайна.
  • Это также позволит заранее оценить, являются ли эти предположения обоснованными, приемлемыми или требуют проверки.
• Дизайн высокого уровня:
  • Этот раздел предназначен для предоставления обновлений технологического процесса и изменений путей передачи информации с использованием диаграмм, таблиц и других визуализаций.
  • Обычно также решает проблемы интеграции с другими системами.
  • Не следует путать с проектным документом высокого уровня (HLD), который содержит дублирующую информацию, но гораздо больше информации о решении.
• Низкоуровневый дизайн:
  • Подробно описывает низкоуровневые требования подкомпонентов и подмодулей.
  • Этого можно добиться с помощью блок-схем, псевдокодов и блок-схем.
  • Цель состоит в том, чтобы точно определить ожидаемые файлы исходного кода, таблицы моделей данных и функции, которые необходимо изменить.
  • Это также даст тестировщикам представление о масштабах изменений и поможет управлять общими усилиями по тестированию.
  • Этот раздел в равной степени охватывает обработку исключений и негативные сценарии.
• Анализ воздействия:
  • Обсуждается влияние на существующие версии продукта, уже находящиеся в производстве. Также обсуждается любая возможная деградация или прерывание обслуживания после обновления.
  • Может принимать форму двунаправленной матрицы прослеживаемости. Последнее чрезвычайно полезно для связывания бизнес-требований с фрагментами кода и конкретными тестовыми примерами, а также пользовательской документацией.
• Вне области: 
  • Необходим для взаимного понимания того, что не будет охвачено в текущем проекте.
  • Помогает зафиксировать прицел и избежать потенциального смещения прицела.
• Риски и их снижение:  Риски могут возникать в виде:
  • Внешние зависимости от наличия сторонних компонентов в программных модулях, спецификациях, отзывах, доступности ресурсов и т. д.
  • Проблемы с регрессией возникают из-за устаревшего кода, плохой документации или ошибочной архитектуры или дизайна программного обеспечения.
  • Неполные требования требуют отложить принятие решений до начала проекта.
  • Любые отсутствующие или недоступные предварительные условия для программистов, тестировщиков или операций, таких как инструменты, тестовые среды и т. д.
• Приложения:
  • Дополнительная информация, которая может быть слишком подробной или не совсем относящейся к обсуждаемым темам
  • Она может быть представлена ​​для полноты и ясности.

Solution-Design-Document-TemplateDownload

8. Заключение

Старайтесь избегать соблазна погрузиться в разработку или внедрение сразу после закрытия продажи. Это действие является распространенной ошибкой, которая подвергает ваш проект ненужному риску.

Инвестирование в усилия по проектированию привлекает всех, позволяет всем заинтересованным сторонам высказать свои опасения и не позволяет проекту основываться на предположениях, а не на фактах.

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

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

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

Избегайте дешевых и пустых лозунгов типа «у нас нет времени». Искорените проблемы, которые мешают вам найти время для качественной работы.

9. Рекомендуемые статьи

Рецензия на книгу: Путь шести сигм — как GE, Motorola и другие ведущие компании оттачивают свою эффективность

7 ноября 2021 г.

Моделирование распространения COVID-19: Часть 4: Модель SEIR-COVID

16 июля 2020 г.

Управление процессами, их совершенствование и редизайн: основное руководство по повышению производительности

23 ноября 2021 г.

Операционное превосходство в 7 цитатах от его отцов-основателей

1 августа 2021 г.

DevOps: поиск пути к успешному и постоянному совершенствованию

25 июля 2021 г.

Квантовые вычисления, помимо кубитов. Часть 3: ИИ, оптимизация и квантовый отжиг

31 октября 2021 г.

Принятие решений в профессиональной среде: приемы и подводные камни

7 июля 2021 г.

Управление водопадными проектами: краткая история и введение

7 августа 2022 г.

Оценка программного обеспечения: как сделать все правильно с первого раза

4 июля 2021 г.

Культурные преобразования и сопротивление изменениям: понимание рисков для роста вашей организации

17 июля 2021 г.

Что это такое и когда он вам нужен?

1. Обзор

Для всех ИТ-проектов требуется высокоуровневый проект решения, также известный как HLD, артефакт, необходимый на этапе анализа SDLC.

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

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

Прежде чем мы продолжим, нужно сделать две заметки:

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

• Проектирование высокого и низкого уровня — HLD не следует путать с проектом низкоуровневого решения (или LLD), основная роль которого заключается в декомпозиции систем, определенных в HLD, на подсистемы, подкомпоненты и, что наиболее важно, , выберите оптимальные значения для ключевых проектных и операционных параметров, заложенных в архитектуре.

Эта статья предназначена для ИТ-проектов. Он объяснит, что такое HLD и зачем он вам нужен, прежде чем, наконец, предоставить шаблон того, что он должен содержать.

2. Содержание

Повестка дня

1. 1. Обзор
2. 2. Содержание
3. 3. Проектная документация высокого уровня (HLD)
   • 3.1 Что такое проектная документация высокого уровня
   • 3.2 Зачем нужен HLD
   2 3.2 Зачем нужен HLD 2 Не идти сразу к LLD?
   • 3.4 Когда требуется проект высокого уровня
   • 3.5 Кому принадлежит проектный документ высокого уровня
4. 4. Документы по архитектуре программного обеспечения
   • 4.1 Что такое архитектура программного обеспечения
   • 4.2 Архитектурные документы
   • 4.2 Архитектурные документы 9012 Гибкий?
5. 5. Шаблон проектной документации высокого уровня (ДВУ)
   • 5.1 Структура и форма ДВУ
   • 5.2 Содержание ДВУ
   • 5.3 Скачать шаблон
6. . a Высокоуровневый проектный документ

   Высокоуровневый проектный документ (HLD) — это немного технический документ для (обычно) нетехнической аудитории.

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

   Он в основном состоит из следующих элементов:

   1. Краткое описание решения:  Сохраняя обсуждение на высоком уровне, HLD описывает основные функции, которые оно предоставит. Для ясности лучше всего перечислить все элементы, не вдаваясь в подробности реализации, так как эти аспекты, вероятно, не для этой конкретной аудитории. Примерами нефункциональных требований являются производительность, высокая доступность, безопасность и соответствие требованиям.
   1. Высокоуровневая диаграмма сети и архитектуры: , показывающая важные компоненты системы (платформы, приложения, серверы, сетевые устройства, специализированное оборудование). Его цель — выделить аппаратные компоненты и сторонние системы, затронутые этим проектом. Убедитесь, что вы используете согласованный язык системного моделирования на всех ваших диаграммах.
   1. Логическая структура различных прикладных модулей и компонентов  иногда необходимо, если решение сложное, добавляются новые модули или обновляются существующие. В этом разделе подробно описано, нужны ли для работы этого проекта новые модули, наборы навыков, лицензии или операционные требования.
   1. Бизнес-процессы, варианты использования и пользовательские истории: Решения обычно добавляют или изменяют варианты использования. Если вводятся новые пользовательские интерфейсы и бизнес-функции, они должны быть соответствующим образом задокументированы, поскольку они могут потребовать дополнительных усилий, таких как обновление руководств по полевым операциям и типовой документации, а также обучение работе с новой системой.
   1. Поток данных описывает входные и выходные данные и их путь в системе. Захват, обработка, хранение, репликация, проверка и вывод — все это аспекты потока данных, которые необходимо документировать.
   1. Другие представления решения:  В дополнение к более популярным методам декомпозиции, представленным выше, решение может быть представлено в нескольких различных представлениях: поведенческом, временном потоке, состояниях и режимах.
   3.2 Зачем вам нужен HLD

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

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

   HLD обычно поставляется с Функциональные спецификации  в качестве вспомогательных документов для Технического задания  (SOW).

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

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

   Помните, что главная причина провала ИТ-проектов — это неясные бизнес-требования, за которыми следуют плохие возможности доставки.

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

   Управление ожиданиями заинтересованных сторон жизненно важно для бесперебойной доставки и удовлетворения клиентов.

   3.3 Почему бы не обратиться сразу к LLD?

   LLD требует больших усилий по проектированию и обычно включает гораздо более широкую аудиторию технического персонала (разработчики, тестировщики, инженеры DevOps).

   Вы не можете оправдать эти усилия на данном этапе проекта, главным образом потому, что объем проекта еще не утвержден, а внутренние и внешние заинтересованные стороны еще не согласовали результаты.

   Помните, что HLD является одним из документов, сопровождающих SoW, поэтому мы все еще находимся на этапе анализа.

   HLD фокусируется на общая картина , в то время как LLD фокусируется на технических деталях и деталях реализации, которые на данном этапе еще не подтверждены.

   3.4 Когда требуется проектирование высокого уровня

   HLD обычно подготавливается в начале проекта программного обеспечения, как правило, на этапе анализа SDLC.

   HLD Требуется на этапе анализа

   Сопровождается ТЗ, чтобы обеспечить ясность концепций решения на высоком уровне.

   3.5 Кому принадлежит проектная документация верхнего уровня

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

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

   Так кто же такой дизайнер/архитектор решений?

   Архитектор решений или разработчик решений — высококвалифицированный технический ресурс  кто хорошо разбирается в:

   •   Бизнес-аспекты проекта:  Они хорошо понимают отрасль и сквозные бизнес-требования. Как правило, это высокопоставленные лица в организации. Они знакомы с важными деловыми и техническими решениями, принятыми на протяжении всей истории приложений.
   • Состояние текущих систем:  Архитектор понимает слабые места системы и может предложить способы их устранения. Они также имеют полное представление о взаимодействии между различными компонентами и могут быстро оценить влияние любого изменения.
   • Технология, на которой работают эти системы:  Архитекторы хорошо осведомлены о преимуществах и недостатках технологии, проблемах и сильных сторонах, а также о том, как они соотносятся с альтернативами на рынке.
   • Любое соответствие или нормативные требования:  Этот навык обеспечивает соответствие системы требованиям и учет в проектах таких условий.

   В Agile самоорганизующиеся команды обычно предпочтительнее традиционной иерархической структуры. Agile-манифест признает это по следующему принципу:

   ---

   ---

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

   ---

   4. Документы по архитектуре программного обеспечения

   4.1 Что такое архитектура программного обеспечения

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

   Что такое архитектура программного обеспечения

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

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

   Мы нашли определение Мартина Фаулера весьма ясным:

   ---

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

   Martin Fowler

   ---

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

   4.2 Архитектурные документы

   По сути, к большинству проектов относятся два архитектурных документа: проект высокого уровня (HLD), который мы обсуждаем в этой статье, и проект низкоуровневого решения (LLD).

   Посмотрите на таблицу ниже, чтобы лучше понять, когда и где эти документы сходятся или расходятся.

   37.

   Property	High-Level Design (HLD)	Low-Level Design (LLD)
   Essential	Yes	Yes
   SDLC Stage	Analysis	Design
   Content	Non-technical	Technical
   Audience	Project Sponsors	Developers, Технический персонал, тестировщики, инженеры DevOps
   Владелец	АРХИТЕКТА / ВЫПУСКА ЛИЦА	АРХИТЕКТА / ВЫХОДНЫЙ ДЕЙСТВИЯ
   9000
   ТЗ поддержки	Разработка привода и задачи тестирования
   Темы	Система и решение архитектура, вариантов использования, поток данных	Дизайн функций, анализ влияния, соображения по проектированию

   Сравнение архитектурных документов
   4.3 Архитектурные документы Актуальны для Agile?

   По нашему мнению, Agile-практики иногда демонстрируют неправильное представление о ценности документации.

   Некоторые Agile-профессионалы даже проповедовали полный отказ от документации в ее традиционной форме. Но это не совсем то, чего хотели создатели Agile. Однако в Agile-манифесте они указали следующее:

   ---

   A) Рабочее программное обеспечение превыше исчерпывающей документации
   B) Реагирование на изменение в соответствии с планом

   Agile-манифест

   ---

   Это сильно отличается, скажем, от отсутствия документации или планирования!

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

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

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

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

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

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

   Оценка программного обеспечения

   Инструкции, как сделать это правильно!

   ---

   5.1 Структура и форма HLD

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

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

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

   1. Четкий и краткий язык без двусмысленности или открытых вопросов:  обычно мы хотим свести к минимуму любые возможности недопонимания в результате необоснованных предположений.
   1. Структура, которую легко читать и следовать:  Используйте пробелы в своих интересах. Разделите различные идеи и концепции на абзацы и разделы, где это применимо.
   1. Вспомогательные разделы, такие как Обзор, Глоссарий, Справочник и Целевая аудитория:  Старайтесь не оставлять читателя в неведении относительно сокращений, внешних ссылок и контекстно-зависимых терминов.
   1. Полнота:  Не упускайте важные темы. Если конкретный вопрос не имеет отношения к делу, отметьте его, чтобы читатель знал, что эта тема обсуждалась, но признана неактуальной для данного проекта.

   Эти рекомендации должны охватывать форму и структуру ДВУ. Следующие разделы охватывают содержание.

   5.2 Содержание ДВУ
   5.2.1 Архитектурный план

   Архитектурный план является первым компонентом проектной документации высокого уровня (ДВУ). Он служит для описания:

   1. Все основные компоненты ИТ-решения
   2. Как они вписываются в общую ИТ-экосистему, которую мы называем контекстом
   3. Различные соединения, которые помогают интегрировать эти компоненты вместе

   Вы также можете включить следующую информацию:

   1. IP-адреса и порты, используемые ссылками
   2. Брандмауэры, которые необходимо обновить
   3. Новые серверы, которые необходимо подготовить
   4. Новые лицензии, которые необходимо приобрести или обновить
   5. Географические местоположения в случае, если серверы не находятся в одном центре обработки данных

   Создание дополнительных диаграмм при необходимости

   Каждая диаграмма должна иметь только одну цель. Создайте две отдельные схемы для описания нескольких аспектов решения (например, оборудования и безопасности).

   Диаграмма ниже должна иллюстрировать идею:

   Архитектурный план или контекст

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

   Пример 1: сервер и сеть, план

   В этом случае компоненты на диаграмме могут быть физическими серверами (или виртуальными машинами), взаимодействующими по каналам TCP/IP.

   Эта диаграмма, вероятно, является лучшим местом для добавления любых брандмауэров или сетевых маршрутизаторов, которые могут быть установлены или настроены для работы системы.

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

   Пример 2: План приложений и служб

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

   Взаимодействия между этими компонентами обычно представляют собой API или общие ссылки для обмена сообщениями.

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

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

   5.2.2 Модули приложений

   После того, как вы завершили описание всех основных компонентов экосистемы решения, пришло время перейти к уровню приложения. Следующая тема, которую вы должны включить, — это детали уровня приложения в проект высокого уровня (HLD).

   Схема уровня приложения обычно выглядит следующим образом:

   На этом этапе вы определите различные подсистемы приложения. Это могут быть:

   • Основные компоненты:  обеспечивают базовые ИТ-функции и могут иметь или не иметь отношения к отрасли. Например, архитектура Enterprise Message Bus является типичным архитектурным шаблоном практически для любой ИТ-системы онлайн-обработки транзакций. Для HLD сведите эти компоненты к минимуму, так как они могут быть не особенно интересны бизнес-аудитории.
   • Пользовательские интерфейсы и слои:  могут сообщить читателю, какой тип пользователей будет взаимодействовать с системой или конкретным компонентом. Эта информация сигнализирует об изменениях на операционном уровне. За такими изменениями обычно следуют обучение, обновления руководств пользователя и обучение пользователей, и они необходимы для информирования клиента задолго до разработки.
   • Уровень базы данных:  , где находятся все данные. Хранение данных и управление ими, хотя и не очень увлекательно, обычно затрагивают такие темы, как резервное копирование, аварийное восстановление, избыточность и высокая доступность, которые имеют решающее значение для бесперебойной работы и непрерывности бизнеса.
   • Модули бизнес-логики:  обеспечивают бизнес-функциональность системы. Например, розничный бизнес может иметь компоненты выставления счетов, электронной коммерции, доставки, складирования и бизнес-аналитики.
   • Лицензионные компоненты:  могут быть интересны для бизнес-аудитории, поскольку для них требуется бюджет и поиск поставщиков. Важно указать на них как на часть предлагаемого решения.
   • API и внешние подключения  необходимо вызывать, поскольку они обычно используются в контексте интеграции со сторонними системами и должны учитываться при разработке, интеграции и тестировании. Как и любую другую зависимость, их также необходимо учитывать на стороне управления проектом.

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

   5.2.3 Поток данных и варианты использования

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

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

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

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

   Бизнес-процессы

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

   Убедитесь, что этот раздел вашего проекта высокого уровня (HLD) удовлетворяет следующим требованиям:

   • Список всех сторон/пользователей/систем вовлеченных
   • Определить все этапы процесса при установление собственности и ответственности (схема дорожек может быть очень полезной)
   • Убедитесь, что критерии перехода между этапами также понятны (входы, выходы, задачи, которые необходимо выполнить между этапами)
   • Перечислите результаты каждого процесса и время, когда он считается выполненным. »

   Пример: Открытие банковского счета

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

   В этом процессе обычно участвуют несколько человек в этом филиале. Каждый человек отвечает за определенный этап процесса утверждения заявки.

   5.3 Загрузка шаблона

   Воспользуйтесь приведенной ниже ссылкой, чтобы загрузить базовый шаблон высокоуровневого проектирования (HLD).

   High-Level-Solution-Design-Document-TemplateDownload

   ---

   6. Язык моделирования систем

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

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

   Ниже приведен список этих проблем:

   • Естественный язык может быть двусмысленным, и одно и то же предложение может быть открыто для различных интерпретаций.
   • Ошибки трудно обнаружить.
   • Оба склонны допускать различную глубину и строгость описания для уровней декомпозиции или компонентов системы.
   • Документы, написанные на естественном языке, могут подавлять когнитивные способности любого человека. В результате получаются груды документов, которые никто не будет читать.
   6.2 Методология объектных процессов (OPM)

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

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

   • Язык описывает объекты и то, как они соотносятся, группируются, классифицируются и подразделяются. Поскольку объекты могут означать разные вещи в разных контекстах, возникла особая ветвь философии, называемая онтологической инженерией. Его задача состоит в том, чтобы преодолеть междоменную проблему связывания разных значений с разными терминами.
   • Значение, связанное с этими объектами: семантика – это соответствующая область исследования.
   • Грамматика позволит правильно строить сложные «предложения». Эти правила называются синтаксисом.

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

   Универсальный, мощный и не зависящий от предметной области язык системного моделирования был достаточно важным, чтобы заслужить собственный стандарт ISO, ISO/PAS 19450:2015.

   Этот стандарт ISO называется OPM или методология объектного процесса. OPM определяет следующие понятия:

   1. Организации:
      1. Объекты : список сущностей и строительных блоков системы.
      2. Состояния объекта : объект может находиться в одном из нескольких состояний в течение своей жизни и переходить из одного состояния в другое.
      3. Процессы  – это преобразования, которые применяются к объектам. Процессы могут создавать, уничтожать или преобразовывать объекты между различными состояниями объекта.
   2. Ссылки:
      1. Структурные связи определяют ассоциации между объектами (композиция, наследование, экспозиция, конкретизация)
      2. Процедурный  , обозначающий, как объекты, состояния и процессы влияют друг на друга.
      3. Событие и условие: модель Событие-Условие-Действие описывает событие , которое инициирует действие , если выполняется определенное условие .

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

   При написании технической документации полезно помнить следующее:

   1. Используйте согласованный язык, символы и выражения при описании системы (компонентов и функций).
   2. Согласованность должна применяться как к тексту, так и к диаграммам.
   3. Опубликуйте руководство по стилю документации, доступное и доступное для всех.
   4. Используйте диаграммы для передачи сложных идей в сжатом, но очень удобоваримом формате.

   ---

   7. Заключительные слова

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

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

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

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

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

   ---

   8. Рекомендуемые статьи

   Книги, которые должен прочитать каждый

   22 июля 2021 г.

   Часто задаваемые вопросы — Наука, технологии и другие увлекательные темы

   27 июля 2021 г.

   Рецензия на книгу: Величайшая история, когда-либо рассказанная до сих пор — почему мы здесь?

   9 марта 2022 г.

   Стоимость изменений — скрытый фактор, лежащий в основе нашего выбора доставки программного обеспечения

   31 августа 2022 г.

   Разработка через тестирование и сила самопроверяющегося кода

   29 августа 2021 г.

   Понимание и управление техническим долгом

   19 мая 2022 г.

   Неформальное образование, социальные навыки и вневременные универсальные темы, которые вы часто пропускаете в инженерной школе

   25 января 2022 г.

   Квантовые вычисления, помимо кубитов — часть 2: Использование случайности природы

   13 октября 2021 г.

   Моделирование распространения COVID-19: часть 2: определение модели

   12 сентября 2020 г.

   Квантовые вычисления, помимо кубитов. Часть 3: ИИ, оптимизация и квантовый отжиг

   31 октября 2021 г.

   Документирование архитектуры решения: введение Спонсор проекта, команды разработки и контроля качества и другие. Потребности в таком общении следующие:

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

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

   Фото ThisisEngineering RAEng / Unsplash

   Начнем с примера

   Каждая программная система достаточно сложна. Первая попытка задокументировать это — попытаться нарисовать какую-то диаграмму, включающую все, что очень быстро терпит неудачу. Представьте, что мы хотим задокументировать что-то относительно простое, скажем, этот конкретный блог, о котором вы читаете статью. Он работает на CMS Ghost, хранящей данные в базе данных MySQL; Apache используется для веб-сервера. Запросы обрабатываются веб-сервером, перенаправляя все запросы с http на https и направляя запросы в CMS. CMS проверяет токены и запрашивает у базы данных контент, включая страницы, сообщения в блогах и плагины. Все три компонента работают на виртуальной машине в GCP в сети по умолчанию в отдельной организации. Доступ к системе имеют читатели и контент-менеджеры, последние могут добавлять новый контент и редактировать текущий. Система также может быть изменена системными администраторами через облачную консоль. Я постараюсь включить всю эту информацию в одну диаграмму:

   ‌

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

   • Перегрузка. Чтобы ответить на любой конкретный вопрос, вы должны искать детали.
   • Недостаточно. Скажите, в скольких регионах развернута система? Создана ли резервная копия базы данных или виртуальной машины? Где хранятся изображения? Как пользователи аутентифицируются? Вы не можете ответить на эти вопросы по диаграмме.
   • Вводит в заблуждение. Почему есть зеленые, синие и желтые прямоугольники? Что это значит?

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

   1. Вы не можете разместить всю информацию на одном изображении
   2. Вам совершенно не обязательно это делать
   3. Вместо этого вы предоставляете набор изображений, чтобы каждое из них подходило идеально подходит для конкретного заинтересованного лица (человека, заинтересованного в вашем проекте)

   Существует несколько подходов к этому (модули-компоненты и разъемы-распределения, подход C4 и т. д.), неважно, что вы выберете. Главное, чтобы вы хотели, чтобы 1 человек одновременно мог получить максимум информации за минимальное время.

   Разделите проблемы

   Для нашей системы у нас есть следующие заинтересованные лица (стейкхолдеры):

   1. Спонсор проекта
   2. Автор блога
   3. Системный администратор
   4. Контент-менеджер
   5. Читатель

   Их соответствующие опасения следующие:

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

   С кем взаимодействует система?

   Контекстная диаграмма

   Эта диаграмма называется Контекстная диаграмма (по нотации C4), которая показывает именно это: с какими агентами взаимодействует система. Смотрите, здесь есть блок «Аналитика». Я буквально забыл об этом, когда рисовал первый, но взгляд на определенном уровне позволяет сосредоточиться на определенных аспектах и ​​ничего не упустить.

   Как и где развернута система?

   Диаграмма развертывания

   На этой диаграмме показано, что решение развернуто на Google Cloud Platform, на одной виртуальной машине в одной сети в одном регионе, доступ защищен Cloud IAM. По сути, он отвечает, сколько денег примерно стоит решение (20-30 долларов в месяц в зависимости от региона и размера ВМ), и что оно плохо масштабируется и потребует редизайна в случае резкого увеличения нагрузки. Кроме того, на месте нет резервной копии БД, поэтому действия должны быть рассмотрены немедленно.

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

   Видите, как мы фокусируемся на отдельных аспектах одновременно? Видите, как легче теперь усваивать информацию?

   Какова функциональность системы?

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

   Похоже, что мы ответили на большинство вопросов всего в трех простых диаграммах. Отличная работа!

   Резюме

   Сегодня мы научились выявлять проблемы и предоставлять соответствующие представления. Тем не менее, для производственного проекта еще многое предстоит охватить, что обычно делается в большом документе, который называется «Документ об архитектуре решения»: я буду говорить об этом в следующих постах.

   Конструкторская документация | Пакет

   (Дополнительные ресурсы, связанные с этой темой, см. здесь.)

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

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

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

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

   • Архитектурный проект
   • План реализации
   • Руководство по установке
   • План проверки достоверности
   • Операционные процедуры

   Эта информация может быть включена в один документ или разделена на разные документы.

   VMware предоставляет комплекты Service Delivery Kit партнерам VMware. Эти комплекты можно найти на портале Университета партнеров VMware по адресу http://www.vmware.com/go/partneruniversity, где представлены шаблоны документации, которые можно использовать в качестве основы для создания проектной документации. Если у вас нет доступа к этим шаблонам, в этой статье приведены примеры схем, которые помогут вам в разработке собственных шаблонов проектной документации.

   Заключительные этапы процесса проектирования включают получение согласия заказчика на начало реализации проекта и реализацию проекта.

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

   Прекрасным примером проектной документации по архитектуре является Белая книга «История архитектуры облачной инфраструктуры» , которую можно найти по адресу http://www.vmware.com/files/pdf/techpaper/cloud-infrastructure-achitecture-case-study.pdf.

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

   Как это сделать…

   Документ по проектированию архитектуры должен включать следующую информацию:

   • Цель и обзор
     • Краткое содержание
     • Методология проектирования
   • Эскизный проект
   • Логическое управление, хранение, вычисления и проектирование сети
   • Физическое управление, хранение, вычисления и проектирование сети

   Как это работает…

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

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

   .

   Краткий обзор. Этот проект архитектуры был разработан для поддержки проекта виртуализации для консолидации 100 существующих физических серверов в виртуальной инфраструктуре VMware vSphere 5.x. Основными целями, которые будет решать эта конструкция, является повышение операционной эффективности и обеспечение высокой доступности клиентских приложений.

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

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

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

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

   В следующей таблице показан пример документирования проектных требований:

   ID	Требование
   Р001	Консолидация существующих 100 физических серверов приложений до пяти серверов
   Р002	Предоставление ресурсов для поддержки роста на 25 дополнительных серверов приложений в течение следующих пяти лет
   Р003	Обслуживание серверного оборудования не должно влиять на время работы приложений
   Р004	Обеспечьте резервирование N+2 для поддержки аппаратного сбоя во время нормальной работы и обслуживания

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

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

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

   Ниже приведен пример таблицы с логической структурой требований к вычислительным ресурсам:

   Параметр	Спецификация
   Требуются текущие ресурсы ЦП	100 ГГц
   *Прирост ЦП	25 ГГц
   Требуется ЦП (загрузка 75 процентов)	157 ГГц
   Требуются текущие ресурсы памяти	525 ГБ
   *Расширение памяти	131 ГБ
   Требуется память (использование 75 процентов)	821 ГБ
   Требуемая память (25-процентная экономия TPS)	616 ГБ
   * Увеличение ЦП и памяти на 25 дополнительных серверов приложений (R002)

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

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

   Образец документа по архитектурному проекту выглядит следующим образом:

   • Титульный лист : Он включает имя заказчика и проекта
   • Журнал версии документа : содержит журнал авторов и изменений, внесенных в документ
   • Контактный документ : включает экспертов в данной области, участвовавших в создании проекта
   • Содержание : Указатель разделов документа для быстрого ознакомления
   • Список таблиц : Указатель таблиц, включенных в документ для быстрого ознакомления
   • Список рисунков : Указатель рисунков, включенных в документ для быстрого ознакомления
   • Назначение и обзор : Этот раздел состоит из краткого описания, в котором представлен обзор проекта и методологии проектирования, использованной при создании проекта
   .
   • Концептуальный проект : Это документация проектных факторов: требования, ограничения и допущения
   • Логическая схема : Подробная информация о логическом управлении, хранении, сети и вычислительной структуре
   • Физический дизайн : содержит сведения о выбранном оборудовании и конфигурации физического и виртуального оборудования

   План реализации документирует требования, необходимые для завершения реализации проекта.

   План реализации определяет роли в проекте и определяет, что ожидается от заказчика и что он может ожидать во время реализации проекта.

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

   Как это сделать…

   План реализации должен включать следующую информацию:

   • Заявление о цели
   • Контакты проекта
   • Требования к реализации
   • Обзор этапов реализации
   • Определение результатов проектной документации
   • Внедрение управления изменениями

   Как это работает…

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

   Ниже приведен пример описания цели:

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

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

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

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

   Роль	Имя	Контактная информация
   Заказчик спонсор проекта
   Технический ресурс заказчика
   Руководитель проекта
   Архитектор-дизайнер
   Инженер по внедрению
   Инженер по обеспечению качества

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

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

   Требования к доступу включают следующее:

   • Физический доступ к сайту.
   • Учетные данные, необходимые для доступа к ресурсам. К ним относятся учетные данные Active Directory и учетные данные VPN (если требуется удаленный доступ).

   Требования к помещениям включают следующее:

   • Питание и охлаждение для поддержки оборудования, которое будет развернуто как часть проекта
   • Требования к пространству в стойке

   Требования к оборудованию, программному обеспечению и лицензированию включают следующее:

   • Лицензирование vSphere
   • Лицензирование Windows или другой операционной системы
   • Лицензирование других сторонних приложений
   • Программное обеспечение (ISO, физические носители и т. д.)
   • Физическое оборудование (хост, массив, сетевые коммутаторы, кабели и т. д.)

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

   1. Закупка оборудования, программного обеспечения и лицензирование.
   2. Планирование инженерных ресурсов.
   3. Проверка доступа и требований к оборудованию.
   4. Проведение инвентаризации необходимого оборудования, программного обеспечения и лицензий.
   5. Установка и настройка массива хранения.
   6. Стойка, кабель и прожиг физического серверного оборудования.
   7. Установка ESXi на физические серверы.
   8. Установка vCenter Server.
   9. Конфигурация ESXi и vCenter.
   10. Тестирование и проверка плана внедрения.
   11. Миграция физических рабочих нагрузок на виртуальные машины.
   12. Оперативная проверка плана внедрения.

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

   Результаты проектной документации определяются как часть плана реализации. Любая документация, которая будет доставлена ​​заказчику после завершения внедрения, должна быть подробно описана здесь. Детали включают название документа и краткое описание цели документа.

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

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

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

   Ниже приведен пример плана реализации:

   • Титульная страница : включает имена клиентов и проектов
   • Журнал версии документа : содержит журнал авторов и изменений, внесенных в документ
   • Контактный документ : включает экспертов в данной области, участвовавших в создании проекта
   • Содержание : Указатель разделов документа для быстрого ознакомления
   • Список таблиц : Указатель таблиц, включенных в документ для быстрого ознакомления
   • Список рисунков : Указатель рисунков, включенных в документ для быстрого ознакомления
   • Заявление о цели : определяет цель документа
   • Контакты проекта : Это документация ключевых контактных лиц проекта
   • Требования к реализации : Предоставляет доступ, оборудование, программное обеспечение и лицензии, необходимые для завершения реализации
   • Обзор реализации : Это обзор шагов, необходимых для завершения внедрения
   .
   • Результаты проекта : Он состоит из документов, которые будут предоставлены в качестве результатов после завершения реализации

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

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

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

   Как это сделать…

   Руководство по установке должно содержать следующую информацию:

   • Описание цели
   • Заявление о предположении
   • Пошаговая инструкция по реализации дизайна

   Как это работает…

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

   Ниже приведен пример основного заявления о цели и допущении, которое можно использовать для руководства по установке:

   Цель: Этот документ содержит руководство по установке и настройке проекта виртуальной инфраструктуры, определенного в Проекте архитектуры.

   Предположения. Это руководство написано для инженера по внедрению или администратора, знакомого с концепциями и терминологией vSphere. Руководство не предназначено для администраторов, не знакомых с понятиями и терминологией vSphere 9.2103 .

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

   • Конфигурации массива хранения
   • Конфигурации физической сети
   • Физические конфигурации хоста
   • Установка ESXi
   • Установка и настройка сервера vCenter
   • Конфигурация виртуальной сети
   • Конфигурация хранилища данных
   • Высокая доступность, планировщик распределенных ресурсов, хранилище DRS и установка и настройка других компонентов vSphere

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

   На следующем снимке экрана показан пример из руководства по установке, в котором подробно описывается включение и настройка программного адаптера iSCSI:

   Ниже приведен пример схемы руководства по установке:

   • Титульная страница : На ней указаны имена заказчика и проекта
   • Журнал версии документа : содержит журнал авторов и изменений, внесенных в документ
   • Контактный документ : включает экспертов в данной области, участвовавших в создании проекта
   • Содержание : Указатель разделов документа для быстрого ознакомления
   • Список таблиц : Указатель таблиц, включенных в документ для быстрого ознакомления
   • Список рисунков : Указатель рисунков, включенных в документ для быстрого ознакомления
   • Заявление о цели : определяет цель документа
   • Заявление о предположении : определяет любые предположения, сделанные при создании документа
   .
   • Руководство по установке : содержит пошаговые инструкции по установке, которым необходимо следовать при реализации проекта

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

   Как это сделать…

   План проверки должен включать следующую информацию:

   • Заявление о цели
   • Заявление о предположении
   • Критерии успеха
   • Процедуры испытаний

   Как это работает…

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

   Ниже приведен пример заявления о целях и предположениях для плана валидационного тестирования:

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

   Предположения : В этом документе предполагается, что человек, выполняющий эти тесты, имеет базовое представление о VMware vSphere и знаком с прилагаемой проектной документацией. Этот документ не предназначен для администраторов или тестировщиков, не знакомых с концепциями и терминологией vSphere.

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

   В следующей таблице приведены некоторые примеры критериев успеха, определенных в плане проверочных испытаний:

   Описание	Измерение
   Члены группы администраторов vSphere Active Directory могут получить доступ к vCenter в качестве администраторов	Да/Нет
   Доступ запрещен для пользователей, не входящих в группу администраторов vSphere Active Directory	Да/Нет
   Доступ к хосту с помощью vSphere Client разрешен, если режим блокировки отключен	Да/Нет
   Доступ к хосту с использованием клиента vSphere запрещен, если включен режим блокировки	Да/Нет
   Использование ресурсов кластера менее 75 процентов.	Да/Нет

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

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

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

   Описание теста	Задачи для выполнения теста	Ожидаемый результат
   Доступ администратора vCenter	Используйте веб-клиент vSphere для доступа к серверу vCenter. Войдите в систему как пользователь, который является членом группы AD администраторов vSphere.	Доступ администратора к инвентаризации vCenter Server
   Доступ к vCenter: нет разрешений	Используйте веб-клиент vSphere для доступа к серверу vCenter. Войдите в систему как пользователь, который не является членом группы AD администраторов vSphere.	Доступ запрещен
   Доступ к хосту: режим блокировки отключен	Отключите режим блокировки через DCUI. Используйте клиент vSphere для доступа к хосту и войдите в систему как root.	Прямой доступ к хосту с помощью клиента vSphere выполнен успешно
   Доступ к хосту: включен режим блокировки	Повторно включите режим блокировки через DCUI. Используйте клиент vSphere для доступа к хосту и войдите в систему как root.	Отказано в прямом доступе к хосту с помощью vSphere Client

   В следующей таблице приведены некоторые примеры процедур проверки надежности:

   Описание теста	Задания для выполнения теста	Ожидаемый результат
   Ошибка пути к хранилищу хоста	Отключить vmnic, обеспечивающий подключение к IP-хранилищу, от хоста	Отключенный путь завершается сбоем, но операции ввода-вывода продолжают обрабатываться на уцелевших путях. Должен сработать сигнал тревоги сетевого подключения, и на настроенный адрес электронной почты должно быть отправлено электронное письмо.
   Восстановление пути к хранилищу хоста	Повторно подключите vmnic, обеспечивающий подключение к IP-хранилищу	Неудачный путь должен стать активным и начать обработку ввода-вывода. Аварийные сигналы подключения к сети должны исчезнуть.
   Ошибка пути хранения массива	Отключить одно сетевое подключение от активного SP	Отключенные пути не работают на всех хостах, но операции ввода-вывода продолжают обрабатываться на уцелевших путях.
   Резервирование сети управления	Отключить активную сеть управления vmnic	Резервный адаптер становится активным. Доступ к управлению хостом не прерывается. Должен сработать аварийный сигнал о потере избыточности сети, и на настроенный адрес электронной почты должно быть отправлено электронное письмо.

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

   Ниже приведен пример плана валидационного тестирования:

   • Титульная страница : включает имена клиентов и проектов
   • Журнал версии документа : содержит журнал авторов и изменений, внесенных в документ
   • Контактный документ : включает экспертов в данной области, участвовавших в создании проекта
   • Содержание : Указатель разделов документа для быстрого ознакомления
   • Список таблиц : Указатель таблиц, включенных в документ для быстрого ознакомления
   • Список рисунков : Указатель рисунков, включенных в документ для быстрого ознакомления
   • Заявление о цели : определяет цель документа
   • Заявление о предположении : определяет любые предположения, сделанные при создании документа
   .
   • Критерии успеха : Это список критериев, которые должны быть соблюдены для подтверждения успешной реализации проекта
   • Процедуры испытаний : это список процедур испытаний, которым необходимо следовать, включая шаги и ожидаемые результаты
   .

   Арен Стивенс-Тейлор Новости облачных и сетевых технологий, Учебники, Новости виртуализации 0 комментариев Нравится: 0

   Шаблон SAD — Справочник по архитектуре

   Резюме

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

   Вы можете скачать этот шаблон в MSWord, OpenOffice или в уценке.

   Но вместо этого статического шаблона я рекомендую наш инструмент для генерировать 80% (или более) документа автоматически.

   Шаги для завершения:

   Определите свои принципы для вашей архитектуры/дизайна

   Определите или соберите ваши требования

   Используйте нашу коллекцию предварительно определенных строительных блоков решения (SBB) и обратитесь к описанию по умолчанию вместо повторения Тривиальная информация в вашем архитектурном документе. Таким образом вы можете Держите ваш документ чистым и средним.

   Это очень просто:

   • Используйте наш предварительно определенный

   Содержание

   Краткое содержание ii

   1 Введение 4

   1.1 Термины, используемые в настоящем стандарте 4

   1.2 Область применения 4

   2 Цели и контекст 6

   Основные требования 2.1. 6

   2.2 История решения 6

   2.2.1 Архитектурные подходы 7

   2.2.2 Результаты анализа 7

   2.2.3 Покрытие требований 7

   2.2.4 Сводка изменений в текущей версии 7

   2.2.5 Вопросы повторного использования продуктовой линейки 7

   3 просмотров 7

   4 Отношения между просмотров 8

   4.1 Общие отношения между просмотрами 9

   4.2 Отношения с просмотром 9

   5 Справочные материалы 9

   6 Глоссарий и аббревиатуры 9

   7 Приложения

   Введение

   Общее введение в проект.

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

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

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

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

   Эффективное документирование архитектуры так же важно, как и ее создание потому что документация

   — это то, как архитектура передается многим заинтересованные стороны. Архитектура

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

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

   Документ означает набор данных независимо от его носителя или количество томов

   из которых состоит. Приветствуется использование электронных данных.

   Точка обзора — это образец или шаблон, определяющий соглашения для построение и

   использование представления. Он создается после того, как были определены три вещи: (1) цель представления

   , (2) аудитория представления и (3) способ создания представления и проанализировано. После создания точки обзора используются для разработки нескольких индивидуальные взгляды.

   Представление — это представление всей системы с точки зрения связанный набор

   Проблемы.

   Представление описывается типами элементов и отношений, которые оно

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

   Пакет представления определяет часть системы в представлении. Это наименьший набор из

   полезной документации, которую можно предоставить заинтересованному лицу [Clements 02]. Просмотр пакетов

   обычно показывают большие участки системы на небольшой глубине или малые участки системы на

   большой глубине.

   Область применения

   1. План документации и обзор

   В этом разделе предоставьте информацию, которая поможет читателям SAD найти информацию, которая им

   нужна быстро. Структурируйте информацию в разделах, перечисленных ниже.

   1.1 Управление документами и информация о контроле конфигурации

   Укажите версию, дату выпуска и другие соответствующие

   информация управления конфигурацией, связанная с текущей версией документ

   . Необязательно: включите историю изменений, выделив важные меняет

   от версии к версии.

   1.2 Цель и объем SAD

   Объясните общую цель и объем SAD. Объясните критерии принятие решения

   о том, какие проектные решения являются архитектурными (и, следовательно, задокументированы в SAD)

   и которые не относятся к архитектуре (и поэтому задокументированы в другом месте).

   1.3 Как организован SAD

   Дайте описательное описание и общее содержание семи основных разделы

   SAD (как указано в этом справочном стандарте).

   1.4 Представительство заинтересованных сторон

   1.4.1 Заинтересованные стороны и их опасения

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

   , описанная в этом SAD. Для каждой роли перечислите проблемы заинтересованных сторон

   , которые могут быть решены с помощью информации, содержащейся в этом SAD. А

   удобно представить эту информацию в виде матрицы, где в строках

   перечислены роли заинтересованных сторон, в столбцах перечислены проблемы, а в ячейках указать, насколько

   серьезна проблема для заинтересованного лица в этой роли. Следующие

   заинтересованные стороны должны быть рассмотрены как минимум:

   • разработчики прикладного программного обеспечения

   • разработчики программного обеспечения для инфраструктуры

   • конечные пользователи

   • инженеры по аппаратному обеспечению приложений и платформ

   • инженеры по безопасности и специалисты по сертификации

   • инженеры по технике безопасности и специалисты по сертификации

   • инженеры связи

   • системные инженеры

   • главный инженер/главный научный сотрудник

   • ведущий системный интегратор (LSI) управление программами

   • управление государственными программами (включая связанные с

   • лицензирование)

   • инженеры по системной интеграции и тестированию

   • внешние испытательные агентства

   • руководители операционных систем

   • кроссовки

   • обслуживающий персонал

   • представители других служб

   • аудиторы (внутренние LSI, Счетная палата правительства и т. д.)

   • представители деятельности по стандартизации

   1.4.2 Сценарии заинтересованных сторон для использования SAD

   Для каждой роли, указанной в разделе 1.4.1, напишите несколько коротких сценариев что

   объяснить, как заинтересованные лица в этой роли будут использовать определенные разделы SAD

   , чтобы помочь решить их проблемы.

   1.5 Точки обзора и определения видов

   Введение в точки обзора. Дайте определение термину «точка зрения» и опишите, как в этом SAD используется

   .

   Опишите каждую точку зрения, используемую в SAD, как указано в Разделе 1.5.i.

   Должны быть включены следующие точки обзора:

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

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

   Точка просмотра загрузки данных. Представления, соответствующие этой точке зрения, показывают

   данные, требуемые и предоставляемые программными элементами, и показывают, где

   хранятся эти данные и как они резервируются и

   восстанавливаются в случае потери. Представления, соответствующие этой точке зрения, обеспечивают основу

   для анализа с целью определения того, будут ли единицы иметь доступ к

   необходимой информации.

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

   службы, которые должны быть защищены от атак типа «отказ в обслуживании».

   Представления, соответствующие этой точке зрения, обеспечивают основу для анализа

   определения того, будут ли

   удовлетворены потребности системы в обеспечении информации.

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

   , которые обеспечивают критически важные для безопасности функции, и то, как они используются.

   с точки зрения надежности. Представления, соответствующие этой точке зрения, показывают

   9Элементы 0002, которые обеспечивают критически важные функции, как они

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

   , предполагают эту функциональность в случае отказа. Представления, соответствующие

   этой точке зрения, обеспечивают основу для анализа для определения того, будут ли удовлетворены

   потребности системы в надежности.

   Цели и контекст

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

   описание роли архитектуры программного обеспечения в жизненном цикле, соответствующие факторы приобретения

   , влияние модели LSI, влияние дополнительных разработка и отношение

   к результатам и артефактам системной инженерии.

   Описание решения

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

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

   информация в следующих разделах:

   Архитектурные подходы

   Обоснование основных проектных решений, реализованных программное обеспечение

   архитектура. Опишите любые подходы к проектированию, применяемые к программному обеспечению архитектура —

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

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

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

   приближается. Опишите любые соответствующие вопросы, связанные с коммерческими готовые компоненты

   (COTS) или государственные стандартные компоненты (GOTS), включая любые связанные

   торговых площадей.

   Результаты анализа

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

   соответствует назначению. Если оценка архитектуры был выполнен

   с использованием ATAM или аналогичного метода, включая анализ разделы

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

   количественное моделирование или другие результаты анализа.

   Покрытие требований

   Опишите требования (исходные или производные), к которым обращается программная архитектура.

   Включить те требования или ограничения, которые вытекают из более высоких САДы уровня.

   Сводка изменений в текущей версии

   Для версий SAD, выпущенных после исходного выпуска, суммируйте действия;

   решения и драйверы решений; изменения требований и анализ и торговать

   результатами исследований, которые стали драйверами принятия решений; и объясните, как эти решения заставили

   архитектуру развиваться или изменяться.

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

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

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

   Вариант может относиться к варианту модуля или набору модулей идентифицированные в этом SAD, или ко всей системе или подсистеме, охватываемой это САД. Для каждого варианта в этом разделе указаны приращения. сборки программного обеспечения, в которой вариант будет доступен и будет использоваться. Наконец, в этом разделе описывается любой дополнительный потенциал, который существует для повторно использовать один или несколько модулей или их идентифицированные варианты, даже если это повторное использование в настоящее время не планируется для какого-либо увеличения.

   УСЛОВИЯ НАИМЕНОВАНИЯ

   #1 В этом разделе должны объясняться все используемые соглашения об именах и внимание на любые моменты, которых программист сопровождения не ожидает. А таблица типов файлов и разрешенных имен или расширений для каждого рекомендуется для быстрого ознакомления.

   #2 Соглашения по именованию файлов, программ, модулей и, возможно, других такие структуры, как переменные и сообщения, должны быть задокументированы здесь.

   СТАНДАРТЫ ПРОГРАММИРОВАНИЯ

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

   #2 При программировании на любом новом языке должен быть установлен стандарт его использования. быть написаны, чтобы предоставить руководство для программистов. Этот стандарт может быть упомянутые или включенные здесь.

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

   #4 В общем, стандарт программирования должен определять последовательный и единый стиль программирования. Конкретные пункты для охвата:

   a. модульность и структурированность;

   б. заголовки и комментарии;

   в. отступы и расположение;

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

   эл. языковые конструкции для использования;

   ф. языковые конструкции, которых следует избегать.

   Представления

   Опишите различные точки обзора.

   Опишите для каждого вида:

   • Назовите вид.

   • Вид Описание

   • Опишите назначение и содержание представления. Обратитесь к точке зрения описание в

   • , которым соответствует этот вид.

   • Просмотр обзора пакетов

   • Показать набор пакетов представления в этом представлении и объяснить, почему набор полный и без дубликатов.

   • Архитектурный фон: укажите любой архитектурный фон (включая значительные требования к вождению, подходы к проектированию, шаблоны, результаты анализа и охват требований), который применяется к этому взгляду.

   • Механизмы вариативности: Опишите любые архитектурные вариации механизмы (например, данные адаптации, параметры времени компиляции и переменная репликация), описываемая этим представлением, включая описание того, как и когда эти механизмы могут быть реализованы и какие-либо ограничения на их использование.

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

   Пакет просмотра: Назовите пакет просмотра.

   Основная презентация: Использование соответствующего языка, языков, нотация или представление на основе инструментов представляют элементы, которые заполнить этот пакет представления и отношения между ними.

   Элемент: Каталог

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

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

   Интерфейсы: Укажите программные интерфейсы для любых элементов, показанных на основное представление, которое должно быть видно другим элементам. Главная представление, которое должно быть видно другим элементам.

   Поведение: укажите любое существенное поведение элементов или групп взаимодействующие элементы, которые показаны в основной презентации.

   Ограничения: Перечислите любые ограничения на элементы или отношения,

   не описанные иначе.

   Контекстная диаграмма: Предоставьте контекстную диаграмму, показывающую контекст часть системы, представленная этим пакетом представления. Назначить вид область пакета с отличительным символом и показать взаимодействие с внешние объекты в словаре представления.

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

   История архитектуры: Обоснование любого важного проекта решения, объем которых ограничен этим пакетом представления.

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

   Отношения между представлениями

   Общие отношения между представлениями

   Опишите общие отношения между представлениями, выбранными для представления архитектура.

   Обсудите соответствие между этими взглядами и определите любые известные несоответствия.

   Отношения между представлениями

   Показать, как связаны элементы в связанных представлениях.

   Ссылочные материалы

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

   Глоссарий и сокращения

   Дайте определения специальных терминов, используемых в SAD.

   No related posts.