软件项目招标文件技术标书最全最详细Word格式.docx

上传人:b****1 文档编号:3639083 上传时间:2023-05-02 格式:DOCX 页数:38 大小:71.21KB
下载 相关 举报
软件项目招标文件技术标书最全最详细Word格式.docx_第1页
第1页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第2页
第2页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第3页
第3页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第4页
第4页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第5页
第5页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第6页
第6页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第7页
第7页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第8页
第8页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第9页
第9页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第10页
第10页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第11页
第11页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第12页
第12页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第13页
第13页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第14页
第14页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第15页
第15页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第16页
第16页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第17页
第17页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第18页
第18页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第19页
第19页 / 共38页
软件项目招标文件技术标书最全最详细Word格式.docx_第20页
第20页 / 共38页
亲,该文档总共38页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

软件项目招标文件技术标书最全最详细Word格式.docx

《软件项目招标文件技术标书最全最详细Word格式.docx》由会员分享,可在线阅读,更多相关《软件项目招标文件技术标书最全最详细Word格式.docx(38页珍藏版)》请在冰点文库上搜索。

软件项目招标文件技术标书最全最详细Word格式.docx

易理解性:

与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性

易学性:

与用户为学习软件应用所花的努力有关的软件属性

易操作性:

与用户为操作和运行控制所花努力有关的软件属性

4、效率:

与在规定的条件下,软件的性能水平与所使用资源量之间关系有关的一组属性,具体包括:

时间特性:

与软件执行其功能时响应和处理时间以及吞吐量有关的软件属性

资源特性:

与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性

5、可维护性:

与进行指定的修改所需的努力有关的一组属性,具体包括:

易分析性:

与为诊断缺陷或失效原因及为判定待修改的部分所需努力有关的软件属性

易改变性:

与进行修改,排除错误或适应环境变化所需努力有关的软件属性

稳定性:

与修改所造成的未预料结果的风险有关的软件属性

易测试性:

与确认已修改软件所需的努力有关的软件属性

6、可移植性:

与软件可从某一环境转移到另一环境的能力有关的一组属性,具体包括:

适应性:

与软件无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性

易安装性:

与在指定环境下安装软件所需努力有关的软件属性

遵循性:

使软件遵循与可移植性有关的标准或约定的软件属性

易替换性:

与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的软件属性

基于以上原则,根据项目的不同需求,我们将会考虑采用B/S和C/S两种模式开发。

1、B/S模式

B/S是Brower/Server的缩写,客户机上只要安装一个浏览器(Browser),如NetscapeNavigator或InternetExplorer,服务器安装Oracle、Sybase、Informix或SQLServer等数据库。

浏览器通过WebServer同数据库进行数据交互。

B/S模式较C/S模式:

C/S模式客户端需要安装专用的客户端软件。

首先涉及到安装的工作量,其次任何一台电脑出问题,如病毒、硬件损坏,都需要进行安装或维护。

特别是有很多分部的情况,不是工作量的问题,而是路程的问题。

还有,系统软件升级时,每一台客户机需要重新安装,其维护和升级成本非常高。

C/S模式对客户端的操作系统一般也会有限制,可能适应于Windows系列操作系统,而不适用于Linux、Unix等操作系统。

而B/S最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。

只要有一台能上网的电脑就能使用,客户端零维护。

系统的扩展非常容易,只要能上网,再由系统管理员分配一个用户名和密码,就可以使用了。

甚至可以在线申请,通过公司内部的安全认证(如CA证书)后,不需要人的参与,系统可以自动分配给用户一个账号进入系统,这在最大程度上满足了项目要求。

系统采用的是目前较流行的一种Web应用程序开源框架--Struts+Spring+Hibernate(SSH)。

  集成SSH框架的系统从职责上分为四层:

表示层、业务逻辑层、数据持久层和域模块层,以帮助开发人员在短期内搭建结构清晰、可复用性好、维护方便的Web应用程序。

其中使用Struts作为系统的整体基础架构,负责MVC的分离,在Struts框架的模型部分,利用Hibernate框架对持久层提供支持,业务层用Spring支持。

具体做法是:

用面向对象的分析方法根据需求提出一些模型,将这些模型实现为基本的Java对象,然后编写基本的DAO接口,并给出Hibernate的DAO实现,采用Hibernate架构实现的DAO类来实现Java类与数据库之间的转换和访问,最后由Spring完成业务逻辑。

  系统的基本业务流程是:

