软件项目招投标文件技术标书最全最详细

1、. 软件工程招标文件技术标书(最全最详细)12.4.2 供给商针对本工程技术效劳类总体要求的理解 在软件开发的过程中，我们一向遵循软件产品的以下原则: 1、功能性:与一组功能及其指定的性质有关的一组属性，具体包括: 适合性:与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性 准确性:与能否得到正确或相符的结果或效果有关的软件属性 互用性:与同其他指定系统进展交互的能力有关的软件属性 依从性:使软件遵循有关的标准,约定,法规及类似规定的软件属性 平安性:与防止对程序及数据的非授权的成心或意外访问的能力有关的软件属性 2、可靠性:与在规定的一段时间和条件下,软件维持其性能水平的能力有关

2、的一组属性，具体包括: 成熟性:与由软件故障引起失效的频度有关的软件属性 容错性:与在软件故障或违反指定接口的情况下,维持规定的性能水平的能力有关的软件属性 易恢复性:与在失效发生后,重建其性能水平并恢复直承受影响数据的能力以及为达此目的所需的时间和能力有关的软件属性 3、易用性:与一组规定或潜在的用户为使用软件所需作的努力和对这样的使用所作的评价有关的一组属性，具体包括: 易理解性:与用户为认识逻辑概念及其应用围所花的努力有关的软件属性 易学性:与用户为学习软件应用所花的努力有关的软件属性 易操作性:与用户为操作和运行控制所花努力有关的软件属性 4、效率:与在规定的条件下,软件的性能水平与所

3、使用资源量之间关系有关的一组属性，具体包括: 时间特性:与软件执行其功能时响应和处理时间以及吞吐量有关的软件属性 资源特性:与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性 5、可维护性:与进展指定的修改所需的努力有关的一组属性，具体包括: 易分析性:与为诊断缺陷或失效原因及为判定待修改的局部所需努力有关的软件属性 易改变性:与进展修改,排除错误或适应环境变化所需努力有关的软件属性 稳定性:与修改所造成的未预料结果的风险有关的软件属性 易测试性:与确认已修改软件所需的努力有关的软件属性 6、可移植性:与软件可从*一环境转移到另一环境的能力有关的一组属性，具体包括: 适应性:与软件

4、无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性 易安装性:与在指定环境下安装软件所需努力有关的软件属性 遵循性:使软件遵循与可移植性有关的标准或约定的软件属性 易替换性:与软件在该软件环境中用来替代指定的其他软件的时机和努力有关的软件属性 基于以上原则，根据工程的不同需求，我们将会考虑采用B/S和C/S两种模式开发。 1、B/S模式 B/S是Brower/Server的缩写，客户机上只要安装一个浏览器(Browser)，如Netscape Navigator或Internet E*plorer，效劳器安装Oracle、Sybase、Informi*或 SQL Se

5、rver等数据库。浏览器通过Web Server 同数据库进展数据交互。B/S模式较C/S模式: C/S模式客户端需要安装专用的客户端软件。首先涉及到安装的工作量，其次任何一台电脑出问题，如病毒、硬件损坏，都需要进展安装或维护。特别是有很多分部的情况，不是工作量的问题，而是路程的问题。还有，系统软件升级时，每一台客户机需要重新安装，其维护和升级本钱非常高。C/S模式对客户端的操作系统一般也会有限制，可能适应于Windows系列操作系统，而不适用于Linu*、Uni*等操作系统。 而B/S最大的优点就是可以在任何地方进展操作而不用安装任何专门的软件。只要有一台能上网的电脑就能使用，客户端零维护。

6、系统的扩展非常容易，只要能上网，再由系统管理员分配一个用户名和密码，就可以使用了。甚至可以在线申请，通过公司部的平安认证(如CA证书)后，不需要人的参与，系统可以自动分配给用户一个账号进入系统，这在最大程度上满足了工程要求。 系统采用的是目前较流行的一种Web应用程序开源框架-Struts+Spring+Hibernate(SSH)。 集成SSH框架的系统从职责上分为四层:表示层、业务逻辑层、数据持久层和域模块层，以帮助开发人员在短期搭建构造清晰、可复用性好、维护方便的Web应用程序。其中使用Struts作为系统的整体根底架构，负责MVC的别离，在Struts框架的模型局部，利用Hiberna

7、te框架对持久层提供支持，业务层用Spring支持。具体做法是:用面向对象的分析方法根据需求提出一些模型，将这些模型实现为根本的Java对象，然后编写根本的DAO接口，并给出Hibernate的DAO实现，采用Hibernate架构实现的DAO类来实现Java类与数据库之间的转换和访问，最后由Spring完成业务逻辑。 系统的根本业务流程是: 在表示层中，首先通过JSP页面实现交互界面，负责传送请求(Request)和接收响应(Response)，然后Struts根据配置文件(struts-config.*ml)将ActionServlet接收到的Request委派给相应的Action处理。在

8、业务层中，管理效劳组件的Spring IoC容器负责向Action提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完成业务逻辑，并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。而在持久层中，则依赖于Hibernate的对象化映射和数据库交互，处理DAO组件请求的数据，并返回处理结果。 采用上述开发模型，不仅实现了视图、控制器与模型的彻底别离，而且还实现了业务逻辑层与持久层的别离。这样无论前端如何变化，模型层只需很少的改动，并且数据库的变化也不会对前端有所影响，大大提高了系统的可复用性。而且由于不同层之间耦合度小，有利于团队成员并行工作，大大提高了开发效率

