From $5 000

Software Architecture

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

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

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

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

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

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

Адекватное определение требований – одно из важнейших условий успеха проекта, возможно, даже более важное, чем использование эффективных методов конструирования.
Различают 3 основных уровня требований:
  • Бизнес-требования описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание - бизнес-цели организации или клиента, заказывающих систему;
  • Пользовательские требования описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то. Область пользовательских требований также включает описания атрибутов или характеристик продукта, которые важны для удовлетворения пользователей;
  • Функциональные требования определяют, каким должно быть поведение продукта в тех или иных условиях. Они определяют, что разработчики должны создать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес-требований. Такое соотношение между тремя уровнями требований жизненно важно для успеха проекта.

Проектирование архитектуры.

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

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

Результат нашей работы

  • Требования к разработке, тестированию и проверке;
  • Детальное описание системы, которая корректно решает поставленные бизнес-задачи;
  • Схема спроектированной и реализованной архитектуры ПО с описанием каждого микросервиса и элемента инфрастуктуры;
  • Оптимально выбранные технологии для каждого микросервиса;
  • Структурированное содеражание функциональных и нефункциональных требований;

Контакты

0/50000