《信息技术工程导论》课件第4章 工程解决方案

第4章工程项目解决方案4.1概述4.2工程项目的前期策划——需求分析

4.3项目解决方案中的设计说明书4.4工程解决方案案例4.1概述项目开发的成败建立在自我不断创新和高质量满足客户要求的基础上，建立在对“需求、问题或机会”的识别能力以及提出相应解决方案的能力。一个项目的启动和完成，都需要一个精心准备和策划的过程，因此在学习和撰写项目解决方案开始时，首先了解项目从启动到完成的整个过程。

一个工程项目一定会有两个角色，即工程项目的需求方和工程项目的实施和完成方，这两个角色我们一般称之为甲方和乙方，甲方一般是项目需求方和出资方，乙方一般是项目的实施方。项目立项必须先由需求方——撰写项目可行性分析报告，且通过甲方领导批准，然后成立相关临时团队或机构负责该项目，即甲方建立。投资金额超过20万人民币以上（含20万），必须招标，因此在招标前一个月，甲方必须完成招标文件，招标文件中必须说明项目需求分析、项目所需的技术指标和项目实施单位的资质。-可行性报告（包含简单的项目需求分析

）中须写明如下几点：

（1）为什么必须完成个项目？对相关单位和部门有什么好处（从提高工作效率和产品质量、降低成本、减少污染的角度说明）。（2）行业内（或国内外）有无类似项目？是引进还是重新开发？为什么？（3）说明和计算开发成本和周期，以及何时能收回投资成本和获益。（4）建议由哪个部门和人员负责。

招标文件一般要在政府指定的招标网上公布。

对该项目有兴趣且能完成和符合招标文件要求的单位，可以到政府指定的招标公司购买标书。在规定的时间了解甲方需求，提交投标文件（含项目解决方案或设计方案），参与竞标。按照国家规定投标方必须超过3家，否则为废标。

在竞标中获胜者为中标者，其与甲方拟定项目开发合同，在合同中中标方被称之为乙方。低于20万人民币的项目一般采取议标，即想参与该项目实施的单位到甲方购买标书，然后在甲方单位参加项目答辩。同上，获胜者为中标方，且与甲方签定项目相关合同。

乙方的投标文件一般包含项目的解决方案，但该解决方案一般不是项目验收的项目解决方案。甲乙双方签订合同后，第一步就是乙方要了解甲方的项目需求，一般项目需求分析报告由甲方提供，但鉴于甲方对技术的掌握程度，因此该需求分析报告最后都是乙方完成。

甲方：（用户、客户）乙方：（开发单位）项目可行性分析报告立项项目需求分析报告

（招标书）项目解决方案

（方案设计说明书）（投标书）（项目开发计划）这一工作完成的是否出色对获取客户合同以及能否成功完成项目的开发和产品的推广至关重要。

-工程项目开发的前期构思4.2工程项目的前期策划——需求分析在获取客户合同后，即进入工程项目开发期。（如4+5+1方式，就可获取项目的首付款40%。）乙方一旦将项目列入开发计划，就应该集中技术人员、成立项目组、确定项目负责人进行实质性的项目开发工作。

参见合同范例为了使项目顺利开展，乙方要明确甲方的需求，甲方的需求往往是潜在的，要使这种需求明确化，需要与甲方相关部门的关键人员进行反复的沟通，通过沟通明确甲方业务流程及实际需求，必要时乙方提出需求建议书。对于软件开发来说，此过程为一个将具体问题进行抽象和建模的过程，然后对模型进行可行性分析，得出结论。为下面的项目实现（编程、调试）做出充分准备。在项目实施过程中，所有的依据应该原于甲方的需求和当前技术允许范围。

甲方的需求在目前阶段体现为招标书中的解决方案，而技术允许范围是指根据当前项目组的技术水平来估计项目组的技术能力，保证应用的方案必须是可行的。4.2.1项目需求分析说明项目需求包括三个不同的层次—业务需求、用户需求和功能需求——也包括非功能需求。-业务需求反映了组织机构或客户对系统、产品高层次的目标要求。-用户需求指用户使用产品必须要完成的任务。

-功能需求定义了开发人员必须实现的系统功能，使得用户能完成他们的任务，从而满足了业务需求。-非功能需求包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。对于我们所拿到的“项目需求分析报告”往往忽略了很多客户的隐形需求。一般而言包括：

