医院就诊管理系统软件配置管理计划

1、医院就诊管理系统配置管理计划作 者：完成f1期：修改情况记录：版本号修改批准人修改人目录1引言11.1目的11.2定义和缩写词11.3参考资料12管理22.1项目组织机构22.2任务22.3职责22.4接口控制32.5实现33软件配置管理活动33配置标识33.1.1 基线33.1.2代码、文档43.2配置控制43.3配置状态的记录和报告53.3配置状态的记录和报告53.4配置的检查和评审64工具、技术和方法65记录的收集、维护和保存66附录：配置管理报表及其格式66软件问题报告单(spr) 66.1.1配置管理人员填写内容66.1.2配置管理状态76.1.3配置管理中请人员填写的内容76.2软

2、件修改报告单(scr) 81引言1.1目的木文档目的在于对医院就诊管理系统项目进行软件配置管理，提高软件的质量，降低软 件开发成本。木计划制定了庾院就诊管理系统项冃如何进行配置管理活动、活动的计划安排、 指派的职责和所要求的资源，以及配置控制活动。对医院就诊管理系统项目实施软件配置管 理活动时，需要参照本计划。1.2定义和缩写词（随便在程序里找几个关键常用参数贴进去自己编一个系统的缩写比如stusys ）hms：hospitalmanagement system 医院管理系统。patient:患者doctor：医生register:挂号人员super manager：超级管理员drug药材ta

3、ble info：数据库表信息（病史表，挂号表，药材表）1.3参考资料a. 软件工程模型与方法（肖丁吴建林周春燕修佳鹏主编）b. 统一软件开发过程，ivar jacobson, james rumbaugh, grady booch 著c. 现代软件工程，清华大学周z英编著2管理2.1项目组织机构木软件系软件管理课程实践项冃，属于小型系统，项冃组共3名成员，小组在开发过程 屮采用民主制小组的形式。因为在开发过程中遇到问题基木上都是通过会议讨论解决，组内 成员可以平等地交换意见，充分发挥每位成员的积极性和主动性。2.2任务生命周期阶段里程碑时间负责人准备软件项目开题、软件开发计 划、配置管理计划

4、、质量保 证计划2012-10项目小组需求需求说明书2012-10项目小组设计构架设计、数据库 设计、功能设计2012-11项目小组编码代码、单元测试2012-11项目小组测试测试总结报告2012-11验收系统验收2012-122.3职责a. 组长全面负责冇关软件配置竹理的各项工作；b. 项目的专职配置管理人员检杳在作配置更改时的质量保证措施，纽长负责监督在软件配置管理丄作中认真执行软件工程规范；c. 各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；d. 用户代表负责反映用户对配置管理的要求，并协助检查各类人员对软件配置管理计划的执行悄况;2.

5、4接口控制a. 用户界面：用户界面是指各子系统与设计人员、用户或维护人员z间的操作约定。 同时还指实现这些操作约定的物理部件的功能与性能特性。b. 系统内部接口 ：系统内部接口是指各子系统在集成为一个总的软件系统时的各种连 接约定。c. 标准程序接口：标准程序接口是指各应用子系统与标准子程序库（包括宿主计算机 系统已冇的库程序）z间的调用约定。d. 设备接口：设备接口是指各了系统与各种设备（包括终端和其他各种输入/输出设 备）之间的连接约定。e. 软件接口 ：软件接口是指各个子系统与猶主计算机上的系统软件以及与调用本软件 的其它软件系统之间的连接约定。2.5实现a. 建立配置控制组；b. 确定

6、各个配置基线；c. 建立接口控制协议；d. 制订评审与检查软件配置管理计划和规程；e. 制订相关的软件开发、测试和支持工具的配置管理计划和规程。3软件配置管理活动3.1配置标识3.1.1基线基线：（基线其实只要指派儿个报告就行如下不用a复杂）(1) 功能基线：医院就诊管理系统评审和批准(2) 指派基线：医院就诊管理系统软件需求规格说明书(3) 产品基线：医院就诊管理系统软件测试b. 与每个基线有关的评审与批准事项以及验收标准：(1)满足功能需求，符合用八相关需求规定c. 在建立基线的过程中用户和开发者的参与情况：用户：阅读销售系统一软件需求规格说明书，并提出其它的相关需求，并制定 相关的标准，

