理顺软件开发各个环节-13（开发管理-概要设计和详细设计）

标签：list   klist   开发技术   思想   strong   资料   需求   开发   组织   

5.5软件概要设计

　　概要设计，用于子系统或模块设计，也可用新增业务需求的跨子系统设计。概要设计在总体设计框架下，遵循总体设计思想，丰富子系统或模块设计，从而能够指导开发实现子系统或模块。

　　由于软件总体设计从宏观上架构软件，距离开发实现，还有许多需要细化之处。如果系统由多个子系统组成，每个子系统可以视为一个独立的应用软件或服务，此时概要设计不可省略；如果系统不大，重点模块也应需要做概要设计来细化。可以理解为概要设计粒度介于总体设计和详细设计之间。

　　另外，概要设计与代码实现的联系更紧密一些，如代码分层、核心的对象类及关系等。

　　责任人：开发项目组长。
　　执行人：高级程序员、子系统或模块开发人员。
　　关键行为：分析和概要设计。　　

• 分析：根据子系统或模块的功能规划，结合对软件需求进行分析，完整把握需求；
• 概要设计：在总体设计框架下，完成子系统或模块的概要设计。

　　输入：

• 软件需求规格书（SRS）；
• 数据字典（DD）；
• 用户故事集合；
• 其它需求资料；
• 软件总体设计文档。

　　输出：

• 软件概要设计文档；
  • 子系统结构设计；
  • 功能模块设计；
  • 接口设计；
  • 软件结构设计；
  • 数据库设计。

　　职责要求：

• 概要设计；
• 沟通、协调、明确对接的上下游子系统/模块的接口和边界；
• 提请软件概要设计评审：
  • 概要设计人员：主讲人，负责讲解和答复各种质询和疑问；
  • 产品经理：评估产品需求在子系统或模块的部分是否被设计的系统所满足；包括后期的需求的满足性；非功能需求的支持情况；
  • 项目经理：组织、协调，关注子系统与其它相关子系统的衔接；
  • 开发项目经理及高级技术人员：关注技术方案的可行性、灵活性；非功能需求的支持情况；关注子系统与其关子系统的衔接；
  • 开发技术人员：了解软件的设计思路，便于开发实现；如前后端分离，前端开发人员需评审涉及前端接口的合理性；
  • 测试技术人员：了解软件的设计思路，以及其对测试的影响；

5.6软件详细设计

　　详细设计，能够在开发人员编码实现前，评审其设计思路，肯定是有帮助的。但是，详细设计是需要时间开销的，做为设计的末端，其数量规模是很大的；如果需求不明确，则这些投入就可能白费。

　　在敏捷开发模式，详细设计一般都不做。在实际操作中，发现有些核心功能还得需要做详细设计，有了总体设计文档，概要设计文档和软件需求规格书，并不能保证每个开发人员都能跟上设计人员的思路，结果实现的效果参差不齐，有的完全没有按照总体设计思路来。

　　因此，我认为，重要或核心功能开发，还是需要做详细设计。具体需要开发项目组长来把握。

　　责任人：开发项目组长。

　　执行人：软件需求开发人员。

　　关键行为：分析和详细设计。

　　输入：

• 软件需求规格书（SRS）；
• 数据字典（DD）；
• 用户故事；
• 其它需求资料；
• 软件总体设计文档；
• 软件概要设计文档。

　　输出：

• 详细设计文档；
• 接口设计：YApi或swagger；
• 单元测试设计：checklist

　　职责要求：

• 详细设计；
• 理解需求；
• 沟通、协调、明确对接的上下游模块的接口和边界；
• 提请软件详细设计评审：
  • 开发人员：主讲人，负责讲解和答复各种质询和疑问；
  • 开发项目组长：关注技术方案的可行性；
  • 上下游相关开发人员：评审接口、业务流程及性能等技术可行性；
  • 高级技术人员：如果功能比较复杂，参与评审；
  • 其它人员，视情况需要

理顺软件开发各个环节-13（开发管理-概要设计和详细设计）

标签：list   klist   开发技术   思想   strong   资料   需求   开发   组织   

原文地址：https://www.cnblogs.com/alabo1999/p/12989728.html