在表示层中,首先通过JSP页面实现交互界面,负责传送请求(Request)和接收响应(Response),然后Struts根据配置文件(struts-config.xml)将ActionServlet接收到的Request委派给相应的Action处理。

在业务层中,管理服务组件的SpringIoC容器负责向Action提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完成业务逻辑,并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。

而在持久层中,则依赖于Hibernate的对象化映射和数据库交互,处理DAO组件请求的数据,并返回处理结果。

采用上述开发模型,不仅实现了视图、控制器与模型的彻底分离,而且还实现了业务逻辑层与持久层的分离。

这样无论前端如何变化,模型层只需很少的改动,并且数据库的变化也不会对前端有所影响,大大提高了系统的可复用性。

而且由于不同层之间耦合度小,有利于团队成员并行工作,大大提高了开发效率的同时,也保证了软件产品的质量。

2、C/S模式

C/S(Client/Server,客户机/服务器)模式又称C/S结构,是20世纪80年代末逐步成长起来的一种模式,是软件系统体系结构的一种。

C/S结构的关键在于功能的分布,一些功能放在前端机(即客户机)上执行,另一些功能放在后端机(即服务器)上执行。

功能的分布在于减少计算机系统的各种瓶颈问题。

C/S模式简单地讲就是基于企业内部网络的应用系统。

与B/S(Browser/Server,浏览器/服务器)模式相比,C/S模式的应用系统最大的好处是不依赖企业外网环境,即无论企业是否能够上网,都不影响应用。

  C/S结构服务器通常采用高性能的PC、工作站或小型机,并采用大型数据库系统,如ORACLE、SYBASE、InfORMix或SQLServer。

客户端需要安装专用的客户端软件。

  C/S结构的优点是能充分发挥客户端PC的处理能力,很多工作可以在客户端处理后再提交给服务器,因此对应的优点就是客户端响应速度快。

C/S架构软件的优势与劣势:

  

(1)应用服务器运行数据负荷较轻。

最简单的C/S体系结构的数据库应用由两部分组成,即客户应用程序和数据库服务器程序。

二者可分别称为前台程序与后台程序。

运行数据库服务器程序的机器,也称为应用服务器。

一旦服务器程序被启动,就随时等待响应客户程序发来的请求;

客户应用程序运行在用户自己的电脑上,对应于数据库服务器,可称为客户电脑,当需要对数据库中的数据进行任何操作时,客户程序就自动地寻找服务器程序,并向其发出请求,服务器程序根据预定的规则作出应答,送回结果,应用服务器运行数据负荷较轻。

  

(2)数据的储存管理功能较为透明。

在数据库应用中,数据的储存管理功能,是由服务器程序和客户应用程序分别独立进行的,并且通常把那些不同的(不管是已知还是未知的)前台应用所不能违反的规则,在服务器程序中集中实现,例如访问者的权限,编号可以重复、必须有客户才能建立定单这样的规则。

所有这些,对于工作在前台程序上的最终用户,是“透明”的,他们无须过问(通常也无法干涉)背后的过程,就可以完成自己的一切工作。

在客户服务器架构的应用中,前台程序不是非常“瘦小”,麻烦的事情都交给了服务器和网络。

在C/S体系的下,数据库不能真正成为公共、专业化的仓库,它受到独立的专门管理。

  C/S模式系统的开发:

  C/S结构是建立在中间件产品基础之上的,要求应用开发者自己去处理事务管理、消息队列、数据的复制和同步、通信安全等系统级的问题。

这对应用开发者提出了较高的要求,而且迫使应用开发者投入很多精力来解决应用程序以外的问题。

这使得应用程序的维护、移植和互操作变得复杂。

如果客户端是在不同的操作系统上,C/S结构的软件需要开发不同版本的客户端软件。

但是,与B/S结构相比,C/S技术发展历史更为“悠久”。

从技术成熟度及软件设计、开发人员的掌握水平来看,C/S技术应是更成熟、更可靠的。

12.4.3项目总体架构及技术解决方案

一、项目总体架构

(一)、SSH框架介绍和分析

