先从组织机构着手提出几个问题，以抛砖引玉。
1。组织机构问题？
2。组织机构和系统框架的关系？
3。开发过程和组织机构的关系？
4。角色如何定义？
5。角色之间的沟通？
6。角色如何具体的落实到实际的开发成员中？
... ...

组织机构问题在CMM(CMMI)中,论述已经很清晰,在ISO9000-2000中有思想,但要你具体运筹，比较抽象。
但无论如何，这与实际的运作相差甚远。我曾经把自己多年来实施配置管理的一些体会写给《软件学报》，他们说我的研究便浅，个人认为这是一件非常遗憾的事。国庆我到浙江的丽水做了次背包游，深刻感受到了朴实而真实的美丽。同样，组织机构的问题做好了，一定是非常简单朴实的，但也是美丽真实的，只可惜一些人，由于种种原因，把事情搞的金玉其外。
深刻的理论基础是做好组织机构问题必须的，生搬硬套或随意裁减应该避免，如不能把这套原理运用自如，建议生搬硬套，当然，如果这样做，你所在公司是应该具备一定的条件。最坏的情况，可以采用“水到渠成”，学佛教的不为而无不为，当然，这是一种消极被动的思路。
简单，就美丽，是工程管理的至高境界，尤其是在我们国家的软件公司，更是这样，可能也是我们与西方文化的重要差异吧。西人的思路确实严谨而美丽，但东方文化的含蓄也有伟大的力量，如何扬长避短，全在个人修为。
在说下去就写成论文了，不多说了。
个人见解。

建议你把2、3合并，这样可能思路更成体系。
组织机构和系统框架的关系、开发过程和组织机构的关系是一体互动的系统。个人认为，由系统框架可以得到建议的开发过程；由你选用的开发过程，可以得到建议的组织机构。
前者更偏向于技术预研，后者更偏向于工程管理。
简单说一些后者，人们往往认为如果开发过程采用偏向于敏捷，那么就是充分发挥开发人员的潜力，而削减组织机构的参与，这是实际上是一种形而上学，是一种不领会软件工程本质肤浅。如果你要进一步，建议更深入地领会配置管理的精神，当然，国外的一些软件需求工程的研究也是有益的，如果时间宝贵，建议不学或少学国内的专家成果。
个人见解

简单，就美丽。精辟！
如果说，我们把一个软件的开发过程作为一个系统来看待，那么组织机构则是他的一个角度，从这个角度来看，组织机构作为一个系统的载体而存在，刻划组织机构的一个核心概念则是角色，从过程的角度来看，角色定义了：任务、活动、和活动的结果；从角色的实际对应者－人或者部门来看，则是定义了：职责、权力和义务。
系统框架可以认为是开发过程核心产物之一的静态结构（组织机构也是开发过程中的一个静态结构），开发过程的定义，则是开发过程的一个动态结构。
那么现在的核心问题则是：理论如何映射实际。即我们采用什么样的原则和手段，把实际的开发过程中的各种任务，显示（上级命令下级）的和隐示（执行者认为这就是他的工作）的落实到具体的组织机构的元素上。也可以说：我们如何定义角色以及角色制造的产物：文档和其他交付物。
这里的矛盾是：资源一直都是紧张的，成本是有限，时间也是有限，保证质量。
具体来说：RUP和过程模式和XP的过程模式，在实际的情况中我们如何定义？
配置管理固化了上述关系，当时当我们开始另一个完全不同的项目时（例如：开发ERP系统和开发嵌入式系统）时，怎么样在最短的时间内，使配置管理达到最优。
采用最简单、有效的方式。
　

看了你的回贴，知道你是一个善于思考的人，努力走下去，你会收获无限的。下面阐述个人认识，供探讨。
一个软件的开发过程确实是一个鲜活的系统工程，这个系统的特点是：平衡是相对的，不平衡是绝对的，知道了这一点，关于“工程管理”这个角色就明白了。明白了工程管理，那么，对组织机构则会有新的认识，当然，组织机构则包含更多。
你后面的论述就是一些经典理论了，也无所谓对错。但在实际工作中，如果你有这些想法，个人认为你还没有达到能否定他的程度，入门后还需要往前走。开发过程其实也是可以这么说，矛盾，就美丽。
后面阐述的具体体会，感觉挺漂亮的。
具体应用，在你能“否定”后，遇山开道，逢水架桥，那是收获的季节。

1.过程维
何时提供何种提交产物?

2.组织结构维
何人负责做何事?如何形成一个价值链(增值链)?

3.技术维
采用哪些技术方法和工具?

推荐阅读:"Working with objects -- The OOram Software Engineering Method", Trygve Reenskaug