软件研发管理问题分析和解决方案

《软件研发管理问题分析和解决方案》由会员分享，可在线阅读，更多相关《软件研发管理问题分析和解决方案（38页珍藏版）》请在金锄头文库上搜索。

1、 上上 海海 漫漫 索索 计计 算算 机机 科科 技技 有有 限限 公公 司司软件研发管理问题和解决方案软件研发管理问题和解决方案常见问题分析常见问题分析根底方法论介绍根底方法论介绍整体解决方案整体解决方案林林 锐锐 博士博士Page 2目录目录1. 企业研发管理的理念企业研发管理的理念2. 常见问题分析常见问题分析3. 中型企业的研发管理需求中型企业的研发管理需求4. 根底方法论介绍根底方法论介绍CMM5. 根底方法论介绍根底方法论介绍 PMBOK6. 根底方法论介绍敏捷开发根底方法论介绍敏捷开发7. 根底方法论介绍根底方法论介绍 RUP8. 面向企业的软件研发管理解决方案面向企业的软件研发

2、管理解决方案9. 基于基于Web的集成化工程管理系统的集成化工程管理系统 Future3.0Page 31. 企业研发管理的理念企业研发管理的理念1.1 1.1 目标目标企业的根本目标是企业的根本目标是“合法地赚取尽可能多的利润，使企业利益最大化。企业所有的特定目合法地赚取尽可能多的利润，使企业利益最大化。企业所有的特定目标和行动都是围绕根本目标开展的。根本目标进一步决定了企业研发管理的目标和策略。标和行动都是围绕根本目标开展的。根本目标进一步决定了企业研发管理的目标和策略。企业研发管理的根本目标是：让所有人员有条不紊地开展工作，在预定的时间和本钱之内，企业研发管理的根本目标是：让所有人员有条

3、不紊地开展工作，在预定的时间和本钱之内，开发完成质量合格的产品，从而使企业和个人获得预定的利益。开发完成质量合格的产品，从而使企业和个人获得预定的利益。企业研发管理的奋斗目标是：调动一切积极因素，努力提高产品质量、提高工作效率并且降企业研发管理的奋斗目标是：调动一切积极因素，努力提高产品质量、提高工作效率并且降低本钱，使企业和个人获得比预定目标更多的利益。低本钱，使企业和个人获得比预定目标更多的利益。1.2 1.2 质量、进度时间、本钱质量、进度时间、本钱“质量、进度时间、本钱通常是衡量企业研发管理质量、进度时间、本钱通常是衡量企业研发管理“优劣的三个关键指标。不同的优劣的三个关键指标。不同的

4、企业，甚至同一企业在不同时期，对三者的重要性看法是不一样的。企业，甚至同一企业在不同时期，对三者的重要性看法是不一样的。 如果出现如果出现“三者难以同时兼得的情况，那么产品的决策者一定要搞清楚质量、进度时间三者难以同时兼得的情况，那么产品的决策者一定要搞清楚质量、进度时间、本钱之间的复杂关系，判断孰重孰轻，给出优化和折衷的措施。、本钱之间的复杂关系，判断孰重孰轻，给出优化和折衷的措施。 1.3 1.3 标准化标准化 vs. vs. 超越标准化超越标准化在企业里，大局部的工作是成熟的，有成功的模式可以套用，应当走标准化的路线；而另外在企业里，大局部的工作是成熟的，有成功的模式可以套用，应当走标准

5、化的路线；而另外小局部的工作可能是独特的，并不适宜套用标准也可能没有标准可以套用，那么应当采小局部的工作可能是独特的，并不适宜套用标准也可能没有标准可以套用，那么应当采用超越标准化的管理方式。通常前者约占用超越标准化的管理方式。通常前者约占80%80%，而后者约占，而后者约占20% 20% Page 42.1 常见问题分析：立项管理常见问题分析：立项管理2.1.1 2.1.1 自主研发产品的立项问题自主研发产品的立项问题拥有决策权的领导人单独决定，或者招集有关人员开会商议是否开发某个产品。拥有决策权的领导人单独决定，或者招集有关人员开会商议是否开发某个产品。决策过程中的主观臆断比较多，风险很高

6、。如果断策错误，即使人们努力开发出决策过程中的主观臆断比较多，风险很高。如果断策错误，即使人们努力开发出功能很好的产品，却可能在商业上失败。功能很好的产品，却可能在商业上失败。由于没有进行充分必要的调研、可行性分析、立项建议、立项评审等工作，企业由于没有进行充分必要的调研、可行性分析、立项建议、立项评审等工作，企业领导在组建开发团队时难以给出恰当的资源和进度方案。团队只知道干活，却不领导在组建开发团队时难以给出恰当的资源和进度方案。团队只知道干活，却不了解产品的开发背景，不清楚用户期望的产品应该是什么样的。在开发过程中经了解产品的开发背景，不清楚用户期望的产品应该是什么样的。在开发过程中经常迷

7、失方向，导致进度延误、费用超支等问题。常迷失方向，导致进度延误、费用超支等问题。 2.1.2 2.1.2 合同工程的立项问题合同工程的立项问题 委托方客户方和承包方开发方在签订合同的时候，双方对软件需求的委托方客户方和承包方开发方在签订合同的时候，双方对软件需求的了解并不深入，合同中对了解并不深入，合同中对“开发什么的描述比较空洞。合同签订之后，客户经开发什么的描述比较空洞。合同签订之后，客户经常变更需求，开发方被迫不断修改软件，弄得疲惫不堪。夸张地概括：除了合同常变更需求，开发方被迫不断修改软件，弄得疲惫不堪。夸张地概括：除了合同金额不变，其它一切都可能改变。刚签订合同时开发方似乎赚钱了，后

8、头却可能金额不变，其它一切都可能改变。刚签订合同时开发方似乎赚钱了，后头却可能得不偿失。得不偿失。双方在签订合同的过程中给出了一些空头承诺例如对进度、质量、费用的估计双方在签订合同的过程中给出了一些空头承诺例如对进度、质量、费用的估计过于乐观，在实际执行时却难以兑现这些承诺。处理不好将引发合同纠纷，轻过于乐观，在实际执行时却难以兑现这些承诺。处理不好将引发合同纠纷，轻那么双方提前终止合同，重那么双方反目成仇。那么双方提前终止合同，重那么双方反目成仇。 2.1.3 2.1.3 建议建议创立一种群体决策的立项管理标准，不仅让群众奉献智慧，而且让群众分担责任，创立一种群体决策的立项管理标准，不仅让群