大型企业级Web应用系统的开发通常要求有一个良好的软件架构、便于协作开发和扩展升级,而传统的开发模式不能很好地满足这些要求。

基于当前Web应用程序开发面临的问题,项目结合目前比较流行的开源框架SSH(Spring、Struts、Hibernate),具体讨论其基本相似性及有关基本概念,提出了一种开发JavaEEWeb应用的轻量级解决方案,此系统架构可以在短期内搭建结构清晰、可复用性好、可扩展性好、维护方便的Web应用程序。

1、框架技术

框架一般具有即插即用的可重用性、成熟的稳定性以及良好的团队协作性。

JavaEE复杂的多层结构决定了大型的JavaEE项目需要运用框架和设计模式来控制软件质量。

目前,市场上出现了一些商业的、开源的基于JavaEE的应用框架,其中主流的框架技术有:

基于MVC模式的Struts框架、基于IoC模式的Spring框架以及对象/关系映射框架Hibernate等。

2、框架共同点

所有现代的网络开发框架几乎都遵循了模型-视图-控制(MVC)设计模式:

商业逻辑和描述被分开,由一个逻辑流控制器来协调来自客户端的请求和服务器上将采取的行动。

这条途径成为了网络开发的事实上的标准。

每个框架的内在的机制当然是不同的,但是开发者们使用来设计和实现他们的Web应用软件的API是很类似的。

差别还存在于每个框架提供的扩展方面,例如标签库,JavaBean包装器等。

  所有的框架使用不同的技术来协调在Web应用程序之内的导航,例如XML配制文件,java属性文件或定制属性。

所有的框架在控制器模块实现的方法方面也存在明显的不同。

例如,EJB可能实例化在每个请求中需要的类或使用Java反射动态地调用一个适当的行为(Action)类。

另外,不同框架在各自引入的概念上也有所不同。

例如,一个框架可能定义用户请求和反应场所,而另外一个框架可能仅仅定义一个完整的流:

从一个请求到多个响答和随后的再请求。

各种Java框架在它们组织数据流的方法方面是很类似的。

在请求发出后,在应用程序服务器上产生一些行动;

而作为响应,一些可能包含对象集的数据总是被发送到WEB层。

然后从那些对象:

可能是有setter和getter方法的简单类、JAVABEANS、值对象、或者一些集合对象中提取数据。

现代的Java框架还想方设法简化开发者的开发任务,如通过使用简易的API、数据库连接池、甚至数据库调用包等提供自动化的追踪方式来实现。

一些框架或者能够钩进(hookedinto)另外的JavaEE技术中,例如JMS(Java消息服务)或JMX,或把这些技术集成到一起。

服务器数据持续性和日志也有可能成为框架的一部分。

3、MVC模式

MVC模式是一个用于将用户界面逻辑与业务逻辑分离开来的基础设计模式,它将数据处理、界面以及用户的行为控制分为:

Model(模型)-View(视图)-Controller(控制器)。

Model:

负责当前应用的数据获取与变更及相关的业务逻辑。

可用JAVABEAN来体现;

View:

负责显示信息。

可以使用JSP、VELOCITY模板等技术;

Controller:

负责收集转化用户的输入。

常用一个SERVLET来实现;

View和Controller都依赖于Model,但是Model既不依赖于View,也不依赖于Controller,这是分离的主要优点之一,这样Model可以单独的建立和测试以便于代码复用,View和Controller只需要Model提供数据,它们不会知道、也不会关心数据是存储在SQLServer还是Oracle数据库中或者别的什么地方。

4、WEB层框架Struts

Struts是一个在JSPModel2基础上实现的MVC框架,其主要的设计理念是通过控制器将表现逻辑和业务逻辑解耦,以提高系统的可维护性、可扩展性及可重用性。

Struts框架的体系结构如下图所示:

下面就上图所示的体系结构图分析Struts框架中的MVC组件。

Ø

视图(view):

视图部分主要由JSP页面组成,其中没有流程逻辑、业务逻辑和模型信息,只有标记。

Struts自身包含了一组标记库(TagLib),这也是Struts的精华之一,灵活运用它们可以简化JSP页面的代码,提高开发效率。

控制器(controller):

Struts中的Controller主要是其自身提供的ActionServlet。

ActionServlet接收所有来自客户端的请求并根据配置文件(struts-config.xml)中的定义将控制转移到适当的Action对象。