9、的同时，也保证了软件产品的质量。 2、C/S模式 C/S (Client/Server，客户机/效劳器)模式又称C/S构造，是20世纪80年代末逐步成长起来的一种模式，是软件系统体系构造的一种。C/S构造的关键在于功能的分布，一些功能放在前端机(即客户机)上执行，另一些功能放在后端机(即效劳器)上执行。功能的分布在于减少计算机系统的各种瓶颈问题。C/S模式简单地讲就是基于企业部网络的应用系统。与B/S(Browser/Server，浏览器/效劳器)模式相比，C/S模式的应用系统最大的好处是不依赖企业外网环境，即无论企业是否能够上网，都不影响应用。 C/S构造效劳器通常采用高性能的PC、工作站或

10、小型机，并采用大型数据库系统，如ORACLE、SYBASE、InfORMi*或 SQL Server。客户端需要安装专用的客户端软件。 C/S构造的优点是能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给效劳器,因此对应的优点就是客户端响应速度快。 C/S架构软件的优势与劣势: (1)应用效劳器运行数据负荷较轻。最简单的C/S体系构造的数据库应用由两局部组成，即客户应用程序和数据库效劳器程序。二者可分别称为前台程序与后台程序。运行数据库效劳器程序的机器，也称为应用效劳器。一旦效劳器程序被启动，就随时等待响应客户程序发来的请求;客户应用程序运行在用户自己的电脑上，对应于数据库效劳

11、器，可称为客户电脑，当需要对数据库中的数据进展任何操作时，客户程序就自动地寻找效劳器程序，并向其发出请求，效劳器程序根据预定的规则作出应答，送回结果，应用效劳器运行数据负荷较轻。 (2)数据的储存管理功能较为透明。在数据库应用中，数据的储存管理功能，是由效劳器程序和客户应用程序分别独立进展的，并且通常把那些不同的(不管是还是未知的)前台应用所不能违反的规则，在效劳器程序中集中实现，例如访问者的权限，可以重复、必须有客户才能建立定单这样的规则。所有这些，对于工作在前台程序上的最终用户，是透明的，他们无须过问(通常也无法干预)背后的过程，就可以完成自己的一切工作。在客户效劳器架构的应用中，前台程序

12、不是非常瘦小，麻烦的事情都交给了效劳器和网络。在C/S体系的下，数据库不能真正成为公共、专业化的仓库，它受到独立的专门管理。 C/S模式系统的开发: C/S构造是建立在中间件产品根底之上的，要求应用开发者自己去处理事务管理、消息队列、数据的复制和同步、通信平安等系统级的问题。这对应 用开发者提出了较高的要求，而且迫使应用开发者投入很多精力来解决应用程序以外的问题。这使得应用程序的维护、移植和互操作变得复杂。如果客户端是在不同的操作系统上，C/S构造的软件需要开发不同版本的客户端软件。但是，与B/S构造相比，C/S技术开展历史更为悠久。从技术成熟度及软件设计、开发 人员的掌握水平来看，C/S技术

13、应是更成熟、更可靠的。 12.4.3 工程总体架构及技术解决方案 一、工程总体架构 (一)、SSH框架介绍和分析 大型企业级Web应用系统的开发通常要求有一个良好的软件架构、便于协作开发和扩展升级，而传统的开发模式不能很好地满足这些要求。 基于当前Web应用程序开发面临的问题，工程结合目前比拟流行的开源框架SSH(Spring、Struts、Hibernate)，具体讨论其根本相似性及有关根本概念，提出了一种开发JavaEE Web应用的轻量级解决方案，此系统架构可以在短期搭建构造清晰、可复用性好、可扩展性好、维护方便的Web应用程序。 1、框架技术 框架一般具有即插即用的可重用性、成熟的稳定

14、性以及良好的团队协作性。JavaEE复杂的多层构造决定了大型的JavaEE工程需要运用框架和设计模式来控制软件质量。目前，市场上出现了一些商业的、开源的基于JavaEE的应用框架，其中主流的框架技术有:基于MVC模式的Struts框架、基于IoC模式的Spring框架以及对象/关系映射框架Hibernate等。 2、框架共同点 所有现代的网络开发框架几乎都遵循了模型-视图-控制(MVC)设计模式:商业逻辑和描述被分开，由一个逻辑流控制器来协调来自客户端的请求和效劳器上将采取的行动。这条途径成为了网络开发的事实上的标准。每个框架的在的机制当然是不同的，但是开发者们使用来设计和实现他们的Web应用

15、软件的API是很类似的。差异还存在于每个框架提供的扩展方面,例如标签库，JavaBean包装器等。 所有的框架使用不同的技术来协调在Web应用程序之的导航,例如*ML配制文件，java属性文件或定制属性。所有的框架在控制器模块实现的方法方面也存在明显的不同。例如,E可能实例化在每个请求中需要的类或使用Java反射动态地调用一个适当的行为(Action)类。另外,不同框架在各自引入的概念上也有所不同。例如,一个框架可能定义用户请求和反响场所，而另外一个框架可能仅仅定义一个完整的流:从一个请求到多个响答和随后的再请求。 各种Java框架在它们组织数据流的方法方面是很类似的。在请求发出后，在应用程序

