自由读 — 8.3软件管理专题

8.3.1 软件管理“V模型”

软件管理“V模型”如图8-2所示。

图8-2 软件管理“V模型”

在一个软件为主的研发项目中，建议留出至少20%的时间用于需求分析，留出至少20%的时间用于概要设计和详细设计，编码时间一般不超过项目时间的40%，留出至少20%的时间用于验收测试，专职的技术经理负责根据系统的用例和设计进行编码与代码检查，建立标准的单元测试管理流程和文档体系。

8.3.2 软件概要设计原则

♢总体原则和方法：由粗到细、互相结合、定性分析和定量分析相结合、模型化，考虑系统的一般性、关联性、整体性和层次性；

♢分解协调：分解是指将一个复杂的系统分解为若干个子系统。协调是系统内协调，即根据系统的结构、功能、目标的要求，使各个子系统之间协调配合。在各个子系统局部优化的基础上，通过内部平衡的协调控制，实现系统的整体优化；

♢屏蔽抽象：从简单的框架开始，隐含细节；

♢一致性：统一的规范、统一的标准、统一的文件模式，每个模块应当有一个统一命名的容易理解的名字；

♢编码：由外向内；

♢面向用户：概要设计是对于按钮按下后系统怎么做的简要说明；

♢模块、组件的充分独立性、封闭性；

♢考虑静态结构与动态运行；

♢每个逻辑对象都应当说明其所处物理对象；

♢每个物理对象都有合适的开发人员，并且有利于分工与组装；

♢确立每个构架视图的整体结构，视图的详细组织结构、元素的分组，以及这些主要分组之间的接口；

♢必要的人员储备及培训，软件构架与使用的技术平台密切相关，具体的软件构架人员应当具备使用这些平台的软件开发经验；

♢通过需求功能与设计模块之间的列表对应，检查每个需求功能是否都有相应的模块来实现，保证需求功能的可追溯性和需求实现模块的完整性，同时可以检查重复和不必要的模块；

♢在需求调研分析过程中，对业务处理过程了解完整性和准确性。调查了解清楚所有的业务流程才能设计出适合各流程业务节点用户业务特点和习惯的软件；

♢进行软件概要设计时，要尽量排除业务流程的制约，把流程中的各项业务结点工作作为独立的对象，设计成独立的模块，充分考虑他们与其他各种业务对象模块的接口，在流程之间通过业务对象模块的相互调用实现各种业务。

8.3.3 软件配置与发布

软件配置管理简称SCM（SoftwareConfigurationManagement的缩写），是在团队开发中，标识、控制和管理软件变更的一种管理。

♢专职的配置经理订立与执行软件发布管理计划；

♢建立标准的软件变更管理流程，收集上线系统的缺陷及功能扩展；

♢组建变更控制委员会来审批软件变更请求，必须严格管理上线系统的版本修改，维护人员不得随意更改上线版本，以便保证已修复的缺陷，在系统升级后不会重复出现；

♢采用发布管理工具来管理软件的修改和发布过程，在每次版本更新时都应提交一份详细的发布版本说明，描述在新版本中修复了哪些缺陷、增加了哪些新功能，以便用户顺利进行系统升级。

8.3.4 软件质量保证及审核

软件质量保证方式包括结对编程，保证软件测试时间，配置技术背景的QA，独立于项目组的QA，按阶段进行正式技术评审。软件质量审核流程如表8-3所示。

表8-3 软件质量审核流程

