软件计划项目管理计划论文材料.doc

《软件计划项目管理计划论文材料.doc》由会员分享，可在线阅读，更多相关《软件计划项目管理计划论文材料.doc（23页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、#+ 软件工程专业软件项目管理 课程设计报告题 目： 软件项目管理 姓 名： 郑闽君 准考证号： 910210311311 学 院： 数学与计算机科学学院专 业： 软件工程 年 级： 09级 2010 年 3 月 #+目 录1 绪论11.1 研究背景11.2目前相关研究现状及分析11.3 现行项目管理存在的主要问题分析22 软件项目管理的组织模式33 软件项目管理过程43.1项目启动阶段43.2项目计划阶段43.3项目实施( 执行) 阶段53.4 项目收尾 ( 关闭) 阶段64 软件项目管理的内容84.1软件项目需求管理84.1.1目标84.1.2原则94.1.3需求管理活动94.1.4需求管

2、理质量保证94.2软件项目估算与进度管理104.2.1软件项目估算104.3软件项目配置管理114.3.1目前软件开发中面临的问题114.3.2软件配置管理应提供的功能124.4版本管理124.5软件质量管理124.5.1软件质量保证计划134.6软件风险管理154.6.1风险的分类154.6.2风险的评价164.6.3风险的驾驭和监控164.7人员管理164.8人力资源管理中的风险管理175 结束语18参考文献19#+1 绪论1.1 研究背景随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。各软件企业都在积极将软件项目管理引入开发活动

3、中，对开发实行有效的管理。我公司是西安一家中型软件企业，在公司中已经实行了项目管理制度，软件项目管理是整个项目管理中的一个重要组成部分。 从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展（即减小开发风险）。 软件开发不同于其他产品的制造，软件的整个过程都是设计过程（没有制造过程）；另外，软件开发不需要使用大量的物质资源，而主要

4、是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。基于上述特点，软件项目管理与其他项目管理相比，有很大的独特性1.2目前相关研究现状及分析一个值得深思的事实是，到目前为止，已经信息化的企业在IT（Information Technology，信息技术）的投资超过了未信息化企业在IT的投资。这意味着什么？这意味着IT项目的投资已经由厂商驱动向用户驱动转变，以往什么利润高IT厂商就说什么好，用户低着头掏腰包的时代过去了。现在大多数的用户都经历过信息化，或成功过，或失败过，经验教训都有了许多。用户更加重视企业信息战略的规划、IT投资的实实在在的效益。 一方面，能够为用户提

5、供IT能力的厂商如雨后春笋般成长，这些企业为了生存，竞争手段花样百出，竞争也日趋白热化。那么，作为IT企业，要想在竞争的市场上持续发展，就必须提高自己核心竞争力。IT企业的竞争力体现在两方面：一是IT解决方案的技术水平；一是IT项目的实施能力。相对于前者，后者在短期提高利润方面更能显示出威力。因为项目管理水平的提高，意味着项目能得到更好地控制。成本能得到更多的节约，人力资源能得到更加合理的安排，客户的需求能得到更好地满足。1.3 现行项目管理存在的主要问题分析再看看国内市场，我国虽然在网络门户、电子商务的模仿、借鉴和推动方面丝毫不亚于西方发达国家，但是在软件项目管理和专业人才的培养方面却大大滞

6、后。所以如何将一个个自由英雄更好、更有效地团结起来，组建出高效的开发小组，已成为越来越多管理者思考的重点。在小组中，每个人的工作都是与其他相关联的，因此，小组成员除了保证自己担负的任务的质量的同时，还需要关注其他关联角色的任务，假使界面工程师迟迟无法定义产品流程，美工人员也许只能望纸生叹，而美工人员不能将产品界面文件及早完成而任由程序员随意定义界面的话，后期重新美化的工作量可能大到重写一遍代码的地步。因此，需要时时掌握小组每个成员的工作进度，并进行监督和协调。有经验的管理人员都知道，项 目的计划和进度在实施中必不可少地会进行调整，这种调整可能来自于：客户的需求进行了补充或修改；工作量估算不准，

