软件设计的总体思路和模板的方法和本质(组图)

软件设计的不同模型：瀑布、快速原型和迭代

自1968年“软件工程”概念提出以来，软件开发领域就从未停止探索传统工程提高质量、降低成本的原理和方法。 在这个过程中，提出了许多不同的软件开发模型，典型的有：瀑布、快速原型、迭代开发。

是最初于1970年提出的一种软件开发模型。在瀑布模型中，认为开发是按照需求分析、设计、实现、测试（确认）、集成、维护的顺序进行的。

在迭代开发方法中，整个开发工作被组织为一系列短的、固定长度（例如，3 周）的小项目，称为一系列迭代。 每个迭代包括需求分析、设计、实现和测试。 通过这种方式，可以在需求完全确定之前就开始开发工作，在一次迭代中完成系统的一部分功能或业务逻辑的开发。 然后利用客户反馈细化需求，开始新一轮的迭代。

不同的开发模式对设计阶段的工作要求不同。 相对而言，瀑布模型对设计文档的要求最细，而快速原型法一般对设计要求相对较弱，迭代开发各阶段设计文档的工作量较小。 但软件开发完成后，最终的设计文档比快速原型制作的方法要好。

软件设计的总体思路

软件设计的本质是根据软件的需求建立模型，通过将模型映射到软件中来解决实际问题。 因此，软件设计要解决的核心问题是建立合适的模型，从而开发出满足用户需求的软件产品，并具有以下特点：

因此，软件设计没有放之四海而皆准的方法和模板。 我们的设计开发人员在软件设计开发过程中需要根据软件项目的特点进行沟通协调，梳理软件项目团队的行为。 一种设计软件的有效方法。 并保证软件设计文档的一致性、完整性和可理解性。

谁来做软件设计

在我们开发人员中，很多人都明白：“软件设计文档是软件架构师和设计师的工作”软件界面设计文档，其实不然。 设计文档是整个软件开发团队的产出，有的是架构师或设计师给的，有的是开发人员给的。 这并没有做出一定的区分。

最佳实践

我们经常听到这样的话：

这些言论不是正确的概念。 根据软件项目的实际情况，软件开发设计团队可以就设计文档的详细程度达成一致。 项目组需要保证设计文件的完整性和一致性。 当项目进度紧张时，软件设计文档可以稍早一些； 当项目时间充足时，相关文件可以更详细。 但是，在项目开发过程中，软件设计开发团队需要对设计文档有共同的理解。

设计文件的分类和使用

一般来说，作为一个软件项目，我们需要有这几类文件

正如我之前所说，在一个软件团队中，对上述文件的要求可能完全不同。 在一个简单的项目中，所有类型的文件可能在一个文件中解释； 在一个复杂的项目中，每一种文档可能要写好几份文档； 在最极端的情况下，每种类型的文件可能会被装订成几卷。 因此，我们软件设计人员和开发人员需要清楚的是，文档不是我们设计的目的，也不是我们设计过程中的额外工作。

软件设计文档是在软件设计和开发过程中形成的，用于在软件设计和开发团队内部以及与利益相关者之间进行交流的文档。 这些文档记录了软件项目中的各种知识、方案的思路和各种决策意见。

下面我们梳理一下软件设计开发过程中必须完成的工作，需要注意的是这些需要完成的工作在不同的开发过程模型的指导下可能有不同的时间要求，我们需要注意的是关注的是这个阶段需要做的工作，这个阶段我们需要沟通的人。

需求分析

需求分析是我们在任何一个软件项目设计开发过程中都必须完成的工作。

这项工作通常与客户一起完成。 在不同的项目中，这个“客户”可能来自购买产品的真实用户、使用系统的用户，或者是团队中的某个人，比如产品经理。 软件设计和开发团队的参与成员根据项目的规模而有所不同。 原则上，设计开发人员越早参与，对需求的理解和把握就越好。 在这个阶段，通常需要软件架构师参与。 从资源优化的角度来看，开发人员不必参与需求分析，但需要了解需求。

需求分析的结果通常需要使用需求规范文档来描述。 目前主流的需求描述方法包括：用户示例图、用户故事等，这些方法各有侧重，核心思想都是清晰描述用户的使用场景。 但是，无论采用哪种方式来描述需求，需求说明书都需要明确以下几点：

特色设计

功能设计和需求分析几乎同时进行。 在很多软件项目中，并没有特别注意功能设计。 但对于某些软件项目来说，这是一项相当大的工作量。 对于以用户界面为主的软件项目软件界面设计文档，功能设计可以看作是绘制原型界面、描述使用场景、获得用户认可的过程。 对于没有接口的软件项目，功能设计和需求分析之间的区别更加模糊。

参与者与参与需求分析的类似，架构师更侧重于参与这类工作，在实现层面给出一些判断和权衡。

功能设计的核心需要明确：

系统架构设计

系统架构设计是一个非常依赖经验的设计过程。 需要根据软件项目具体的功能需求和非功能需求进行取舍，最终得到满足各方要求的系统架构。 系统架构的差异将在很大程度上决定系统的开发和维护能否轻松适应需求的变化和业务的扩展。

在架构设计工作中，用户参与度很低。 软件开发团队中需求人员的参与度很低，但团队中的所有核心设计和开发人员都应该参与并达成一致。

架构设计的主要成就是呈现系统的不同视图，并将它们实施到开发中：

在软件开发过程中，系统架构并不是一成不变的。 随着设计人员和开发人员对系统理解的加深，系统架构也将随之演变。 在软件项目中，架构设计是开发团队沟通的统一语言。 设计文档必须随着系统的变化而更新，以保证开发团队对系统的理解和沟通的一致性。

模块/子系统概要设计

模块/子系统的概要设计以架构师参与、核心设计人员和开发人员负责的方式进行。

在总体设计工作中，需要在架构确定的开发路线的指引下，完成模块功能实现等关键设计工作。 在概要设计阶段，需要围绕模块的核心功能和难点进行设计。 在这个过程中，更推荐使用UML进行概要设计，需要：

模块详细设计

在瀑布开发模式中，模块的细节设计会更加严格，所有的类都会进行详细的设计。 据我所知，除了一些对系统健壮性要求非常严格的软件项目，比如国防项目，金融项目也需要详细的设计文档。 大多数其他项目使用其他方法来处理此类工作，例如自动化测试。

综上所述，软件设计文档作为软件开发团队沟通、理解和知识共享的手段具有重要意义。 根据软件团队的规模，对文档所载信息的详细程度可能有不同的要求。 我们的软件团队对*如何使用设计文档有统一的认识，并坚持更新设计文档*，这是软件设计的最佳实践！

软件设计所需的知识和技能