如何做好软件研发项目管理.docx
- 文档编号:29569849
- 上传时间:2023-07-24
- 格式:DOCX
- 页数:10
- 大小:72.14KB
如何做好软件研发项目管理.docx
《如何做好软件研发项目管理.docx》由会员分享,可在线阅读,更多相关《如何做好软件研发项目管理.docx(10页珍藏版)》请在冰豆网上搜索。
如何做好软件研发项目管理
如何做好软件研发项目管理
1什么是软件项目管理
软件项目管理是在一定的约束条件下,以高效率地实现项目业主的目标为目的,以项目经理负责制为基础和以项目为独立实体进行经济核算,并按照项目内在的逻辑规律进行有效的计划、组织、协调、控制的系统管理活动。
2软件项目管理的特点
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,合理地配置和使用各种资源,而对人员、进度、质量、风险等进行分析和管理,以达到既定目标的过程。
软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期都能在管理者的控制之下,以预定成本按期,按质的完成软件交付用户使用。
软件项目管理更强调项目经理的作用和团队的合作精神,更加关注人的因素,关注客户服务,着重于提高软件项目研发的效率和质量。
3做好软件项目前期管理
3.1项目计划管理
在软件项目管理过程中一个关键的活动是制定项目计划,它是软件开发工作的第一步。
项目计划的目标是为项目负责人提供一个框架,使之能合理地估算软件项目开发所需的资源、经费和开发进度,并控制软件项目开发过程按此计划进行。
主要进行的工作包括:
确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。
3.2项目需求管理
需求管理是每个软件开发的基础,是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法,可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。
软件需求主要包括业务需求、用户需求、功能需求和非功能需求、软件需求规格说明。
需求分析包括提炼、分析和仔细审查已收集到的需求,为最终用户所看到的系统建立一个概念模型以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其他不足的地方。
在项目需求分析阶段,双方必须全面地尽可能细致地讨论项目的应用范围、业务流程、性能要求、操作界面要求、与其他软件的接口要求,以及对项目进行评估的各种评价标准。
3.3项目团队管理
建立项目团队是项目开发过程的开始,一切工作都是由项目团队的成员完成的在整个项目的运行过程中,需要很多不同的角色参与到项目中,完成不同阶段的任务。
所以在建立项目团队的过程中要把握好人员角色的划分,尽量发挥项目成员特长是项目经理进行工作分配要考虑的问题。
各项目成员的知识技能评估,个性特点分析,优点和缺点是要事先分析和考虑的内容。
团队的管理是项目管理的关键,也是项目成功的基本保障。
3.4生命周期模型
生命周期模型指软件开发全部过程、活动和任务的结构框架。
软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。
目前软件开发实践中使用的各种生命周期模型,主要如下:
1)瀑布模型。
需要对每一个阶段进行验证,瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠,而应该是在评审通过,相关的产出物都已经基线后才能够进入到下一个阶段。
采用瀑布模型可以保证系统在整体上的充分把握,使系统具备良好的扩展性和可维护性。
但对于前期需求不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型。
2)螺旋模型。
首先螺旋模型是遵从瀑布模型的。
即需求->架构->设计->开发->测试的路线。
螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的。
通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项目的风险。
螺旋模型实现了随着项目成本投入不断增加,风险逐渐减小。
以帮我我们加强项目的管理和跟踪,在每次迭代结束后都需要对产出物进行评估和验证,当发现无法继续进行下去时可以及早的终止项目。
3)增量和迭代模型。
增量迭代是RUP统一过程常采用的软件开发生命周期模型。
就对风险的消除上,增量和迭代模型都能够很好的控制前期的风险并解决。
但迭代模型在这方面更有优势。
迭代模型更多的可以从总体方面去系统的思考问题,从最早就可以给出相对完善的框架或原型,后期的每次迭代都是针对上次迭代的逐步精化。
3.5项目风险管理
风险管理贯穿项目管理的各个阶段和各个领域,是项目管理中的重点和难点。
软件项目风险管理是指对在软件开发过程中所遇到的预算和进度等方面的问题进行分析,寻求风险应对方法,做好风险管理计划。
通过缓和或预知等手段来减轻风险,降低风险发生的可能性或减缓风险带来的不利后果。
针对软件项目中的风险管理问题,主要风险管理模型如下:
1)SEI的连续风险管理模型(CRM)。
SEICRM模型的风险管理原则是不断地评估可能造成恶劣后果的因素;决定最迫切需要处理的风险;实现控制风险的策略;评测并确保风险策略实施的有效性。
CRM模型要求在项目生命期的所有阶段都关注风险识别和管理,它将风险管理划分为五个步骤:
风险识别、分析、计划、跟踪、控制。
2)BarryBoehm模型。
Boehm模型的思想核心是:
10大风险因素列表。
针对每个风险因素,都给出了一系列的风险管理策略。
在实际操作时,Boehm以10大风险列表为依据,总结当前项目具体的风险因素,评估后进行计划和实施,在下一次定期召开的会议上再对这10大风险因素的解决情况进行总结,产生新的10大风险因素表,依此类推。
3)软件工程风险模型(SERIM)。
SERIM模型要求从技术和商业两个角度对软件风险管理进行剖析,考虑的问题涉及开销、进度、技术性能等。
它还提供了一些指标和模型来估量和预测风险,由于这些数据来源于大量的实际经验,因此具有很强的说服力。
4项目过程管理
4.1软件设计
软件设计采用自顶向下、逐次功能展开的设计方法,首先完成总体设计,然后完成各有机组成部分的设计。
根据工作性质和内容的不同,软件设计分为概要设计和详细设计。
概要设计实现软件的总体设计、模块划分、用户界面设计、数据库设计等等;详细设计则根据概要设计所做的模块划分,实现各模块的算法设计,实现用户界面设计、数据结构设计的细化,等等。
概要设计是详细设计的基础,必须在详细设计之前完成,概要设计经复查确认后才可以开始详细设计。
概要设计,必须完成概要设计文档,包括系统的总体设计文档、以及各个模块的概要设计文档。
每个模块的设计文档都应该独立成册。
详细设计必须遵循概要设计来进行。
详细设计方案的更改,不得影响到概要设计方案;如果需要更改概要设计,必须经过项目经理的同意。
详细设计,应该完成详细设计文档,主要是模块的详细设计方案说明。
4.2设计评审
在设计完成后,必须安排设计评审以保证设计的质量,设计评审是对一项设计进行正式的、按文件规定的、系统的评估活动,由不直接涉及开发工作的人执行。
设计评审可采用向设计组提建议或帮助的形式,或就设计是否满足客户所有要求进行评估。
评审的内容主要包括:
1)关键算法的可行性;
2)接口是否符合概要设计的要求;
3)技术清晰度是否符合设计标准;
4)文档的完备性。
4.3编码
在编码阶段,主要需要在编码工作结束后,进行代码审核,这项工作非常重要主要应该由项目小组的技术负责人完成,审核的目的并不是为了检验代码的正确性而是需要对编码是否按照规范进行审核。
主要内容包括:
1)变量、包、方法等的命名是否符合规则;
2)注释是否填写完整,是否符合规范;
3)代码的可读性,编写风格是否符合规范;
4)是否有明显的造成系统运行低效率的处理方法;
5)公共变量的定义和使用。
4.4调试
编码工作完成以后,通常需要开发人员自己进行单元测试,有些部分需要编写相应的测试程序。
应该避免发生这类的情况,有些开发人员任务自己不应该进行测试工作,在编写完代码以后,只要编译成功,就直接提交成果,将测试工作完全交给测试人员去做,这样做不仅仅给测试人员增加了许多的工作量,同时增加了许多因为交流产生的时间,造成进度的延迟,管理人员应该杜绝程序员的这样的思想,同时在管理中予以考虑,可以将提交成果产生的Bug数量作为考核程序员业绩的标准之一。
4.5客户沟通
项目中一定要有沟通策略,沟通的作用对于高管是让他们清楚我们一直按照项目目标前进,每个阶段工作进展是否顺利,影响项目正常运做原因是什么,需要哪些资源帮助。
和高管沟通比较多的话,第一个好处是高管经常听汇报就知道项目进展程度,可以安排反馈检查,看是否具备我们所说的进展,这样一旦认可了各个阶段目标后,最终要求高管签字确认也就顺理成章了。
中层往往是项目主要的推动力量和实际执行者,也往往是对具体业务需求最主要的要求者,他们对企业实际运做过程最清楚,提出要求最具体,而且项目验收与否没有中层的同意往往也是不太容易做到的。
和基层的沟通主要体现对最终用户的关怀,定期主动和最终用户沟通,消除一些怨气,让用户能坚持用下去,这个时候我们往往发现很多用户真的是非常好相处,尽管软件还有很多值得改进的地方,但他们一旦认可我们团队,反而会尽心尽力帮助我们推动项目的进行。
5项目后期管理
5.1项目验收
项目验收,是整个项目生命周期中最后一个环节。
当系统经过一段试运行,具备验收的各项条件之后,我们就需要着手验收阶段的准备工作了。
首先我们需要把到目前为止完成的工作进行一个总结,列出我们已经完成的各项目工作成果、各类文档,对合同以及各类约定的技术文档中的相关内容进行自查,要彻底了解系统目前完成的情况如何,没有完成的,准备采取什么策略去进一步完成或者采取一定的回避措施,使客户在验收的时候不再提出这些未实现的需求。
同时做一个详细的验收计划是非常必要的,可以用来作为验收阶段的工作指导。
这就需要与客户进行详细的沟通,再次明确验收前需要完成的工作,尽量避免客户方在此阶段提出过多的更改需求,这是极为重要的。
验收计划中不光要有需要继续完成的工作,还需要有一个相对固定的工期,使双方都继续朝着这个方向去努力,防止无限制的拖延。
5.2软件维护
软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改,修改时应充分利用源程序。
修改后要填写程序改登记表,并在程序变更通知书上写明新旧程序的不同之处。
目前软件维护分类主要如下:
1)正确性维护。
是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
所发现的错误有的不太重要,不影响系统的正常运行,其维护工作可随时进行。
2)适应性维护。
是指使用软件适应信息技术变化和管理需求变化而进行的修改。
企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求,将导致适应性维护工作的产生。
3)完善性维护。
这是为扩充功能和改善性能而进行的修改,主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
另外,还包括对处理效率和编写程序的改进。
4)预防性维护。
为了改进应用软件的可靠性和可维护性,为了适应未来的软硬件环境的变化,应主动增加预防性的新的功能,以使应用系统适应各类变化而不被淘汰。
要做好软件维护工作,必须对设计文档定期更新,进入维护期后,代码和先期的设计文档容易出现偏差。
如果不定期的对原有设计文档进行更新,日积月累将大大降低原有文档的价值,增加新员工入手的难度。
做好人员交叉备份,各个模块的维护人员之间交叉备份,一方面降低人力资源;另一方面避免一个人维护一块,规避人员流动引发的风险。
6软件项目管理技术
以上谈了软件项目管理的一般过程,我们可以通过规范的体系建设来有效的进行项目管理,以下介绍两种项目管理体系。
6.1CMM
CMM(CapabilityMaturityModelForSoftware,软件能力成熟度模型)是美国卡纳基梅隆大学软件工程研究所(CMU/SEI)提出的软件研发项目管理的一系列方法,它基于组织对关键过程域的支持,定义了软件过程成熟度的五个级别。
级别1(初始级)描述了不成熟,或者说是未定义过程的组织。
级别2(可重复级),级别3(已定义级),级别4(已管理级)和级别5(优化级)分别描述了软件过程成熟度级别递增的组织。
和这些级别相关的KPA是:
级别2:
需求管理,软件项目计划,软件项目跟踪和监控,软件子合同管理,软件质量保证,软件配置管理。
级别3:
组织级过程焦点,组织级过程定义,培训大纲,集成软件管理,软件产品工程,组间协调,同行评审。
级别4:
定量过程管理,软件质量管理。
级别5:
缺陷预防,技术更新管理,过程更改管理。
6.2PSP
PSP(PersonalSoftwareProcess,个体软件过程)是由CMU/SEI开发出来的,它的推出在软件工程界引起了极大的轰动,可以说是由定向软件工程走向定量软件工程的一个标志。
PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径,例如如何制订计划,如何控制质量,如何与其他人相互协作等等。
在软件设计阶段,PSP的着眼点在于软件缺陷的预防,其具体办法是强化设计约束准则,而不是设计方法的选择。
7小结
本文分析研究了项目管理中的前期、中期和后期的各种管理要求。
同时对项目管理技术进行了研究,在实际项目中,我们要坚持改善软件项目管理,充分利用软件项目管理技术,并在实践中总结适合自身的经验,这样才有利于管理技术的进步和软件项目的顺利完成,创造出更高的品质、更大的效益。
1什么是软件项目管理
软件项目管理是在一定的约束条件下,以高效率地实现项目业主的目标为目的,以项目经理负责制为基础和以项目为独立实体进行经济核算,并按照项目内在的逻辑规律进行有效的计划、组织、协调、控制的系统管理活动。
2软件项目管理的特点
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,合理地配置和使用各种资源,而对人员、进度、质量、风险等进行分析和管理,以达到既定目标的过程。
软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期都能在管理者的控制之下,以预定成本按期,按质的完成软件交付用户使用。
软件项目管理更强调项目经理的作用和团队的合作精神,更加关注人的因素,关注客户服务,着重于提高软件项目研发的效率和质量。
3做好软件项目前期管理
3.1项目计划管理
在软件项目管理过程中一个关键的活动是制定项目计划,它是软件开发工作的第一步。
项目计划的目标是为项目负责人提供一个框架,使之能合理地估算软件项目开发所需的资源、经费和开发进度,并控制软件项目开发过程按此计划进行。
主要进行的工作包括:
确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。
3.2项目需求管理
需求管理是每个软件开发的基础,是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法,可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。
软件需求主要包括业务需求、用户需求、功能需求和非功能需求、软件需求规格说明。
需求分析包括提炼、分析和仔细审查已收集到的需求,为最终用户所看到的系统建立一个概念模型以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其他不足的地方。
在项目需求分析阶段,双方必须全面地尽可能细致地讨论项目的应用范围、业务流程、性能要求、操作界面要求、与其他软件的接口要求,以及对项目进行评估的各种评价标准。
3.3项目团队管理
建立项目团队是项目开发过程的开始,一切工作都是由项目团队的成员完成的在整个项目的运行过程中,需要很多不同的角色参与到项目中,完成不同阶段的任务。
所以在建立项目团队的过程中要把握好人员角色的划分,尽量发挥项目成员特长是项目经理进行工作分配要考虑的问题。
各项目成员的知识技能评估,个性特点分析,优点和缺点是要事先分析和考虑的内容。
团队的管理是项目管理的关键,也是项目成功的基本保障。
3.4生命周期模型
生命周期模型指软件开发全部过程、活动和任务的结构框架。
软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。
目前软件开发实践中使用的各种生命周期模型,主要如下:
1)瀑布模型。
需要对每一个阶段进行验证,瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠,而应该是在评审通过,相关的产出物都已经基线后才能够进入到下一个阶段。
采用瀑布模型可以保证系统在整体上的充分把握,使系统具备良好的扩展性和可维护性。
但对于前期需求不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型。
2)螺旋模型。
首先螺旋模型是遵从瀑布模型的。
即需求->架构->设计->开发->测试的路线。
螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的。
通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项目的风险。
螺旋模型实现了随着项目成本投入不断增加,风险逐渐减小。
以帮我我们加强项目的管理和跟踪,在每次迭代结束后都需要对产出物进行评估和验证,当发现无法继续进行下去时可以及早的终止项目。
3)增量和迭代模型。
增量迭代是RUP统一过程常采用的软件开发生命周期模型。
就对风险的消除上,增量和迭代模型都能够很好的控制前期的风险并解决。
但迭代模型在这方面更有优势。
迭代模型更多的可以从总体方面去系统的思考问题,从最早就可以给出相对完善的框架或原型,后期的每次迭代都是针对上次迭代的逐步精化。
3.5项目风险管理
风险管理贯穿项目管理的各个阶段和各个领域,是项目管理中的重点和难点。
软件项目风险管理是指对在软件开发过程中所遇到的预算和进度等方面的问题进行分析,寻求风险应对方法,做好风险管理计划。
通过缓和或预知等手段来减轻风险,降低风险发生的可能性或减缓风险带来的不利后果。
针对软件项目中的风险管理问题,主要风险管理模型如下:
1)SEI的连续风险管理模型(CRM)。
SEICRM模型的风险管理原则是不断地评估可能造成恶劣后果的因素;决定最迫切需要处理的风险;实现控制风险的策略;评测并确保风险策略实施的有效性。
CRM模型要求在项目生命期的所有阶段都关注风险识别和管理,它将风险管理划分为五个步骤:
风险识别、分析、计划、跟踪、控制。
2)BarryBoehm模型。
Boehm模型的思想核心是:
10大风险因素列表。
针对每个风险因素,都给出了一系列的风险管理策略。
在实际操作时,Boehm以10大风险列表为依据,总结当前项目具体的风险因素,评估后进行计划和实施,在下一次定期召开的会议上再对这10大风险因素的解决情况进行总结,产生新的10大风险因素表,依此类推。
3)软件工程风险模型(SERIM)。
SERIM模型要求从技术和商业两个角度对软件风险管理进行剖析,考虑的问题涉及开销、进度、技术性能等。
它还提供了一些指标和模型来估量和预测风险,由于这些数据来源于大量的实际经验,因此具有很强的说服力。
4项目过程管理
4.1软件设计
软件设计采用自顶向下、逐次功能展开的设计方法,首先完成总体设计,然后完成各有机组成部分的设计。
-全文完-
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 如何 做好 软件 研发 项目 管理