软件研发管理问题和解决方案ppt课件

1、软件研发管理问题和处理方案常见问题分析根底方法论引见整体处理方案林 锐 博士目录1. 企业研发管理的理念2. 常见问题分析3. 中型企业的研发管理需求4. 根底方法论引见CMM5. 根底方法论引见 PMBOK6. 根底方法论引见矫捷开发7. 根底方法论引见 RUP8. 面向企业的软件研发管理处理方案9. 基于Web的集成化工程管理系统 Future3.01. 企业研发管理的理念1.1 目的企业的根本目的是“合法地赚取尽能够多的利润，使企业利益最大化。企业一切的特定目的和行动都是围绕根本目的开展的。根本目的进一步决议了企业研发管理的目的和战略。企业研发管理的根本目的是：让一切人员有条不紊地开展任

2、务，在预定的时间和本钱之内，开发完成质量合格的产品，从而使企业和个人获得预定的利益。企业研发管理的斗争目的是：调动一切积极要素，努力提高产质量量、提高任务效率并且降低本钱，使企业和个人获得比预定目的更多的利益。1.2 质量、进度时间、本钱“质量、进度时间、本钱通常是衡量企业研发管理“优劣的三个关键目的。不同的企业，甚至同一企业在不同时期，对三者的重要性看法是不一样的。 假设出现“三者难以同时兼得的情况，那么产品的决策者一定要搞清楚质量、进度时间、本钱之间的复杂关系，判别孰重孰轻，给出优化和折衷的措施。 1.3 规范化 vs. 超越规范化在企业里，大部分的任务是成熟的，有胜利的方式可以套用，该当

3、走规范化的道路；而另外小部分的任务能够是独特的，并不适宜套用规范也能够没有规范可以套用，那么该当采用超越规范化的管理方式。通常前者约占80%，而后者约占20% 2.1 常见问题分析：立项管理2.1.1 自主研发产品的立项问题拥有决策权的指点人单独决议，或者召集有关人员开会商议能否开发某个产品。决策过程中的客观臆断比较多，风险很高。假设断策错误，即使人们努力开发出功能很好的产品，却能够在商业上失败。由于没有进展充分必要的调研、可行性分析、立项建议、立项评审等任务，企业指点在组建开发团队时难以给出恰当的资源和进度方案。团队只知道干活，却不了解产品的开发背景，不清楚用户期望的产品应该是什么样的。在开

4、发过程中经常迷失方向，导致进度延误、费用超支等问题。 2.1.2 合同工程的立项问题 委托方客户方和承包方开发方在签署合同的时候，双方对软件需求的了解并不深化，合同中对“开发什么的描画比较空洞。合同签署之后，客户经常变卦需求，开发方被迫不断修正软件，弄得疲惫不堪。夸张地概括：除了合同金额不变，其它一切都能够改动。刚签署合同时开发方似乎赚钱了，后头却能够得不偿失。双方在签署合同的过程中给出了一些空头承诺例如对进度、质量、费用的估计过于乐观，在实践执行时却难以兑现这些承诺。处置不好将引发合同纠纷，轻那么双方提早终止合同，重那么双方反目成仇。 2.1.3 建议创建一种群体决策的立项管理规范，不仅让群

5、众奉献智慧，而且让群众分担责任，使胜利的阅历被企业不断复用，并升华成为企业的制度。 2.2 常见问题分析： 结项管理2.2.1 共性问题某些工程由于进度拖延，不能按方案结项；某些工程即使开发完成了，由于利益关系也不愿结项。这些“不良工程或者曾经完成的工程不断占用企业资源如人力资源和设备，无疑违背企业利益最大化的目的。在结项时，人们往往对财务和设备进展了详细的清算，却忽视了对知识财富、阅历教训的总结。殊不知设备越用越差，但是知识财富越用越好，可谓主次颠倒。没有对工程的价值进展评价，开发人员干完活后，不知道本人的任务成果产生多大的效益，缺乏成就感。结项后，不能对员工的业绩进展公正考核，自然不能很好

