东北可行性研究报告编制中心 编写各类研究咨询报告

软件开发过程实验报告

实验一 软件需求分析

一、目的和意义

对本书第二和三章的内容做进一步的掌握，写出软件需求规

格说明书。为下面的实习奠定基础。

二、实习内容

1、确定软件题目（学生可自己拟定，也可在本书附录2中选择）；

2、分析软件需求以及人工模式下的工作流程；

3、编写需求规格说明书（需求规格说明书的编写要求参见本节模板参考）；

4、完成形式：以文档的形式完成软件的需求规格说明书。纸张型号为A4。

三、实习指导

1、在磁盘上建立一个软件工程实习文件夹，以自己的姓名命名。

2、提交文档的格式如下：

第一页的格式为：

软件名称： 文档编号

文档名称：

项目名称：

项目负责人：

编写 时间

审核 时间

批准 时间

开发单位

第二页之后的内容为：

?

? 编写目的：阐明编写该文档的目的，指出读者对象 项目背景：项目的委托单位、开发单位、该软件系统与其他系统的关系。

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告

? 参考资料

软件需求规格说明的书写原则

①任务概述：软硬件环境、条件和限制（软件的使用条件和限制）。

②数据描述：输入数据、输出数据、数据库设计和建立数据词典。

③功能需求：功能划分和功能描述

④性能需求：数据精度、时间特性、适应性（操作方式、与其他软件的接口、开发计划变化时，软件应具有的适应能力。）。

⑤运行要求：用户界面、硬件接口（如：连接打印机）、软件接口（如：是否为其他项目的子项目）、故障处理。

⑥其他需求：可使用性、安全保密性、可维护性、可移植性等。

? 模板参考

第一页：

软件名称： 教务管理软件 文档编号 001

版本号

文档名称： 需求规格说明书

项目名称： 课表编排系统

项目负责人： 屈艳

编写： 刘楠、叶艺、赵春、马燕 时间： 2005-2-14

审核： 屈艳 时间： 2005-2-16

批准： 王湘桃 时间： 2005-2-20

开发单位： 冰雪五人组

第二页之后的内容：

编写目的：编写该文档是为了分析人工状态下课表编排的工作流程，把人工模式抽象为可在计算机上处理的自动模式。便于开发小组成员对系统整体功能的认识。

项目背景：高校的课表编排一直是一个烦琐的工作，为了解决这个问题，某某高校教务处委托我们开发该软件。该软件是高校教务软件的一个子系统。该子系统与专业规划子系统和教师管理软件有一定的关系。

参考资料：

1．郑人杰 实用软件工程（第二版）北京：清华大学出版社，1997

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告 任务概述：

硬件环境：CPU的型号为PentiumIII以上，内存256M ，及其兼容机

软件环境：Win98/2000/xp、VB/VC/VF/DeLphi 等。

软件的使用条件和限制：教室的数量能满足排课的需求；一个教师只能代两门课；修改课表有安全级别。

数据描述：

用户提供的资料：计划书和教师、教室情况

用户对软件的要求：输入计划书，系统自动按班级排课表，并可查询打印课表。

静态数据：教室信息（编号、名称、类型（普通/多媒体）、规模等）。

动态数据：计划书（课程名称，专业年级，人数，学时，讲课（周次），实验周次，教师姓名，对教室的要求等。）、教师信息（编号、姓名、学院、职称）

数据流图：

数据流图的图符含义为：圆圈表示加工，矩形框表示结果，箭头表示数据流向。

课表编排系统的数据流图如下：

计划书中的数据有：学生所在学院、专业年级、班级、人数、课程名称、总学时、周学时、周次、教师姓名、教室类型等信息。

教室数据有：教室编号、教室类型、教室的规模（60人/90人）、周一到周五各个时间段的使用情况等信息

一级课表数据有：专业年级、班级、周一至周五每天五个时间段（12节，34节，56节，78节，90节）、课程名称、教室编号、教师姓名、课程起始周次或间断的周次。

注：对计划书中的数据和教室数据的加工处理，形成一级课表所需要的数据。

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告

数据库描述及数据词典：

班级表banji

教室表jiaoshi

课程表kecheng

计划表jihua

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告

功能需求：

功能划分：基本信息输入模块、计划书信息输入模块、课表自动生成模块、备份删除数据模块。