7、造成进度不平衡；某个技术环节出现障碍，需要另外需求人员或帮助；有人不遵从开发规范，导致产品缺陷等方面。在面对意料中的意外时，项目管理人员需要有应急解决的办法，从而保障开发持续稳定地向目标前进。项目经理对人员的管理、进度的掌握、质量的控制、成本的核算等等所做的工作已经远远山东三联电子信息有限公司济南2 5 0 0 1 2 超过代码本身，作为项目负责人，应随时能掌握先进的技术和方法并在适当的时机采用，管理整个项目小组往既定的目标前进。因此需要建立完善的软件项目管理体系， 使其覆盖公司范围内所有软件项 目类型， 实现公司级和项 目级不同层面对软件项目进行有效的管理和监督， 确保项 目在既定的时间和成

8、本范围内， 达到计划 目标， 满足客户的需求。 2 软件项目管理的组织模式软件项目可以是一个单独的开发项目，也可以与产品项目组成一个完整的软件产品项目。如果是订单开发，则成立软件项目组即可；如果是产品开发，需成立软件项目组和产品项目（负责市场调研和销售），组成软件产品项目组。 公司实行项目管理时，首先要成立项目管理委员会，项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。1、项目管理委员会 项目管理委员会是公司项目管理的最高决策机构，一般由公司总经理、副总经理组成。主要职责如下： （1）依照项目管理相关制度，管理项目； （2）监督项目管理相关制度的执行； （3）对项目立项、项目撤消

9、进行决策； （4）任命项目管理小组组长、项目评审委员会主任、项目组组长. 2、项目管理小组 项目管理小组对项目管理委员会负责，一般由公司管理人员组成。主要职责如下： （1）草拟项目管理的各项制度； （2）组织项目阶段评审； （3）保存项目过程中的相关文件和数据； （4）为优化项目管理提出建议。 3、项目评审小组 项目评审小组对项目管理委员会负责，可下设开发评审小组和产品评审小组，一般由公司技术专家和市场专家组成。主要职责如下： （1）对项目可行性报告进行评审； （2）对市场计划和阶段报告进行评审； （3）对开发计划和阶段报告进行评审； （4）项目结束时，对项目总结报告进行评审。 4、软件产品项

10、目组 软件产品项目组对项目管理委员会负责，可下设软件项目组和产品项目组。软件项目组和产品项目组分别设开发经理和产品经理。成员一般由公司技术人员和市场人员构成。主要职责是：根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。3 软件项目管理过程为保证软件项目获得成功，必须清楚其工作范围、要完成的工作任务、需要的资源、需要的工作量、进度安排、可能遇到的风险等。软件项目的管理工作在技术工作开始之前就应开始。而在软件从概念到实现的过程中继续进行，且只有当软件开发工作最后结束时才终止。管理的过程一般分为以下几个阶段：3.1项目启动阶段 启动软件项目是指必须明确项目的目标和范围、考虑可能的

11、解决方案以及技术和管理上的要求等这些信息是软件项目运行和管理的基础。a 注重和客户的沟通，了解客户的期望以及对项 目的认知情况，了解客户的业务，进一步了解相关技术，编写初步需求分析报告和项目建设方案。 b 交付物：项目建议书、需求规格说明书、概要设计说明书、详细设计说明书、测试计划配置管理、开发立项申请报告等。 在这一阶段，正确理解或记录需求，并充分地控制需求变更，十分重要，可以避免成本增加、 延期交付以及开发质量不高， 从而提高客户满意度。正确的需求分析和确定需求规格对一个项 目的成功是非常关键的。3.2项目计划阶段 a 制订项目实施计划：将工作进行足够细的分解( WB S ) 、制定详细的

