.NET企业架构设计

软件的需求和质量

系统的最终目标有一系列需求描述，这些需求最终决定了系统的架构。需求又分为功能需求和非功能需求：

功能性需求是指系统需要做的事情，即系统需要为特定的任务和达到用户的目的提供哪些功能。通常而言，一个功能包含输入，行为和输出。软件需求必须“清晰，正确，避免二义，明确且可检验的”

非功能需求是指不属于工方面的需求。一个常见的例子是使用(或不使用)某一特定版本的某框架，或是需要让最终产品可以和指定的遗留系统配合使用。还有一些比如支持可访问性，安全性，可靠性等。

一般而言，非功能需求表示对系统的一种限制，进而影响系统的质量。

架构师的职责：接收需求，拆分系统，确定并评估技术，编写详细说明书。

软件的生命周期

软件开发是一个用来处理复杂性，并保证程序得到预期结果的流程。软件工程的目的是控制复杂性，而不是增加复杂性。为了达到这个目标，软件项目的各个阶段都需要用某种方法论来指导。

根据ISO/IEC 12207标准，软件开发周期分为23个步骤，每个步骤包含一系列的活动和结果。步骤分为3种类型：主要步骤，支持型步骤和组织型步骤。如图所示：

 

具体内容可以参考：ISO 12207

获取(Acquisition)步骤包含引出需求，评估可用方法，协商和约定。

供应(Supply)是指供方提供系统，软件产品或软件服务的活动

开发(Development)步骤包括分析需求，设计系统，实现系统，测试与部署，这也成为了架构师大显身手的地方。

运营(Operation)包括让软件可以在公司中使用，与现有系统集成，进行小规模试验，及辅助用户熟悉软件等。

维护(Maintenance)步骤着眼于保持系统良好运行，包括修复Bug，提供新功能等。这其中有限活动也许也需要架构师的参与。

墨菲法则：

1. 为一个赶不上进度的软件项目增加人手只能让其更加落后于进度。

2. 程序的复杂性会一直增加，直到负责维护的程序员力不从心为止。

3. 若建筑师按照程序员写的程序那样造房子，那么史上出现的第一只啄木鸟也许会毁掉整个文明。