9、众奉献智慧，而且让群众分担责任，使成功的经验被企业不断复用，并升华成为企业的制度。使成功的经验被企业不断复用，并升华成为企业的制度。 Page 52.2 常见问题分析：常见问题分析： 结项管理结项管理2.2.1 2.2.1 共性问题共性问题某些工程由于进度拖延，不能按方案结项；某些工程即使开发完成了，由于利益关系也不某些工程由于进度拖延，不能按方案结项；某些工程即使开发完成了，由于利益关系也不愿结项。这些愿结项。这些“不良工程或者已经完成的工程一直占用企业资源如人力资源和设备，不良工程或者已经完成的工程一直占用企业资源如人力资源和设备，无疑违背企业利益最大化的目标。无疑违背企业利益最大化的目标

10、。在结项时，人们往往对财务和设备进行了详细的清算，却无视了对知识财富、经验教训的在结项时，人们往往对财务和设备进行了详细的清算，却无视了对知识财富、经验教训的总结。殊不知设备越用越差，但是知识财富越用越好，可谓主次颠倒。总结。殊不知设备越用越差，但是知识财富越用越好，可谓主次颠倒。没有对工程的价值进行评估，开发人员干完活后，不知道自己的工作成果产生多大的效益，没有对工程的价值进行评估，开发人员干完活后，不知道自己的工作成果产生多大的效益，缺乏成就感。缺乏成就感。结项后，不能对员工的业绩进行公正考核，自然不能很好地鼓励员工。结项后，不能对员工的业绩进行公正考核，自然不能很好地鼓励员工。合同软件工

11、程在结项之前，还面临合同软件工程在结项之前，还面临“客户验收的一些问题。例如缺乏双方认同的客户验收的一些问题。例如缺乏双方认同的“验收验收标准，导致验收过程混乱，过多地消耗双方的精力。标准，导致验收过程混乱，过多地消耗双方的精力。 2.2.2 2.2.2 建议建议首要措施是建立企业的首要措施是建立企业的“结项管理标准和结项管理标准和“验收与发布标准。验收与发布标准。自主研发的软件产品在结项之前，公司内部要进行类似的自主研发的软件产品在结项之前，公司内部要进行类似的“验收，防止不良工程蒙混过验收，防止不良工程蒙混过关。关。 Page 62.3 常见问题分析：工程规划常见问题分析：工程规划2.3.

12、1 2.3.1 共性问题共性问题在工程刚开始阶段，人们对产品需求和技术的了解还比较浅薄，工程不确定因素比较多，在工程刚开始阶段，人们对产品需求和技术的了解还比较浅薄，工程不确定因素比较多，此时很难对工作量和进度作出比较准确的估算。软件工程教科书和此时很难对工作量和进度作出比较准确的估算。软件工程教科书和CMMCMM推荐的推荐的COCOMOCOCOMO模型、模型、代码行估算方法等等，对大多数国内工程无法适用，效果如同代码行估算方法等等，对大多数国内工程无法适用，效果如同“电脑算命。由此制定的电脑算命。由此制定的工程方案可能不切实际，后面经常发生工程方案的变更所以业界流传工程方案可能不切实际，后面

13、经常发生工程方案的变更所以业界流传“方案快不如变化方案快不如变化快，将导致工程管理的复杂性和风险提高。快，将导致工程管理的复杂性和风险提高。工程的人员已经被上级领导限定死了，再多的活也是那几个人干；工程的结束日期早就被工程的人员已经被上级领导限定死了，再多的活也是那几个人干；工程的结束日期早就被领导和客户指定了，不管合理不合理，反正时间一到就要交付软件；除了办公计算机和工领导和客户指定了，不管合理不合理，反正时间一到就要交付软件；除了办公计算机和工资外，这个工程没有其它经费，工程经理只有干活的权利没有用钱的权利。如果人员、资资外，这个工程没有其它经费，工程经理只有干活的权利没有用钱的权利。如果

14、人员、资金、时间都已经被毫无道理地指定了，那么工程规划就失去意义，这样的工程在国内非常金、时间都已经被毫无道理地指定了，那么工程规划就失去意义，这样的工程在国内非常普遍。普遍。 2.3.2 2.3.2 建议建议建立企业的建立企业的“工程规划标准，给出适宜的工程估算方法和工程方案模板。工程规划标准，给出适宜的工程估算方法和工程方案模板。使用方便的软件工具，帮助工程经理进行工程规划。使用方便的软件工具，帮助工程经理进行工程规划。 Page 72.4 常见问题分析：工程监控常见问题分析：工程监控2.4.1 2.4.1 共性问题共性问题许多工程经理肩负重要的软件开发工作，他们往往把注意力集中在开发上面

15、，很少认真考许多工程经理肩负重要的软件开发工作，他们往往把注意力集中在开发上面，很少认真考虑如何进行工程监控虑如何进行工程监控 。没有突出工程监控的重点，工程经理要么什么都不监控导致工程失控，要么监控得太没有突出工程监控的重点，工程经理要么什么都不监控导致工程失控，要么监控得太多而陷入琐碎事务中。多而陷入琐碎事务中。 工程经理写周期性工程进展报告时，记流水帐，或者复制上次的报告，应付了事。懒得动工程经理写周期性工程进展报告时，记流水帐，或者复制上次的报告，应付了事。懒得动脑筋分析工程遇到的一些问题，例如某些任务的进度延误了，不分析为什么延误了，就顺脑筋分析工程遇到的一些问题，例如某些任务的进度

16、延误了，不分析为什么延误了，就顺延。导致问题越积越多。延。导致问题越积越多。工程实际执行情况与原定的工程方案严重脱节，领导、客户、市场人员、开发团队不了解工程实际执行情况与原定的工程方案严重脱节，领导、客户、市场人员、开发团队不了解工程真正的状况，使工程方案行同虚设。工程真正的状况，使工程方案行同虚设。 2.4.2 2.4.2 建议建议建立企业的建立企业的“工程监控标准，使用方便的软件工具，帮助工程经理进行工程监控。工程监控标准，使用方便的软件工具，帮助工程经理进行工程监控。上级领导和相关人员每周都要检查工程的监控要素，及时发现问题，及时解决问题，既要上级领导和相关人员每周都要检查工程的监控要

