1. 版本控制技术及工具
版本控制是程序开发、管理必不可少的工具，特别是在多人协作的团队中，适宜的版本控制工具可以提高开发效率，消除很多由代码版本带来的问题。通过使用版本控制技术及工具，可以确保在软件项目开发中不同的开发人员所涉及的同一文档都得到正确的更新。
1.1 常用版本控制工具
1. CVS (Concurrent Versions System)
CVS 是一款开放源代码软件，其功能强大、跨平台、支持并发版本控制而且免费，所以它在中小型软件企业中得到广泛使用。CVS最大的遗憾就是缺少相应的技术支持，许多问题的解决需要自己寻找资料，甚至是研究源代码。CVS是一个典型的服务器/客户端软件，支持远程管理，项目组分布开发时一般都采用CVS做代码及文档的版本控制。
2. SVN (SubVersion)
SVN是对CVS的缺点进行改进产生的版本控制工具,相比于CVS而言，SVN更为简单易用，且SVN有其特定平台的客户端工具。如TortoiseSVN，是为windows外壳程序集成到windows资源管理器和文件管理系统的SVN客户端，使用相当方便。
3. Clearcase
Clearcase是Rational公司一款重量级的软件配置管理工具。与CVS和SVN不同的是，Clearcase涵盖的范围包括版本控制、建立管理、工作空间管理和过程控制。Clearcase贯穿于整个软件生命周期，支持现有的绝大多数操作系统，但它的安装、配置、使用相对较复杂，需要进行团队培训。
2. 软件测试技术及工具
随着软件应用领域越来越广泛，软件质量的优劣也日益受到人们的重视，软件质量保证能力的强弱成为了直接影响业界发展与生存的重要因素。软件测试作为软件质量保证的主要内容，是一个成熟软件企业的重要组成部分，它是软件生命周期中一项非常重要且复杂的工作，对软件可靠性保证具有极其重要的意义。
2.1 软件测试技术
软件测试的目的是对软件质量或可接受性做出判断，发现软件开发过程存在的问题。在实际的项目开发流程中，经常用到的软件测试方法有：单元测试，集成测试，功能测试，验收测试等。
1. 单元测试
单元测试主要是开发者针对开发过程中程序内部的函数、类、变量等数据进行正确性测试。开发人员根据需求，在经过详细设计之后开始着手编写代码。一般情况下，每完成一个函数（类）之后，就要进行单元测试，以验证编写的函数能完成详细设计说明中的功能。目前常用的单元测试工具有Junit测试、C++Test等等。
2. 集成测试
集成测试是在单元测试的基础上，将所有模块按照详细设计的要求组装成子系统或系统，进行集成测试。与单元测试侧重单个函数（类）功能的正确性不同的是，集成测试侧重于模块间的接口正确性以及集成后的整体功能的正确性。
3. 功能测试
功能测试即软件的黑盒测试。单元测试和集成测试保证了开发是可以正常运行，执行起来的效率是最高的，但无法保证需求所需的功能是正确实现的。根据用户需求设计的功能测试（黑盒测试），可以按照严格的按照需求说明，测试新开发的系统是否完全符合用户的要求以及是否符合实际的操作流程和业务逻辑。
4. 验收测试
在验收测试中，相关的用户根据需求说明文档对系统进行测试和验收，决定是否接收系统，它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试的目的是确保系统已经准备就绪，可以投入日常使用，让最终用户使用需求中描述的功能。
2.2 软件测试工具
1. Junit测试
Junit测试是目前J2EE平台上最为流行的单元测试工具，它是程序员测试，即所谓的白盒测试。在Junit测试中，程序员知道被测试的软件如何完成功能和完成什么样的功能，因此在继承了TestCase后就可以用Junit进行自动测试。
2. C++ Test测试
C++ Test是Parasoft公司出品的一个针对C/C++源代码进行自动化单元测试的工具，它可以对源代码进行三种测试：白盒测试、黑盒测试以及回归测试。鉴于C/C++在嵌入式领域的广泛应用，Parasoft同时为嵌入式程序提供了相应的版本，支持Eclipse和Visual Studio，可以批处理执行。
3. WinRunner测试
Winrunner工具用于功能性测试，最主要的功能是自动重复执行某一固定的测试过程。它记录下手工测试的一系列操作，在环境相同的情况下重放，检查程序在相同的环境中有无异常的现象或与实际结果不符的地方。
4. LoadRunner测试
LoadRunner是一种预测系统行为和性能的工业标准级压力测试工具，近几年来一直是软件压力测试的首选工具。它可以模拟成千上万的并发操作，对应用系统、Web Service、Web服务器、数据库等进行压力和性能测试，兼容Window和Unix操作系统。
3. 文档管理技术
项目文档管理，是指在一个项目开发进程中将提交的文档进行收集管理的过程。通常，文档管理在项目开发中不是很受重视，当发现其重要性时，往往为时已晚，整个项目可能因此变得管理混乱，问题产生后无据可查。文档管理对于一个项目的顺利进行有着至关重要的作用，其关键性不容忽视。
3.1 文档管理技术
软件项目中的文档是用来记录、描述、展示软件项目开发过程中一系列信息的处理过程，它描述和规定了软件项目开发的每一个细节，使用软件的操作命令，对产品使用过程中意见及产品缺陷、质量等方面的说明。
文档的编写需要了解和遵循文档的行业标准。现有软件开发中常见的文档种类如下：
1. 开发文档
这类文档是在软件项目开发过程中，体现了软件开发人员前一阶段工作的成果，同时又是后一阶段工作的依据。这类文档包括可行性研究报告、软件项目开发计划、软件需求规格说明、系统规格说明书、软件功能说明书和数据字典等。
2. 管理文档
这类文档是在软件项目开发过程中，由软件开发人员制定的需提交管理部门的一些工作计划、工作方案和工作报告。通过阅读这些文档，管理人员能够了解软件项目开发活动安排、进度、资源使用等情况。这类文档包括项目开发计划、测试计划、测试方案、开发进度报告和项目总结报告等。
3. 用户文档
这类文档是软件开发人员为使用该软件的网点经办人员准备的有关该软件产品使用、操作的资料，主要是操作手册及新功能介绍方面的文档。
4. 软件建模工具
随着软件开发规模越来越大，面向对象分析与设计的优势突显，软件开发建模在公司项目开发中呈现越来越频繁的趋向。开发中常用的软件建模技术有两种，UML建模以及数据库建模，前者作为一种可视化建模语言，主要用于面向对象模型的分析与设计；后者用于数据库的逻辑设计，生成的是项目数据库的实体关系图。
4.1 常用的软件建模工具
1. Rational Rose
Rational Rose是一款强大的UML建模工具，它使改进和维护设计、从模型生成报表、在平行协作环境中与他人共同进行建模工作变得十分方便。同时，作为一款优秀的分析和设计工具，Rose具有强大的正向和逆向工程能力。正向工程指的是由设计产生代码，逆向工程指由代码归纳出设计，Rose可以通过逆向工程对历史系统做出分析，然后进行改进，再通过正向工程产生新的系统代码，这样的设计方式称之为再工程。
2. Visio
Visio是目前国内用得最多的Case工具，可以用于常见的case设计及UML建模。它提供了日常使用中的绝大多数框图的绘画功能(包括信息领域的各种原理图，设计图)，同时提供了部分信息领域的实物图。Visio的优势在于使用方便，安装后的Visio既可以单独运行，也可以在Word中作为对象插入，与Word集成良好。Visio支持UML的静态和动态建模，对UML的建模提供了单独的组织管理。
3. PowerDesigner
简练实用的建模工具，既是数据库建模传统的优秀工具，也可以用于UML建模。PowerDesigner在数据库建模方面功能强大，使用非常方便，自8.0版本后支持逆向工程、再工程，同时开始支持UML建模的UseCase/Sequence/Class视图。
4. ER/Studio
另外一款常用的数据库建模工具，是一款模型驱动的数据结构管理和数据库设计产品。与PowerDesigner相比更为精简，且同样支持逆向工程及再工程，在数据库兼容性以及UML建模上与PowerDisigner有一定差距。
5. 软件进度管理：软件开发周期估算
软件开发周期估算是IT人员经常提到的一个概念，那么究竟什么是软件开发周期估算呢?我们可以把它定义如下：根据软件的开发内容、开发工具、开发人员等因素对需求调研、程序设计、编码、测试等整个开发过程所花费的时间做的预测。在这个定义中，“预测”两个字非常关键，它突出体现了估算的含义，同时也隐含表明了结果的不确定性。有效的软件开发周期估算在软件开发中是非常困难的工序之一，之所以说困难，是因为软件开发所涉及的因素不仅多而且异常复杂，即便是及其类似的软件项目也不能完全照搬，在估算的把握上有一定难度。估算也是软件开发中很重要的一个环节，如果低估项目周期会造成人力低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算，为完成项目不得不赶工，影响项目质量，甚至导致项目失败。项目周期估计过长表面看来影响不大，但是实际上也会带来成本估计过高，人力资源利用不充分效率低下的后果。无论哪种情况对于项目经理控制整个项目都会带来很大影响，周期估算如同盖楼房中打地基，是后续工作的基础，它完成质量的好坏所带来的影响会贯穿整个项目，由此可见开发周期正确估算的重要性。
2.国内外软件估算比较
国内软件开发的管理目前正逐步向规范化发展，但是在开发周期的估算上绝大部分还是处于手工作坊的状态。所谓的手工作坊指两个方面，一方面是管理人员意识上没有认识到估算的重要性，认为估算就是一个大概的估计，很多还受限于商业行为，比如为了签订合同而不惜减少开发工作量却未经任何评审；另一方面也没有专门的工具来辅助估算，或者说没有专门对它进行研究。一个软件开发周期究竟要多长基本上是依靠经验来判断，不同经验的人估算出的周期相差很大，而更糟糕的是这种开发周期的判断由于完全凭借经验使得不同意见的人之间很难沟通，因为谁都没有确切的量化标准来支持自己的判断，最终的结果往往是以“专家”的估算为准。这就有些类似于中式烹调，放多少作料没有依据，一般都是“少许”，这个“少许”靠的就是经验，高级厨师和新手根据这个量炒出的菜味道可能差得很远；实际上国内的软件开发需要的正是定量估算，这样做不仅规范而且精确，十分有助于软件事业的健康发展以及与国际接轨。
国外发达国家在软件估算上比国内要成熟的多，不仅有很多先进方法比如代码行估算法、功能点估算法、人力估算法，而且形成了专业化的估算工具来辅助这项工作，比如微软公司开发的项目管理工具软件Project，加拿大Software Productivity Center Inc.公司开发的Estimate，都是比较成熟的估算辅助工具。Project采用了自下而上的估算法，Estimate更是属于专业化工具，包含常用的各种估算方法、校正方法，使用了Putnam Methodology、Cocomo II和 Monte Carlo Simulation几种成熟算法，估算结果除了项目花费时间、人力，还包括十几种分析报告以及模拟发散图、计划编制选项图、人力图、预计缺陷图、缺陷方差图等等，从各种不同角度辅助管理人员进行分析。
采用辅助工具对软件开发周期进行估算具有明显的优势，这些辅助工具是在大量不同类型项目数据研究的基础上总结开发出来的，采用的算法、估算的方法已经很成熟，估算结果的准确性有保障，由于这种估算是可以量化的，并非依据个人经验直接得出一个结果，在结果的评审上有据可依。长期依靠工具辅助估算可以将大量项目的数据和估算结果积累形成历史经验库，知识成果得以保存，便于以后利用。
3. 软件估算中的因素探讨
软件开发是一项非常复杂的工程，不仅包含需求分析、设计、编码、测试、实施、维护等完整的过程，还涉及到开发工具、开发人员、项目管理、风险等众多因素，不同因素对估算产生的影响不尽相同，在进行软件估算时（包括利用工具辅助估算）必须考虑到这些方面，否则最终结果就会和实际结果有很大的偏差，影响项目控制，以下对其中几个常见的因素做一些探讨。
3.1估算与软件规模
软件规模通常指的是软件的大小，这可以通过不同的方式来描述，比如程序代码行的长度、功能函数的数量、数据库中表的数量、数据库的大小等等。一般而言软件规模越大，所花费的开发周期就越长，但这并不是一个简单的线形函数关系，下表详细列举了实际开发中的一些数据，开发平台为Lotus Domino/Notes。
表一
单个模块的开发周期
序号 模块 开发周期（中级程序员） 代码行长度 数据库大小(无数据)
1. 办事指南 0.25人月 300 1170K
2. 名片簿 0.25人月 300 1039K
3. 合同管理 0.25人月 460 2110K
4. 物控管理 0.5人月 850 2560K
5. 组织机构 0.5人月 900 1318Khttp://www.mypm.net
6. 流程管理 0.8人月 1000 2304K
7. 公告板 0.5人月 1400 2560K
8. 人事管理 1人月 1800 3840K
9. 公文管理 1.8人月 2500 2304K项目管理者联盟文章，深入探讨。
10. 事务审批 1.5人月 3750 2110K
11. 考勤管理 1.8人月 4800 3840K
12. 资源管理 1.8人月 5800 3840K
13. 会议管理 2.5人月 11000 4608K
表二http://blog.mypm.net
软件项目的开发周期
软件项目 开发周期 包含的模块 备注http://www.mypm.net
某政府客户 3个人月 10个 定制开发量较小
某媒体客户 6个人月 17个 有3个模块完全重新开发
某金融客户 10个人月 14个 80%完全重新开发
某保险客户 16个人月 18个 完全重新开发
从表一中可以看出，模块的代码行越长，开发周期就越长，对同一开发工具而言基本是一个线形关系，但其中也要考虑代码重用问题，比如一个模块代码很长，但是可能包含了很多公用函数，那么在估算时就应适当减少代码行数量，表中会议管理就是个例子，这个模块的代码行超过一万行，但其中公共函数很多，去除此因素，真正的代码行在9000行左右。
表二是软件项目的实际开发周期（不考虑系统实施），从普通意义上说软件项目中包含的功能模块越多、越复杂，或者说软件越大开发周期增长的就越快，这个时间绝不是模块开发时间的简单叠加，因为模块功能数量的增加直接带来了软模块间相互关联度、复杂度的成倍增加，这就直接导致了在需求、设计等阶段需要花费更多的时间，这比单独考虑一个模块复杂的多。在表二中随着模块数量增加，开发周期增加不是特别明显，这是因为产品化程度高所引起的，由于相当数量的模块可以完全重用，实际开发量大大减少，最后一个例子完全重新开发，开发周期就长的多。
在实际进行软件开发周期估算的时候，软件规模肯定是首先考虑的因素，根据我们上面所讨论的情况，在考虑软件规模时一定要去除可重用的部分，由于当今软件在设计上很重视这点，所以这部分会占相当的比重。另外软件功能之间的关联所造成的复杂性必须足够重视，这样在估算上就不会产生重大偏差。
3.2估算与项目风险
任何一个项目都或多或少存在风险，软件项目开发过程中也避免不了这种情况而且有这类项目自己的特点，最常见的风险有以下几种：技术风险，项目技术难度很大，花费的时间超过原先的估计；客户风险，客户需求不定，增加需求，组织协调不畅；人员风险，开发人员突然更换、离职；管理风险，项目经理管理不善、决策失误。对于风险控制，在项目管理中通常是提前做风险分析和预测，制定风险应对措施，这样在风险真的来临时不至于措手不及，提高整个项目的可控性。
软件项目的潜在风险对于开发周期的影响在很多情况下是非常大的，当然好的项目控制会最大限度的减少这种影响，绝对避免是不可能的，所以在开发周期估算时项目风险应该适当考虑，尤其是技术风险和客户风险。
技术风险主要来自于软件本身的技术难度，如果对于一套成熟的产品，定制开发的技术风险相对非常小，因为重要的技术已经成型，客户也很少有新的能带来高难度技术问题的需求，这种风险可以不予考虑。但是对于完全重新开发的项目，或是研发类的项目，技术风险必须特别重视，其中应该考虑的细节主要包括下面几个。
开发平台，是否能适合本项目所涉及的软件开发、能否满足最终的需求，平台的错误选择将导致庞大的开发工作量，即便满足了用户需求也可能造成系统效率低下，扩展性差的致命问题，软件可能会很快被淘汰。功能实现难度，在切实了解需求的基础上要仔细分析采用的开发工具能否实现其中的难点，是否会耗费大量时间。
在实际估算中，建议技术难度分为十级，每一级在初次估算的代码行上增加10%，最终估算代码长度=初始估算代码长度×(1+0.1×n)。假设模块A的初次估计代码行为15000行，但考虑技术难度高的风险，设定技术难度级别为二级，最终代码行的估算数量为15000X(1+20%)=18000。
由于技术风险的分析是一项技术性很强的工作，要求做技术风险分析的人必须是技术专家，在相关技术领域有着丰富的经验，对重大技术风险的分析结果必须要经过评审，保证准确性。
客户风险存在于客户化项目中，不同行业的客户特点不尽相同，技术、理解水平也相差甚远，在我经历开发的项目中，80%的项目延期属于客户方的原因，而且这种风险可控性很低，对项目影响超过技术风险。在开发周期估算前，项目经理要仔细分析客户的具体状况，包括客户的计算机水平、管理水平、可沟通程度，在此基础上结合以往的经验综合判断是否会对开发带来明显的影响，可以按照上述的技术风险的方式将客户分级，最终确定开发周期。在这个过程中，项目经理的经验极其重要，对客户的分析基本上要依赖经验做判断，要求管理人员有大量的客户经验和行业分析能力。
3.3估算与人力资源
对于软件开发项目来说，人力资源是核心力量，因为软件开发不同于其它类型的项目，除了电脑它不需要利用其它工具，最终结果的产生完全取决于人脑中的知识，这也是知识经济的最大特点。
人力资源对估算的影响表现在技术水平、理解能力、沟通能力等几个方面，编程水平的高低、速度的快慢、能否适应团队、能否与各成员保持良好的沟通都会对开发进度产生影响，其中技术水平是最关键的因素。评价程序员的技术水平可以从编程熟练程度、编程速度、解决技术问题的能力几个因素考虑，编程熟练程度指的是程序员能否很顺畅的使用编程工具实现软件的功能，编程速度指的是完成某个功能的时间，解决技术问题的能力可以反映程序员在遇到技术难点时表现出的技术功底，如果以100%作为总和，这三个因素分别占70%、15%和15%这样的比例。
软件开发周期估算前，应对开发人员定级，建议按新手、初级程序员、中级程序员、高级程序员来划分，每一级人员再评定上述三个因素，初次估算时可以假定开发人员为中级程序员，然后依据项目组实际人员的水平做修正，这样结果的精确度能大大提高。
4. 历史数据估算法的运用
依据历史数据估算软件开发周期是一种比较常见的方法，这种方法以历史软件开发周期为依据，在估算时把当前软件项目的情况与历史数据加以对比，从而得出最终结果。按照历史数据估算开发周期准确度还是相当高的，但这种方法只适用于对某类软件的开发，比如某个行业业务系统的开发，当要估算的软件与历史软件相差太多，比如开发工具完全不同，或者类型完全不同，就不能再依赖这种方法，最起码应该辅助使用其它估算法。如果没有历史数据或是开发一种新领域软件，可以使用代码行或功能点估算法，在此基础上再通过其它方法校正。
事实上目前项目管理人员对开发周期的估算大部分属于人力时间估算法，凭借的是自己的经验，经验越多估算的结果就越精确，但是大部分项目管理人员对以前很有价值的历史数据缺乏归纳整理，估算的时候凭借感觉的成分多一些，所以精确度相对要低很多，所以要求我们的项目管理人员不仅要有大量软件开发的经验还要不断总结积累，历史项目数据对于以后软件开发周期的估算是非常有价值的。
在实际使用历史数据估算法时，建议项目经理建立一个历史项目数据库，在库中包含以前所有项目的开发周期、项目规模、开发人员状况、客户状况等详细数据，当估算时根据当前项目的状况在库中寻找最类似的历史项目，然后再比较两个项目之间在项目规模、项目风险、人力资源之间的区别，我们假定历史项目开发周期为A当前项目的周期可以依据下列公式得出
B=A×(2×S+R+P+2×C)/6
S：代表软件规模 R：代表风险 P：代表人力资源 C：代表客户
以上值均指当前项目与历史项目的比率。
实际的比较因素应该不止这些，但软件规模、风险、人力资源及客户状况是其中最重要的，对软件开发的影响也最大，所以这个公式中只考虑了这些因素。其中软件规模和客户两项占的权重最大，这也是根据项目管理经验得出的，在实际使用历史数据估算法时还可以灵活加入其它因素。
项目经理的一个重要职责就是要保证项目的进度，同时负责项目的进展，那么如何能够保证项目的进度呢？那么首先要弄清楚，进度与进展的概念.
1 首先要区分进度和进展的概念
进度：schedule，工期是否拖延了，拖延了多久。
进展: progress，任务的完成情况，任务完成了%多少，还有哪些任务未完成。
比如：
某项任务到今天为止，工期已经拖了2天，任务完成了80%了，还剩20%未完成；
某项任务到今天为止，已经完成，但是比计划日期拖期了2天，任务100%完成了。
2 如何度量进度？
（1）检查关键路径是否拖期，如果关键路径有拖期，则项目一定是拖期了，则要计算关键路径的拖期天数。
（2）检查非关键路径是否拖期了，如果非关键路径的拖期后超过了关键路径的工期，则要计算非关键路径的拖期天数。
（3）上述2步计算结果的最大值即为项目的拖期天数。提前以此类推。
3 如何度量进展？
有多种方法：
（1） 任务完成%=已完成的任务个数/应完成的任务个数。
（2） SPI=挣值/计划值，在软件项目中通常采用已完成任务的计划工作量/应完成任务的计划工作量。
（3） 需求完成%=已完成的需求个数/总的需求个数，或者=已完成需求的功能点/总的功能点，在敏捷方法中可以用已完成的故事点/总的故事点
（4） 在敏捷方法中也可以是燃烧图，度量剩余任务的计划工作量。