5.5软件概要设计
概要设计,用于子系统或模块设计,也可用新增业务需求的跨子系统设计。概要设计在总体设计框架下,遵循总体设计思想,丰富子系统或模块设计,从而能够指导开发实现子系统或模块。
由于软件总体设计从宏观上架构软件,距离开发实现,还有许多需要细化之处。如果系统由多个子系统组成,每个子系统可以视为一个独立的应用软件或服务,此时概要设计不可省略;如果系统不大,重点模块也应需要做概要设计来细化。可以理解为概要设计粒度介于总体设计和详细设计之间。
另外,概要设计与代码实现的联系更紧密一些,如代码分层、核心的对象类及关系等。
责任人:开发项目组长。
执行人:高级程序员、子系统或模块开发人员。
关键行为:分析和概要设计。
- 分析:根据子系统或模块的功能规划,结合对软件需求进行分析,完整把握需求;
- 概要设计:在总体设计框架下,完成子系统或模块的概要设计。
输入:
- 软件需求规格书(SRS);
- 数据字典(DD);
- 用户故事集合;
- 其它需求资料;
- 软件总体设计文档。
输出:
- 软件概要设计文档;
- 子系统结构设计;
- 功能模块设计;
- 接口设计;
- 软件结构设计;
- 数据库设计。
职责要求:
- 概要设计;
- 沟通、协调、明确对接的上下游子系统/模块的接口和边界;
- 提请软件概要设计评审:
- 概要设计人员:主讲人,负责讲解和答复各种质询和疑问;
- 产品经理:评估产品需求在子系统或模块的部分是否被设计的系统所满足;包括后期的需求的满足性;非功能需求的支持情况;
- 项目经理:组织、协调,关注子系统与其它相关子系统的衔接;
- 开发项目经理及高级技术人员:关注技术方案的可行性、灵活性;非功能需求的支持情况;关注子系统与其关子系统的衔接;
- 开发技术人员:了解软件的设计思路,便于开发实现;如前后端分离,前端开发人员需评审涉及前端接口的合理性;
- 测试技术人员:了解软件的设计思路,以及其对测试的影响;
5.6软件详细设计
详细设计,能够在开发人员编码实现前,评审其设计思路,肯定是有帮助的。但是,详细设计是需要时间开销的,做为设计的末端,其数量规模是很大的;如果需求不明确,则这些投入就可能白费。
在敏捷开发模式,详细设计一般都不做。在实际操作中,发现有些核心功能还得需要做详细设计,有了总体设计文档,概要设计文档和软件需求规格书,并不能保证每个开发人员都能跟上设计人员的思路,结果实现的效果参差不齐,有的完全没有按照总体设计思路来。
因此,我认为,重要或核心功能开发,还是需要做详细设计。具体需要开发项目组长来把握。
责任人:开发项目组长。
执行人:软件需求开发人员。
关键行为:分析和详细设计。
输入:
- 软件需求规格书(SRS);
- 数据字典(DD);
- 用户故事;
- 其它需求资料;
- 软件总体设计文档;
- 软件概要设计文档。
输出:
- 详细设计文档;
- 接口设计:YApi或swagger;
- 单元测试设计:checklist
职责要求:
- 详细设计;
- 理解需求;
- 沟通、协调、明确对接的上下游模块的接口和边界;
- 提请软件详细设计评审:
- 开发人员:主讲人,负责讲解和答复各种质询和疑问;
- 开发项目组长:关注技术方案的可行性;
- 上下游相关开发人员:评审接口、业务流程及性能等技术可行性;
- 高级技术人员:如果功能比较复杂,参与评审;
- 其它人员,视情况需要