17、素，及时发现问题，及时解决问题，既要关心结果也要关心过程。关心结果也要关心过程。 Page 82.5 常见问题分析：配置管理和变更管理常见问题分析：配置管理和变更管理2.5.1 2.5.1 共性问题共性问题有些软件机构竟然不使用软件配置管理工具，用最原始的方式手工管理代码和文档，经常有些软件机构竟然不使用软件配置管理工具，用最原始的方式手工管理代码和文档，经常出现出现“成果丧失、版本混乱等问题。成果丧失、版本混乱等问题。不少机构按照的不少机构按照的CMMCMM的要求制定了配置管理标准。该标准在理论上比较完善，面面俱到，但的要求制定了配置管理标准。该标准在理论上比较完善，面面俱到，但是实际操作比

18、较麻烦，没有突出重点。久而久之，人们厌烦后就逐渐放弃了标准，按自己是实际操作比较麻烦，没有突出重点。久而久之，人们厌烦后就逐渐放弃了标准，按自己的习惯操作，留下了隐患。例如不少程序被的习惯操作，留下了隐患。例如不少程序被 checkout checkout 后长久没有后长久没有 checkin checkin；有些程序保；有些程序保存在开发者本机，根本就没有放入配置库。存在开发者本机，根本就没有放入配置库。维护期间修改了程序，但是没有放入配置库。维护期间修改了程序，但是没有放入配置库。没有变更控制流程，经常随意变更需求、设计、代码等，严重影响工程的正常开发进程。没有变更控制流程，经常随意变更需

19、求、设计、代码等，严重影响工程的正常开发进程。 2.5.2 2.5.2 建议建议建立简单有效的建立简单有效的“配置管理标准和配置管理标准和“变更管理标准。变更管理标准。并使用方便的工具，帮助团队进行软件配置管理和变更管理。并使用方便的工具，帮助团队进行软件配置管理和变更管理。 Page 92.6 常见问题分析：质量管理常见问题分析：质量管理2.6.1 2.6.1 共性问题共性问题虽然人们大都认可软件的质量很重要，但是许多软件人员并不懂得如何有效地改善软件质虽然人们大都认可软件的质量很重要，但是许多软件人员并不懂得如何有效地改善软件质量属性如正确性、健壮性、可靠性、性能、易用性、平安性、可扩展性

20、、可复用性、兼容量属性如正确性、健壮性、可靠性、性能、易用性、平安性、可扩展性、可复用性、兼容性、可移植性等等。不会分析当前软件的质量要素是什么，没有把精力集中在改善对经济性、可移植性等等。不会分析当前软件的质量要素是什么，没有把精力集中在改善对经济效益奉献最大的质量要素上面。效益奉献最大的质量要素上面。 有些软件机构没有软件质量管理的措施，开发人员把完成功能当成终极目标。用户在使用有些软件机构没有软件质量管理的措施，开发人员把完成功能当成终极目标。用户在使用软件的过程中发现许多软件的过程中发现许多BugBug，导致开发方的纠错性维护代价很高。，导致开发方的纠错性维护代价很高。 有些软件机构虽

21、然很重视软件质量，按照有些软件机构虽然很重视软件质量，按照ISO,CMM ISO,CMM 的要求建立了管理标准，但是效果不明的要求建立了管理标准，但是效果不明显。人们搞不清楚软件测试、技术评审、质量保证的作用和关系。不懂得内建质量，主要显。人们搞不清楚软件测试、技术评审、质量保证的作用和关系。不懂得内建质量，主要靠修补错误的方式提升质量，代价比较高。靠修补错误的方式提升质量，代价比较高。 很多人误以为提高软件质量是质量保证人员和测试人员的责任，没有意识到任何开发人员、很多人误以为提高软件质量是质量保证人员和测试人员的责任，没有意识到任何开发人员、管理人员都会对质量产生影响，都要对质量负责。另外

22、，质量保证人员的权力比较小，很管理人员都会对质量产生影响，都要对质量负责。另外，质量保证人员的权力比较小，很难推动质量改进措施。难推动质量改进措施。 2.6.2 2.6.2 建议建议让人们理解让人们理解“什么是软件质量及常见的软件质量属性，树立全面软件质量管理的理念什么是软件质量及常见的软件质量属性，树立全面软件质量管理的理念模型，制定软件测试、技术评审、质量保证的标准。模型，制定软件测试、技术评审、质量保证的标准。并使用方便的工具，帮助团队进行软件质量管理。并使用方便的工具，帮助团队进行软件质量管理。 Page 102.7 常见问题分析：需求开发与管理常见问题分析：需求开发与管理2.7.1

23、2.7.1 共性问题共性问题对于大局部软件机构而言，需求开发与需求管理是问题最多、最难解决的过程域。对于大局部软件机构而言，需求开发与需求管理是问题最多、最难解决的过程域。 软件机构中，通晓需求调查、需求分析、需求定义、需求评审、需求跟踪、需求变更控制软件机构中，通晓需求调查、需求分析、需求定义、需求评审、需求跟踪、需求变更控制的人员本来就比较少，也不容易招聘和培养这样的人才。的人员本来就比较少，也不容易招聘和培养这样的人才。 用户说不清楚需求、用户经常变更需求是普遍现象，令开发方非常头痛。用户说不清楚需求、用户经常变更需求是普遍现象，令开发方非常头痛。 开发人员不善于写文档，很难写出清楚、完

24、整的软件需求规格说明书。后续开发人员可能开发人员不善于写文档，很难写出清楚、完整的软件需求规格说明书。后续开发人员可能误解需求，做出与需求不一致的设计、代码、测试用例等等，最后不得不大量返工重做。误解需求，做出与需求不一致的设计、代码、测试用例等等，最后不得不大量返工重做。 最难办的事情是莫过于最难办的事情是莫过于“拒绝客户提出的需求变更请求。客户会想当然地以为变更需求拒绝客户提出的需求变更请求。客户会想当然地以为变更需求是他的权利，因为他付钱给开发方。通常情况下开发方是不敢得罪客户的，但是无原那么是他的权利，因为他付钱给开发方。通常情况下开发方是不敢得罪客户的，但是无原那么地退让将使开发小组

25、陷入困境。地退让将使开发小组陷入困境。 2.7.2 2.7.2 建议建议建立建立“需求开发与管理标准，给出适宜的文档模板，采用方便的需求分析和管理工具。需求开发与管理标准，给出适宜的文档模板，采用方便的需求分析和管理工具。还要多请有经验的人来培训、传授实战经验。还要多请有经验的人来培训、传授实战经验。 制定应对需求变更的方法，例如：制定应对需求变更的方法，例如：(1)(1)双方签订需求变更管理协议双方签订需求变更管理协议;(2);(2)将重大需求变更延缓将重大需求变更延缓到下个软件版本中实现到下个软件版本中实现;(3);(3)让客户欠下人情。让客户欠下人情。 Page 112.8 常见问题分析

