本节书摘来异步社区《挖掘管理价值：企业软件项目管理实战》一书中的第2章，第2.4节，作者： 徐勤 责编： 杨海玲, 更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.4　软件设计过程

挖掘管理价值：企业软件项目管理实战
软件设计是根据需求的内容，运用计算机理论、技术和工具将其合理地、有机地、具体地转化为功能，并演示其实现的方法、过程和结果。设计人员在理解了用户的需求之后，首先在自己的脑海中会有一个大致的概念和思路，然后考虑如何去实现这些功能，当然这需要一定的专业知识和实践经验。这里就不阐述软件或数据库设计的理论知识了，而重点介绍如何将设计人员脑子里对软件的设计和理解反映到文字、图形和流程上，使得用户可以了解计算机是如何实现他们的需求的。我们用图 2-9 来说明软件设计的过程。

如图 2-9 所示，用户的需求仿佛就是混乱的揉合在一起的愿望和想法，经过设计人员的处理、分析和设计，就变成了清晰的、系统的、有效的软件功能或界面。

软件设计是一项创造性的工作，就好比绘画一样，有一定的规律和章法。尽管一些教科书阐述了一些基本的理论和方法，但是这些远远不够。在实践中你会发现，软件设计是一个大熔炉，不但会用到计算机的理论，甚至其他科学和艺术范畴也会融合进来，譬如美学、音乐、财务、机械工程、数学等。如果只局限于计算机的理论和方法，很难设计出一套灵活、有效、精致和满足用户体验的软件，因此软件设计人员要善于综合运用各种知识和经验，跳出束缚，大胆创新。

2.4.1　软件结构设计

软件是个复杂的系统，是众多功能、操作和数据的结合体，就好比一幢大厦，里面有电梯、房间、水管、电路、大门、空调等。在设计软件的具体功能和界面之前，先要理顺软件的结构，否则就像盲人摸象一样无从下手。

软件的结构一般按照功能来进行分类组合，这里给出一个围墙模型，如图2-10所示。

在此图中“数据处理”是核心模块，所有的数据计算和处理都是它来完成，通常也是三层架构中的逻辑层。围绕着“数据处理”模块的有“用户操作界面”、“数据输出界面”、“数据接口”、“系统设置界面”和“系统管理界面”模块。

一般而言，用户分为三类：普通用户、超级用户和系统管理员。他们在系统内的分工和权限是不同的，因此他们的界面、操作方法也不同。“用户操作界面”模块是普通用户使用的，在此模块中，普通用户只能进行访问、查询和输入数据等一般的操作，此模块也是软件数据的主要来源窗口。“系统设置界面”模块是超级用户使用的，在此模块中，超级用户可以修改系统内的业务逻辑和普通用户的权限。“系统管理界面”是系统管理员使用的，在此界面中，系统管理员可以修改系统的数据算法和结构、用户的权限、以及系统流程等。

“数据输出界面”模块是各类报告、报表、数据导出和打印的界面。“数据接口”模块和“数据输出界面”模块类似，但是它更多的是一种无界面的机器与机器之间进行数据交互的模块，因此把它单列出来。在界面的外围是“用户登录”和“用户退出”模块，主要是负责在用户使用软件的时候认证用户信息和在用户关闭软件时保存相关信息。

2.4.2 软件界面设计

界面的作用就是提供软件和用户交互的窗口，通过用户在界面上的操作，软件就知道用户行为和需要什么，因此界面的设计目的就是要解决什么样的控件布局和组合可以让用户获得所需要的东西。很多设计人员在做界面设计时往往走入一个误区，认为界面越华丽就越好，功能越多越好，其实不然，固然华丽无错、功能强大是好，但是却违背了设计的“够用”和“适用”原则。尽管青菜萝卜各有所爱，大部分的用户更偏向于简单好用。那么到底什么才是“够用”和“适用”呢？

“够用”是指除了用户需要的功能，不要额外地增加多余无关的信息、图片、内容和功能。