16、效劳器上产生一些行动;而作为响应，一些可能包含对象集的数据总是被发送到WEB层。然后从那些对象:可能是有setter和getter方法的简单类、JAVABEANS、值对象、或者一些集合对象中提取数据。现代的Java框架还想方设法简化开发者的开发任务，如通过使用简易的API、数据库连接池、甚至数据库调用包等提供自动化的追踪方式来实现。一些框架或者能够钩进(hooked into)另外的JavaEE技术中,例如JMS(Java消息效劳)或JM*,或把这些技术集成到一起。效劳器数据持续性和日志也有可能成为框架的一局部。 3、MVC模式 MVC模式是一个用于将用户界面逻辑与业务逻辑别离开来的根底设计模

17、式，它将数据处理、界面以及用户的行为控制分为:Model(模型),View(视图),Controller(控制器)。 Model:负责当前应用的数据获取与变更及相关的业务逻辑。可用JAVABEAN来表达; View:负责显示信息。可以使用JSP、VELOCITY模板等技术; Controller:负责收集转化用户的输入。常用一个SERVLET来实现; View和Controller都依赖于Model，但是Model既不依赖于View，也不依赖于Controller，这是别离的主要优点之一，这样Model可以单独的建立和测试以便于代码复用，View和Controller只需要Model提供数据，

18、它们不会知道、也不会关心数据是存储在SQL Server还是Oracle数据库中或者别的什么地方。 4、 WEB层框架Struts Struts是一个在JSP Model2根底上实现的MVC框架，其主要的设计理念是通过控制器将表现逻辑和业务逻辑解耦，以提高系统的可维护性、可扩展性及可重用性。Struts框架的体系构造如下列图所示: 下面就上图所示的体系构造图分析Struts框架中的MVC组件。 , 视图(view):视图局部主要由JSP页面组成，其中没有流程逻辑、业务逻辑和模型信息，只有标记。Struts自身包含了一组标记库(TagLib)，这也是Struts的精华之一，灵活运用它们可以简化J

19、SP页面的代码，提高开发效率。 , 控制器(controller):Struts中的Controller主要是其自身提供的ActionServlet。ActionServlet接收所有来自客户端的请求并根据配置文件(struts-config.*ml)中的定义将控制转移到适当的Action对象。 , 模型(model):Struts没有定义具体Model层的实现，Model层通常是和业务逻辑严密相关的，有持续化的要求。目前在商业领域和开源世界，都有一些优秀的工具可以为Model层的开发提供便利。 、业务逻辑层框架Spring 5Spring是一个解决了许多JavaEE开发中常见问题并能够替代E

20、技术的强大的轻量级框架。这里所说的轻量级指的是Spring框架本身，而不是指Spring只能用于轻量级的应用开发。Spring的轻盈表达在其框架本身的根底构造以及对其他应用工具的支持和装配能力。与E这种庞然大物相比，Spring可使程序研发人员把各个技术层次之间的风险降低。 Spring框架的核心是控制翻转IoC(Inversion of Control)/依赖注入DI(Dependence Injection)机制。IoC是指由容器中控制组件之间的关系(这里，容器是指为组件提供特定效劳和技术支持的一个标准化的运行时的环境)而非传统实现中由程序代码直接操控，这种将控制权由程序代码到外部容器的转

21、移，称为翻转。DI是对IoC更形象的解释，即由容器在运行期间动态地将依赖关系(如构造参数、构造对象或接口)注入到组件之中。Spring采用设值注入(使用Setter方法实现依赖)和构造子注入(在构造方法中实现依赖)的机制，通过配置文件管理组建的协作对象，创立可以构造组件的IoC容器。这样，不需要编写工厂模式、单例模式或者其他构造的方法，就可以通过容器直接获取所需的业务组件。Spring框架的构造如下列图所示。 Spring框架由七个定义明确的模块组成，且每个模块或组件都可以单独存在，或者与其他一个或多个模块联合实现。Spring Core Container是一个用来管理业务组件的IoC容器，

22、是Spring应用的核心;Spring DAO和Spring ORM不仅提供数据访问的抽象模块，还集成了对Hibernate、JDO和iBatis等流行的对象关系映射框架的支持模块，并且提供了缓冲连接池、事务处理等重要的效劳功能，保证了系统的性能和数据的完整性;Sprnig Web模块提供了Web应用的一些抽象封装，可以将Struts、Webwork等Web框架与Spring整合成为适用于自己的解决方案。 Spring框架可以成为企业级应用程序一站式的解决方案，同时它也是模块化的框架，允许开发人员自由地挑选适合自己应用的模块进展开发。Spring框架式是一个松耦合的框架，框架的局部耦合度被设计

23、为最小，在各个层次上具体选用哪个框架取决于开发者的需要。 6、持久层框架Hibernate O/R mapping技术是为了解决关系型数据库和面向对象的程序设计之间不匹配的矛盾而产生的。Hibernate是目前最为流行的O/R mapping框架，它也是开源软件,它在关系型数据库和Java对象之间做了一个自动映射，使得程序员可以以非常简单的方式实现对数据库的操作，它不仅负责从Java类到数据库表格(以及来自Java数据类型的SQL数据类型)的映射,而且还提供数据查询和检索能力，并能大大减少花在SQL和JDBC手工数据处理上的开发时间。Hibernate工作原理如下列图所示: Hibernate