6、地鼓励员工。合同软件工程在结项之前，还面临“客户验收的一些问题。例如缺乏双方认同的“验收规范，导致验收过程混乱，过多地耗费双方的精神。 2.2.2 建议首要措施是建立企业的“结项管理规范和“验收与发布规范。自主研发的软件产品在结项之前，公司内部要进展类似的“验收，防止不良工程蒙混过关。 2.3 常见问题分析：工程规划2.3.1 共性问题在工程刚开场阶段，人们对产品需求和技术的了解还比较浅薄，工程不确定要素比较多，此时很难对任务量和进度作出比较准确的估算。软件工程教科书和CMM引荐的COCOMO模型、代码行估算方法等等，对大多数国内工程无法适用，效果好像“电脑算命。由此制定的工程方案能够不真实践

7、，后面经常发生工程方案的变卦所以业界流传“方案快不如变化快，将导致工程管理的复杂性和风险提高。工程的人员曾经被上级指点限定死了，再多的活也是那几个人干；工程的终了日期早就被指点和客户指定了，不论合理不合理，反正时间一到就要交付软件；除了办公计算机和工资外，这个工程没有其它经费，工程经理只需干活的权益没有用钱的权益。假设人员、资金、时间都曾经被毫无道理地指定了，那么工程规划就失去意义，这样的工程在国内非常普遍。 2.3.2 建议建立企业的“工程规划规范，给出适宜的工程估算方法和工程方案模板。运用方便的软件工具，协助工程经理进展工程规划。 2.4 常见问题分析：工程监控2.4.1 共性问题许多工程

8、经理肩负重要的软件开发任务，他们往往把留意力集中在开发上面，很少仔细思索如何进展工程监控 。没有突出工程监控的重点，工程经理要么什么都不监控导致工程失控，要么监控得太多而堕入琐碎事务中。 工程经理写周期性工程进展报告时，记流水帐，或者复制上次的报告，应付了事。懒得动脑筋分析工程遇到的一些问题，例如某些义务的进度延误了，不分析为什么延误了，就顺延。导致问题越积越多。工程实践执行情况与原定的工程方案严重脱节，指点、客户、市场人员、开发团队不了解工程真正的情况，使工程方案行同虚设。 2.4.2 建议建立企业的“工程监控规范，运用方便的软件工具，协助工程经理进展工程监控。上级指点和相关人员每周都要检查

9、工程的监控要素，及时发现问题，及时处理问题，既要关怀结果也要关怀过程。 2.5 常见问题分析：配置管理和变卦管理2.5.1 共性问题有些软件机构竟然不运用软件配置管理工具，用最原始的方式手工管理代码和文档，经常出现“成果丧失、版本混乱等问题。不少机构按照的CMM的要求制定了配置管理规范。该规范在实际上比较完善，面面俱到，但是实践操作比较费事，没有突出重点。久而久之，人们腻烦后就逐渐放弃了规范，按本人的习惯操作，留下了隐患。例如不少程序被 checkout 后长久没有 checkin；有些程序保管在开发者本机，根本就没有放入配置库。维护期间修正了程序，但是没有放入配置库。没有变卦控制流程，经常随

10、意变卦需求、设计、代码等，严重影响工程的正常开发进程。 2.5.2 建议建立简单有效的“配置管理规范和“变卦管理规范。并运用方便的工具，协助团队进展软件配置管理和变卦管理。 2.6 常见问题分析：质量管理2.6.1 共性问题虽然人们大都认可软件的质量很重要，但是许多软件人员并不懂得如何有效地改善软件质量属性如正确性、强壮性、可靠性、性能、易用性、平安性、可扩展性、可复用性、兼容性、可移植性等等。不会分析当前软件的质量要素是什么，没有把精神集中在改善对经济效益奉献最大的质量要素上面。 有些软件机构没有软件质量管理的措施，开发人员把完胜利能当成终极目的。用户在运用软件的过程中发现许多Bug，导致开

11、发方的纠错性维护代价很高。 有些软件机构虽然很注重软件质量，按照ISO,CMM 的要求建立了管理规范，但是效果不明显。人们搞不清楚软件测试、技术评审、质量保证的作用和关系。不懂得内建质量，主要靠修补错误的方式提升质量，代价比较高。 很多人误以为提高软件质量是质量保证人员和测试人员的责任，没有认识到任何开发人员、管理人员都会对质量产生影响，都要对质量担任。另外，质量保证人员的权益比较小，很难推进质量改良措施。 2.6.2 建议让人们了解“什么是软件质量及常见的软件质量属性，树立全面软件质量管理的理念模型，制定软件测试、技术评审、质量保证的规范。并运用方便的工具，协助团队进展软件质量管理。 2.7

