个人网站策划书范文

网络规划与需求分析

需求分析从字面上的意思来理解就是找出"需"和"求"的关系,从当前业务中找出最需要重视的方面,从已经运行的网络中找出最需要改进的地方,满足客户提出的各种合理要求,依据客户要求修改已经成形的方案

本章重点

21需求分析的类型

22如何获得需求

23可行性论证

24工程招标与投标

221应用背景分析

应用背景需求分析概括了当前网络应用的技术背景,介绍了行业应用的方向和技术趋势,说明本企业网络信息化的必然性

应用背景需求分析要回答一些为什么要实施网络集成的问题

(1) 国外同行业的信息化程度以及取得哪些成效

(2) 国内同行业的信息化趋势如何

(3) 本企业信息化的目的是什么

(4) 本企业拟采用的信息化步骤如何

需求分析的类型

P33

221应用背景分析

应用背景需求分析要回答一些为什么要实施网络集成的问题

(1) 国外同行业的信息化程度以及取得哪些成效

(2) 国内同行业的信息化趋势如何

(3) 本企业信息化的目的是什么

(4) 本企业拟采用的信息化步骤如何

需求分析的类型

P33

222业务需求

业务需求分析的目标是明确企业的业务类型,应用系统软件种类,以及它们对网络功能指标(如带宽,服务质量QoS)的要求

业务需求是企业建网中首要的环节,是进行网络规划与设计的基本依据

需求分析的类型

P33

222业务需求

通过业务需求分析要为以下方面提供决策依据:

(1) 需实现或改进的企业网络功能有那些

(2) 需要集成的企业应用有哪些

(3) 需要电子邮件服务吗

(4) 需要Web服务吗

(5) 需要上网吗 带宽是多少

(6) 需要视频服务吗

(7) 需要什么样的数据共享模式

(8) 需要多大的带宽范围

(9) 计划投入的资金规模是多少

需求分析的类型

P33

223管理需求

网络的管理是企业建网不可或缺的方面,网络是否按照设计目标提供稳定的服务主要依靠有效的网络管理高效的管理策略能提高网络的运营效率,建网之初就应该重视这些策略

需求分析的类型

P34

223管理需求

网络管理的需求分析要回答以下类似的问题:

是否需要对网络进行远程管理,远程管理可以帮助网络管理员利用远程控制软件管理网络设备,使网管工作更方便,更高效

谁来负责网络管理;

需要哪些管理功能,如需不需要计费,是否要为网络建立域,选择什么样的域模式等;

需求分析的类型

P34

223管理需求

选择哪个供应商的网管软件,是否有详细的评估;

选择哪个供应商的网络设备,其可管理性如何;

需不需要跟踪和分析处理网络运行信息;

将网管控制台配置在何处

是否采用了易于管理的设备和布线方式

需求分析的类型

P34

224安全性需求

企业安全性需求分析要明确以下几点:

企业的敏感性数据的安全级别及其分布情况;

网络用户的安全级别及其权限;

可能存在的安全漏洞,这些漏洞对本系统的影响程度如何;

网络设备的安全功能要求;

需求分析的类型

P34

224安全性需求

网络系统软件的安全评估;

应用系统安全要求;

采用什么样的杀毒软件;

采用什么样的防火墙技术方案;

安全软件系统的评估;

网络遵循的安全规范和达到的安全级别

需求分析的类型

P34

225通信量需求

通信量需求是从网络应用出发,对当前技术条件下可以提供的网络带宽做出评估

需求分析的类型

P35

应用类型

基本带宽需求

备注

PC连接

144kb/s~56kb/s

远程连接,FTP,HTTP,E-mail

文件服务

100kb/s以上

局域网内文件共享,C/S应用,

B/S应用,在线游戏等绝大部分纯文本应用

压缩视频

256kb/s以上

Mp3,rm等流媒体传输

非压缩视频

2Mb/s以上

Vod视频点播,视频会议等

表2-1 列举常见应用对通信量的需求

225通信量需求

未来有没有对高带宽服务的要求;

需不需要宽带接入方式,本地能够提供的宽带接入方式有哪些;

哪些用户经常对网络访问有特殊的要求 如行政人员经常要访问OA服务器,销售人员经常要访问ERP数据库等

哪些用户需要经常访问Internet 如客户服务人员经常要收发E_mail

哪些服务器有较大的连接数

哪些网络设备能提供合适的带宽且性价比较高

需要使用什么样的传输介质

