软件项目的范围管理浅析
软件工程项目范围管理

软件工程项目范围管理软件工程项目范围管理是软件开发过程中非常重要的一环。
它旨在确保软件项目在开发过程中能够明确定义和控制项目的范围,以确保项目能够按时完成、以预期的质量交付。
一、引言软件工程项目范围管理是软件开发项目的关键过程之一。
它涉及到对项目范围进行规划、定义、验证和控制,以确保项目的交付能够满足客户的需求和期望。
本文将介绍软件工程项目范围管理的重要性以及范围管理的过程和技术。
二、软件工程项目范围管理的重要性范围管理在软件工程项目中具有重要的作用。
一个没有明确定义和控制的项目范围很容易陷入项目进度延误、成本超支和质量问题等困境。
通过对项目的范围进行管理,可以帮助团队明确项目目标,减少项目风险,提高项目的成功率。
三、范围管理过程范围管理过程主要包括以下几个方面:1. 范围规划范围规划是在项目启动阶段对项目范围进行规划和定义的过程。
这包括明确项目的目标和需要实现的功能,以及定义项目团队的职责和任务分工。
范围规划还需要与项目的相关方进行沟通和协商,以获取他们对项目范围的认可和支持。
2. 范围定义范围定义是明确定义项目范围的过程。
这包括明确项目的边界、功能需求和非功能需求。
对于复杂的软件项目,可以采用工具和技术如需求分析和用户故事来帮助明确范围。
范围定义的结果通常是一个范围说明书,它包含了项目的详细需求和范围界定。
3. 范围验证范围验证是确保项目交付符合客户要求和期望的过程。
这包括与客户和其他相关方进行验收测试和确认,以确保项目的交付物完全满足需求规定。
范围验证还包括对交付物进行功能和性能测试,并确保符合软件标准和规范。
4. 范围控制范围控制是在项目执行过程中对项目范围进行控制和管理的过程。
这包括变更管理、配置管理和风险管理等方面。
范围控制的目标是确保项目在范围内按时完成,并及时处理范围相关的变更和风险。
四、范围管理的技术和工具范围管理过程中可以使用一系列的技术和工具来辅助管理范围。
以下是一些常用的技术和工具:1. 工作分解结构(WBS)WBS是一种将项目分解为可管理的工作包的方法。
软件工程中的软件工程项目范围与变更管理

软件工程中的软件工程项目范围与变更管理在软件工程中,项目范围与变更管理是项目管理过程中至关重要的一部分。
它涉及到确定项目的范围和目标,以及在项目执行过程中管理和控制变更。
本文将探讨软件工程项目范围与变更管理的概念、方法和最佳实践,并提供几个案例来说明其重要性和应用。
软件工程项目范围管理是指在项目开始之前明确和定义项目的范围和目标,确定项目交付的具体内容,以及界定项目的边界。
它涉及到识别需求、定义项目任务、界定项目目标和交付物等一系列活动。
范围管理的目标是确保项目交付的结果符合客户的期望,并保证项目能够按时、按质量完成。
范围管理的主要步骤包括需求收集和分析、项目任务分解和工作分解结构(WBS)的制定、范围确认和范围控制。
需求收集和分析是通过与客户、用户和利益相关者的沟通,收集并分析相关的需求信息。
项目任务分解和WBS的制定是将项目任务逐步细化,形成一个具体的工作分解结构。
范围确认是在项目启动和计划阶段与客户和用户确认项目的范围和目标。
范围控制是在项目执行过程中,通过变更管理来管理和控制项目范围的变化。
软件工程项目变更管理是指在项目执行过程中,管理和控制项目范围的变化。
由于项目的范围和需求可能随着时间的推移而发生变化,变更管理是确保项目能够适应变化的重要手段。
变更管理包括变更请求的收集和评估、变更的批准和实施、以及对变更的控制和监督。
变更管理的主要步骤包括变更请求的收集和评估、变更的批准和实施、以及变更的控制和监督。
在变更请求的收集和评估阶段,项目团队需要对变更请求进行评估,包括评估变更的影响、成本和风险等方面。
然后,根据评估结果,决定是否批准变更。
如果批准变更,变更将被实施,并进行必要的控制和监督。
范围和变更管理在软件工程项目中具有重要意义。
首先,它能够帮助项目团队明确项目的范围和目标,以及交付物的具体内容。
这有助于确保项目的可交付成果符合客户的期望,并能够满足项目的目标和需求。
其次,范围和变更管理能够帮助项目团队管理和控制项目的变化。
如何进行软件项目的范围管理