“适用”是指界面上提供的信息、图片和控件等是适合和方便用户使用的，不会让用户觉得不会用、不知道怎么用，或者难用，有的时候简洁反而更有效。

当然“够用”和“适用”原则也不是一蹴而就的，就像探寻迷宫一样，经过多次尝试才能找到最短的路径，界面也是通过不断的修正才逐渐趋向于“够用”和“适用”的。同时也不是一成不变的，随着用户需求的变化，“够用”和“适用”的标准也在变化着，可能以前的“够用”和“适用”的界面变得不“够用”和不“适用”了，也可能以前不“够用”和不“适用”的变得“够用”和“适用”了。总之，用户的体验才是衡量是否够用和适用的标准。

案例8：适当的界面设计
案例情景
金辉机械加工公司希望机床操作工人使用系统来输入工作单的信息。系统的设计要求是让操作工尽可能地快速和准确操作，不会影响到正常的工作，另外工作单上有工单编号和型号条形码。设计人员设计了两种界面用于工作单登记，如图2-11和图2-12所示。

案例分析
我们对比一下这两个界面，其基本的框架是一样的，只是内容和页面的元素不同。就功能而言，这两个页面都能满足用户的需求，即都能完成工作单的登记，也不存在哪个设计好与坏的问题，我们所要关注的是“是否够用和适用”。这两点的对比如表2-11所示。

因此经过综合评估，界面一最符合当前软件的需求，即满足了快速、高效和简单的要求。当然界面一并不是完满无缺的，它还需要在今后的使用中不断完善。界面二尽管也可以满足功能，但在当前情况下，不是完全适用，或许在其他场合可以使用，譬如产线领班的管理界面或是公共区域使用平台等。

案例启迪
对于企业应用的软件来说，实用是第一主义，而对于商业应用的软件来说，吸引力是第一主义，因此在不同的应用场合，软件的设计要符合实际应用场合的情境而不是设计者的意愿。

2.4.3 软件数据设计

数据设计主要是定义数据的格式和结构。这里说的数据不光是关系数据库里的数据，还包括广义的任何软件处理的数据，如字符、警告信息、文件或语音等。设计人员往往只关注数据库结构的设计，认为数据库设计好了，软件的数据处理就成功了。要知道，不是所有的数据处理都是依赖数据库完成的，也不是所有的数据都用数据库来处理就一定又快又好。

那么我们在做数据设计的时候，应该注意什么呢？

• 精炼的类型。数据的类型有很多种，不同的开发语言和数据库都有自己特有的数据格式。为了加强软件的适用性和扩展性，在没有特殊要求的情况下，最好使用通用的数据格式，而不是某些互不兼容的格式。如果一旦使用了特殊格式，会增加开发的成本，因为可能需要开发额外的代码来解释和转换数据。特别是在软件投入使用后，可能面临着数据无法转换的风险，有很多软件就因为这个技术难题而销声匿迹了。
• 统一的格式。同样类型的数据使用同样的格式，如日期类型的数据格式为“yyyy-MM -dd hh:mm:ss”，那么所有的日期数据都应该保存为这种格式。这样做的好处是，一组代码就可以读取、计算和保存所有同一类型的数据，在显示不同格式的日期格式时，如dd/mm/yyyy，可以使用系统函数来转换。统一的格式将促使代码变得精炼高效，其运算速度也是最快的。相反，各种各样的格式势必需要多种代码来支持其相互之间的转换，如果仅是多一两行代码，倒也不会对软件效率产生太多影响，可是如果有成千上百的格式转换代码，情况又会是怎样的呢？ - 恰当的长度和精度。数据需要适当的长度和精度，如果太短，则以后难以扩展，如果太长又浪费存储空间。例如，货币类型的数据，精度在2～4位为宜。 - 自定义类型。创建自定义的数据类型可以有效地提高数据处理的能力。 - 保护机制。为了避免数据运算时产生错误或溢出，对数据进行必要的校验，如不能为空或NULL、满足一定的长度、只能有数字或字符中不能有空等。 - 合理的索引功能。频繁读取的数据应该建立索引，但是过多的索引会降低数据的性能，因此选择数据结构和类型的时候应该考虑索引的平衡。