-维护需求

-升级需求

-易用性需求

-性能需求

现在客户也在不断成熟，以上需求会或多或少的提到，但是，请注意，很可能不够全面。所以我们需要认认真真的考虑一下，这些需求到底应该包含些什么。（1）维护需求客户对维护的要求，一般至少包括：

①日志需求。日志需求是和客户的隐性需求密切相关，并且几乎全部涉及的一种需求。

例如：日志要记录维护信息和升级信息，日志还要简单明了，一看就知道写的啥意思，另外日志记录功能还不能对系统的性能有大的影响。

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

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

④故障报警。当系统出现严重故障时，能够给出足够的信息，并触发故障处理流程。（2）升级需求客户对升级的要求，一般至少包括：

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

②不影响业务的升级。基本上客户都希望升级不要影响他们的正常业务。但是有些系统实在太老了，基于这种旧系统的再开发项目必然受限于原系统的升级方案。这时就要考虑：

-能不能通过升级，使系统以后升级不再影响业务；-如果不能，怎样使（本次）升级对业务的影响最小；-升级的简单性，升级应该简单快捷，没有太多的参数需要配置，没有太多需要手工干预的步骤；-升级的完整性，尤其是对于分布式系统，升级时需要考虑各个部件之间版本的一致性。一个升级方案必须是完整的，不能在升级以后出现由于版本间不兼容的原因而导致系统无法工作。例子：一个简单的C/S系统，采用加密通道进行通讯，现在升级加密算法，该如何设计呢？假设是互联网应用，有上万个客户端，该如何设计呢？从这个例子可以看出，系统的设计，从一开始就必须考虑这些“隐性”需求，否则系统架构有可能推翻重来。

（3）易用性通常提到易用性，一般觉得无非是界面和帮助。没错，但是不全。让我们看几个例子，可以大概理解一下易用性是什么概念。

在桌面系统的竞争中，专业而强大的Unix败给了经常被人批评的Windows。

windows安装、升级简单，安装新的软件也很简单，操作起来更是如此，直观的图形界面虽然设计和功能不太丰富和强大，但是相对于unix必须先学习“文件系统”概念，再学习命令行而言，“树”的概念用户可以无师自通，拖拽更是命令行方式不可比拟。

同样是微软，C++语言乘微软之名，挟操作系统之利，语言和开发环境都不可谓不强大，但是结果怎样呢？多数人情愿用Java，微软更是不得不推出C#来与Java抗衡。在中文输入法的竞争中，强大高效的笔画输入法败给了拼音输入法。现在拼音输入法大行其道，笔画输入几乎鲜有提起。

易用性的关键是业务模型要和客户的一致。这个应该算是基础。业务模型代表着思维模式（比如输入法），也就是说，要从客户的角度来设计系统。操作应该照顾客户的习惯，尽可能的降低客户的学习成本。当然，前提是正确定位你的客户群。

一般而言，易用性的需求还包括：

1.常用的功能应该能够直接了当的访问如财务系统，不同的角色有不同的常用功能，系统应该设计为可以根据角色来打开不同的初始页面；2.操作应该照顾客户的习惯可降低客户的学习成本。当然，前提是正确定位你的客户群。

3.优雅还是用微软的VisualStudio做例子，编译错误可以直接通过双击跳转到源代码所在错误点，而不像Makefile那样只是生硬的输出文件和行号。打开一个巨大的文件，给出一个可度量的进度条，总比只显示一个沙漏要好吧？“优雅”=专业+体贴（4）性能需求在软件系统开发的编写合同或者招标书时，经常有性能需求方面的章节。在编写这部分内容时，文档撰写人经常会觉得无从下手。性能需求具体要求涉及如下几个方面：

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

②知道自己的“承受上限”。达到上限的时候，通过合理的方法让系统给予提示，而不是直接瘫痪。例如在软件系统的性能需求细节上包括：长时间运行要有提示；已输过的内容尽量不要再次输，必要时用下拉列表框来选；命令按钮要有悬停帮助信息；因权限或操作条件限制时，有关操作元素自动置“灰”或不可见；不离开编辑界面添加新内容时，可用鼠标也可用键盘定位至输入字段；不能输入不合理的日期等等。