服务器和网络应用能够支持负载均衡吗

需求分析的类型

P35

226网络扩展性需求分析

网络的扩展性有两层含义,其一是指新的部门能够简单地接入现有网络;其二是指新的应用能够无缝地在现有网络上运行

扩展性分析要明确以下指标:

(1) 企业需求的新增长点有哪些;

(2) 已有的网络设备和计算机资源有哪些

(3) 哪些设备需要淘汰,哪些设备还可以保留

(4) 网络节点和布线的预留比率是多少

(5) 哪些设备便于网络扩展

(6) 主机设备的升级性能

(7) 操作系统平台的升级性能

需求分析的类型

P35

227网络环境需求

网络环境需求是对企业的地理环境和人文布局进行实地勘察以确定网络规模,地理分划,以便在拓扑结构设计和结构化综合布线设计中做出决策

网络环境需求分析需要明确下列指标:

(1) 园区内的建筑群位置;

(2) 建筑物内的弱电井位置,配电房位置等;

(3) 各部分办公区的分布情况;

(4) 各工作区内的信息点数目和布线规模;

需求分析的类型

P36

231获得需求信息的方法

1 实地考察

实地考察是工程设计人员获得第一手资料采用的最直接的方法,也是必需的步骤;

如何获得需求

P36

231获得需求信息的方法

2 用户访谈

用户访谈要求工程设计人员与招标单位的负责人通过面谈,电话交谈,电子邮件等通讯方式以一问一答的形式获得需求信

如何获得需求

P36

231获得需求信息的方法

3问卷调查

问卷调查通常对数量较多的最终用户提出,询问其对将要建设的网络应用的要求

如何获得需求

P36

问卷调查的方式可以分为无记名问卷调查和记名问卷调查

231获得需求信息的方法

4向同行咨询

将你获得的需求分析中不涉及到商业机密的部分发布到专门讨论网络相关技术的论坛或新闻组中,请同行给你参考你制定的设计说明书,这时候,你会发现热心于你的方案的人们通常会给出许多中肯的建议

如何获得需求

P36

232归纳整理需求信息

通过各种途径获取的需求信息通常是零散的,无序的,而且并非所有需求信息都是必要的或当前可以实现的,只有对当前系统总体设计有帮助的需求信息才应该保留下来,其他的仅作为参考或以后升级使用

1将需求信息用规范的语言表述出来

2对需求信息列表

如何获得需求

P38

232归纳整理需求信息

需求信息也可以用图表来表示图表带有一定的分析功能,常用的有柱图,直方图,折线图和饼图

如何获得需求

P39

24 可行性论证

需求分析所取得的资料经过整理后得到需求分析文档,但这种需求分析文档还需要经过论证后才能最终确定下来参与论证活动的人员除了需求分析工作的负责人外,还要邀请其他部门的负责人,以及招标方的领导和专家

可行性论证求

P40

241 可行性论证的目的

可行性论证是就工程的背景,意义,目的,目标,工程的功能,范围,需求,可选择的技术方案,设计要点,建设进度,工程组织,监理,经费等方面作出可行性验证,指出工程建设中选择软硬件的依据,降低项目建设的总体风险

提供正确选择软硬件系统的依据

验证可行性,减少项目建设的总体风险

产生应用系统原型,积累必要的经验

加强客户,系统集成商,设备供应商之间的合作关系

降低后期实施的难度,提高客户服务水平和满意度

可行性论证求

P40

241 可行性论证的目的

在编写可行性论证报告时,主要对下列项目逐条说明:

1系统建设的目的

2技术可行性

3应用可行性

4人员,资金可行性

5设备可行性

6安全可行性

可行性论证求

P40

25 工程招标与投标

为了保证网络工程的建设质量,网络建设方应该以公开招标的方式确定承建商参与投标的承建商拿出各自的标书参与投标,其中标书的主要内容就来自于需求分析报告和可行性论证报告

工程招投标是一个规范的网络工程必需的环节

工程招标与投标

P41

251工程招标流程简介

1招标方聘请监理部门工作人员,根据需求分析阶段提交的网络系统集成方案,编制网络工程标底;

2 做好招标工作的前期准备,编制招标文件;

3 发布招标通告或邀请函,负责对有关网络工程问题进行咨询;

4 接受投标单位递送的标书;

5 对投标单位资格,企业资质等进行审查审查内容包括:企业注册资金,网络系统集成工程案例,技术人员配置,各种网络代理资格属实情况,各种网络资质证书的属实情况