如何进行软件项目的范围管理在软件项目管理中,范围管理是确保项目按时完成的关键要素之一。
范围管理涉及到识别、定义和控制项目范围,以确保项目交付符合客户的需求和期望。
本文将介绍如何有效进行软件项目的范围管理。
一、需求分析在项目开始之前,进行详细的需求分析是范围管理的首要任务。
需求分析包括明确项目的目标、功能、约束条件和实施计划。
通过与客户和利益相关方的沟通,收集他们的需求并明确期望,以便确定项目的范围。
二、制定项目范围说明书根据需求分析的结果,制定项目范围说明书是范围管理的重要步骤。
项目范围说明书应该清晰地描述项目的目标、范围、可交付成果,以及排除在外的工作内容。
此外,项目范围说明书还应包括时间、成本和质量的约束条件,以确保项目在可接受的范围内完成。
三、范围分解范围分解是将项目工作分解为更小、更具体的任务的过程。
通过范围分解,可以将项目范围划分为一系列可管理的工作包或任务,以便更好地安排资源和控制进度。
范围分解可以使用工作分解结构(Work Breakdown Structure,简称WBS)图来展示,将项目工作划分为层次结构,从总体任务到更具体的子任务。
四、制定变更控制过程在项目执行过程中,客户或利益相关方可能会提出变更请求。
为了控制项目范围的变化,需要制定变更控制过程。
变更控制过程应包括变更请求的收集、评估和决策。
所有变更请求都应记录在变更请求登记册中,并经过审查和批准后,方可进行实施。
变更控制过程的目的是确保项目范围的变化是有根据的、可控制的,以避免无限制的范围增加导致项目延期或超出预算。
五、验证和确认项目成果在项目完成之前,需要对项目交付的成果进行验证和确认,以确保其符合客户的需求和期望。
通过与客户和利益相关方的沟通,核实项目的可交付成果是否满足项目范围说明书中的要求。
验证和确认项目成果需要进行严格的测试和评估,以确保软件的功能和性能达到预期标准。
六、范围管理工具和技术为了支持软件项目的范围管理,可以采用一些工具和技术。
软件项目管理-目标和范围管理

项目范围管理---范围计划编制---输出
2.详细依据.范围说明的详细依据应当被适当地组织并形成文 档,以使其能够被其他项 目管理的过程使用.详细依据应当包 括所有确定的假定和约束条件的文档.详细依据的数量 随着应 用领域的不同而变化.
3.范围管理计划.此文档描述项目范围是如何被管理的,以 及项目范围的变更是如何被集成到项目中去的.
WBS组织并定义了整个项目范围,未列入工作分解结构 的工作将排除在项目范围之外。
工作分解结构是组织管理工作的主要依据,是项目管理 工作的基础。因此,从某种程度上讲,WBS是项目管理 的骨架。
工作分解结构图
工作分解结构是将项目按照其相关构成随层 进行工作分解的一种方法。
它可以将一个项目逐层分解到工作内容单 一、便于进行组织管理的单项工作,并能把 各单项工作在整个项目中的地位、构成直观 的表示出来。
项目目标定义
(1)项目目标:简单地说就是实施项目所要达到的期望结果。
(2)项目与常规活动的主要区别在于,项目通常是具有一定期望 结果的一次性活动,任何项目都是要解决一定的问题,达到合理 的目标。日常重复性的工作、没有明确起始时间和结束时间的事 情、通用的词语不能确定是项目。要根据项目定义和项目特性来 判断某件事情是否可以称得上是否为项目。
修改外购软件包
□
○
开发 修改内部程序 修改手工操作系统程序
□
○
□
○
测试外购软件包
□
测试 测试内部程序 测试手工操作系统流程
□
□
4.专家评定.
项目范围管理---范围计划编制---输出
1.范围说明.范围说明在项目干系人之间确认或建立 一个对项目范围的共识,作为未来项目决策的文档基 准,随着项目进展,项目范围说明可能需要根据项目 范围的变更而进行修改或者细化.范围说明应当直接 或通过参见其他文档如下内容:
04-软件项目范围管理