性能需求例子：

实例一：

1.

时间特性的要求：

1)普遍情况下：

●搜索时间最大不超过5秒

●平均时间在1～3秒以内

2)1860前台（业务知识库）：

●知识文档的搜索不超过1秒

●知识文档的搜索与打开合计时间不超过3秒

●平均在1秒内

2.

系统容量要求

●静态用户（注册用户）：3500以上

●动态用户（在线用户）：1500以上

●并发数：500以上实例二：

●检查系统在2000个用户的负载下，所有业务动作是否可用及稳定；

●检查系统在2000个用户的负载下，连续运行72小时过程中，订单上传、转单、详情单查询、发运、勾核、签收及邮路填报功能等业务动作是否可用及稳定；

●检查系统在1500个用户、500个并发用户操作的负载下，连续运行72小时过程中，以上业务动作是否可用及稳定；

●检查系统在8.0GB业务数据、1500个用户、500个并发用户运行的负载下，连续运行72小时过程中，以上业务动作是否可用及稳定。

只有对需求进行分析、总结和概括，提出准确可行的解决方案是非常重要的。因为只有这样才能明确用户项目的内容和目标，准确评估自己成本，提出一个确实可行的项目解决方案。

—工程项目开发的前期

构思/项目可行性分析报告/项目需求分析报告

方案设计说明书隐形需求◆维护需求:日志需求

/故障定位的能力

/日常维护

/故障报警

◆升级需求:可控制/不影响业务/简单性/完整性◆易用性需求:Unix与Windows/笔画输入法与拼音输入法/VC与Java

常用的功能应该能够直接了当的访问操作应该照顾客户的习惯优雅◆性能需求：分清楚软件各部分都有什么样的性能需求/用户参与的操作，性能要求通常高于其他操作/极限提示避免瘫痪/小结：用户需求4.2.2项目需求分析的理解

把握好需求分析对系统的开发是至关重要的。在撰写系统解决方案时，常常把自己当成用户，按照自己的思维设计系统，要弄清需求分析的三个层次，即：什么是业务需求、用户需求和功能需求，千万不要混为一谈。

举个例子来说明前面介绍的三种需求分析：

一个生产自行车厂的经理对开发者说，我们希望开发一种受市场欢迎的儿童自行车，这是业务需求；这时开发者就要了解市场上家长和儿童对自行车的要求，如为了防止自行车摔倒，要在自行车后轮添加两个侧轮，如最好能折叠用于现在家用汽车托运，要能在骑行中播放音乐等，这是用户需求；自行车的座位采用软质材料做成的椅子，自行车的车架放矮便于小孩上下车，链条外有盒子保护，以防挂着小孩等，这是功能需求。下面我们再通过一个超市管理系统软件的需求分析人员与超市不同人员的对话来理解不同性质的需求分析。超市经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，实现总部-门店的连锁经营的计算机管理模式。达到门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。”上述表达表明超市经理给出了该软件的业务需求，这是很重要的，它说明了系统的作用和目的。分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”超市经理觉得奇怪：“我不是刚告诉你我的需求了吗？”分析员：“实际上，您只说明了整个项目的概貌和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”注意：用户需求和功能需求一定是下面的操作人员（系统用户）提出的，必须与这些人员沟通才能获得。经理层的人员通常阐明产品的高层次概貌，即各模块的主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“各模块的主要业务需求”的规定。经理层有时试图代替实际操作人员说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。分析员尽量给超市经理解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。无数的案例表明，未真正明白这些问题就开始编码，结果没有人对产品满意。”最后分析人员要从超市的工作人员那里获得用户需求以及性能需求，还要注意的是，在了解这些需求是，一定要了解当前超市是否在使用类似的、或者具有部分功能的系统，如果有，一定要对这些系统的操作界面和操作方式有一个清楚的了解，这样保证所开发的新系统兼容原来系统的用户操作习惯，避免不必要的超市工作人员学习成本，因为不同的操作模式带来的学习成本，会给新系统带来不必要抱怨，导致经理层认为系统使用有问题，除非新系统的操作模式改革可以大大减少操作步骤。用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种系统客户，他们清楚要使用该产品完成什么任务即功能性的特性需求。此外，还有一些非功能性的特性需求。例如：系统必须遵从的标准、规范、程序的易用性、健壮性和可靠性等，而这些特性将会使用户很好地接受具有该特点的系统。以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段倍感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，是开发出一个优秀的软件产品的基础，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。由此可见，需求分析奠定了工程项目管理的基础。开发软件系统最困难的事情就是准确说明开发什么。最为困难的工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。