12、 常见问题分析：需求开发与管理2.7.1 共性问题对于大部分软件机构而言，需求开发与需求管理是问题最多、最难处理的过程域。 软件机构中，知晓需求调查、需求分析、需求定义、需求评审、需求跟踪、需求变卦控制的人员本来就比较少，也不容易招聘和培育这样的人才。 用户说不清楚需求、用户经常变卦需求是普遍景象，令开发方非常头痛。 开发人员不擅长写文档，很难写出清楚、完好的软件需求规格阐明书。后续开发人员能够误解需求，做出与需求不一致的设计、代码、测试用例等等，最后不得不大量返工重做。 最难办的事情是莫过于“回绝客户提出的需求变卦恳求。客户会想当然地以为变卦需求是他的权益，由于他付钱给开发方。通常情况下开发

13、方是不敢得罪客户的，但是无原那么地退让将使开发小组堕入姿态。 2.7.2 建议建立“需求开发与管理规范，给出适宜的文档模板，采用方便的需求分析和管理工具。还要多请有阅历的人来培训、教授实战阅历。 制定应对需求变卦的方法，例如：(1)双方签署需求变卦管理协议;(2)将艰苦需求变卦延缓到下个软件版本中实现;(3)让客户欠下人情。 2.8 常见问题分析：软件设计2.8.1 共性问题对于大部分软件机构而言，用户界面设计是弱项。国内绝大多数大学的计算机学科没有开设人机工程学、美学、心思学这些必修课。由于学生们接受的教育几乎全是科学与技术，他们根本不知道怎样才干设计出易用、美观的用户界面，很多人甚至想都没

14、有想过。当他们毕业后真正参与软件产品开发时，只好凭着个人的阅历与觉得设计软件的用户界面，这样产生的界面往往得不到群众用户的认可。 大部分软件机构都有一些技术出色的软件人员，他们在系统构架、数据库方面的设计才干相当不错。但是很多人不情愿、不擅长写系统设计报告，这不利于后续的软件开发和维护。 软件设计该当“细到什么程度很难把握。太粗了的话，对后续开发任务的指点价值不高；反之倘假设太细的话，耗费时间就比较多，假设后面不断改良设计的话，前面的设计浪费太多。 2.8.2 建议建立“软件设计规范，给出适宜的文档模板，采用方便的设计工具。 还要多请有阅历的人来培训、教授实战阅历。 2.9 常见问题分析：编程

15、与调试2.9.1 共性问题软件机构的大部分程序员的技艺是合格的，但是他们编写的程序风格差别较大，代码质量有高有低。大多数软件机构没有编程规范，即使有的话，开发人员也没有很好地按规范编程。相当多的程序员没有养成对一切代码进展“单步跟踪调试的习惯。嫌单元测试很费事，懒得执行，却没有替代方案。2.9.2 建议制定简单明了、重点突出的“编程规范，让团队遵照此规范编写程序。采用集成化的开发调试工具，提高编程质量和效率。 2.10 常见问题分析：软件测试2.10.1 共性问题许多软件人员没有系统地学习过软件测试，搞不清楚各种测试的概念，例如单元测试、集成测试、验收测试、黑盒测试、白盒测试、功能测试、性能测

16、试等等，混为一谈，不知如何下手。测试人员没有掌握有效测试的方法，大多凭觉得测试，结果反复测试曾经测试过的，那些深藏的bug却发现不了。客户在运用软件的过程中发现的bug比公司内部测试时发现的还多，不仅改错代价高，而且降低了客户对产品的称心度。团队没有采用有效的缺陷跟踪工具。测试人员发现bug时，口头告知有关人员或者记在Word、Excel文件中，修正bug信息或者测试报告时非常费事。难以及时从bug列表中找出规律，测试的效率比较低。 2.9.2 建议建立“软件测试规范，采用方便的测试管理工具。还要多请有阅历的人来培训、教授实战阅历。 2.11 常见问题分析：软件维护2.11.1 共性问题在维护