功能描述：

基本信息输入模块的功能：建立良好的用户输入界面，输入基本信息（教师信息和教室信息）。

计划信息输入模块的功能：输入计划书中的信息。

课表自动生成模块的功能：根据输入的基本信息，自动生成一级课表。（具体算法在详细设计中查询）。

备份删除数据模块的功能：课表编排系统将在多学期使用，一个学期结束后，应备份数据，并将旧数据删除，产生新的课表数据。 性能需求：

数据精确度：整数

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告

时间特性：无特殊要求

适应性：有一定的适应能力，可将数据导入导出。

运行需求：

用户界面：简单

硬件接口：标准接口（打印机接口）

软件接口：无，该软件暂时独立使用。

故障处理：重新安装该软件。

其他需求：

可使用性：良好

安全保密性：有安全保密性。课表编排必须由教务管理人员进行，课表修改要设定权限。 可维护性：可以进行简单的维护，

可移植性：适用于各种操作系统。

实习二 软件详细设计

一、目的和意义

对本书第四章的内容做进一步的掌握，写出软件详细设计说

明书。为下面的实习奠定基础。

二、 实习内容

确定软件的总体结构，设计每个模块的细节。

①总体设计：画软件系统的结构图

②程序描述：每个模块给出以下说明

功能、性能、输入项目、输出项目、算法、限制条件、测试要点（模块的主要测试要求）。

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告

三、 实习指导

提交文档的格式如下：

第一页：

软件名称： 教务管理软件 文档编号 002

版本号 Ver 1.0

文档名称： 软件详细设计说明书

项目名称： 课表编排系统

项目负责人： 屈艳

编写： 叶艺、赵春、马燕、刘楠 时间： 2005-3-14

审核： 屈艳 时间： 2005-3-16

批准： 王湘桃 时间： 2005-3-20

开发单位： 冰雪五人组

第二页之后的内容：

编写目的：编写详细设计是为了上程序员在写程序时有一个依据。程序员根据详细设计写出符合设计要求的程序。

项目背景：详细设计的设计思路由教务管理科的管理人员提供，经过设计人员的加工处理，形成可在计算机上实现的算法。

参考资料：

1．郑人杰 实用软件工程（第二版）北京：清华大学出版社，1997

课表编排系统的总体结构图：

基本信息输入模块：

功能：完成基本信息的输入，并将信息保存在数据库中，供自动排课模块使用。基本信息有（教师信息，教室信息）。

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告

输入项：有9项，具体项目见测试用例列表。

输出项：有9项，同上。 算法：（可以用程序流程图或算法语言）见右上程序流程图 测试用例： 教师信息：

教室信息：

功能：完成计划书的信息输入，并保存在数据库中，供自动排课模块使用。 输入项：有9项，具体见测试用例。

输出项：有9项，同上。

算法：算法同基本信息输入模块。 测试用例：

功能：该模块根据计划书信息，完成各个班级的一级课表的编排。

输入项：从计划书信息库和教室信息库中获的信息。 输出项：班级的课表 算法：

DO1

在计划书数据库取一条信息（某个专业年级，班级）

DO2

在教室数据库取一个教室信息

if 教室类型满足 then

if 教室规模满足 then

if 教室空且时间合适 then

占用教室 exit DO2

endif

endif

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告 endif

LOOP UNTIL EOF(教室信息库)

LOOP UNTIL EOF(计划书)

注：如果某个计划书不能找到合适的教室，则该计划书转入手动排课。

测试用例：信息学院02级计算机1-3班的计划书为例。教室为信息学院的专业教室。

备份删除数据模块：（省略）

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告

实验三 原型软件设计

一、目的和意义

我们对系统进行一次分析，不可能很清楚的完成软件的需求规格说明书，我们通常是先对系统进行简单的需求分析之后，设计一个原型软件。原型软件是一个看起来像真软件，具有真软件的简单功能，但不具有真软件的强大的功能。客户通过使用原型软件可以很容易发现未来的软件包是否满足需要、或者还应作什么修改。对原型软件不断的修该，使它成为一个真正意义上的软件。

二、实习内容

1、题目：原型软件设计

2、要求：设计原型软件的界面和主要功能模块。

3、完成形式：进行简单的输入，软件可以运行。