26、：软件设计常见问题分析：软件设计2.8.1 2.8.1 共性问题共性问题对于大局部软件机构而言，用户界面设计是弱项。国内绝大多数大学的计算机学科没有开对于大局部软件机构而言，用户界面设计是弱项。国内绝大多数大学的计算机学科没有开设人机工程学、美学、心理学这些必修课。由于学生们接受的教育几乎全是科学与技术，设人机工程学、美学、心理学这些必修课。由于学生们接受的教育几乎全是科学与技术，他们根本不知道怎样才能设计出易用、美观的用户界面，很多人甚至想都没有想过。当他他们根本不知道怎样才能设计出易用、美观的用户界面，很多人甚至想都没有想过。当他们毕业后真正参与软件产品开发时，只好凭着个人的经验与感觉设计

27、软件的用户界面，这们毕业后真正参与软件产品开发时，只好凭着个人的经验与感觉设计软件的用户界面，这样产生的界面往往得不到群众用户的认可。样产生的界面往往得不到群众用户的认可。 大局部软件机构都有一些技术出色的软件人员，他们在系统构架、数据库方面的设计能力大局部软件机构都有一些技术出色的软件人员，他们在系统构架、数据库方面的设计能力相当不错。但是很多人不愿意、不善于写系统设计报告，这不利于后续的软件开发和维护。相当不错。但是很多人不愿意、不善于写系统设计报告，这不利于后续的软件开发和维护。 软件设计应当软件设计应当“细到什么程度很难把握。太粗了的话，对后续开发工作的指导价值不高；细到什么程度很难把

28、握。太粗了的话，对后续开发工作的指导价值不高；反之倘假设太细的话，消耗时间就比较多，如果后面不断改进设计的话，前面的设计浪费反之倘假设太细的话，消耗时间就比较多，如果后面不断改进设计的话，前面的设计浪费太多。太多。 2.8.2 2.8.2 建议建议建立建立“软件设计标准，给出适宜的文档模板，采用方便的设计工具。软件设计标准，给出适宜的文档模板，采用方便的设计工具。 还要多请有经验的人来培训、传授实战经验。还要多请有经验的人来培训、传授实战经验。 Page 122.9 常见问题分析：编程与调试常见问题分析：编程与调试2.9.1 2.9.1 共性问题共性问题软件机构的大局部程序员的技能是合格的，但

29、是他们编写的程序风格差异较大，代码质量软件机构的大局部程序员的技能是合格的，但是他们编写的程序风格差异较大，代码质量有高有低。大多数软件机构没有编程标准，即使有的话，开发人员也没有很好地按标准编有高有低。大多数软件机构没有编程标准，即使有的话，开发人员也没有很好地按标准编程。程。相当多的程序员没有养成对所有代码进行相当多的程序员没有养成对所有代码进行“单步跟踪调试的习惯。单步跟踪调试的习惯。嫌单元测试很麻烦，懒得执行，却没有替代方案。嫌单元测试很麻烦，懒得执行，却没有替代方案。2.9.2 2.9.2 建议建议制定简单明了、重点突出的制定简单明了、重点突出的“编程标准，让团队遵照此标准编写程序。

30、编程标准，让团队遵照此标准编写程序。采用集成化的开发调试工具，提高编程质量和效率。采用集成化的开发调试工具，提高编程质量和效率。 Page 132.10 常见问题分析：软件测试常见问题分析：软件测试2.10.1 2.10.1 共性问题共性问题许多软件人员没有系统地学习过软件测试，搞不清楚各种测试的概念，例如单元测试、集许多软件人员没有系统地学习过软件测试，搞不清楚各种测试的概念，例如单元测试、集成测试、验收测试、黑盒测试、白盒测试、功能测试、性能测试等等，混为一谈，不知如成测试、验收测试、黑盒测试、白盒测试、功能测试、性能测试等等，混为一谈，不知如何下手。何下手。测试人员没有掌握有效测试的方法

31、，大多凭感觉测试，结果重复测试已经测试过的，那些测试人员没有掌握有效测试的方法，大多凭感觉测试，结果重复测试已经测试过的，那些深藏的深藏的bugbug却发现不了。客户在使用软件的过程中发现的却发现不了。客户在使用软件的过程中发现的bugbug比公司内部测试时发现的还多，比公司内部测试时发现的还多，不仅改错代价高，而且降低了客户对产品的满意度。不仅改错代价高，而且降低了客户对产品的满意度。团队没有采用有效的缺陷跟踪工具。测试人员发现团队没有采用有效的缺陷跟踪工具。测试人员发现bugbug时，口头告知有关人员或者记在时，口头告知有关人员或者记在WordWord、ExcelExcel文件中，修改文件

32、中，修改bugbug信息或者测试报告时非常麻烦。难以及时从信息或者测试报告时非常麻烦。难以及时从bugbug列表中找出规律，列表中找出规律，测试的效率比较低。测试的效率比较低。 2.9.2 2.9.2 建议建议建立建立“软件测试标准，采用方便的测试管理工具。软件测试标准，采用方便的测试管理工具。还要多请有经验的人来培训、传授实战经验。还要多请有经验的人来培训、传授实战经验。 Page 142.11 常见问题分析：软件维护常见问题分析：软件维护2.11.1 2.11.1 共性问题共性问题在维护期间，除了纠错性维护外，客户可能提出需求变更但是不支付费用，维护人员在维护期间，除了纠错性维护外，客户可

33、能提出需求变更但是不支付费用，维护人员对客户妥协，导致维护工作量增大、本钱增加。对客户妥协，导致维护工作量增大、本钱增加。如果是合同软件工程，用户对开发方的依赖性比较大，不愿意自己解决粗浅的问题，经常如果是合同软件工程，用户对开发方的依赖性比较大，不愿意自己解决粗浅的问题，经常叫开发方叫开发方“干这干那。开发方不敢得罪客户，导致开发方做了许多不属于维护的工作，干这干那。开发方不敢得罪客户，导致开发方做了许多不属于维护的工作，吃哑巴亏。吃哑巴亏。开发人员一边开发新工程，一边维护老工程。而维护为表达不出业绩，又影响了新工程的开发人员一边开发新工程，一边维护老工程。而维护为表达不出业绩，又影响了新工