为什么这么说呢，因为在大多数的软件系统中，最终用户可能都不清楚他的需求是什么，这是千真万确的。如果你的用户告诉你需求就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。虽然听上去有些不可思议，但这是教训之谈，几乎没有一个用户在软件接近完成的时候会不提出更改要求。

在实际工程项目开发过程中，客户项目经理通常阐明产品的高层次概貌，即各模块的主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“各模块的主要业务需求”的规定。经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。在实际需求分析过程中，如果您希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。

优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。4.2.3项目开发中的沟通

沟通是一门艺术，也是能力。不论目的是为了自信地演说、轻松地谈判，还是愉快地销售，它都将协助有效的增进信息传递——沟通的技巧。

交流沟通是人类行为的基础。但是交流沟通是否能准确传达出愿望、或对某事的态度，是非常重要的能力。良好地进行交流沟通是一个双向的过程，它依赖于您能抓住听者的注意力和正确地解释您所掌握的信息。

良好沟通的有这样一些益处：

（1）能获得更佳更多的合作；（2）能减少误解；（3）能使人更乐于作答；（4）能使人觉得你的话值得聆听；（5）能使你办事更加井井有条；（6）能提高你进行清晰思考的能力；（7）能使你感觉现能把握所做的事。1.沟通的分类

按沟通的形式有四种类型：正式沟通、会议、非正式沟通和报告报表。①正式沟通指按照合同规定的程序或格式进行的具有一定合同约束效力的沟通，包括信函、传真。现在很多信函、传真经相关人员的草拟、审核完毕后，经过合同授权人签字或盖章扫描后，利用合同指定的项目邮箱进行传送，当对方收到后，通过邮箱发送回执确认，而不必要送达原件到对方。②会议

包括按照合同规定召开正式例会和不定期的专项会议，并形成会议纪要备查，参加会议的人员应具有所讨论问题的决策权力。由于信函、传真、会议纪要具有相应的约束力，双方交流时都比较慎重，导致沟通过程中很多真实的信息不愿意透露。③非正式沟通：

指口头交流、电话联系、私人间邮件往来。这种沟通方式更方便快捷。由于沟通的信息或结果没有合同的约束力，所以交流时彼此警惕性不高，表达的信息有些比较真实，对方的某位人士可能会透露目前项目存在的一些问题。

④报告报表：指按照合同规定定期提交的日报、周报、月报，或者按照合同提交的各种审批表单，如材料审批单、加班许可申请表等。按沟通的对象可以将沟通分为：对外沟通和内部沟通。

-对外沟通：凡是以经济合同为基础进行合作的项目团队叫外部单位，与外部单位进行的交流沟通叫对外沟通。

-内部沟通：内部沟通指团队内部各个职能部门间的交流讨论。①对外沟通对外沟通尽量采用正式沟通和会议的方式进行。

对外沟通要以合同条款为依据。合同是双方交流的基础，也是判断双方对错的唯一标准，所以首先我们要深入学习合同，不论是商务条款还是技术标准，与交流问题相关的都要清楚知晓，否则就会显得我们很不专业。与外部进行交流沟通应注意的问题：

-注意交流沟通的时效一般国际工程项目都规定某类问题提出和答复期限。比如，一般的国际项目发生索赔时，索赔方要在发生28天内提出索赔申请，超过28天，索赔无效。对方提出的变更申请单一般要在7个工作日内答复，超过期限不答复就等于同意对方的变更申请。

-不要轻视非正式交流在对外交流沟通中，正式沟通的形式很重要，但是非正式交流也不能轻视。很多正式交流沟通前都要先做大量的非正式交流，以增进双方的理解和共识，为正式沟通排除障碍，铺平道路，这样正式沟通中才能比较容易的达成结果，提高正式交流的效率。

