软件工程综合实习报告模板文档格式.docx
《软件工程综合实习报告模板文档格式.docx》由会员分享，可在线阅读，更多相关《软件工程综合实习报告模板文档格式.docx（14页珍藏版）》请在冰豆网上搜索。
2.4.7系统变更6
2.5系统模型6
2.5.1用例模型6
2.5.1.1参与者汇总6
2.5.1.2用例汇总6
2.5.1.3顶层用例图7
2.5.1.4用例描述7
2.5.2对象模型7
2.5.3动态模型7
3.概要设计8
3.1系统总体设计8
3.1.1逻辑结构设计8
3.1.2软件架构设计8
3.2系统功能设计8
3.2.1总体结构8
3.2.1功能设计说明8
3.3数据库设计9
3.3.1建库设计9
3.3.2数据库表存放关系9
3.4界面设计9
3.4.1主界面9
3.4.2子界面A10
4.详细设计11
4.1模块接口设计11
4.1.1接口A11
4.1.1.1功能描述11
4.1.1.2数据结构11
4.1.1.3输入项与输出项11
4.1.1.4算法与程序逻辑11
5.单元测试12
6.系统测试13
6.1模块测试13
6.1.1模块A13
6.1.1.1模块简述13
6.1.1.2测试结果13
6.2模块缺陷数量统计14
6.3测试评价14
6.3.1充分性评价14
6.3.2缺陷与不足14
6.3.3改进建议14
7.实习体会15
参考文献16
1.系统概述
1.1系统背景
[对综合实习选题内容进行说明，可给出对当前研究问题或现有系统的现状分析]
1.2系统目标
[概述系统要完成的内容或建设目标，可采用条目描述或表格形式给出]
序号
目标内容
1
2
3
4
1.3里程碑计划
项目阶段
阶段完成标准（里程碑）
开始时间
结束时间
工作量（日）
项目启动
项目启动会议
项目计划
项目计划核准
项目实施
需求分析完成
项目实施与监控
概要设计完成
5
详细设计完成
6
系统代码完成
7
系统测试完成
8
交付软件成果
合计
1.4系统可交付成果
里程碑
可交付成果
交付日期
责任人
主要工作
软件需求规格说明
概要设计说明
详细设计说明
单元测试问题追踪表
系统测试报告
系统软件/演示数据
1.5人力计划
阶段
人力数量
备注
计划核准
需求分析
概要设计
详细设计
编码及单元测试
系统测试
系统提交
姓名
进入日期
期望结束日期
承担角色和职责
项目经理
配置管理员
业务分析师
系统架构与功能设计师
系统界面设计师
研发人员
数据库设计人员，DBA
9
测试负责人
10
质量保证员
1.6人员计划
1.7测试计划
测试产品
测试类型
负责人
模块A
单元测试
模块B
…..
模块A+模块B
集成测试
交付系统
系统提交最终产品
验收测试
1.8开发环境与工具
类别
具体需求
硬件
软件
2.需求分析
2.1现有系统概述
[描述现有系统的状况，包括系统中的数据情况以及业务运作情况。
如果设计的新系统将取代现有系统，这一部分就可以描述新系统所支持的任务现在是怎样完成的。
同时，描述现有系统存在的问题]
2.2系统需求概述
[对待实现系统做一个概要的高层描述]
2.3功能性需求
[列出待实现系统的功能性需求]
2.4非功能性需求
[此处可根据待实现系统的自身特点，对下列条目进行裁剪或补充]
2.4.1用户界面
[在这里要分析系统潜在的用户使用系统的情况。
要考虑下面的问题：
哪些类型的用户将使用本系统（专家，新手，等等）？
将会有多种类型的用户使用本系统吗？
对每一种类型的用户将要提供什么样的培训？
容易学习是否是一个非常重要的特性？
防止用户出错是否是一个非常重要的特性？
人机接口会用到哪些输入/输出设备，它们的特性如何？
]
2.4.2硬件考虑
[在这里考虑系统面对的硬件问题。
考虑下面的一些问题：
建议的系统将使用什么样的硬件设备？
设备的特性如何？
包括内存大小、硬盘容量等等]
2.4.3性能特征
[在这里考虑系统的性能要求要限制。
在系统中是否有任何关于速度、吞吐量、响应时间等性能要求或限制？
系统所处理的数据是否有容量的限制？
等等]
2.4.4错误处理
[在这里要关注系统如何处理可能发生的错误。
系统对输入错误如何响应？
系统对一些极端条件如何响应？
2.4.5系统接口
[在这里考虑系统的I/O。
考虑下面的一些情况：
输入是否有来自于外部系统？
输出是否有到外部系统？
对输入输出是否有要执行的限制格式或者中间格式？
2.4.5质量要求
主要质量属性
详细要求
正确性
可靠性
健壮性
兼容性
[在这里关注可能的质量增强或者妥协情况。
对可靠性的需求是什么？
在一次失败后重起系统的时间是否有限制？
每24小时，能够接受的系统当机的次数是多少？
2.4.6安全问题
[在这里关注所有可能的安全问题。
考虑：
访问任何数据或者系统本身是否必须受控？
是否需要物理上的安全性？
2.4.7系统变更
[考虑系统需求的哪些部分可能会在以后更改？
可能会有什么类型的更改？
2.5系统模型
2.5.1用例模型
2.5.1.1参与者汇总
[列出系统的所有执行者，并且对其进行简短描述]
参与者
参与者说明
2.5.1.2用例汇总
[列出系统中的所有用例，说明其优先级，实现难度等信息。
建议此处的用例名通过超链接技术与具体的用例描述关联起来。
如果用例非常多，可以对其进行分类，分类为多个表格。
分类的依据可以是按照参与者、按照开发组、按照主题等等]
用例编号
用例名称
优先级
复杂度
2.5.1.3顶层用例图
[把顶层用例图（UML图，一个或者几个）放在这里。
在顶层用例图中，可以清晰的看到系统所有的参与者，系统的主要用例，参与者与用例的关系，参与者之间的关系，系统的边界等，配合上面的2小节，可以给读者在整个系统的层面上有一个比较完整的认识]
2.5.1.4用例描述
[对系统中的用例，逐一进行描述。
用例的格式有多种，根据情况进行选择]
2.5.2对象模型
[利用UML中的类图，对系统中的类，类之间的关系建模。
此处不涉及设计的考虑，只是对问题域进行分析，得到一个或者多个类图]
2.5.3动态模型
[通过对系统的分析，利用UML中的状态图、顺序图、活动图等手段对系统的动态模型进行建模。
模型的画法可以参考UML相关书籍]
3.概要设计
3.1系统总体设计
［说明待实现系统的总体框架、系统逻辑结构和软件结构架构等。
］
3.1.1逻辑结构设计
［说明系统拟采用的逻辑体系结构，例如C/S、B/S、三层体系、N层体系、J2EE等常用体系架构］
3.1.2软件架构设计
［根据系统所采用的逻辑结构，结合系统自身的业务特点，说明系统拟采用的软件架构，例如常见的四层架构：
数据存储、应用服务、Web发布、用户层］
3.2系统功能设计
3.2.1总体结构
［说明系统按照功能划分的总体结构。
可用结构图来描述系统的子系统划分情况；
如果待实现系统比较简单，则可以直接描述系统中模块间关系的层次。
结构图的基本组成部分是模块，模块用来标识一个功能，在结构图中表示了系统的层次关系和调用关系］
3.2.1功能设计说明
［按照系统的子系统划分情况，或者单个系统的模块划分情况，依次给出各个子系统或模块的详细的功能描述，及其设计的说明。
此处设计说明可采用UML包图、构件图、部署图、细化的模块图进行辅助说明］
3.3数据库设计
3.3.1建库设计
[对系统中需要管理的各种数据，用什么方式进行管理进行设计。
对放到数据库中管理的数据，要描述出表、表之间的关系、视图、触发器、储存过程接口等设计。
此处可以使用下列表格形式直观地描述数据表的定义]
字段名称
类型
宽度（字节）
说明
3.3.2数据库表存放关系
［说明本文件各个表空间与各张表之间的存储关系等等；
可以用实体-联系图（ERD）来建立模型，包括数据实体、数据实体的属性以及它们之间的关系。
3.4界面设计
3.4.1主界面
[1、绘制主界面的视图，或给出系统原型界面抓图，说明主界面中所有对象的功能与操作方式]
3.4.2子界面A
[若系统可以下分若干子系统，则依次给出各个子界面的视图或界面抓图，说明其中所有对象的功能与操作方式]
4.详细设计
4.1模块接口设计
［对照概要设计中的系统功能设计，依次给出各个子系统中各个模块的接口设计详细说明。
可以按照如下章节进行组织，也可以采用UML类图加上程序逻辑描述的形式给出。
[若待实现系统功能较为简单，那么只需给出其中若干关键模块的详细设计说明即可。
4.1.1接口A
4.1.1.1功能描述
[此处加入接口A功能的描述]
4.1.1.2数据结构
[此处加入接口A使用的数据结构]
4.1.1.3输入项与输出项
[此处加入接口A的输入/输出参数的定义]
4.1.1.4算法与程序逻辑
[此处加入接口A的程序逻辑描述，可以采用流程图或者伪码形式描述]
5.单元测试
[
升级会员 