Мне очень нравится ответ Уильяма Пьетри (+1), но я считаю, что к нему нужно добавить. Даже предполагая, что то, что вы подразумеваете под системами, состоит исключительно из программного обеспечения.
Но прежде чем углубиться в это, я не знаю книги, которая могла бы помочь. Все, что следует, я узнал из опыта (имея в виду три момента, которые Уильям сделал).
То, о чем вы говорите, охватывает как минимум четыре широкие роли. Иногда один человек может выполнять все эти роли для небольших и средних проектов, но когда вы начинаете работать над большими проектами, вам необходимо хотя бы несколько выделить эти роли. Кому-то трудно быть экспертом во всех отношениях каким-либо значимым образом.
Бизнес-аналитик
Это человек, который разговаривает с заказчиком и переводит его требования в то, что может понять архитектор. В основном список правильно сформулированных требований. Это включает в себя очевидные функциональные требования (что должна обеспечивать эта система?), А также нефункциональные требования (какие общие характеристики должна выполнять система? Это может включать безопасность, надежность, доступность, устойчивость, емкость, производительность, надежность и другие подобные требования с точки зрения пользователя).
Это первый шаг к тому, что должна делать система, самое начало серьезного мышления.
Системный архитектор
Этот человек создает техническую основу высокого уровня для работы. Они дают общий план матча. Общие инструменты, методики, конструкции. Они разбивают всю систему на более мелкие компоненты, как они сочетаются друг с другом, как они сочетаются с внешним миром ...
Это помогает во многом уточнить то, о чем нужно подумать. Очень часто на этом этапе обнаруживаются проблемы с требованиями, написанными бизнес-аналитиком. Обратитесь к ним за некоторыми итерациями, чтобы улучшить их понимание того, чего они хотят, и их выражения этого.
Системный дизайнер
Эта роль о том, как заставить все это работать. Это может быть больше командной работы, чем шоу одного человека. Но есть, вероятно, ведущий дизайнер, который будет контролировать весь дизайн системы. Этот человек должен углубиться в детали и убедиться, что взгляд архитектора действительно может быть построен.
Ожидайте дальнейшего совершенствования архитектуры системы и, следовательно, потенциально бизнес-анализа.
Менеджер тестов
Эта роль очень часто забывается. Но в конце концов, если вы не можете проверить это, как вы можете доказать, что вы можете его построить? Должен быть проведен обзор результатов всех этапов: бизнес-анализа, архитектуры и проектирования кем-то, кто компетентен в тестировании и сможет выявить недостатки и, следовательно, сделать возможными ранние исправления, задолго до написания любого кода.
Это краткое резюме.
Эти парни / девчонки - это лишь обычные люди в цепочке, которые думают о том, о чем нужно думать.
Для сложных проектов, таких как крупные банковские или космические приложения, просто для примера (например, от нескольких сотен до многих тысяч человеко-дней), есть много экспертов в данной области, так как мы призываем их проверять и поддерживать проекты на каждом этапе. Эти роли включают анализ безопасности, определение размера системы, емкости, производительности, баз данных, кластеризации и многие другие такие узкие области знаний, включая конкретные области бизнеса. Разнообразие ролей зависит от размера и сложности систем.
Все это, чтобы сказать, что вы не должны пытаться и знать все это, вы не будете. Однако вы можете понять общую картину, и в небольших проектах вы можете углубиться в гораздо большее, чем в большие проекты, просто потому, что уровень сложности позволяет вам быть более округлым.
Если вы хотите знать, как проектировать системы, то вам нужно начать задавать вопросы, думая нестандартно. Поставьте себя на место клиента и постарайтесь подумать, что может пойти не так, что нужно проверить. Затем соберитесь с реальным клиентом и подтолкните его, чтобы объяснить масштабы и ограничения системы, в которой они нуждаются. Кроме того, всякий раз, когда я говорю «клиент», вы должны понимать, что это касается нескольких совершенно разных людей. Есть человек, который изо дня в день использует систему для того, для чего она предназначена. Там есть оператор, техническая поддержка, менеджер, которому нужен тот или иной отчет, аудитор, команда инфраструктуры, заинтересованная сторона, которая заплатила за него, менеджер по качеству, которому нужны средства для тестирования вашей системы ... Спросите их всех (и если они один человек, попросите их надеть все эти шляпы по одной за раз), поэтому спросите их все, что им нужно, и вы хорошо начнете понимать, каковы ваши системные требования. Оттуда вы можете получить архитектуру, а оттуда дизайн.
Для сложных систем (будь то программное обеспечение или интеграция с аппаратным обеспечением в наиболее общем смысле) не только одного человека недостаточно для каждой из четырех ролей, которые я перечислил выше, но вам необходимо управлять проектом, даже определяя, что система должна делать, не говоря уже о других этапах.
HPH, асм.