17、期间，除了纠错性维护外，客户能够提出需求变卦但是不支付费用，维护人员对客户妥协，导致维护任务量增大、本钱添加。假设是合同软件工程，用户对开发方的依赖性比较大，不情愿本人处理粗浅的问题，经常叫开发方“干这干那。开发方不敢得罪客户，导致开发方做了许多不属于维护的任务，吃哑巴亏。开发人员一边开发新工程，一边维护老工程。而维护为表达不出业绩，又影响了新工程的进度，开发人员比较心烦。 2.11.2 建议制定“软件维护规范，界定什么是“免费维护、什么是“有偿维护，以及相应的操作规那么，提高维护效率并且降低维护本钱。 2.12 常见问题分析：其它问题2.12.1 技术 vs. 市场许多开发人员喜欢技术研讨和

18、技术挑战。虽然嘴上说开发产品要以“客户市场为中心，但是在开发软件的时候，却不知不觉以技术为中心，例如喜欢采用新技术、追求技术上的完美。导致进度延误，本钱添加，甚至能够有质量风险。他们开发出来的软件在技术上能够很先进，但是并不是用户所关怀的。多数开发人员缺乏商业头脑，经常做出背叛企业根本目的的事情。企业指点该当注重这个问题，要经常性地向开发人员们灌输商业理念。让他们明白 “可以赚钱的技术才是好技术。在企业里，商业利益高于技术追求。 2.11.2 工程经理的财务权国内大部分企业的工程经理有带头干活的权益和义务，他们对工程的进度和质量负最大责任，但是没有财务权。大部分工程没有经费，即使有经费，也得由

19、上级指点审批运用，不能本人作主。有时团队加班干了不少活，工程经理却没有钱“意思意思，很没有面子。没有财务权的工程经理，不是完好意义上的工程经理。企业不给工程经理财务权的初衷是为了控制本钱，防止工程经理乱花钱。但是实践上效果适得其反。由于工程经理没有财务权，他们就不会关怀本钱也不懂得如何控制本钱。因管理不成熟、任务效率不高、进度延误等问题导致“隐性本钱不断添加，钱在不知不觉地流失。企业指点该当给予工程经理“适当的财务权，只需确定工程财务制度并限定经费额度，就不会呵斥失控。既让工程经理“有点小钱慰劳团队，有任务积极性；又让他真正注重本钱控制，并付诸实际。用“小量胡萝卜获得大报答。 3. 中型企业的

20、研发管理需求3.1 需求特征必要性。假设软件机构只需数人或者十几个人，即使没有研发管理规范，才干强的机构指点一个人也能从容指挥。当软件机构的人数超越50人后，假设还没有研发管理规范的话，那么机构指点将会力不从心。人数越多，非规范化管理越容易产生混乱，迫使企业不得不走规范化管理的道路，以降低管理代价和风险。经济根底。建立规范化的研发管理是需求一定的投资的，例如咨询、培训、购买工具等等。小型软件机构通常没有钱去做这件事情，望洋兴叹。中型机构可以养活50200人，表示它们是有一定经济实力的，只需投资额适当而且产生的效益高于投资，那么中型机构普通都情愿做这件事情。 开展愿望。有些中型机构的指点雄心勃勃

21、，高瞻远瞩，他们迫切希望提高研发管理才干从而提升整个企业的中心竞争力，产生源源不断的推进力，推进企业继续开展壮大。他们对研发管理的态度是自动的，而不是被动的。 3.2 费用估算国内一些大型IT企业建立了完好的研发管理体系，投资宏大。例如上海贝尔、华为分别请HP、IBM建立研发管理体系，投资额分别到达数千万元、上亿元。这种投资额是中型企业望尘莫及的。在研发管理方面，中型企业无法效仿大型企业的做法。国内中型软件机构对研发管理的投资额大约在数万元至元数十万元。这点“小钱根本无法引入IBM、HP、Rational等公司的研发管理处理方案。 大部分国内中型软件机构需求的是“轻量级的研发管理处理方案，包括