工程招标与投标

P41

251工程招标流程简介

6 邀请计算机专家,网络专家组成评标委员会;

7 开标,公开招标各方资料,准备评标;

8 评标,邀请具有评标资质的专家参与评标,对参评方各项条件公平打分,选择得分最高的系统集成商;

9 中标,公告中标方,并与中标方签订正式工程合同

工程招标与投标

P41

252工程招标

计算机网络工程招标的目的,是为了以公开,公平,公正的原则和方式,从众多系统集成商中,选择一个有合格资质,并能为用户提供最佳性能价格比的集成商

编制招标文件

招标

工程招标与投标

P41

253工程投标

投标人在索取,购买标书后,应该仔细阅读标书的投标要求及投标须知在同意并遵循招标文件的各项规定和要求的前提下,提出自己的投标文件

编制投标文件

投标

1,递交投标文件

2,评标

3,中标

4,签订合同

工程招标与投标

P41

标书内容

(1)参评方案一览表

(2)参评方案价格表

(3)系统集成方案

(4)设备配置及参数一览表

(5)公司有关计算机设备及备件报价一览表

(6)从业人员及其技术资格一览表

(7)公司情况一览表,

(8)公司经营业绩一览表

(9)中标后服务计划

(10)资格证明文件,及参评方案方认为需要加以说明的其他内容

(11)文档资料清单

(12)参评方案保证金

需求分析

格式

1 引言

11 编写目的

说明目标：对用户的需求进行收集、整理与分析，弄清楚系统究竟要 “干什么”及“由谁干”，并用合乎规范的文字及图表予以描述。不需要说明“怎么干”，因为那是设计阶段的事情。有关文字与图表应尽量让用户便于理解。

预期读者：用户方的相关业务人员、双方的开发人员和系统维护人员。

作用：实现开发方与用户方的双向沟通，是把业务需求计算机化的关键步骤。

为下一阶段的概要设计工作提供依据。当用户的需求发生变更时，应添写补充说 明；如变动过大可形成新版本。

软件需求说明（Software Requirements Specification）的主要作用为：

 为用户方与开发方建立共同协议奠定基础。

 提高开发效率、强化进度控制。

 为项目的的评测与验收提供依据。

 便于移植。

 作为系统不断提高的基础。

12 编写背景

121 系统名称及版本号

说明形如“网银三期系统V300”。其中，版本号的格式为“XXXXXX”，X为阿拉伯数字，左“0”可省略。

122 使用者

说明适应对象和范围。主要指预期读者，也供有关领导审阅。

123 与其它系统的关系

说明在用户现有的及预期的整个应用系统中，给本系统准确定位。用示意图及相应的文字予以说明。

2 用户的基本情况

21 系统建设背景

说明项目背景与依据、现有基础、项目规模、预期目标等。可繁可简，格式自定。

22 组织机构与职能

说明用层次示意图及相应文字表示(如果需要开发的系统与部门没有直接依赖关系此节可省略,本章随后的小节数将顺次减1)，

加注：组织机构的层次数、数目、各个机构的职能简述。

23 用户特点

说明所在行业特征、操作人员与系统维护人员的数量、学历与水平、数据量大小、使用频度等。

24 用户业务分析

说明在本部分，希望系统分析人员能够对用户业务现状进行分析、对用户对本系统的未来发展方向作出一定的预测等。以便设计人员对业务及其发展有所了解，增强系统设计的前瞻性。

25 计算机应用现状

说明可繁可简，格式自定。

3 业务需求

31 项目概述

说明

第一、 指明项目的开发意图、应用目标（总目标、分期目标）、作用范围、预期效益等。

第二、 指明在输入信息转变为输出信息的过程中，为了满足用户的业务需求，应用软件必须完成的基本功能(采用自然语言叙述)。但此时不要求对基本功能进行分解。

第三、 如果本系统与其他系统相关联，则应确定本系统的基本功能边界（可采用图示+文字说明的形式，用蓝色标示出本系统的功能，用绿色标示出相关系统的功能）。

32 约束条件

321 费用约束

说明 预计投资金额概算、其中软硬件费用的比例、资金分期到位计划。

322 进度约束

说明预计完成日期、分步实施期限。

323 其它约束

说明场地面积限制、通信设施基础、其它干扰因素。

注意：任何计算机系统都不是包罗万象的；用户自身的能力也是有限的。轻诺必寡信。故应特别指出：由于哪些条件的约束，本系统不能满足哪些业务需求与系统需求。