-对外沟通中要把握原则以合同为依据，以非正式交流为铺垫，以正式交流为准绳，以书面双方签字的书面材料为结果，履行好合同义务和权利，建立维护良好的客户关系。②内部沟通内部沟通指团队内部各个职能部门间的交流讨论。内部沟通提倡非正式交流，发挥主管领导的协调作用。在一个团队内，过多的正式交流会导致大家过分的责任分明，阻碍了双方充分交流的渠道，影响了部门间协同配合的深度，导致一些工作推动无力。工程项目实施本来就是在问题中寻找办法，逐步推进的过程，只有大家集思广益、密切配合、精诚合作，才能把项目完成。同时也看到，领导在项目团队中的重要作用，对项目团队遇到的问题，要善于判断问题的症结，积极协调，敢于拍板，勇于承担责任。在团队中，要建立开放的交流沟通团队文化：一个论资排辈、工作岗位级别鲜明的团队里表达观点时就会谨小慎微，不敢轻易发言，很难做到集思广益、协同配合。一个开放的团队里踊跃发言，各抒己见，不自觉地表达意见，可发挥每个人的聪明才智。

项目经理在遇到不符合开放交流文化的做法时，要坚决制止，不要放纵。在员工看来，不制止就等于提倡。2.沟通的技巧开会讨论是团队交流沟通的一个有效手段。团队内部的会议，不同于对外沟通的会议，其目的是把多人召集起来集思广益，寻找问题的最佳解决方案。既然是讨论就难免有人表达的观点不恰当，进行反驳时，要注意讲话的方式，要做到对事不对人，不要给人造成有人身攻击的感觉，影响发言人的热情，伤害同事间的感情。-恰当的时间终止不同解决方案的争论，在对探讨解决方案效果不大，作为部门领导，要在适当的时候终止争论，进行总结发言，确定解决问题的最佳方案。-明确沟通的目的项目沟通首先要有明确目的。沟通前，项目经理要弄清楚作这个沟通的真正目的是什么？要对方理解什么？确定了沟通目标，沟通的内容就围绕沟通要达到的目标组织规划，也可以根据不同的目的选择不同的沟通方式。

其次，要做到充分的“听”与艺术的“说”。项目经理只有集中精力地听，才能领会讲话者的意图，只有领会了讲话者的意图，才能选择合适的语言和方法进行沟通。

沟通是人们获取信息并在其指导下更加出色地进行工作必经的核心过程。良好的沟通不仅意味着把自己的思想整理得井然有序，并将其进行适当的表述，使别人一听就懂，而且还要深入人心，促使听者全神贯注。-良好沟通的益处：能获得更佳更多的合作；能减少误解；能使人更乐于作答；能使人觉得你的话值得聆听；能使你办事更加井井有条；能提高你进行清晰思考的能力；能使你感觉现能把握所做的事。

良好地进行交流沟通是一个双向的过程，它依赖于您能抓住听者的注意力和正确地解释您所掌握的信息。

从理论上讲人与人之间最好是坦诚相见，取长补短，优势互补，这样就容易结交成为好朋友。技巧是用来做表面工作，平和他人心态，让人逐步逐步接受的过程。所以只能具体事情具体办理，灵活运用，不可千篇一律。

人性对赞赏比较认同,在适当时候不妨用欣赏的眼光,赞美他人的优点，这样对方就会产生成就感，容易认同你为知己而继续深入交往。

结交他人应寻找双方的共同点，谈一些互相感兴趣的话题，只有志同方可道合。

对人提出批评，应该先肯定对方优点，再讲自已的看法，不可力争要嬴。要具备一颗仁慈之心,多行善事，用行动帮助他人，这样人家就会心生感激之情。

当人家帮助了你，应滴水之恩当涌泉相报。这样当遇困难之时别人就乐意帮你度过难关。

总之，当你以独特的人格魅力展现在他人面前，有时不用你操心，别人会以你为标榜调整心态，交往自然会顺利。4.2.4需求分析中的沟通和确认

需求分析沟通的目的除了完成技术性能指标详细说明外，还有完成“需求确认”，即在“需求分析说明书”上签名。

对“需求分析说明书”的签名是建立在一个需求协议的基础上，因此甲乙双方对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基础上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”

对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。下面给出甲乙双方沟通中，遵守的20条法则：1、分析人员要使用符合客户语言习惯的表达

