软件工程课程实践-软件配置管理计划

1. 引言

随着当今社会的快速发展，人们的生活日益美好。在吃穿无忧的情况下，人们逐渐注重个人理财，其中基金就是理财产品的一种。基金的收益平稳，风险较低，受到了大多数人的青睐，但是大部分的消费者并不懂专业数据管理与分析，对个人基金也没有合理的规划。本系统的开发由此而来，用于解决基金用户日常的基金管理和数据分析，让用户可以合理规划自己的基金。

该基金管理系统界面简洁美观，功能友好。系统采用了可视化的图表，方便用户可视化地分析数据的对比与变化，给用户更加直观的感受和分析个人的基金，并且通过我们的系统可以在线购买和抛售，免去了一些繁琐的过程，增强了用户体验。

1. 数据表格和统计图表结合分析
2. 基金情况横纵对比（不同基金的，同一基金不同时间）
3. 多种查询方式，智能表格排序
4. 多种数据统计（种类统计，盈亏统计，收支统计）图表展示
5. 在线抛售与购买，记录购买和抛售记录
6. 强大的安全系统（支持原密码，邮箱，密保多种密码修改方式）

1. 组织及职责

  配置管理的角色和职责见表1

               表1：配置管理角色职责表

角色	人员	职责和工作范围
项目组 配置管理员	XXX	制定《配置管理计划》;搭建配置库结构;申请并配合建立配置库;配置库的管理;准备、申请、并实施基线化(或发布入库)工作;将建库和入库情况及时通知各项目成员;备份、维护基线库（或发布库):配合高级配置管理员、SQA完成配置管理状态报告
高级配置管理员	XXX	根据实际情况审批建库申请，分配服务器资源，完成建库;管理配置库的用户帐号、权限;对配置库做物理审计;配合项目配置管理员、SQA完成配置管理状态报告;定期编制产品库定期报告
项目CCB	XXX	审批配置管理员递交的基线化申请表、发布入库申请表，评审是否同意配置项的变更
项目经理PM	XXX	与各项目组代表一起审批配置管理计划;审批建库申请表;与CCB成员一起审批配置项的变更、基线化、发布申请;检查配置管理计划完成情况
项目组成员	XXX	了解并按权限正确使用配置库;配合项目组配置管理员准备、申请基线化(或发布入库）工作
SQA	XXX	检查项目SCM工作是否按流程和计划实施:反馈不符合项给项目组，并跟踪其修正情况;对配置库做功能审计;检查项目组和高级配置管理员的工作，并与之合作完成配置管理状态报告。

1. 配置管理环境

   本项目是小型项目，工期也不是很长，本次基金管理项目采用Microsoft Project为配置管理工具。

   Microsoft Project是项目管理工具软件，作用是可以快速、准确地创建项目计划；可以帮助项目经理实现项目进度、成本的控制、分析和预测；可产生关键路径日程表，关键链以甘特图形象化；可以辨认不同类别的用户，对专案、概观、和其它资料有不同的访问级别。

3.1用户和权限

类别	人员	权限说明
配置管理者	XXX	负责项目配置管理，拥有所有权限
项目经理	XXX	访问、读
质量保证人员	XXX	访问、读
开发人员	XXX	访问、读
高层管理	XXX	访问、读

3.2功能简介

   该系统面向的对象是社会上的基金用户，基金用户需要提前在我们的官网上进行注册，之后登陆之后才能进入我们的系统中。用户可以使用我们系统的各个功能模块，包括“基金市场”、“基金查询”、“基金管理”、“用户管理”四大模块。管理员可以进行后端数据库数据的更新

   该系统是基于网络技术的一种在线系统，管理员通过网络对各个数据库进行维护；用户通过系统进行对个人基金进行管理；

功能	具体描述	对应此功能的系统角色
登录与注册	用户登录与注册功能	用户
基金市场	每日的基金情况以及基金查询搜索	用户
基金查询	过往基金的查询，包括“代码查询”、“日期查询”、“简称查询”	用户
基金管理	用户个人基金的管理，包括“基金抛售”、“购买记录查询”、“抛售记录查询”、“基金图表”	用户
用户管理	修改用户信息、更改密码	用户
数据更新	对数据库中的数据进行更新	管理员

1. 配置计划

4.1WBS

软件开发的工作分解结构（Work Breakdown Structure） 如下所示：

 

4.2项目组文档目录结构

一级目录	二级目录	内容
01管理文档	01项目启动	项目总结等各种文件
	02项目结项
	03开发计划	项目、培训、质量、配置
	04管理制度
	05风险管理
	06项目估算
	07配置报告
	08评审记录
	09会议记录	一般会议记录
	10变更文档	需求、配置、计划等变更记录
	11周月报
	12验收	项目验收各文件
	13授权	包括项目管理软件和软件系统的授权
	QA
	其他
02技术文档	01可行性研究报告
	02开发规范	各种规范
	03需求文档	业务、分析
	04设计文档	架构、概要、详细、数据库
	05测试及缺陷	单元、集成、系统、压力、性能
	06技术手册	各种开发技术文档及指南
	07上线及试运行	计划、报告
	08维护	报告、记录
	09投资及部署	投资手册、部署手册
	10其他
03用户文档	01用户提交文档	各种需求、界面、需求等
	02用户手册	用户、操作
	03培训资料	其他培训资料
	04其他
04其他文档

1. 配置项
   1. 配置项标志
      1. 命名规范

本项目配置项命名规范由5个字段组成，从左到右依次为:公司、项目、类型、编号和版本号，如图1所示。这些字段用一横线(-）分隔。

                

 

1. 1. 1. 主要配置项

类型	主要配置项
技术合同	《合同》
	SOW
计划	《项目计划》
	《质量保证计划》
	《配置管理计划》
需求	《需求规格说明书》
	用户DEMO
设计	《总体设计说明书》
	《数据库设计》
	《详细设计说明书》
	《设计术语及规范》
编程	源程序
	编码规则
测试	《测试计划》
	《测试用例》
	《测试报告》
提交	运行产品
	《验收报告》
	《用户手册》

1. 1. 1. 项目基线

  基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。

1. 1. 1. 配置项的版本管理

  配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支:主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。

  这四类工作空间(分支)由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

  对配置项的版本管理在不同分支具有不同的策略:

1.  主干分支
   
     系统默认自动建立的物理分支一主于 分支(/main)，基线均以LABLE方式出现在主干分支上。
   
   (2) 私有分支
   
     如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不与管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。
   
   (3) 小组分支
   
     如果出现小组共同开发一配置项， 该分支可视为项目组内部分组的私有空间，存放代码开发过程中的版本分支，由项目组内部控制。
   
   (4) 集成分支

集成测试时在主干分支的特定版本上建立集成分支，测试工作在集成分支上完成。

1. 1. 变更管理

  变更管理的流程是:

(1)由请求者提交变更请求，SCCB会召开复审会议对变更请求进行复

审，以确定该请求是否为有效请求。典型的变更请求管理有需求变更管理、缺陷追踪等。

(2）配置管理者收到基线修改请求后，在配置库中生成与此配置项相关

的波及关系表。

(3）配置管理者将基线波及关系表提交给SCCB，由SCCB确定是否需

要修改，如果需要修改，SCCB应根据波及关系表，确定需要修改的具体文件，并在波及分析表中标志出来。

1. 配置管理者按照出库程序从配置库中取出需要修改的文件。

(5)项目人员将修改后的文件提交给配置管理者。

(6）配置管理者将修改后的配置项按入库程序放入配置库。

(7)配置管理者按SCCB标识出的修改文件，由波及关系表生成基线变

更记录表，并按入库程序放入配置库。

1. 配置审核

  按照配置管理规程，定期对配置库和配置项的状态进行审核，审核配置管理活动和过程，确定所产生的基线和文档是否准确，并且在适当时记录审核结果，以便维护配置基线的完整性。将结果记录到《配置状态报告》中。

  具体计划：

审核内容	审核的频率	审核人	审核对象、方式
基线的完整性	1次/两周		审核基线是否完整。如果基线不完整，则对基线进行调整。
检查配置记录	1次/两周		审核配置管理记录是否正确反映了配置项的配置情况。
审查配置库和配置项的结构	1次/两周		根据《配置管理计划》审查配置管理系统中配置项的结构完整性
审查配置项的完备性和正确性	1次/两周		以《配置管理计划》中说明的需求和所批准的变更请求的处置为基础来验证配置项的完备性和正确性
跟踪审核后的行动	1次/两周		对审核后提出的各项行动进行跟踪，直到结束
审核配置项的变更	1次/两周		审核配置项变更的状态、配置项变更的版本、内容等方面的正确性
审查配置库的操作和备份	1次/两周		审核配置库的操作、管理状态，以及备份、安全维护等方面活动。