12、时间进度表、 选定各阶段的里程碑事件。包括项目进度安排、质量计划、项目测量计划、项目培训计划、配置管理计划 、 定义项目跟踪规程、定义项目计划的假设前提，对项目计划和工作安排进行组评审( 现在没进行这一活动) ，获得高级管理者的授权即公司领导签批。 b 参加者有项目负责人、客户、S E P G公司评审小组(质量顾问。如果过程改进想获得成功，需要很多因素的支持，形成一个担负起协调内部过程活动的核心小组是一个成功的因素， 同时也是 C M M3机构过程焦点 K P A的一个重要实践。这个核心小组通常称为软件工程过程组，S o f t w a r e E n g in e e r i n g P r

13、 o c e s s G r o u p ， S E P G，由质量专家组成，工作就是监督和改进用于改进机构的过程。这些人占公司软件工程师的比例大约为 1 5 ) 和项目的业务主管。c 入口准则：合同已签和项目已授权。主要的输出是合同或建议书。 d 出口准则：制定出项目计划并经过组评审。主要输出是计划文档和评审记录。 这个阶段主要的测量项是花费的工作量和在评审时发现的缺陷。3.3项目实施( 执行) 阶段 包括执行项 目计划和当项 目进展偏离项 目计划时采取的纠正活动。或者说是项目跟踪和控制项 目过程的实现。a 主要活动有：跟踪项目状态；与高级管理者评审项目状态；管理需求变更；监督项目与定义好的

14、项 目过程的一致性，其中要从两方面注意：一是对项 目计划和工作安排进行组评审，与项目经理定好并要求传达到项目组成员；二是项目计划如有变化要及时提出申请，报分管领导审批；进行里程碑评审。 b 参加者有项目负责人、客户、S E P G、项目组成员和项目的业务主管。 c 入口准则：项目计划完成并被批准。主要输出是项目计划和项目文档， 如合同软件需求等。d 出口准则：客户接受的所有已提交的工作产品。输出是计划文档、 评审记录、 状态报告和类似的文档。 这个阶段主要测量花费的工作量。软件项目管理的基础是软件项目计划，通过项目周报、里程碑报告等方式来跟踪项目的实际执行状况，并参照项目计划比对偏差，从而采取

15、相应的措施来保证软件项目的顺利进行。软件项目在执行的过程中，从以下三个层面对项目的状况进行跟踪和监督。 项目经理在项目初期制定项目计划，并在项目执行的过程中通过管理项目组的日常活动跟踪项目的进展状况，根据实际完成的工作更新项 目计划。如果项目计划出现重大变更，则要申请变更项目计划，根据变更后的项目计划来执行工作。 根据项目计划、项目周报和里程碑报告等方式跟踪项目的阶段偏差(进度 、成本) 、质量状况、需求变更等内容，判断项目中存在的风险并采取相应的措施，处理项目组解决不了的问题。当项目出现重大偏差时，决定是否变更项目计划及采取有效措施。计划经营部收集所有项 目的项目周报和项目里程碑报告，并通过

16、数据汇总与分析，计算项目T Q C( 进度、质量和成本) 偏差情况，然后根据偏差情况采取相应的措施。为项目组指定质量经理，对项目进行阶段检查，判断项目的执行情况，提供项目对公司的项目管理体系的遵循情况。 3.4 项目收尾 ( 关闭) 阶段从我们做项目的经验来看， 在项目进行过程中由于项目组成员的全体合作，加上公司领导对这个项目非常重视，所以在整个项目过程中工作开展的还是比较顺利的，在项目进行到编码时，进度还基本控制在计划的范围内，但在项目将近收尾阶段却出现较多的问题。 项目收尾阶段的主要活动：项目结束的数据分析，包括执行的度量数据分析，为将来使用而收集的过程评估 ，记录学到的经验教训等等。参加

17、者是项目负责人、项目组成员、项目的质量顾问和业务主管。主要输出是在项目中采集的度量数据、客户抱怨记录和项目计划。入口准则是客户已接受的工作产品，出口准则是召开项目结束会议。输出是项目结束报告和从项目中收集的过程评估。项目收尾其实并不只是收尾阶段要做的事情，它的根源会牵扯到项目的各个阶段。谈起项目收尾，根据 P MI ( 美国项目管理协会) 的概念，项 目收尾包括合同收尾和管理收尾两部分。 合同收尾： 合同收尾就是抓起合同，和客户一项项的核对，是否完成了合同所有的要求，是否可以把项目结束，也就是我们通常所讲的验收。 主要的问题在足够的里程碑事件的确认书。在将要提供交付物之前临时准备相关的文档 ，