24、通过对JDBC的封装，向程序员屏蔽了底层的数据库操作，使程序员专注于OO程序的开发，有助于提高开发效率。程序员访问数据库所需要做的就是为持久化对象编制*ml映射文件。 底层数据库的改变只需要简单地更改初始化配置文件(hibernate.cfg.*ml或者perties)即可，不会对应用程序产生影响。 Hibernate有自己的面向对象的查询语言HQL，HQL功能强大，支持目前大局部主流的数据库，如Oracle、DB2、MySQL、Microsoft SQL Server等，是目前应用最广泛的O/R映射工具。Hibernate为快速开发应用程序提供了底层的支持。 (二)

25、、基于SSH框架的Web应用架构分析与设计 前面分析了基于JavaEE的SSH框架技术，现代的企业开发中，越来越多地引入了多层架构设计模式。SSH就是其中之一，SSH架构是当前主流的架构，在很多领域，包括金融、电信工程，大型门户均选择该架构作为业务支撑架构，开发流程也已经非常成熟。但是该构造开发起来，依旧存在一些问题。分析这些问题，得先从SSH架构的组成说起。 SSH为Struts+Spring+Hibernate的组成方式，Struts实现MVC，Spring负责架构的结合，Hibernate进展数据的持久化。通常其分层开发的构造图如下: 这样的构造，系统从职责上分为四层:WEB层、业务逻辑

26、层、数据持久层和实体层。其中使用Struts作为系统的整体根底架构，负责MVC的别离，在Struts框架的模型局部，利用Hibernate框架对持久层提供支持，业务层用Spring支持。具体做法是:用面向对象的分析方法根据需求提出一些模型，将这些模型实现为根本的Java对象，然后编写根本的DAO接口，并给出Hibernate的DAO实现，采用Hibernate架构实现的DAO类来实现Java类与数据库之间的转换和访问，最后由Spring完成业务逻辑。 系统的根本业务流程是:在WEB表示层中，首先通过JSP页面实现交互界面，负责传送请求(Request)和接收响应(Response)，然后Str

27、uts根据配置文件(struts-config.*ml)将ActionServlet接收到的Request委派给相应的Action处理。在业务层中，管理效劳组件的Spring IoC容器负责向Action提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完成业务逻辑，并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。而在持久层中，则依赖于Hibernate的对象化映射和数据库交互，处理DAO组件请求的数据，并返回处理结果。 采用上述开发模型，不仅实现了视图、控制器与模型的彻底别离，而且还实现了业务逻辑层与持久层的别离。这样无论前端如何变化，模型层只需很少的改

28、动，并且数据库的变化也不会对前端有所影响，大大提高了系统的可复用性。而且由于不同层之间耦合度小，有利于团队成员并行工作，大大提高了开发效率。 但是对于当前日益复杂化的WEB2.0的开发，却存在不少问题，归纳起来主要有以下的缺乏: , DAO和效劳层容易出现职责不明，由于按照MVC逻辑，业务代码应该写在Struts Action里，但是其事务的提供，却是配置在Service层。为了一组在逻辑上完整的数据操作业务逻辑，需要涉及两个层(Service、Action)来进展编写，遇到判断的情况下，为了保证完整的事务操作，则需要将业务代码移到Service层完成，而通常习惯了在Struts Action

29、里调用屡次Service而产生多个事务,但在出现E*ception导致出错时,操作之前调用的Service事务的业务数据没有被回滚。 , 当需要返回的数据供AJA*使用，操作JSON或*ML的大量使用时。开发起来会很费力，一段同样的业务代码，为了使用AJA*和*ML可能需要重新编写一次，或者在同一个ACTION里通过标志来判断，对分层构造造成了比拟糟糕的破坏。如果设计得不好，为了使用JSON和*ML还得额外增加大量的配置，严重降低了开发效率。 因此，为了克制这些缺点，对于SSH架构，进展了重新的分层，共享了业务代码。简化了开发、增强了与AJA*技术、*ML技术的结合。提供了一种更高效的开发模式

30、。 其开发的构造图如下: 这个架构的优点在于，由于业务代码统一实现BusinessService接口，使得只需要相对固定的几个Struts Action类调用Service层的方法，便可以完成工作。包括JSON格式输出，*ML输出及WebService输出均调用Service层方法来完成功能。这样便实现了业务代码的别离，以及与前端框架的极大解耦。 二、技术解决方案 开发一款好的软件产品，离不开一个好的开发过程。开发期间对过程的把控程度，往往会决定软件产品的质量好坏。因此，开发前期的方案流程是必不可少的。 本公司软件系统的开发是按阶段进展的，一般划分为以下阶段:项 目 可行性分析 可行性研究报告

31、 需求分析 软件需求说明书 概要设计 概要设计说明书 详细设计 数据库设计说明书 编码 详细设计说明书 测试 测试方案 修改完善 测试分析报告 验收 验收报告 维护 用户操作手册 1、可行性分析 可行性分析的目的是明确系统的目的、功能和要求，了解目前所具备的开发环境和条件，分析的容有: 在技术能力上是否可以支持 在经济上效益如何 在法律上是否符合要求 与部门、企业的经营和开展是否吻合 系统投入运行后的维护有无保障 可行性讨论的目的是判定软件系统的开发有无价值，分析和讨论的容形成系统开发方案书，主要容有: (1) 开发的目的及所期待的效果 (2) 系统的根本设想，涉及的业务对象和围 (3) 开发

