Создание эффективного документа по проектированию программного обеспечения – CodesCode

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

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

Формулирование проблемы

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

Сбор требований

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

1. Расшифровка формулировки проблемы: Описание проблемы в одной строчке – это высокоуровневое объяснение того, что конечная цель заинтересованных лиц. Обычно это абстрактное утверждение. Чтобы разработать эффективную систему, мы сначала должны понять формулировку проблемы, задавая различные уточняющие вопросы, такие как «кто являются пользователями», «какие требуются функции», «какие ограничения» и т. Д. Это позволит нам хорошо понять, что требуется.

2. Определение требований: Всегда лучше документировать и утвердить их до реализации. После определения проблемы требования могут быть разделены на функциональные и нефункциональные и определены по приоритету P0, P1, P2 и т. Д. в зависимости от времени, сложности и т. Д. Это будет служить основой для того, что должно быть доставлено и когда.

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

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

Примерные расчеты на основе общих данных

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

Разбиение на задачи

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

Проектирование на высоком уровне

Очень важный и важный шаг: проектирование системы. Проектирование на высоком уровне – это план вашего приложения и руководство для разработчиков. Как только требования ясны, оно дает нам глубокое понимание системы. Основываясь на требованиях, мы определяем различные компоненты, необходимые для проектирования системы. Проектирование на высоком уровне включает эти компоненты и взаимодействие между ними. Оно определяет различных акторов и их взаимодействие с инфраструктурой. Чтобы обеспечить лучшую видимость, также можно предоставить легенды, нумерацию и отметки этих взаимодействий. Возможно, что существуют не один, а несколько различных существующих и новых компонентов/служб, которые взаимодействуют вместе. Всегда лучше использовать цветовые коды или разделы для группировки связанных компонентов вместе. Это дает читателям четкое понимание взаимодействия между компонентами и их границами.

Проектирование на низком уровне

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

Диаграмма потока

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

Альтернативные варианты

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

Схема данных

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

Структура API

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

Затраты на эксплуатацию

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

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

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

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

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

Детали тестирования

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

Операционное совершенство

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

Условия сбоев

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

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