从例子2就可以总结出如下几个现象：工作与工作之间可以有层次关系的，一个看似很简单的工作，很可能会隐含着巨大的工作量，在某些先决条件没有或者预备不足的情况下尤其如此。要正确估算一个工作所用的时间，首先我们就要把“折叠”起来的“工作树”尽可能完全“展开”，其次就必须要遏制工作中的“学习”、“研究”甚至“查询搜索”的工作量。总之，在实际项目开展的时候，就要尽可能让所有的工作都是单纯的，可以猜测的，并且尽可能排除那些不可控、不可靠的因素。

　　换句话说，项目的每一个工作与时间的关系都必须是“线性”的。假如实在不能排除“非线性”的工作，也必须在“可控”的范围内，项目内部不答应有“不可控”的“非线性”因素存在。

　　一句话： 脑筋动得越多，事情做得越慢!

　　到底项目中究竟有多少因素是属于“不可控”呢?哪些又是属于“可控”的?哪些属于“线性”因素?要回答这个题目，我们首先来看一下我们目前的软件开发方式和流程吧：

　　(一)接单签订合同

　　(二)需求调研、分析

　　(三)架构设计、概要设计

　　(四)具体设计

　　(五)编码、测试

　　(六)交付、维护

　　大致六个步骤，其中三四五是和我们谈得开发过程相关联(其他部分我会在以后的系列文章中讨论)。首先我们看第三点和第四点，他们统称为“设计”，参考文献2中给出的“设计”阶段的目标是解决四方面的题目：数据结构，软件体系结构，过程细节，接口性质。

　　有经验的读者我想已经看出来了，传统的“设计”所解决的题目，有相当一部分应该回纳为现在的“架构”范围内。软件架构涉及的范围主要包括如下：

　　(一)应用程序的层次划分(比如界面层，存储层等)，

　　(二)部分应用程序模块的划分(比如初始化模块，配置模块，权限模块等)，

　　(三)部分应用程序模块的实现(权限、用户、组织机构治理等)，

　　(四)函数库的实现，

　　(五)各模块、层之间的相互关系和通讯机制，

　　(六)相关的部分数据结构定义。

　　如此可见，上文中的第三和第四点最重要和最基础的工作基本就在“架构”范围内，剩下的工作，基本就是跟具体业务相关的了。

　　在上文的三个“xx设计”中，架构设计的时间最难控制和估算，概要设计和具体设计由于就是直接从需求条目演化而来，而且轻易细化(以后我会有文章专门讨论)，所以固然也是属于“设计”这种“非线性”工作，但是“可控性”要比“架构”强很多。从个人的项目维护经验来看，维护过程中产生的题目，有相当一部分是由于用户需求突破了原先架构的能力所致，而正是这种题目，才是拖延时间最长，引起客户反映最强烈，也是维护职员最痛苦最头痛的题目。因此，“架构设计”我把它回类到“非线性”工作中，而且是“难点”工作。

营销广告策划网(www.ideatop.net)