18、需要补充许多应该在项目执行阶段签署的确认文档。谁也不愿意在项目“ 接近”结束的时候陷入困境 ，客户不断的提出新要求；以为已经干完了“ 该干的事情”，结果拿起合同一看，客户要一项一项地对合同的话，根本就不可能验收。迟迟不能验收的原因是缺少 测试报告和 项目实施方案，没有及时的对已完成的系统的自测结果要求用户签署阶段性确认书。为避免这种情况的出现，应从以下方面注意： a 项目开始的时候是不是看着最后的合同验收来做事呢?从一开始就尽可能地按合同要求来做，一定不要留给对方抓小辫子的机会。当然业务人员在签合同时，为了拿下这个项 目，把项目吹得能把客户想要的一切都办得到，在客户面前信誓旦旦才能把项目签下来

19、。这也应该能够理解，项目做得不好，最难交待的还是他们。但是项目启动之后，项目经理是否就应该好好的研究合同，与业务人员沟通，了解客户最想要的是什么，然后重新列出项 目的范围， 尽可能让客户认同，锁定项目范围。这样就算不能完全避免需求不断增加不断改变的风险，也能有所改善的。b 还需要的就是与客户做好沟通，这个时候谈判的技巧是很重要的，既要不卑不亢，又要理据充分，不能胡编乱造哄骗客户，客户不是傻子，他们如果怀疑你的能力和诚信以后就更难沟通了。在难度不大改变不多的时候，我们更应该的是作出适当的退让，爽快的答应客户的要求，然后让他们知道我们作出了多大的牺牲去帮助他们实现愿望。管理收尾： 为了使项目干系人

20、对项目产品的验收正式化而进行的项目成果验收和归档，收集项目记录保存项目信息(包括项目总结)管理收尾是对于内部来说的，把做好的项目文档等归档；对外宣称项目已经结束；转入维护期，把相关的产品说明转到维护组；进行经验教训总结，项 目成员一起来“ 怀旧” 学习一把。 把项目文档整理一下归档，对于项目的延续性是有很重要的意义的。项目经理把项 目经验归纳归档起来，又会对别的项 目经理、对公司的项目管理文化作出了不少的贡献。很多著名的公司都对项 目经验总结这一环节看得很重，毕竟现在业界提倡的 P MM( P r o j e c t Ma t u r i t y M o d e 1 ) 的最高境界就是不断地学

21、习改进。 当项目规模或时间达到一定程度时，粗放式、不规范的管理方法是行不通的，在具体实施过程中必将在无休无止的项目变更和反复的与干系人的交流中消耗掉极大量的时间和成本。 所以越是大的项目越是要进行规范的项目管理，规范化的初期可能是痛苦的，可结果却是值得的。从目前看，公司的运营成本是增加了，因为要增加管理人员、撰写文档也需要人手，但从长远看，其会带来降低成本、提高质量、提高用户满意度等好处。对此，我们应确信不疑。 4 软件项目管理的内容根据公司实际情况，公司在进行软件项目管理时，重点将软件配置管理、软件质量管理、软件风险管理及开发人员管理四方面内容导入软件开发的整个阶段。 在八十年代初，著名软件

22、工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则，同样，我们在进行软件项目管理时，也应该遵循这七条原则。它们是： （1）用分阶段的生命周期计划严格管理； （2）坚持进行阶段评审； （3）实行严格的产品控制； （4）采用现代程序设计技术； （5）结果应能够清楚地审查； （6）开发小组地人员应该少而精； （7）承认不断改进软件工程实践地必要性。 4.1软件项目需求管理软件需求是软件工程过程中的重要一环，是软件设计基础。也是用户和软件工程之间的桥梁。简单的说，软件需求就是确定系统需要做什么，严格意义上，软件需求是系统或软件必须达到的目标与能力。4.1.1目标需求管理是一种获取、组织并