下例是因数据库设计导致的数据迁移问题。

宝硕公司在2004年开发了一套生产管理系统，根据当时公司的策略使用了Oracle 9i作为数据库。在2010年的时候，宝硕公司被实达公司收购，实达公司的策略是使用微软的SQL作为数据库。因此，需要将该系统的数据库由Oracle 9i转换为SQL数据库，在进行转换的时候，发现原有的一些数据格式无法转换，具体如图2-13所示。

如JOBS表中的ROUTINE_IDS字段的数据类型是NCLOB，是Oracle的一个特殊的对象存储类型，并不能直接转换到SQL数据库中。为此需要开发专门的数据转换软件或脚本，这将大大增加数据库转换的成本和时间。如果在当初设计的时候，可以使用其他常用的类型或使用其他表格来保存一对多的关系，则不会有这些额外的工作。

数据库的设计应该考虑到软件的生命周期和数据库技术发展方向，鉴于新版本总是兼容旧版本，没有特殊需要，数据格式尽量使用通用格式，对于有特殊要求的数据，可以用代码或自定义类型来转换数据。

2.4.4 软件功能设计

功能实现了信息的输入、处理和输出，同时它要求一定的交互操作来触发或激活功能的运行。无数个小功能（或者说是小算法）汇集成全部的功能，实现软件的作用。在设计功能的时候，我们应该注意以下几个方面。

独立性。一个功能只解决一个特定的问题，如加密和解密属于同一问题的两个方面，不要期望开发出一个全能的或者是万能的功能，这既不可能也不现实。特定的代码实现特定的功能，其好处在于代码精炼、执行效率高、交互性好、开发成功率高以及维护成本低。
多态性。一个特定的功能可以解决一个问题的多个方面或形式，如加密解密功能既可以解决64位加密也可以解决128位加密，既可以明文加密也可以图形加密。
自然性。功能的具体操作应该符合人使用的自然习惯，如按钮点击次序应该从左到右。

2.4.5 软件接口设计

接口是软件与软件、机器与机器、数据库与数据库之间的数据交换窗口。不同软件和设备之间是不能直接简单地进行数据交换的，一定要进行特定的转换和处理以后才能保证交换的成功和正确。开发人员一般认为只要拿到其他软件或系统的API（Application Programming Interface）或者SDK（Software Development Kit）就可以进行数据交换了。其实不然，如果接口没有设计好，就直接开发代码交换数据，很可能无法交换数据，或是交换过程不稳定，或是可以交换但是效率低下。因此设计好高效率规范的接口非常重要。

在设计接口的时候，应该遵循以下原则。

• 可获取。需要交换的数据必须是可获取的，而且要知道哪些数据是可获得的？是如何获得的？需要什么样的权限？
• 可转换。因为交换的数据格式可能是不同的，甚至是迥异的，所以获得的数据需要进行必要的转换，而且这种转换又要求是可行的和正确的。因此，在设计的时候就要定义好转换映射表和转换逻辑。
• 可验证。如果数据交换是要写入数据，则接口应该设计数据验证的功能，或者是由对方系统的API来验证。如果数据没有经过有效的验证，将导致严重的后果，甚至将原来好的数据篡改变成混乱的数据。
• 可调试。无论交换是读取还是写入数据，都要求其过程是可调试和可监控的，只有提供了可调试的接口，才有可能保障数据交换的质量。
• 回馈机制。如果交换是写入数据，当数据交换以后，接收数据的系统需要提供反馈信息给发送数据的系统。回馈信息包括成功或失败的状态和理由。回馈信息有助于发送系统的用户知道数据交换的情况和及时处理异常情况。
• 回滚机制。如果交换是写入数据，一旦数据交换失败，被修改的数据可以返回到修改之前的状态。
• 负载平衡。数据交换不能以牺牲系统的使用性能为代价。在设计接口的时候要评估数据交换对系统的影响，如运行时间、运行频率、网络通信、数据吞吐量等。开发人员有的时候只考虑技术层面，为了实现接口而开发接口，却忽视了关联影响。设计人员应该明确提出负载平衡方面的要求，避免发生接口拖累系统性能的情况。
• 可追溯。凡是通过接口进行交换的数据处理，都应该有历史记录，以方便追溯数据和了解当时的情况。IT审计非常重视数据的可追溯性，设计人员应该对此给予充分的考虑并提出明确的要求，以满足审计的要求。
  下例是因接口设计导致的数据交互问题。

