我非常喜欢William Pietri的答案(+1),但我认为需要添加它。甚至假设您所说的系统仅包含软件。
但是在深入探讨之前,我不知道有什么书可以帮助您。接下来的所有事情,我都从经验中学到了(意思是威廉提出的三点)。
您所讨论的范围至少具有四个主要角色。有时,一个人可能会担任中小型项目的所有这些角色,但是当您开始进行大型项目时,至少需要将这些角色分开。任何人都很难以任何有意义的方式来精通他们。
业务分析师
那就是与客户交谈并将他们的需求转化为架构师可以理解的东西的人。基本上是正确制定的要求列表。这包括明显的功能需求(该系统必须交付什么?),还包括非功能需求(系统必须满足的一般特征是什么?)可能包括安全性,可靠性,可用性,弹性,容量,性能,健壮性和从用户的角度来看其他此类要求)。
这是系统必须做的第一步,是认真思考的开始。
系统架构师
这个人产生了在其中工作的高级技术框架。他们给出了轮廓匹配计划。通用工具,技术,构造。他们将整个系统分解为更小的组件,它们如何相互配合,如何与外界相适应...
这在许多方面有助于完善需要考虑的内容。在那个阶段,通常会发现与业务分析师编写的需求有关的问题。回到他们那里进行一些迭代,以提高他们对所需内容及其表达方式的理解。
系统设计师
这个角色是关于如何使其全部工作的。与单人表演相比,这可能是更多的团队合作。但是可能会有首席设计师来监督整个系统的设计。这个人必须深入研究细节,并确保建筑师的观点是可以实际构建的。
期望进一步完善系统的体系结构,从而可能进一步完善业务分析。
测试经理
这个角色经常被遗忘。但是,如果最终无法测试,怎么证明自己可以构建呢?必须对所有阶段的结果进行审查:具有测试能力的人员可以进行业务分析,体系结构和设计,以便能够突出缺陷,因此可以在编写任何代码之前进行早期更正。
这是一个简短的摘要。
那些家伙/女友只是链条中考虑必须考虑的事情的一般人。
对于大型银行或航天应用之类的复杂项目,仅举两个例子(想想成百上千个工日),有许多主题专家,我们称其为每个阶段的项目审查和支持。这些角色包括安全分析,系统大小确定,容量,性能,数据库,群集以及许多其他狭窄的专业领域,包括精确的业务领域。角色的多样性取决于系统的大小和复杂性。
所有这一切都表明您不应该尝试并了解全部内容,而您不会。但是,您可以了解整体情况,在小型项目中,您可以深入研究大型项目,而不仅仅是大型项目,这是因为复杂程度可以使您更加全面。
如果您想知道如何设计系统,那么您需要先在框外思考,然后再提出问题。将自己放在客户的鞋子上,尝试思考可能出问题的地方,需要测试的地方。然后与真正的客户聚在一起,推动他们解释他们所期望的系统范围和限制。另外,每当我说“客户”时,您都必须理解,这包括几个非常不同的人。有人每天都在使用系统来完成其设计工作。有操作员,技术支持,需要报告或其他报告的经理,审计师,基础架构团队,为报告付费的利益相关者,需要手段来测试系统的质量经理...询问所有这些人(以及是否他们是一个人,让他们一次把所有这些帽子戴上),然后问他们所有他们需要什么,这样您就可以很好地了解系统要求。从那里您可以得出体系结构,然后从那里进行设计。
对于复杂的系统(无论是仅软件还是最一般意义上的与硬件集成),不仅我一个人不足以胜任上面列出的四个角色,而且甚至需要对系统必须定义的内容进行项目管理。这样做,更不用说其他阶段了。
HPH,ASM。