—106
— CMM 二级SQA 关键过程域与软件过程改进
刘彦涛，马闰娟
(华东计算技术研究所，上海 200233)
摘 要：探讨了CMM 二级KPA 软件质量保证的实施与软件过程改进，描述了实施SQA 过程的职能、SQA 过程与软件开发过程的关系和SQA 过程实施。在CMM 二级中，SQA 是唯一评审其他5个KPA 的过程域。由于它的这种监督性，软件过程改进的大部分信息源来自SQA KPA ，SQA 在整个软件过程的改进中起着关键的作用，充当SEPG 和项目组之间的桥梁。 关键词：关键过程域；软件质量保证；评审和审核；软件过程；软件过程改进
SQA of CMM Level 2 KPA and Software Process Improvement
LIU Yan-tao, MA Run-juan
(East China Institute of Computer Technology, Shanghai 200233)
【Abstract 】This paper studies the implement SQA of CMM Level 2 KPA and software process improvement, and depicts SQA process duty,relation of SQA process and software development process, SQA process implement. SQA is only a KPA of review other five KPA and audit software work product. Due to this supervise, a part of information of software process improvement is from SQA. SQA takes on key affect in whole of software process improvement, SQA plays the role of a bridge in SEPG and software project group.
【Key words 】key process area(KPA); software quality assurance(SQA); audit and review; software process; software process improvement
计 算 机 工 程Computer Engineering 第33卷 第15期
Vol.33 No.15 2007年8月
August 2007
·软件技术与数据库·
文章编号：1000—3428(2007)15—0106—03
文献标识码：A
中图分类号：TP311
软件工程学的发展为软件开发带来了收益，但也有许多方面不尽如人意。准确定义软件过程现状，要求有一套评价标准、一个度量框架以及对其他许多工作提出的要求。CMM 二级“可重复级”是第1个软件过程改进的台阶，二级中的6个关键过程域(KPA)(需求管理、软件项目策划、软件项目跟踪和监督、软件子合同管理、软件质量保证、软件配置管理)集中关注软件项目所关心的、与建立基本软件项目管理和控制有关的事项。
其中，SQA 为管理者提供对软件项目正在使用的过程和正在构造的产品的可视性。SQA 是绝大多数软件工程过程和管理过程不可缺少的一部分，前5个关键过程域是围绕着组织软件工程过程展开的过程管理，SQA 关键过程域则是全程确保这5个KPA 活动的过程符合标准、规程和组织方针，与组织外部施加标准和要求的一致性。由于SQA 在整个软件过程管理中对所有KPA 起着全程监督作用，因此SQA 在整个软件工程过程的改进中有着最实际的第一手资料，对过程改进起着关键的作用。
1 SQA 过程实施与软件过程改进
1.1 SQA 过程
1.1.1 SQA 过程的职能
SQA 过程实施必须有一个独立的机构，如SQA 组，充当高层关注软件项目的“眼睛和耳朵”。SQA 组有一个独立于项目经理、项目软件工程组和其他软件有关组的向CMM 管理委员会报告的渠道，必须具有独立验证与确认(independent verification and validation, IV&V)的功能。组织可根据自己的情况选择SQA 组人员，例如，SQA 人员可以由质量处人员与开发部门人员结合组成，直接由质量部门领导。SQA 的独立性保证了使其成为高层管理者在软件项目上的“耳目”，并真正行使监督的职能。 1.1.2 SQA 过程的流程与软件开发过程的关系
SQA 参与软件项目早期策划并制定SQA 计划，SQA 的核心工作是对软件过程评审和维护。使软件开发或维护过程不仅是一个技术开发过程，而是一个软件工程过程。图1显示了SQA 过程的流程[1]。
图1 SQA 过程的流程
从图1可以看出，SQA 负责对软件开发过程所有阶段进
行评价。SQA 通过制定一系列过程评审检查表，来评价每一软件开发过程对标准、规程的符合性，适时地反映软件项目过程可视性，将有关项目过程状态信息提供给高层和软件项目负责人。从软件需求阶段开始到系统测试为止，软件质量保证过程与软件开发过程是同步的，并且与软件开发过程具有双向反馈信息。图中软件配置管理(software configuration management, SCM)是CMM 二级的一个KPA 。
作者简介：刘彦涛(1976－)，男，工程师，主研方向：质量管理； 马闰娟，工程师
收稿日期：2007-04-20 E-mail ：liuyt@https://www.doczj.com/doc/3b9421475.html,
1.2 SQA 过程的实施
软件过程管理的目标是在按计划生产产品的同时提高组织的能力，以便生产更好的产品。如果过程的未来业绩在一个设定的统计区间内可以预测，可以认为这一过程是稳定的，或处于统计控制之下的。在CMM二级中，它为组织定义了管理基本软件过程的模型，在关键实践中，一般只描述“做什么”，而不强制规定“如何做”。
1.2.1 评审软件过程活动
SQA KPA就是对过程定期地评价以决定它们的当前适宜性和有效性，SQA 应能有效地识别过程必需的和有益的改进，保证软件开发计划、软件配置管理计划、软件质量保证计划或其他计划的实施和控制。下面是SQA实施软件过程评审的要点[1]：
(1)SQA评审过程：SQA本身应遵循一个已定义的审核过程，并且SQA评审过程应为项目所有人员接受。SQA评审采用检查表方式将要检查的内容写成检查项；
(2)SQA评审范围：必须确定SQA评审的范围，例如：代码审查，单元测试过程评审；
(3)过程符合性：对那些遵循过程的开发活动，SQA人员应积极地报告过程活动符合项目活动和项目目标的有效性，并建议采取改进措施（改变不够健壮的过程）；
(4)过程不符合性：对那些不遵循过程的开发活动，SQA人员应报告不符合项以及它对项目的影响，并建议由项目组或向上管理层采取纠正措施。
SQA评价软件开发过程及其评价项目所有过程的任务，并验证二级5个KPA活动。以此来保证项目开发的质量。在整个实施过程中，SQA人员工作同步于开发人员，并在周例会、评审会上适时地报告当前开发过程的状态，使软件开发过程适当可视。对过程符合的，建议项目组采取改进措施；对过程不符合的，建议项目组采取纠正措施。如在项目级不能解决的不符合问题，则上溯至高层。作为组织过程改进的数据信息，分6个方面进行描述：
(1)评价软件产品评审过程：SQA 应该报告评价的软件产品验证过程的结果和报告实施任务的度量。
(2)评价项目计划和监督过程：SQA 保证项目产品评价活动满足项目计划，对计划的任何变更需得到项目负责人的批准。SQA 将确定标准或实施方针，适当的数据项描述有助于剪裁标准、实施方针以符合项目的需要。
(3)评价基本软件开发过程：参与软件项目早期策划并制定SQA 计划；主要评价体系结构设计、需求和设计，负责代码审查；评价单元测试、CSC集成测试、CSCI合格性测试、系统集成及测试、系统合格性测试和项目结束交付过程。SQA 将评价准备最终项交付的活动，以保证最终项产品的功能和物理审核满足计划和项目需求。在某些情况下，如果项目不符合项目需求或标准，SQA 应禁止项目的交付，例如：文档，代码或系统。
(4)评价其他管理过程：评价软件开发过程中的支撑过程满足组织相关规程、项目软件配置管理计划要求。
(5)实施配置审核：按配置管理计划实施配置审核，一般在以下几种时机：1) 软件工作产品正式发布即软件产品基线建立之前；2) 很多较小的变更或基线变更时。
(6)验证5个KPA：1)SQA组评审和/或审核管理分配需求的活动和工作产品，并报告其结果；2)SQA组评审和/或审核软件项目策划的活动和工作产品，并报告其结果；3)SQA组评审和/或审核软件项目跟踪和监督的活动和工作产品，并报告其结果；4)SQA组评审和/或审核软件分包工作的活动和工作产品，并报告其结果；5)SQA组评审和/或审核SCM的活动和工作产品，并报告其结果。
1.2.2 审核软件工作产品
审核系统需求分析过程、系统设计过程、软件需求分析过程、软件设计过程、编码和单元测试过程、单元集成和测试、CSCI 合格性测试、 CSCI/HWCI集成和测试、系统合格性测试过程、项目结束交付过程的所有文档审核。
1.2.3 参与配置审核、评审技术活动、管理活动
SQA 按需求实施或依据项目SCMP协助做正式配置审核。配置审核是CSCI的正式验证。有2种配置审核类型：功能配置审核(FCA)和物理配置审核(PCA)。
由项目组实施的技术评审将评审过程和最终软件产品，而不是评审产生的文档资料。SQA将保证技术评审是可实施的和有选择地关注符合经批准的技术文档，并报告评审结果。
对软件项目状态、进展、问题和风险的SQA 的周期管理评审将提供项目活动的一个独立的评价。SQA 将提供下列各项数据给上级管理部门：(1)依从性。识别项目与已建立的组织和项目规程的依从性。(2)问题区域。基于技术评审结果分析，识别潜在的或实际的项目问题区域。(3)风险。基于参与和评价项目进展和问题区域，识别风险。
SQA人员将报告评审结果，并跟踪管理评审发现的问题直至问题处理结束。
1.2.4 SQA处理项目的不符合问题
对项目的不符合问题，无论是在项目内还是在项目外处理，都必须由SQA人员来跟踪，直至关闭。对不符合问题有3种方式解决：
(1)使得产品或过程满足标准、规程、或需求（改正不符合项）；
(2)改变标准或规程以它可用；
(3)做出管理决策，允许不满足标准、规程、或需求（让步）。
对组织暂时不能处理的不符合问题，提出让步处理，作为组织软件过程改进的信息。
1.3 SQA KPA与软件过程改进
CMM主要目标是实现过程的控制和度量，以建立持续改进的基础。组织要求有一套评估方法和项目管理体系才能确保使用CMM，评估帮助组织认清其成熟度状态。整个软件过程的改进以许多小的改进步骤为基础，这些小的改进步骤通过一些关键实践来实现[2]。
过程改进的信息从哪里来？表面上好像项目组可以向SEPG提出，SEPG自己也可以去发现。但是实际情况往往是：一方面项目组成员尤其是成熟度等级较低企业的项目组成员缺乏质量意识，只关注与自身相关的开发工作，对过程改进工作缺乏应有的认识，提不出问题或者有问题也不愿提出来；而另一方面SEPG却又往往苦于不了解项目情况而找不到关键问题所在。SQA的存在可以解决这一矛盾，因为SQA经常要参与过程改进工作，又常常参与项目的活动，既熟悉过程体系又熟悉项目情况，所以SQA在整个软件过程的改进中起着关键的作用，充当SEPG和项目组之间的桥梁。过程改进的信息来源于：(1)它呈现了项目在实施CMM二级中大部分问题，有些问题是因为项目组本身执行得不够规范而产生的，而另一些问题则是由于过程本身存在着一些缺陷引起的，如可操作性不强或前后矛盾等而让项目组无法实施。另外项目实施过程中值得借鉴的一些经验做法通过SQA也会反映给高层和SEPG；(2)内部评估和外部机构对组织CMM 二级的评价中产生的强项、弱项、待改进项和建议项。以上2点，SQA在工作中都会客观反映这些问题以促使过程改进。
为改进软件能力，组织必须分6步：
(1)了解开发过程现状；
(2)确定目标过程；
—107—
—108
—(3)确定所需要的过程改进活动清单，并安排先后顺序； (4)制定完成所需活动的计划； (5)提供实施计划所需要的资源； (6)回到第(1)步。
实施CMM 是组织软件过程的一面镜子，看到组织目前软件过程的水平；评估是组织认清CMM 实施后的结果。例如，根据组织当前软件工程状况和发现的弱项、待改进项、建议项，提出过程改进分2步：
(1)强化培训，采取在组织级上实施以下几方面培训：
1)软件开发文档模板（SJ 20778-2000）及UML 建模方法专题 培训；
2)单元测试、合格性测试类型、技术、工具使用的专题培训； 3)Project 高层使用培训（结合开发计划案例）；
4)SQA 高层技能培训、课题组长项目管理专题培训。 (2)开发SPP 、SPTO 工具。
2 实施SQA 过程的资源
2.1 SQA 角色和技能
SQA 角色来自CMM ，这个角色也将拓展成软件项目管理的SQA ，它对组织无论是处在软件工程的管理层上，还是在CMM 的管理层上，都必须有这个角色。这个角色的作用即是高层领导的耳目又是项目经理的副手，直接负责项目的质量保证。它应具备软件开发的技能、软件工程知识和基本项目管理知识。
2.2 SQA 工具
SQA 检查工具是检查单，分析工具首推Pareto 图。
(1)检查单是SQA 的有效工具；
(2)检查单既对过程活动又对工作产品；
(3)过程检查表的有效性取决于检查项与项目实际的贴切程度和具体程度；
(4)对检查结果必须进行分析，了解趋势，发现问题，宜采用Pareto 图。
2.3 组织对SQA 的评审
SQAG 是唯一一个检查其他KPA 的机构，而他本身也必须被监督，才能保证他的公正性、客观性。高层管理者、独立SQA 专家、项目经理定期评审SQA 活动，并向SQA 组发放评审结果，对不符合问题也被跟踪至关闭，确保SQA 活动是有效的。
3 结论
本文从CMM 角度来阐述组织软件过程的改进，通过实施CMM ，尤其是由SQA KPA 发现的问题对组织的软件过程能力清楚地被刻画，使高层、中层领导和软件开发人员都能认识到自己的需要和欠缺，并需要在那些方面着手改进。为此真正提供组织软件工程的能力，从而保证软件产品质量。
参考文献
1 刘孟仁. 能力成熟度模型(CMM): 软件过程改进指南[M]. 北京: 电子工业出版社, 2001-07.
2 Humphrey W S. 软件过程管理[M]. 高书敬, 译. 北京: 清华大学出版社, 2003-04.
3 GJB 5000-2003. 军用软件能力成熟度模型[S]. 中国人民解放军总装备部, 2003.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
（上接第95页）
lating wavelet, AdaptiveIW)恢复奇异点算法、根据NN 算法得到的特征曲线调整奇异点方法(记为NNcurve)和单纯采用3次样条插值还原奇异点方法(记为SplineI)三者的还原精度。使用2006年的3周负荷数据得到的对比实验结果如图2所示，插值小波的AdaptiveIW 算法对奇异点恢复的平均准确率是最高的。
501001502002502
5
12
20
30
36
样本集合中离群点的个数/个
时间/m s
图1 AKF 算法和NN 算法的平均检测时间对比
91
92939495
962002/3/10-2002/3/17
2002/8/4-2002/8/112002/12/1-2002/12/8
日期 / 周
平均修正准确率 %
图2 算法AdaptiveIW 、Nncurve 和SplineI 的平均恢复准确率
根据仿真实验结果得出结论：在检测奇异点的时间、空间开销和质量方面，AKF 在奇异点的检测时间上较优，而在 奇异点检出精度上稍差。AKF 适合预测短时间间隔的存在大量随机成分的数据流序列，而人工智能方法具有纯数值方法不具有的长处，具有良好的抗差能力，能够掌握那些不易表达的规律，NN(组合神经网络方法)可获得更好的辨识率，但由于模式变化后重新训练的收敛速度慢，造成实时性差，不适于在线恢复奇异点。而在总体平均恢复精度上，ADR 高于NNcurve 和SplineI ，ADR 算法使用的插值小波能够体现数据变化特征，奇异点恢复的精度较好，且运算时间少,性能稳定。
4 结论
本文在线识别并恢复奇异数据的方法,相比传统的方法主要有两个改进:更低的计算代价和更好的恢复精度。利用Kalman 滤波检测奇异数据和使用自适应奇异数据恢复精度的插值小波对奇异数据进行辨识和还原的思想，对小波分析在数据流分析领域是一种有益的尝试。
参考文献
1 Babcock B, Babu S, Datar M, et al. Models and Issues in Data Streams[C]//Proc. of ACM Symp. on Principles of Database Systems. 2002: 1-16.
2 Knorr E M, Ng R T. Algorithms for Mining Distance-based Outliers in Large Datasets[C]//Proc. of the 24th Int’1 Conf. on Very Large Databases. New York: Morgan Kaufmann. 1998: 392-403.
3 Mallat S. A Wavelet Tour of Signal Processing[M]. Academic Press, 1999: 221-226.
软件开发的几个关键过程三 - 一.软件项目管理（Software Project Management） SW-CMM将项目管理分为两个部分，即软件项目计划（Software Project Planning）和软件项目跟踪及监控（Software Project Tracking and Oversighting）。 软件项目计划的目的是为完成软件工程和管理软件项目制定合理的计划。 软件项目计划包含估计待完成的工作，建立必要的约定和确定进
行该工作的计划。 软件计划计划首先作出有关待完成的工作和其它定义及界定软件项目的约束和目标（由需求管理关键过程区域的实践所建立的）的陈述。软件计划过程包括以下步骤：估计软件工作产品规模及所需的资源，制定时间表，鉴别和评估软件风险和协商约定。为了制定软件计划（即软件开发计划），可能需要重复地通过这些步骤。 该计划提供完成和管理软件项目活动的基础，并按照软件项目的资源、约束和能力，阐述对软件项目的顾客作的约定。 软件项目跟踪和监控的目的是建立对实际进展的适当的可视性，使管理者能在软件项目性能明显偏离软件计划时采取有效措施。
软件项目跟踪和监控包括对照已文档化的估计、约定、和计划评审和跟踪软件完成情况和结果。基于实际的完成情况和结果调整这些计划。 软件项目的已文档化的计划（即软件开发计划，正如在软件项目计划关键过程区域中所描述的）用作跟踪软件活动、传送状态和修订计划的基础。管理者监控软件活动。主要通过在所选出的软件工作产品完成时和在所选择的里程碑处，将实际的软件规模。工作量、成本和时间表与计划相比较，来确定进展情况。当确定未实现软件项目计划时，采取纠正措施。这些措施可以包括修订软件开发计划以反映实际的完成情况和重新计划遗留的工作或者采取改进性能的措施。 二.软件需求（Software Requirement） 需求管理的目的是在顾客和将处理顾客需求的软件项目之间建立对顾客需求的共同理解。
（SPI：software process improvement） 参考教材： Introduction to personal software process improvement Introduction to team software process improvement 特点： 采集数据:time时间defect缺陷 成绩： 期末60（PSP 英文）实践20 期中12 （TSP 中文四次课学完，第五次课期中考）平时8 实验： 6 8 11 次课及之后 期末： 第九周五一之后 L1 2018.3.6 Lecture 1: 一个体软件过程的定义: 软件工程师的任务：在预期的进度、费用下高质量地开发软件产品（3点） PSP: 控制、管理和改进个人开发工作的自我改进过程 结构化框架：开发表格、指南和规程 PSPi（I—>introduction） 时间管理—>计划过程 缺陷管理—>产品质量
二时间管理 1、时间管理的逻辑原理 ·制定计划，按照计划去做 ·跟踪现在时间使用情况 ·检查时间与计划的准确性，写成文档与实际情况作比较·检查存在的错误 2、了解时间使用情况 将数据保存在合适的地方 3、工程记事本 记录时间使用情况 ·纪录作业、跟踪所承诺的工作、作课堂笔记 ·工作实施方案的凭证 ·保护知识产权 *编号*终止日期每一页编号，前两页作为目录
三时间跟踪 目标：估算完成任务的时间以定义质量目标单位：分钟 工具：标准的时间记录日志 时间记录日志：C completed Unit 数据来源工程记事本 **及时总结记录的时间数据 四阶段计划 1.定义： ?阶段计划短时间的计划 ?产品计划基于活动的计划 二者互相包含 2.阶段计划： 工具：周活动总结表三个子表 数据来源于时间记录日志
软件配置管理过程指导说明书
目录 1 前言 (2) 1.1 目的 (2) 1.2 适用范围 (2) 1.3 术语名词解释 (2) 2 角色和职责说明 (3) 3 输入 (4) 4 入口准则 (4) 5 配置管理实施 (4) 5.1 配置库结构 (4) 5.1.1 配置库 (4) 5.1.2 配置管理库系统 (6) 5.2 配置管理流程 (6) 5.2.1 配置管理流程图 (6) 5.2.2 配置变更流程图 (7) 5.3 配置标识 (8) 5.3.1 配置库划分 (8) 5.3.2 配置库结构 (8) 5.3.3 配置项命名 (11) 5.3.4 版本编号规范 (11) 5.4 配置管理活动 (12) 5.4.1 制定配置管理计划 (12) 5.4.2 建立配置库 (12) 5.4.3 建立配置项 (12) 5.4.4 基线建立及发布过程 (12) 5.4.5 配置变更 (13) 5.4.6 配置审计 (15) 5.4.7 备份 (16) 6 输出 (16) 7 出口准则 (16) 8 本过程裁剪规定 (16)
1 前言 1.1 目的 用于描述配置管理作用和过程，规范配置管理的实施过程、活动和操作。 1.2 适用范围 适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3 术语名词解释 CCB：Configuration Control Board，配置管理委员会，每个项目组需要建立项目级的CCB作为变更控制权威。CCB由质量工程师、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、上级质量部门主管。CCB组长可以是质量工程师或质量部领导，但不能是项目经理。 软件配置项：是指软件工程过程中所生产或使用的任何元素，或者是纳入软件产品的元素。它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等，包括：项目文档，源代码，执行程序，相关设备及资料。 软件配置管理：对软件配置项的管理称为软件配置管理。软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。 软件工作产品：由定义、维护和使用一个软件过程所产生的任何人工制品，包括过程描述、计划、规程、计算机程序和相关文档，无论是否打算将它们交给客户或最终用户。 软件产品：可交付给客户或最终用户的软件工作产品的子集称作软件产品 基线：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，也即指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。（3）基线变更必须经过CCB审批。 变更控制：对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。 版本发布：指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。即交付给客户的一个包括可执行程序和文档的发布基线称为发布（release）。 配置审计：可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。 物理审计的内容包括： ? 确认配置项标识的正确性； ? 确认已受控配置项的更改是受到控制的； ? 验证配置库内容与相应记录之间的一致性； ? 验证配置管理活动与相应记录之间的一致性； ? 验证配置管理工作是否符合适用的标准和规程； ? 验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括： ? 验证当前基线所含配置项对前一基线所含配置项的追溯性； ? 确认当前基线所含配置项均正确反映了项目需求； ? 评估基线的完整性； ? 验证当前基线和各基线间所含配置项的一致性； 验证配置库内容的完备性和正确性等。
浅谈软件开发管理体会 杨利梅
从毕业至今，大小的项目做了一些，有不少成功的喜悦，也有很多失败的教训。今年由于工作需要，我以软件项目负责人的身份参加了接入网统一网管系统开发的整个过程。从中学到了不少知识，有许多体会,想将自己的感受写出来，与大家共勉。 软件项目管理是一个庞大而复杂的系统工程，当前业界对于软件开发流程有不少规范和定义，如CMM和ISO9000。在该管理体系的管理下是可以开发出高质量的软件产品。但是由于该体系较适合于大型而且复杂项目的团队开发，真正实施尚需要时间和过程。而我们当前执行的项目，一般只有10个人左右，要实施软件工程难度更大。我认为：虽然项目大小不一，但管理方法是相通的，要做好软件开发工作，就必须加强有效管理。 大家知道，“软件危机”起源于一些大型项目的不断延迟甚至失败。与大项目相比，小项目具有以下特点: ?项目功能相对较少； ?开发人员较少； ?开发周期较短。 小项目看起来比较简单，比较容易成功，人们往往容易忽视小项目的管理，其实这是一种误解。 据我了解，小项目开发中容易出现以下问题：: 1、开发之前没有认真地进行项目可行性和工作量的估计。 往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差距。 2、没有真正的设计过程。 开发人员少，不同人员的程序之间交互、接口相对少一些。开发周期短往往是几个人从头到尾负责一个项目，几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档来规范各自职责和项目细节。 这种做法潜在的危险之一是有人可能会对所讨论的接口、结构理解有偏差，可能会造成以后的返工。 另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按时完成分工任务后，才发现各个模块组合起来却无法形成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。 第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，难以理解以前别人做好的代码，又要从头做起。另外，没有文档的程序，日后维护和版本升级都比较困难。 3、不经过单元测试而直接进入系统测试。 造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。 针对以上问题，我认为在开发过程中必须处理好四个关键问题，严格把关，可以大大提高软件的质量。 这四个关键问题为：人员、规范、测试、时间控制。 一、合理配置人员 首先软件开发是一项长期艰苦的工作，所以一个团结、协作的团体才能在规定的时间内完成一个质量上乘的软件项目。团队中的每个人必须积极融入到整个集体中，不能互相推诿，更不能互相埋怨和指责，正确的态度是大家在充分信任的基础上团结协作，互相帮助，主动承担任务, 利用集体的智慧获得成功。整个团队就是一部机器，只有每一个齿轮都能正常运作，才能生产出优质的产品。 合理配备人员是成功完成软件开发项目的切实保证。所谓合理配备人员应包括按不
软件配置管理（Software configuration management，SCM） 目录 软件配置管理 (1) 什么是软件配置管理 (2) 配置管理的任务 (2) 实施软件配置管理的优点 (2) 配置软件管理实施的流程 (3) 软件配置管理与CMMI (4) 软件配置管理案例分析 (4) 案例：配置管理在软件企业中的应用 (4)
软件配置管理(SCM)是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。SCM活动的目标就是为了配置管理是对产品进行标识、存储和控制，以维护其完整性、可追溯性以及正确性的学科。目的是使错误降为最小并最有效地提高生产效率。 1.维护和编制公司配置管理规划、流程和策略。 2.负责日常运行维护及系统优化，负责配置管理工作，包括权限分配、基线管理、版本管理、变更管理、配置审计等;负责配置管理报告的编写和分析。 3.监督和审核项目过程中配置管理规范的实施情况,为项目组提供配置管理流程、工具方面的咨询、培训和支持，参与公司产品及体系认证与维护工作 4.负责建立和优化公司配置管理的相关规范和流程并进行相关推广。 不断优化公司配置管理方法和工具 (1)定义配置项：软件配置项(SCI)即软件配置管理的对象。软件开发过程中产生的所有信息构成软件配置，它们是：代码(源代码、目标代码)以及数据结构(内部数据、外部数据)、文档(技术文档、管理文档、需方文档)、报告，其中每一项称为 (2)标识配置项：正确标识软件配置项对整个管理活动非常重要，对软件开发过程中的所有软件项目赋予唯一的标识符，便于对其进行状态控制和管理。 (3)定义基线：基线标志着软件开发过程一个阶段的结束，任一软件配置项，一旦形成文档并审议通过，即成为基线。基本的作用在于把各阶段的工作划分得更明确，使本来连续的工作在这些点上断开，以便检验和肯定阶段成果。 (4)定义软件配置库：软件配置库内容涵盖开发的全过程. 实施软件配置管理的优点 ?节约费用：缩短开发周期、减少施工费用 ?利于知识库的建立：代码对象库、业务及经验库 ?规范管理：量化工作量考核、规范测试、加强协调与沟通。
被访谈角色问题说明 -CMMI3 1）高层经理： 高层经理Sheet页内容； 2）EPG人员： 公共实践、OPD、OPF sheet页内容；3）培训管理员： 公共实践、OT sheet页内容。 4）项目经理： 公共实践、立项与结项、PP、PMC、 IPM、RSKM、MA、REQM、VER、DAR sheet页内容。 5）需求人员： 公共实践、RD、REQM、VER、DAR sheet 页内容； 6）设计开发人员： 公共实践、TS、VER、DAR、PI sheet 页内容； 7）测试人员： 公共实践、VAL、VER sheet页内容；8）配置管理员： 公共实践、CM、VER sheet页内容；9）QA人员： 公共实践、PPQA、VER sheet页内容。CMMI3级过程域(PA)： 过程管理 1、OPD：（Organizational Process Definition）组织级过程定义。建立和 维护有用的组织过程资产。2、OPF：（Organizational Process Focus） 组织级过程焦点。在理解现有过程强 项和弱项的基础上计划和实施组织过 程改善。 3、OT：（Organizational Training）组织培 训管理。增加开发人员的技能和知识， 使他们能有效地执行他们的任务。 项目管理 4、PP：（Project Plan）项目计划。保证在 正确的时间有正确的资源可用。为每 个人员分配任务。协调人员。根据实 际情况，调整项目。 5、PMC：（Project Monitoring and Control） 项目监督与控制。通过项目的跟踪与 监控活动，及时反映项目的进度、费 用、风险、规模、关键计算机资源及 工作量等情况，通过对跟踪结果的分 析，依据跟踪与监控策略采取有效的 行动，使项目组能在既定的时间、费 用、质量要求等情况下完成项目。 6、SAM：（Supplier Agreement Management）供应商协议管理。旨在 对以正式协定的形式从项目之外的供 方采办的产品和服务实施管理。 7、IPM：（Integrated Project Management） 集成项目管理。根据从组织标准过程 剪裁而来的集成的、定义的过程对项 目和利益相关者的介入进行管理。 8、RSKM：（Risk Management）风险管理。 识别潜在的问题，以便策划应对风险 的活动和必要时在整个项目生存周期 中实施这些活动，缓解不利的影响， 实现目标。 工程管理 9、REQM：（Requirements Management） 需求管理。需求管理的目的是在客户 和软件项目之间就需要满足的需求建 立和维护一致的约定。 10、RD：（Requirement Development） 需求开发。需求开发的目的在于定义 系统的边界和功能、非功能需求，以 便涉众（客户、最终用户）和项目组 对所开发的内容达成一致。 11、TS：（Technical Solution）技术解 决方案。在开发、设计和实现满足需 求的解决方案。解决方案的设计和实 现等都围绕产品、产品组件和与过程 有关的产品。 12、PI：（Product Integration）产品集 成。从产品组件组装产品，确保集成 产品功能正确并交付产品。 13、VER：（Verification）验证。验证 确保选定的工作产品满足需求规格。 14、VAL：（Validation）确认。确认证 明产品或产品部件在实际应用下满足 应用要求。 支持管理： 15、CM：（Configuration Management） 配置管理。建立和维护在项目的整个 软件生存周期中软件项目产品的完整 性。 16、PPQA：（Process and Product Quality Assurance）过程和产品质量保 证。为项目组和管理层提供项目过程 和相关工作产品的客观信息。 17、MA：（Measurement and Analysis） 测量与分析。开发和维持度量的能力， 以便支持对管理信息的需要，作为改 进、了解、控制决策。 18、DAR：（Decision Analysis and Resolution）决策分析与解决。应用正 式的评估过程依据指标评估候选方案， 在此基础上进行决策。 总结CMMI3级的几个重要特点： 1) 明确规定了需求开发、设计、编码、 测试、集成等软件开发各过程的要求。 2) 对项目管理提出了更高的要求，要利 用组织级的数据来管理项目。 3) 出现了专门针对组织级的PA，要求有 专门的组织来负责过程改进的工作。 4) 提供了一个做出最佳决策的指导，而 这个方法可以用于软件工程，也可以用于 组织级过程改进。 注意：本次评估中只包含除SAM（Supplier Agreement Management）供应商协议管理 外的17个过程域。 SG：特定目标 SP：特定实践 立项管理文档立项管理（Project Initialization Management,PIM）的目的是：（1）采纳符合 机构最大利益的立项建议被采纳，避免浪费机构 的人力资源、资金、时间等。 【√设计】TS-技术解决方案 【√设计】DAR-决策分析与解决 【√设计、开发】VER(同行评审)-验证 【√开发】PI-产品集成
配置管理流程规定 (Ver1.0) 拟制：___________________ 审核：___________________ 签发：___________________
目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)
1.配置管理流程 1.1概述 规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图
1.3软件需求分析阶段 参加需求分析会议，配置管理负责人记录，有关文档提交归档。如《需求分析》。 1.4软件设计阶段 参加设计阶段，为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 1.5制定配置管理计划 配置管理员制定配置管理计划，主要内容包括配置管理软硬件资源、配置项计划、备份计划等，审批该计划。 1.6配置库管理 配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限 项目经理： 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划，并按相关规定贯彻执行； 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求； 5)提出管理管理的建议和要求。 配置管理员 1)编制配置管理计划； 2)执行配置项管理； 3)执行版本控制和变更控制方案； 4)编制配置状态报告； 5)配置库的建立和权限分配； 6)配置管理工具的日常管理与维护； 7)配置库的日常操作和维护 开发人员
软件开发项目影响进度因素及控制浅谈 一、影响软件开发项目进度的因素 要有效地进行进度控制，必须对影响进度的因素进行分析，事先或及时采取必要的措施，尽量缩小计划进度与实际进度的偏差，实现对项目的主动控制。软件开发项目中影响进度的因素很多，如人为因素、技术因素、资金因素、环境因素等等。在软件开项目的实施中，人的因素是最重要的因素，技术的因素归根到底也是人的因素。软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。常见的问题有以下几种情况： 1、80-20原则与过于乐观的进度控制 80-20原则在软件开发项目进度控制方面体现在：80%的项目工作可以在20%的时间内完成，而剩余的20%的项目工作需要80%的时间。这个80%的项目工作 不一定是在项目的前期，而可能是分布在项目的各个阶段，但是剩余的20%左右的项目工作大部分是在后期。所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉，使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。有些领导看到软件交付给用户了，就一块石头落地“总算交差了”，同时又可能撤出一些被认为不必要的人力资源。但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。这样的结果是拖延了后期的工作，同时如果软件还不成熟的话，会给用户造成不好的影响。 2、范围、质量因素对进度的影响
软件开发项目比其他任何建设项目都会有更经常的变更，大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧，用户是想改就改，造成需求的蔓延，项目经理有时还不知如何拒绝，加上要说“我能”的心理因素，一般都会答应修改。这样集少成多，逐渐影响了项目进度。 如果某项工作在进度上表面上达到目标了，但经检验其质量没有达到要求，则必然要通过返工等手段，增加人力资源的投入，增加时间的投入，实际上是拖延了进度。不管是从横向或纵向来看，部分任务的质量会影响总体项目的进度，前面的一些任务质量中会影响到后面的一些任务质量。 3、资源、预算变更对进度的影响 资源，最主要的还是人力资源，有时某方面的人员不够到位，或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。还有一个很重要的资源，就是信息资源，如某些国家标准、行业标准，用户可能提供不了，而是需要去收集或购买，如果不能按时得到，就会影响需求分析、设计或编码的工作。其他资源，如开发设备或软件没有到货，也会对进度造成影响。 预算其实就是一种资源，它的变更会影响某些资源的变更，从而对进度造成影响。 4、低估了软件开发项目实现的条件
软件过程与软件管理课程复习题 (一)解释相关概念或术语 1)软件工程 ●是指导软件开发和维护的工程类学科，它以计算机科学理论及其他相关学科的理论为指导，采用工程化的概 念、原理、方法和技术，进行软件的开发和维护，并与经过时间证明正确的管理方法与措施相结合，以较少的代价获取高质量的软件。 ●The IEEE Computer Society：是(1) 将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过 程，即将工程化应用于软件中。(2) 对(1)中所述方法的研究。 2)软件过程 ●软件过程是指软件开发人员开发和维护软件及相关产品（如项目计划、设计文档、代码、测试用例、用户手 册等）的一套行为、方法、实践及变换过程 ●根据IEEE对软件过程概念的解释，软件过程涵盖了软件采购、软件开发、软件维护、软件运行、软件获取、 软件管理、软件支持等7大类的软件活动 ●ISO12207分别将这些活动归结为基本过程、支持过程和组织过程等3大类 3)软件过程工程 为建造软件过程所进行的一系列工程化活动，包含如下基本活动：过程定义、过程例化、过程模拟、过程运作。 现代软件工程=软件项目工程+软件过程工程，这标志着软件过程的时代的到来。 4)软件配置管理 SCM是标识和确定系统中配置项的过程，在系统整个生命周期内控制这些项的投放和变动，记录并报告配置的状态和变动要求，验证配置项的完整性和正确性（GB/T11457-1995软件工程术语）。 针对SCM在软件生命周期各阶段所起的作用，一个完整的SCM环境要求具有版本控制、变更管理、状态统计、和配置审计的功能。 5)CMM CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM 的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。 6)CMM中的关键过程域 每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程方面，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域。 ●确定了实现一个成熟度级别所必须解决的问题 ●处于级别3的机构，必须解决级别2和级别3的所有关键过程域中的问题 ●每个关键过程域都确定了一套相应的活动，完成了这些活动，就达到了被认为是对改进过程非常重要的一组 目标 ●目标说明了每个关键过程域的范围、界限和意义 ●对于满足关键过程域的机构，一个关键过程域的所有目标都必须实现 ●每个关键过程域的目标总结了它的关键实践 7)CMM中的关键实践 是指关键过程域种的一些主要实践活动。每个关键过程域最终由关键实践所组成，通过实现这些关键实践达到关
软件过程改进与管理 The pony was revised in January 2021
软件过程改进与C M M I 第一章绪论 本课题研究的背景 21世纪是信息社会高速发展的世纪，软件作为信息技术的核心，将在其中起着至关重要的作用。随着信息经济、网络经济和科学技术的发展，各行各业已经越来越离不开软件的支持，软件产业的发展，各行各业已经越来越离不开软件的支持，软件产业的发展水平已经成为衡量信息技术发展水平的一个重要因素。 自出现软件危机以来，学术界和企业界对软件工程的研究都倾注了大量的人力、物力和财力，多年来也取得了一些成效。但就全世界而言，软件质量问题仍然非常严重，特别对于军方来说，更是一个致命的问题。正因为如此，美国国防部不惜花费重金，委托美国卡内基梅龙软件工程学院(SEI)研究制定软件质量保证规范。1991年，第一个软件保证规范能力成熟度模型(CMM:Capabiliy Maturity Model)制定完成并在美国应用，随后CMM作为一种软件能力成熟度评估标准在全世界推广实施，主要用于指导软件开发过程改进软件管理能力的提高，从而极大地提高了软件项目的控制能力和软件产品的质量，促进了全世界软件产业的健康发展。 CMM的应用虽然得到了很好的成效，但也存在一些缺陷，能力成熟度模型集成(CMMI:Capability Maturity Model Integration)应运而生，它是在CMM基础之上的发展和完善，2002年SEI正式推出CMMI,2005年开始逐步取代CMM. 从我国软件产业的发展现状来看，企业管理软件过程的能力还比较弱，过程混乱使得新技术、新工具的优势难以体现。究其原因，是因为我国的软件过程管理缺乏规范化和标
C M M文件软件配置管理过程 XXXXXXXXXXXX (版权所有,翻版必究)
文档变更请求(DCR)
文档变更记录
目录 1 概述 (1) 1.1 目的 (1) 1.2 范围 (1) 1.3 术语与定义 (1) 1.4 参考文档 (1) 1.5 引用文档 (2) 2 过程目标 (2) 3 过程定义 (2) 3.1 责任人 (2) 3.2 输入 (3) 3.3 入口准则 (3) 3.4 过程活动 (3) 3.5 出口准则 (6) 3.6 输出 (6) 附录 A ：软件配置项/产品包标识 (8) A.1 文档的编号 (8) A.2 程序的名称 (9) A.3 软件产品包的标识 (9) A.4 系统、数据库、开发与支持软件工具的编号 (9) 附录 B ：配置项状态报告 (10) B.1 系统软件、数据库、开发与支持软件工具列表 (10) B.2 软件基线/配置项状态报告 (10) B.3 软件基线软件基线变更报告 (10) 附录 C ：软件配置管理测量报告 (11)
1概述 1.1目的 软件配置管理（简写为SCM）是维护项目软件整个生命周期产品完整性的重要活动，本文档明确规定了公司软件配置管理活动的目标和过程定义，为公司软件配置管理提供所遵循的过程、程序和指导方针。 1.2范围 本文档适用于管理公司所有软件项目在各阶段标识的软件配置。软件配置管理的大部分活动用“软件配置管理工具”实现。 1.3术语与定义 1.3.1软件工作产品：作为定义、维护或应用软件过程的一部分所生成的任何人工制品，包括过程描述、 计划、规程、计算机程序和相关文档，这些可能交付也可能不交付给顾客或最终用户。 1.3.2软件基线：软件配置项经软件验证、确认、评审和认定后，形成了软件基线，也就成了该阶段的一 个基准。下一个阶段只能在这个基准上进行开发活动。 1.3.3软件配置项：是指一个软件产品在软件生存周期各个阶段所产生或应用的各种形式（机器可读或人 工可读）和各种版本的文档、程序及其数据。 1.3.4SCCB：软件配置管理委员会（Software Configuration Control Board）（关于责任，参见“责任 人”）。 1.3.5SCM：软件配置管理(Software Configuration Management) 包括了标识软件工作产品、控制对 软件工作产品的更改、和维护在整个软件生存周期中的软件工作产品的完整性和可跟踪性。 1.4参考文档 1.4.1Mark C. Paulk，Bill Curtis，Mary Beth Chrissis，Charles V. Weber，Capability Maturity Model for Software （Version 1.1） 1.4.2Roger S. Pressman，Software Engineering –A Practitioner’s Approach (Fourth Edition) 1.4.3《计算机软件配置管理计划规范》GB/T 12505-90
软件项目成果的需求分析方和软件项目的承担者都十分关心这样的一个问题：什么样的因素会导致软件项目的失败？与项目有关的因素的改变将对按时、按经费预算交付符合预定质量要求的软件成果产生什么样的影响？这些都属于软件项目开发过程中考虑的风险问题。 软件项目的风险是指在软件开发过程中可能出现的不确定因而造成损失或者影响，如资金短缺、项目进度延误、人员变更以及预算和进度等方面的问题。风险关注未来的事情，这意味着，软件风险涉及选择及选择本身包含的不确定性，软件开发过程及软件产品都要面临各种决策的选择。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。另一方面，风险将涉及思想、观念、行为、地点等因素的改变。 软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。因此有必要对软件项目中的风险进行分析并采取相应的措施加以管理，尽可能减少风险造成的损失。风险是在项目开始之后才对项目的执行过程其负面的影响，所以软件项目开始之前风险分析的不足，或者是软件项目实施过程中风险应对措施不得力，都有可能造成软件失败。 如果对项目进行风险管理，就可以最大限度的减少风险的发生。它是为了将不确定因素出现的概率控制到最低，将不确定性所造成的损失减少到最低限度，对软件项目全过程中的风险识别、分析和应对的过程。在整个软件项目的实施过程中，可能形成项目风险的因素有很多，如在项目启动阶段可能存在项目目标不明确，与用户沟通少导致项目范围不明确等分先因素；在系统设计阶段可能因为缺乏有经验的分析人员、设计人员导致和设计的结果不能直接用于程序员的开发；在项目实施阶段可能因为开发环境没有准备好，程序员开发能力差，或者因为用户提出新的功能需求导致原有设计实效、开发费用超支，还有可能因为开发人员的流动导致项目延期，客户不满意等情况。 软件项目运用专家调查法和头脑风暴法分析软件开发项目中，并将其进行整理分类。 由于与客户沟通不畅对客户的需求了解不足造成的风险在软件开发项目整 个生命周期的中都存在的风险，主要包括需求变更风险，涉及风险，过程风险，安装及维护风险。 由于管理人员素质不够，经验不足，沟通不畅，任务或其分配不合理，对项目的控制力度不够造成的各种风险，主要包括进度风险，预算风险，管理能力风险，信息安全风险。 由于技术力量不足，开发环境工具不足造成的。主要包括技术风险，质量风险，软件设计工具风险，软件开发工具风险，员工技能风险。 由于公司或项目组内外部环境变化所导致的风险，主要包括人力资源风险，政策风险，市场风险，营销风险。 软件项目中的风险永远不能全部消除，而只能采用避免、减轻、和接受三种因对策略。 避免：通过分析找出发生风险事件的原因，消除这些原因来避免一些特定风险事件的发生。
XXXX软件项目过程改进年度计划 XXXX企业有限公司 ____年___月___日
文档信息 修改记录
目录 软件过程改进年度计划 (3) 1 引言 (3) 1.1 制定目的 (3) 1.2 项目背景 (3) 1.3 术语定义 (3) 1.4 参考资料 (3) 2 上一年度过程改进总结 (3) 2.1 与计划目标对比 (3) 2.2 工作量 (4) 2.3 过程改进效果 (4) 2.4 经验教训 (4) 3 改进目标 (4) 4 改进范围 (4) 5 角色与职责 (4) 5.1 过程改进领导小组 (4) 5.2 EPG组 (4) 5.3 QA组 (4) 5.4 其它 (4) 6 改进策略 (5) 7 进度计划 (5) 8 人力资源计划 (5)
9 沟通计划 (5) 10 QA计划 (5) 11 里程碑计划 (5) 12 过程改进项目列表 (5)
软件过程改进年度计划 1 引言 1.1 制定目的 说明编写本项目过程文件的目的，指出预期的读者 1.2 项目背景 1、待开发的系统名称 2、任务提出者、开发者、用户及实现系统的计算机中心或网络 3、该系统同其他系统或其他机构的基本的相互关系 1.3 术语定义 本文件中用到的专门术语的定义和外文首字母组词的原词组并解释 1.4 参考资料 1、本项目经核准的计划任务书、合同、上级批文等 2、属于本项目的其他已发表的文件 3、本文件各处引用的文件、资料包括所需用到的软件开发标准等 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些资料的来源 2 上一年度过程改进总结 2.1 与计划目标对比
软件配置管理流程
目录 1.配置管理流程 (3) 1.1 概述 (3) 1.2 总体流程图 (3) 1.3 软件需求分析阶段 (4) 1.4 软件设计阶段 (4) 1.5 制定配置管理计划 (4) 1.6 配置库管理 (4) 1.6.1 相关人员分配权限 (4) 1.6.2 配置项 (5) 1.7 版本控制 (6) 1.8 变更控制 (6) 1.9 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9)
1.配置管理流程 概述 规范配置管理活动,明确配置项正确的唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 总体流程图
软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 软件设计阶段 参加涉及阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本于需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 相关人员分配权限 项目经理： 1）与（有关负责人员）协商确定项目起始基线； 2）接受配置管理计划，并按相关规定贯彻执行； 3）接受配置控制委员会的报告； 4）提出配置管理计划的修改要求； 5）提出管理的建议和要求。 配置管理员 1）编制配置管理计划； 2）执行配置项管理； 3）执行版本控制和变更控制方案； 4）编制配置状态报告； 5）配置库的建立和权限分配； 6）配置管理工具的日常管理与维护； 7）配置库的日常操作和维护； 开发人员 1）根据确定的配置管理计划和相关规定，提交配置项
浅谈软件开发过程中的方法问题 摘要：先进的制造模式要求信息集成和功能集成贯穿于产品生命周期的每一阶段，功能的集成需要软件系统的支持，从而推动先进制造模式的实现。软件开发过程是建造软件解决方案的关键要素。本文详细讨论了两类主要的过程开发方法，即面向对象方法和结构化方法。 关键词：软件开发过程；面向对象方法；结构化方法methodological issues in the process of software development xia xue (beijing elite creation technology co.,ltd.,beijing100081,china) abstract:advanced manufacturing model requires information integration and functional integration throughout the product life cycle at every stage of the functional integration needs the support of the software system,thus promoting the realization of advanced manufacturing mode.the software development process is a key element of construction software solutions.this paper discusses the two main types of process development methods,object-oriented methods and structured methods.
软件过程与软件管理课程复习题 一．解释相关概念或术语 1.软件过程： 软件过程是指软件开发人员开发和维护软件及相关产品（如项目计划、设计文档、代码、测试用例、用户手册等）的一套行为、方法、实践及变换过程。 软件过程涵盖了软件采购、软件开发、软件维护、软件运行、软件获取、软件管理、软件支持等7大类的软件活动。 2.软件过程工程： 为建造软件过程所进行的一系列工程化活动。软件过程工程的基本活动包括过程定义、过程例化、过程模拟、过程运作。 3.软件配置管理： SCM是标识和确定系统中配置项的过程，在系统整个生命周期内控制这些项的投放和变动，记录并报告配置的状态和变动要求，验证配置项的完整性和正确性（GB/T11457-1995软件工程术语）。 针对SCM在软件生命周期各阶段所起的作用，一个完整的SCM环境要求具有版本控制、变更管理、状态统计、和配置审计的功能。 4.CMM中的关键过程域： 每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程方面，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域。 5.CMM中的关键实践： 是指关键过程域种的一些主要实践活动。每个关键过程域最终由关键实践所组成，通过实现这些关键实践达到关键过程域的目标。一般情况下，关键实践描述了该“做什么”，但没有规定“如何”去达到这些目标。 6.CMM中的SEPG： 软件工程过程组（Software Engineering Process Group）由专家组成，统领CMM 实施活动，协调全组织软件过程的开发和改进活动，制定、维护和跟踪与软件过程开发和改进活动有关的计划，定义用于过程的标准和模板，负责对全体人员培训有关软件过程及其相关的活动。 https://www.doczj.com/doc/3b9421475.html,DP/RUP： USDP（Unified Software Development Process，统一软件开发过程）是一种基于构件的，用况和风险驱动的，以构架为中心，迭代和增量式的开发过程。分为初始、细化、构造、移交四个阶段。 RUP（Rational Unified Process，统一软件开发过程，统一软件过程）是一个面向对象且基于网络的程序开发方法论。根据Rational(Rational Rose和统一建模语言的开发者)的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。RUP和类似的产品——例如面向对象的软件过程（OOSP），以及OPEN Process都是理解性的软件工程工具--把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。 8.SWEBOK： 软件工程知识体(SWEBOK)提出五个目的：(1)促进软件工程业界统一看法；(2)划定学科边界，澄清软件工程的学科地位；(3)刻画软件工程的学科内容；(4)提出访问SWEBOK的论题(知识点)；(5)为个人认证、申请执照、课程体系制定提供基础。