7、参与审阅；开发者：同样阅读销售系统软件需求规格说明书，设置程序功能，进行开发; 并参阅销售系统一软件测试进行软件测试。在产品基线中，要定义的元素包括：a. 产品的名字和规则；b. 产品标识编号;c. 对每一个新交付的版本，要给出版本交付号、新修改的描述、修改交付的方法、对 支持软件的修改要求以及对有关文档的修改要求；d. 安装说明；e. 已知的缺陷和故障；f. 软件媒体和媒体标识。3.1.2代码、文档开题报告需求说明书软件配置管理计划书项h开发计划书3.2配置控制a修改批准权限：对考试系统屮的模块、基线以及任何修改，都必须通过木项目的配置管理小组的讨论。b. 描述软件库控制的规程，其中包括存収

8、控制、対于适用基线的读写保护、成员保护、成员标识、档案维护、修改历史以及故障恢复等七项规程；c.如果要修改考试系统的冃标代码，则采用命名标识対其进行追踪标识。d. 修改控制工具：修改控制工具是协助软件配置管理人员进行配置控制的冇效手段3.3配置状态的记录和报告a. 规格说明的状态：如：屮请修改状态等b. 修改建议的状态：设置软件修改报告单进行状态追踪c. 修改批准的报告d. 产甜版本或其修改版的状态；e. 安装、更新或交付的实现报告；f. 川户提供的产品（如操作系统）的状态；g. 有关开发项目历史的报告。3.3配置状态的记录和报告本条必须：a. 指明怎样收集、验证、存储、处理和报告配置项的状态

9、信息;b. 详细说明要定期提供的报告及其分发办法；c. 如果有动态杏询，要指出所提供的动态杏询的能力；d. 如果要求记录用户说明的特殊状态时，要描述具实现手段。例如，在配置状态记录和报告中，通常要描述的信息有：a. 规格说明的状态；b. 修改建议的状态；c. 修改批准的报告；d. 产品版本或其修改版的状态；e. 安装、更新或交付的实现报告；f. 用户提供的产品（如操作系统）的状态；g. 有关开发项目历史的报告。3.4配置的检查和评审目的：保证系统在整个生存周期中在技术上和管理上的完整性。软件配登管理小组耍对所有由笫三方捉供的软件进行物理配直检查;对销伟软件及具各 个子模块的每一个新的释放进行功

10、能配置检査和物理配置检查；在软件开发周期各阶段的评审与检查工作中，要对该阶段所进行的配置管理工作进行必要 的评审和检查，项目开发过程中记录并保存各项评市记录。4工具、技术和方法软件配置管理所使用的工具：a软件测试工具b、软件配置管理工具c、文档辅助生成 工具与图形编辑工具(如：rational rose 2003)技术：c#语言、sql severe 2005数据库操作、ado.net技术方法：设计并编写文档，设计界面，编写代码，调试测试5记录的收集、维护和保存收集并保存医院就诊管理系统一软件配置管理计划书、医院就诊管理系统一软件需 求规格说明等，定期对其进行备份，保存期限为一年6附录：配置管

11、理报表及其格式6.1软件问题报告单(spr)在系统的运行与维护阶段对软件产品的任何修改建议，或在软件开发的任一阶段屮对前面各 个阶段的阶段产晶的任何修改建议，都应填入软件软件问题报告单。软件问题报告单位的格 式见表1。配置管理人员填写内表屮a、b、c、p和状态等项目是由负责修改控制的配置管理人员填写的。表屮其他各项 即d、e、f、g、h、i、k、n和0各项是由发现问题的人或申请配置管理的人填写的，他 可能还要填写j、l和m三项内容。前四项内容的意义如下：a是由配总管理人员确定的登记号，一般按报告问题的先后顺序编号；b是曲配置管理人员登记问题报告的日期；c是发现软件问题的li期；p是填写若干补充

12、信息和修改建议。关于配査管理七种状态的含义在下面解释。6.1.2配置管理状态状态一栏分成七种情况，现分別说明如下：1表示软件问题报告正被评审，已确定釆取什么 行动；2表示软件问题报告已由指定的开发人员去进行维护工作；3表示修改已经完成、测 试好,正准备禅放给主程序库；4表示主程序库已经更新,主程序库修改的重新测试尚未完 成；5表示已经进行了复测，但发现问题仍然存在；6表示已经进行了复测，已经顺利完成 所做的修改，软件问题报告单被关闭（维护已完成）；7表示留待以后关闭，因问题不是可 重产生的，或者是属于产品改善方面的，或者只貝有很低的优先级等等。6.1.3配置管理申请人员填写的内容在软件问题报告

