软件项目管理

1、软件项目管理一、名词解释1、软件项目管理:软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。2、需求管理:一个为系统的需求进行启发、组织、建档的系统方法，一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。3、软件配置管理:软件配置管理是指通过执行版本控制、变更控制的规程,以及使用合适的配置管理软件,来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。4、软件风险管理:在进行软件项目时，辩识风险，评估它们出现的概率及产

2、生的影响，然后建立一个规划来管理风险。风险管理(RiskManagement)的定义为，当企业面临市场开放、法规解禁、产品创新，均使变化波动程度提高，连带增加经营的风险性。良好的风险管理有助于降低决策错误之几率、避免损失之可能、1相对提高企业本身之附加价值.二、简答1、对软件项目经理的要求包括哪些内容,答:(1)在本行业中某一技术领域中具有权威，技术过硬(2)任务分解能力强(3)注重对项目成员的激烈和团队建设，能量好地协调项目小组成员的关系(4)具备较强的客服人际关系能力(5)具有很强的工作责任心，能够接受经常加班的要求(6)应更注重管理方面的贡献，胜过作为技术人员的贡献。项目经理是项目组织的

3、管理者，负责对项目的计划、组织、领导和控制等工作，因此，一个项目经理必须具备以下几方面的能力:5大素质要求:职业道德、身体素质、心理素质、知识、经验4大能力要求:领导能力、决策能力、沟通能力、人力资源开发能力每个素质能力要求点都蕴含着无限的深意，甚至其中一点足够优秀，就可以让你成为一个非常成功的人。但作为真正合格的项目经理，你必须全面，除非你对这个职业没有足够的热情。我们一起来认识他们，给自己一个修炼的方向。良好的职业道德:良好的职业道德表现为做人做事的责任心，面对利益冲突的原则性，团队合作的积极性与热情。不仅如此，而且有着更广泛的内容。思考吧，职业道德绝对是成为合格项目经理的必要条件之一。健

4、康的身体:身体是革命的本钱。软件项目经理是一个劳心劳力的职业，“责任重而权力小”是大家的共识。这一切都需要健康的身体。优秀的心理素质:心理素质对一个项目经理太重要了。当然，如果你的心理素质很好，也许你不会感到这是什么问题。让我感觉，心理素质的一个重要表现是:面对重大的项目压力时，你的心理承受情况如何,坚实的知识积累:知识决定命运，同样决定着项目经理的命运。坚实的知识积累，当然我更多指跟项目经理职业相关的知识，会成为你项目经理职业生涯的坚实后盾。丰富的经验:有丰富的经验注定重要，没有人会反对这一点。但我想说的是，如果你没有经验，不要气馁，谁生下来就做过项目经理呢。更重要的是把握获取和积累经验的机

5、会。一旦你有机会，不要轻易放弃，而要抓住机会，努力为自己积累经验。如果你恰好刚刚抓住这个机会，我建议你，仔细检查一下自己从事这一职业尚需修炼的内容。领导能力:项目经理需要领导能力，而作为项目经理也正在运用着领导能力从事领导工作。可见领导能力是项目经理必备的能力之一。项目经理做好领导工作，关键做好如下四件事情:1)选择正确的人;2)为他们分配正确的工作;3)保持他们的积极性;4)帮助团队凝聚起来并保持团队的凝聚力。作为项目经理，能做好这四件事情，至少能保证你的领导能力有了不错的发挥。希望你与我一样，能细细体会。决策能力:项目经理作为基层管理人员，又不同于普通的基层管理人员，常常面对各种项目决策，

6、需要较强的决策能力。其实，我更想说的是，决策技巧能力。不要把决策与拍板简单等价，务必要认识到决策技巧的重要性。分清哪些是你可以直接作决策的，哪些必须是借助集体力量才能作决策的，甚至哪些是你根本不能参与任何决策的。沟通能力:各种项目管理书籍都强调沟通能力的重要性。也的确如此，沟通能力是软件开发项目经理必须具备的首要能力。如果要成为一名出色的项目经理，务必重视沟通能力的培养，但同时一定要注意沟通的技巧，让沟通成为真正有效的沟通。人力资源开发能力人员开发的能力，虽然我常会提到，但我也很明白，并不是所有的项目经理都真正认识到它的重要性。对于刚刚踏上项目经理职路上的人们，这也是可以理解的。让你手上资源升

