Проектирование ИТ-систем

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

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

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

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

Стандартизация и прозрачность проектирования позволяют:

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

Что это даёт бизнесу:

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

Методология RB Tech строится на сочетании архитектурной строгости, гибкости сценариев и соответствия международным и национальным стандартам (ГОСТ, ISO, IEEE).

1. Идея

Формирует границы проекта, ключевые цели и архитектурный замысел. Может быть оформлена как эскизный проект (ЭП), Business Case или концептуальная записка.

2. Архитектура

Определяет структуру системы, модули, взаимосвязи и интерфейсы. Часто оформляется как технический проект (ТП), соответствующий SRS и ISO 42010.

3. Реализация

Включает описание программных модулей, их взаимодействие, требования к сборке и развертыванию. Оформляется в виде SDD, ГОСТ 19.402–78 или внутренней рабочей документации.

4. Взаимодействие

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

5. Контроль и испытания

Определяются критерии приёмки, сценарии тестирования и документация ПМИ. Следуем стандартам ГОСТ 34.601 и IEEE V&V.

6. Сопровождение

Описываются условия поставки, поддержка, обновление, а также паспорт системы или подсистемы (ГОСТ 2.601).

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

Используемые стандарты

Национальные (ГОСТ)

• ГОСТ 34.201–89 — жизненный цикл АС
• ГОСТ 34.602–89 — техническое задание
• ГОСТ 34.603–92 — технический проект
• ГОСТ 34.601–90 — программа и методика испытаний
• ГОСТ 19.402–78 — описание программ
• ГОСТ 2.601–2013 — паспорт изделия

Международные

• ISO/IEC/IEEE 42010 — архитектура систем
• IEEE 1016 — описание дизайна программного обеспечения
• ISO/IEC 12207 — процессы жизненного цикла ПО
• CMMI — модель зрелости процессов (уровни 2–3 применимы для большинства проектов)

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

Что проверить дальше:

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

Если нужно перейти от общей архитектурной рамки к документам, откройте карту раздела Документация и артефакты проекта.