本章主要介绍项目的总体业务功能,要求站在客户的角度把握系统需求

33 性能需求

说明依据ISO9000标准及我们的理解，下面列出了软件的6组性能，共涵盖21个子特性。这些性能/子特性的相对重要性并不是等同的。编写时，可以基于具体项目的实际需求，对下述标题或内容进行取舍/侧重。事实上不可能做到面面俱到，往往要作出某些折中。

本节说明系统在性能方面的预期目标，不要求提供实现上述目标的具体实施方案。

331 功能性

说明指与软件实现的各项功能及其指定性质有关的一组属性。这些功能都是满足规定需求和潜在需求所必需的。它包括5个子特性：

适用性：与指定业务所需各项功能的实现及其适合程度有关的一些软件属性。

准确性：与保证正确（或符合要求的）结果（或效果）有关的一些软件属性。

互操作性：与软件同一些指定系统交互作用能力有关的一些软件属性。

复合性：使软件遵守相关的标准、约定/法律或类似规定有关的一些软件属性。

保密安全性：与针对蓄意（或无意）而非法存取程序和数据的预防能力有关的一些软件属性。这里主要指的是保护软件的要素，旨在防止各种非法访问、修改、破坏、泄密及感染计算机病毒等。

332 可靠性

说明指在规定的条件和期限内，与软件保持其性能水平有关的一组软件属性。

成熟性：与软件故障引起的失误频率有关的一些软件属性。

容错性：在软件故障发生或其规定界面被破坏的情况下，与软件仍能保持规定性 能水平的能力有关的一些软件属性。

可恢复性：在失效的情况下、在限定的期限和强度范围内，与软件重建性能水平 并恢复直接受影响的数据的能力有关的一些软件属性。

333 易使用性

说明指与规定用户（或潜在用户）使用软件所需的努力程度、对这种使用所做的评估有关的一组软件属性。它包括3个子特性：

易理解性：与用户为理解其逻辑概念及适用范围需做的努力有关的一些软件属性。

易学习性：与用户学习其应用（例如操作控制、输入、输出）需做的努力有关的一些软件属性。

易操作性：与用户操作及运行控制需做的努力有关的一些软件属性。

334 高效性

说明指在特定的运行环境中，描写软件性能水平与所用的资源量之间关系的一组软件属性。它包括两个子特性：

时间特性：在完成软件功能时，与响应时间、处理时间、吞吐率有关的一些软件属性。

资源特性：在完成软件功能时，与所用资源量及占用时间有关的一些软件属性。

335 可维护性

说明与对软件进行指定的修改所需的工作量有关的一组软件属性。它包括4个子特性：

易分析性：与诊断故障、确定失败原因、在需要修改的部位进行标识等所做努力有关的一些软件属性。

易修改性：与实施修改、排除故障、环境改变所做努力有关的一些软件属性。

稳定性：与修改的意外影响带来的风险有关的一些软件属性。

易测试性：与对经过修改的软件进行检验/确认做努力有关的一些软件属性。

336 可移植性

说明指软件从一个环境转移的另一个环境时，与其适应能力有关的一组软件属性。它包括4个子特性：

适应性：除已有手段外，无须采用其它措施或手段，软件便应能适应指定的环境。与这种能力有关的一些软件属性称为适应性。

易安装性：在指定环境内，与安装软件所需努力有关的一些软件属性。

一致性：软件从一个环境转移的另一个环境时，应符合一定的标准和约定。与这种符合程度有关的一些软件属性，称为一致性。

易替换性：有时会出现这种需求：在某个其它软件的运行环境下，要用本软件来置换那个软件。与这种可能性及所需努力有关的一些软件属性。

4 用户需求

说明本章下面介绍的是一般规模软件系统的书写格式。在书写过程中可能要以业务名称划分小节(例如:51 代收电话费)。每个业务小节包含两个部分：第一部分是对此业务中角色和功能的定义；第二部分是此业务的图形分析方法。

在本章开始未分节的部分，应当绘制一个总体结构图，依据这个总体结构图进行一个总体描述，使得阅读者对下面分节描述的各个功能形成一个整体印象。这个总体结构图不一定是指在ROSE工具中绘制的用例总图， 而是根据需要可以选择包括“用例总图”、“适当级别的数据流图”、“IDFF图”、“数据流程图”或其他专业图形分析图示等。

