2011软件设计师知识点：构建完整的解决方案

会计考友

　　序言：
8 I( B0 S9 ~7 _$ ?- P5 h. d% s9 J　　今天写的是：构建完整的解决方案。 原因是在过去的几年中，经常面临“需求变化”的问题。努力寻找了很多年的解决方案，现在想来，或许问题还是出在我们自己身上，因为我们当初的基础不对。一句“客户并不真的清楚自己的需求”，我们真的明白这句话的含义并知道如何应对了么?
/ z% k0 J- _" g' E+ ^　　什么是“完整的解决方案”?
, v. [- I+ i; f) q- F1 s7 `　　“完整解决方案”顾名思义，就是包含了客户的所有真实需求，并可以合理实施的方案。定义很简单，简单的像围棋只有黑白二子一样，唯一的问题就是：可能的变化多了点，不确定性高了点。
　　相对围棋而言，软件的需求和方案的问题简单很多了。
) j; J7 U; u- w0 J　　主要的问题在于，我们的“需求”中忽略了很多客户的隐形需求。
　　隐形需求包含哪些呢?一般而言包括：
5 ^0 R3 R8 m6 R6 ^# k% s( l: `　　1.1 维护需求
　　1.2 升级需求
　　1.3 易用性需求
" Z9 q& f  L, i$ `: p& Q# t0 P, G　　1.4 性能需求
　　基本而言，现在客户也在不断成熟，以上需求会或多或少的提到，但是，请注意，很可能不够全面。 所以我们需要认认真真的考虑一下，这些需求到底应该包含些什么。
　　维护需求
　　客户对维护的要求，一般至少包括这么几个：
4 r7 `$ g: w  N  @  l* F　　1. 日志需求。 这个比较复杂，后面会单独考虑。
  [/ w; |) G  U# t& W6 e　　2. 故障定位的能力。 就是说，当系统出现问题时，客户希望系统能够通过某种方式迅速查明故障的原因，并找到解决或者规避的办法。
　　3. 日常维护。 通常包括软件和硬件的“健康检查”。
, I7 [) ^* A: U  z& z　　4. 故障报警。 当系统出现严重故障时，能够给出足够的信息，并触发故障处理流程。

会计考友

升级需求　　一般来说，客户对升级的需求有这么几点：
　　1. 可控制的升级。 即检测是否可升级、是否执行升级、多个升级目标的选择、升级的计划任务等都是可以控制的，比如可以设定自动检测是否升级;设定自动升级到最高版本;设定执行升级必须为手工设置;设置手工升级时可以立即升级也可以指定计划任务时间等等。
+ p' ?' j$ U! c9 y1 U7 a5 S2 W　　2. 不影响业务的升级。 基本上客户都希望升级这个事情，不要影响他们的业务。但是有些系统实在太老了，基于这种旧系统的再开发项目必然受限于原系统的升级方案。这时就考虑：1.能不能通过升级，使系统以后升级不再影响业务;2.如果不能，怎样使(本次后以后)升级对业务的影响最小。
: u* }, w6 r& G+ l4 K　　3. 升级的简单性。升级应该简单快捷，没有太多的参数需要配置，没有太多需要手工干预的步骤。
　　4. 升级的完整性。尤其是对于分布式系统，升级时需要考虑各个部件之间版本的一致性。一个升级方案必须是完整的，不能在升级以后出现由于版本间不兼容的原因而导致系统无法工作。举个例子：
　　一个简单的CS系统，采用加密通道进行通讯，现在升级加密算法，该如何设计呢?
　　假设是互联网应用，有上万个客户端，该如何设计呢?
4 S! W* Q: m5 Z　　从这个例子可以看出，系统的设计，从一开始就必须考虑这些“隐性”需求，否则系统架构可能都要****重来。
　　易用性需求
6 ]* K  ^  F8 K% Q1 F- ]　　通常提到易用性，大家会觉得无非是界面啦，帮助啦。没错，但是不全。
* M" K% }8 m9 ~$ I! t9 K　　让我们看几个例子，可以大概理解一下易用性是什么概念。
　　在桌面系统的竞争中，专业而强大的Unix败给了经常被人批评的Windows系列，因为windows安装简单，升级简单，安装新的游戏或者软件也很简单，操作起来更是如此，直观的图形界面虽然设计和功能不太丰富和强大，但是相对于unix必须先学习“文件系统”概念，再学习命令行而言，“树”的概念用户可以无师自通，拖拽更是没有命令行可以比拟;
　　同样是微软，C++语言乘微软之名，挟操作系统之利，语言和开发环境都不可谓不强大，但是结果怎样呢?IDE方面多数人还是用SI，语言方面，微软更是不得不推出C#来与Java抗衡。就因为SI看代码的时候查找上下文方便;Java比C++开发起来方便;
  D/ d: O/ m: ?/ I　　在中文输入法的竞争中，强大高效的笔画输入法败给了拼音输入法。现在拼音输入法大行其道，笔画输入几乎鲜有提起。
0 T, n: z$ y+ x: J8 W( |　　最主要的，是业务模型要和客户的一致。这个应该算是基础。业务模型代表着思维模式(比如输入法)，也就是说，要从客户的角度来设计系统，而不是机械的堆砌数据和流程。

会计考友

　一般来言，易用性的需求还包括：　　1. 常用的功能应该能够直接了当的访问。比如财务系统，不同的角色有不同的常用功能，系统应该设计为可以根据角色来打开不同的初始页面;再比如我们常见的游戏，Save/Load菜单通常都在主页面上，没有谁设计成非得看完片头(还不能跳过)再新建游戏然后再一路杀到存取点才可以读取进度。
# ^  S$ d6 P1 h　　这里，不推荐严格的学术分级模式。或许这样看起来很专业，但是不好用。
. G( q2 Y/ I2 }- C1 f$ i& t　　2. 操作应该照顾客户的习惯，尽可能的降低客户的学习成本。当然，前提是正确定位你的客户群。
, p9 ?& a& T6 i# |  I9 x- T　　3. 优雅。举个例子，log。
　　写log的时候，不要一口气写个7、8G的log文件，尽可能的根据某些标准来归类和拆分。例如按照时间，按照log的级别。
" G; q7 X3 n: I6 d- B) p　　还是用MS的VS Studio做例子，编译错误可以直接通过双击跳转到源代码所在，而不像Makefile那样只是生硬的输出文件和行号。
　　打开一个巨大的文件，给出一个可度量的进度条，总比只显示一个沙漏要好吧?
, v$ |: j+ t9 g- s7 a5 x/ d　　现在，应该可以理解什么是“优雅”了吧?我的理解，就是专业，而且体贴。
: r& e6 ~% _$ p$ E& }# l　　性能需求
3 k3 N( l3 [$ y" \3 e　　好像现在性能需求越来越被重视了，所以我的废话也不多说，简单讲，包括：
　　1. 首先分清楚哪些部分各自有什么样的性能需求。用户参与的操作，性能要求通常高于其他操作。
　　2. 知道自己的上限。达到上限的时候，通过合理的方法让系统给予提示，而不是直接瘫痪。当然，这是理想主义。只能无限接近，不能达到;
6 c: u0 m' i5 }9 W0 E' V. j+ j　　性能是需要设计的，而不是仅靠硬件来实现。所以，在客户没有提到性能需求时，你需要通过各种渠道，真正的确定系统的性能要求是什么。“先做做试试”的结果往往是推倒重来。子曰“有的放矢”是也。
  e" X+ |5 B1 t. J' Y+ I　　日志需求
0 e# }6 @. l! ^. g　　最后来说说日志需求。
　　日志需求是和客户的隐性需求密切相关，并且几乎全部涉及的一种需求。例如：日志要记录维护信息和升级信息，日志还要简单明了，一看就知道写的啥意思，另外日志记录功能还不能对系统的性能有大的影响。