软件项目管理
3
1. 项目范围管理的过程
▪ 项目启动后,要清晰地确定项目范围,形成项目 规格说明,明确阐明项目的范围特征。在制定项 目范围管理计划时,一定要界定清楚项目的分工 界面,以防在项目实施时责任不清。
▪ 项目范围的界定,不能代表项目范围是可控的。 还需要对项目范围进一步细化,使之具体化、层 次化,从而达到可管理、可控制、可实施的目的。 这就需要建立工作分解结构WBS (Work Breakdown Structure)。
3) 项目范围定义:将项目划分为一些较小的更 好管理的组成部分。这个过程的工作成果是 提交一个工作分解结构WBS
(Work Breakdown Structure)。
软件项目管理
6
4) 项目范围核实:对经过分解的项目范围进行 正式的确认。主要项目干系人,如客户、项 目发起人等要对项目可交付成果的定义给予 正式的审核和确认。
10
▪ 项目通常是有一定期望结果的一次性活动,它 有确定的起点和终点,并且任何一个具体项目 都要解决一定的问题,达到一定预期的合理目
标。
1) 项目目标的多样性:在一个项目中,目标往 往不是单一的,而是多个目标交织的。各种 目标之间可能有冲突。因此,在项目实施过
程中,要注意在同一层次中不同目标的协调 以及在不同层次中总目标和子目标的协调。
预算 成本
12
2) 项目目标的优先性:项目的不同目标,在项 目管理的不同阶段,根据不同的需要,其重 要性可能会不同,关注的重点也会不同。例 如,在项目的启动阶段,可能给予技术性能 以较多的关注;在实施阶段,成本将成为重 点;在验收时,对时间进度将给予高度的重 视。
3) 项目目标的层次性:项目的目标可以有一个 从抽象到具体的逐层细化的层次结构。例如, 一个 ERP 项目,大项目目标是 6 个月完成一 个 ERP 系统的开发,在下层可能有网络、分 布式数据库等子目标。
软件项目管理(三):软件项目范围管理

软件项⽬管理(三):软件项⽬范围管理项⽬范围对项⽬的影响是决定性的,它确定了软件项⽬⼯作内容的多少。
有效的范围管理可以保证项⽬只做必须做的事情,避免范围蔓延和做⽆⽤功,同时也避免不清晰的需求所导致的严重的系统缺陷1. 需求获取⼯作的任务就是收集项⽬⼲系⼈的需求信息,为定义项⽬的范围奠定基础。
2. 需求获取⼯作只能通过⽤户与开发⼈员之间进⾏⾼度的合作和交流才能成功。
3. 在软件项⽬的需求获取活动中,⼀般要收集以下类别的⽤户需求:(1)界⾯需求:描述软件系统的外部特性,即系统如何从外部得到数据输⼊,如何向外部输出数据。
(2)功能需求:列出软件系统必须完成的所有功能。
(3)性能需求:响应时间、吞吐量、处理时间、存储空间等⽅⾯的限定。
(4)质量需求:对安全性、保密性、可靠性、可维护性、可移植性、易⽤性等⽅⾯的要求。
(5)资源使⽤需求:对硬件、⽀持软件、数据通信接⼝等⽅⾯的要求。
(6)软件成本消耗与开发进度需求:即对时间和经济⽅⾯的要求。
(7)异常处理要求:在运⾏过程中出现异常情况 ( 如临时性或永久性的资源故障,不合法或超出范围的输⼊数据、⾮法操作等 ) 时应采取的⾏动以及希望显⽰的信息。
4. 获取需求的常⽤⽅法( 1 )访谈。
访谈是通过与⼲系⼈直接交谈来获取信息。
访谈的典型做法是向被访者提出问题,并记录他们的回答。
访谈经常是⼀个访谈者和⼀个被访者之间的⼀对⼀谈话,但也可包括多个访谈者或多个被访者。
访谈有经验的项⽬参与者、发起⼈、以及主题专家,有助于识别和定义项⽬可交付成果的特征和功能。
( 2 )讨论会。
讨论会把主要项⽬⼲系⼈召集在⼀起,通过集中讨论来定义项⽬需求。
讨论会是快速定义跨职能需求和协调⼲系⼈差异的重要⽅法。
由于群体互动的特点,被有效引导的讨论会有助于参与者之间建⽴信任、改善关系、改进沟通,从⽽有利于⼲系⼈达成⼀致意见。
在每次讨论会中,都必须记录所讨论的内容,并在会后加以整理。
在会前应提前发给参加⼈员有关讨论会的议题和内容等材料,以便有所准备。
软件工程中的软件工程项目范围管理与控制

