构架浅析
李宝剑 libaojian@sina.com
从广义方面来理解构架，在自然世界中到处都是。作为一个好的构架概念最终会形成模式。这里笔者仅从软件工程的领域将自己的一些浅薄认识进行分析整理，以求获取通用的可控制其风险的构架模式。
从静态视角分析，构架涉及了公司，部门，团队，涉众等。从动态视角分析，构架涉及了产品创造过程以及围绕此过程发生的各种事件。从软件技术的视角分析，构架涉及了需求，设计，程序，用例等。不同视角看到不同的构架，这些构架彼此相互联系，相互制约。
对于一个构架的组成，我暂称其为元素，元素会有关系，关系包括了控制，协作，支持等。
从以上分析，你的头脑里应该会有一个模糊的构架view展现。
我们的目标是借助诸多构架支持完成某些构架的实现，在这个过程中，会发生一些阻碍事情进展的情况。那好，事情就变的有目的了，我们的目的就是解决这些阻碍，对症下药，尽大可能的解决这些问题，权衡利弊，使最终的利益最大化。
构架可抽取，可形成模式，而具体到一个项目构架模式就变成了构架实例，有了动作动态这个元素来打破了构架的一些常规。作为项目的控制者需要合理的处理和控制常规的可预见的风险和突发的风险。在不同的场景中，构架中的元素所担任的角色就不同，其属性和行为也会动态的进行变化。例如你在公司构架下是一个员工，在部门构架下是一个设计师，在项目构架中是一个设计组长，在涉众中是一名设计人员，在过程中是一名团队成员，在需求构架中是一个需求的翻译者，在设计构架中你就是大师，等等。
分析抽取了初始的构架模型如下
下面我将根据初始的构架模型，进行具体的项目分析。我将从目前的项目进行此项目架构以及支持和约束此项目架构的其他架构的分析，找出仅可能多的问题和解决方案，形成一定的模式，避免重蹈覆辙。
项目背景
公司近期在电子政务方面，会面临大量的政务信息的交互。 在此背景下，开发代号为ABC的数据交换平台。因为某研究所已经有若干成熟的设计，将和此研究所合作进行开发。公司派3，4人进驻研究所， 同研究所的研究生团队组成新的团队，共同开发。
构架列表
n 公司构架（公司领导 政务部门领导 开发领导）
n 团队构架（公司监督 项目指导 项目管理 技术管理 公司员工 研究所学生）
n 研究所构架（导师 学生（博士研究生 硕士研究生））
n 涉众构架（公司 研究所 用户）
n 项目构架（高层用例构架 组成人员）
n 需求构架（用例架构）
n 设计构架（系统架构）
n 实现构架（类架构）
n 过程构架（周期，里程碑）
n 技术构架
总体构架关系
下面一排都是外部约束和支持项目构架的若干构架。上面一排是项目过程中内部所要协调的构架。下面就支持架构的目标和责任以及未能达到目标的状况进行分析。
公司构架
公司对于此项目的责任应该是约束，监督，支持。从目前的状况来看，项目组所感受的的只是约束和监督，未能明显的感觉支持。对于监督的力度不够也就是过程的监督仅停留于常规的周报等纸面内容，掩盖了事实的真相。
问题
就是监督不力，不予支持。结果是上下信息不畅，项目进展困难。这种严重的等级信息传递，造成了链条式的信息沟通，因为某一个环节的缺失，就会造成监督盲区和支持盲区。
参考模式
解决方案
从公司对于此项目的构架组成包括了五级，董事长，副总，政务部总，政务部开发负责，政务部项目监督员。那问题显然出在政务部总和政务部开发负责这个点（元素）上。解决问题将从此深入。借用我党常用的什么下乡活动的策略，并且支持鼓励员工的合理建议，广开言论。
研究所构架
研究所的目的不言而预，教学为主，培养学生目的很明显。对于项目的进展做出了很大的努力，而问题也随着进展暴露的越来越突出。优势，人力多。
问题
1， 经验不足
2， 流动性大
3， 责任心不足
4， 需花费培养成本
解决方案
传 帮 带 ，这就要求团队组成的格局需要按照这种方式进行重新规划。将比较优秀的团队成员作为产品组的领军。人才浪费也是一个缺憾，未能人尽其用。通过一段时间的观察和磨合，仔细分析每个组员的特点，进行团队合理的人员分配。真正的实现1＋1》3。
团队构架
不管是从传统的软件过程来讲还是从rup的项目管理过程分析。团队的组成缺失很大，也很不科学。一句话：一哄而上。
问题
1. 项目管理者位置、职权不突出，没有独立的协调、组织、调配权力；
2. 团队组成人员结构不合理，往往不能按照科学的职能需要配置项目开发人员；
3. 团队中职能交错混乱，管理模式不确定，存在严重的职能重叠浪费和缺失不齐的矛盾现象；
4. 团队精神不明确，项目目标不一致。
解决方案
在公司构架的基础上，明确项目管理者的地位和作用；按照类比或经验的管理模式，组建所需要的研发人员团队，明确团队精神和唯一奋斗目标.。
涉众构架
没有用户的参与。涉众不完全。听不到不同的意见（或者不同的意见仅局限于内部），会形成一叶障目。
问题
解决方案
作好充分的项目前期调研，广泛收集用户（或业主）信息，建立项目用户跟踪回访制度，最好由原软件开发负责人牵头。
需求构架
需求来源太狭小。
问题
导致产品规划不太合理，盲目的靠近什么红头文件。连技术细节都盲目靠近。
解决方案
从其他的政务系统入手，结合其他的类似产品，进行产品规划和需求获取。
设计构架
概要设计阶段因为产品族的规划不到位，造成了某些概念不统一。详细设计阶段问题依旧，并且对于整体感未能有人把握。
问题
1. 设计目标不明确，设计范围模糊，造成设计概念含混不清；
2. 设计阶段划分不清，设计深度很难把握。
3. 设计成果的校核、审查、确定系统不健全，没有准确的把关人员。
解决方案
明确设计阶段，提前作好设计沟通协调工作，给定项目设计内容，设立专人设计组，健全设计成果的审查把关系统。
技术构架
技术风险
问题
无总体感
解决方案
架构师，在那里。如果没有合适人选，就要从团队中培养。
实现构架
类结构比较合理，但是因为总体无人驾驭，可能造成百花齐放。
问题
许多公用类未尽其用，并且对于程序中效能都是没有把握。
解决方案
代码框架的确定和培训。
过程构架
过程中的缺憾主要是周期和里程校验，以及过程中的审查。
问题
不及时 力度不够
解决方案
项目管理方面的资料很多，我这里就不罗索了。