每个小节中的第二部分采用rational公司的rose2000作为工具绘制用例（use case）图和顺序（sequence）图。在这里采用rose工具是作为绘图分析工具使用，对需求的描述和分析并不代表我们的设计采用UML标准和面向对象的设计，具体分析人员应当根据实际的用户需求描述绘制顺序图，而并不着重考虑对象的分析限制。

需求变更的处理原则：获得批准的需求变更，需要在《需求分析》中有所体现。增加的需求，需直接从本章尾部顺序添加，相应的小节编号也需要依次增加。例如：本章小节为51—55，增加的需求小节编号则为56。删除的需求，不需要将相应需求直接从《需求分析》中删除，而只需在相应需求小节上注明删除，并标出《需求变更单》编号。修改的需求，可在相应的需求小节直接修改。所有对《需求分析》内容的修改必须在修改历史中留有记录。

41 业务名称1

411 角色/功能定义

说明根据会议纪要、小组讨论，确定系统中的角色（角色可以为外部系统或系统用户），和功能，并给出相应的定义或解释。

412 图形分析

说明本节主要描述相应业务的用例图和顺序图的内容

统一建模语言（UML）是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。它记录了对必须构造的系统的决定和理解，可用于对系统的理解、设计、浏览、配置、维护和信息控制。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模方法。

在本需求模板中我们选取的是UML视图来辅助进行图形需求分析，选用Rational公司的ROSE工具完成。在需求分析过程需要完成结构分类中的用例分析，绘制用例图；对用例的动态行为进行交互分析，描述执行系统功能的各个角色之间相互传递消息的顺序关系，绘制顺序图。

在这里请作者将制作的用例图和顺序图拷贝到本文档中。

基本成分：用例（use case）、用例视图（use case view）、角色（role、actor）、顺序图（sequence diagram）、协作图（collaboration diagram）。

模板和命名：为更好地使用ROSE图形分析工具，我们设定一个基本的分析模板，文件名为lansoftmdlmdl。该文档涉及项目开发的需求、概设和详设3个阶段，在需求阶段主要完成模板中用例视图（use case view）规定完成的部分。在项目中使用该模板后生成的mdl文件纳入文档的配置管理，具体命名参照SEMP体系的命名规定。修改历史记入文档开始部分的“mdl文档修改历史表”中。

ROSE使用要求

1、 要求使用ROSE工具时必须完成模板和使用要求中规定完成的内容，在完成基本内容的基础上，可以根据需要增加部分内容。

2、 在公司没有购买确定版本的ROSE以前，使用的ROSE版本应在项目开始前在项目组规定好，并由配置管理员负责配置。

3、 在用例视图（use case view）中建立一个名称为main的主用例图（use case diagram），具体内容应当包括所有用例图的全部内容，具体应用时还可以根据情况建立多个用例图（use case diagram）。

4、 在用例视图中请采用中文对所有的角色（actor\role）进行命名。其中角色必须在双击该对象图后，详细填写该角色的描述（documentation）和该角色代表的角色数量（detail-multiplic）。

5、 在用例视图中请采用中文对所有的用例（use case）进行命名。命名中在一般的中文概括前应增加代表本节编号的部分，如“1用户认证”，顺序编号。其中用例必须在双击该对象图后，详细填写该用例的描述（documentation）。

6、 在每个用例下必须组织建立相应的顺序图（sequence diagram），对于一个用例可以包含多个顺序图（sequence diagram），各个顺序图（sequence diagram）的命名需在一般的中文概括前增加代表本节编号的部分，如“11用户认证”，顺序编号，其中第一个1代表所属的用例，第二个1代表顺序图（sequence diagram）的编号。产生顺序图的数量根据说明需求的具体要求设定。其中顺序图中的各个对象消息（object message）必须在双击该对象图后，详细填写该对象消息（object message）的描述（documentation）。

413 数据存储需求

说明根据会议纪要、小组讨论，对于在需求调研中有关的数据实体对象或数据实体信息，应当根据需要提出可能数据类型和数据长度以及单位量纲的记录或建议。

5 运行环境

说明本章只提出运行环境的逻辑结构，物理结构将在《概要设计说明书》中给出。

容许提出几种可选方案。

51 硬件平台

说明指出本应用软件适用的主机/服务器与终端/工作站的技术指标、基本配置、接口特点、特殊约定等。

应尽可能地说明上述设备在各级用户机构预计的分布状态。

52 网络平台

说明选型标准、网络类型、基本部件、接口情况、对综合布线的要求、限制条件等。应画出网络（广域网、局域网）的拓扑结构图，说明后者对前者的接入方式。