三、实习指导

1、高级程序设计语言的选择

2、编写主界面程序代码（按照实验二的详细设计说明书进行代码编写）。

3、编写主要功能程序代码（按照实验二的详细设计说明书进行代码编写）。

4、对编写好的程序进行测试（使用实验二提供的测试用例测试程序）。

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告

实验四 软件测试用例设计和测试

一、目的和意义

对软件进行测试是为了得到安全可靠的软件产品。软件测试常用的方法有两个：白盒法和黑盒法。不论是白盒法还是黑盒法都不能完全找到软件的错误（bug），所以要设计软件的测试用例，希望尽可能多的发现软件中存在的错误。

二、实习内容

1、题目：对实习三设计的软件进行测试

2、要求：选择两个软件单元，一个用白盒法进行测试，一个用黑盒法进行测试。

3、完成形式：写出测试用例及测试结果。对测试结果进行分析，评价软件的可靠程度。

三、实习指导

1、对所选择的白盒法测试软件单元进行逻辑分析，画出逻辑流程图。

2、根据逻辑流程图设计测试用例。记录测试结果，并对测试结果进行分析。

3、确定黑盒法测试的软件单元。

4、设计黑盒法的测试用例。记录测试结果，并对测试结果进行分析。

提交文档的格式如下：

第一页：

软件名称： 教务管理软件 文档编号 003

版本号 Ver 1.0

文档名称： 测试用例的设计

项目名称： 课表编排系统

项目负责人： 屈艳

编写：赵春、马燕、刘楠、叶艺 时间： 2005-4-14

审核： 屈艳 时间： 2005-4-16

批准： 王湘桃 时间： 2005-4-20

开发单位： 冰雪五人组

第二页之后的内容：

编写目的：为了在测试软件的过程中思路清晰，测试的目标明确。该测试计划供测试人员使用。

要测试的程序模块名：教室信息输入模块和自动排课模块。

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告

测试用例1：

教室信息输入模块的测试用例：

No。

测试结果：数据库中的信息与用户输入的信息一致。 软件评价：该模块运行正确。 测试用例2：

自动排课模块的测试用例：

以信息学院计算机02级1-3班的计划书为例。运行自动排课模块。

书转入手动排课系统（即手工调整课表）。

测试结果：形成一张计算机02级1-3班的课表。

软件评价：基本完成设计要求。

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

东北可行性研究报告编制中心 编写各类研究咨询报告

实验五 软件提交与维护

一、目的和意义

软件开发成功后，将交付用户使用，在用户使用前，要对

用户进行培训。并要求写出详细的使用说明书和维护手册，待后续修改和维护。否则，软件的使用将受到限制，软件寿命将缩短，成本会增高。

二、实习内容

1、题目：对开发该软件的所有资料进行整理

2、要求：从软件需求分析规格说明书到使用说明书的所有资料进行收集和整理。

3、完成形式：将所有文档编辑成册。

三、实习指导

1、根据用户的要求写出软件的使用说明书

2、根据开发的限制条件，写出软件的维护手册

①系统说明：系统具备的功能，输入和输出。

②操作环境：系统的设备配置及其特性。列出系统使用的所有支持软件（名称和

版本号）。

③维护过程：约定（所有标识和助记符的使用规则）。列出出错状态和纠正方法。修改错误，并详细描述修改。

王工 133-1792-3626 公司电话：0451-5556-5030 133-1365-4030

 

第二篇：软件设计模式实验报告xx

应用4+1视图法及UML设计软件体系架构及设计模式实践

一 实验目的

通过对实际案例进行软件设计来掌握软件体系架构模式的选择应用以及典型4+1视图软件架构设计方法的应用，并能熟练掌握如何利用Rational Rose软件进行软件架构设计。

二 实验内容

(1) 根据“信用卡申请件处理外包业务处理平台设计”需求选定软件体系结构模式

(2) 利用UML软件进行4+1视图架构设计，包括逻辑视图、开发视图、进程视图、物理视图和场景视图。’

A 逻辑视图描述系统的功能需求，系统分解成一系列的功能抽象，采用时序图、协作图、类图等来表示；

B 开发视图描述软件在开发环境下的静态组织。开发视图关注程序包，应用的统一框架，引用的类库、SDK和中间件，以及工程和包的划分规则等，规范、约束开发环境的结构；