模型(model):

Struts没有定义具体Model层的实现,Model层通常是和业务逻辑紧密相关的,有持续化的要求。

目前在商业领域和开源世界,都有一些优秀的工具可以为Model层的开发提供便利。

5、业务逻辑层框架Spring

Spring是一个解决了许多JavaEE开发中常见问题并能够替代EJB技术的强大的轻量级框架。

这里所说的轻量级指的是Spring框架本身,而不是指Spring只能用于轻量级的应用开发。

Spring的轻盈体现在其框架本身的基础结构以及对其他应用工具的支持和装配能力。

与EJB这种庞然大物相比,Spring可使程序研发人员把各个技术层次之间的风险降低。

Spring框架的核心是控制翻转IoC(InversionofControl)/依赖注入DI(DependenceInjection)机制。

IoC是指由容器中控制组件之间的关系(这里,容器是指为组件提供特定服务和技术支持的一个标准化的运行时的环境)而非传统实现中由程序代码直接操控,这种将控制权由程序代码到外部容器的转移,称为“翻转”。

DI是对IoC更形象的解释,即由容器在运行期间动态地将依赖关系(如构造参数、构造对象或接口)注入到组件之中。

Spring采用设值注入(使用Setter方法实现依赖)和构造子注入(在构造方法中实现依赖)的机制,通过配置文件管理组建的协作对象,创建可以构造组件的IoC容器。

这样,不需要编写工厂模式、单例模式或者其他构造的方法,就可以通过容器直接获取所需的业务组件。

Spring框架的结构如下图所示。

 Spring框架由七个定义明确的模块组成,且每个模块或组件都可以单独存在,或者与其他一个或多个模块联合实现。

SpringCoreContainer是一个用来管理业务组件的IoC容器,是Spring应用的核心;

SpringDAO和SpringORM不仅提供数据访问的抽象模块,还集成了对Hibernate、JDO和iBatis等流行的对象关系映射框架的支持模块,并且提供了缓冲连接池、事务处理等重要的服务功能,保证了系统的性能和数据的完整性;

SprnigWeb模块提供了Web应用的一些抽象封装,可以将Struts、Webwork等Web框架与Spring整合成为适用于自己的解决方案。

Spring框架可以成为企业级应用程序一站式的解决方案,同时它也是模块化的框架,允许开发人员自由地挑选适合自己应用的模块进行开发。

Spring框架式是一个松耦合的框架,框架的部分耦合度被设计为最小,在各个层次上具体选用哪个框架取决于开发者的需要。

6、持久层框架Hibernate

O/Rmapping技术是为了解决关系型数据库和面向对象的程序设计之间不匹配的矛盾而产生的。

Hibernate是目前最为流行的O/Rmapping框架,它也是开源软件,它在关系型数据库和Java对象之间做了一个自动映射,使得程序员可以以非常简单的方式实现对数据库的操作,它不仅负责从Java类到数据库表格(以及来自Java数据类型的SQL数据类型)的映射,而且还提供数据查询和检索能力,并能大大减少花在SQL和JDBC手工数据处理上的开发时间。

Hibernate工作原理如下图所示:

 Hibernate通过对JDBC的封装,向程序员屏蔽了底层的数据库操作,使程序员专注于OO程序的开发,有助于提高开发效率。

程序员访问数据库所需要做的就是为持久化对象编制xml映射文件。