23、记录软件需求的系统化方案，同时也是一个使客户与项目开发组对不断变更的软件需求达成并保持一致的过程。在需求管理中，软件工程组的工作是采取适当的措施来保证分配的需求，即要将分配的需求文档化，控制需求的变化，负责项目实施过程中需求的实现情况。需求管理的目的是在客户和处理客户需求的软件项目之间建立对客户需求的共同理解，需求管理的目标有两个：l 使软件需求受控，并建立供软件工程和管理使用的需求基线。l 使软件计划、产品和活动与软件需求保持一致。在需求管理过程，为实现第一个目标，必须控制需求基线的变动，按照变更控制的标准和规范的过程进行需求变更控制和版本控制；为实现第二个目标，必须就变更和软件项目各小组达

24、成共识，对软件项目计划做出调整，其中包括人员的安排、用户的沟通、成本的调整、进度的调整等。4.1.2原则为进行有效的需求管理，一般要遵循如下五条原则l 需求一定要分类管理 进行软件项目管理的时候，一定要将软件需求分出层次。不同层次需求的侧重点、描述方式、管理方式是不同的。l 需求必须分优先级 在软件项目中，如果出现过多的需求，通常会导致项目超出预算和预定进度，最终导致软件项目的失败，因而需求的优先级可能比需求本身更加重要。l 需求必须文档化 需求必须有文档记录。该文档必须是正确的、最新的、可管理的、可理解的，是经过验证的，是在受控的状态下变更的。4.1.3需求管理活动 需求管理在需求开发基础上

25、进行，贯穿于整个软件项目过程，是软件项目管理的一部分。在软件项目进行的过程中，无论正处于哪个阶段，一旦有需求错误出现或任何有关需求的变更出现，都需要需求管理活动来解决，需求管理是一个对系统需求变更了解和控制的过程。初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求活动就开始了。需求管理活动活动的任务变更控制建议需求变更并分析其影响，做出是否变更的决策版本控制确定单个需求和SRS（即功能规格说明）的版本需求跟踪定义对于其他需求及系统元素的联系链需求状态定义并跟踪需求的状态表1 需求管理活动4.1.4需求管理质量保证 需求验证过程 需求验证很重要，如果在构造设计开始之前，通

26、过验证基于的测试计划和原型测试来验证需求的正确性及其质量，就能大大减少项目后期的返工现象。需求验证可按以下步骤来进行： 审查需求文档 依照需求编写测试用例 编写用户手册 确定合格的标准l 验证的内容在需求验证过程中，需对需求文档中定义的需求执行多种类型的检查。有效性检查-对于每项需求都必须证明它是有效的，确实能解决用户面对的问题。一致性检查-在需求文档中，需求不应该冲突，即对同一个系统功能不应出现不同的描述或相互矛盾的约束。完备性检查-需求文档应该包括所有系统用户想要功能和约束。现实性检查-检查需求以保证能利用现有技术实现可检验性检查-描述的需求能够实际测试可跟踪性检查-需求的出处被清晰的记录

27、，每一个系统功能都能被跟踪到要求它的需求集合，每一项都能追溯到特定的用户要求。可调节性检查-需求变更能够不对其他系统大规模的影响/可读性检查-需求说明能否被系统购买者和最终用户读懂。l 需求评审 需求分析完成后，应由用户和系统分析员共同进行需求评审。鉴于需求规格说明是软件设计的基础，需求评审需要有客户方和承包商方的人员共同参与，检查文档中的不规范之处和遗漏之处。4.2软件项目估算与进度管理4.2.1软件项目估算软件项目包括工程估算和成本估算两个方面。软件估算作为软件项目管理的一项重要内容。是确保软件项目成功的关键因素。估算是指通过预测构造软件项目需要的工作量的过程。初步的估算用于确定软件项目的

28、可行性，详细估算用于指导项目计划的制定。4.2.1.1软件规模l 工作分解结构 对软件项目进行估算遇到的第一个问题就是软件规模、即软件的程序量。软件规模是软件工作量的主要影响因素。软件项目的设计有一个分层结构，这一分层结构就对应着工作分解结构（WBS Work Breakdown Structure），它将软件过程和软件产品结构联系起来。有了工作分解结构之后，还必须定义度量标准用以对软件规模进行估计。常用的软件规模度量标准有两种：代码行LOC(Line Of Code)和功能点FP（Function Points）。l 代码行代码行LOC是常用的源代码程序长度的度量标准，指源代码的总行数。源代