华天（上海）公司使用Oracle公司的EBS作为本公司的ERP系统。为了能够节省大量的工作单打印纸，同时可以将纸张放入物料盘，计划将A4的纸张改成A5的尺寸。因此需要开发一套简单的打印工作单的软件，有关工作单的基本信息，BOM和制程将从ERP的数据库里定期同步过来。ERP的数据库服务器位于其母公司的总部美国洛杉矶，总部和上海分公司之间用2MB的带宽进行专线通信。

开发人员根据这个要求开发了多个数据库脚本，如表2-12所示。

这个接口设计完成后，通过了测试，也能够正常使用。但是在使用了1个月后，有人反应少数工作单的信息没有及时更新，导致投产数量和原材料领用发生错误，增加了报废。开发人员通过调试和检查，再次确认代码本身是正确的。测试环境和正式环境的差别在于，测试环境没有那么多的数据量。因此怀疑问题出在接口的同步上，通过将脚本运行的间隔时间调整为每2小时，则不再发生此类问题。但是如果运行间隔时间为2小时，则工作单信息更新不够及时，生产线要等待最少2小时后才能投产最新的工作单，会影响到产量。于是开发人员再三模拟，最后发现，只有当大量工作单出现的时候，才会发生这种情况。由于大量的工作单信息需要更新，加上网络带宽有限，结果前面一个脚本还没有执行完毕，后面一个周期的脚本又要执行了。开发人员于是将接口的工作机制做了如下修改。

• 优化脚本，将单个工作单的执行时间提升20%。
• 限制每次脚本更新的工作单数量，最大为100个。
• 将脚本的运行间隔时间调整为每45分钟一次。

通过上述改进，基本杜绝了工作单信息缺失和未更新的情况。由此可见，接口的质量和效率不仅仅取决于代码和逻辑，还取决于环境的影响。

2.4.6 软件设计评估

软件设计完成以后，是否符合用户的需求呢？这就需要和用户一起来确定。由于设计人员和用户出于不同的视角，因而他们对设计的意见不尽相同，有的时候还会争执不下。那么如何评估软件设计的成果呢？唯用户意见为准则是不可取的，唯设计人员意见为规范也是不客观的。最好的方法是采用打分制进行客观的评估，令双方心服口服。

软件设计的评估的考察点由以下几个方面组成。

• 可用性。可用性是指设计的功能都是可以实现的。
• 易用性。易用性是指设计的功能都是容易操作的。
• 完全性。完全性是指设计的功能所涉及的内容是完全的，该显示的都显示，无关的信息都不显示。
• 完整性。完整性是指设计的功能是完整的，在一个整体内的，没有缺失，没有遗漏。
• 一致性。一致性是指设计的功能，界面和操作步骤在一定程度上是保持一致的。
• 延展性。延展性是指设计的功能具有再次开发和扩展的能力。

只要满足了这6个基本要求，就可以认为软件设计是合格的。当然光是合格还不够，好的软件设计应该是超出用户预期的，因为这些设计可能是用户潜在的需求，不是必须要完成的，这并不和前面说的“够用”和“适用”原则矛盾。那么怎样才能超出预期呢？这里给出一些建议以供参考。