序号	主题	内容
1	SQA审核的启动	² 根据项目SQA计划进行的审核； ² 事件驱动审核，如果有以下警告信息出现，SQA组就应根据实际情况及时加强审核：经常的进度/里程碑的变更，开发者不能或不愿意提供足够和准确的有关项目状态、进度和计划的信息，不断地把应该马上实现的功能推迟到以后的版本中，过多/过少的不一致项或变更请求数量
2	审核准备	² 了解项目软件开发的目标、工作产品，阅读项目的管理文档，熟悉项目所采用的标准和规程； ² 评审项目最近的状态报告，了解产品的完成情况和预示的问题，阅读项目的不合格报告和上一次审核报告； ² 确定审核的重点，剪裁和确定审核检查单
3	现场审核	² 收集与审核目标、审核时间和资源一致的审核证据； ² 审核内容包括项目计划制定、跟踪和监督过程，软件需求分析过程，软件设计过程，编码实现过程，测试过程，产品评审过程，配置管理过程； ² 常采用的现场审核的方法有：与研发人员交谈和询问，查阅有关记录和工作产品，对活动及结果进行验证，常用来证实有疑问的结果，进行现场观察，如观察测试人员是否按照测试规程进行测试； ² 抽样审核，证明其不合格的客观证据，撰写审核报告
4	SQA审核后续活动	跟踪不合格项的纠正，并对纠正情况进行验证关闭。所有不合格项都应该在规定的落实时间内关闭，超过规定时间仍不能关闭的，SQA组将向研发副总报告

8.3.5 软件测试

软件测试方法如表8-4所示。

表8-4 软件测试方法

序号	主题	内容
1	黑盒测试	等价类划分、因果图、边值分析、猜错法、随机数法
2	白盒测试	语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖

一般测试通过标准是：单元功能同设计需求一致，规定的路径覆盖率及覆盖类达到要求，且单元执行正确，所规定的测试手段被使用，且单元执行正确，对残留错误有合法解释或被认可暂留，致命和严重类缺陷为0，一般类缺陷小于1%。

8.3.6 软件度量

软件度量如表8-5所示。

表8-5 软件度量

序号	主题	内容
1	项目度量	理解和控制当前项目的情况和状态，包括规模、成本、工作量、进度、风险、生产率、客户满意度、工作量分布等。生产率指单位工作量所生产的代码量，工作量分布指生命周期每个阶段所占总工作量的百分比
2	软件质量	描述和评价软件质量的一组属性，包括交付质量、缺陷引入率、缺陷移除率、功能性、可靠性、易用性、效率性、可维护性、可移植性、缺陷分布等。交付质量指千行代码缺陷数，缺陷引入率指单位规模内发现的缺陷数，过程的缺陷移除率指项目交付前解决的缺陷数据占总缺陷的比例，缺陷分布指每个阶段发现的缺陷占总发现缺陷的百分比

8.3.7 软件管理改善路径图

笔者认为改善软件管理过程需要首先保证输出的质量，其次要减少“救火”式行为，从“软件是测试出来”向“软件是设计出来”转变。详细的软件管理改善路径如表8-6所示。

表8-6 软件管理改善路径

序号	主题	内容
1	管好软件发布	软件管理平台，软件源代码、目标文件管理，建立源代码和目标文件、嵌入式软件和应用软件关联关系
2	流程和架构管理	软件开发流程梳理，软件问题和缺陷跟踪管理，公共代码开发，设置公共代码开发人员，保证开发代码的质量和文档。设置软件配置员，保证源代码和目标文件的一致性
3	软件需求管理	强化需求评审，需求分析质量直接影响后续的各个工作环节，分别进行全局评审和局部评审，全局评审关注方向、核心竞争力功能，局部评审关注业务流程和操作流程。统一需求来源，使用统一的平台管理需求的分类，设置统一的需求接口人员，合理的过滤，不要立即着手实现
4	软件测试管理	测试和设计同步，包括测试计划、测试用例与功能代码同步。统一管理测试用例，并形成测试用例的更新流程。形成测试用例的Checklist和完成测试的Checklist，统一管理Bug，建立一个专门的Bug管理平台，及时发布已暴露的Bug解决方法，避免问题重复出现。测试问题的整理，在例会中总结、分享
5	软件工程管理	增加系统设计比重，公共模块开发，经验分享，连续性检讨和优化