29、码中除了可执行语句外，还有帮助理解的注释语句。l 功能点功能点度量是在需求分析阶段基于系统功能的一种规模估计方法，该方法通过已经初始应用需求来确定各种输入、输出、查询、外部文件和内部文件的数目，从而确定功能点数量。4.2.1.2 软件项目成本估算 成本估算是对完成软件项目所需费用的估计和计划，是软件项目计划中的一个重要的组成部分。 成本估算步骤如下： 建立目标-规划需要的数据和资源-确定软件需求-拟订可行细节-运用多种独立的技术和原始资料-比较各个估算值-随访跟踪4.2.1.3 软件项目进度管理l 制定项目计划项目计划在项目开始时候制定，并随着项目的进展不断发展。软件项目计划的要素包括目标、合

30、理的概念设计、工作分解结构、规模设计、工作量估计和项目进度计划安排。项目计划为管理者提供了根据计划定期评审和跟踪项目进展的基础。l 进度安排在确定了项目的资源（总成本及时间等）后，把其分配到各个项目开发阶段中，即确定项目的进度项目各阶段的工作量。4.3软件项目配置管理 是否进行配置管理与软件的规模有关，软件的规模越大，配置管理就显得越重要。软件配置管理简称SCM（Software Configuration Management的缩写），是在团队开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。 4.3.1目前软件开发中面临的问题 。在有限的时间、资

31、金内，要满足不断增长的软件产品质量要求； 。开发的环境日益复杂，代码共享日益困难，需跨越的平台增多； 。程序的规模越来越大； 。软件的重用性需要提高； 。软件的维护越来越困难。 4.3.2软件配置管理应提供的功能 在ISO9000.3中，对配置管理系统的功能作了如下描述： 。唯一地标识每个软件项的版本； 。标识共同构成一完整产品的特定版本的每一软件项的版本； 。控制由两个或多个独立工作的人员同时对一给定软件项的更新；。控制由两个或多个独立工作的人员同时对一给定软件项的更新； 。按要求在一个或多个位置对复杂产品的更新进行协调； 。标识并跟踪所有的措施和更改；这些措施和更改是在从开始直到放行期间，

32、由于更改请求或问题引起的。 4.4版本管理 软件配置管理分为版本管理、问题跟踪和建立管理三个部分，其中版本管理是基础。版本管理应完成以下主要任务： 。建立项目； 。重构任何修订版的某一项或某一文件； 。利用加锁技术防止覆盖； 。当增加一个修订版时要求输入变更描述； 。提供比较任意两个修订版的使用工具； 。采用增量存储方式； 。提供对修订版历史和锁定状态的报告功能； 。提供归并功能； 。允许在任何时候重构任何版本； 。权限的设置； 。晋升模型的建立； 。提供各种报告。 4.5软件质量管理 随着软件开发的规模越来越大，软件的质量问题显得越来越突出。软件质量的控制不单单是一个软件测试问题，在软件开发

33、的所有阶段都应该引入质量管理。我公司除加强了国家标准信息技术软件生存期过程（GB/T8566-1995）的规范管理外，还积极为通过ISO 9000.3做准备。 4.5.1软件质量保证计划 在进行软件开发前，需要有一个软件质量保证计划。目前较常用的是ANSI/IEEE STOL 730-1984，983-1986标准，包括以下内容： 4.5.1.1质量管理的基本原则 。控制所有过程的质量； 。过程控制的出发点是预防不合格； 。质量管理的中心任务是建立并实施文件化的质量体系； 。持续的质量改进； 。有效的质量体系应满足顾客和组织内部双方的需要和利益； 。定期评价质量体系； 。搞好质量管理关键在于领