软件工程中的软件工程项目范围管理与控制软件工程项目范围管理与控制是软件开发过程中至关重要的一部分,它涉及到项目的定义、规划、追踪和控制,对于确保项目的成功和交付高质量的软件产品起到了关键作用。
本文将重点探讨软件工程项目范围管理与控制的重要性、过程和方法以及面临的挑战。
一、软件工程项目范围管理的重要性软件工程项目范围管理是确保项目成功的基石,它涉及到项目的定义、确定项目目标和交付成果的过程。
范围管理能够帮助项目团队定义项目的边界,明确项目的目标和需求,避免项目范围的蔓延和需求的不明确,从而保证项目交付的成果符合预期。
范围管理还能够帮助项目团队合理分配资源,制定项目计划,确保项目按时交付。
二、软件工程项目范围管理的过程和方法1. 项目定义在项目开始之前,需要对项目进行明确的定义,明确项目的目标、范围、交付成果和相关利益相关者的期望。
项目定义阶段需要与项目相关的各方进行充分沟通,共同明确项目的需求和目标。
2. 需求分析需求分析是软件工程项目范围管理的核心环节,它涉及到对项目需求的收集、分析和验证。
在需求分析阶段,需要与利益相关者进行沟通,明确项目的功能需求和非功能需求,并将其转化为明确的需求规格说明。
3. 范围规划范围规划是根据项目的需求和目标,制定项目的范围管理计划和项目计划。
在范围规划阶段,需要细化项目的工作分解结构(WBS),明确各个工作包的内容和交付成果,确保项目的可管理性和可交付性。
4. 范围控制范围控制是对项目范围进行监控和调整,确保项目按照计划进行和交付预期的成果。
在范围控制阶段,需要进行变更管理,及时处理范围变更请求和风险,确保项目的进展和交付的质量。
三、软件工程项目范围管理面临的挑战软件工程项目范围管理面临着一系列的挑战,如需求变更、范围蔓延、沟通不畅等。
这些挑战可能导致项目交付的延迟、质量下降甚至项目失败。
为了克服这些挑战,项目团队需要通过以下方法和技术来增强范围管理的效果:1. 紧密合作项目团队成员之间需要紧密合作,充分沟通,确保项目的范围和需求得到准确理解和落实。
软件项目范围管理

