计算机软件文档写作11-管理文档

第七章软件管理文档7.1管理文档概述工程化的软件生产方式是软件业界始终在不懈追求的目标。软件工程管理方法适用与否，对软件工程的成败有着举足轻重的作用。而软件工程管理方法改进的途径之一，就是建立行之有效、可操作性强的软件管理文档。软件管理文档项目开发计划测试计划测试分析报告开发进度报告开发总结报告管理文档的组成：管理文档有以下几个方面的作用：维护人员软件开发管理人员软件开发人员软件操作人员用户软件管理文档管理文档的作用主要表达在3个方面：①是软件开发各阶段工作成果的表达；②把软件开发过程中的一些“不可见〞的事物转换成“可见〞的文字资料；③提供了管理人员、开发人员、操作人员和用户之间相互沟通、协调的窗口。17.2工程开发方案工程开发方案又称软件定义文档，是和软件本身一样重要的知识资产，是工程启动后第一件最重要的工作。工程开发方案一般包括资源需求、工作分解、工作目标、开发团队及人员安排、进度安排、内外接口约定、风险分析以及软件质量控制机制等。1.工程开发方案书工程开发方案书的具体内容随着工程和开发机构类型的不同而不同，一般都会包括以下几个局部：①工程目标。简述工程目标，并列出影响管理的约束条件，如预算、时间…②开发团队及人员安排。阐述团队组织方式、人员构成及分工③软硬件资源需求。分析和列出所需资源，注明估算的资源需要时间及价格④工作分解。分解工程为一系列活动，确定工程里程碑及可交付文档⑤工程进度。描述工程各活动之间的依赖关系、到达里程碑的时间等⑥风险分析。分析工程可能存在的风险、发生的可能性及应对风险的策略⑦监控机制。制定详细、可操作的工程监控机制，明确管理报告的递交时间⑧开发估算。包括规模、工作量、本钱等的估算，要求依据并积累历史数据制定工程开发方案的过程被称为工程筹划。由于方案所具有的在时间上的提前性，工程开发方案通常会经常性的修正，有些局部甚至会频繁的改变！而局部内容的变化，会影响开发方案的正确性和符合性，使其越来越偏离工程实际，最后变得没有价值。如随着工程需求的逐渐明确引起的工程方案细化、工程可提供资源变化引起的工程方案的变化等。所以，在实际工作中，需要有明确的责任人和操作原那么，来对工程方案实施维护，并对工程方案的变更实施必要的控制。另一个重要的方面是，在组织文档时，就要考虑到这种频繁变更的需要，使得当变更发生时，文档的相应局部能够容易替换。22.工作分解结构工作分解结构(workbreakdownstructure,WBS)是对整个工程工作的分级描述，是工程方案开发的第一步。分解示意如以下图所示。目标活动活动活动活动活动活动1级2级……m级工作包任务1任务2任务3…任务n活动工作分解结构设计一般可以采用2种方法：-自上而下的方法。从工程的目标开始，逐步分解，直到具体任务；-自下而上的方法。也称集思广益法。即从底层开始，逐层集成，最后集合后完成目标。工作分解结构主要有4个用途：思路工具：可以描述工程的整体思路，是一个方案和设计的工具；结构设计工具：是工程工作的结构图，可以清晰表达工程各项工作间的相互关系；方案工具：能够展示工程全貌，说明为完成工程所需完成的各项活动；工程状态报告工具：可以作为工程状态报告的框架。随着低一级工程活动的完成，工程由下而上不断整合，某一项工作的完成将成为里程碑，所以，工作分解结构就定义了里程碑事件。33.工程里程碑与阶段性文档由于软件产品是无形的，因此，管理者需要通过文档的形式获得信息，了解软件的开发状况，以作出管理的决定。里程碑的建立，可以描述软件开发活动一个过程的终结。在每个里程碑，都有一个正式的可以提交给管理层的阶段性结果。比方，一份报告。里程碑报告的内容不拘，以能清楚说明阶段性结果为标准，应能代表工程中一个特定逻辑意义上的阶段的终结。要建立里程碑，软件过程就一定要分解成一系列相关的根本活动，而每个根本活动都要有相应的输出结果。如以下图，是一个需求描述中的活动，其中每个活动都有主要输出。可行性研究可行性研究可行性研究可行性研究可行性研究可行性报告用户需求估算报告体系结果设计系统需求44.工程进度工程管理者要求估算完成各项活动所需的时间和资源，并将它们严密的组织起来，以安排工程进度。不同的工程，具有不同的工程开发进度。初始的工程进度安排往往是不精确的，但随着工程进展信息的不断增多，进度安排也会越来越接近工程实际进度，因此，必须不断更新工程进度。工程进度包括将一个工程分解为假设干独立的活动，以及判断完成这些活动所需的时间。通常，有些活动是可以并行的，工程管理者应组织并协调这些并行的工作。工程进度过程见以下图：识别活动识别活动依赖关系估算活动的资源为活动分配资源创建项目图表软件需求活动图表及条形图在进度估算时，管理者需要有一定的余量。如工程难度大，那么花费的时间也会较多。又如，工程个别开发人员可能发生的变动，硬件环境的变化等，都是在估算工程进度时必须考虑的因素。除了时间和人员、环境的变化，资源和预算也需要考虑适当的余量。恰当的估算方法是采用“理想－实际〞方式。即先估算理想值，然后逐步参加预计出现的状况、偶然因素致成的状况、工程开发人员的素质和经验……作为经验数据，一般在最初估算的根底上增加30%作为实际可能发生的状况值，再预留20%的估算值给所谓不可预见的其它问题，那么进度估算的结果会较符合实际。55.运用图和表描述工程进度工程进度可以采用图表工具更直观的表示任务分解、活动依赖关系和人员分配情况等。下表是一个“任务的持续时间及其依赖关系〞的例子。任务持续时间(天数)依赖关系T18T215T315T1(M1)T410T510T2，T4(M2)T65T1，T2(M3)T720T1(M1)T825T4(M5)T915T3，T6(M4)T1015T5，T7(M7)T117T9(M6)T1210T11(M8)6甘特图法(GanttChart)的例tw12345678ABCD当前进度优点：简单，能动态地反映开发进程。缺点：难以反映多个任务间的逻辑关系。条形图和活动网络图是表示工程进度的两种图形表示法。(1)条形图。又称甘特图法(GanttChart)，可以表示面向活动的负责人是谁，以及活动的开始和结束时间。如以下图所示的例子。7012345678

