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

企业动态
2011软件设计师知识点:构建完整的解决方案,帮助考生梳理知识点。

序言:

今天写的是:构建完整的解决方案。 原因是在过去的几年中,经常面临“需求变化”的问题。努力寻找了很多年的解决方案,现在想来,或许问题还是出在我们自己身上,因为我们当初的基础不对。一句“客户并不真的清楚自己的需求”,我们真的明白这句话的含义并知道如何应对了么?

什么是“完整的解决方案”?

“完整解决方案”顾名思义,就是包含了客户的所有真实需求,并可以合理实施的方案。定义很简单,简单的像围棋只有黑白二子一样,唯一的问题就是:可能的变化多了点,不确定性高了点。

相对围棋而言,软件的需求和方案的问题简单很多了。

主要的问题在于,我们的“需求”中忽略了很多客户的隐形需求。

隐形需求包含哪些呢?一般而言包括:

1.1 维护需求

1.2 升级需求

1.3 易用性需求

1.4 性能需求

基本而言,现在客户也在不断成熟,以上需求会或多或少的提到,但是,请注意,很可能不够全面。 所以我们需要认认真真的考虑一下,这些需求到底应该包含些什么。

维护需求

客户对维护的要求,一般至少包括这么几个:

1. 日志需求。 这个比较复杂,后面会单独考虑。

2. 故障定位的能力。 就是说,当系统出现问题时,客户希望系统能够通过某种方式迅速查明故障的原因,并找到解决或者规避的办法。

3. 日常维护。 通常包括软件和硬件的“健康检查”。

4. 故障报警。 当系统出现严重故障时,能够给出足够的信息,并触发故障处理流程。

升级需求

一般来说,客户对升级的需求有这么几点:

1. 可控制的升级。 即检测是否可升级、是否执行升级、多个升级目标的选择、升级的计划任务等都是可以控制的,比如可以设定自动检测是否升级;设定自动升级到***版本;设定执行升级必须为手工设置;设置手工升级时可以立即升级也可以指定计划任务时间等等。

2. 不影响业务的升级。 基本上客户都希望升级这个事情,不要影响他们的业务。但是有些系统实在太老了,基于这种旧系统的再开发项目必然受限于原系统的升级方案。这时就考虑:1.能不能通过升级,使系统以后升级不再影响业务;2.如果不能,怎样使(本次后以后)升级对业务的影响最小。

3. 升级的简单性。升级应该简单快捷,没有太多的参数需要配置,没有太多需要手工干预的步骤。

4. 升级的完整性。尤其是对于分布式系统,升级时需要考虑各个部件之间版本的一致性。一个升级方案必须是完整的,不能在升级以后出现由于版本间不兼容的原因而导致系统无法工作。举个例子:

一个简单的CS系统,采用加密通道进行通讯,现在升级加密算法,该如何设计呢?

假设是互联网应用,有上万个客户端,该如何设计呢?

从这个例子可以看出,系统的设计,从一开始就必须考虑这些“隐性”需求,否则系统架构可能都要****重来。

易用性需求

通常提到易用性,大家会觉得无非是界面啦,帮助啦。没错,但是不全。

让我们看几个例子,可以大概理解一下易用性是什么概念。

在桌面系统的竞争中,专业而强大的Unix败给了经常被人批评的Windows系列,因为windows安装简单,升级简单,安装新的游戏或者软件也很简单,操作起来更是如此,直观的图形界面虽然设计和功能不太丰富和强大,但是相对于unix必须先学习“文件系统”概念,再学习命令行而言,“树”的概念用户可以无师自通,拖拽更是没有命令行可以比拟;

同样是微软,C++语言乘微软之名,挟操作系统之利,语言和开发环境都不可谓不强大,但是结果怎样呢?IDE方面多数人还是用SI,语言方面,微软更是不得不推出C#来与Java抗衡。就因为SI看代码的时候查找上下文方便;Java比C++开发起来方便;

在中文输入法的竞争中,强大高效的笔画输入法败给了拼音输入法。现在拼音输入法大行其道,笔画输入几乎鲜有提起。

最主要的,是业务模型要和客户的一致。这个应该算是基础。业务模型代表着思维模式(比如输入法),也就是说,要从客户的角度来设计系统,而不是机械的堆砌数据和流程。

一般来言,易用性的需求还包括:

1. 常用的功能应该能够直接了当的访问。比如财务系统,不同的角色有不同的常用功能,系统应该设计为可以根据角色来打开不同的初始页面;再比如我们常见的游戏,Save/Load菜单通常都在主页面上,没有谁设计成非得看完片头(还不能跳过)再新建游戏然后再一路杀到存取点才可以读取进度。

这里,不推荐严格的学术分级模式。或许这样看起来很专业,但是不好用。

2. 操作应该照顾客户的习惯,尽可能的降低客户的学习成本。当然,前提是正确定位你的客户群。

3. 优雅。举个例子,log。

写log的时候,不要一口气写个7、8G的log文件,尽可能的根据某些标准来归类和拆分。例如按照时间,按照log的级别。

还是用MS的VS Studio做例子,编译错误可以直接通过双击跳转到源代码所在,而不像Makefile那样只是生硬的输出文件和行号。

打开一个巨大的文件,给出一个可度量的进度条,总比只显示一个沙漏要好吧?

现在,应该可以理解什么是“优雅”了吧?我的理解,就是专业,而且体贴。

性能需求

好像现在性能需求越来越被重视了,所以我的废话也不多说,简单讲,包括:

1. 首先分清楚哪些部分各自有什么样的性能需求。用户参与的操作,性能要求通常高于其他操作。

2. 知道自己的上限。达到上限的时候,通过合理的方法让系统给予提示,而不是直接瘫痪。当然,这是理想主义。只能无限接近,不能达到;

性能是需要设计的,而不是仅靠硬件来实现。所以,在客户没有提到性能需求时,你需要通过各种渠道,真正的确定系统的性能要求是什么。“先做做试试”的结果往往是推倒重来。子曰“有的放矢”是也。

日志需求

***来说说日志需求。

日志需求是和客户的隐性需求密切相关,并且几乎全部涉及的一种需求。例如:日志要记录维护信息和升级信息,日志还要简单明了,一看就知道写的啥意思,另外日志记录功能还不能对系统的性能有大的影响。

【编辑推荐】

  1. 2011软件设计师知识点:如何控制需求变更
  2. 2011软件设计师知识点:工程辅导浅谈架构
  3. 2011软件设计师知识点:简易应用规格说明技术
  4. 更多软考资料请点击51CTO软考专题
责任编辑:张攀 来源: 考试吧
相关推荐

2011-01-14 10:57:18

软件设计师

2010-12-27 10:03:29

软件设计师

2011-01-18 11:33:55

软件设计师

2011-01-11 11:33:26

软件设计师

2011-01-05 15:02:57

2011-01-07 10:49:22

2011-03-02 11:33:51

软件设计师

2010-12-10 10:32:15

软件设计师

2010-12-08 10:50:16

软件设计师

2010-12-08 10:54:27

软件设计师

2010-12-17 10:34:03

软件设计师

2010-12-09 10:51:56

考试软件设计

2010-12-20 10:50:33

软件设计师

2010-12-06 10:28:45

2010-12-21 10:46:08

软件设计师

2010-12-10 10:39:50

软件设计师

2010-12-07 10:51:22

件设计师

2011-01-28 10:10:10

软件设计师

2010-12-27 10:28:19

软件设计师

2010-12-23 10:37:44

软件设计师
点赞
收藏

51CTO技术栈公众号