• 交互性。交互性是指在现有的功能上提供更多的反馈信息，如错误提示或中间过程，这样有助于用户理解数据和结果是怎么来的。
• 智能化。智能化是指在现有的功能上分析用户的常用操作和需求，将这些因素提炼出来，进行固化和总结。在用户使用时，提供自动计算和统计，即智能化操作，这样将有效地提高用户的工作效率，避免重复操作。
• 个性化。个性化是指在现有的功能上提供可以让用户自由选择的一些算法和操作方式，并把这些特点记录下来，方便用户快捷地使用。
  下面的例子说明了如何评估软件设计的内容。

明志公司委托一家软件公司开发了一个简单的仓库入库和领料系统。软件公司完成了设计，明志公司电脑部的软件经理对供应商提供的设计方案进行了评估。评估表的部分内容如表2-13所示。

表2-13中的每项评分范围从1到10，10为最符合，1为最不符合。如果某项没有必要进行评估，则可以不计分。综合分为计分项的平均分。

通过对设计页面和功能的打分，可以有针对性地、客观全面地评估设计结果，避免了人为的因素和主观的喜好。

2.4.7 软件设计文档

软件设计文档是对软件设计思路和方案的记录，该文档通常包括以下内容。

• 术语。术语包括两方面的内容，一是特指业务中的专业术语，如折旧、四班三运转等，因为不是每个开发人员都非常了解和精通业务，详细地说明术语，有助于开发人员理解业务。此外，软件的术语也需要做一定的解释，如异步处理、多线程、组策略等，因为用户对软件的认知程度是不一样的。
  软件结构。说明软件的整体结构，主要模块的组成，各个模块的作用和相互之间的联系。
• 流程说明。流程对于软件开发至关重要，如果把软件比作是身体的话，流程就是血液，只有流程对了，软件的功能才对。把流程用图画的形式表现出来，可以清晰地说明流程的来龙去脉，方便开发人员理解，这样软件的功能才能符合用户的实际需要，同时也有利于和用户确认设计的正确性。
• 界面。界面是用户和软件交互的介质，将基本的界面用图画的形式表现出来，可以让用户和开发人员更明确地知道软件提供了什么内容和功能，是否和用户的预期吻合。界面上需要填充一些必要的数据，当然可以是一些虚拟的数据。
• 操作步骤。说明界面操作的步骤，使用户明白界面中元素、控件是如何使用的，例如如何查询数据、如何保存、如何修改等。用户通过了解操作步骤能够判读软件设计的功能是否方便，是否符合习惯，同时让开发人员明白如何实现界面的功能。
• 计算方法。说明数据计算的方法，如公式、条件、例外等，如果能够附上推演的细节则更有助于用户确认和开发人员理解。
• 数据结构。说明数据的关系，特别是关系型数据库各实体之间的关系，以及数据的格式。
• 数据接口。说明接口的作用，链接的平台或系统，以及数据输入和输出的方法。为了保证数据接口被准确地使用，应该提供规范的数据示例。
  技术要求。说明软件开发使用的技术类型，如开发语言、脚本类型、数据接口、运行的技术要求，如服务器操作系统的版本、语言要求、字符集、磁盘空间大小和速度、内存大小、数据库的版本、存储路径、数据备份要求、客户端设备的型号、打印机的型号等。其中的一些参数将直接影响到软件性能和质量，比如32位还是64位，单一语言还是多语言显示。

案例9：从用户的需求出发提升软件设计
案例背景
斯特软件公司专门为全国的厨具制造商提供电子商务销售平台，该平台运行了一年多后，月度注册用户和销量始终维持在1万人和40万左右，连续几个月都没有显著增加。投资方对于平台的业绩非常不满意，希望尽快改变这种现状。斯特软件委托京通咨询公司通过多种渠道和方法收集用户的使用体验，经过大量细致的分析和比较，发现问题主要集中在以下三个方面：

（1）商品分类方式不适合。根据数据库的追踪数据显示，只有2.1%的用户在打开首页后能够在3次点击内（含第3次）完成订单。大部分客户在打开首页后就放弃了继续浏览，原因之一就是首页的商品分类菜单方式。客户一般出于两种目的浏览购物网站，一是无目的性地随便逛逛；二是有目地性地购买某个商品。对于第一类客户，商品的准确分类不能起到很大的吸引作用，因为客户的关注度不是商品的规格，而是商品的特点。对于第二类客户，因为他们有明确的购买目的，所以希望在第一次看到菜单时就能找到自己所需要的分类，如果经过第二次尝试还是没有找到所需要的分类，绝大部分的客户会放弃购物。