34、程的进度，开发人员比较心烦。进度，开发人员比较心烦。 2.11.2 2.11.2 建议建议制定制定“软件维护标准，界定什么是软件维护标准，界定什么是“免费维护、什么是免费维护、什么是“有偿维护，以及相应的操有偿维护，以及相应的操作规那么，提高维护效率并且降低维护本钱。作规那么，提高维护效率并且降低维护本钱。 Page 152.12 常见问题分析：其它问题常见问题分析：其它问题2.12.1 2.12.1 技术技术 vs. vs. 市场市场许多开发人员喜欢技术研究和技术挑战。虽然嘴上说开发产品要以许多开发人员喜欢技术研究和技术挑战。虽然嘴上说开发产品要以“客户市场为中心客户市场为中心，但是在开发软

35、件的时候，却不知不觉以技术为中心，例如喜欢采用新技术、追求技术，但是在开发软件的时候，却不知不觉以技术为中心，例如喜欢采用新技术、追求技术上的完美。导致进度延误，本钱增加，甚至可能有质量风险。他们开发出来的软件在技术上的完美。导致进度延误，本钱增加，甚至可能有质量风险。他们开发出来的软件在技术上可能很先进，但是并不是用户所关心的。多数开发人员缺乏商业头脑，常常做出背离企上可能很先进，但是并不是用户所关心的。多数开发人员缺乏商业头脑，常常做出背离企业根本目标的事情。业根本目标的事情。企业领导应当重视这个问题，要经常性地向开发人员们灌输商业理念。让他们明白企业领导应当重视这个问题，要经常性地向开发

36、人员们灌输商业理念。让他们明白 “ “能够能够赚钱的技术才是好技术。在企业里，商业利益高于技术追求。赚钱的技术才是好技术。在企业里，商业利益高于技术追求。 2.11.2 2.11.2 工程经理的财务权工程经理的财务权国内大局部企业的工程经理有带头干活的权利和义务，他们对工程的进度和质量负最大责国内大局部企业的工程经理有带头干活的权利和义务，他们对工程的进度和质量负最大责任，但是没有财务权。大局部工程没有经费，即使有经费，也得由上级领导审批使用，不任，但是没有财务权。大局部工程没有经费，即使有经费，也得由上级领导审批使用，不能自己作主。有时团队加班干了不少活，工程经理却没有钱能自己作主。有时团队

37、加班干了不少活，工程经理却没有钱“意思意思，很没有面子。意思意思，很没有面子。没有财务权的工程经理，不是完整意义上的工程经理。没有财务权的工程经理，不是完整意义上的工程经理。企业不给工程经理财务权的初衷是为了控制本钱，防止工程经理乱花钱。但是实际上效果企业不给工程经理财务权的初衷是为了控制本钱，防止工程经理乱花钱。但是实际上效果适得其反。由于工程经理没有财务权，他们就不会关心本钱也不懂得如何控制本钱。因管适得其反。由于工程经理没有财务权，他们就不会关心本钱也不懂得如何控制本钱。因管理不成熟、工作效率不高、进度延误等问题导致理不成熟、工作效率不高、进度延误等问题导致“隐性本钱不断增加，钱在不知不

38、觉地隐性本钱不断增加，钱在不知不觉地流失。流失。企业领导应当给予工程经理企业领导应当给予工程经理“适当的财务权，只要确定工程财务制度并限定经费额度，适当的财务权，只要确定工程财务制度并限定经费额度，就不会造成失控。既让工程经理就不会造成失控。既让工程经理“有点小钱慰劳团队，有工作积极性；又让他真正重视有点小钱慰劳团队，有工作积极性；又让他真正重视本钱控制，并付诸实践。用本钱控制，并付诸实践。用“小量胡萝卜获得大回报。小量胡萝卜获得大回报。 Page 163. 中型企业的研发管理需求中型企业的研发管理需求3.1 3.1 需求特征需求特征必要性。如果软件机构只有数人或者十几个人，即使没有研发管理标

39、准，能力强的机构领必要性。如果软件机构只有数人或者十几个人，即使没有研发管理标准，能力强的机构领导一个人也能沉着指挥。当软件机构的人数超过导一个人也能沉着指挥。当软件机构的人数超过5050人后，如果还没有研发管理标准的话，人后，如果还没有研发管理标准的话，那么机构领导将会力不从心。人数越多，非标准化管理越容易产生混乱，迫使企业不得不那么机构领导将会力不从心。人数越多，非标准化管理越容易产生混乱，迫使企业不得不走标准化管理的路线，以降低管理代价和风险。走标准化管理的路线，以降低管理代价和风险。经济根底。建立标准化的研发管理是需要一定的投资的，例如咨询、培训、购置工具等等。经济根底。建立标准化的研

40、发管理是需要一定的投资的，例如咨询、培训、购置工具等等。小型软件机构通常没有钱去做这件事情，望洋兴叹。中型机构能够养活小型软件机构通常没有钱去做这件事情，望洋兴叹。中型机构能够养活5050200200人，表示它人，表示它们是有一定经济实力的，只要投资额适当而且产生的效益高于投资，那么中型机构一般都们是有一定经济实力的，只要投资额适当而且产生的效益高于投资，那么中型机构一般都愿意做这件事情。愿意做这件事情。 开展欲望。有些中型机构的领导雄心勃勃，高瞻远瞩，他们迫切希望提高研发管理能力从开展欲望。有些中型机构的领导雄心勃勃，高瞻远瞩，他们迫切希望提高研发管理能力从而提升整个企业的核心竞争力，产生源

41、源不断的推动力，推动企业持续开展壮大。他们对而提升整个企业的核心竞争力，产生源源不断的推动力，推动企业持续开展壮大。他们对研发管理的态度是主动的，而不是被动的。研发管理的态度是主动的，而不是被动的。 3.2 3.2 费用估算费用估算国内一些大型国内一些大型ITIT企业建立了完整的研发管理体系，投资巨大。例如上海贝尔、华为分别请企业建立了完整的研发管理体系，投资巨大。例如上海贝尔、华为分别请HPHP、IBMIBM建立研发管理体系，投资额分别到达数千万元、上亿元。这种投资额是中型企业望建立研发管理体系，投资额分别到达数千万元、上亿元。这种投资额是中型企业望尘莫及的。在研发管理方面，中型企业无法效仿

42、大型企业的做法。国内中型软件机构对研尘莫及的。在研发管理方面，中型企业无法效仿大型企业的做法。国内中型软件机构对研发管理的投资额大约在数万元至元数十万元。这点发管理的投资额大约在数万元至元数十万元。这点“小钱根本无法引入小钱根本无法引入IBMIBM、HPHP、RationalRational等公司的研发管理解决方案。等公司的研发管理解决方案。 大局部国内中型软件机构需要的是大局部国内中型软件机构需要的是“轻量级的研发管理解决方案，包括咨询、培训、购轻量级的研发管理解决方案，包括咨询、培训、购置工具，总费用在置工具，总费用在5 5万元至万元至2020万元之间比较适宜。万元之间比较适宜。 Page