底层数据库的改变只需要简单地更改初始化配置文件(,不会对应用程序产生影响。

Hibernate有自己的面向对象的查询语言HQL,HQL功能强大,支持目前大部分主流的数据库,如Oracle、DB2、MySQL、MicrosoftSQLServer等,是目前应用最广泛的O/R映射工具。

Hibernate为快速开发应用程序提供了底层的支持。

(二)、基于SSH框架的Web应用架构分析与设计

  

 

前面分析了基于JavaEE的SSH框架技术,现代的企业开发中,越来越多地引入了多层架构设计模式。

SSH就是其中之一,SSH架构是当前主流的架构,在很多领域,包括金融、电信项目,大型门户网站均选择该架构作为业务支撑架构,开发流程也已经非常成熟。

但是该结构开发起来,依旧存在一些问题。

分析这些问题,得先从SSH架构的组成说起。

SSH为Struts+Spring+Hibernate的组成方式,Struts实现MVC,Spring负责架构的结合,Hibernate进行数据的持久化。

通常其分层开发的结构图如下:

这样的结构,系统从职责上分为四层:

WEB层、业务逻辑层、数据持久层和实体层。

系统的基本业务流程是:

在WEB表示层中,首先通过JSP页面实现交互界面,负责传送请求(Request)和接收响应(Response),然后Struts根据配置文件(struts-config.xml)将ActionServlet接收到的Request委派给相应的Action处理。

  采用上述开发模型,不仅实现了视图、控制器与模型的彻底分离,而且还实现了业务逻辑层与持久层的分离。

而且由于不同层之间耦合度小,有利于团队成员并行工作,大大提高了开发效率。

但是对于当前日益复杂化的WEB2.0的开发,却存在不少问题,归纳起来主要有以下的不足:

DAO和服务层容易出现职责不明,由于按照MVC逻辑,业务代码应该写在StrutsAction里,但是其事务的提供,却是配置在Service层。

为了一组在逻辑上完整的数据操作业务逻辑,需要涉及两个层(Service、Action)来进行编写,遇到判断的情况下,为了保证完整的事务操作,则需要将业务代码移到Service层完成,而通常习惯了在StrutsAction里调用多次Service而产生多个事务,但在出现Exception导致出错时,操作之前调用的Service事务的业务数据没有被回滚。

当需要返回的数据供AJAX使用,操作JSON或XML的大量使用时。

开发起来会很费力,一段同样的业务代码,为了使用AJAX和XML可能需要重新编写一次,或者在同一个ACTION里通过标志来判断,对分层结构造成了比较糟糕的破坏。

如果设计得不好,为了使用JSON和XML还得额外增加大量的配置,严重降低了开发效率。

因此,为了克服这些缺点,对于SSH架构,进行了重新的分层,共享了业务代码。

简化了开发、增强了与AJAX技术、XML技术的结合。

提供了一种更高效的开发模式。

其开发的结构图如下:

这个架构的优点在于,由于业务代码统一实现BusinessService接口,使得只需要相对固定的几个StrutsAction类调用Service层的方法,便可以完成工作。

包括JSON格式输出,XML输出及WebService输出均调用Service层方法来完成功能。

这样便实现了业务代码的分离,以及与前端框架的极大解耦。

二、技术解决方案

开发一款好的软件产品,离不开一个好的开发过程。

开发期间对过程的把控程度,往往会决定软件产品的质量好坏。

因此,开发前期的计划流程是必不可少的。

本公司软件系统的开发是按阶段进行的,一般划分为以下阶段:

1、可行性分析

可行性分析的目的是明确系统的目的、功能和要求,了解目前所具备的开发环境和条件,分析的内容有:

①在技术能力上是否可以支持

②在经济上效益如何

③在法律上是否符合要求

④与部门、企业的经营和发展是否吻合

⑤系统投入运行后的维护有无保障

可行性讨论的目的是判定软件系统的开发有无价值,分析和讨论的内容形成“系统开发计划书”,主要内容有:

(1)开发的目的及所期待的效果

(2)系统的基本设想,涉及的业务对象和范围

(3)开发进度表,开发组织结构

(4)开发、运行的费用

(5)预期的系统效益

(6)开发过程中可能遇到的问题及注意事项。

2、需求分析

需求分析是软件系统开发中最重要的一个阶段,直接决定着系统的开发质量和成败。

因此必须要明确用户的要求和应用现场环境的特点,了解系统应具有哪些功能、数据的流程和数据之间的联系。

需求分析应有用户参加,到使用现场进行调研学习,软件设计人员应虚心向技术人员和使用人员请教,共同讨论解决需求问题的方法,对调查结果进行分析,明确问题的所在。

需求分析阶段的工作,可以分为四个方面:

问题识别,分析与综合,制订规格说明,评审。

(一)、问题识别

从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准。

这些需求包括:

功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率),安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标。

(二)、分析与综合

逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分。

最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型)。

(三)、制订规格说明书

即编制文档,描述需求的文档称为软件需求规格说明书。

(四)、评审

对功能的正确性,完整性和清晰性,以及其它需求给予

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 初中教育 > 语文

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2