软件过程管理实验指导书1Word文档下载推荐.docx
《软件过程管理实验指导书1Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《软件过程管理实验指导书1Word文档下载推荐.docx（32页珍藏版）》请在冰豆网上搜索。
论坛、教师学生信息维护
3、软件工程课程群教学论坛
4、在线考试系统
5、高校排课系统
6项目管理软件的开发
7基于Android平台的手机相册
8基于地理信息系统的校园导航系统
9基于地理信息系统的大众点评
开发语言和工具：
（C#，JAVA，C++）
VS2010，SQLSERVER2008，sqlserver2000
六、课程实验报告要求：
以组为单位按软件系统开发可交付文档的形式书写实验报告，按附件中所给出的内容和格式要求作为参考。
其中，项目计划书、软件过程规范的制定由组长组织全组成员共同完成，其他文档按系统功能结构进行分工，分别由各责任人完成相应部分文档然后进行整合。
详细要求见附件。
七、实验时间安排：
由实验室安排。
附件：
实验报告样本
河北工业大学
《软件过程管理》课程实验
实验报告
题目：
专业：
班级：
分组编号：
组长：
成员：
指导教师：
完成日期：
1软件项目开发计划………………………………………………（页码）
2软件需求规格说明书……………………………………………（页码）
3软件配置管理计划……………………………………………（页码）
4软件设计规格说明………………………………………………（页码）
5软件测试计划……………………………………………………（页码）
6软件测试分析报告………………………………………………（页码）
7软件项目开发总结报告…………………………………………（页码）
小组制定的软件过程规范……………………………………（页码）
其他软件开发过程记录信息……………………………………（页码）
小组成员角色与分工情况表
姓名
职责和完成的工作
项目组评定
一、软件项目开发计划
完成人：
1引言
1.1编写目的
说明：
编写这份软件项目开发计划的目的，并指出预期的读者。
1.2背景
说明：
a.待开发的软件系统的名称；
b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c.该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
列出本文件中用到的专门术语的定义和外文的首字母组词的原词组。
1.4参考资料
列出用得着的参考资料，如：
a.本项目的经核准的计划任务书和合同、上级机关的批文；
b.属于本项目的其他已发表的文件；
c.本文件中各处引用的文件、资料，包括所要用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2项目概述
2.1工作内容
简要地说明在本项目的开发中须进行的各项主要工作。
2.2主要参加人员
扼要说明参加本项目开发的主要人员的情况，包括他们的技术水平。
2.3产品
2.3.1程序
列出须移交给用户的程序的名称、所用地编程语言及存储程序的媒体形式，并通过引用相关文件，逐项说明其功能和能力。
2.3.2文件
列出须移交用户的每种文件的名称及内容要点。
2.3.3服务
列出需向用户提供的各项服务，如培训安装、维护和运行支持等，应逐项规定开始日期、所提供支持的级别和服务的期限。
2.3.4非移交的产品
说明开发集体应向本单位交出但不必向用户移交的产品（文件甚至某些程序）。
2.4验收标准
对于上述这些应交出的产品和服务，逐项说明或引用资料说明验收标准。
2.5完成项目的最迟期限
2.6本计划的批准者和批准日期
3实施计划
3.1工作任务的分解与人员分工
对于项目开发中需要完成的各项工作，从需求分析、设计、实现、测试直到维护，包括文件的编制、审批、打印、分发工作，用户培训工作，软件安装工作等，按层次进行分解，指明每项任务的负责人和参加人员。
3.2接口人员
说明负责接口工作的人员及他们的职责，包括：
a.负责本项目同用户的接口人员；
b.负责本项目同本单位各管理机构，如合同计划管理部门、财务部门、质量管理部门等的接口人员；
c.负责本项目同个份合同负责单位的接口人员等。
3.3进度
对于需求分析、设计、编码实现、测试、移交、培训和安装等工作，给出每项工作任务的预定开始日期、完成日期及所需资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件（即所谓“里程碑）。
3.4预算
逐项列出本开发项目所需要的劳务（包括人员的数量和时间）以及经费的预算（包括办公费、差旅费、机时费、资料费、通讯设备和专用设备的租金等）和来源。
3.5关键问题
逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目的影响。
4支持条件
说明为支持本项目的开发所需要的各种条件和设施。
4.1计算机系统支持
逐项列出开发中和运行时所需的计算机系统支持，包括计算机、外围设备、通讯设备、模拟器、编译（或汇编）程序、操作系统、数据管理程序包、数据存储能力和测试支持能力等，逐项给出有关到货日期、使用时间的要求。
4.2需由用户承担的工作
逐项列出需要用户承担的工作和完成期限。
包括需由用户提供的条件及提供时间。
4.3由外单位提供的条件
逐项列出需要外单位分合同承包者承担的工作和完成的时间，包括需要由外单位提供的条件和提供的时间。
5专题计划要点
说明本项目开发中需制定的各个专题计划（如分合同计划、开发人员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装计划等）的要点。
二、需求规格说明书
完成人：
1．概述（Summary）
1.1项目的目的与目标（PurposeandAimofProject）
项目的目的是对开发本系统意图的总概括。
项目的目标是将目的细化后的具体描述。
项目目标应是明确的、可度量的、可以达到的,项目的范围应能确保项目的目标可以达到。
对于项目的目标可以逐步细化，以便与系统的需求建立对应关系，检查系统的功能是否覆盖了系统目标。
1.2术语定义（TermsGlossary）
将该用户需求报告中的术语、缩写进行定义,包括用户应用领域与计算机领域的术语与缩写等。
1.3相关文档（RelatedDocuments）
说明用户需求报告的变更，以及可能受变更影响的其他相关文档，如：
项目开发计划和设计说明书。
2．问题初始分析（EarlyAnalysis）
2.1场景描述（SceneDescription）
自然语言描述
2.2初始功能提取（EarlyFunctionDistill）
3．目标系统功能需求（FunctionofTargetSystem）
3.1功能需求分析（FunctionAnalysis）
对具体功能需求进行细化分析，并用图形工具进行描述。
采用面向对象分析方法，要求采用业务类模型和用例图，配合活动图和序列图进行系统逻辑建模。
3.2功能需求点列表（FunctionList）
在功能需求分析完成后，要详细列出用户需求功能点列表，提供给后续设计、编程、测试中使用，更是为了用户测试验收中使用。
功能需求点列表的格式，如表2-1所示。
表2-1功能需求点列表
编号
功能名称
使用人
功能描述
输入内容
输出内容
1
2
3
4．目标系统性能需求（PerformanceofTargetSystem）
4.1时间要求（TimeRequest）
如：
（1）响应时间，如查询的最长等待时间。
（2）更新处理时间，如记账的最长时间。
（3）数据的转换和传送时间，如远程数据传输的时间要求。
（4）解题时间。
4.2空间要求（SpaceRequest）
（1）支持的终端数。
（2）支持的并行操作的使用者数。
（3）处理的文件和记录数。
（4）处理任务的数量。
（5）对输入和输出数据的精度要求。
（6）对处理和传输过程中的精度要求。
4.3性能需求点列表（PerformanceList）
详细列出用户性能点列表，提供给后续分析、设计、编程、测试中使用，更是为了用户测试验收中使用。
需求性能点列表的格式，如表2-2所示。
表2-2性能需求点列表
性能名称
使用部门
使用岗位
性能描述
输入内容
输出内容
5．目标系统界面与接口需求（InterfaceofTargetSystem）
5.1界面需求（InterphaseRequirement）
界面的原则要求，如方便、简洁、美观、一致等。
整个系统的界面风格定义，某些功能模块的特殊的界面要求。
（1）输入设备：
键盘、鼠标、条码扫描器、扫描仪等；
（2）输出设备：
显示器、打印机、光盘刻录机、磁带机、音箱等；
（3）显示风格：
图形界面、字符界面、IE界面等；
（4）显示方式：
1024*768、640*480等；
（5）输出格式：
显示布局、打印格式等。
5.2接口需求（InterfaceRequirement）
与其他系统的接口，如监控系统、控制系统、银行结算系统、税控系统、财务系统、政府网络系统及其他系统等。
（1）与系统特殊外设的接口，如CT机、磁共振、柜员机（ATM）、IC卡、盘点机等。
（2）与中间件的接口，要列出接口规范、入口参数、出口参数、传输频率等。
应在此列举出所有的外部接口名称、接口标准、规范。
外部接口列表，如表2-3所示。
表2-3外部接口需求点列表
接口名称
接口规范
接口标准
入口参数
出口参数
传输频率
6．目标系统其他需求（OtherRequirementsofTargetSystem）
6.1安全性（Security）
6.2可靠性（Dependability）
6.3灵活性（Agility）
6.4特殊需求（SpecialRequirements）
（1）进度需求：
系统的阶段进度要求。
（2）运行环境需求：
平台、体系结构、设备要求。
（3）培训需求：
用户对培训的需求，是否提供多媒体教学光盘。
（4）推广需求：
推广的要求，如在上百个远程部门推广该系统，是否要有推广的支持软件。
7．目标系统假设与约束条件（SupposeandRestrictionofTargetSystem）
假设与约定条件是对预计的系统风险的描述,如：
（1）法律、法规和政策方面的限制。
（2）硬件、软件、运行环境和开发环境方面的条件和限制。
（3）可利用的信息和资源。
（4）系统投入使用的最晚日期。
三、软件配置管理计划
1.引言
1.1目的
本条必须指出特定的软件配置管理计划的具体目的.还必须描述该计划所针对的软件项目（及其所属的各个子项目）的名称和用途.
1.2定义和缩写词
应该列出计划正文中需要解释的而在GB/T11457中尚未包含的术语的定义,必要时,还要给出这些定义的英文单词及其缩写词.
1.3参考资料
列出要用到的参考资料,如:
本项目的经核准的计划任务书或合同,上级机关的批文;
属于本项目的其他已发表的文件;
本文件中各处引用的文件,资料,包括所要用到的软件开发标准.
列出这些文件的标题,文件编号,发表日期和出版单位,说明能够得到这些文件资料的来源.
2管理
必须描述负责软件配置管理的机构,任务及其有关的接口控制.
2.1机构
必须描述在各阶段中负责软件配置管理的机构.描述内容如下:
描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构;
说明项目和子项目与其他有关项目之间的关系;
指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的相互关系.
2.2任务
描述在软件生存周期各个阶段中的配置管理任务以及要进行的评审和检查工作,并指出各个阶段的阶段产品应存放在哪一类软件库中（软件开发库,软件受控库或软件产品库）.
2.3职责
必须描述与软件配置管理有关的各类机构或成员的职责,并指出这些机构或成员相互之间的关系.
指出负责各项软件配置管理任务（如配置标识,配置控制,配置状态记录以及配置的评审与检查）的机构的职责;
指出上述机构与软件质量保证机构,软件开发单位,项目承办单位,项目委托单位以及用户等机构的关系;
说明由本计划第2.2条指明的生存周期各个阶段的评审,检查和审批过程中的用户职责以及相关的开发与维护活动;
指出与项目开发有关的各个机构的代表的软件配置管理职责;
指出其他特殊职责,例如为满足软件配置管理要求所必要的批准要求.
2.4接口控制
本条应该描述:
接口规格说明标识和文档控制的方法;
对已交付的接口规格说明和文档进行修改的方法;
对要完成的软件配置管理活动进行跟踪的方法;
记录和报告接口规格说明和文档控制状态的方法;
控制软件和支持它运行的硬件之间的接口的方法.
2.5实现
应该规定实现软件配置管理计划的主要里程碑,例如:
建立配置控制组;
确定各个配置基线;
建立接口控制协议;
制订评审与检查软件配置管理计划和规程;
制订相关的软件开发,测试和支持工具的配置管理计划和规程.
2.6适用的标准,条例和约定
2.6.1指明
本条必须指明所适用的软件配置管理标准,条例和约定,并把它们作为本计划要实现的一部分;
还必须说明这些标准,条例和约定要实现的程度.
2.6.2内容
必须描述要在本项目中编写和实现的软件配置管理标准,条例和约定,内容可如下:
软件结构层次树中软件位置的标识方法;
程序和模块的命名约定;
版本级别的命名约定;
软件产品的标识方法;
规格说明,测试计划与测试规程,程序设计手册及其他文档的标识方法;
媒体和文档管理的标识方法;
文档交付过程;
软件产品库中软件产品入库移交或交付的过程;
问题报告,修改请求和修改次序的处理过程;
配置控制组的结构和作用;
软件产品交付给用户的验收规程;
软件库的操作,包括准备,存储和更新模块的方法;
软件配置管理活动的检查;
问题报告,修改请求或修改次序的文档要求,指出配置修改的目的和影响;
软件进入配置管理之前的测试级别;
质量保证级别,例如,在进入配置管理之前,验证软件满足有关基线的程度.
3软件配置管理活动
本章必须描述配置标识,配置控制,配置状态记录与报告以及配置检查与评审等四方面的软件配置管理活动的需求.
3.1配置标识
3.1.1基线
本条必须详细说明软件项目的基线（即最初批准的配置标识）,并把它们与本计划第2.2条描述的生存周期的特定阶段相联系.在软件生存周期中,主要有三种基线,它们是功能基线,指派基线和产品基线.对于每个基线,必须描述下列内容:
每个基线的项（包括应交付的文档和程序）;
与每个基线有关的评审与批准事项以及验收标准;
在建立基线的过程中用户和开发者的参与情况.
例如,在产品基线中,要定义的元素可以包括:
产品的名字和规则;
产品标识编号;
对每一个新交付的版本,要给出版本交付号,新修改的描述,修改交付的方法,对支持软件的修改要求以及对有关文档的修改要求;
安装说明;
已知的缺陷和故障;
软件媒体和媒体标识.
3.1.2代码,文档
本条必须描述本项目所有软件代码和文档的标题,代号,编号以及分类规程.例如,对代码来说:
编译日期可以作为每个交付模块标识的一部分;
在构造模块源代码的顺序行号时,应使它适合于对模块作进一步的修改.
3.2配置控制
必须描述在本计划第2.2条描述的软件生存周期中各个阶段使用的修改批准权限的级别;
必须定义对已有配置的修改建议进行处理的方法,其中包括:
详细说明在本计划第2.2条描述的软件生存周期各个阶段中提出修改建议的程序（可以用注上自然语言的流程图来表达）;
描述实现已批准的修改建议（包括源代码,目标代码和文档的修改）的方法;
描述软件库控制的规程,其中包括存取控制,对于适用基线的读写保护,成员保护,成员标识,档案维护,修改历史以及故障恢复等七项规程;
如果有必要修补目标代码,则要描述其标识和控制的方法.
对于各个不同层次的配置控制组和其他修改管理机构,本条必须:
定义其作用,并规定其权限和职责;
如果已组成机构,则指明该机构的领导人及其成员;
如果还没有组成机构,则说明怎样任命该机构的领导人,成员及代理人;
说明开发者和用户与配置控制组的关系.
当要与不属于本软件配置管理计划适用范围的程序和项目进行接口时,本条必须说明对其进行配置控制的方法.如果这些软件的修改需要其他机构在配置控制组评审之前或之后进行评审,则本条必须描述这些机构的组成,它们与配置控制组的关系以及它们之间的相互关系;
本条必须说明与特殊产品（如非交付的软件,现存软件,用户提供的软件和内部支持软件）有关的配置控制规程.
3.3配置状态的记录和报告
本条必须:
指明怎样收集,验证,存储,处理和报告配置项的状态信息;
详细说明要定期提供的报告及其分发办法;
如果有动态查询,要指出所提供的动态查询的能力;
如果要求记录用户说明的特殊状态时,要描述其实现手段.
例如,在配置状态记录和报告中,通常要描述的信息有:
规格说明的状态;
修改建议的状态;
修改批准的报告;
产品版本或其修改版的状态;
安装,更新或交付的实现报告;
用户提供的产品（如操作系统）的状态;
有关开发项目历史的报告.
3.4配置的检查和评审
定义在软件配置管理计划的第2.2条所定义的软件生存周期的特定点上执行的检查和评审中软件配置管理计划的作用;
规定每次检查和评审所包含的配置项;
指出用于标识和解决在检查和评审期间所发现的问题的工作规程.
4工具,技术和方法
必须指明为支持特定项目的软件配置管理所使用的软件工具,技术和方法,指明它们的目的,并在开发者所有权的范围内描述其用法.例如,可以包括用于下列任务的工具,技术和方法:
软件媒体和媒体文档的标识;
把文档和媒体置于软件配置管理的控制之下,并把它正式地交付给用户.例如,要给出对软件库内的源代码和目标代码进行控制的工具,技术和方法的描述;
如果用到数据库管理系统,则还要对该系统进行描述.又如,要指明怎样使用软件库工具,技术和方法来处理软件产品的交付.
编制关于程序及其有关文档的修改状态的文档.因此必须进一步定义用于准备多种级别（如项目负责人,配置控制小组,软件配置管理人员和用户）的管理报告的工具,技术和方法.
5对供货单位的控制
供货单位是指软件销售单位,软件开发单位或软件子开发单位.必须规定对这些供货单位进行控制的管理规程,从而使从软件销售单位购买的,其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求.管理规程应该规定在本软件配置管理计划的执行范围内控制供货单位的方法;
还应解释用于确定供货单位的软件配置管理能力的方法以及监督他们遵循本软件配置管理计划需求的方法.
6记录的收集,维护和保存
本章必须指明要保存的软件配置管理文档,指明用于汇总,保护和维护这些文档的方法和设施（其中包括要使用的后备设施）,并指明要保存的期限.
四、设计规格说明书
1．引言（Introduction）
本章对该文档的目的、功能范围、术语、相关文档、参考资料、版本更新进行说明。
1.1目的（Purpose）
1.2命名规则（NamingRule）
变量对象命名规则：
申明全局变量、局部变量对象的命名规则。
数据库对象命名规则：
申明数据库表名、字段名、索引名、视图名等对象的命名规则。
1.3术语定义（TermsGlossary）
术语定义或解释一般用表格形式给出，如表3-1所示。
表3-1术语定义或解释表
序号
术语名称
术语定义
总体结构
软件系统的总体逻辑结构。
按照不同的设计方法，有不同的总体逻辑结构。
若采用面向功能或面向数据的设计方法，则总体逻辑结构为一树形的功能模块结构图。
若采用面向对象或面向部件（构件）的设计方法，则总体逻辑结构为部件（构件）的组装图
外部接口
升级会员 