2、分析人员要了解客户的业务及目标3、分析人员必须编写软件需求报告4、报告中各种图表的解释说明5、开发人员要尊重客户的意见6、开发人员要对需求及产品实施提出建议和解决方案7、描述产品使用特性8、允许重用已有的软件组件9、对变更的代价提供真实可靠的评估10、满足客户功能和质量要求11、给分析人员讲解您的业务

12、抽出时间清楚地说明并完善需求

13、准确而详细地说明需求

14、及时作出决定

15、尊重开发人员的需求可行性及成本评估16、划分需求的优先级

17、评审需求文档和原型（用户体验设计）

18、需求变更要立即联系并按规定处理19、遵照项目变更控制过程要求进行变更

20、尊重开发人员采用的需求分析过程

4.3项目解决方案中的设计说明书

在项目解决方案中最重要的部分是设计说明书，它体现了设计系统的技术性能和水平，设计说明书一般有两个部分组成，即概要设计和详细设计。4.3.1概要设计

概要设计说明书（简称概要设计）是针对系统的整体设计，如系统组成结构划分、功能划分等。本章所有下面案例都是采用软件系统设计进行说明。一个软件系统的概要设计编制的目的是说明对系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。

概要设计说明书（简称概要设计）是针对系统的整体设计，一般一个简单的概要设计是由文字说明、结构图、方框图和表组成。作为较为复杂的系统，其概要设计的主要内容包含如下：

1．引言及背景部分：引言、背景、相关定义和设计参考文件与标准。

2．结构及流程部分：是概要设计的核心，包括需求规定、运行环境、基本设计概念和处理流程、系统结构、功能需求与程序的关系、人工处理过程、未解决的问题。

3．接口设计部分：是为详细设计定义各个模块如何连接的内容：用户接口、外部接口和内部接口。

4．设计控制部分：说明各个模块的组合和运行关系。

5．系统数据结构设计：是对系统数据格式的定义、数据存储和访问方式的简要说明。

6．系统出错处理设计：说明系统运行和维护过程中如何处理的技术说明。4.3.2

详细设计说明书

详细设计说明书（简称详细设计）在概要设计的基础上进一步明确系统结构，详细地介绍系统的各个模块，为进行后面的实现和测试作准备。详细设计的内容主要有：引言、程序系统的组织结构、程序设计说明。

1．引言：内容与概要设计类似。

2．程序系统的组织结构：用一系列图表列出程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间的层次结构关系。

3．程序设计说明：是详细设计的重点，该部分逐个地给出各个层次模块中的每个子程序的设计考虑。它包含：程序描述、功能、性能、输入项、输出项、算法、流程逻辑、接口、存储分配和注释设计。4.3.3工程项目解决方案的其他部分

在工程项目解决方案中，除了说明需求分析、概要设计和详细设计外，还有其他一些内容，这些内容包含以下几个方面。1.工程项目组织管理

当承担一个项目后，项目承担方（常常是乙方）一般会组织专门人员来完成，同时也需要项目承担方的多个部门或者小组协同配合完成，为了说明各个部门或小组在项目中所起的作用，常常在工程解决方案中会用结构图说明。项目组织结构图反映一个组织系统(如项目管理班子)中各子系统之间和各元素（如各工作部门）之间的组织关系，反映的是各工作单位、各工作部门和各工作人员之间的组织关系。

而项目结构图描述的是工作对象之间的关系。项目组织结构图反映项目经理和费用（投资或成本）控制、进度控制、质量控制、合同管理、信息管理和组织与协调等主管工作部门或主管人员之间的组织关系。2.工程项目工期计划一个成功的项目管理，其必然也是成功的时间管理。而项目工期的拖延，即便其质量优异、成本低廉，也可能由于时间的滞后而变得不再适宜。因此，项目的时间安排在工程项目中显得尤为重要。项目时间管理的首要任务是制定项目的进度计划，其目的在于：保证按时获利以补偿已经支出的费用、协调资源的调配、调整工作内容的优先级、满足严格的时间约束。在工程解决方案中常常用图来表示工程项目进度计划，编制工程项目进度计划一般可借助于两种方式，即文字说明与进度计划图表。其中，常用的进度计划表包括：（1）横道图：又称甘特图（Gantt），是应用广泛的进度表达方式，横道图通常在左侧垂直向下依次排列工程任务的各项工作名称，而在右边与之紧邻的时间度度表中则对应各项工作逐项绘制道线，从而