32、进度表，开发组织构造 (4) 开发、运行的费用 (5) 预期的系统效益 (6) 开发过程中可能遇到的问题及考前须知。 2、需求分析 需求分析是软件系统开发中最重要的一个阶段，直接决定着系统的开发质量和成败。因此必须要明确用户的要求和应用现场环境的特点，了解系统应具有哪些功能、数据的流程和数据之间的联系。 需求分析应有用户参加，到使用现场进展调研学习，软件设计人员应虚心向技术人员和使用人员请教，共同讨论解决需求问题的方法，对调查结果进展分析，明确问题的所在。 需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审。 (一)、问题识别 从系统角度来理解软件,确定对所开发系统

33、的综合要求,并提出这些需求的实现条件,以及需求应该到达的标准。这些需求包括:功能需求(做什么),性能需求(要到达什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率),平安需求,用户界面需求,资源使用需求(软件运行是所需的存,CPU等),软件本钱消耗与开发进度需求,预先估计以后系统可能到达的目标。 (二)、分析与综合 逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理局部,增加需要局部。最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型)。 (三)、制订规格说明书 即编制文档,描述需求的文档称为软件

34、需求规格说明书。 (四)、评审 对功能的正确性,完整性和清晰性,以及其它需求给予评价。评审通过才可进展下一阶段的工作,否则重新进展需求分析。 需求分析的容最终会编写成系统需求分析报告。 3.系统设计 (一)、设计原则和设计要求 描述对本软件系统进展概要设计的原则，通常可以考虑以下几方面的容: 1、命名规则; 2、模块独立性原则; 3、边界设计原则; 4、数据库设计规则; 5、必须的平安措施; 6、平安性和原则; 7、系统灵活性要求; 8、系统易操作性要求; 9、系统可维护性要求; (二)、系统逻辑设计 系统逻辑设计主要是根据软件产品需求规格说明书和软件产品数据字典建立系统的逻辑模型。此种模型暂

35、时与系统的物理因素(例如:计算机、数据库管理系统)无关。它是系统需求与物理实现的中间构造，它的主要结果是建立:系统构造图、系统界面构造图、系统出错处理、以及系统开发技术说明。 (三)、系统组织设计 系统组织设计通过系统组织表描述本系统由哪些子系统(模块)组成，这些子系统与业务职能之间的关系，以及各个子系统的安装地点。系统组织表的格式如下: 子系统 英文名称 中文名称 业务职能 安装地点 备注 其中: 1、子系统 给出本系统中指定子系统的顺序。如果本系统末划分为多个子系统，仅由一个运行模块组成;则本项容仍需要描述，但是本表容只有一行。 在一个系统中有可能安装假设干个一样的子系统，在这种情况下，应

36、该视为一个子系统，并且对多个安装地点分别进展描述。如果一样的子系统通过系统设置，实现的业务职能具有明显差异时，应该采用多行进展分别描述，并且在备注中说明其差异所在。 2、子系统英文名称 给出本子系统的英文名称，该名称是在应用软件中实际使用的可执行文件名称，必须能够说明该子系统的特点。 假设本系统中只有一个子系统，则本项容仍需要描述，但是本表容只有一行。 3、子系统中文名称 给出本子系统的中文名称，该名称必须能够说明该子系统的特点。 假设本系统中只有一个子系统，则本项容仍需要描述，但是本表容只有一行。 4、业务职能 描述该子系统完成的核心业务。 5、安装地点 描述该子系统实际安装的部门、或者*个

37、具体地点。 6、备注 针对该子系统，需要说明的其它有关问题。 (四)、系统构造设计 1、系统特性表 系统特性是系统中完成*项具体操作的根本单元，它由入口参数，出口参数以及处理过程三局部组成。系统特性可以具有操作界面，也可以没有操作界面;可以被其它操作界面、或者系统特性调用，也可以调用其它操作界面、非操作界面、或者系统特性;但是不允许递归调用(调用自己)，包括间接递归调用。 当系统由多个子系统(模块)组成时，每个子系统分别使用一系统特性表进展描述。系统特性表的格式如下: 子系统: 子系统英文名称: 子系统中文名称: 特性 系统特征 系统特征 操作功能 调用对象 被调用对象 备注 英文名称 中文名

38、称 说明: 其中: (1)、子系统 含义同上。 (2)、子系统英文名称 含义同上。 (3)、子系统中文名称 含义同上。 (4)、特性 整个系统所有特性的统一。 (5)、系统特性英文名称 系统特性的英文正式名称，将来用于软件开发中，必须符合命名规。 (6)、系统特性中文名称 系统特性的中文正式名称，来源于需求规格说明书中，系统特性一节中的有关描述。 (7)、操作功能 是指该特性实际完成的操作说明。 (8)、调用对象 是指调用该系统特性的系统对象，这里的系统对象可以是系统特性、也可以是操作界面。 (9)、被调用对象 是指被该系统特性调用的系统对象，这里的系统对象可以是系统特性、也可以是操作界面。

39、(10)、备注 描述与该系统特性有关的其它考前须知。 (11)、说明 描述与该系统特性表有关的其它考前须知。 (五)、系统接口设计 1、系统接口表 接口作为系统的一种输入,输出形式，分为网络接口、数据库接口、RS-232串行通485串行总线接口、并行I/O接口等等多种类型。 讯接口、IEEE当系统由多个子系统(模块)组成时，每个子系统分别使用一系统接口表进展描述。系统接口表的格式如下: 子系统 子系统英文名称 子系统中文名称 接口 接口名称 接口类型 接口性质 接口速率 接口协议 备注 说明: 其中: (1)、子系统 含义同上。 (2)、子系统英文名称 含义同上。 (3)、子系统中文名称 含义