53 软件平台

说明操作系统的名称、生产厂家、版本号等。

数据库的名称、生产厂家、版本号等。

数据库设计工具的名称、生产厂家、版本号等。

网络通信协议的名称、生产厂家、版本号等。

前端开发工具的名称、生产厂家、版本号等。

测试开发工具的名称、生产厂家、版本号等。

现场运行时需要的工具软件的名称、生产厂家、版本号等。

配置管理工具软件的名称、生产厂家、版本号等。

6 附录

说明列出基础素材中的文件、报表、单据等的样张，再附上必要的注释。

如果条件成熟，可以把数据字典（data dictionary）作为附件列于后。

61 电子文档编写方式与使用工具

说明编写要求、工具名、版本号、操作系统平台。使用多种工具时，应分别说明。形如：

Microsoft Word 97 for Windows 95/98

Power Designer 60 for Windows 95/98

Rational Rose 98 for Wintel

Visio或Power Point 97 for Windows 95/98

62 定义说明与符号

说明包括对专用术语及缩略语的解释、所用到的图（如use case、sequence图）之图符的表示与解释等。

63 参考资料

说明格式：作者，[版本号，]资料来源，日期 [，起止页号] 。其中，《质量保证计划》是必选的参考资料。

64 有关表格清单

说明列出用户提供的素材，加上我们积累的有关文件，作为系统分析的基础。在这里除系统内部没有用户参与的需求分析工作外，必须包括一个以上的用户访谈纪要、用户确认签名文件以及用户访谈计划等文件的列表。在列表中的文件应当作为附件与需求文档共同纳入配置管理

关于实施和运维哪个好如下：

干好了都有潜力，运维工程师薪资一般在：5-20k之间，平均:5-8k。软件实施工程师，还是看实施什么。如果只是卖软件，给客户装上。

并且测试通过，这种估计拿不到几个钱。说多了也只是个销售代表。如果是那种直接针对客户直接现场开发，或者对客户所提的需求进行二次开发的工程师。还是比较有发展潜力的。最后可以发展到项目经理。

java实施和java运维有什么区别？哪个有发展前途？ 

实施偏商务一点,运维偏技术一点;如果单纯的java运维没有前途,但是可以尝试进行周边技术的研究,转型DBA,钱途无限。如果嘴皮子溜的话,可以做实施,每次给客户安装完了,可以跟客户拉拉关系,将来把公司的客户全部撬到自己手里,然后自己创业,同样是钱途不可估量。

主要还是看个人,我现在是需求调研+开发+测试+实施+运维以一体毫无专长可言所以一定要认清自己的定位。it运维工程师和实施工程师有什么区别 

个人更倾向与实施工程师。运维主要工作为维护与技术支持，相对要被动一点。而实施更具有矗动性。很多小型公司会出于成本等额考虑，一般会将这两者综合在一起的“复合型人才”！比如运维的网络工程师：

1负责IDC机房Linux业务服务器的配置，维护，监控，调优，故障排除等；2大用户量下高性能服务器系统部署方案的制定及实施；3保障服务器与数据库安全，检查并消除安全漏洞；4数据备份、数据监控、应急响应、故障排除、编写数据分析报告等。而实施：更主要负责整体的网络规划、建置、设备调试等等。

在自营销中，客户需求和产品创新的关系中，客户需求是第一位的。客户需求分为显性需求及隐形需求。在显性的客户需求中，产品的创新必须以满足客户的需求，这是不言而喻的。

亨利·福特说过，如果你问用户需要一个什么样的汽车，他会告诉你需要一辆更好的马车。福特列举了他详细调研的结果，基本上吃瓜群众都说不出个子丑寅卯。乔布斯后来把这句话改装成：人们根本不知道他们想要什么。

直到你把产品摆在他的桌面。他们二位显然主要是创新驱动轮。任正非在谈以客户为中心时是这样说的：二十年来，我们由于生存压力，在工作中自觉不自觉地建立了以客户为中心的价值观。应客户的需求开发一些产品。

如接入服务器、商业网、校园网，因为那时客户需要一些独特的业务来提升他们的竞争力。不以客户需求为中心，他们就不买我们小公司的货，我们就无米下锅。我们被迫接近了真理，但我们并没有真正认识它的重要性。

没有认识它是唯一的原则，因而对真理的追求是不坚定的、漂移的。华为是一个客户导向派，很多人把以客户为中心看成是一种态度，甚至是一种广告就太肤浅了。以客户为中心是华为业务决策、流程、管理等基础观念。