43、 174. 根底方法论介绍根底方法论介绍CMM4.1 4.1 根本概念根本概念产品是在过程中研制出来的。一般地，好的过程才可能得到好的产品，而差的过程只会得产品是在过程中研制出来的。一般地，好的过程才可能得到好的产品，而差的过程只会得到差的产品。提高软件过程能力的实践通称为软件过程改进到差的产品。提高软件过程能力的实践通称为软件过程改进Software Process Software Process ImprovementImprovement。软件过程改进的根本目的是：提高质量、提高生产率并且降低开发本钱。软件过程改进的根本目的是：提高质量、提高生产率并且降低开发本钱。 CMM/CMMIC

44、MM/CMMI是世界范围内用于衡量软件过程能力的事实上的标准，同时也是软件过程改进最是世界范围内用于衡量软件过程能力的事实上的标准，同时也是软件过程改进最权威的指南。权威的指南。 CMMCMM等级评估：从狂热回归理性。现在软件业界普遍关注的是：企业如何以比较低的代价有等级评估：从狂热回归理性。现在软件业界普遍关注的是：企业如何以比较低的代价有效地提高软件过程能力。效地提高软件过程能力。CMMCMM等级评估那么退居次要地位。等级评估那么退居次要地位。 4.2 CMM4.2 CMM的盲区和常见应用问题的盲区和常见应用问题CMMCMM本身不谈如何赚钱的问题。它假设了美好的前提条件，即企业有充足的人员

45、、资金、时本身不谈如何赚钱的问题。它假设了美好的前提条件，即企业有充足的人员、资金、时间从事软件过程改进，当软件过程能力提高了，那么产品的质量、生产率自然上去了同间从事软件过程改进，当软件过程能力提高了，那么产品的质量、生产率自然上去了同时本钱也下降了，企业自然能够获取更多的利润。软件过程改进对企业经济效益的奉献时本钱也下降了，企业自然能够获取更多的利润。软件过程改进对企业经济效益的奉献是间接的，从投入到产出，时间相比照较长。是间接的，从投入到产出，时间相比照较长。 企业领导当然想把资源用在企业领导当然想把资源用在“刀刃上，即赚钱最多最快的地方。当软件过程改进和其它刀刃上，即赚钱最多最快的地方

46、。当软件过程改进和其它直接赚钱的事情直接赚钱的事情“发生资源冲突时，人们只好发生资源冲突时，人们只好“拆东墙，补西墙，往往减少软件过程拆东墙，补西墙，往往减少软件过程改进的资源。改进的资源。小结：对于软件过程改进而言，小结：对于软件过程改进而言，CMM/CMMICMM/CMMI和和ISOISO等等都是用来参考的，而不是用来迷信的。等等都是用来参考的，而不是用来迷信的。企业在参考业界推荐的标准或标准时，要舍弃那些听起来很先进但是对本企业无益处的东企业在参考业界推荐的标准或标准时，要舍弃那些听起来很先进但是对本企业无益处的东西，只选取对企业有实用价值的东西。西，只选取对企业有实用价值的东西。 Pa

47、ge 185. 根底方法论介绍根底方法论介绍PMBOK5.1 5.1 根本概念根本概念工程管理协会工程管理协会PMIPMI是目前全球影响最大的工程管理专业机构，该机构的工程管理专家认是目前全球影响最大的工程管理专业机构，该机构的工程管理专家认证证PMPPMP被广泛认同。被广泛认同。PMIPMI的突出奉献是总结了一套工程管理知识体系的突出奉献是总结了一套工程管理知识体系PMBOKPMBOK。 PMBOKPMBOK把工程管理知识划分为九个知识领域：综合管理、范围管理、时间管理、本钱管理、把工程管理知识划分为九个知识领域：综合管理、范围管理、时间管理、本钱管理、质量管理、人力资源管理、沟通管理、风险

48、管理和采购管理。每个知识领域包括数量不等质量管理、人力资源管理、沟通管理、风险管理和采购管理。每个知识领域包括数量不等的工程管理过程。的工程管理过程。 5.2 PMBOK5.2 PMBOK和和CMM/CMMICMM/CMMI比照简评比照简评 CMM/CMMICMM/CMMI论述的工程管理方法仅仅适用于软件工程，但是不适用于其它行业的工程管理。论述的工程管理方法仅仅适用于软件工程，但是不适用于其它行业的工程管理。PMBOKPMBOK论述的方法适用于任何行业的工程管理，但是对软件工程管理而言，论述的方法适用于任何行业的工程管理，但是对软件工程管理而言，PMBOKPMBOK的针对性的针对性不够强。不

49、够强。 CMM/CMMICMM/CMMI不仅论述软件工程管理，而且论述整个机构的软件研发管理。不仅论述软件工程管理，而且论述整个机构的软件研发管理。PMBOKPMBOK的方法局限于的方法局限于工程管理，对于企业研发管理那么不够用。工程管理，对于企业研发管理那么不够用。 CMM/CMMICMM/CMMI根本上不谈根本上不谈“本钱管理和本钱管理和“人力资源管理，它先假设机构有充足的资金和人人力资源管理，它先假设机构有充足的资金和人力资源，通常不切合企业实际情况。因此力资源，通常不切合企业实际情况。因此PMBOKPMBOK的的“本钱管理和本钱管理和“人力资源管理可以弥人力资源管理可以弥补补CMM/C

50、MMICMM/CMMI的缺乏。的缺乏。 建议：对于软件机构研发管理或者软件工程管理，采用建议：对于软件机构研发管理或者软件工程管理，采用CMM/CMMICMM/CMMI为主导的方法论，并结合为主导的方法论，并结合PMBOKPMBOK的知识，取长补短。的知识，取长补短。 Page 196. 根底方法论介绍敏捷开发根底方法论介绍敏捷开发6.1 6.1 根本概念根本概念20012001年，为了解决许多公司的软件团队陷入不断扩大的过程泥潭，一批业界专家概括出了年，为了解决许多公司的软件团队陷入不断扩大的过程泥潭，一批业界专家概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原那么，他们

