在软件开发的过程中，我们一向遵循软件产品的以下原则： 1、功能性:与一组功能及其指定的性质有关的一组属性，具体包括:
适合性:与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性 准确性:与能否得到正确或相符的结果或效果有关的软件属性 互用性:与同其他指定系统进行交互的能力有关的软件属性 依从性:使软件遵循有关的标准,约定,法规及类似规定的软件属性
安全性:与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性
2、可靠性:与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性,具体包括：
成熟性：与由软件故障引起失效的频度有关的软件属性
容错性：与在软件故障或违反指定接口的情况下,维持规定的性能水平的能力有关的软件属性
易恢复性:与在失效发生后,重建其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间和能力有关的软件属性
3、易用性:与一组规定或潜在的用户为使用软件所需作的努力和对这样的使用所作的评价有关的一组属性,具体包括：
易理解性:与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性 易学性：与用户为学习软件应用所花的努力有关的软件属性 易操作性：与用户为操作和运行控制所花努力有关的软件属性
４、效率:与在规定的条件下,软件的性能水平与所使用资源量之间关系有关的一组属性,具体包括:
时间特性:与软件执行其功能时响应和处理时间以及吞吐量有关的软件属性 资源特性:与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性
５、可维护性:与进行指定的修改所需的努力有关的一组属性，具体包括:
易分析性:与为诊断缺陷或失效原因及为判定待修改的部分所需努力有关的软件属性 易改变性：与进行修改，排除错误或适应环境变化所需努力有关的软件属性 稳定性:与修改所造成的未预料结果的风险有关的软件属性 易测试性:与确认已修改软件所需的努力有关的软件属性
6、可移植性：与软件可从某一环境转移到另一环境的能力有关的一组属性，具体包括: 适应性：与软件无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性
易安装性:与在指定环境下安装软件所需努力有关的软件属性 遵循性:使软件遵循与可移植性有关的标准或约定的软件属性
易替换性:与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的软件属性
基于以上原则，根据项目的不同需求,我们将会考虑采用B/S和C／S两种模式开发. 1、B/S模式
B／Ｓ是Brｏwer/Servｅr的缩写,客户机上只要安装一个浏览器（Browｓeｒ)，如Ｎetscａpe Nａvｉｇator或Internｅt Expｌorer，服务器安装Ｏrａclｅ、Sybａsｅ、Infｏrmix或 SＱL Server等数据库。浏览器通过Wｅb Sｅrｖeｒ 同数据库进行数据交互。B/Ｓ模式较C/S模式:
ﻩC/Ｓ模式客户端需要安装专用的客户端软件.首先涉及到安装的工作量,其次任何一台电脑出问题，如病毒、硬件损坏,都需要进行安装或维护。特别是有很多分部的情况，不是工作量的问题，而是路程的问题。还有，系统软件升级时,每一台客户机需要重新安装,其维护和升级成本非常高。C/S模式对客户端的操作系统一般也会有限制,可能适应于Ｗinｄows系列操作系统,而不适用于Linux、Unix等操作系统。
而B/S最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件.只要有一台能上网的电脑就能使用，客户端零维护。系统的扩展非常容易,只要能上网,再由系统管理员分配一个用户名和密码,就可以使用了.甚至可以在线申请，通过公司内部的安全认证（如CA证书）后,不需要人的参与，系统可以自动分配给用户一个账号进入系统，这在最大程度上满足了项目要求。
系统采用的是目前较流行的一种Web应用程序开源框架—-Ｓtｒｕts+Ｓｐrinｇ
+Hibeｒnate（SＳH)。
集成SSH框架的系统从职责上分为四层:表示层、业务逻辑层、数据持久层和域模块层,以帮助开发人员在短期内搭建结构清晰、可复用性好、维护方便的Ｗｅｂ应用程序。其中使用Strｕｔs作为系统的整体基础架构，负责MVＣ的分离，在Sｔrutｓ框架的模型部分，利用Ｈｉbernate框架对持久层提供支持，业务层用Sｐriｎg支持.具体做法是：用面向对象的分析方法根据需求提出一些模型,将这些模型实现为基本的Ｊava对象，然后编写基本的ＤAO接口，并给出Hibernatｅ的ＤAO实现,采用Hｉｂernａte架构实现的DＡO类来实现Java类与数据库之间的转换和访问，最后由Spriｎg完成业务逻辑。
系统的基本业务流程是: 在表示层中，首先通过JSP页面实现交互界面,负责传送请求（Rｅｑuest）和接收响应（Ｒesponｓｅ)，然后Struts根据配置文件(struｔs－conｆiｇ。xml）将AｃｔionSｅrｖｌet接收到的Rｅquesｔ委派给相应的Actioｎ处理.在业务层中，管理服务组件的Ｓｐｒｉng IoC容器负责向Actｉon提供业务模型(Modｅｌ）组件和该组件的协作对象数据处理(ＤＡO)组件完成业务逻辑,并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。而在持久层中，则依赖于Hiberｎａｔe的对象化映射和数据库交互，处理DＡO组件请求的数据，并返回处理结果。
采用上述开发模型，不仅实现了视图、控制器与模型的彻底分离,而且还实现了业务逻辑层与持久层的分离。这样无论前端如何变化,模型层只需很少的改动,并且数据库的变化也不会对前端有所影响,大大提高了系统的可复用性。而且由于不同层之间耦合度小,有利于团队成员并行工作，大大提高了开发效率的同时,也保证了软件产品的质量． 2、C／S模式
C/Ｓ （Clienｔ/Serｖeｒ，客户机/服务器)模式又称C/S结构，是２0世纪8０年代末逐步成长起来的一种模式,是软件系统体系结构的一种。C/Ｓ结构的关键在于功能的分布,一些功能放在前端机（即客户机）上执行，另一些功能放在后端机（即服务器)上执行。功能的分布在于减少计算机系统的各种瓶颈问题。C/S模式简单地讲就是基于企业内部网络的应用系统。与B/S(Broｗｓer／Sｅｒver，浏览器/服务器)模式相比,Ｃ／S模式的应用系统最大的好处是不依赖企业外网环境,即无论企业是否能够上网,都不影响应用．
C/S结构服务器通常采用高性能的PC、工作站或小型机,并采用大型数据库系统,如ORACLＥ、ＳYBASE、IｎfORMix或 SQL Ｓｅrveｒ．客户端需要安装专用的客户端软件。 Ｃ/S结构的优点是能充分发挥客户端PＣ的处理能力,很多工作可以在客户端处理后再提交给服务器，因此对应的优点就是客户端响应速度快。
Ｃ/S架构软件的优势与劣势:
（１)应用服务器运行数据负荷较轻。最简单的Ｃ/Ｓ体系结构的数据库应用由两部分组成，即客户应用程序和数据库服务器程序.二者可分别称为前台程序与后台程序．运行数据库服务器程序的机器，也称为应用服务器。一旦服务器程序被启动，就随时等待响应客户程序发来的请求；客户应用程序运行在用户自己的电脑上，对应于数据库服务器,可称为客户电脑，当需要对数据库中的数据进行任何操作时,客户程序就自动地寻找服务器程序，并向其发出请求,服务器程序根据预定的规则作出应答,送回结果,应用服务器运行数据负荷较轻。
（２）数据的储存管理功能较为透明。在数据库应用中，数据的储存管理功能，是由服务器程序和客户应用程序分别独立进行的，并且通常把那些不同的（不管是已知还是未知的）前台应用所不能违反的规则,在服务器程序中集中实现,例如访问者的权限,编号可以重复、必须有客户才能建立定单这样的规则。所有这些,对于工作在前台程序上的最终用户，是“透明”的，他们无须过问（通常也无法干涉)背后的过程,就可以完成自己的一切工作。在客户服务器架构的应用中,前台程序不是非常“瘦小”,麻烦的事情都交给了服务器和网络。在C/S体系的下，数据库不能真正成为公共、专业化的仓库,它受到独立的专门管理． C/S模式系统的开发:
Ｃ／Ｓ结构是建立在中间件产品基础之上的，要求应用开发者自己去处理事务管理、消息队列、数据的复制和同步、通信安全等系统级的问题。这对应 用开发者提出了较高的要求,而且迫使应用开发者投入很多精力来解决应用程序以外的问题。这使得应用程序的维护、移植和互操作变得复杂.如果客户端是在不同的操作系统上，C/S结构的软件需要开发不同版本的客户端软件.但是，与B/Ｓ结构相比,Ｃ/S技术发展历史更为“悠久”.从技术成熟度及软件设计、开发 人员的掌握水平来看，Ｃ/Ｓ技术应是更成熟、更可靠的。
１2.4．3 项目总体架构及技术解决方案
一、项目总体架构
(一)、ＳSH框架介绍和分析
大型企业级Wｅb应用系统的开发通常要求有一个良好的软件架构、便于协作开发和扩展升级,而传统的开发模式不能很好地满足这些要求。
基于当前Wｅb应用程序开发面临的问题,项目结合目前比较流行的开源框架SSH（Ｓｐring、Ｓtruts、Hｉｂｅrnate），具体讨论其基本相似性及有关基本概念，提出了一种开发JavaEＥ Ｗeｂ应用的轻量级解决方案，此系统架构可以在短期内搭建结构清晰、可复用性好、可扩展性好、维护方便的Wｅb应用程序．
1、框架技术
框架一般具有即插即用的可重用性、成熟的稳定性以及良好的团队协作性。ＪavaEE复杂的多层结构决定了大型的JavaEＥ项目需要运用框架和设计模式来控制软件质量。目前,市场上出现了一些商业的、开源的基于JavaEＥ的应用框架，其中主流的框架技术有：基于ＭVC模式的Stｒuts框架、基于ＩoC模式的Spring框架以及对象/关系映射框架Hibｅrnate等。
2、框架共同点
所有现代的网络开发框架几乎都遵循了模型—视图－控制(ＭVＣ)设计模式：商业逻辑和描述被分开,由一个逻辑流控制器来协调来自客户端的请求和服务器上将采取的行动。这条途径成为了网络开发的事实上的标准。每个框架的内在的机制当然是不同的，但是开发者们使用来设计和实现他们的Weｂ应用软件的ＡPI是很类似的.差别还存在于每个框架提供的扩展方面,例如标签库,JaｖａBeａn包装器等。
所有的框架使用不同的技术来协调在Web应用程序之内的导航,例如ＸML配制文件，jａva属性文件或定制属性.所有的框架在控制器模块实现的方法方面也存在明显的不同。例如，EJB可能实例化在每个请求中需要的类或使用Javａ反射动态地调用一个适当的行为(Ａction）类。另外,不同框架在各自引入的概念上也有所不同。例如,一个框架可能定义用户请求和反应场所,而另外一个框架可能仅仅定义一个完整的流：从一个请求到多个响答和随后的再请求。
各种Ｊａva框架在它们组织数据流的方法方面是很类似的。在请求发出后，在应用程序服务器上产生一些行动；而作为响应,一些可能包含对象集的数据总是被发送到WEＢ层。然后从那些对象:可能是有seｔｔer和ｇetｔｅｒ方法的简单类、JAVＡBＥAＮＳ、值对象、或者一些集合对象中提取数据。现代的Ｊava框架还想方设法简化开发者的开发任务，如通过使用简易的APＩ、数据库连接池、甚至数据库调用包等提供自动化的追踪方式来实现。
一些框架或者能够钩进（hookｅd inｔo)另外的JaｖaEＥ技术中,例如JMＳ（Ｊava消息服务)或JMX,或把这些技术集成到一起。服务器数据持续性和日志也有可能成为框架的一部分.
3、ＭＶC模式
MＶC模式是一个用于将用户界面逻辑与业务逻辑分离开来的基础设计模式,它将数据处理、界面以及用户的行为控制分为：Mｏdeｌ（模型）－View（视图)－Ｃontroller(控制器)。
Moｄeｌ：负责当前应用的数据获取与变更及相关的业务逻辑。可用ＪＡVＡBEＡN来体现; Ｖiｅw：负责显示信息。可以使用JＳＰ、VELOCITY模板等技术; Conｔroｌlｅr:负责收集转化用户的输入。常用一个SEＲVＬET来实现;
View和Contｒolｌer都依赖于Modeｌ,但是Modeｌ既不依赖于View，也不依赖于Controlｌer,这是分离的主要优点之一,这样Moｄel可以单独的建立和测试以便于代码复用,Vieｗ和Coｎｔrｏｌｌer只需要Ｍｏdel提供数据,它们不会知道、也不会关心数据是存储在SQL Ｓｅｒveｒ还是Oraｃｌｅ数据库中或者别的什么地方。
４、 WEB层框架Strｕts
Ｓtrutｓ是一个在JＳP Ｍoｄel2基础上实现的MVＣ框架，其主要的设计理念是通过控制器将表现逻辑和业务逻辑解耦，以提高系统的可维护性、可扩展性及可重用性。Struts框架的体系结构如下图所示：
下面就上图所示的体系结构图分析Struts框架中的MVC组件。
➢ 视图（vｉew）:视图部分主要由ＪSP页面组成,其中没有流程逻辑、业务逻辑和模
型信息,只有标记。Strｕｔs自身包含了一组标记库（ＴａgLｉb),这也是Struｔｓ的精华之一,灵活运用它们可以简化JSP页面的代码，提高开发效率。 ➢ 控制器(cｏntrollｅｒ）:Struts中的Controllｅｒ主要是其自身提供的Actiｏn
Ｓeｒvｌｅt．ActｉｏnＳeｒvlｅt接收所有来自客户端的请求并根据配置文件(struｔｓ-confｉg.xml）中的定义将控制转移到适当的Actｉon对象。 ➢ 模型(model)：Ｓtruｔs没有定义具体Model层的实现，Model层通常是和业务逻
辑紧密相关的，有持续化的要求。目前在商业领域和开源世界,都有一些优秀的工具可以为Moｄel层的开发提供便利。
5、业务逻辑层框架Ｓpｒｉnｇ
Sprｉnｇ是一个解决了许多JavaEＥ开发中常见问题并能够替代EJB技术的强大的轻量级框架。这里所说的轻量级指的是Ｓpring框架本身，而不是指Sｐriｎｇ只能用于轻量级的应用开发。Spｒing的轻盈体现在其框架本身的基础结构以及对其他应用工具的支持和装配能力。与EJB这种庞然大物相比,Ｓｐring可使程序研发人员把各个技术层次之间的风险降低。
Ｓprｉnｇ框架的核心是控制翻转IoＣ（Ｉnversion ｏf Controｌ)/依赖注入DI(Dependence Ｉnｊectiｏn)机制。ＩoＣ是指由容器中控制组件之间的关系(这里,容器是指为组件提供特定服务和技术支持的一个标准化的运行时的环境）而非传统实现中由程序代码直接操控，这种将控制权由程序代码到外部容器的转移，称为“翻转”。ＤI是对IｏＣ更形象的解释，即由容器在运行期间动态地将依赖关系(如构造参数、构造对象或接口）注入到组件之中。Spｒing采用设值注入(使用Setter方法实现依赖）和构造子注入(在构造方法中实现依赖）的机制，通过配置文件管理组建的协作对象,创建可以构造组件的IｏC容器。
这样，不需要编写工厂模式、单例模式或者其他构造的方法，就可以通过容器直接获取所需的业务组件。Sprinｇ框架的结构如下图所示。
Sｐriｎｇ框架由七个定义明确的模块组成，且每个模块或组件都可以单独存在,或者与其他一个或多个模块联合实现。Spriｎg Coｒe Containｅr是一个用来管理业务组件的ＩｏC容器,是Spring应用的核心;Spｒiｎg DＡO和Sprｉng ORM不仅提供数据访问的抽象模块,还集成了对Hibernate、JDO和iBａtiｓ等流行的对象关系映射框架的支持模块,并且提供了缓冲连接池、事务处理等重要的服务功能,保证了系统的性能和数据的完整性;Spｒnｉg Ｗeb模块提供了Web应用的一些抽象封装，可以将Strｕｔs、Webwork等Wｅｂ框架与Sprinｇ整合成为适用于自己的解决方案.
Ｓprｉng框架可以成为企业级应用程序一站式的解决方案,同时它也是模块化的框架，允许开发人员自由地挑选适合自己应用的模块进行开发.Sprinｇ框架式是一个松耦合的框架,框架的部分耦合度被设计为最小，在各个层次上具体选用哪个框架取决于开发者的需要。
6、持久层框架Hiｂｅｒnate
Ｏ/R maｐｐing技术是为了解决关系型数据库和面向对象的程序设计之间不匹配的矛盾而产生的。Hｉｂernａte是目前最为流行的Ｏ/R mapping框架,它也是开源软件，它在关系型数据库和Jaｖa对象之间做了一个自动映射，使得程序员可以以非常简单的方式实现对数据库的操作,它不仅负责从Ｊava类到数据库表格（以及来自Jａva数据类型的ＳQL数据类型)的映射，而且还提供数据查询和检索能力，并能大大减少花在ＳＱL和JDBC手工数据处理上的开发时间。Hiberｎaｔe工作原理如下图所示：
Hｉbernaｔe通过对JDBC的封装，向程序员屏蔽了底层的数据库操作,使程序员专注于ＯＯ程序的开发,有助于提高开发效率.程序员访问数据库所需要做的就是为持久化对象编制ｘmｌ映射文件。
底层数据库的改变只需要简单地更改初始化配置文件(hibernate.cfｇ.ｘｍl或者ｈiberｎａｔe.proｐerｔies)即可，不会对应用程序产生影响。
Hiｂeｒｎａte有自己的面向对象的查询语言HQＬ，HＱL功能强大,支持目前大部分主流的数据库，如Oｒａclｅ、DB2、ＭｙSQL、Miｃrｏsｏfｔ SＱL Ｓerｖｅｒ等，是目前应用最广泛的O／R映射工具。Ｈiｂernate为快速开发应用程序提供了底层的支持。
(二)、基于ＳSＨ框架的Web应用架构分析与设计
前面分析了基于JavaEＥ的SSH框架技术，现代的企业开发中，越来越多地引入了多层架构设计模式。SSH就是其中之一，SＳH架构是当前主流的架构,在很多领域,包括金融、电信项目，大型门户网站均选择该架构作为业务支撑架构,开发流程也已经非常成熟。但是该结构开发起来,依旧存在一些问题。分析这些问题,得先从ＳSH架构的组成说起.
SSH为Strｕts＋Ｓprｉng+Hibernａｔe的组成方式,Struts实现MVC,Spriｎg负责架构的结合,Hiberｎａte进行数据的持久化.通常其分层开发的结构图如下:
这样的结构，系统从职责上分为四层：WEB层、业务逻辑层、数据持久层和实体层.其中使用Strｕｔs作为系统的整体基础架构,负责MVＣ的分离，在Struts框架的模型部分,利用Ｈｉbｅｒnate框架对持久层提供支持,业务层用Sｐriｎg支持．具体做法是：用面向对象的分析方法根据需求提出一些模型，将这些模型实现为基本的Jａｖa对象,然后编写基本的DＡＯ接口，并给出Ｈibernate的DAＯ实现，采用Hｉbernaｔe架构实现的DAＯ类来实现Ｊava类与数据库之间的转换和访问,最后由Ｓprｉng完成业务逻辑．
系统的基本业务流程是:在ＷEB表示层中，首先通过JＳＰ页面实现交互界面,负责传送请求（Rｅqｕest)和接收响应(Responｓe),然后Stｒuts根据配置文件（strｕｔs-config。xmｌ)将ＡctiｏnSerｖlet接收到的Ｒｅquｅｓt委派给相应的Ａｃtioｎ处理.在业务层中,管理服务组件的Spring IｏC容器负责向Aｃtion提供业务模型(Mｏdel）组件和该组件的协作对象数据处理(DAＯ)组件完成业务逻辑,并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。而在持久层中,则依赖于Hibｅrnate的对象化映射和数据库交互，处理ＤAO组件请求的数据,并返回处理结果。
采用上述开发模型,不仅实现了视图、控制器与模型的彻底分离,而且还实现了业务逻辑层与持久层的分离。这样无论前端如何变化,模型层只需很少的改动，并且数据库的变化也
不会对前端有所影响,大大提高了系统的可复用性。而且由于不同层之间耦合度小，有利于团队成员并行工作，大大提高了开发效率。
但是对于当前日益复杂化的WEＢ２.0的开发，却存在不少问题,归纳起来主要有以下的不足：
➢ DAO和服务层容易出现职责不明，由于按照MＶC逻辑,业务代码应该写在Sｔruts
Acｔion里,但是其事务的提供,却是配置在Servｉcｅ层。为了一组在逻辑上完整的数据操作业务逻辑,需要涉及两个层(Serviｃe、Acｔioｎ）来进行编写,遇到判断的情况下，为了保证完整的事务操作，则需要将业务代码移到Servｉce层完成，而通常习惯了在Struｔs Actiｏn里调用多次Ｓｅｒvicｅ而产生多个事务，但在出现Eｘceｐtｉon导致出错时,操作之前调用的Sｅrvｉce事务的业务数据没有被回滚.
➢ 当需要返回的数据供ＡJAX使用，操作JＳＯN或ＸML的大量使用时。开发起来会
很费力，一段同样的业务代码,为了使用AJAX和XML可能需要重新编写一次，或者在同一个ACTION里通过标志来判断,对分层结构造成了比较糟糕的破坏。如果设计得不好,为了使用JSＯN和XML还得额外增加大量的配置,严重降低了开发效率。 因此，为了克服这些缺点,对于SSH架构,进行了重新的分层，共享了业务代码。简化了开发、增强了与ＡJAＸ技术、XML技术的结合。提供了一种更高效的开发模式.
其开发的结构图如下:
这个架构的优点在于，由于业务代码统一实现BusinesｓＳervｉcｅ接口，使得只需要相对固定的几个Ｓtrｕｔs Aｃｔion类调用Serｖice层的方法,便可以完成工作。包括JＳON格式输出，XML输出及WebSerｖiｃe输出均调用Sｅrvice层方法来完成功能。这样便实现了业务代码的分离,以及与前端框架的极大解耦。
二、技术解决方案
开发一款好的软件产品,离不开一个好的开发过程。开发期间对过程的把控程度,往往会决定软件产品的质量好坏。因此,开发前期的计划流程是必不可少的。 本公司软件系统的开发是按阶段进行的，一般划分为以下阶段:
项 目 可行性分析 《可行性研究报告》 需求分析 《软件需求说明书》 概要设计 《概要设计说明书》 详细设计 《数据库设计说明书》 编码 《详细设计说明书》 测试 《测试计划》 修改完善 《测试分析报告》 验收 《验收报告》 维护 《用户操作手册》
1、可行性分析
可行性分析的目的是明确系统的目的、功能和要求，了解目前所具备的开发环境和条件,分析的内容有:
① 在技术能力上是否可以支持 ② 在经济上效益如何 ③ 在法律上是否符合要求
④ 与部门、企业的经营和发展是否吻合 ⑤ 系统投入运行后的维护有无保障
可行性讨论的目的是判定软件系统的开发有无价值，分析和讨论的内容形成“系统开发计划书\主要内容有：
（1） 开发的目的及所期待的效果
（2） 系统的基本设想,涉及的业务对象和范围 （３） 开发进度表，开发组织结构 (４） 开发、运行的费用 （5） 预期的系统效益
(６) 开发过程中可能遇到的问题及注意事项。
2、需求分析
需求分析是软件系统开发中最重要的一个阶段,直接决定着系统的开发质量和成败.因此必须要明确用户的要求和应用现场环境的特点，了解系统应具有哪些功能、数据的流程和数据之间的联系。
需求分析应有用户参加，到使用现场进行调研学习,软件设计人员应虚心向技术人员和使用人员请教，共同讨论解决需求问题的方法,对调查结果进行分析,明确问题的所在。
需求分析阶段的工作，可以分为四个方面：问题识别,分析与综合,制订规格说明，评审。 （一)、问题识别
从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括:功能需求(做什么）,性能需求（要达到什么指标），环境需求（如机型，操作系统等)，可靠性需求(不发生故障的概率),安全保密需求，用户界面需求，资源使用需求(软件运行是所需的内存,CPＵ等)，软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标。
（二)、分析与综合
逐步细化所有的软件功能,找出系统各元素间的联系，接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分。最后，综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型）。
（三）、制订规格说明书
即编制文档，描述需求的文档称为软件需求规格说明书。
（四)、评审
对功能的正确性,完整性和清晰性，以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析．
需求分析的内容最终会编写成“系统需求分析报告”。
3。系统设计
(一）、设计原则和设计要求
描述对本软件系统进行概要设计的原则,通常可以考虑以下几方面的内容: 1、命名规则; 2、模块独立性原则； 3、边界设计原则； ４、数据库设计规则； 5、必须的安全措施; 6、安全性和保密原则; ７、系统灵活性要求； 8、系统易操作性要求; ９、系统可维护性要求;
(二)、系统逻辑设计
系统逻辑设计主要是根据软件产品需求规格说明书和软件产品数据字典建立系统的逻辑模型。此种模型暂时与系统的物理因素(例如:计算机、数据库管理系统)无关。它是系统需求与物理实现的中间结构,它的主要结果是建立：系统结构图、系统界面结构图、系统出错处理、以及系统开发技术说明.
（三)、系统组织设计
系统组织设计通过系统组织表描述本系统由哪些子系统(模块)组成,这些子系统与业务职能之间的关系，以及各个子系统的安装地点。系统组织表的格式如下: 子系统编号 英文名称 中文名称 业务职能 安装地点 备注 其中: 1、子系统编号
给出本系统中指定子系统的顺序编号。如果本系统末划分为多个子系统,仅由一个运行模块组成;则本项内容仍需要描述，但是本表内容只有一行。
在一个系统中有可能安装若干个相同的子系统,在这种情况下,应该视为一个子系统,并且对多个安装地点分别进行描述.如果相同的子系统通过系统设置，实现的业务职能具有明显差异时,应该采用多行进行分别描述，并且在备注中说明其差异所在。 2、子系统英文名称
给出本子系统的英文名称，该名称是在应用软件中实际使用的可执行文件名称,必须能够说明该子系统的特点.
若本系统中只有一个子系统，则本项内容仍需要描述,但是本表内容只有一行。
3、子系统中文名称
给出本子系统的中文名称,该名称必须能够说明该子系统的特点。
若本系统中只有一个子系统，则本项内容仍需要描述，但是本表内容只有一行。 4、业务职能
描述该子系统完成的核心业务。 5、安装地点
描述该子系统实际安装的部门、或者某个具体地点. 6、备注
针对该子系统,需要说明的其它有关问题.
(四)、系统结构设计 １、系统特性表
系统特性是系统中完成某项具体操作的基本单元，它由入口参数,出口参数以及处理过程三部分组成.系统特性可以具有操作界面,也可以没有操作界面;可以被其它操作界面、或者系统特性调用,也可以调用其它操作界面、非操作界面、或者系统特性;但是不允许递归调用(调用自己),包括间接递归调用。
当系统由多个子系统（模块）组成时，每个子系统分别使用一张系统特性表进行描述。系统特性表的格式如下：
子系统编号： 子系统英文名称： 子系统中文名称： 特性编号 系统特征 系统特征 操作功能 调用对象 英文名称 中文名称 说明： 其中：
（1)、子系统编号
含义同上。 （2)、子系统英文名称
含义同上。 (3)、子系统中文名称
含义同上. (４)、特性编号
整个系统所有特性的统一编号. (5)、系统特性英文名称
系统特性的英文正式名称，将来用于软件开发中，必须符合命名规范。 （6)、系统特性中文名称
系统特性的中文正式名称，来源于需求规格说明书中,系统特性一节中的有关描述。 (7)、操作功能
是指该特性实际完成的操作说明。 (8)、调用对象
是指调用该系统特性的系统对象，这里的系统对象可以是系统特性、也可以是操作界面。
（9）、被调用对象
是指被该系统特性调用的系统对象,这里的系统对象可以是系统特性、也可以是操作界面。 （10)、备注
被调用对象 备注 描述与该系统特性有关的其它注意事项. （１1)、说明
描述与该系统特性表有关的其它注意事项。
（五)、系统接口设计 １、系统接口表
接口作为系统的一种输入/输出形式，分为网络接口、数据库接口、RS—23２串行通讯接口、ＩEEE—4８5串行总线接口、并行I／O接口等等多种类型。
当系统由多个子系统（模块）组成时,每个子系统分别使用一张系统接口表进行描述。系统接口表的格式如下: 子系统编号 子系统英文名称 子系统中文名称 接口编号 说明: 其中：
（1)、子系统编号
含义同上。 （2）、子系统英文名称
含义同上. (3)、子系统中文名称
含义同上． （4)、接口编号
整个系统所有接口的统一编号。 （5）、接口名称
系统接口的正式名称,必须符合通常习惯。 （6）、接口类型
指出该接口所传输的数据在该模块中起到的作用。
接口名称 接口类型 接口性质 接口速率 接口协议 备注 （7)、接口性质
指出该接口在通讯中起到的作用,这里的作用可以是：输入、输出、双向. （8)、接口速率
指出该接口的传输速率。如果该接口依赖于其它通讯方式，那么传输速率将不高于它所依赖的其它通讯方式的速率。 (9)、接口协议
给出该接口实际使用的通讯协议。 (1０)、相关对象
给出直接使用本接口的系统对象，这里的系统对象,可以是操作界面，也可以是系统特性。 (１1)、备注
描述与该系统接口有关的其它注意事项． (１2)、说明
描述与该系统接口表有关的其它注意事项。
（六）、系统完整性设计
描述系统对象(数据元、数据类),所受到的逻辑约束关系。
当系统由多个子系统（模块）组成时，每个子系统应分别使用一张系统完整性约束表进行描述。系统完整性约束表的格式如下: 子系统编号 子系统英文名称 子系统中文名称 约束编号 说明: 其中：
(1)、子系统编号
含义同上。 (2)、子系统英文名称
完整性名称 相对对象名 约束表达式 备注 含义同上。 (３)、子系统中文名称
含义同上。 (4)、约束编号
整个系统所有约束的统一编号。 (5)、完整性名称
系统完整性约束的正式名称,必须符合通常习惯。 (6)、相对对象名
完整性约束中的相关对象(数据元和数据类)。 (７)、约束表达式
用一阶逻辑表达式表达的约束方程式． (8）、备注
描述与该系统完整性约束有关的其它注意事项。 （9）、说明
描述与该系统完整性约束表有关的其它注意事项.
系统设计具体可根据系统的规模分成概要设计和详细设计两个阶段,概要设计包括：
① 划分系统模块 ② 每个模块的功能确定 ③ 用户使用界面概要设计 ④ 输入输出数据的概要设计 ⑤ 报表概要设计
⑥ 数据之间的联系、流程分析 ⑦ 文件和数据库表的逻辑设计 ⑧ 硬件、软件开发平台的确定
⑨ 有规律数据的规范化及数据惟一性要求。
系统的详细设计是对系统的概要设计进一步具体化,其主要工作有：
① 文件和数据库的物理设计 ② 输入输出记录的方案设计
③ 对各子系统的处理方式和处理内容进行细化设计 ④ 编制程序设计任务书。
程序说明书通常包括程序规范、功能说明、程序结构图，通常用HPIPＯ（Ｈｉeｒarｃhy Ｐlｕs Inｐｕt Proceｓｓ Output）图描述.
4、编码
根据程序设计任务书的要求,用计算机算法语言实现解题的步骤,主要工作包括：
① 模块的理解和进一步划分
② 以模块为单位的逻辑设计,也就是模块内的流程图的编制 ③ 编写代码，用程序设计语言编制程序 ④ 进行模块内功能的测试、单元测试。 程序质量的要求包括：
① 满足要求的确切功能 ② 处理效率高
③ 操作方便，用户界面友好
④ 程序代码的可读性好，函数、变量标识符合规范 ⑤ 扩充性、维护性好。
降低程序的复杂性也是十分重要的,系统的复杂性由模块间的接口数来衡量,一般地讲，n 个模块的接口数的最大值为ｎ(n—１)/2；若是层次结构，ｎ 个模块的接口数的最小值为ｎ-1。为使复杂性最小,对模块的划分设计常常采用层次结构。
要注意编制的程序或模块应容易理解、容易修改，模块应相互独立，对某一模块的修改应对其他模块的功能不产生影响,模块间的联系尽可能少。
5.系统测试
测试是为了发现程序中的错误,对于设计的软件,出现错误是难免的。系统测试通常由经验丰富的设计人员设计测试方案和测试样品,并写出测试过程的详细报告。系统测试是在单元测试的基础上进行的，包括：
① 测试方案的设计; ② 进行测试； ③ 写出测试报告；
④ 用户对测试结果进行评价。 具体测试方式如下:
1. 黑盒测试
黑盒测试也称为功能测试,它着眼于程序的外部特征,而不考虑程序的内部逻辑结构。测试者把被测程序看成一个黑盒,不用关心程序的内部结构。黑盒测试是在程序接口处进行测试,它只检查程序功能是否能正常使用，程序是否能接收输入数据产生正确的输出信息,并且保持外部信息(如数据库或文件）的完整性。黑盒测试是基于用户角度进行的测试。
2. 白盒测试
本公司系统软件测试的主要方法之一，也称结构测试、逻辑驱动测试或基于程序本身的测试。测试者需要了解待测试程序代码的内部结构、算法等信息，这是从程序设计者的角度对程序进行的测试.它的优点是帮助软件测试人员增大代码的覆盖率,提高代码的质量，发现代码中隐藏的问题。
3. 灰盒测试
可以理解为静态的白盒测试或动态的黑盒测试，灰盒就是界于黑白之间， 对软件内部有所了解, 但不见得到了如指掌的程度, 却可以结合这些了解做些比黑盒多点的测试。
4. 文档测试
文档测试涵盖面很大，在软件的各个版本中均有所使用.随着软件版本的变化,文档测试的测试内容也有所变化。在需求分析以及原型架构阶段,文档测试主要目标是: Sｉｔemap、动作分解列表、数据库ER图、ＵML用例图、流程图、需求文档等文档。
文档测试主要检查文档的正确性、完整性和可理解性。正确性是指不要把软件的功能和操作写错,也不允许文档内容前后矛盾。完整性是指文档不可以漏掉关键性内容．可理解性是指在文档中描述的语言要简明易懂,不能让别的开发人员拿到文档时看不懂文档的内容。
5. 命名规范测试
命名规范测试用于测试项目中的文件命名、代码以及版本号等书写是否符合规范．
6. 需求完整性测试
需求完整性测试主要存在于需求探索阶段,在需求尚未完全明确之前对已收集到的需求做出整理性的、检查遗漏性的测试,确认需求是否明确。另外，需求完整性测试也承担着一部分澄清需求的任务。
7. 链接完整性测试
在原型架构阶段，链接完整性的测试是非常有必要的。该项测试任务主要是检查假页面中各种链接是否完整,是否指向目标位置,属于检查性的测试。
8. 页面完整性测试
页面完整性测试主要存在于集成测试阶段以及其后续其它阶段中，测试页面是否完整,页面质量是否达标,属于检查性测试。
9. ＵＩ合理性测试
UI合理性测试也就是人机交互界面的合理性,ＵI合理性测试的内容很多,具体测试内容
如下:
o 提示、菜单、帮助的格式是否一致; o 提示、菜单、帮助中的术语是否一致; o 各个控件之间的对齐方式是否一致；
o 输入界面和输出界面在外观、布局、交互方式上是否一致; o 功能类似的相关界面在外观、布局、交互方式上是否一致;
o 同一层次的文字在同一种提示场合（一般情况、特殊字体、警告等）在文
字大小、字体、颜色、对齐方式方面是否一致,字体大小 是否与界面的大小比例协调;
o 多个连续界面依次出现的情况下，界面的外观、操作方式是否一致； o 系统是否拒绝客户的错误输入并做出提示； o 系统是否在用户完成操作时给出操作成功的提示；
o 用户界面是否存在空白空间,没有空白空间的界面是杂乱无章的,易用性
差;
o 各个控件的间隔是否一致,垂直和水平方向上是否对齐; o 是否允许动作的可逆性，返回原有操做；
10. 数据和数据库完整性测试
在开发阶段开发人员随时都有可能根据需要来修改数据库,所以对数据和数据库完整性测试在软件项目的任何阶段也是非常必要的。该项测试内容主要是以数据库表为单位,检查数据库表以及表中各字段命名是否符合命名规范，表中字段是否完整,数据库表中的字段描述是否正确包括字段的类型、长度、是否为空,数据库表中的关系、索引、主键、约束是否正确。
11. 功能测试
功能测试在软件项目的任何阶段中都是重要的。实现功能,满足客户需求是软件本身最大的使命。功能测试在任何阶段下基本上都作为测试工作的第一项出现.该项测试任务主要为了测试已实现的功能是否满足需求,是否正确，是否有价值以及是否完整。在黑盒和白盒测试状态下,该测试均会被使用。
功能测试中测试人员往往会忽略掉一些细节问题,比如:一个功能的实现必须要经过６步操作才能完成,而且需要加入２０条信息才能看得出测试结果,有的测试人员为了节省时间虽然做完了6步操作,但是没有加入足量的信息,使得测试不全面,正是因为这样而导致一些隐藏的BUG没有被测试出来.所以说在功能测试中要按部就班的把所有要进行的测试功能每一步都执行一遍,应该添加的数据都添加完整,以避免遗漏掉BUG没有测试出来.
12. 压力测试
压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。这通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的。这种操作也称为负载测试,但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。
对应用程序进行压力测试最简单的方法是手工改变输入（客户机数量、需求大小、请求的频率、请求的混合程度等等)并描绘性能的变化。但是如果有许多输入，或者需要在大的范围内改变输入，那么你可以借助一个自动化的压力测试工具来完成此测试。
13. 安全性测试
安全性测试主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据和页面的安全。测试人员可以学习一些黑客技术,来对系统进行攻击。 另外,对操作权限的测试也包含在安全性测试中。具体测试内容如下:
o 执行添加、删除、修改等动作中是否做过登录检测。 o 退出系统之后的操作是否可以完成。
o 所有插入表单操作中输入特殊字符是否可以正常输正常存储,特殊字符
为：！?#￥％……—*(）～———＋=[]｛｝、|;:‘”?／《》<〉,.
o 在带有参数的回显数据的动作中更改参数,把参数改为特殊字符并加入操
作语句看是否出错.
o 测试表单中有没有做标签检测,标签检测是否完整.
o 在插入表单中加入特殊的HTML代码,例如： 14. 页面脚本测试 页面中时常使用到ＪaｖaSｃｒipt脚本,为了降低页面的出错率,则必须对页面脚本进行测试。其主要内容包括：相关页面中的脚本是否正常运行,JaｖaScｒipt脚本是否有错误页面。 15. 提示文本测试 提示文本测试从严格意义上来讲应该属于UＩ合理性测试的一部分，该项测试主要针对各个页面中使用到的大量提示文档进行测试，主要包括:表达不明确的位置是否有提示文本、提示文本的弹出是否正常、提示信息含义是否明确易懂. 16. 浏览器测试 由于B/S结构项目是基于浏览器运行的,所以需要对浏览器进行必要的测试．该测试任务主要是软件对各种浏览器（IE5。5、IE6.０、 ＦireFｏx浏览器 )的支持是否正常,在IE浏览器中可以正常显示的页面在其它浏览器中是否可以正常显示。 17. 安装测试 在软件项目的后期阶段,会对做好的软件进行打包把软件做成安装程序，以便用户可以正确的安装使用，所以需要对做好的安装文件进行安装功能方面的测试。该测试的主要任务是：检查软件是否能够正常安装使用、是否可以完全卸载此软件的所有功能和页面。 6、文档资料 文档包括开发过程中的所有技术资料以及用户所需的文档,软件系统的文档一般可分为系统文档和用户文档两类。 用户文档主要描述系统功能和使用方法，并不考虑这些功能是怎样实现的,系统文档描述系统设计、实现和测试等方面的内容。文档是影响软件可维护性、可用性的决定因素,有句话讲，系统编程人员的每一张纸片都要保留,所以文档的编制是软件开发过程中的一项重要工作。系统文档包括： ① 开发软件系统在计划 ② 需求分析 ③ 设计 ④ 编制 ⑤ 调试 ⑥ 运行等阶段的有关文档。 在对软件系统进行修改时,系统文档应同步更新,并注明修改者和修改日期，如有必要应注明修改原因,应切记过时的文档是无用的文档. 用户文档包括： ① 系统功能描述 ② 安装文档，说明系统安装步骤以及系统的硬件配置方法 ③ 用户使用手册,说明使用软件系统方法和要求,疑难问题解答 ④ 参考手册，描述可以使用的所有系统设施，解释系统出错信息的含义及解决途径. 7、系统的运行与维护 系统只有投入运行后，才能进一步对系统检验,发现潜在的问题，为了适应环境的变化和用户要求的改变,可能会对系统的功能、使用界面进行修改。要对每次发现的问题和修改内容建立系统维护文档,并使系统文档资料同步更新。 １2。4。4 服务保证措施 本公司软件质量保证由各项任务构成，这些任务的参与者有两种人：软件开发人员和质量保证人员。前者负责技术工作，后者负责质量保证的计划、监督、记录、分析及报告工作。软件开发人员通过采用可靠的技术方法和措施，进行正式的技术评审,执行计划周密的软件测试来保证软件产品的质量。软件质量保证人员则辅助软件开发组得到高质量的最终产品。 我们的软件质量保证计划大体分为如下三大部分： ① 把软件研制合理地划分为若干阶段,并针对每个阶段的特点，制定出质量评审、评测 的要求和措施。 ② 从软件质量的要求出发,制定出相应的技术和管理规范，如软件文档规范、软件编程 规范、软件测试规范、软件版本控制规范等. ③ 创建和积累公用模块,向软件工厂化方向发展． 1、软件研制的阶段划分及其质量控制 我们把软件系统的研制划分为8个阶段,即总体需求分析、总体设计、各分系统的需求说明及概要设计、详细设计（面向子系统)、程序编制、自测试、组装与验收测试、试用和初步定型。 我们规定，总体需求分析及总体设计需经有关领导及管理专家评审认定.分系统的需求说明、概要设计及详细设计需经总工程师组织的技术评审组评审．评审前,多数分系统的需求说明及概要设计需经有代表性的用户审核认可,即分析和设计阶段主要靠评审把关，编程和实施阶段主要靠执行规范和测试把关。每次评审的结果都有相应的记录,并填写相应的表格。 2、软件的文档规范 系统开发的文档要求是:每个分系统必须有需求说明、概要设计，每个子系统必须有详细设计和操作使用说明.需求说明、概要设计和详细设计必须串行完成,而且规定,详细设计未经评审通过不能进入正规编程.不写设计就进入编程，这是软件开发人员常犯的毛病,在我们的系统开发中这是不允许的。 3、软件编程规范 开发中所有设计文件经过认真的评审、推敲和认定后,软件编程将是保证软件质量的一个重要环节。为保证这一环节的质量,我们专门制定了编程的有关规范。其中最主要的是界面规范。 需要强调的是,对界面的理解不应只限于屏幕格式和操作方法，界面设计应贯穿于软件编制的全过程，我们的界面规范分为两大部分: 第一部分是设计原则,包括:一般原则、屏幕格式设计原则、输入过程设计原则、信息显示设计原则、提示信息设计原则、报表设计原则、菜单设计原则、操作方法原则。它重点解决操作的方便性和直接性、显示和提示的确定性、输入的准确性、输入输出的一致性,以保证对用户习惯和心理的良好适应性,给用户一种愉快感，让用户产生一种喜爱感。 第二部分是屏幕格式设计，包括：版权屏幕、登录屏幕、单记录录入窗口、多记录录入窗口、查询列表窗口、 主/细数据录入窗口、命令按钮格式。它的主要目标是，力求使屏幕格式简炼、实用、直观、醒目、格调一致，使操作使用方便。 软件编程规范更是一种设计和编程经验的总结，是对所用开发工具的深入认识和全面理解.这一规范本身的质量直接关系到全系统的编程效率和可移植性、软件的可扩展性及可维护性、数据的可恢复性和系统的可靠性。特别是在客户／服务器模式下工作的系统,编程时对处理和数据的合理分布将直接影响到系统资源利用得是否充分、恰当，直接影响到整个系统的性价比. 它包括:对象和控制命名规范、编程风格、数据校验、环境配置与应用的可移植性、事件驱动、面向对象、数据库访问规范、数据及处理分布、出错处理、安装及设置。实践证明,这一规范对保证程序质量、提高软件重用度，进而对提高编程效率、乃至提高系统的可靠性均起了重要作用。 4、软件测试规范 软件测试是在设计阶段保证软件质量的最后一关.从测试手段来说,我们把整个测试分为白盒测试和黑盒测试,并在软件编制过程中交叉使用。指派对开发工具认识最深入、编程经验最丰富的同志从事白盒测试;指派对工作流程最熟悉、对操作使用研究和体会最细致的同志从事黑盒测试。从测试过程来说，又分为两步：自测试和组装验收测试。自测试是软件编制者自己设计测试用例,自己验证;组装和验收测试则是按照需求说明和工作流程全面设计测试案例,进行全面测试。工作流程、数据流程、各子系统之间及各模块之间的接口是验收测试的重点之一。 整个测试阶段必然是一个发现问题→修改完善→再测试的过程,而且可能多次反复．此时,最重要的是要把握住两点：一是每提出一个修改,都需经过总体设计师和分系统设计者的认真研究讨论,既要保证软件的正确性、流程的合理性和功能的完备性，又要保证总体设计思想和软件设计风格不受破坏,即保证软件的整体质量;二是程序编制者和测试者都要有足够的耐心和良好的协作精神,都要有对软件质量负责的责任感。 无论自测试,还是组装及验收测试,都是极其细致而又繁琐的过程。不少技术人员愿意搞设计和编程,而不愿在测试方面多花功夫.软件开发的管理者对这种倾向需严密注视、尽力防范,同时应做出具体规定,作为软件设计的法规,要求大家严格遵守。测试规范的概要如下在自测试阶段制定了自测试方法和自测试过程。 自测试方法重点规定了两点:一是白盒测试、人工审查与机器执行相结合；二是给出了测试用例设计原则,即模块内部和模块间的测试用例设计原则及重点检查的内容。自测试过程分为代码审查、模块测试、组装测试和整理测试报告四个过程。规范中详细规定了每一过程的细节和要求.组装及验收测试规范中同样规定了测试方法和测试过程. 其中，重点强调三点：一是再次推敲流程是否合理，功能是否齐全；二是测试用例设计必须考虑如下几方面要求：功能测试、性能测试、大数据量测试、可靠性测试、可恢复性测试、多用户测试、安装测试和配置测试；三是要重视模块和子系统之间的接口测试。 5、软件版本控制 版本控制是对已做成的软件在发展过程中的一种质量管理,各大公司对自己的软件均有一套版本控制方法。我们开发的软件系统绝不是“一锤子买卖”,推出了第一期软件的试用版，还会有第二期软件补充进来,两期软件到一定阶段都将定为正式版,而且今后还会继续发展,到一定时候还要更新。何时定为正式版,何时宣布版本升级，都需要有明确的要求和界限,两个版本之间的任何修改和维护都需要一套管理办法。升级也好，更新也好，都需要考虑与 原来版本的兼容,以保护用户的投资利益。 6、建立公共模块,向工厂化方向发展 尽管一套软件系统可分为若干分系统和子系统,但它们仍会有一些共同或类似的操作。将共同操作抽取出来，制成若干公用模块,供各子系统调用或直接使用，这不仅可提高软件的编程效率，也直接提高了软件质量。这虽属于总体设计和总体规划中的工作,但从质量管理的角度重视这一工作，把它作为软件质量保证的一项措施，也很有意义。 12。4．5 技术培训计划 １、概述 人员培训作为工程实施的一个重要环节,对整个项目的实施至关重要，通过系统的培训,使得工作人员得到日常工作需要的专业技术知识和经验,从而保障整个系统的顺利运行。 项目建设最终系统将交付用户使用,项目培训是项目实施中的重要环节，通过项目培训对业主人员进行全面的技术培训，使业主单位人员达到能独立进行管理、故障处理、日常测试维护等工作,以便于我方提供的软、硬件能够正常、安全的运行。 培训的总体目标： 1、管理员培训。 培训对象：系统管理员。 培训目的：可以独立完成本单位行政执法的日常维护，解决一般问题。 培训内容:系统体系结构、系统配置、系统管理、系统使用. 培训方式：集中培训和个别培训。 培训批次：不少于1次的集中培训,个别培训随时安排。 ２、使用人员培训 培训对象：系统一般使用人员。 培训目的：熟练掌握所涉及部分的操作. 培训内容：系统使用。 培训方式:集中培训和个别培训． 培训批次:不少于2次的集中培训,个别培训随时安排. 2、培训对象 如果项目是一项综合型的项目,系统使用范围广,用户层次多，不同用户层次使用的系统角色不相同，使用的内容和侧重点各不相同，那么我们在项目中将针对不同的用户层次提供针对性的用户培训，保障培训效果,使各层次的用户都能熟练掌握系统相关的知识． 2。1、普通用户层 普通用户层是应用系统的直接使用者,涉及到系统的各方面功能，是对系统功能理解最深、业务最熟悉的用户群,然而普通用户层由于覆盖的面广，各部门主要使用的功能模块不尽相同,因此针对于普通用户将按照不同的部门的侧重点进行分期培训，组织类似业务部门或单独部门进行培训,以便于各部门对各自业务系统使用的把握，以达到各用户能熟练掌握系统的使用方法。 ２.２、系统管理员和应用级管理员 系统管理员和应用级管理员是业主单位对系统进行管理维护的主要人员,这一用户群掌握一定的信息技术，并且针对应用系统管理员和平台维护员分别进行针对性的培训,主要侧重于系统的建设原理和规划,总体架构，常见问题的解决,系统安装配置等内容。系统的维护和管理工作需要对应用系统较熟悉，并且能处理运行过程中遇到的各类问题,因此对于软件维护人员和管理员将采用共同参与项目维护和实施的方式,从长期实践中逐渐掌握系统维护知识，提升其技术技能和对系统的认识. 2.3、技术人员培训 技术人员主要是指业主单位具备一定的应用系统开发能力,主要用于系统上线后对系统的需求变动进行二次开发和修改,以及系统扩展能力的技术人员，针对这一用户群，将着重于应用系统的开发原理、开发工具、系统架构等进行培训,使其掌握系统二次开发技术,为今后系统升级改造、功能扩展储备技术力量。 3、培训课程 3。1、应用系统使用培训 课程名:系统应用。 课程内容: 计算机系统基本操作方法;系统基本功能介绍;业务流程规范;系统使用方法。 课时:1天。 3．２、系统运维技术培训 课程名：日常维护培训。 课程内容: 系统总体逻辑及工作原理;系统基本功能介绍；可视化流程定制工具使用方法;可视化表单定制工具使用方法;系统的部署，应用的安装，系统的使用、配置、管理和备份，系统日常维护任务;系统故障处置方法。 课时：4天。 3。３、项目管理初级（可选) 课程名:项目管理初级． 课程内容: 项目管理基本知识；项目管理方法；项目管理工具应用。 课时:1天。 ３.4、系统支撑软、硬件环境应用管理 课程名:系统支撑软、硬件环境应用管理. 课程内容: 操作系统安装、配置和管理；数据库安装、配置和管理;支撑环境常规故障处置方法． 课时：３天。 3。5、系统设计与开发基础(可选) 课程名:系统设计与开发。 课程内容: 系统设计基础;开发工具使用初步;系统开发规范;数据库设计基础;系统二次开发方法. 课时：5天。 4、培训组织保障 公司会建立专业的项目培训小组，人员配置如下： 项目培训组组长:1人 培训讲师:2人; 培训监督员：1人; 培训资料管理员:1人; 培训组织人员：1人; 5、教学方案 如果项目是一个综合型的项目,培训对象层次分明,培训内容多样,且在系统上线培训期间各用户还有自身的事务需要处，那么公司会在培训过程中将针对不同的用户和不同的培训内容采用不同的培训方案,以达到最佳的培训效果，培训方案如下图所示: 5。1、实践培训 实践培训是指在项目实施过程中与我方工程师一道参与项目研发和实施过程,在实践过程中逐渐掌握培训内容。实践培训主要针对于技术开发人员及系统维护和管理人员。在项目实施之初即邀请技术开发人员与我公司开发人员一起参与项目开发过程,从大量的实践过程中获取开发知识,以便于对系统的设计、开发语言、系统架构熟悉,为业主单位培养较全面，对系统理解较深的专业技术人员. ５。2、集中培训 集中培训将培训对象集中,以授课的方式进行培训。这类培训主要针对于培训用户较多，培训内容较单一的内容进行,如最终用户使用培训。通过演示和现场交流的方式达到培训效果。 5.3、研讨会 在项目实施过程将不定期进行研讨会。召集技术相关人员或业务处理人员,针对技术的发展和业务模型的处理通过交流的方式进行讨论，在研讨会上将邀请业界的专家列席，以便于相互之间的交流,对参与交流会的人员提供技术咨询和指导，促进业主单位技术和业务水平的提高。 5。4、远程培训 当培训用户无法集中,或聘请远程专家进行培训时，我们将采用网络培训的方式完成远程培训工作。 5.５、一对一培训 一对一培训主要针对于统一培训时无法参加、未掌握培内容或个别特殊用户如领导、唯一的系统管理员、特殊的业务操作人员等,进行一对一的单独培训。 6、培训规模设定建议 培训的规模大小主要看受训的人数和受训次数,百人以上就可算是较大规模的培训．从培训的效果来看，一次性受训的人数超过４0人后，培训的效果下降地越快。一次性受训的人数为２0人,培训的效果和效率是相对最佳的。 所以对于大型软件的培训，在受训人数较多的情况下,常用的办法是：化整为零,将受训人员分为20—40个人一批,进行分批、分时或同时进行培训，不宜进行大课培训。 同时针对培训对象的不同，培训的规模也可以进行适当地调整，如:领导干部、技术人员和主要业务系统使用人员，人数不是很多的情况下，为了更好的效果,将人数尽量小组化的情况下批次不会有明显增加（因为批次过多，学习的内容不能同步，影响了相互沟通的及时性)，将人数分为５－10人一批，这样便能保证重点用户的培训质量。 7、培训阶段安排 公司项目的培训内容丰富，培训对象也各不相同，我们将针对不同的培训对象和培训内容安排在项目建设过程中的不同阶段完成，以达到良好的培训效果。 7。1、系统开发阶段 主要针对业主单位技术开发人员的培训，本阶段的培训主要以一对一培训、实践培训为主要方式进行培训。 7.2、初验 初验时需要对系统进行大量的性能、功能、业务测试，此时主要针对系统管理员和开发人员进行现场的测试培训，以便于系统管理员和开发人员了解系统测试方法，及时了解系统业务,以便于系统的维护。 7。3、系统安装 系统安装过程中主要是通过实践活动,对系统管理员与应用级管理员进行系统安装、配置等的培训。 ７.４、调试 调试过程中主要针对系统管理员和技术人员进行系统的调试进行培训,以便于系统管理员和技术人员及时了解系统调试方法,保障系统在出现故障时能及时解决． 调试成功后将大规模地组织最终用户培训. 7。5、试运行 试运行阶段主要培训对象为系统管理员和最终用户。 在试运行期间将出现系统日常维护问题,通过对现实问题的解决,增强系统管理员日常维护能力,使受训人员能熟练掌握包括人机通信在内的软件维护工作并能及时排除大部分的故障。 通过集中式的培训，最终用户基本掌握了系统的使用方法,在试运行过程中将通过实际的一对一培训和系统使用过程,进一步巩固和加深,达到熟练的操作程度. 7.6、最终验收 最终验收将对系统管理员进行系统日常备份和日常维护的培训,使受训学员能在维护期内能解决大部分的故障,保障系统的稳定运行。 8、培训质量保障 为了确保培训的质量,我们导入了《 ＩSO1００15 国际培训标准体系质量管理——培训指南》。 ISO10015 标准的作用是帮助组织识别和分析培训需求、设计和策划培训、提供培训、评价培训结果并监视和改进培训过程提供指南以达到其目标。为了保证培训质量,我们承诺在培训工作中严格遵循ISO１0015标准: 1、确定培训需求:确定业务和技术岗位的能力要求，评价现有人员已有能力,确定能力差距,形成培训需求说明书。作为设计和策划培训阶段的输入域。该阶段的重点是定位人员实际能力与岗位能力需求的差距，即明确“缺什么”。 ２、设计和策划培训:确定制约条件、培训方式和选择准则、培训计划、选择培训提供者构成了它的核心内容。该过程的重点是根据需求阶段已明确的人员能力差距策划具体的培训方案,决定“补什么\"． 3、提供培训:提供培训（含培训前支持、实施培训和培训后支持). 该过程的重点在于用正确的“滋补”方式提高学员的能力，使学员真正能够从培训中学到有价值的东西，也就是解决“怎么补”的问题。 4、评价培训结果：收集资料并准备评价报告,评估本阶段培训是否到达预期效果，为下一阶段的培训策划和改进提供参考. 5、培训过程的监视和改进:培训过程的确认。 12。4.６ 售后服务方案 售后服务作为企业整体服务中最为重要的组成部分，已经成为重要的竞争手段。良好的售后服务不仅能为企业赢得市场,扩大市场占有率,使企业获得良好的经济效益,而且通过售后服务的实施可以使企业获得来自市场的最新信息，促使企业更好地改进产品和服务，使企业始终处在竞争的领先地位,为企业实现可持续发展战略提供决策依据。我公司本着这些落脚点做出如下的服务方案: 1、安装调试服务 （1)我公司负责按合同中规定的软件型号、数量将产品送达指定地点,并保证按合同要求按时完成设备安装、调试、启动、运行等工作; （２)我公司按照合同要求测试所有硬件、软件； （3)我公司提供技术培训; （4)我公司负责合同中所有产品的现场安装调试、现场验收测试。 （5）产品到达后，由本公司和用户人员监督下，由用户人员清点，检查产品。 (6)所有产品完成安装调试后，双方即可进行验收测试。 （７）服务人员对产品的使用、注意事项，服务人员现场进行演示解说;客户对产品的疑问，服务人员给予一一解答。 2、售后电话服务 (1)客户来电咨询我公司的产品信息，服务人员接到电话后应给予全面的解析。 （2)本公司售后服务人员接到客户来电,对于问题不大或者可以在电话中直接解决的 问题，应立即给客户解决。 （3)若客户遇到的问题通过电话沟通的方式不能得到良好的解决,需要上门服务的客户，电话人员应立即问清客户问题和客户信息，并做客户问题登记,将问题转交相关人员，在3个工作日内必须与之处理。 3、上门服务 关于我公司的上门服务，必须是在正常合理的,不违反法律法规等的前提下，顾客在使用本公司产品的过程中出现问题而不能通过电话或者网络方案解决的前提下而使用的一种直接面对面为顾客提供的一种服务方案。 本方案流程如下: 第一步：客户服务人员接到客户的来电或者网络信息,不能通过交流解决只能上门服务的问题,客户人员需精确了解客户的问题所在，登记客户问题和客户信息. 第二步：客户服务人员将客户需求上门服务的信息交予相关工作人员。 第三步:相关工作人员接到上门服务信息，应已最快的时间将任务分配到公司具体人员手中。 第四步：上门服务人员接到上级分配的任务,应立即联系到顾客，与顾客约定上门时间。 第五步：上门服务人员在与顾客约定的时间内到达顾客地址，为其服务并收取相应的费用。 第六步:服务人员返回公司,需将此次的服务中所出现的问题和内容做一个系统报告提交公司售后服务部. 第七步:我公司对于此次的服务做一次电话或者网络回访,咨询顾客对于产品使用状况及用户在服务过程中的感受。 企业为顾客服务不仅是为了保证顾客的满意度和忠诚度，更多的可以收集客户信息，了解顾客需求。从而促进公司的产品更加完善，得到顾客的青睐。良好的售后服务能为企业的今后的发展带来巨大的商机,所以我公司的售后服务不仅仅是着眼于为顾客服务，还要能够很好的收集客户意见,了解客户需求信息,完善公司产品. 因篇幅问题不能全部显示，请点此查看更多更全内容