软件项目范围管理简介软件项目范围管理是项目管理中的关键过程之一,用于确定项目的目标和交付物,确保项目在特定的时间、预算和资源范围内得到成功完成。
范围管理的目的是明确项目的边界和可交付成果,确保项目按照既定的目标和需求进行开发。
范围管理包括需求收集、范围定义、范围排除和范围控制等阶段,在整个项目生命周期中都起着重要的作用。
正确地管理项目范围可以帮助项目团队更好地控制项目进度和成本,减少变更请求和风险。
本文将介绍软件项目范围管理的重要性、步骤和常用工具,以及如何有效地进行范围管理。
软件项目范围管理的重要性范围管理有助于项目团队明确项目目标和交付物,并将其与项目需求和约束进行匹配。
通过范围管理,项目团队可以更好地控制项目进度、资源分配和成本管理,确保项目成功完成。
以下是软件项目范围管理的重要性:1. 清晰的项目目标和交付物通过范围管理,项目团队可以明确项目目标和可交付成果。
这有助于项目团队和利益相关者在项目初期就达成共识,并确保团队按照既定的目标和需求进行工作。
2. 控制项目进度和成本范围管理可以帮助项目团队更好地控制项目进度和成本。
明确的项目范围可以减少需求变更和范围蔓延,从而减少项目延期和成本超支的风险。
3. 减少变更请求和风险通过范围管理,项目团队可以更好地识别和管理需求变更和范围蔓延。
及时识别和评估变更请求可以减少项目风险,并避免团队陷入无限循环的变更请求中。
4. 有效的沟通和合作范围管理有助于项目团队和利益相关者之间的有效沟通和合作。
明确的项目范围可以帮助团队共同理解项目目标,并分工合作,提高项目团队的整体效率。
软件项目范围管理的步骤1. 需求收集在范围管理的第一步,项目团队需要收集和分析项目需求。
这包括访谈利益相关者、澄清需求和优先级,以及编写需求规格说明书。
需求收集是确保项目的基础,因此项目团队应该花足够的时间和精力来收集和理解项目需求。
2. 范围定义范围定义是明确项目的目标、可交付成果和任务分解的过程。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件项目的范围管理浅析乔玉东-3750902082012年12月27日摘要:范围管理是软件项目管理中的重要一环,项目的范围决定了项目的工作内容,有效的范围管理可以保证项目的顺利实施,避免范围蔓延和做无用功。
软件项目的复杂性,决定了项目的范围的不确定,范围变更频繁,更难驾驭。
关键词:计算机系统集成项目管理范围管理一,软件项目范围管理概述项目范围对项目的影响是决定性的。
项目只有完成项目范围内的全部工作才能结束,一个不明确的项目范围、或者项目干系人对项目范围理解的不一致,都会造成项目的不成功。
项目范围的不明确造成的结果是项目范围蔓延;对项目范围理解的不一致的结果是项目成果得不到项目业主的认可。
对于软件开发项目来说,需求理解的偏差会造成严重的系统缺陷,需求的不明确会在开发过程中不断的产生新的需求。
项目的业主不会接受一个没有满足要求的软件系统,软件开发团队只能不断地对自己的工作进行返工,项目的工期无限延长、项目的范围无限扩大、项目的成本不断超支、项目的产品质量无法控制……根据PMBOK2004定义的项目范围管理,包括五个基本过程:(1)范围规划——制定项目范围管理计划,制定范围控制规程,定义工作分解结构。
(2)范围定义——制定项目范围说明书,确定项目的工程量。
(3)制作工作分解结构——把项目的可交付成果与项目的工作划分为可控的组成部分,并分步实施。
(4)范围核实——对项目的产品进行交付验收。
(5)范围控制——严格控制项目的范围变更,防止项目的无限蔓延。
对于软件开发这种抽象性很强的项目来说,项目范围的确定是很困难的事情。
由于项目的业主和项目开发人员对软件系统的需求不明确,对需求的认知不统一,特别是业主与开发人员由于专业领域不同而造成的沟通障碍,使得开发人员对业主的隐性需求认知困难,这些问题造成的直接结果就是在项目实施过程中,会遇到各种各样的变更。
如果不能很好的管理、控制好这些变化,可能造成项目成本超支、项目进度拖延,让项目陷入混乱状态。
在软件项目中,软件系统的需求,与项目范围管理有着直接的关系。
首先,交付一个可以满足用户需求的软件系统是软件项目中最重要的工作之一。
因此,这个软件系统的功能特征就决定了主要的项目范围。
整个软件开发过程中包括需求分析、设计、编码、和测试工作,都是这个软件系统的项目范围之一。
与工程项目不同,软件开发项目范围中可能包括更多的内容。
比如很多软件项目中,交付物中会包括系统功能规格说明书、系统设计说明书、系统使用手册、使用培训等内容。
软件项目中,较难把握的部分就是软件系统的范围,或者说是软件系统的功能特性。
绝大多数软件项目的需求都有问题,每一个需求问题都带来不明确的项目范围。
软件本身的抽象性,使得对软件描述经常会有二义性和模糊性,而据此定义的系统范围也是模糊和不明确的,这也是软件项目中范围难以控制的重要原因。
二,范围规划很显然,要想做好项目的范围管理,首先就要有一个管理的规划,通常把这个规划称为项目范围管理计划。
软件项目范围规划的工作要点包括四个方面:1,如何确定详细的项目范围。
即需要采取什么样的方法、采用什么样的工具和过程来逐步得到详细的项目范围。
对于抽象的软件系统项目,确定精确的项目范围不是一件容易的事情,必须要有科学的方法。
需求工程拥有一套完整的理论体系,在需求开发方法中有许多成熟获取、分析需求的方法论,如用例分析等,项目经理需要结合具体的项目特点和环境来进行剪裁和取舍,制定出当前定义范围的方法。
范围定义的最终结果是项目范围说明书。
而软件项目中,是把用户需求或者系统规划说明书作为项目范围说明的主要文档,配合其他的文档共同说明项目的范围。
制定范围计划,需要考虑清楚如何综合需求说明书等文档,以清晰且详细地表述项目的需求。
2,如何根据详细的项目范围得到WBS在范围管理计划中关注的问题是采用什么样的过程和方法得到WBS。
WBS 是整个项目团队为完成项目目标,创造项目成果而进行的工作的有层次的结构分解。
WBS也表达了完整的项目范围,WBS的层次结构让项目的范围变得更加清晰、更容易管理。
3,如何验收已经交付的项目成果随着项目的开展,项目的产品——项目的可交付成果逐渐的完成,对产品的验收就摆在了台面。
软件开发项目的产品是抽象的,与工程项目的产品验收的方法也不同。
对需求分析、设计文档等验收,通常是组织专家进行评审来验收,而对于开发完成的系统,则采取测试的方法来进行验收。
三,软件产品的范围定义软件项目的目标是开发或实施某项软件系统或产品,软件系统的项目范围,也就表现为软件需求规格说明书。
软件需求规格说明书一般包括三方面的内容:一,功能特征的描述。
功能特征描述是指对系统功能的详细描述,即软件系统应该具有的功能,这些功能是怎么向使用者提供服务的。
功能特征的描述对于不同的软件系统,描述的内容也千差万别,但基本的重点描述应该考虑四个部分:(1)功能分层。
通过对系统功能特征分层处理,可以让功能特征更清晰,更易于管理和控制。
(2)文字描述尽量简洁。
对于难以描述,或者需要大篇幅文字说明的功能,充分利用图表的方式来表述,用简洁的语言把问题说清楚。
(3)考虑系统状态的变化。
软件系统的状态变化较为复杂,同样的功能在不同的系统状态下会呈现不同的特征。
这也要求在功能描述时,考虑到系统状态的特点,理清系统状态变化的规律。
二,系统接口的描述。
随着信息系统的快速发展,软件系统的接口数量也在快速的增长,需要描述系统接口的特征、类型、作用、连接标准等内容,这样便于清晰的划分系统的范围。
三,质量特征的描述。
系统的质量特征,也要在产品范围中进行定义和描述。
主要的质量特征包括:可靠性、可移植性、机密性和完整性。
四,范围的控制在软件开发的项目中,项目控制的目的是确保范围的变化处在可控制可跟踪的状态。
业界流行的“唯一不变的就是变化”这样的段子,也充分的说明了项目充满了各种各样的变化。
当项目发生变化时,也就意味着项目中需要做的工作发生了变化,这必然造成项目的进度计划、人员安排、项目的成本等一系列的变化。
如果项目的范围失控,可能使项目陷入混乱,增加项目的风险。
为了保证项目能够有条不紊的进行,消除范围变更造成的不利影响,在项目管理中,是通过范围的变更控制系统来完善的。
在范围控制过程中,要注意三点:(1)范围控制是必须的,不存在没有变化的项目。
为了避免范围变更的盲目性和不确定性,就一定要建立范围变更控制机制。
(2)项目范围的变化,并不总是意味着项目工作量的增加,项目范围的变化,也意味着更贴近用户的需求,更适应项目的环境,范围控制要做的是消除变更带来的不良影响。
(3)项目范围控制的目的不是阻止变更的发生。
项目范围控制的主要任务是,出现范围变更需求时,管理相关的计划、资源安排以及项目成果,使项目的各个部分能很好的配合在一起,消除变更带来的不利影响。
项目范围控制主要通过变更控制系统来完成的。
在软件项目中,系统需求构成了最主要的系统范围。
变更控制系统遵循“请求——评估审批——跟踪”的原则进行的。
首先,变更申请人提交变更请求,此后变更控制委员会CCB需要召集相关人员评估变更的范围和可能的结果,并确定是否执行该变更的决定,最后CCB将跟踪变更的执行。
在整个变更控制流程中,有四个角色在进行交互:(1)变更申请人:范围需求变更的发起者。
(2)变更责任人:任何变更都要落实到具体的工作当中,变更责任人就是变更的执行者。
(3)变更控制委员会CCB:CCB是变更控制系统的核心角色,任何变更需求,都必须经过CCB的审核和评估,决定是否执行变更,跟踪变更的过程,评估变更的结果。
(4)配置管理员:配置管理员管理系统的配置项。
通常情况下,描述系统范围的范围说明书以及项目的产品,都纳入了配置管理的范围,对这些配置项的存取,都必须通过配置管理员完成。
五,案例分析案例分析:2011年接到某集团公司的的一个备件管理信息系统的软件开发项目。
该公司在2003年实施了SAP的R/3系统ERP系统。
2007年,该集团自主开发了一套CMS管理系统。
由于该公司规模比较庞大,产品遍布全国,其旗下有三十多个营销子公司,其售后服务网络也遍布全国各个县镇。
该公司以前的备件管理一直纳入了R/3系统来管理,运行一直都很稳定。
其备件管理的模式是:当用户购买该公司的产品发生故障后,用户拨打该公司的统一服务电话或登录售后服务网站报修,公司客服通过CMS系统受理用户的报修,并根据该用户的的地理位置,将维修服务工单派发到所属分公司;分公司接到CMS的派单后,将工单下派到旗下的特约维修服务站,由特约维修站派技术人员上门去用户家维修。
技术人员在用户家中维修产品时,如果需要更换备件,则向所属的分公司请购,而分公司根据各个特约维修服务站的备件需求,统一做出备件请购计划,然后报给集团总部备件管理部,由备件管理部根据各个分公司的需求计划,进行统一采购,派发到各分公司,各分公司再将备件下发到各个下属维修服务站,服务站维修完毕后,登录CMS网站,填写工单信息和耗材物料。
集团有一个备件总仓,各分公司也有自己的备件仓库。
各特约服务站自己也备有一些常用的耗材。
当前备件管理的弊端:(1)备件流转时间长。
从用户报修,到备件下到维修站,时间周期最长可达一周,严重影响了用户对该公司产品的信誉。
(2)备件调配不均。
当分公司向总部备件管理部请购的备件,总仓没货,而其他分公司的备件仓却积存过多,而各分公司之间不能结算备件成本,因此也无法互通有无。
(3)管理成本增加。
由于各个分公司各有自己的仓库,备件的管理成本高,备件流转周期长。
开发SPM的基本需求:当各维修服务站发生备件需求时,登录SPM网站,填写备件需求表,提交需求表到SPM系统中,集团备件管理部根据SPM的需求单从仓库直接通过快递公司发货到给维修服务站。
成本核算由备件管理部直接同各分公司结算,分公司再跟各服务站结算。
保修期内的备件,费用由分公司承担,保修外的费用,成本由服务站承担,服务站向用户收费收回成本,同时撤销分公司的分仓。
该SPM信息系统流程清晰,我作为该项目的负责人,组织项目组人员,对用户的需求进行搜集、整理、归纳,最后形成了项目的软件需求规格说明书。
并组织项目组成员对需求规格说明书进行评审,评审通过后,项目组成员就积极投入到项目的开发中。
软件工程面对的项目中唯一不变的就是变化。
在整个项目开发过程中,遇到过三次比较大的范围变更。
(1)要求SPM与CMS对接。
由于管理的无序性,造成各服务站通过SPM请购到备件,私自高价出售给别的维修企业的弊端。
公司要求服务站请购专用材料,不直接通过SPM,而是通过CMS的派工单,根据派工单的对应的产品填写所需物料,由CMS生成请购单,发送到SPM,再由SPM来给服务站发货,而通用材料继续通过SPM来操作。