51、称自己为一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原那么，他们称自己为敏捷联盟敏捷联盟Agile AllianceAgile Alliance。他们起草了一个旨在鼓励更好的软件开发方法的宣言，称。他们起草了一个旨在鼓励更好的软件开发方法的宣言，称为敏捷联盟宣言为敏捷联盟宣言The Manifesto of the Agile AllianceThe Manifesto of the Agile Alliance。然后在该宣言根底上制定了。然后在该宣言根底上制定了1212条原那么用于指导实践。该宣言和条原那么用于指导实践。该宣言和1212条原那么是敏捷软件开发方法的核心。条原那么

52、是敏捷软件开发方法的核心。 6.2 6.2 我们的观点我们的观点敏捷软件开发的宣言和敏捷软件开发的宣言和1212条原那么并非普遍适用。条原那么并非普遍适用。 敏捷开发方法表达了敏捷开发方法表达了“简单、快速、实用的软件开发思想，它不是成熟的理论、也不是简单、快速、实用的软件开发思想，它不是成熟的理论、也不是事实上的标准不象事实上的标准不象CMM, PMBOKCMM, PMBOK那样具有严密的理论体系，被企业广泛接受。即使人们那样具有严密的理论体系，被企业广泛接受。即使人们认同某些原那么，但是不同的人往往有不同的理解，实践差异很大。认同某些原那么，但是不同的人往往有不同的理解，实践差异很大。 敏

53、捷开发方法对于提高个人、小型团队的工作效率是很有帮助的如果用对了的话。但敏捷开发方法对于提高个人、小型团队的工作效率是很有帮助的如果用对了的话。但是企图用它指导大型、中型软件机构的研发管理是有很高风险的，它的某些主张是局部观是企图用它指导大型、中型软件机构的研发管理是有很高风险的，它的某些主张是局部观点而不是全局观点，如果把握不好分寸的话可能导致整体混乱，而点而不是全局观点，如果把握不好分寸的话可能导致整体混乱，而“整体的混乱会淹没整体的混乱会淹没“局部的好处。局部的好处。我们研制的我们研制的“精简并行过程精简并行过程SPPSPP的理论根底是的理论根底是“经典软件工程、经典软件工程、CMMCM

54、M、PMBOKPMBOK。为了。为了提高效率，在局部地方借鉴了提高效率，在局部地方借鉴了“敏捷软件开发的思想，用于裁减过于冗长、笨重的过程敏捷软件开发的思想，用于裁减过于冗长、笨重的过程标准。标准。 Page 206. 根底方法论介绍敏捷开发根底方法论介绍敏捷开发敏捷软件开发的敏捷软件开发的1212条原那么：条原那么：1 1我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 2 2即使到了开发的后期，也欢送改变需求。敏捷过程利用变化来为客户创造竞争优势。即使到了开发的后期，也欢送改变需求。敏捷过程利用变化来为客户

55、创造竞争优势。3 3经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。隔越短越好。 4 4在整个工程开发期间，业务人员和开发人员必须天天都在一起工作。在整个工程开发期间，业务人员和开发人员必须天天都在一起工作。 5 5围绕被鼓励起来的个人来构建工程。给他们提供所需的环境和支持，并且信任他们能围绕被鼓励起来的个人来构建工程。给他们提供所需的环境和支持，并且信任他们能够完成工作。够完成工作。 6 6在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。在团队内部，最具有效果并

56、富有效率的传递信息的方法，就是面对面的交谈。 7 7可以工作的软件是首要的进度度量标准。可以工作的软件是首要的进度度量标准。 8 8敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。恒定的开发速度。 9 9不断地关注优秀的技能和好的设计会增强敏捷能力。不断地关注优秀的技能和好的设计会增强敏捷能力。 1010简单简单把无需做的工作最大化的艺术把无需做的工作最大化的艺术是最根本的。是最根本的。 1111最好的构架、需求和设计出于自我组织的团队。最好的构架、需求和设计出于自我组织的团队。

57、 1212每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。的行为进行调整。 Page 217. 根底方法论介绍根底方法论介绍RUP7.1 7.1 根本概念根本概念RUPRUPRational Unified ProcessRational Unified Process是是RationalRational公司推出的软件过程模型，它是软件业界迄公司推出的软件过程模型，它是软件业界迄今为止商品化最成功的软件过程模型。今为止商品化最成功的软件过程模型。RUPRUP的近千页文档可以从的近千页

58、文档可以从RationalRational公司的网站公司的网站 :/ rational :/ rational 下载，下载，RUP 2000RUP 2000中文版也已经发布。中文版也已经发布。RUPRUP的主要特征是：的主要特征是：采用迭代的、增量式的开发过程。采用迭代的、增量式的开发过程。采用采用UMLUML语言描述软件开发过程。语言描述软件开发过程。有一系列功能强大的软件工具支撑有一系列功能强大的软件工具支撑RationalRational公司的软件产品。公司的软件产品。 7.2 7.2 我们的观点我们的观点RUPRUP及其配套软件工具是重量级的软件研发管理解决方案，它面向的是高端用户，对

59、用户的及其配套软件工具是重量级的软件研发管理解决方案，它面向的是高端用户，对用户的财力、开发和管理能力要求都很高：财力、开发和管理能力要求都很高：首先，用户得有钱买首先，用户得有钱买RationalRational的软件工具，否那么光有的软件工具，否那么光有RUPRUP方法论如同纸上谈兵。方法论如同纸上谈兵。 如果要使用如果要使用RUPRUP方法，人们得先熟悉方法，人们得先熟悉UMLUML，否那么除了，否那么除了RUPRUP模型图之外你根本上看不懂细节内模型图之外你根本上看不懂细节内容。可是在普通企业里，大局部人尤其是领导和管理人员不熟悉容。可是在普通企业里，大局部人尤其是领导和管理人员不熟悉

60、UMLUML。学习。学习UMLUML和和RUPRUP的的难度远高于难度远高于CMMCMM和和PMBOKPMBOK。工程经理和开发组长要有能力控制迭代过程，否那么迭代式开发就变得混乱无序和漫无边工程经理和开发组长要有能力控制迭代过程，否那么迭代式开发就变得混乱无序和漫无边际际 RUPRUP及其配套的软件工具根本上不适合于国内中型和小型软件机构。及其配套的软件工具根本上不适合于国内中型和小型软件机构。 Page 228. 面向企业的软件研发管理解决方案面向企业的软件研发管理解决方案8.1 目标目标帮助企业建立适合于自身需求的软件研发管理标准，并部署配套的软件工具；帮助企业建立适合于自身需求的软件研