这个就不展开了。技术创新和客户需求驱动到底是什么关系？这是一个很朴素，很有实用价值的问题。首先，生产方是要靠产品赚钱，预期销售成千上万份产品，它通常还有这种产品方面的专家，绞尽脑汁的琢磨。

需求方不过是选择一个产品而已，不会不上心，也不会太专业。一个通俗的例子是，手机公司更想做出好产品还是某个用户更想得到一款好手机？单从意识形态和驱动力而言，厂商总是比用户要强烈得多。厂商很多人不停的苦思怎么做出好产品。

用户一般不可能这么投入的，宁可卖肾买手机的毕竟是极少的情况。各个方面不对称的投入表明，用户不可能比厂商更明白。这就是福特说法的逻辑推演。问题的另一方面则是，用户虽然无法想象出产品的全貌。

但挑毛病的能力是不能否认的。比如，我写这篇文章，起码敲字都有半个小时，读者只是三分钟搞定。但不能因此否定读者不可能挑出毛病。产品也是这样的，你的产品一旦投向市场，各种用户就会挑出各种毛病。

提出各种需求，这是华为经历的理论解释。把这二者兼容起来，融会贯通就是完整的创新哲学。福特基本上是汽车业的开创者（虽然不是发明者），福特本人是机械天才。你不可能指望用户发明一种全新的东西。

所以，站在福特公司的角度，亨利福特是对的。乔布斯也是同样的。华为则像所有后发者一样，没做什么原始的创造性产品。在跟随中不断听取客户意见，做出更贴合用户需求的产品，华为在一定历史阶段完全用户导向是对的。

第一步：需求调研分析　1相关系统分析员向用户初步了解需求，然后用WORD列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。　2 系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚利用系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。　3 系统分析员向用户再次确认需求。　第二步：概要设计　首先，开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计 进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、 运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。　第三步：详细设计　在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实 现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。　第四步：编码　在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。　　第五步：测试　测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。　第六步：软件交付准备　在软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。　《用户安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置。　《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容，在需要时还应举例说明。　第七步：验收　用户验收。

　　问卷调查是现代社会掌握舆情态势、了解消费意愿的重要手段，而SPSS是一种广泛使用的统计分析工具。随着“在线问卷调查”的广泛应用，人们希望能将“在线问卷调查”和SPSS这种强大的统计分析软件结合起来，以更加高效地完成统计分析工作。从软件工程的角度来说，也就是要开发出SPSS数据规范型在线问卷调查系统即让调查问卷的数据格式符合SPSS数据定义，从而通过Web平台自动完成舆情数据的采集、转化并生成SPSS数据库，进而改变舆情研究部门的低效状态，以大幅度提升整个社会的舆情信息研究质量。

项目的设计思路与模块规划

根据我国用户的网络使用习惯，要将SPSS统计分析软件包引入大中型在线舆情调查，要重点考虑一般文本条件下的问卷处理子系统和在线调查网站平台子系统两组模块的建构。

就问卷处理子系统而言，基本设计思路是问卷编辑器要基于常规的文本处理软件，不仅实现问卷变量同SPSS数据规范的可靠对接，同时还提供编制大中型问卷所需的各种操作。这组模块运行在Windows操作系统环境中，其功能设计重点关注以下几点:

1 它有一个能编制大中型调查问卷的电子问卷模版，用户依托它可以像处理普通文档一样创建新问卷、设置或修改问卷的相关基本信息。

2 用户可以在预设的电子问卷中添加和设置不限数量的单选题、多选题、各种单选矩阵、排序题及主观题等，所有题型的题目都可以对其进行编辑。

3 用户可编辑每道题目的SPSS变量数据关联信息。单选题每个题目对应一个SPSS变量，多选题题目中每个选项对应一个SPSS变量，用户可根据需要编辑所有的SPSS变量参数。

4 用户可以设置创建包含若干题目的分区，按照需求对不同类别的调查题目进行架构组织调整，还可以选用描述性信息对分区特性做出说明并在调查页面中加以显示。

5 问卷编辑器能以特定格式将问卷信息存放在一个文档中，供日后发布调查项目时调用。用户还可以选择对问卷进行加密处理，以增强文本的安全性。

而在线网站子系统的设计方面，主要考虑这组模块应能够接受用户上传的含有SPSS数据规范信息的大中型电子文本问卷，并较为便捷地将其转化成网页页面，还要支持多个问卷同时开展在线调查数据采集，获得舆情数据后能自动生成SPSS数据库文件供用户下载分析。