40、同上。 (4)、接口 整个系统所有接口的统一。 (5)、接口名称 系统接口的正式名称，必须符合通常习惯。 (6)、接口类型 指出该接口所传输的数据在该模块中起到的作用。 (7)、接口性质 指出该接口在通讯中起到的作用，这里的作用可以是:输入、输出、双向。 (8)、接口速率 指出该接口的传输速率。如果该接口依赖于其它通讯方式，则传输速率将不高于它所依赖的其它通讯方式的速率。 (9)、接口协议 给出该接口实际使用的通讯协议。 10)、相关对象 (给出直接使用本接口的系统对象，这里的系统对象，可以是操作界面，也可以是系统特性。 (11)、备注 描述与该系统接口有关的其它考前须知。 (12)、说明 描

41、述与该系统接口表有关的其它考前须知。 (六)、系统完整性设计 描述系统对象(数据元、数据类)，所受到的逻辑约束关系。 当系统由多个子系统(模块)组成时，每个子系统应分别使用一系统完整性约束表进展描述。系统完整性约束表的格式如下: 子系统 子系统英文名称 子系统中文名称 约束 完整性名称 相对对象名 约束表达式 备注 说明: 其中: (1)、子系统 含义同上。 (2)、子系统英文名称 含义同上。 (3)、子系统中文名称 含义同上。 (4)、约束 整个系统所有约束的统一。 (5)、完整性名称 系统完整性约束的正式名称，必须符合通常习惯。 6)、相对对象名 (完整性约束中的相关对象(数据元和数据类)

42、。 7)、约束表达式 (用一阶逻辑表达式表达的约束方程式。 (8)、备注 描述与该系统完整性约束有关的其它考前须知。 (9)、说明 描述与该系统完整性约束表有关的其它考前须知。 系统设计具体可根据系统的规模分成概要设计和详细设计两个阶段，概要设计包括: 划分系统模块 每个模块的功能确定 用户使用界面概要设计 输入输出数据的概要设计 报表概要设计 数据之间的联系、流程分析 文件和数据库表的逻辑设计 硬件、软件开发平台确实定 有规律数据的规化及数据惟一性要求。 系统的详细设计是对系统的概要设计进一步具体化，其主要工作有: 文件和数据库的物理设计 输入输出记录的方案设计 对各子系统的处理方式和处理容

43、进展细化设计 编制程序设计任务书。 程序说明书通常包括程序规、功能说明、程序构造图，通常用HPIPO(Hierarchy Plus Input Process Output)图描述。 4、编码 根据程序设计任务书的要求，用计算机算法语言实现解题的步骤，主要工作包括: 模块的理解和进一步划分 以模块为单位的逻辑设计，也就是模块的流程图的编制 编写代码，用程序设计语言编制程序 进展模块功能的测试、单元测试。 程序质量的要求包括: 满足要求确实切功能 处理效率高 操作方便，用户界面友好 程序代码的可读性好，函数、变量标识符合规 扩大性、维护性好。 降低程序的复杂性也是十分重要的，系统的复杂性由模块间

44、的接口数来衡量，一般地讲，n 个模块的接口数的最大值为n(n-1)/2;假设是层次构造，n 个模块的接口数的最小值为n-1。为使复杂性最小，对模块的划分设计常常采用层次构造。 要注意编制的程序或模块应容易理解、容易修改，模块应相互独立，对*一模块的修改应对其他模块的功能不产生影响，模块间的联系尽可能少。 5.系统测试 测试是为了发现程序中的错误，对于设计的软件，出现错误是难免的。系统测试通常由经历丰富的设计人员设计测试方案和测试样品，并写出测试过程的详细报告。系统测试是在单元测试的根底上进展的，包括: 测试方案的设计; 进展测试; 写出测试报告; 用户对测试结果进展评价。 具体测试方式如下:

45、1. 黑盒测试 黑盒测试也称为功能测试,它着眼于程序的外部特征,而不考虑程序的部逻辑构造。测试者把被测程序看成一个黑盒,不用关心程序的部构造。黑盒测试是在程序接口处进展测试，它只检查程序功能是否能正常使用，程序是否能接收输入数据产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试是基于用户角度进展的测试。 2. 白盒测试 本公司系统软件测试的主要方法之一，也称构造测试、逻辑驱动测试或基于程序本身的测试。测试者需要了解待测试程序代码的部构造、算法等信息，这是从程序设计者的角度对程序进展的测试。它的优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

46、3. 灰盒测试 可以理解为静态的白盒测试或动态的黑盒测试，灰盒就是界于黑白之间, 对软件部有所了解, 但不见得到了如指掌的程度, 却可以结合这些了解做些比黑盒多点的测试。 4. 文档测试 文档测试涵盖面很大，在软件的各个版本中均有所使用。随着软件版本的变化，文档测试的测试容也有所变化。在需求分析以及原型架构阶段，文档测试主要目标是: Sitemap、动作分解列表、数据库ER图、UML用例图、流程图、需求文档等文档。 文档测试主要检查文档的正确性、完整性和可理解性。正确性是指不要把软件的功能和操作写错，也不允许文档容前后矛盾。完整性是指文档不可以漏掉关键性容。可理解性是指在文档中描述的语言要简明

47、易懂，不能让别的开发人员拿到文档时看不懂文档的容。 5. 命名规测试 命名规测试用于测试工程中的文件命名、代码以及版本号等书写是否符合规。 6. 需求完整性测试 需求完整性测试主要存在于需求探索阶段，在需求尚未完全明确之前对已收集到的需求做出整理性的、检查遗漏性的测试，确认需否明确。另外，需求完整性测试也承当着一局部澄清需求的任务。 7. 完整性测试 在原型架构阶段，完整性的测试是非常有必要的。该项测试任务主要是检查假页面中各种是否完整，是否指向目标位置，属于检查性的测试。 8. 页面完整性测试 页面完整性测试主要存在于集成测试阶段以及其后续其它阶段中，测试页面是否完整，页面质量是否达标，属于

48、检查性测试。 9. UI合理性测试 UI合理性测试也就是人机交互界面的合理性，UI合理性测试的容很多，具体测试容如下: o 提示、菜单、帮助的格式是否一致; o 提示、菜单、帮助中的术语是否一致; o 各个控件之间的对齐方式是否一致; o 输入界面和输出界面在外观、布局、交互方式上是否一致; o 功能类似的相关界面在外观、布局、交互方式上是否一致; o 同一层次的文字在同一种提示场合(一般情况、特殊字体、警告等)在文字大小、字体、颜色、对齐方式方面是否一致，字体大小 是否与界面的大小比例协调; o 多个连续界面依次出现的情况下，界面的外观、操作方式是否一致; o 系统是否拒绝客户的错误输入并做

49、出提示; o 系统是否在用户完成操作时给出操作成功的提示; o 用户界面是否存在空白空间，没有空白空间的界面是杂乱无章的，易用性差; o 各个控件的间隔是否一致，垂直和水平方向上是否对齐; o 是否允许动作的可逆性，返回原有操做; 10. 数据和数据库完整性测试 在开发阶段开发人员随时都有可能根据需要来修改数据库，所以对数据和数据库完整性测试在软件工程的任何阶段也是非常必要的。该项测试容主要是以数据库表为单位，检查数据库表以及表中各字段命名是否符合命名规，表中字段是否完整，数据库表中的字段描述是否正确包括字段的类型、长度、是否为空，数据库表中的关系、索引、主键、约束是否正确。 11. 功能测试

50、 功能测试在软件工程的任何阶段中都是重要的。实现功能，满足客户需软件本身最大的使命。功能测试在任何阶段下根本上都作为测试工作的第一项出现。该项测试任务主要为了测试已实现的功能是否满足需求，是否正确，是否有价值以及是否完整。在黑盒和白盒测试状态下，该测试均会被使用。 功能测试中测试人员往往会忽略掉一些细节问题，比方:一个功能的实现必须要经过6步操作才能完成，而且需要参加20条信息才能看得出测试结果，有的测试人员为了节省时间虽然做完了6步操作，但是没有参加足量的信息,使得测试不全面,正是因为这样而导致一些隐藏的BUG没有被测试出来。所以说在功能测试中要按部就班的把所有要进展的测试功能每一步都执行一

51、遍，应该添加的数据都添加完整，以防止遗漏掉BUG没有测试出来。 12. 压力测试 压力测试是为了发现在什么条件下您的应用程序的性能会变得不可承受。这通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的。这种操作也称为负载测试，但是负载测试通常描述一种特定类型的压力测试增加用户数量以对应用程序进展压力测试。 对应用程序进展压力测试最简单的方法是手工改变输入(客户机数量、需求大小、请求的频率、请求的混合程度等等)并描绘性能的变化。但是如果有许多输入，或者需要在大的围改变输入，则你可以借助一个自动化的压力测试工具来完成此测试。 13. 平安性测试 平安性测试

52、主要是测试系统在没有授权的部或者外部用户对系统进展攻击或者恶意破坏时如何进展处理，是否仍能保证数据和页面的平安。测试人员可以学习一些黑客技术，来对系统进展攻击。 另外，对操作权限的测试也包含在平安性测试中。具体测试容如下: o 执行添加、删除、修改等动作中是否做过登录检测。 o 退出系统之后的操作是否可以完成。 o 所有插入表单操作中输入特殊字符是否可以正常输正常存储，特殊字符为:#,%*()-+=、|;:,/，。 o 在带有参数的回显数据的动作中更改参数，把参数改为特殊字符并参加操作语句看是否出错。 o 测试表单中有没有做标签检测，标签检测是否完整。 o 在插入表单中参加特殊的HTML代码，

53、例如:表单中的字本是否移动,。 14. 页面脚本测试 页面中时常使用到JavaScript脚本，为了降低页面的出错率，则必须对页面脚本进展测试。其主要容包括:相关页面中的脚本是否正常运行，JavaScript脚本是否有错误页面。 15. 提示文本测试 提示文本测试从严格意义上来讲应该属于UI合理性测试的一局部，该项测试主要针对各个页面中使用到的大量提示文档进展测试，主要包括:表达不明确的位置是否有提示文本、提示文本的弹出是否正常、提示信息含义是否明确易懂。 16. 浏览器测试 由于B/S构造工程是基于浏览器运行的，所以需要对浏览器进展必要的测试。该测试任务主要是软件对各种浏览器(IE5.5、I

54、E6.0、 FireFo*浏览器 )的支持是否正常，在IE浏览器中可以正常显示的页面在其它浏览器中是否可以正常显示。 17. 安装测试 在软件工程的后期阶段，会对做好的软件进展打包把软件做成安装程序，以便用户可以正确的安装使用，所以需要对做好的安装文件进展安装功能方面的测试。该测试的主要任务是:检查软件是否能够正常安装使用、是否可以完全卸载此软件的所有功能和页面。 6、文档资料 文档包括开发过程中的所有技术资料以及用户所需的文档，软件系统的文档一般可分为系统文档和用户文档两类。 用户文档主要描述系统功能和使用方法，并不考虑这些功能是怎样实现的，系统文档描述系统设计、实现和测试等方面的容。文档是

55、影响软件可维护性、可用性的决定因素，有句话讲，系统编程人员的每一纸片都要保存，所以文档的编制是软件开发过程中的一项重要工作。系统文档包括: 开发软件系统在方案 需求分析 设计 编制 调试 运行等阶段的有关文档。 在对软件系统进展修改时，系统文档应同步更新，并注明修改者和修改日期，如有必要应注明修改原因，应切记过时的文档是无用的文档。 用户文档包括: 系统功能描述 安装文档，说明系统安装步骤以及系统的硬件配置方法 用户使用手册，说明使用软件系统方法和要求，疑难问题解答 参考手册，描述可以使用的所有系统设施，解释系统出错信息的含义及解决途径。 7、系统的运行与维护 系统只有投入运行后，才能进一步对

56、系统检验，发现潜在的问题，为了适应环境的变化和用户要求的改变，可能会对系统的功能、使用界面进展修改。要对每次发现的问题和修改容建立系统维护文档，并使系统文档资料同步更新。 12.4.4 效劳保证措施 本公司软件质量保证由各项任务构成，这些任务的参与者有两种人:软件开发人员和质量保证人员。前者负责技术工作，后者负责质量保证的方案、监视、记录、分析及报告工作。软件开发人员通过采用可靠的技术方法和措施，进展正式的技术评审，执行方案周密的软件测试来保证软件产品的质量。软件质量保证人员则辅助软件开发组得到高质量的最终产品。 我们的软件质量保证方案大体分为如下三大局部: 把软件研制合理地划分为假设干阶段，

57、并针对每个阶段的特点,制定出质量评审、评测的要求和措施。 从软件质量的要求出发,制定出相应的技术和管理规，如软件文档规、软件编程规、软件测试规、软件版本控制规等。 创立和积累公用模块，向软件工厂化方向开展。 1、软件研制的阶段划分及其质量控制 我们把软件系统的研制划分为8个阶段，即总体需求分析、总体设计、各分系统的需求说明及概要设计、详细设计(面向子系统)、程序编制、自测试、组装与验收测试、试用和初步定型。 我们规定，总体需求分析及总体设计需经有关领导及管理专家评审认定。分系统的需求说明、概要设计及详细设计需经总工程师组织的技术评审组评审。评审前，多数分系统的需求说明及概要设计需经有代表性的用

58、户审核认可，即分析和设计阶段主要靠评审把关，编程和实施阶段主要靠执行规和测试把关。每次评审的结果都有相应的记录，并填写相应的表格。 2、软件的文档规 系统开发的文档要:每个分系统必须有需求说明、概要设计，每个子系统必须有详细设计和操作使用说明。需求说明、概要设计和详细设计必须串行完成，而且规定，详细设计未经评审通过不能进入正规编程。不写设计就进入编程，这是软件开发人员常犯的毛病，在我们的系统开发中这是不允许的。 3、软件编程规 开发中所有设计文件经过认真的评审、推敲和认定后，软件编程将是保证软件质量的一个重要环节。为保证这一环节的质量，我们专门制定了编程的有关规。其中最主要的是界面规。 需要强

59、调的是，对界面的理解不应只限于屏幕格式和操作方法，界面设计应贯穿于软件编制的全过程，我们的界面规分为两大局部: 第一局部是设计原则，包括:一般原则、屏幕格式设计原则、输入过程设计原则、信息显示设计原则、提示信息设计原则、报表设计原则、菜单设计原则、操作方法原则。它重点解决操作的方便性和直接性、显示和提示确实定性、输入的准确性、输入输出的一致性，以保证对用户习惯和心理的良好适应性，给用户一种愉快感，让用户产生一种喜爱感。 第二局部是屏幕格式设计，包括:屏幕、登录屏幕、单记录录入窗口、多记录录入窗口、查询列表窗口、 主/细数据录入窗口、命令按钮格式。它的主要目标是，力求使屏幕格式简炼、实用、直观、

60、醒目、风格一致，使操作使用方便。 软件编程规更是一种设计和编程经历的总结，是对所用开发工具的深入认识和全面理解。这一规本身的质量直接关系到全系统的编程效率和可移植性、软件的可扩展性及可维护性、数据的可恢复性和系统的可靠性。特别是在客户/效劳器模式下工作的系统，编程时对处理和数据的合理分布将直接影响到系统资源利用得是否充分、恰当，直接影响到整个系统的性价比。 它包括:对象和控制命名规、编程风格、数据校验、环境配置与应用的可移植性、事件驱动、面向对象、数据库访问规、数据及处理分布、出错处理、安装及设置。实践证明，这一规对保证程序质量、提高软件重用度,进而对提高编程效率、乃至提高系统的可靠性均起了重