codingA

testingA

debuggingABcoding

understandingC

modifyingC

testingB

testingC

debuggingB

debuggingC

testingABC012356789

codingA

testingA

debuggingA

understandingC

modifyingC

testingB

testingC

debuggingB

debuggingC

testingABC4

debuggingABcoding例：开发三个模块A、B、C。

A为公用模块，B、C的测试须等A的调试完成后进行。A的编码需6天，测试8天，调试6天。B的编码需7天，测试8天，调试6天。C利用已有的模块，须先理解原模块8天，再修改8天，测试9天，调试7天。最后三模块集成测试需5天完成。(2)活动网络图。又称网络方案法表示构成一个工程的不同活动之间的依赖关系。是用网状图表安排与控制各项活动的方法。最适合反映多个工作之间的逻辑关系。8持续时间LastingTime机动时间SlackTime编号EarliestStartTimeLatestStartTime012345678941363029222014126006142082028293641(0)(0)(15)(4)(2)(4)(0)(2)(0)(2)(0)(0)686678886975(1)标出LastingTime(2)标出EST:=从起点始，所有进入事件的EST+LT中最大的(3)标出LST:=从终点(EST=LST)始，所有离开事件的LSTLT中最小的(4)标出ST:=终点LST起点EST

LT(5)标出KeyPath：即EST=LST的所有事件组成的路径通常，甘特图适合按开发阶段安排，以作工程总体进度控制。网络方案便于在细节上安排人力，适合按开发阶段或子工程的工作步骤安排。96.风险管理由于绝大多数软件工程都存在不确定性，因此，风险管理对软件工程而言就尤为重要。根据产生的影响不同，一般将风险分为三类：工程风险、产品风险和业务风险。下表给出了一些典型风险：风险风险类型风险描述职员跳槽项目有经验的职员未完成项目就跳槽管理层变更项目不同的管理层考虑、关注的事情会不同硬件缺乏项目项目所需的基础硬件没有按期交付需求变更项目和产品软件需求与预期的相比，将会有较大变化描述延迟项目和产品有关主要接口的描述未按期完成低估了系统规模项目和产品过低估计了系统的规模CASE工具性能较差产品支持项目的CASE工具达不到要求技术变更业务系统的基础技术被新技术取代产品竞争业务系统还未完成，其它有竞争力的产品就已经上市了10以下图是风险管理过程示意图。风险识别风险分析风险规划风险监控潜在的风险列表优先级高的风险列表风险规避和应急计划风险评估(1)风险识别风险识别是风险管理的第一阶段，其目的是发现可能的风险。右表给出了可能的风险及风险类型的实例。这些风险将可能影响到软件产品、过程或业务。风险类型可能的风险技术系统使用的数据库的处理速度不够快要复用的软件组件有缺陷，限制了项目的性能人员招聘不到符合项目技术要求的职员在项目的非常时刻，关键职员生病，无法发挥作用职员所需的培训跟不上机构重新进行机构调整，由不同的管理层负责这个项目开发机构的财务出现问题，必须削减项目预算工具CASE工具产生的编码效率低CASE工具不能被集成需求需求发生变化，主体设计要返工客户不了解需求变更对项目造成的影响估算低估了软件开发所需要的时间低估了缺陷的修补率低估了软件的规模11(2)风险分析