22、咨询、培训、购买工具，总费用在5万元至20万元之间比较适宜。 4. 根底方法论引见CMM4.1 根本概念产品是在过程中研制出来的。普通地，好的过程才能够得到好的产品，而差的过程只会得到差的产品。提高软件过程才干的实际通称为软件过程改良Software Process Improvement。软件过程改良的根本目的是：提高质量、提高消费率并且降低开发本钱。 CMM/CMMI是世界范围内用于衡量软件过程才干的现实上的规范，同时也是软件过程改良最权威的指南。 CMM等级评价：从狂热回归理性。如今软件业界普遍关注的是：企业如何以比较低的代价有效地提高软件过程才干。CMM等级评价那么退居次要位置。 4.

23、2 CMM的盲区和常见运用问题CMM本身不谈如何赚钱的问题。它假设了愉快的前提条件，即企业有充足的人员、资金、时间从事软件过程改良，当软件过程才干提高了，那么产品的质量、消费率自然上去了同时本钱也下降了，企业自然可以获取更多的利润。软件过程改良对企业经济效益的奉献是间接的，从投入到产出，时间相对比较长。 企业指点当然想把资源用在“刀刃上，即赚钱最多最快的地方。当软件过程改良和其它直接赚钱的事情“发生资源冲突时，人们只好“拆东墙，补西墙，往往减少软件过程改良的资源。小结：对于软件过程改良而言，CMM/CMMI和ISO等等都是用来参考的，而不是用来迷信的。企业在参考业界引荐的规范或规范时，要舍弃那

24、些听起来很先进但是对本企业无益处的东西，只选取对企业有适用价值的东西。 5. 根底方法论引见PMBOK5.1 根本概念工程管理协会PMI是目前全球影响最大的工程管理专业机构，该机构的工程管理专家认证PMP被广泛认同。PMI的突出奉献是总结了一套工程管理知识体系PMBOK。 PMBOK把工程管理知识划分为九个知识领域：综合管理、范围管理、时间管理、本钱管理、质量管理、人力资源管理、沟通管理、风险管理和采购管理。每个知识领域包括数量不等的工程管理过程。 5.2 PMBOK和CMM/CMMI对比简评 CMM/CMMI论述的工程管理方法仅仅适用于软件工程，但是不适用于其它行业的工程管理。PMBOK论述

25、的方法适用于任何行业的工程管理，但是对软件工程管理而言，PMBOK的针对性不够强。 CMM/CMMI不仅论述软件工程管理，而且论述整个机构的软件研发管理。PMBOK的方法局限于工程管理，对于企业研发管理那么不够用。 CMM/CMMI根本上不谈“本钱管理和“人力资源管理，它先假设机构有充足的资金和人力资源，通常不切合企业实践情况。因此PMBOK的“本钱管理和“人力资源管理可以弥补CMM/CMMI的缺乏。 建议：对于软件机构研发管理或者软件工程管理，采用CMM/CMMI为主导的方法论，并结合PMBOK的知识，取长补短。 6. 根底方法论引见矫捷开发6.1 根本概念2001年，为理处理许多公司的软件

26、团队堕入不断扩展的过程泥潭，一批业界专家概括出了一些可以让软件开发团队具有快速任务、呼应变化才干的价值观和原那么，他们称本人为矫捷联盟Agile Alliance。他们起草了一个旨在鼓励更好的软件开发方法的宣言，称为矫捷联盟宣言The Manifesto of the Agile Alliance。然后在该宣言根底上制定了12条原那么用于指点实际。该宣言和12条原那么是矫捷软件开发方法的中心。 6.2 我们的观念矫捷软件开发的宣言和12条原那么并非普遍适用。 矫捷开发方法表达了“简单、快速、适用的软件开发思想，它不是成熟的实际、也不是现实上的规范不象CMM, PMBOK那样具有严密的实际体系，

27、被企业广泛接受。即使人们认同某些原那么，但是不同的人往往有不同的了解，实际差别很大。 矫捷开发方法对于提高个人、小型团队的任务效率是很有协助的假设用对了的话。但是企图用它指点大型、中型软件机构的研发管理是有很高风险的，它的某些主张是部分观念而不是全局观念，假设把握不好分寸的话能够导致整体混乱，而“整体的混乱会淹没“部分的益处。我们研制的“精简并行过程SPP的实际根底是“经典软件工程、CMM、PMBOK。为了提高效率，在部分地方自创了“矫捷软件开发的思想，用于裁减过于冗长、笨重的过程规范。 6. 根底方法论引见矫捷开发矫捷软件开发的12条原那么：1我们最优先要做的是经过尽早地、继续地交付有价值的