7、值的途径很多，你一定要仔细斟酌。尽量多的培训、充足的内部交流、非工作方面的经验交流等等，都是必不可少的。2、软件项目估算规模的基本方法有几种,答:(1)Delphi法(2)类比法(3)功能估算法(4)PERT估计法方法一、Delphi法Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。这种方式对决定其它模型的输入时特别有用。方法二、类比法类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。方法三、功能点估计法功能点测量是在需求分析阶段基于系统功能的一种规模估计方法。通过研

8、究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。方法四、PERT古计法PERT寸各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert统计估计。Pert估计可得到代码行的期望值E，和标准偏差SD.方法一、Delphi法Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家"专"的程度及对项目的理解程度是工作中的难点，尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成

9、本时通常用得不多，但是，这种方式对决定其它模型的输入时特别有用。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种软件相关经验人的参与，互相说服对方。Delphi法的步骤是:1、协调人向各专家提供项目规格和估计表格;2、协调人召集小组会各专家讨论与规模相关的因素;3、各专家匿名填写迭代表格;4、协调人整理出一个估计总结，以迭代表的形式返回专家;5、协调人召集小组会，讨论较大的估计差异;6、专家复查估计总结并在迭代表上提交另一个匿名估计;7、重复4-6，直到达到一个最低和最高估计的一致。方法二、类比法类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目

10、的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。其基本步骤是:1、整理出项目功能列表和实现每个功能的代码行;2、标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方;3、通过步骤1和2得出各个功能的估计值;4、产生规模估计。软件项目中用类比法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测

11、试的代码百分比。根据这三个百分比，可用下面的计算公式计算等价新代码行:等价代码行=(重新设计+重新编码+重新测试)/3x已有代码行比如:有10,000行代码，假定30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的代码行可以计算为:(30%+50%+70%)/3X10,000=5,000等价代码行。意即:重用这10000代码相当于编写5000代码行的工作量。方法三、功能点估计法功能点测量是在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。通常的步骤是:1、计算输入，输出，查询，主控文件，和接口需求的数目。2

12、、将这些数据进行加权乘。下表为一个典型的权值表。功能类型权值输入4输出5查询4主控文件10接口103、估计者根据对复杂度的判断，总数可以用+25%、0、或-25%调整。据发现，对一个软件产品的开发，功能点对项目早期的规模估计很有帮助。然而，在了解产品越多后，功能点可以转换为软件规模测量更常用的LOC。方法四、PERT古计法PERT寸各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert统计估计。Pert估计可得到代码行的期望值E，和标准偏差SD.3、什么是软件需求规格说明书,良好的软件需求规格说