（2）“加入购物车”按钮位置不合适。最初的设计思想是，为了多给商品的照片和规格留出显示的位置，“加入购物车”按钮被放置在右下角。但是根据Complete公司对全球多数电子商务平台的调研的资料显示，“加入购物车”按钮的位置会直接影响到用户下单的第一意愿，以Wal-Mart和Target网站为例，其不同的“加入购物车”按钮的位置，导致“点击成交率”差异为9%左右。这就意味着如果客户喜欢该产品，但是因为没有注意到“加入购物车”的按钮而没有能够在第一时间下单。

（3）相同页面过多。即使是不同品牌、不同类型和不同包装的厨具，不仅其页面布局相同，绝大部分的文字内容也是相同的。明显不同的地方只有品名和规格，商品描述部分由于使用了嵌入框架技术（Iframe），其代码部分是通过另外一个页面（不同的URL）传递的。Google 对超过25%以上不同内容的网页才会认为是独特的网页，才行收录。因此在网站搜索方面，很多商品被引擎算法过滤掉，大大地降低了无目的性用户搜索到商品的机会。这是当初为了节省开发成本而始料未及的。

案件分析
斯特软件公司组成专门的业务改善小组，进一步完善平台结构和功能。改善小组针对京通公司提出的三点问题，逐项给出了改进的方案。

（1）首页分类菜单重新设计，不再以品牌为一级分类，改成按商品功能来分类。由于品牌认知度的不同，客户的第一动作就会去点击自己熟知的或者是排位靠前的品牌。但是从品牌代理的角度而言，一两种知名品牌对于销量的贡献并不是很大，相反有些小品牌的利润率却是很好。另外如果知名品牌的商品不能经常性地推陈出新的话，客户很快就会对平台失去兴趣。如果去除品牌的分类，在同一类商品中显示所有品牌的商品，将丰富页面的内容，同时多个品牌商品的不断更新也将满足客户尝鲜的心理。按照商品类别分类的另一个好处是满足了有目的性购物客户的快速定位要求。

（2）将“加入购物车”按钮放置在商品标价的下方，网页中部突出位置。无论客户是否对商品满意或者最终是否下单，都给以客户下单的意识驱动，增加客户购物成交的可能性。

（3）改变商品描述页面的代码，在保持总体风格一致的前提下，区别性地显示商品内容，对于不同类型的商品，使用不同的描述模板和主题颜色。依据商品的特点，增加精炼的广告性描述语。去除Iframe的结构，将所有HTML代码通过一个URL传递到客户端的浏览器。

平台开发组根据改善小组的意见，加上其他改进措施，很快推出了新版本。新版本上线后，给人以全新的感觉和体验，用户注册数量成倍增长，用户访问变得越来越频繁，销售量有了明显提升。

案例启迪
软件的设计不是一成不变的，一旦它不能满足业务的要求，就必须重新评估和做出调整。调整的原则依然是面向用户的“适用”和“够用”的原则。

案例10：从业务的角度出发提升软件设计
案例情景
宝硕公司被收购以后，其企业的文化也逐渐受到新公司的影响。新公司的一个显著特点就是业务管理完全依赖于系统数据，系统提供了强大的数据分析和处理功能。因此，宝硕公司的新管理层团队希望现有的系统可以提供更多智能化的和人性化的功能。开发人员经过收集和分析需求，结合过去用户反馈的一些问题，觉得现有的系统在以下几个方面可以增加一些更方便的功能，如表2-14所示。

案例分析
多从用户的角度考虑，就能发现很多有价值的改进空间。就好比房子，已经装修好了，只要添置家具和家电就可以住人了，软件本身就提供了坚实的使用基础，只要不断地在细节方面改进，软件设计就能做到出类拔萃。