请详细谈谈software baseline

going

请详细谈谈software baseline

tingting

在软件开发过程中，由于各种原因，可能需要变动需求、预算、进度和设计方案等，尽管这些变动请求中绝大部分是合理的，但在不同的时机作不同的变动，难易程度和造成影响差别甚大，为了有效地控制变动，软件配置管理引入基线（baseline）的概念。\r\n\r\n　　基线标志软件开发过程的各个里程碑，任一SCI（例如，设计师说明书），一旦形成文档并复审通过，即形成一个基线，它标志开发过程中一个阶段的结束。对于已成为基线的SCI，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。相反，对于未成为基线的SCI，可以进行非正式修改。\r\n\r\n　　基线可在任何级别上定义，某个SCI一旦成为基线，随即被放入项目数据库（project database）。此后，若开发小组中某位成员与、欲改动SCI，首先要将它拷贝到私有工作区并在项目数据库中锁住，不允许他人使用。在私有工作区中完成修改控制过程并复审通过之后，再把修改后的SCI推出并回到项目数据库，同时解锁。

tingting

软件配置项\r\n\r\n　　一般软件配置需包括下列SCI：\r\n　　1． 系统规格说明书\r\n　　2． 软件项目规划\r\n　　3． 要求分析结果\r\n　　　a． 软件需求规格说明书\r\n　　　b． 可执行的或“纸样”原形 \r\n　　4． 初步用户手册\r\n　　5． 设计规格说明书\r\n　　　a． 数据设计描述\r\n　　　b． 总体结构设计描述\r\n　　　c． 模块设计描述 \r\n　　　d． 界面设计描述\r\n　　　e． 对象描述（若采用面向对象技术）\r\n　　6． 源代码清单\r\n　　7． 测试规格说明书\r\n　　　a． 测试计划和过程\r\n　　　b． 测试用例与实验结果\r\n　　8． 操作和安装手册\r\n　　9． 可执行程序\r\n　　　a． 每个模块的可执行代码\r\n　　　b． 链接到一起的代码\r\n　　10． 数据库描述\r\n　　　a． 数据模型和文件结构\r\n　　　b． 初始化映象\r\n　　11． 联机用户手册\r\n　　12． 维护文档\r\n　　　a． 软件问题报告单\r\n　　　b． 维护申请单\r\n　　　c． 预计变动的顺序\r\n　　13． 软件工程的标准\r\n\r\n　　除此之外，有时把软件工具也列入配置管理的范畴，即把软件开发中选用的编辑器，编译器和其他一些CASE工具固定地作为软件配置的一部分，当配置中其他的SCI发生变化时，， 时考虑这些工具是否与之适应和匹配。\r\n\r\n　　普遍认为，用面向对象的方法组织项目数据库最自然、合理。此时，将每个SCI看作一个配置对象，它有自己的名字和一组属性，各SCI之间的联系用对象间的关系表示。

tingting

这些多少软件配置管理中的software baseline的一些说法，但是我感觉对于IS auditor来说似乎最重视软件需求的变更、软件版本的控制。也就是说，在实际生产环境中的IS是由software baseline控制下递交的满足用户需求的，对change control进行了严格控制的系统版本。\r\n\r\n不知道我的理解是否正确，大家讨论讨论