Как вы планируете запустить новую веб -систему?

Question

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

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

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

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

Answer 1

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

Чтобы ответить на ваш вопрос:

1 - Поймите ограничения

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

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

2 - Просмотры

В Togaf (и Zachman) это то, что у него есть концепция различных «взглядов», например:

• Взгляд безопасности
• представление данных
• технологический вид
• представление приложения
• Процесс просмотра
• Поддержка представления
• оперативный взгляд
• Биллинг вид
• Пользовательский вид
• производительность и т. Д.

Впереди вы хотите внимательно думать о том, какие взгляды имеют отношение к системе, которую вы планируете / архивируете. По мере развития проекта / системы вам нужно помнить об этом; Они помогут руководить основными решениями. Мне также нравится этот Appoarch / Wemning, потому что он работает в соответствии с «разделите завоевание» - разбивайте большую головную головку на более мелкие.

3 - Моделирование

Я раньше не слышал об использовании шариков из пенопласта, но идея моделирования отношений тактильным образом звучит очень привлекательно - хотя, если это большая система, вам может понадобиться действительно большая комната :)

Белая доска - мой любимый способ изучения того, как относятся классы (и все, что, правда). Я настоятельно рекомендую иметь с вами цифровую камеру или телефон со встроенной камерой; Я использую последнее, я фотографирую доски по мере необходимости, а затем синхронизируя их с моим компьютером после встречи и отправляю копии участникам. Это очень легко запечатлеть информацию и заставляет вас выглядеть довольно профессионально.

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

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

• Система выше определенного размера / сложности, или
• У вас есть много небольших систем для работы.

4 - Методология проекта

Я большой поклонник Agile / Scrum. Я смотрю на способы применения гибких принципов к архитектуре SLN - но у меня еще ничего нет.

Я присутствовал на хорошей сессии в Tech -ED в прошлом году (ARC202, бросая вызов роли архитектора с Кевином Фрэнсисом) - у меня есть написать здесь.

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

Answer 2

Некоторым нравится Канбан.

Другие находят UML быть полезным.

Архитектурные войны используют Zachmann Framework.

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