34、导。 4.5.1.2软件质量因素 正确性：系统满足规格说明和用户目标的程度，即，在预定环境下能正确地完成预期功能的程度。 健壮性：在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程度。 效率：为了完成预定的功能，系统需要的计算资源的多少。 完整性（安全性）：对未经授权的人使用软件或数据的企图，系统能过控制（禁止）的程度。 可用性：系统在完成预定应该完成的功能时另人满意的程度。 风险：按预定的成本和进度把系统开发出来，并且为用户所满意的概率。 可理解性：理解和使用该系统的容易程度。 可维修性：诊断和改正在运行现场发现的错误所需要的工作量的大小。 灵活性（适应性）：修改或

35、改进正在运行的系统需要的工作量的多少。 可测试性：软件容易测试的程度。 可移植性：把程序从一种硬件配置和（或）软件系统环境转移到另一种配置和环境时，需要的工作量多少。有一种定量度量的方法是：用原来程序设计和调试的成本除移植时需用的费用。 可再用性：再其他应用中该程序可以被再次使用的程度（或范围）。 互运行性：把该系统和另一个系统结合起来需要的工作量的多少。 4.5.1.3软件评审 软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误，如果这些错误不及时发现并纠正，会不断地扩大，最后可能导致开 发的失败。下面这组数据可以清楚的看出前

36、期的错误对后期的影响。 软件评审是相当重要的工作，也是目前国内开发最不重视的工作。 （1）评审目标 。发现任何形式表现的软件功能、逻辑或实现方面的错误； 。通过评审验证软件的需求； 。保证软件按预先定义的标准表示； 。已获得的软件是以统一的方式开发的； 。使项目更容易管理。 （2）评审过程 A、召开评审会议：一般应有3至5人参加，会前每个参加者做好准备，评审会每次一般不超过2小时。 B、会议结束使必须做出以下决策之一：接受该产品，不需做修改；由于错误严重，拒绝接受；暂时接受该产品。 C、评审报告与记录；所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审简要报告。 （3

37、）评审准则 。评审产品，而不是评审设计者（不能使设计者有任何压力）； 。会场要有良好的气氛； 。建立议事日程并维持它（会议不能脱离主题）； 。限制争论与反驳（评审会不是为了解决问题，而是为了发现问题； 。指明问题范围，而不是解决提到的问题； 。展示记录（最好有黑板，将问题随时写在黑板上）； 。限制会议人数和坚持会前准备工作； 。对每个被评审的产品要尽力评审清单（帮助评审人员思考）； 。对每个正式技术评审分配资源和时间进度表； 。对全部评审人员进行必要的培训； 。及早地对自己地评审做评审（对评审准则的评审）。 4.5.1.4ISO9000.3软件质量认证体系 ISO9000.3是ISO9000质

38、量体系认证中关于计算机软件质量管理和质量保证标准部分。它从管理职责、质量体系、合同评审、设计控制、文件和资料控制、采购、顾客提供产品的控制、产品标识和可追溯性、过程控制、检验和试验、检验/测量和试验设备的控制、检验和试验状态、不合格品的控制、纠正和预防措施、搬运/贮存/包装/防护和交付、质量记录的控制、内部质量审核、培训、服务、统计系统等二个方面对软件质量进行了要求。 4.5.1.5、测试 软件测试是软件开发的一个重要环节，同时也是软件质量保证的一个重要环节。所谓测试就是用已知的输入在已知环境中动态地执行系统（或系统的部件）。测试一般包括单元测试、模块测试、集成测试和系统测试。如果测试结果与预

39、期结果不一致，则很可能是发现了系统中的错误，测试过程中将产生下述基本文档： （1）测试计划：确定测试范围、方法、和需要的资源等。 （2）测试过程：详细描述和每个测试方案有关的测试步骤和数据（包括测试数据及预期的结果）。 （3）测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且必须经过调试解决所发现的问题。测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且必须经过调试解决所发现的问题。 4.6软件风险管理 软件项目管理存在着风险，如果我们提前重视风险，并且有所防范，就可以最大限度减少风险的发生。进行风险管理是有效的手段。 4.6.1风险的分类

