先说结论吧，本人在开发过程中使用ICONIX
ICONIX过程是usecase driven的，但比RUP更轻巧。和敏捷方法相比，提供了充分的需求和设计文档。同时避免了过度分析。ICONIX过程只使用有四种UML图（usecase,class,sequence,robustness analysis）。
robustness analysis是ICONUX和其它过程的主要区别，它填补了分析和设计之间的GAP，在domain model的上下文编写，最大限度的消除了usecase的歧义，ICONIX使得usecase更容易设计、测试和评估。下图是ICONIX的概念图
为什么类国企系统开发适合使用ICONIX过程？这是因为
1、系统难于做到很好的迭代模型，难于以拥抱变化的态度去开发，商务上更注重SOW，变更就是CR;
2、业务人员和技术人员理解歧义很大，这个不是简单有个BA或客户代表什么的就能解决的，使用ICONIX的好处就是ICONIX是基于核心逻辑分析设计的一种建模过程;
3、ICONIX过程不用裁剪就可使用，避免掉企业过程工程师缺乏和裁剪过程的麻烦（如RUP）。
4、V模型的测试模型，更利于对测试的把控。
当然软件过程的使用还有很多相关的内容，比如CMM/CMMI的一些理念和过程要结合起来。
有了软件过程并不能保证按照时间和质量完成系统的开发，这个需要一些自动化的集成工具集来帮助解决，这部分参考了一些敏捷的方法，主要的工具集有（基于JAVA开发）
Issue Tracking和项目管理：redmine
版本控制：Subversion
持续集成：Hudson
单元测试：testNG
测试覆盖率：cobertura
代码检查：findBugs,pmd,checkstyle,cpd
集成测试：selenium
压力测试：jmeter
以下分别解释：
redmine基于ROR开发，提供了足够的项目Issue Tracking和管理功能，Subversion等的整合功能，开源里最好用。如果使用商业的Jira也很好。trac太难配了，mantis只是个bug tracking的工具。
Hudson是持续集成工具，原来我用CC，不过还是Hudson好使。
hudson会在每天生成一个daily build版本;10分钟compile以下源码，将错误发给相关开发者;每日做一次report，包括unit test，findbugs/pmd/checkstyle/cpd/cobertura的集成报告(使用jcreport集成 https://github.com/jCoderZ/fawkez/wiki/JcReport)，做一次selenium测试等等。也可手动/自动做部署。
Subversion是集中式VCS，本人对git十分感兴趣，毕竟是linus的大作。但git的理念是开放，没有权限控制，并不适合企业应用开发。
testNG,junit也OK，只是我会关注关联性的单元测试，而junit的理念是以隔离为主。另外单元测试可能是程序员比较反感的，但是写不写单元测试和单元测试的质量是我衡量一个开发商能力的重要指标，不写单元测试系统变更影响的BUG可能会大量下放到QA的测试，集成测试在这方面能力还是不足。
cobertura,java单元测试覆盖率的框架，和testNG集成很好。同样功能的还有emma，cobertura适合完整的报告，如果是eclipse使用，eclemma不错。使用测试覆盖率的问题是不能让unit test来欺骗它，另外我追求90%的覆盖率，实际上，能到70%就很不错了。
findBugs,pmd,checkstyle,cpd:
fingbugs基于bug pattern，检查javabytecode，如NullPointer
pmd检查源文件,如未使用变量
checkstyle主要是编码规范，如javadoc的规范等
cpd主要是copy paste
selenium:如果商业的可以用qtp
selenium可以录制web的脚本，现在对js的支持也很强大了。自动化集成测试只是个附加手段，不能有太高的期望值。
jmeter做部分压力测试的功能，比如数据库，web应用等，由于系统的复杂性，在一些场景，会自己实现压力测试的程序。jmeter一般不集成到hudson，因为它的行为可能引起hudson系统的不稳定。
结束语：虽然按照这种方式工作能有效提升软件开发的质量，对于开发成本的提升也不大，但真正能做到这样的项目少之又少，有时真是一种无奈。