13、明书应有哪些属性,答:软件需求的定义IEEE软件工程标准词汇表(1997年)中定义需求为：(1) 用户解决问题或达到目标所需的条件或权能(Capability)。(2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。(3) 一种反映上面(1)或(2)所描述的条件或权能的文档说明。软件需求包括三个不同的层次业务需求、用户需求和功能需求也包括非功能需求。业务需求(businessrequirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(userrequirement)文档描述了用户使用产品必须要完成的任务，

14、这在使用实例(usecase)文档或方案脚本(scenario)说明中予以说明。功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。

15、多角度描述产品对用户和开发人员都极为重要。值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。4、软件配置管理的任务有哪些,答:软件配置管理的主要任务也就归结为以下几条:(1)制定项目的配置计划;(2)对配置项进行标识;(3)对配置项进行版本控制;(4)对配置项进行变更控制;(5)定期进行配置审计;(6)向相关人员报告配置的状态。在此，我想特别指出的是:由于软件配置管理覆盖了整个软件的开发过程，因此它是改进我们的软件过程、提高过程能力成熟度的理想的切入点。希望本文所描述的这个软件配置管理的角色分配和工作流程能在实践中

16、不断地得到完善，从而使我们的软件开发活动能够更加有序、高效的进行5、简述软件风险管理的基本过程。答:对于现代企业来说，风险管理就是通过风险的识别、预测和衡量、选择有效的手段，以尽可能降低成本，有计划地处理风险，以获得企业安全生产的经济保障。这就要求企业在生产经营过程中，应对可能发生的风险进行识别，预测各种风险发生后对资源及生产经营造成的消极影响，使生产能够持续进行。可见，风险的识别、风险的预测和风险的处理是企业风险管理的主要步骤。风险管理就是一个识别、确定和度量风险，并制定、选择和实施风险处理方案的过程。风险管理应是一个系统的、完整的过程，一般也是一个循环过程。风险管理过程包括风险识别、风险评

17、价、风险对策决策、实施决策、检查五方面内容。1. 风险识别是风险管理中的首要步骤，是指通过一定的方式，系统而全面地识别出影响建设工程目标实现的风险事件并加以适当归类的过程，必要时，还需对风险事件的后果作出定性的估计。2. 风险评价风险评价是将建设工程风险事件的发生可能性和损失后果进行定量化的过程。这个过程在系统地识别建设工程风险与合理地作出风险对策决策之间起着重要的桥梁作用。风险评价的结果主要在于确定各种风险事件发生的概率及其对建设工程目标影响的严重程度。3.风险对策决策风险对策决策是确定建设工程风险事件最佳对策组合的过程。一般来说，风险管理中所运用的对策有以下四种:风险回避、损失控制、风险自

18、留和风险转移。这些对策的适用对象各不相同，需要根据风险评价的结果，对不同的风险事件选择最适宜的风险对策，从而形成最佳的风险对策组合。4. 实施决策对风险对策所作出的决策还需要进一步落实到具体的计划和措施。5.检查在建设工程实施过程中，要对各项风险对策的执行情况不断地进行检查，并评价各项风险对策的执行效果;在工程实施条件发生变化时，要确定是否需要提出不同的风险处理方案。除此之外，还需检查是否有被遗漏的工程风险或者发现新的工程风险，也就是进入新一轮的风险识别，开始新一轮的风险管理过程。一、风险识别风险识别过程的活动是将不确定性转变为明确的风险陈述。包括下面几项，他们在执行时可能是重复，也可能是同时

19、进行的:1、进行风险评估。在项目的初期，以及主要的转折点或重要的项目变更发生时进行。这些变更通常指成本、进度、范围或人员等方面的变更。2、系统地识别风险。采用下列三种简单的方法识别风险:风险检查表，定期会议（周例会上），日常输入（每天晨会上）。3、将已知风险编写为文档。通过编写风险陈述和详细说明相关的风险背景来记录已知风险，相应的风险背景包括风险问题的何事、何时、何地、如何及原因。4、交流已知风险。同时以口头和书面方式交流已知风险。在大家都参加的会议上交流已知风险，同时将识别出来的风险详细记录到文档中，以便他人查阅。二、风险分析风险分析过程的活动是将风险陈述转变为按优先顺序排列的风险列表。包括

20、以下活动:1、 确定风险的驱动因素。为了很好地消除软件风险，项目管理者需要标识影响软件风险因素的风险驱动因子，这些因素包括性能、成本、支持和进度。2、 分析风险来源。风险来源是引起风险的根本原因。3、 预测风险影响。如果风险发生，就将可能性和后果来评估风险影响。可能性被定义为大于0而小于100，分为5个等级（1、2、3、4、5）。将后果分为4个等级（低，中等，高，关键的）。采用风险可能性和后果对风险进行分组。4、 对风险按照风险影响进行优先排序，优先级别最高的风险，其风险严重程度等于1，优先级别最低的风险，其风险严重程度等于20。对级别高的风险优先处理。三、风险计划风险计划过程的活动是将按优先

21、级排列的风险列表转变为风险应对计划。包括以下内容:1、 制定风险应对策略。风险应对策略有接受、避免、保护、减少、研究、储备和转移几种方式。2、 制定风险行动步骤。风险行动步骤详细说明了所选择的风险应对途径。它将详细描述处理风险的步骤。四、风险跟踪风险跟踪过程的活动包括监视风险状态以及发出通知启动风险应对行动。包括以下内容:1、 比较阈值和状态。通过项目控制面板来获取。如果指标的值在可接受标准之外，则表明出现了不可接受的情况。2、 对启动风险进行及时通告。对要启动的风险，在每天的晨会上通报给全组人员，并安排负责人进行处理。3、 定期通报风险的情况。在定期的会议上通告相关人员目前的主要风险以及他们

22、的状态。五、风险应对风险应对过程的活动是执行风险行动计划，以求将风险降至可接受程度。包括以下内容:1、 对触发事件的通知作出反应。得到授权的个人必须对触发事件作出反应。适当的反应包括回顾当前现实以及更新行动时间框架，并分派风险行动计划。2、 执行风险行动计划。应对风险应该按照书面的风险行动计划进行。3、对照计划，报告进展。确定和交流对照原计划所取得的进展。定期报告风险状态，加强小组内部交流。小组必须定期回顾风险状态4、校正偏离计划的情况。有时结果不能令人满意，就必须换用其他途径。将校正的相关内容记录下来。风险管理的基本程序包括风险识别、风险估测、风险评价、风险控制和风险管理效果评价等环节。1（

23、风险的识别风险的识别:是经济单位和个人对所面临的以及潜在的风险加以判断、归类整理，并对风险的性质进行鉴定的过程。2(风险的估测风险的估测:是指在风险识别的基础上，通过对所收集的大量的详细损失资料加以分析，运用概率论和数理统计，估计和预测风险发生的概率和损失程度。风险估测的内容主要包括损失频率和损失程度两个方面。3(风险管理方法风险管理方法分为控制法和财务法两大类，前者的目的是降低损失频率和损失程度，重点在于改变引起风险事故和扩大损失的各种条件;后者是事先做好吸纳风险成本的财务安排。4(风险管理效果评价风险管理效果评价是分析、比较已实施的风险管理方法的结果与预期目标的契合程度，以此来评判管理方案

24、的科学性、适应性和收益性。三、分析1、结合下图，试论述需求开发和需求管理的活动上图是需求工程的组成部分，从图中可以看出，需求工程划分为两个部分:需求开发和需求管理。需求开发又分为需求获取(Elicitation)、需求分析(Analysis)、编写规约(Specification)和需求验证(Validation)。需求管理又分为基线管理、变更管理、需求跟踪。下面我将分别介绍一下上面各个主要组成部分主要的工作内容，以便那些不熟悉需求的人员读后能够从总体上把握需求所涉及的工作内容。需求开发需求开发活动包括以下几个方面,确定产品所期望的用户分类。,获取每类用户的需求。,了解实际用户任务和目标以及这

25、些任务所支持的业务需求。,分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。,将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。,了解相关质量属性的重要性。,商讨实施优先级的划分。,将所收集的用户需求编写成规格说明和模型。？评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。实际工作中很难一次性得到完全正确的需求，所以以上步骤并不是严格顺序执行到底的，它是一个不断反复的过程。这些步骤也不是完全顺序的，很可能需要迭代的进行。基于项目的产品需求开发过程可能如下图所示:实际工作中很难一次性得到完全正

26、确的需求，所以以上步骤并不是严格顺序执行到底的，它是一个不断反复的过程。这些步骤也不是完全顺序的，很可能需要迭代的进行。基于项目的产品需求开发过程可能如下图所示:企业需求H发是一个不断反复的过程开发商开裳商？Eft胃物喇JKH企ii漫忤群弹甲缁证，井提山修改意见X.二科一南瞰修中后的料,喻上北电u*#值马泵TI一版新板属和福振我再至谑3I人-L企业人可备期%OK下面就需求开发每个活动进行简单介绍：需求获取在软件需求的三个层次中介绍了三个层次的需求，在需求获取中，这些需求都是我们需要获取的，我们需要收集问题域的描述，要求解决的问题列表，以及了解系统的行为或约束。信息来源,客户（实际的和潜在的）,

27、用户（实际的和潜在的）,已有系统及其文档,领域专家,相关技术标准和法规获取技术，阅读背景资料,用户访谈、调研,需求讨论会现场观摩需求分析需求分析是指通过对需求获取中获得的问题域的研究，获得对该领域特性及存在其中的问题特性的透彻理解并用文档说明。,不需要等到需求完全捕获后开始，在“业务需求”充分理解下，并且收集了本质的“用户需求”之后就可以开始进行需求分析,交替进行，先把握“用户需求”主要部分，然后在分析的基础上引入系统级的需求（系统的涉及与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台,分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二

28、次的需求调研计划、问题和素材编写规约,规格说明书是对需求分析结果的文档化过程,需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离,为需求规约定义统一的格式是一个很重要的工作,规约内容必须严谨、正确、无歧义需求验证,不重视需求验证工作会在系统交付时，客户发现不是这样的，导致不期望的需求变更,提高需求质量的重要手段有:需求评审、需求确认和原型验证需求方法之原型开发需求管理需求管理活动包括：,定义需求基线(迅速制定需求文档的主体)。,评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。,以一种可控制的方式将需求变更融入到项目中。，使当前的项目计划与需求一致。,估计变更需求所产生影响并在此基础上协商新的承诺(约定)。,让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。,在整个项目过程中跟踪需求状态及其变更情况。什么是软件需求规格说明书，组成