40、根据风险内容，我们可以将风险分为项目风险（成本提高，时间延长等）、技术风险（技术不成熟等）、商业风险（销售问题等）、战略风险（公司的经营战略发生了变化）、管理风险（公司管理人员是否成熟等）、预算风险（预算是否准确等）等。 另外，我们还可以将风险分为已知风险（如员工离职等）、可预报风险（从以往经验得出可能有风险的）和不可预知风险。 4.6.1.1风险的识别 风险识别的有效方法是建立风险项目检查表。主要涉及以下几方面检查： 。产品规模风险检查 。业务影响风险检查 。与客户相关的风险检查 。过程风险检查 。技术风险检查 。开发环境风险检查 。与人员的模式和经验有关的风险检查 4.6.1.2风险评估

41、风险评估主要从下面七个方面进行： 。发生的可能性 。发生的结果（影响） 。建立一个尺度表示风险可能性（如，极罕见、罕见、普通、可能、极可能） 。描述风险带来的后果 。估计对产品和项目的影响 。确定风险评估的正确性 。根据影响排定有限队列 另外，要对每个风险的表现、范围、时间做出尽量准确的判断。 4.6.2风险的评价 对风险的评价主要依据三个因素：风险描述、风险概率和风险影响。从成本、进度及性能三个方面对风险进行评价。确定项目的中止点，在中止点出再一次进行风险评价。 4.6.3风险的驾驭和监控 风险的驾驭与监控主要要靠管理者的经验来实施。如，某开发人员的离职概率是0.7，离职后会对项目造成一定的

42、影响，则该风险驾驭和监控的策略如下： 。与在职人员协商，确定流动原因。 。在项目开始前，把环节这些流动原因的工作列入风险驾驭计划。 。项目开始时，作好人是会流动的准备，采取一些措施确保人员一旦离开时，项目仍能继续。 。制定文档标准，并建立一种机制，保证文档及时产生。 。对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作。 。对每个关键性技术人员培养后备人员。 在考虑风险成本之后，决定是否采用上述策略。 4.7人员管理 1、对项目经理的要求 。能够使小组每个成员都能发挥能力 。有一定的组织能力 。能够使小组美味成员有成就感 。有提出解决问题方案的能力 。对问题的理解有一定的深度 。要能

43、让成员知道软件质量的重要性 2、人员的通讯方式 （1）正式非个人方式，如正式会议等； （2）正式个人之间交流，如成员之间的正式讨论等（一般不形成决议）； （3）非正式个人之间交流，如个人之间的自由交流等； （4）电子通讯，如E-MAIL（电子邮件）、BBS（电子公告板系统）等； （5）成员网络，如成员与小组之外或公司之外有经验的相关人员进行交流； 在实践中发现，（5）的通讯效率最高，其次是（1）。 4.8人力资源管理中的风险管理 在进行人力资源管理时，我们往往重视招聘、培训、考评、薪资等各个具体内容的操作，而忽视了其中的风险管理问题。其实，每个企业在人事管理中都可能遇到风险，如招聘失败、新政策

44、引起员工不满、技术骨干突然离职等等，这些事件会影响公司的正常运转，甚至会对公司造成致命的打击。如何防范这些风险的发生，是我们应该研究的问题。特别是高新技术企业，由于对人的依赖更大，所以更需要重视人力资源管理中的风险管理。5 结束语项目管理虽然没有非常高深的理论，但要真正实施起来，也绝非易事。对于软件开发企业而言，这不是一个小的改变，而是一种变革，企业需要为此付出艰苦的努力，宣传并树立公司范围内的项目管理文化十分重要。从而在实践中锻炼提高，解决各种各样的问题，使项目管理工作越做越好。参考文献1郑人杰，殷人昆，陶永雷.实用软件工程:清华大学出版社.1996.102Roger S。Pressman.软件工程实践者的研究方法.机械工业出版社.2002.93徐晓春,李高健. 软件配置管理:清华大学出版杜4周睿:项目风险缓解、监控和管理.5史济民.软件工程原理，方法与应用:高等教育出版社.1989.16苏统华:项目管理精髓