由于在线调查通常与社会事务决策和企业管理决策密切关联，SPSS数据规范型在线问卷调查系统的安全管理和稳定运行同样重要。因此，该子系统的模块设计特别强调拥有可靠的调查管理、问卷管理及用户管理等平台管理功能，确保只有拥有特定权限的用户能够在调研平台上进行操作。该子系统还能够限定问卷可接受的样本规模，并仅向合法用户提供数据下载等必要的在线服务。模块还能记录IP地址等有关的特征信息，防止一台计算机同时登录两个被调查者。

项目的开发难点

符合SPSS数据规范的大中型在线问卷调查系统要真正适用，有一系列难点需解决。其中，有关问卷文档的存储处理、调查数据的暂存处理、在线问卷调查页面处理以及调查数据转化处理等四个问题需要特别关注。

对于问卷文档的格式设计，人们期待的是一个高度自动化的系统，它不但能保存问卷文本、保存相关的SPSS数据定义以及数据定义与问卷题目之间的关联信息，而且能够将所有文本与数据定义正确解析出来。其中，文件的格式以及系统对文件的访问方式具有决定性的影响。本设计采取基于XML技术的问卷文档格式。

在线数据的暂存处理要着眼于控制开发成本和降低开发难度，设计以商用数据库（如Oracle、SQL Server）作为数据中转点，待填写问卷结束后系统再对暂存的数据进行符合SPSS规范的转化。由于在线调查的不同问卷所包含的题目数量各不相同，故问卷所包含的SPSS变量数量也不确定，这意味着调查系统无法按照一个统一的数据库表结构进行数据存储。为此选择为每一个问卷在数据库中创建一个数据表，数据表的键要与问卷所包含的SPSS变量名一一对应，以有效防止可能出现的数据表键名定义冲突。此外，由于SPSS和商用数据库的数据类型差异较大，在暂存数据库中存储的数据可考虑转化为字符串形式进行存储。

在在线问卷的调查页面处理方面，由于大中型在线问卷调查的页面是动态的，其调查页面使用ASPNET技术实现。为了避免系统为每个调查问卷均生成HTML页面文件导致系统存储空间被大量占用，同时防止SPSS变量信息泄漏，问卷的页面转化、呈现、数据采集等工作可以通过开发相应的服务器控件完成。这样，不同的调查可通过向同一个页面中的服务器控件传递不同参数的机制实现区分和引导。为此，专门设计了问卷访问接口和数据库访问接口。问卷访问接口用于读取并解析指定问卷中的XML格式题目与SPSS变量信息，并传递给服务器控件进行呈现与数据采集。服务器控件在采集到被调查者填写的信息后，将一组或若干组SPSS变量相关的数据集合传送给数据库访问接口。数据库访问接口接收到数据后，将每一个SPSS变量对应的数据存储在指定的暂存数据库表中相应行位置的同名键位置处。这种问卷调查页面不仅能够读取各不相同的问卷并将之显示于被调查用户的浏览器中，而且还能根据同样各不相同的SPSS数据定义进行数据的获取和存储。

调查数据的转化处理就是将商用数据库中的数据转化为SPSS数据库文件，可以考虑采用基于SPSS开放的spssio32dll进行NET环境下封装的方法加以实现。Spssio32dll封装了对SPSS文档（sav）进行访问的一些基本操作，相关程序涉及的函数数量很多，操作的逻辑动作相当细微，可根据需要对之进行整合与组装，这相当于创建了一个精巧方便、可以脱离SPSS软件环境操纵SPSS数据的文件驱动。在大中型在线问卷调查平台上，它可以被当做一个普通的程序模块而不是一个完整程序实例调用。

链 接

SPSS数据库的组成

一个完整的SPSS数据库（sav文件）由数据集合与变量集合两部分组成。数据集合包含若干数据样本条目，而变量集合则定义和限制了数据集合的结构与数据的属性。数据集合中每一个数据样本均由一组属性对应相应的变量组成，同一个数据库文件中所有数据样本的结构相同。

变量集合则集中定义和维护数据库变量的属性。SPSS数据库中的变量概念和商用数据库中的键的概念类似，但因SPSS数据库面向数理统计分析，其资料格式与商用数据库存在较大差异。因此，其数据无法直接用于商用数据库中，这是一般网络调查数据无法直接用于SPSS的主要原因。