61、发管理标准，并部署配套的软件工具；通过充分的培训，帮助员工们掌握提高质量、提高生产率、降低本钱的方法；通过充分的培训，帮助员工们掌握提高质量、提高生产率、降低本钱的方法；协助企业依据标准开展软件研发和管理工作，持续提升能力。协助企业依据标准开展软件研发和管理工作，持续提升能力。 8.2 工作流程工作流程面向企业的软件研发管理解决方案Page 238. 面向企业的软件研发管理解决方案面向企业的软件研发管理解决方案 8.3 集成化研发管理方法集成化研发管理方法Simplified Parallel Process, SPPPage 248. 面向企业的软件研发管理解决方案面向企业的软件研发管理解决

62、方案8.4 内容和时间内容和时间1.1.调查分析问题调查分析问题对企业研发管理的能力现状进行调查与分析，调查内容要覆盖所有工作领域（过程域），总结“强项”和“弱项”，给出建议。 预计时间跨度为2个月，乙方到甲方现场工作和服务约20工作日。日程安排由双方共同商定。2.制定研发管理规范制定研发管理规范 绘制研发管理的总体流程图；绘制组织结构图，并确定角色职责表 ；定义每个过程域的规范（目的，关键活动和流程，工作成果） 3.选用合适的工具选用合适的工具选择并部署合适的开发工具和管理工具。推荐管理工具是Future和CVS。含1年免费维护和升级服务4.4.充分必要的培训充分必要的培训为研发管理流程中的

63、所有人员提供充分必要的培训，包括软件工程、项目管理等，让人们掌握提高软件质量、提高生产率、降低成本的方法。 5.5.执行、监督与反馈执行、监督与反馈协助客户依据规范开展软件研发和管理工作。跟踪试点项目的执行情况，及时解答执行过程中遇到的问题，持续地提升客户的软件研发能力。 乙方提供一年的售后服务。解决方案的内容视企业的实际情况而定。解决方案的内容视企业的实际情况而定。Page 258.5 相关著作Page 269. 集成化软件工程管理系统集成化软件工程管理系统Future9.1 什么是什么是FutureFuture是基于是基于Web的集成化工程管理系统，目标是的集成化工程管理系统，目标是“让工

64、程管理变得简单有效。让工程管理变得简单有效。Future的主要客户是国内中型软件机构，主要最终用户是研发主管、工程经理、的主要客户是国内中型软件机构，主要最终用户是研发主管、工程经理、软件开发人员、测试人员和质量管理人员等等。详见软件开发人员、测试人员和质量管理人员等等。详见 介绍。介绍。Page 27Page 289. 集成化软件工程管理系统集成化软件工程管理系统Future9.2 Future 的特色的特色物美价廉、富有成效的集成化工程管理工具物美价廉、富有成效的集成化工程管理工具 Future将将企企业业研研发发管管理理过过程程中中最最常常用用的的工工具具全全部部集集成成于于Web环环境

65、境，并并与与方方法法论论“精精简简并并行行过过程程SPP配配套套，相相互互支支持持。企企业业不不必必购购置置多多个个分分立立的的管管理理工工具具，防防止止了了管管理理工工具具之之间间不不兼兼容容、数数据据孤孤立立的的问问题题。不不仅仅提提高高了了研研发发管管理理效效率率，而而且且大大大大降低了购置工具的本钱。降低了购置工具的本钱。Future软软件件不不仅仅可可以以为为企企业业建建立立完完备备的的研研发发管管理理数数据据库库，而而且且帮帮助助企企业业领领导导对对所所有有工工程程的的进进度度、工工作作量量、本本钱钱、质质量量进进行行数数据据分分析析，为为研研发发绩绩效效考考核核提提供供客客观观依

66、依据。据。易用美观的用户界面易用美观的用户界面Future软软件件的的系系统统视视图图、工工程程视视图图、个个人人视视图图、领领导导视视图图、文文档档视视图图、论论坛坛视视图图具具有有高高度度一一致致、易易用用美美观观的的用用户户界界面面。用用户户使使用用Future，可可以以轻轻松松地地完完成成研研发发工工程的管理工作。这源于我们对用户特征的深刻理解，和对用户界面的精心设计。程的管理工作。这源于我们对用户特征的深刻理解，和对用户界面的精心设计。 容易扩展、与流行软件兼容容易扩展、与流行软件兼容Future 3.0的所有页面数据可以导出到的所有页面数据可以导出到Excel文件；文件； 后续版本

67、可以导入、导出后续版本可以导入、导出 MS Project数据；数据；后续版本可以访问配置管理软件后续版本可以访问配置管理软件CVS的文件库；的文件库；后续版本将集成更多的工具，如人力资源管理系统、客户关系管理系统等。后续版本将集成更多的工具，如人力资源管理系统、客户关系管理系统等。 为为了了方方便便地地和和企企业业现现有有的的管管理理系系统统交交互互信信息息，我我们们提提供供Web Service接接口口，并并帮帮助用户对助用户对Future进行二次开发。进行二次开发。 Page 299. 集成化软件工程管理系统集成化软件工程管理系统Future9.3 Future 3.0的运行环境的运行环

68、境效劳器端效劳器端 操作系统：操作系统：Windows 2000 / 2003 / XP，或，或Linux 数数 据据 库：缺省采用库：缺省采用My SQL 4.0.* ，兼容，兼容Oracle, SQL ServerJAVA运行环境：运行环境：J2SE 1.4以上版本以上版本Web效劳器：效劳器：Tomcat 4.1以上版本以上版本内存：建议至少内存：建议至少512M客户端的配置客户端的配置操作系统：操作系统：Windows 2000 / 2003 / XP浏浏 览览 器：器：IE 6.0以上版本以上版本内存：建议至少内存：建议至少256MPage 309.4 Future 3.0功能例如系

69、统视图立项结项功能例如系统视图立项结项 Page 319.5 Future 3.0功能例如工程视图任务管理功能例如工程视图任务管理Page 329.6 Future 3.0功能例如工程视图功能例如工程视图Gantt图图Page 339.7 Future 3.0功能例如工程视图缺陷跟踪功能例如工程视图缺陷跟踪Page 349.8 Future 3.0功能例如工程视图缺陷统计图功能例如工程视图缺陷统计图Page 359.9 Future 3.0功能例如文档视图功能例如文档视图Page 369.10 Future 3.0功能例如领导视图人员工作统计功能例如领导视图人员工作统计 Page 379.11 Future 3.0功能例如个人视图个人任务功能例如个人视图个人任务 Page 389.12 Future 3.0功能例如论坛视图发贴回贴功能例如论坛视图发贴回贴