软件项目管理论文.docx
《软件项目管理论文.docx》由会员分享，可在线阅读，更多相关《软件项目管理论文.docx（23页珍藏版）》请在冰豆网上搜索。
软件项目管理论文
Documentnumber【980KGB-6898YT-769T8CB-246UT-18GG08】
软件项目管理论文
软件工程专业《软件项目管理》
课程设计报告
题目：
软件项目管理
姓名：
郑闽君
准考证号：
9
学院：
数学与计算机科学学院
专业：
软件工程
年级：
09级
2010年3月
1绪论
研究背景
随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。
各软件企业都在积极将软件项目管理引入开发活动中，对开发实行有效的管理。
我公司是西安一家中型软件企业，在公司中已经实行了项目管理制度，软件项目管理是整个项目管理中的一个重要组成部分。
从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。
实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展（即减小开发风险）。
软件开发不同于其他产品的制造，软件的整个过程都是设计过程（没有制造过程）；另外，软件开发不需要使用大量的物质资源，而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。
基于上述特点，软件项目管理与其他项目管理相比，有很大的独特性
目前相关研究现状及分析
一个值得深思的事实是，到目前为止，已经信息化的企业在IT（InformationTechnology，信息技术）的投资超过了未信息化企业在IT的投资。
这意味着什么
这意味着IT项目的投资已经由厂商驱动向用户驱动转变，以往什么利润高IT厂商就说什么好，用户低着头掏腰包的时代过去了。
现在大多数的用户都经历过信息化，或成功过，或失败过，经验教训都有了许多。
用户更加重视企业信息战略的规划、IT投资的实实在在的效益。
一方面，能够为用户提供IT能力的厂商如雨后春笋般成长，这些企业为了生存，竞争手段花样百出，竞争也日趋白热化。
那么，作为IT企业，要想在竞争的市场上持续发展，就必须提高自己核心竞争力。
IT企业的竞争力体现在两方面：
一是IT解决方案的技术水平；一是IT项目的实施能力。
相对于前者，后者在短期提高利润方面更能显示出威力。
因为项目管理水平的提高，意味着项目能得到更好地控制。
成本能得到更多的节约，人力资源能得到更加合理的安排，客户的需求能得到更好地满足。
现行项目管理存在的主要问题分析
再看看国内市场，我国虽然在网络门户、电子商务的模仿、借鉴和推动方面丝毫不亚于西方发达国家，但是在软件项目管理和专业人才的培养方面却大大滞后。
所以如何将一个个自由英雄更好、更有效地团结起来，组建出高效的开发小组，已成为越来越多管理者思考的重点。
在小组中，每个人的工作都是与其他相关联的，因此，小组成员除了保证自己担负的任务的质量的同时，还需要关注其他关联角色的任务，假使界面工程师迟迟无法定义产品流程，美工人员也许只能望纸生叹，而美工人员不能将产品界面文件及早完成而任由程序员随意定义界面的话，后期重新美化的工作量可能大到重写一遍代码的地步。
因此，需要时时掌握小组每个成员的工作进度，并进行监督和协调。
有经验的管理人员都知道，项目的计划和进度在实施中必不可少地会进行调整，这种调整可能来自于：
客户的需求进行了补充或修改；工作量估算不准，造成进度不平衡；某个技术环节出现障碍，需要另外需求人员或帮助；有人不遵从开发规范，导致产品缺陷等方面。
在面对意料中的意外时，项目管理人员需要有应急解决的办法，从而保障开发持续稳定地向目标前进。
项目经理对人员的管理、进度的掌握、质量的控制、成本的核算等等所做的工作已经远远山东三联电子信息有限公司济南250012超过代码本身，作为项目负责人，应随时能掌握先进的技术和方法并在适当的时机采用，管理整个项目小组往既定的目标前进。
因此需要建立完善的软件项目管理体系，使其覆盖公司范围内所有软件项目类型，实现公司级和项目级不同层面对软件项目进行有效的管理和监督，确保项目在既定的时间和成本范围内，达到计划目标，满足客户的需求。
2软件项目管理的组织模式
软件项目可以是一个单独的开发项目，也可以与产品项目组成一个完整的软件产品项目。
如果是订单开发，则成立软件项目组即可；如果是产品开发，需成立软件项目组和产品项目（负责市场调研和销售），组成软件产品项目组。
公司实行项目管理时，首先要成立项目管理委员会，项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。
1、项目管理委员会
项目管理委员会是公司项目管理的最高决策机构，一般由公司总经理、副总经理组成。
主要职责如下：
（1）依照项目管理相关制度，管理项目；
（2）监督项目管理相关制度的执行；
（3）对项目立项、项目撤消进行决策；
（4）任命项目管理小组组长、项目评审委员会主任、项目组组长.
2、项目管理小组
项目管理小组对项目管理委员会负责，一般由公司管理人员组成。
主要职责如下：
（1）草拟项目管理的各项制度；
（2）组织项目阶段评审；
（3）保存项目过程中的相关文件和数据；
（4）为优化项目管理提出建议。
3、项目评审小组
项目评审小组对项目管理委员会负责，可下设开发评审小组和产品评审小组，一般由公司技术专家和市场专家组成。
主要职责如下：
（1）对项目可行性报告进行评审；
（2）对市场计划和阶段报告进行评审；
（3）对开发计划和阶段报告进行评审；
（4）项目结束时，对项目总结报告进行评审。
4、软件产品项目组
软件产品项目组对项目管理委员会负责，可下设软件项目组和产品项目组。
软件项目组和产品项目组分别设开发经理和产品经理。
成员一般由公司技术人员和市场人员构成。
主要职责是：
根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。
3软件项目管理过程
为保证软件项目获得成功，必须清楚其工作范围、要完成的工作任务、需要的资源、需要的工作量、进度安排、可能遇到的风险等。
软件项目的管理工作在技术工作开始之前就应开始。
而在软件从概念到实现的过程中继续进行，且只有当软件开发工作最后结束时才终止。
管理的过程一般分为以下几个阶段：
项目启动阶段
启动软件项目是指必须明确项目的目标和范围、考虑可能的解决方案以及技术和管理上的要求等这些信息是软件项目运行和管理的基础。
a．注重和客户的沟通，了解客户的期望以及对项目的认知情况，了解客户的业务，进一步了解相关技术，编写初步需求分析报告和项目建设方案。
b．交付物：
项目建议书、需求规格说明书、概要设计说明书、详细设计说明书、测试计划配置管理、开发立项申请报告等。
在这一阶段，正确理解或记录需求，并充分地控制需求变更，十分重要，可以避免成本增加、延期交付以及开发质量不高，从而提高客户满意度。
正确的需求分析和确定需求规格对一个项目的成功是非常关键的。
项目计划阶段
a．制订项目实施计划：
将工作进行足够细的分解（WBS）、制定详细的时间进度表、选定各阶段的里程碑事件。
包括项目进度安排、质量计划、项目测量计划、项目培训计划、配置管理计划、定义项目跟踪规程、定义项目计划的假设前提，对项目计划和工作安排进行组评审（现在没进行这一活动），获得高级管理者的授权即公司领导签批。
b．参加者有项目负责人、客户、SEPG公司评审小组（质量顾问。
如果过程改进想获得成功，需要很多因素的支持，形成一个担负起协调内部过程活动的核心小组是一个成功的因素，同时也是CMM3机构过程焦点KPA的一个重要实践。
这个核心小组通常称为软件工程过程组，SoftwareEngineeringProcessGroup，SEPG，由质量专家组成，工作就是监督和改进用于改进机构的过程。
这些人占公司软件工程师的比例大约为1．5％）和项目的业务主管。
c．入口准则：
合同已签和项目已授权。
主要的输出是合同或建议书。
d．出口准则：
制定出项目计划并经过组评审。
主要输出是计划文档和评审记录。
这个阶段主要的测量项是花费的工作量和在评审时发现的缺陷。
项目实施（执行）阶段
包括执行项目计划和当项目进展偏离项目计划时采取的纠正活动。
或者说是项目跟踪和控制项目过程的实现。
a．主要活动有：
跟踪项目状态；与高级管理者评审项目状态；管理需求变更；监督项目与定义好的项目过程的一致性，其中要从两方面注意：
一是对项目计划和工作安排进行组评审，与项目经理定好并要求传达到项目组成员；
二是项目计划如有变化要及时提出申请，报分管领导审批；进行里程碑评审。
b．参加者有项目负责人、客户、SEPG、项目组成员和项目的业务主管。
c．入口准则：
项目计划完成并被批准。
主要输出是项目计划和项目文档，如合同软件需求等。
d．出口准则：
客户接受的所有已提交的工作产品。
输出是计划文档、评审记录、状态报告和类似的文档。
这个阶段主要测量花费的工作量。
软件项目管理的基础是软件项目计划，通过项目周报、里程碑报告等方式来跟踪项目的实际执行状况，并参照项目计划比对偏差，从而采取相应的措施来保证软件项目的顺利进行。
软件项目在执行的过程中，从以下三个层面对项目的状况进行跟踪和监督。
项目经理在项目初期制定项目计划，并在项目执行的过程中通过管理项目组的日常活动跟踪项目的进展状况，根据实际完成的工作更新项目计划。
如果项目计划出现重大变更，则要申请变更项目计划，根据变更后的项目计划来执行工作。
根据项目计划、项目周报和里程碑报告等方式跟踪项目的阶段偏差（进度、成本）、质量状况、需求变更等内容，判断项目中存在的风险并采取相应的措施，处理项目组解决不了的问题。
当项目出现重大偏差时，决定是否变更项目计划及采取有效措施。
计划经营部收集所有项目的项目周报和项目里程碑报告，并通过数据汇总与分析，计算项目TQC（进度、质量和成本）偏差情况，然后根据偏差情况采取相应的措施。
为项目组指定质量经理，对项目进行阶段检查，判断项目的执行情况，提供项目对公司的项目管理体系的遵循情况。
项目收尾（关闭）阶段
从我们做项目的经验来看，在项目进行过程中由于项目组成员的全体合作，加上公司领导对这个项目非常重视，所以在整个项目过程中工作开展的还是比较顺利的，在项目进行到编码时，进度还基本控制在计划的范围内，但在项目将近收尾阶段却出现较多的问题。
项目收尾阶段的主要活动：
项目结束的数据分析，包括执行的度量数据分析，为将来使用而收集的过程评估，记录学到的经验教训等等。
参加者是项目负责人、项目组成员、项目的质量顾问和业务主管。
主要输出是在项目中采集的度量数据、客户抱怨记录和项目计划。
入口准则是客户已接受的工作产品，出口准则是召开项目结束会议。
输出是项目结束报告和从项目中收集的过程评估。
项目收尾其实并不只是收尾阶段要做的事情，它的根源会牵扯到项目的各个阶段。
谈起项目收尾，根据PMI（美国项目管理协会）的概念，项目收尾包括合同收尾和管理收尾两部分。
合同收尾：
合同收尾就是抓起合同，和客户一项项的核对，是否完成了合同所有的要求，是否可以把项目结束，也就是我们通常所讲的验收。
主要的问题在足够的里程碑事件的确认书。
在将要提供交付物之前临时准备相关的文档，需要补充许多应该在项目执行阶段签署的确认文档。
谁也不愿意在项目“接近”结束的时候陷入困境，客户不断的提出新要求；以为已经干完了“该干的事情”，结果拿起合同一看，客户要一项一项地对合同的话，根本就不可能验收。
迟迟不能验收的原因是缺少《测试报告》和《项目实施方案》，没有及时的对已完成的系统的自测结果要求用户签署阶段性确认书。
为避免这种情况的出现，应从以下方面注意：
a．项目开始的时候是不是看着最后的合同验收来做事呢从一开始就尽可能地按合同要求来做，一定不要留给对方抓小辫子的机会。
当然业务人员在签合同时，为了拿下这个项目，把项目吹得能把客户想要的一切都办得到，在客户面前信誓旦旦才能把项目签下来。
这也应该能够理解，项目做得不好，最难交待的还是他们。
但是项目启动之后，项目经理是否就应该好好的研究合同，与业务人员沟通，了解客户最想要的是什么，然后重新列出项目的范围，尽可能让客户认同，锁定项目范围。
这样就算不能完全避免需求不断增加不断改变的风险，也能有所改善的。
b．还需要的就是与客户做好沟通，这个时候谈判的技巧是很重要的，既要不卑不亢，又要理据充分，不能胡编乱造哄骗客户，客户不是傻子，他们如果怀疑你的能力和诚信以后就更难沟通了。
在难度不大改变不多的时候，我们更应该的是作出适当的退让，爽快的答应客户的要求，然后让他们知道我们作出了多大的牺牲去帮助他们实现愿望。
管理收尾：
为了使项目干系人对项目产品的验收正式化而进行的项目成果验收和归档，收集项目记录保存项目信息（包括项目总结）管理收尾是对于内部来说的，把做好的项目文档等归档；对外宣称项目已经结束；转入维护期，把相关的产品说明转到维护组；进行经验教训总结，项目成员一起来“怀旧”学习一把。
把项目文档整理一下归档，对于项目的延续性是有很重要的意义的。
项目经理把项目经验归纳归档起来，又会对别的项目经理、对公司的项目管理文化作出了不少的贡献。
很多着名的公司都对项目经验总结这一环节看得很重，毕竟现在业界提倡的PMM（ProjectMaturityMode1）的最高境界就是不断地学习改进。
当项目规模或时间达到一定程度时，粗放式、不规范的管理方法是行不通的，在具体实施过程中必将在无休无止的项目变更和反复的与干系人的交流中消耗掉极大量的时间和成本。
所以越是大的项目越是要进行规范的项目管理，规范化的初期可能是痛苦的，可结果却是值得的。
从目前看，公司的运营成本是增加了，因为要增加管理人员、撰写文档也需要人手，但从长远看，其会带来降低成本、提高质量、提高用户满意度等好处。
对此，我们应确信不疑。
4软件项目管理的内容
根据公司实际情况，公司在进行软件项目管理时，重点将软件配置管理、软件质量管理、软件风险管理及开发人员管理四方面内容导入软件开发的整个阶段。
在八十年代初，着名软件工程专家总结出了软件开发时需遵循的七条基本原则，同样，我们在进行软件项目管理时，也应该遵循这七条原则。
它们是：
（1）用分阶段的生命周期计划严格管理；
（2）坚持进行阶段评审；
（3）实行严格的产品控制；
（4）采用现代程序设计技术；
（5）结果应能够清楚地审查；
（6）开发小组地人员应该少而精；
（7）承认不断改进软件工程实践地必要性。
软件项目需求管理
软件需求是软件工程过程中的重要一环，是软件设计基础。
也是用户和软件工程之间的桥梁。
简单的说，软件需求就是确定系统需要做什么，严格意义上，软件需求是系统或软件必须达到的目标与能力。
目标
需求管理是一种获取、组织并记录软件需求的系统化方案，同时也是一个使客户与项目开发组对不断变更的软件需求达成并保持一致的过程。
在需求管理中，软件工程组的工作是采取适当的措施来保证分配的需求，即要将分配的需求文档化，控制需求的变化，负责项目实施过程中需求的实现情况。
需求管理的目的是在客户和处理客户需求的软件项目之间建立对客户需求的共同理解，需求管理的目标有两个：
使软件需求受控，并建立供软件工程和管理使用的需求基线。
使软件计划、产品和活动与软件需求保持一致。
在需求管理过程，为实现第一个目标，必须控制需求基线的变动，按照变更控制的标准和规范的过程进行需求变更控制和版本控制；为实现第二个目标，必须就变更和软件项目各小组达成共识，对软件项目计划做出调整，其中包括人员的安排、用户的沟通、成本的调整、进度的调整等。
原则
为进行有效的需求管理，一般要遵循如下五条原则
需求一定要分类管理
进行软件项目管理的时候，一定要将软件需求分出层次。
不同层次需求的侧重点、描述方式、管理方式是不同的。
需求必须分优先级
在软件项目中，如果出现过多的需求，通常会导致项目超出预算和预定进度，最终导致软件项目的失败，因而需求的优先级可能比需求本身更加重要。
需求必须文档化
需求必须有文档记录。
该文档必须是正确的、最新的、可管理的、可理解的，是经过验证的，是在受控的状态下变更的。
需求管理活动
需求管理在需求开发基础上进行，贯穿于整个软件项目过程，是软件项目管理的一部分。
在软件项目进行的过程中，无论正处于哪个阶段，一旦有需求错误出现或任何有关需求的变更出现，都需要需求管理活动来解决，需求管理是一个对系统需求变更了解和控制的过程。
初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求活动就开始了。
需求管理活动
活动的任务
变更控制
建议需求变更并分析其影响，做出是否变更的决策
版本控制
确定单个需求和SRS（即功能规格说明）的版本
需求跟踪
定义对于其他需求及系统元素的联系链
需求状态
定义并跟踪需求的状态
表1需求管理活动
需求管理质量保证
需求验证过程
需求验证很重要，如果在构造设计开始之前，通过验证基于的测试计划和原型测试来验证需求的正确性及其质量，就能大大减少项目后期的返工现象。
需求验证可按以下步骤来进行：
审查需求文档依照需求编写测试用例编写用户手册确定合格的标准
验证的内容
在需求验证过程中，需对需求文档中定义的需求执行多种类型的检查。
有效性检查----对于每项需求都必须证明它是有效的，确实能解决用户面对的问题。
一致性检查----在需求文档中，需求不应该冲突，即对同一个系统功能不应出现不同的描述或相互矛盾的约束。
完备性检查----需求文档应该包括所有系统用户想要功能和约束。
现实性检查----检查需求以保证能利用现有技术实现
可检验性检查----描述的需求能够实际测试
可跟踪性检查----需求的出处被清晰的记录，每一个系统功能都能被跟踪到要求它的需求集合，每一项都能追溯到特定的用户要求。
可调节性检查----需求变更能够不对其他系统大规模的影响/
可读性检查----需求说明能否被系统购买者和最终用户读懂。
需求评审
需求分析完成后，应由用户和系统分析员共同进行需求评审。
鉴于需求规格说明是软件设计的基础，需求评审需要有客户方和承包商方的人员共同参与，检查文档中的不规范之处和遗漏之处。
．软件项目估算与进度管理
软件项目估算
软件项目包括工程估算和成本估算两个方面。
软件估算作为软件项目管理的一项重要内容。
是确保软件项目成功的关键因素。
估算是指通过预测构造软件项目需要的工作量的过程。
初步的估算用于确定软件项目的可行性，详细估算用于指导项目计划的制定。
软件规模
工作分解结构
对软件项目进行估算遇到的第一个问题就是软件规模、即软件的程序量。
软件规模是软件工作量的主要影响因素。
软件项目的设计有一个分层结构，这一分层结构就对应着工作分解结构（WBSWorkBreakdownStructure），它将软件过程和软件产品结构联系起来。
有了工作分解结构之后，还必须定义度量标准用以对软件规模进行估计。
常用的软件规模度量标准有两种：
代码行LOC（LineOfCode）和功能点FP（FunctionPoints）。
代码行
代码行LOC是常用的源代码程序长度的度量标准，指源代码的总行数。
源代码中除了可执行语句外，还有帮助理解的注释语句。
功能点
功能点度量是在需求分析阶段基于系统功能的一种规模估计方法，该方法通过已经初始应用需求来确定各种输入、输出、查询、外部文件和内部文件的数目，从而确定功能点数量。
软件项目成本估算
成本估算是对完成软件项目所需费用的估计和计划，是软件项目计划中的一个重要的组成部分。
成本估算步骤如下：
建立目标----规划需要的数据和资源----确定软件需求----拟订可行细节----运用多种独立的技术和原始资料----比较各个估算值----随访跟踪
软件项目进度管理
制定项目计划
项目计划在项目开始时候制定，并随着项目的进展不断发展。
软件项目计划的要素包括目标、合理的概念设计、工作分解结构、规模设计、工作量估计和项目进度计划安排。
项目计划为管理者提供了根据计划定期评审和跟踪项目进展的基础。
进度安排
在确定了项目的资源（总成本及时间等）后，把其分配到各个项目开发阶段中，即确定项目的进度项目各阶段的工作量。
软件项目配置管理
是否进行配置管理与软件的规模有关，软件的规模越大，配置管理就显得越重要。
软件配置管理简称SCM（SoftwareConfigurationManagement的缩写），是在团队开发中，标识、控制和管理软件变更的一种管理。
配置管理的使用取决于项目规模和复杂性以及风险水平。
目前软件开发中面临的问题
。
在有限的时间、资金内，要满足不断增长的软件产品质量要求；
。
开发的环境日益复杂，代码共享日益困难，需跨越的平台增多；
。
程序的规模越来越大；
。
软件的重用性需要提高；
。
软件的维护越来越困难。
软件配置管理应提供的功能
在中，对配置管理系统的功能作了如下描述：
。
唯一地标识每个软件项的版本；
。
标识共同构成一完整产品的特定版本的每一软件项的版本；
。
控制由两个或多个独立工作的人员同时对一给定软件项的更新；
。
控制由两个或多个独立工作的人员同时对一给定软件项的更新；
。
按要求在一个或多个位置对复杂产品的更新进行协调；
。
标识并跟踪所有的措施和更改；这些措施和更改是在从开始直到放行期间，由于更改请求或问题引起的。
版本管理
软件配置管理分为版本管理、问题跟踪和建立管理三个部分，其中版本管理是基础。
版本管理应完成以下主要任务：
。
建立项目；
。
重构任何修订版的某一项或某一文件；
。
利用加锁技术防止覆盖；
。
当增加一个修订版时要求输入变更描述；
。
提供比较任意两个修订版的使用工具；
。
采用增量存储方式；
。
提供对修订版历史和锁定状态的报告功能；
。
提供归并功能；
。
允许在任何时候重构任何版本；
。
权限的设置；
。
晋升模型的建立；
。
提供各种报告。
软件质量管理
随着软件开发的规模越来越大，软件的质量问题显得越来越突出。
软件质量的控制不单单是一个软件测试问题，在软件开发的所有阶段都应该引入质量管理。
我公司除加强了国家标准"信息技术软件生存期过程"（GB/T8566--1995）的规范管理外，还积极为通过ISO做准备。
软件质量保证计划
在进行软件开发前，需要有一个《软件质量保证计划》。
目前较常用的是ANSI/IEEESTOL730--1984，983--1986标准，包括以下内容：
质量管理的基本原则
。
控制所有过程的质量；
。
过程控制的出发点是预防不合格；
。
质量管理的中心任务是建立并实施文件化的质量体系；
。
持续的质量改进；
。
有效的质量体系应满足顾客和组织内部双方的需要和利益；
。
定期评价质量体系；
。
搞好质量管理关键在于领导。
软件质量因素
正确性：
系统满足规格说明和用户目标的程度，即，在预定环境下能正确地完成预期功能的程度。
健
升级会员 