13、单中，属于配置管理中请人填写的各项内容的意义如下：d、e两项是项目和子项目的名称，f是该子项日的代号，这应按配置标识的规定来命名代 号；阶段名和报告人的姓名、住址和电话等的含义是显而易见的；g表示问题属于哪一方而的，是程序的问题还是例行程序的问题，是数据库的问题述是文档的问题，是功能性修改还是性能改进性修改问题，也町能是它们的某种组合；h表示子例行程序/子系统，即要指出出现问题的子例行程序名字，如果不知是哪个子例行程序，可标出子系统名，总之，尽可能给出细节；i是修订版木号，指出出现问题的了例行程序版木号；j是媒体，表示包含有问题的子例行程序的主程序库存储媒体的标识符；k是数据库，表示当发现问题

14、时所使川的数据库标识符；l是文档号，表示有错谋的文档的编号；m表示出现错谋的主要测试实例的标识符；n是驶件，表示发现问题时所使用的计算机系统的标识；0是问题描述/影响，填写问题征候的详细描述，如果对能则写明实际问题所在，还要给出 该问题对将來测试、界面软件和文档等的影响。6.2软件修改报告单(scr)对软件产品或其阶段产品的任何修改，都必须经过评审、批准后才能重新投入运行或作为阶 段产品释放。这一过程用软件修改报告单(software change report)给以记录。软件修改报 告单的格式表2。当收到了软件问题报告单之后，配置管理人员便填写软件修改报告单。软 件修改报告单要指出修改类型、

15、修改策略和配置状态，它是供配宜控制小组进行审批的修改 申请报告。表中各项内容的意义如下：a是登记号，它是配置修改小组收到软件修改报告单时所作的编号；b是配置管理人员登记软件修改报告单的h期；c是已经准备好软件修改报告单、可以対它进行评审的时间；d、e和f的意义为软件问题报告单屮的d、e和f的意义相同；g填写被处理的软件问题报告单的编号，如该编号中提出的问题只是部分解决，则在填写时 要在该编号示附以字母p (pan表示部分之意)；h指出是程序修改、文档更新、数据库修改还是它们的纽合，如果仅是指出用户文档的缺陷 则在解释处作上记号；i是修改的详细描述，如果是文档更新，则要列出文档更新通知单的编号；

16、如果是数据库修 改，则要列出数据库修改申请的标识号；j是批准人，经批准人签字、批准示才能进行修改；k是语句类型，程序修改屮涉及到的语句类型包括：输入/输出语句类、计算语句类、逻辑 控制语句类、数据处理语句类(如数据传送、存放语句)；l是程序名，指被修改注程序、文档或数据库注名字。如果只要求软件修改报告单做解释性 工作，则注重复软件问题报告单给出的名字；m指当前注版木/修订木标识；n指修改后的新版本/修订本标识；0指数据库，如果申请数据库修改，这里给岀数据库的标识符；p是数据库修改中请号dbcr；q指文档，即如果要求文档修改，则在这里给出文档的名字；r是文档更新通知单编号dut；s表示修改是否己

17、经测试，指出己对修改做了哪些测试，如单元、了系统、组装、确认和运 行测试等，并注明测试成功与否；t指出在软件问题报告单小给出的问题描述是否准确，并回答是或否；u是问题注释，准确地重新叙述要修改的问题；v指明问题来口哪里，如系统设计规格说明帖、软件需求规格说明书、概耍设计说明书、详细设计说明书、数据库、源程序等；w说明完成修改所需要的资源估计，即所需要的人月数和计算机终端时数；x指出所要进行修改的类型，由执行修改的人最后填写。修改类型主要有适应性修改、改进 性修改以及计算错误、逻辑错误、输入和输出错误、接口错误、数据库错误、文档错误以及 配置错误等的修改；y是提出对软件问题进行修改的人员或单位；z是完成软件问题修改的人员或单位。表1软件问题报告单（spr）项冃名软件问题报告单子项h代号登记号a登记日期b年 月 日发现期c年 月 口软件定义需求分析概要设计详细设计编码测试组装测试安装验收运行维护报告人姓名地址电话子例行程序/子系统：h修改版本号：i媒体：j数据库：k文档：l测试实例：m硬件:n例行程序口程序口数据库口文档口改进口问题描述/彩响：0附注及修改建议：p表2软件修改报告单（s