软件过程实验报告.docx
《软件过程实验报告.docx》由会员分享，可在线阅读，更多相关《软件过程实验报告.docx（19页珍藏版）》请在冰豆网上搜索。
软件过程实验报告
题目学生评教系统
年级
专业软件工程
指导教师
小组成员（姓名学号）
实验类型综合型
成绩评定
评语：
教师签名：
年月日
2012年4月25日
一、前言
1.目的
软件产品不能靠人们的意念瞬间完成，它需要一个研发过程。
一般情况下，好的过程才可能得到好的产品，而差的过程会得到差的产品。
人们使用合适的方法、技术、工具才能开发出用户需要的产品。
过程是指“人，方法，技术和工具”的集合。
本实验的目的是按照软件过程的规范要求，结合实际的程序设计，来深入理解并运用软件过程的基本概念、方法与过程。
软件开发过程综合实验要求学生在学习完程序设计语言、数据结构、操作系统等课程后，综合利用所学计算机软件知识完成一个应用系统的设计。
是一个重要的教学实践环节，是对学生所学知识的掌握和应用程度的一个全面地、综合地考察。
2.项目背景概述
3.项目实施环境（注：
包括开发、运行环境）
组件
描述
客户端硬件
可以上网的PC，可以上网的移动终端
服务器端硬件
Intel至强处理器，2TB硬盘，32GB内存
软件：
操作系统（服务器）
Centos
软件：
操作系统（客户端）
Windows,Macos,linux等
软件：
应用开发（客户端）
软件：
数据库（服务器）
MSSQL,MYSQL,ORCAL
软件：
事务处理（服务器）
ORCAL
软件：
Web（服务器）
APACHE,IIS
软件：
Web界面（服务器）
协议：
网络
Tcp/ip
数据库接口
4.项目人员及其分工
该项目共有3个人共同实施，分别是臧银中，杨敏，龙跃。
5.项目实施计划
根据RUP基本思想，本实验可以根据系统的复杂度，选择1-2次开发循环周期（鉴于时间关系，以1次循环为宜），按照初始、细化、构造、移交4个阶段进行项目推进。
二、项目实施
（1）初始阶段
1.阶段目标
A．总体目标
本阶段的根本原则是验证可行性。
总体目标是生成具有必要内容的业务案例，以证明启动项目是正确的。
该阶段的重要工作是确定系统范围、扩展系统构想、进行项目规划和设立评价准则。
本阶段是项目建立初期，项目管理方面的任务比较重。
B．基本活动
用例分析、初步建模、确定项目范围、制定发布周期、确立初始构架。
C．项目管理
Ø识别相关业务发起人；
Ø定义角色和职责；
Ø建立业务目标；
Ø组建项目团队；
Ø评估项目风险；
Ø建立风险评估/转移流程；
Ø建立问题解决流程；
Ø建立变更控制流程；
Ø评估业务目标；
Ø建立项目初步的发布周期；
Ø评估初步项目发布周期；
Ø制定项目计划；
Ø开始首次增量开发；
Ø制定细化阶段实施计划。
D．技术开发
a）确定项目范围-迭代1
评估/选择CASE工具；
识别项目特征；
识别参与者；
识别事件；
创建事件表。
b）用例分析与初步建模-迭代2
从事件表中识别用例；
识别基本事件流（只给出名字）；
识别备选事件流（只给出名字）；
识别异常处理（只给出名字）；
识别潜在用例（只给出名字）；
划分基本事件流和备选事件流的优先级别。
c）细化用例路径和准备系统初始构架-迭代3
详细描述基本事件流；
评估网络影响；
评估操作影响；
评估初始执行框架；
成本估算；
确定增量发布计划。
2.迭代实施
初始阶段的关键是制定项目计划，本阶段需要关注的内容有：
待建系统需要支持的事件、用例、系统架构等。
推荐的项目规划模版
条目
目的
业务用途
开发本项目的原因，如业务流程处理自动化
业务目标
本项目的商务目的
期望特性
项目必须指出的特征列表，如订单跟踪和控制、方便记账、管理库存清单等等
关键成功因素
如按时并在预算内交付、获得全职用户确认
限制
对时间、资金和功能方面的要求
风险
如项目组不熟悉开发环境、新老系统衔接问题，等等
人员安排
相关人员职责
地域的影响
期望使用待建系统的地区
参与者
使用系统的用户，如订单职员、配送员、计费系统，也可以是其它系统或硬件设施
事件表
系统必须注意的一些重要事件，如客户下订单、客户查询订单状态、托运货物等等
用例
在事件表中标识的一组相关事件的分组，如处理订单、维护订单、托运货物、管理库存、支付订单等等
用例的时间流
通过逐一描述事件表的每个事件的事件操作过程来刻画用例的实现路径
系统初始执行构架
如采用分层软件体系结构
项目的基础设施
具体阐述如何实现变更控制和风险评估
项目发布策略
如本项目通过3次增量完成
本阶段拟通过3次迭代完成生命周期目标里程碑。
迭代1：
确定项目范围；
重点内容：
填写项目规划模版，确定系统的参与者、必须响应的事件。
系统参与者模版表格
序号
参与者
定义
1
学生
选择老师，进行评教。
2
老师
查看评教结果
3
教学秘书
通知学生进行评教活动，查看教师评教结果。
4
管理员
设置系统人员，分配权限，设置评教问题，查看评教结果来源。
5
系统管理员
设置系统配置，维护系统。
系统事件表模版表格
主语
动词
宾语
频度
触发方式
响应
学生
评教
活动
特定时间
特定
产生评教结果并保存到系统
老师
查看
评教结果
返回评教结果
教学秘书
通知、查看
评教/评教结果
特定时间
特定
返回评教结果
管理员
设置/查看
权限/问题/来源
返回人员/评教问题/来源
系统管理员
设置/维护
系统
设置成功
迭代2：
用例分析和初步建模；
本次迭代关注焦点是项目范围、用例分析、初步模型3个活动。
目标：
建立用例模型，确定用例的优先级。
注意：
（1）用例是面向目标的，避免编程；
（2）相似功能用例应合并；
（3）一个用例图中的用例一般不超过20个。
用例生成的一般过程：
系统特征—系统响应事件表—对事件表排序、合并、梳理—提取用例
用例名
参与者
功能描述
登陆
学生
学生登陆系统
评教
学生
登陆后学生进行评教活动
查看评教结果
老师
登陆后老师查看评教结果
通知评教
教学秘书
教学秘书通知学生进行评教
设置评教问题
管理员
管理员设置评教问题
查看评教结果来源
管理员
管理员查看评教结果来源
设置系统
系统管理员
开放评教
管理员
开放系统评教功能
迭代3：
细化用例路径和准备系统初始构架。
本次迭代的目标：
确定待建系统的初步方案，确定应用系统交付计划，为后续开发做好准备。
关注焦点：
用例分析、初始架构、发布周期。
（1）用例参加模板
用例名
开放评教系统
用例描述
管理员在每学期的特定时间开放系统评教功能，并通知教学秘书
用例作者
参与者
管理员
物理位置
教务处
状态
已经定义的流程
优先级
1（1-5，1代表最高优先级）
假设
直到评教问题设置完成时，管理员方可开放评教功能
前提条件
管理员进入系统
后置条件
开放评教功能，通知教学秘书
基本路径
评教功能开放，通知教学秘书
备选路径
评教问题设置完成，用纸制档进行评教
异常处理路径
开放评教功能时，评教问题未设置；
开放评教功能后，未通知教学秘书。
业务规则
（2）确定系统初步架构：
确定系统的初步开发与部署环境、工具、数据库以及可能的体系结构等等信息。
可以采用对系统的组件和部署图等进行描述。
C/S架构
组件
描述
客户端硬件
可以上网的PC，可以上网的移动终端
服务器端硬件
Intel至强处理器，2TB硬盘，32GB内存
软件：
操作系统（服务器）
Centos
软件：
操作系统（客户端）
Windows,Macos,linux等
软件：
应用开发（客户端）
软件：
数据库（服务器）
MSSQL,MYSQL,ORCAL
软件：
事务处理（服务器）
ORCAL
软件：
Web（服务器）
APACHE,IIS
软件：
Web界面（服务器）
协议：
网络
Tcp/ip
数据库接口
（3）确定发布周期
首先需要根据对系统业务范围和复杂度的理解，以及确定的初步架构，结合用例的优先级，对系统的整个工作量进行估算。
估算方法：
代码行、功能点估算方法，用例估算方法，等等。
用例估算法基本步骤：
a.确定角色设置角色权重因子；
b.确定用例权重系数；
c.确定技术因素的复杂度权重因子；
d.考虑项目参与者的权重系数；
e.确定用例点；项目评估；
f.制定系统增量发布计划。
用例权重因子示例
用例类型
描述
因子
简单
3个或更少路径
5
一般
4-7个路径
10
复杂
超过7个
15
角色权重因子
角色类型
描述
因子
简单
3个或更少路径
2
一般
4-6个路径
6
复杂
超过6个
10
技术复杂度权重因子
技术因素
权重
等级（0-5）
扩展权重
原因
分布式系统
2
3
6
系统需要能伸缩
响应或吞吐率
1
2
2
可重用代码
1
3
3
易使用
5
4
2
系统必须易于使用
并发性
1
1
1
当前并发性要求低
……
总计因子
26
对于本系统，将涉及角色划分如下：
学生-复杂
管理员，系统管理员：
复杂
教学秘书：
一般
教师：
简单
角色权重2+6+10*3=42
用例权重系数：
1*5（简单）+1*10（一般）+3*15（复杂）=60
未调整用例点UUCP=42+60=102
技术因素：
技术复杂度T=26
TCF=0.6+（0.01*T）=0.86
项目参与者权重系数：
序号
环境因素
权重
等级0-5
扩展权重
原因
1
使用正规过程模型
1.5
3
4.5
2
应用程序经验
0.5
5
2.5
3
面向对象编程经验
1
0
0
4
首席分析师能力
0.5
5
2.5
5
…
…
E因子
21.5
环境系数EF=1.4+（-0.03*E）=0.755
用例点
UCP=UUCP*TCF*EF=66.228
项目评估：
假定每个UCP需要20个单位的个人时间，则系统最终需要的时间为20*UCP=1325个单位个人时间，如果每周工作32h，一个人完成整个项目需要约42周。
设项目有5个人，则需要月9周。
考虑到各种无效时间、交流问题等，额外增加4周。
则总时间约13周。
增量发布计划制定：
增量1
增量2
增量3
3.主要交付物
如上
（2）细化阶段
1.阶段目标
A.本阶段的主要工作
定义、确认结构并将其基线化，设置构想的基线，为构造阶段的高可信度计划设定基线，通过演示说明基线架构可以在期望的时间和费用内实现预期的构想。
A.本阶段的主要工作
细化构想，建立对大多数关键用例的确定理解，这些关键用例将驱动做出最终构架和决定性的计划；细化过程、基础设施、开发环境，而且过程、工具和自动化支持也都各就各位；细化构架并选择组件；可执行的演示是否表明主要的风险要素已被处理并被可靠地解决；构造阶段的计划是否足够准确；是否得到一个可靠的基本估计的支持，等等。
B.基本活动
用例分析、初步建模、静态建模、动态建模、UI原型、最终构架。
2.迭代实施
迭代1：
创建分析模型；
迭代2：
早期UI原型；
迭代3：
动态建模；
本迭代中应该画出顺序图、活动图、协助图、状态图等模型图
1．顺序图
2．活动图
学生对象状态图
迭代4：
确定系统架构。
“最终构架”部分包括三方面内容：
✓技术：
处理构建应用程序所需要的工具、资源及软件分布策略
✓数据访问技术：
处理应用程序中的数据如何被访问，包括数据库复制技术及数据访问结构
✓应用程序技术：
怎样处理应用程序的分层策略及层间的通信机制
a.选择构架模式----三个逻辑层模型
b.对传统三层模型的进一步细化：
Ø业务服务层实际上包含两种类型的服务,业务上下文，处理用户接口，在信息进入系统时对其进行筛选和清除.如：
当一个域中输入的值限制了在另一域中允许输入的值时
Ø业务规则，处理更传统的业务规则,如，在待开发系统中，若一个客户在一年内完成10000美元的订单，则在下一年的订单中可享受10%折扣
Ø数据服务层实际上包括三种类型的服务:
数据转化服务，将对信息服务的逻辑请求（如：
更新）转换为数据库兼容的语言（如SQL）;数据访问服务,执行某些API（如本地数据库接口，适用OLE/DB的ADO，或者ODBC驱动程序）的请求;数据库服务，实际的数据库技术（如Oracle或ＭsSQLserver）
c.选择构架模式----六个逻辑层模型
d.层间如何通信
问题：
应该在层次间采用哪种进程间通信（IPC）技术?
（使用COM/DCOM实现进程间通信）
使用该IPC时，各层间的参数以何种形式传递?
3.主要交付物
（3）构建阶段
1.阶段目标
通过优化资源和避免不必要的返工来尽可能减少开发成本；尽可能快地达到标准所要求的质量；尽可能快地实现可用构想（测试版本）。
2.迭代实施
迭代1：
数据库设计与创建；
迭代2：
组件设计与创建；
（1）存储过程和触发器的使用
存储过程和触发器在解决数据库性能瓶颈问题和需要访问很多行信息才能处理的非常复杂的业务规则时非常实用。
（2）数据转化服务和数据访问服务
包装数据转化服务层的方法
Ø使用一个类，其中对每一个逻辑服务请求（例如，检索指定日期之后的所有订单）都有一个公共的操作
优点：
在系统中产生较少的类
缺点：
可能会产生一个庞大的类，这不符合“类只做一件事而且要把这件事做好的”原则
Ø为每一个业务类使用一个数据转化类。
例如对应于Customer的CustomerDT（DT代表数据转化）。
优点：
更加面向对象，为较小的类提供了高度的内聚性
缺点：
系统中的类的数目太多
迭代2：
组件设计与创建
（1）探讨表示服务层
（2）探讨业务上下服务层
（3）探讨业务规则服务层
（4）合作类-接口、控制和实体
迭代3：
网络设计与创建。
3.主要交付物
如上
三、过程实施中遇到的问题
1.（详细分析所遇问题和相应的解决方法）
四、总结
（要求1000字左右，结合实际探讨对软件过程的认识与体会，包括所使用的主要技术、RUP过程、人员配置与管理、产品及项目管理与实施等几个方面）
五、参考文献
六、术语表
七、附录
（分阶段将相应模型图、文档等交付物附在其后）
升级会员 