风险分析就是对每一个已经识别的风险，对其出现的可能性和影响的严重性作出判断。风险出现可能性的评估大致可以有：非常小(<10%)、小(10～25%)、中等(25～50%)、大(50～75%)、很大(>75%)。风险出现的可能性后果开发机构的财务出现问题，必须削减项目预算小灾难性招聘不到符合项目技术要求的职员大灾难性在项目的非常时刻，关键职员生病中等严重要复用的软件组件有缺陷，限制了项目的性能中等严重需求发生变化，主体设计要返工中等严重开发机构调整，由不同的管理层负责这个项目大严重系统使用的数据库的处理速度不够快中等严重低估了软件开发所需要的时间大严重CASE工具不能被集成大可容忍客户不了解需求变更对项目造成的影响中等可容忍职员所需的培训跟不上中等可容忍低估了缺陷的修补率中等可容忍低估了软件的规模大可容忍CASE工具产生的编码效率低中等可忽略风险影响大小的评估，可能的结果有：灾难性的、严重的、可以容忍的和可以忽略的。右表是对上表已识别风险分析后得出的结果作成的表格：这个表格的内容应随着工程的进展而更新。经过风险分析和排序，就可以判断哪些风险是最重要需要优先关注的，以有利于工程的顺利开展。12(3)风险规划风险规划过程就是对已识别的每一个重大风险，确定相应的处理策略。制定风险管理方案同样需要工程管理者的判断和经验。下表给出了处理上表中严重和灾难性风险的可能的策略。风险策略机构的财务风险拟一份简短报告，提交高层管理者，说明这个项目将对业务目标有重大贡献职员招聘风险稳定已有职员，加紧招聘工作，加紧已有低层职员的培训、培养职员生病风险重新对团队进行组织，使更多工作可以并发和重叠，员工可以了解他人工作有缺陷的组件购买更可靠、稳定的组件，替代有潜在缺陷的组件需求变更导出可追溯信息来评估需求变更带来的影响，把隐藏在设