28、软件来使客户称心。 2即使到了开发的后期，也欢迎改动需求。矫捷过程利用变化来为客户发明竞争优势。3经常性地交付可以任务的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 4在整个工程开发期间，业务人员和开发人员必需天天都在一同任务。 5围绕被鼓励起来的个人来构建工程。给他们提供所需的环境和支持，并且信任他们可以完成任务。 6在团队内部，最具有效果并富有效率的传送信息的方法，就是面对面的交谈。 7可以任务的软件是首要的进度度量规范。 8矫捷过程提倡可继续的开发速度。责任人、开发者和用户应该可以坚持一个长期的、恒定的开发速度。 9不断地关注优秀的技艺和好的设计会加强矫捷才干。 10

29、简单把无需做的任务最大化的艺术是最根本的。 11最好的构架、需求和设计出于自我组织的团队。 12每隔一定时间，团队会在如何才干更有效地任务方面进展反省，然后相应地对本人的行为进展调整。 7. 根底方法论引见RUP7.1 根本概念RUPRational Unified Process是Rational公司推出的软件过程模型，它是软件业界迄今为止商品化最胜利的软件过程模型。RUP的近千页文档可以从Rational公司的网站rational下载，RUP 2000中文版也曾经发布。RUP的主要特征是：采用迭代的、增量式的开发过程。采用UML言语描画软件开发过程。有一系列功能强大的软件工具支撑Ratio

30、nal公司的软件产品。 7.2 我们的观念RUP及其配套软件工具是分量级的软件研发管理处理方案，它面向的是高端用户，对用户的财力、开发和管理才干要求都很高：首先，用户得有钱买Rational的软件工具，否那么光有RUP方法论好像纸上谈兵。 假设要运用RUP方法，人们得先熟习UML，否那么除了RUP模型图之外他根本上看不懂细节内容。可是在普通企业里，大部分人尤其是指点和管理人员不熟习UML。学习UML和RUP的难度远高于CMM和PMBOK。工程经理和开发组长要有才干控制迭代过程，否那么迭代式开发就变得混乱无序和漫无边沿 RUP及其配套的软件工具根本上不适宜于国内中型和小型软件机构。 8. 面向企

31、业的软件研发管理处理方案8.1 目的协助企业建立适宜于本身需求的软件研发管理规范，并部署配套的软件工具；经过充分的培训，协助员工们掌握提高质量、提高消费率、降低本钱的方法；协助企业根据规范开展软件研发和管理任务，继续提升才干。 8.2 任务流程面向企业的软件研发管理处理方案8. 面向企业的软件研发管理处理方案 8.3 集成化研发管理方法Simplified Parallel Process, SPP8. 面向企业的软件研发管理处理方案8.4 内容和时间1.调查分析问题对企业研发管理的能力现状进行调查与分析，调查内容要覆盖所有工作领域（过程域），总结“强项”和“弱项”，给出建议。 预计时间跨度为

32、2个月，乙方到甲方现场工作和服务约20工作日。日程安排由双方共同商定。2.制定研发管理规范 绘制研发管理的总体流程图；绘制组织结构图，并确定角色职责表 ；定义每个过程域的规范（目的，关键活动和流程，工作成果） 3.选用合适的工具选择并部署合适的开发工具和管理工具。推荐管理工具是Future和CVS。含1年免费维护和升级服务4.充分必要的培训为研发管理流程中的所有人员提供充分必要的培训，包括软件工程、项目管理等，让人们掌握提高软件质量、提高生产率、降低成本的方法。 5.执行、监督与反馈协助客户依据规范开展软件研发和管理工作。跟踪试点项目的执行情况，及时解答执行过程中遇到的问题，持续地提升客户的软件研发能力。 乙方提供一年的售后服务。解决方案的内容视企业的实际情况而定。8.5 相关著作9. 集成化软件工程管理系统Future9.1 什么是FutureFuture是基于Web的集成化工程管理系统，目的是“让工程管理变得简单有效。Future的主要客户是国内中型软件机构，主要最终用户是研发