C 进程试图侧重系统的运行特性，关注非功能性的需求（性能，可用性）。服务于系统集成人员，方便后续性能测试。强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个进程和线程中被执行，可以组件图为基础表示；

D 物理试图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射；

E 场景用于刻画构件之间的相互关系，将四个视图有机地联系起来。

可以描述一个特定的视图内的构件关系，也可以描述不同视图间的

构件关系。通常用Use Case图来描述。

(3) 设计模式的实践，从创建者模式、结构型模式和行为模式三大类模式进

行对象设计，每种类型的模式至少应用一种，并用应用了设计模式后的类设计修订逻辑视图中的类图。

三 SOA架构模式及流程分析（湛滨瑜）

3.1 SOA架构介绍 SOA是英文Service-Oriented Architecture，即面向服务架构的缩写。

面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

SOA三大基本特征

1、独立的功能实体

在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。 SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主 (Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问 题的时候，在该宿主上运行的其它应用服务就会受到影响。

SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue) ，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

2、大数据量低频率访问

对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成 往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽 略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次 性进行信息交换。

3、基于文本的消息传递

由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中， 从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言， 不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处 理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。

3.2信用卡申请件外包处理流程分析

信用卡申请件外包处理的主要流程为：

第一阶段：

信用卡申请人准备个人档案资料并接件提交，将所有接受的档案文件通过拆件、然后再分类整理后，给申请人的档案资料帖上条形码标识。在影像处理过程中，通过电子扫描设备将档案条形码扫人，经过对档案文件的质量检测和影像的切分后将数据信息传输给外包中心做数据处理。

第二阶段：

外包中心接受到影像处理阶段传递的数据信息后，通过任务分配环节将传递过来的数据信息录入，两次录入完成后，进入一个重要的复核环节。如果复核匹配失败，则进入第三人复核阶段，如果第三人复核成功，在确保数据录入的准确无误后进入影像匹配阶段。如果第三人复核失败，则将问题交由专门的人员来处理解决。通过影像匹配环节将数据归档处理。供工作人员查询使用。同时将数据回传递给银行信用卡数据中心。

第三阶段：

银行信用卡数据中心，接受到数据，并保存。

四 4+1视图（张献忠）和设计模式（李金栓）

4.1 4+1视图介绍

软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。Perry 和 Wolfe 使用一个精确的公式来表达，该公式由 Boehm 做了进一步修改：

软件架构 ＝ {元素，形式，关系/约束}

软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描述它。为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图

逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。

过程视图（Process View），捕捉设计的并发和同步特征。

物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。

开发视图（Development View），描述了在开发环境中软件的静态组织结构。

架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例 （use cases）或场景(scenarios)来说明，从而形成了第五个视图。正如将看到的，实际上软件架构部分从这些场景演进而来，我们在每个视图上均独立地应用 Perry & Wolf 的公式，即定义一个所使用的元素集合（组件、容器、连接符），捕获工作形式和模式，并且捕获关系及约束，将架构与某些需求连接起来。每种视图使用自身所特有的表示法－蓝图（blueprint）来描述，并且架构师可以对每种视图选用特定的架构风格（architectural style），从而允许系统中多种风格并存。

我们将轮流的观察这五种视图，展现各个视图的目标：即视图的所关注的问题，相应的架构蓝图的标记方式，描述和管理蓝图的工具。并以非常简单的形式从 PABX 的设计中，从我们在Alcatel 商业系统（Alcatel Business System）上所做的工作中，以及从航空运输控制系统（Air Traffic Control system）中引出一些例子―旨在描述一下视图的特定及其标记的方式，而不是定义这些系统的架构。

"4+1"视图模型具有相当的"普遍性"，因此可以使用其他的标注方法和工具，也可以采用其他的设计方法，特别是对于逻辑和过程的分解。但文中指出的这些方法都已经成功的在实践中运用过。

4.2设计模式介绍

4.3创建者模式

4.4结构型模式

4.5行为模式

五 逻辑试图（罗创） 逻辑试图介绍

5.1用例图

5.2时序图

5.3状态图

5.4类图（李金栓）

5.5。。。

六 开发视图（罗创）

七 进程视图

八 物理视图（李金栓）

九 场景视图