我的配置管理工作总结

我的配置管理工作总结
我的配置管理工作总结

我的配置管理工作总结

我想,是时候对三年来的配置管理工作做一下回顾和总结了,因为之前从事的关于配置管理的工作已经结束了。也许现在说结束还为时过早,因为在未来的一段时间里,无论我从事何种岗位,都要对后来的配置管理初学者提供咨询和技术支持,暂且就阶段性总结一下吧。

零三年春节过后,我走出校门,怀着一颗信心匮乏但勇往直前的心,跋山涉水一日千里的来到了中创软件设立在江苏昆山阳澄湖畔的分公司,在开发中心度日如年了两个月后,我被分配到了管理中心下属的配置管理组,束丽华担任组长,在当时的配置管理组中,包括束姐在内,除了张云之前有较长时间的配置管理经验之外,大家都是初涉此领域的门外汉,我们对配置管理一窃不通,甚至从不知晓配置管理到底是怎样的一门学问,尽管公司为我们提供了一次形式大于内容的培训,但培训过后收获甚微,我们对配置管理的理论和工具的使用仍然云里雾里,于是我们利用所有时间苦读资料。

我们当时得到的相关资料少之又少,并且绝大部分都是英文的,这对于像我这样英语水平近乎白痴的人来说简直就是一种摧残,尽管如此,我还是怀揣着高涨的学习热情和求知欲望,日以继夜的抱着那些英文资料死啃。公司为我们提供了足够多的硬件资源,闲置着的电脑几乎无一幸免的充当了我们的肉鸡,我们在这些肉鸡上搭配服务环境,反复练习各种操作。很多时候,我们会从早上上班开始,一直练习到深夜,那段日子是充实的、匆忙的,当然,上天对我们的不舍昼夜给予的回报是丰厚的,使我们对配置管理理论的理解和工具的使用得到了最初的积累,很多弥足珍贵的经验也在那段日子里被总结了出来,并且形成了各种文档,

这些总结在我们日后对于新员工的培训上发挥了重要作用,也使得公司的过程财富库得到了前所未有的扩充。

一段时间之后,公司对我们的学习成果进行了考核,优胜劣汰,我很荣幸没有被淘汰出局。考核过后,配置管理组一分为二,张云带领谢起飞负责公司各项目的日常配置管理工作,束姐带领我和邢希文来到技术支持中心负责Rational支持工作,所谓技术支持指的就是谁的CC或CQ出问题了我们过去帮着维护一下,剩下的时间留守在那里继续学习,顺便做点别的不沾边的杂事儿,在这期间,我们遇到并解决了开发人员因各种原因导致的各种问题,总结了大量的问题解决方案,我们解决问题的能力也得到了迅速的提高。

16软件配置管理报告

份号:001 密级: XXXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX公司 XXXX年XX月XX日

辑要页

文档修改记录

目次 1 范围 (1) 1.1标识 (1) 1.2系统概述 (1) 1.3文档概述 (1) 2 引用文挡 (1) 3 软件配置管理情况综述 (1) 4 软件配置管理基本信息 (1) 5 专业组划分及权限分配 (1) 6 配置项记录 (1) 7 变更记录 (2) 8 基线记录 (2) 9 入库记录 (2) 10 出库记录 (2) 11 审核记录 (2) 12 备份记录 (2) 13 测量 (2) 14 主释 (2)

1 范围 1.1 标识 本条应描述本文档所适用的系统和软件的完整标识,适用时,包括其标识号、名称、缩略名、版本号和发布号。 1.2 系统概述 本条应概述本文档所适用的系统和软件的用途。它还应描述系统与软件的一般特性;概述系统开发、运行和维护的历史;标识项目的需方、用户、开发方和保障机构等;标识当前和计划的运行现场;列出其他有关文档。 1.3 文档概述 本条应概括本文档的用途和内容,并描述与其使用有关的保密性考虑。 2 引用文挡 本章应列出引用文档的编号、标题、编写单位、修订版及日期,还应标识不能通过正常采购活动得到的文档的来源。 3 软件配置管理情况综述 本章应描述软件配置管理活动进展,与软件配置管理计划的偏差;软件配置管理活动与规程是否相符;对不符合项所采取的措施;完成软件配置管理工作的工作量等。 4 软件配置管理基本信息 本章应概述软件配置管理的基本信息,包括项目负责人、各级软件配置管理机构组成人员和负责人、软件配置管理所用的资源(如计算机、软件和工具)等。 5 专业组划分及权限分配 本章应列出项目专业组的划分、各专业组的成员以及各成员的权限分配,如专业组可分为项目负责人、开发组、测试组、质量保证组、配置管理组等,权限可分为读出、增加、替换、删除等。 6 配置项记录 本章所列出项目的所有配置项,包括配置项名称、配置项最后发布日期、配置项控制力度(控制力度可分为基线管理、非基线管理(受到管理和控制))、配置项版本变更历史、配置项变更累计次数等内容。

CMM中的需求管理与需求开发

需求管理(Requirements Management )是属于CMM2中的过程域,简称为REQM ,需求开发(Requirements Development )是CMM3中的过程域,简称RD 。这两个过程域是CMMI 体系中关于需求的全部内容,下面分别对这两部分进行介绍。本文对CMM 的一些基础知识、基础术语不再介绍。 需求管理与需求开发的分界线: 市场营销 用户需求 管理层 需求开发 需求管理 市场 营销 管理层项目环境 项目变更 大家可以这样理解,需求管理是指对需求变更的管理、对需求的跟踪,而获取需求、定义需求则属于需求开发部分。 需求管理 在CMMI 中,需求管理的目标定义为: a. 把软件需求建立一个基线供软件工程和管理使用。 b. 软件计划、活动和工作产品同软件需求保持一致。 更高的目标: 软件需求的复用 需求管理的原则和方法 a. 必须与需求工程的其他活动紧密整合

b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的 c. 只要需求变化了,需求变更的影响就必须被评估 d. 需求必须分优先级 e. 需求一定要分类管理 需求管理的主要工作: 特定目标和特定实践 特定目标 ●管理需求 管理需求并识别需求与项目计划和工作产品之间的差 异。 ●SP 1.1 取得需求理解 ●SP 1.2 取得需求承诺 ●SP 1.3 管理需求变更 ●SP 1.4 维护需求的双向追溯性 ●SP 1.5 识别项目工作与需求间的差异 REQM特定目标的关系

SP 1.1 取得需求理解 SP 1.1 和需求提出者一同来了解需求。 l 识别出谁是需求的提供者 l 识别出需求的接受标准: a. Clearly and properly stated得到清晰和恰当的定义 b. Complete完整的 c. Consistent with each other相互一致的 d. Uniquely identified得到唯一标识的 e. Appropriate to implement适宜实现 f. Verifiable (testable)可以验证(测试) g. Traceable可追溯 l 分析需求,确保符合已建立的准则。 l 与需求提供者达到需求共识,以使项目成员能承诺它们SP1.2 获取对需求的承诺 SP1.2 取得项目成员对需求的承诺。 ●评估需求对现有承诺的影响。 需求变更或新需求发生时,评估它们对项目成员的影 响。 ●协商并记录承诺。

软件配置管理报告

份号:001密级: XXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX 公司 XXXX 年XX月XX日

辑要页

摘要: 主题词:

文档修改记录

1范围............................................................................................... 1.1标识.......................................................................................... 1.2系统概述...................................................................................... 1.3文档概述......................................................................... 1........... 2引用文挡........................................................................................... 3软件配置管理情况综述............................................................................. 4软件配置管理基本信息............................................................................. 5专业组划分及权限分酉己.......................................................................... 6配置项记录......................................................................................... 7变更记录........................................................................................... 8基线记录........................................................................................... 9入库记录...........................................................................................

软件开发项目配置管理工具的选择

软件开发项目配置管理工具的选择 通过软件配置管理,将对软件系统中的多重版本实施系统的管理;全面记载系统开发的历史过程,包括为什么修改,谁作了修改,修改了什么;管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制,完整、明确地记载开发过程中的历史变更,形成规范化的文档,不仅使日后的维护和升级得到保证,而且更重要的是,这还会保护宝贵的代码资源,积累软件财富,提高软件重用率,加快投资回报…… 每一个软件项目,无论是工程类项目,还是产品类项目,都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中,将生成各种各样不同的工件,包括文档、源程序、可执行代码、支持库。更可怕的是,频繁出现的变更是不可避免的,因此面向如此庞大且不断变动的信息集,如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题,最早的开发人员尝试过的解决办法是通过手工来实现: 1)文档:每次修改时都另存为一个新的文件,然后通过文件名进行区分,例如"XXX 软件需求说明书V1.0,XXX软件需求说明书V1.1,XXX 软件需求说明书V2.0.",并且在文件中注明每次版本变化的内容; 2) 源代码:每次要修改时就将整个工程目录复制一份,将原来的文件夹进行改名,例如"XX 项目V1.0、XX 项目1.01、.",然后在新的目录中进行修改; 但是这种方法,不仅十分繁琐,容易出错,而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时,还是会造成很大的混乱。很显然,这样简陋的方法是无法应对这一问题的。后来,有人尝试从制造工业领域引入了"配置管理"这一概念,通过不懈的研究与实践,最终形成了一套管理办法和活动原则,这也就是软件配置管理。 通过软件配置管理,将对软件系统中的多重版本实施系统的管理;全面记载系统开发的历史过程,包括为什么修改,谁作了修改,修改了什么;管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制,完整、明确地记载开发过程中的历史变更,形成规范化的文档,不仅使日后的维护和升级得到保证,而且更重要的是,这还会保护宝贵的代码资源,积累软件财富,提高软件重用率,加快投资回报。 常见的配置管理工具 正如前面所述,由于软件配置管理过程十分繁杂,管理对象错综复杂,如果是采用人工的办法不仅费时费力,还容易出错,产生大量的废品。因此,引入一些自动化工具是十分有裨益的,这也是做好配置管理的必要条件。 正是因为如此,市场上出现了大量的自动化配置管理工具,这些工具的实现原理与基本机制

需求管理工具比较

本人从网上收集整理的几个需求管理工具- 项目管理 需求是研发团队工作的起点,很多研发团队的开发过程混乱的源头都在于需求管理没有做好。这里是本人收集整理的几个需求管理系统,希望对大家有点帮助。 Rational RequisitePro Rational RequisitePro是一个强大、易用、集成的需求管理产品。而通过与Rational系列软件产品的广泛集成,大大扩展了RequisitePro及其他产品的功能,给软件工程生命周期内的各个阶段都提供了强大、方便的信息查询、跟踪、管理功能。从而能够促进更好的团队沟通、帮助管理变更和评估变更的影响,帮助验证所有的规划需求被交付物所满足、降低项目风险。 网址:https://www.360docs.net/doc/7719081896.html,/software/awdtools/reqpro/ IBM Rational DOORS IBM Rational DOORS前身是大名鼎鼎的Telelogic DOORS,被IBM收购后更名为IBM Rational DOORS。DOORS 是最老牌的企业需求管理套件,通过使用DOORS/ERS,可以帮助企业更有效地进行沟通并加强协作与验证,从而降低失败的风险。通过对整个组织实施多种需求管理的方法,可以使项目的管理更加透明。它可以使企业跨越地域与组织的边界来按国际化的方式运行。

网址:https://www.360docs.net/doc/7719081896.html,/software/awdtools/doors/ Borland CaliberRM Borland CaliberRM是一个基于Web 和用于协作的需求定义和管理工具,可以帮助分布式的开发团队平滑协作,从而加速交付应用系统。CaliberRM 辅助团队成员沟通,减少错误和提升项目质量。CaliberRM 有助于更好地理解和控制项目,是Borland 生命周期管理技术暨Borland Suite 中用于定义和设计工作的关键内容,能够帮助团队领先于竞争对手。CaliberRM提供集中的存储库,能够帮助团队在早期及时澄清项目的需求,当全体成员都能够保持同步,工作的内容很容易具有明确的重点。此外,CaliberRM 和领先的对象建模工具、软件配置管理工具、项目规划工具、分析设计工具以及测试管理工具良好地集成。这种有效的集成有助于更好地理解需求变更对项目规模、预算和进度的影响。 网址:https://www.360docs.net/doc/7719081896.html,/us/products/caliber/index.html

软件项目管理小结篇精修订

软件项目管理小结篇 SANY标准化小组 #QS8QHH-HHGX8Q8-GNHHJ8-HHMHGN#

软件项目管理小结2篇 软件项目管理已经到了学期的最后,我们seed小组的软件项目也已完工,这一个学期真的是获益匪浅! 礼平老师曾经说我既可以走技术路线也可以走管理路线,一切都看我自己。真的很是佩服老师的看人眼光,很犀利。我知道,现在的我不是没有能力去做好,只是自己没有去做,一直在殿外徘徊,不肯付出努力向前迈进。从大一到现在,我的专业技术一直都是我的短板,理由么,很简单,就是因为自己懒,不肯花时间去做。从以前不知道自己想做什么,到现在明确目标,可以说,软件项目管理课程给了我很多灵感,让我从自己纷乱的思绪中看清楚了自己最想要的东西。一直自己很喜欢管理,我会花费很多时间在这上面,从大一到现在一直都是,一直没有改变过。在技术上,我总是给自己找借口,总是偷懒,但我现在明确了一点,没有技术,就没有管理!脱离技术的管理是不可能的,也是不现实的。在这个行业里,技术是一切的基本,想作工程师也好,想作管理者也好,技术都是起步的根基。而我这次所经历的项目更让我明确了这一点。在这个小项目里,虽然我们两个星期就开发完成了这个软件,并交付使用,但是问题还是很多的。在这么一个小项目里,由于需求、设计、代码、文档产生的问题,每一个看似容易,却都需要实实在在的经验在里面,都需要对业务的熟悉,有语言功底作根基。 在这个项目里,我负责软件配置管理工作,在文档的整理过程中,我仔细看了他们的需求分析,概要设计,数据库设计,模块设计等文档,也参与了风险分析文档的编写,承担了用户手册和项目成本估算的编写。在这个过程中,我明确了技术的实在意义,明确了技术对我的指导作用,同时也明确了自己的学习道路应该怎么走下去! 整个项目进行的过程中,我一直在努力从中学习,我旁听开发组的会议,为组长提供管理意见,为会议、文档制定标准,整个过程我收获了很多。 1、软件项目小组中的人员安排要职责明确,并有配套的管理记录,整理每个人的工作进度,随时更新,以方便开发人员、测试人员之间的沟通。 2、会议、文档、代码都要有相应的“纪律”,否则整个小组的开发效率会大打折扣。

配置管理岗位职责

配置管理员岗位职责 摘自:软件配置管理论坛 一、配置经理的基本技能与资格 资格: 能够重视配置管理工作; 能够按规范实施配置管理工作; 积极支持部门的配置管理方面的工作; 能够积极支持与帮助其他人员; 为部门的配置管理能力的提高贡献力量; 熟悉公司配置流程以及其他相关的流程; 为增进项目管理,对于项目内的困难和关键问题,能够及时反映到部门; 基本技能: 能够独立规划项目的配置管理工作; 熟练掌握配置管理的相关概念; 能够了解配置的相关工具,熟练使用技术工程部配置所使用的工具; 具有基本的与人沟通的技巧; 能够了解项目管理过程中的主要环节; 初步了解项目管理过程中的质量保证的各个方面; 了解部分系统和应用工具,如数据库ORACLE,前台开发工具DEPHI等; 二、配置经理的职责 作为一名配置人员,配置经理的职责就是能够与质量人员、测试人员等共同保证项目的质量。如:作为质量保证的成员之一,能够为整个技术工程部规范化管理的推进作贡献,如宣传规范化管理的知识,陈述规范化管理的利弊等;能够在项目进行的整个生命过程中,不断的与项目经理、QA、SCCB及项目成员进行配置管理规范化的沟通,为项目配置管理的规范化作出努力. 具体表现为: ?项目进行初期或首次进入项目中时,能够首先与项目经理、QA、SCCB及项目成员就项目的未来配置管理工作进行沟通,取得项目经理、QA、SCCB及项目全体成员对配置工作的认可与支持; ?积极了解项目情况,项目各阶段的进展,为更好的进行配置管理作努力; ?熟练并充分的利用配置管理工具的各方面的功能,提高配置管理的效率; ?为项目控制好版本,保证项目各阶段所使用的版本正确; ?及时发现项目问题,把问题及时反馈给项目经理、QA或SCCB,并积极协助解决; ?与项目内其他组成员,如开发组、测试组等协调工作,并能够很好的沟通; ?能够在项目中不断总结、分析,为项目内配置管理工作的进一步优化作贡献;

软件配置管理实验报告-SVN

软件过程管理 实验报告 (2011/ 2012 学年第二学期) 实验报告 指导教师 实验名称软件配置管理-SVN的安装配 置和使用 实验类型验证实验学时 2 实验时间一、实验目的和要求 掌握开源软件配置工具SVN的安装配置和使用。 二、实验环境(实验设备) PC机,V isual SVN Server ,Tortoise SVN

三、实验原理及内容 实验内容:1.安装SVN服务器端软件Visual SVN Server及配置。 2.安装SVN客户端软件Tortoise SVN及配置。 实验步骤: 1.安装服务器端Visual SVN Server 2.安装客户端Tortoise CVS 3.配置SVN服务器的用户,用户组和权限 4.客户端机器上,新建一个工作目录,执行检出操作。 5.修改版本库 6.SVN分支与合并 实验报告

四、实验小结(包括问题和解决方法、心得体会、意见与建议等) svn(subversion)是近年来崛起的版本管理工具,是cvs的接班人。目前,绝大多数开源软件都使用svn作为代码版本管理软件。 SVN采用virtual copy(虚拟拷贝)的方式创建分支.创建后展现给客户端的是独立的库路径,而实际上和主版本共用同样的数据,哪怕是创建多个分支.因此,完全不用担心创建多个分支会增加磁盘的占用空间,而且,其创建效率也是非常高的,官方的说法是constant time(恒定时间),无论你的库有多大,其创建分支的时间基本上是恒定的。 SubV ersion官方建议SVN库根目录应包括Trunk和Branches,这是两个最基本的目录.其实其目录结构可以是任意的.一般Trunk存放主版本,Branches存放众多的分支版本.如下图所示EAS100C的SVN目录结构.因此可以把EditionG3和EditionContracts放在Branches目录. 如何创建分支 TortoiseSVN是官方SVN客户端,以性能好,对Subversion支持全面而被广泛使用.(Tortoise,海龟,无明确寓意). 有多种方式可创建分支. 方式一 第一种方式是采用浏览模式,这种方式简单,快捷,会以当前trunk的最新修订本创建分支,无其他可选项.见完整图示: (1)右键,选择Repo-browser

软件公司工作总结4篇

软件公司工作总结4篇 xx年软件公司工作总结及xx年工作规划 光阴如梭,一年的工作转瞬即将成为历史,伴随着新年钟声的临近,我们依依惜别硕果累累的xx年,满怀热情的迎接到来的xx年。 xx年是自己进公司的第三个年头,在这一年里也是自己进公司最忙最累的一年,由于工作的重要性超负荷工作,除正常的上班八个小时,下班后几乎每天都要忙到23点后甚至通宵,有付出就有收获,现在回头看看,还是挺有成就感的。 xx工作总结 xx年1月到3月:维护及更新oa系统、人事系统、vip卡管理系统分布式、美容院前台客户管理系统。由于工作量问题,在3月将oa系统移交给他人维护及更新,将人事系统移交给他人维护及更新。 xx年3月到8月:维护及更新vip卡管理系统分布式、美容院前台客户管理系统。主要工作是vip卡管理系统的分布式功能的实现,经过前 ----------------精选公文范文 1

面几个月的开发及测试,在3月中旬开始将分布式功能放在华景店进行测试,经过一段时间的测试及相关问题的跟进与更新,4月1日在黄埔店进行分布式系统的安装。经过两家店的分布式功能的使用,在后面的时间里对广州所有店都安装好分布式系统。处理日常系统操作中遇到的问题、更新一线对系统提出的修改及分布系统客户端数据与服务器数据的核对。 xx年8月到12月:从8月份开始,应该对财务的问题,开始次vip卡管理系统进行升级到美容院管理系统,结合提出的需求,对vip卡管理系统中的功能、数据库结构及操作页面进行全面的更新。经过一个月的更新,从9月2日开始使用新的更新完一部分的美容院管理系统。从9月份开始根据财务人员提出的修改,对系统进行更新,协助财务部对系统数据的调整。一直到现在系统一直在修改及改进,相比以前的vip卡管理系统,系统中增加了许多在以前系统中没有的功能,在功能的实现及数据的稳定进行了大大的改善。 xx工作规划及打算 ----------------精选公文范文 2

软件项目管理年度工作总结范文

( 工作总结 ) 单位:_________________________ 姓名:_________________________ 日期:_________________________ 精品文档 / Word文档 / 文字可改 软件项目管理年度工作总结范 文 Annual work summary model of software project management

软件项目管理年度工作总结范文 软件项目管理已经到了学期的最后,我们seed小组的软件项目也已完工,这一个学期真的是获益匪浅! 礼平老师曾经说我既可以走技术路线也可以走管理路线,一切都看我自己。真的很是佩服老师的看人眼光,很犀利。我知道,现在的我不是没有能力去做好,只是自己没有去做,一直在殿外徘徊,不肯付出努力向前迈进。从大一到现在,我的专业技术一直都是我的短板,理由么,很简单,就是因为自己懒,不肯花时间去做。从以前不知道自己想做什么,到现在明确目标,可以说,软件项目管理课程给了我很多灵感,让我从自己纷乱的思绪中看清楚了自己最想要的东西。一直自己很喜欢管理,我会花费很多时间在这上面,从大一到现在一直都是,一直没有改变过。在技术上,我总是给自

己找借口,总是偷懒,但我现在明确了一点,没有技术,就没有管理!脱离技术的管理是不可能的,也是不现实的。在这个行业里,技术是一切的基本,想作工程师也好,想作管理者也好,技术都是起步的根基。而我这次所经历的项目更让我明确了这一点。在这个小项目里,虽然我们两个星期就开发完成了这个软件,并交付使用,但是问题还是很多的。在这么一个小项目里,由于需求、设计、代码、文档产生的问题,每一个看似容易,却都需要实实在在的经验在里面,都需要对业务的熟悉,有语言功底作根基。 在这个项目里,我负责软件配置管理工作,在文档的整理过程中,我仔细看了他们的需求分析,概要设计,数据库设计,模块设计等文档,也参与了风险分析文档的编写,承担了用户手册和项目成本估算的编写。在这个过程中,我明确了技术的实在意义,明确了技术对我的指导作用,同时也明确了自己的学习道路应该怎么走下去! 整个项目进行的过程中,我一直在努力从中学习,我旁听开发组的会议,为组长提供管理意见,为会议、文档制定标准,整个过

需求管理过程

软件过程标准 需求管理过程 V1.0

修订记录

目录 1目的和范围 (1) 2术语简称与解释 (1) 3进入准则 (1) 4退出准则 (1) 5阶段交付产品 (2) 6文件使用者 (2) 7过程流图 (3) 7.1过程 (3) 7.1.1需求收集与获取 (3) 7.1.2需求评审 (5) 7.1.3需求变更管理过程 (6) 7.2过程描述 (7) 7.2.1需求收集与获取过程细则 (7) 7.2.2需求评审细则 ......................................................................... 错误!未定义书签。 7.2.3需求变更管理过程细则 (8) 7.3验证机制 (9) 7.4度量 (9) 8活动职责矩阵 (10) 9参考资料 (10) 10附件 (10)

1目的和范围 本过程的目的在于为公司实施与需求相关的方针提供指南。该过程对所有公司负责需求采集的项目适用,也适用于那些客户在自行采集需求时需要帮助的项目。 2术语简称与解释 总经理:简称GM,指公司总经理,具备法人代表资格。 副总:简称VGM,公司的一种职务,指公司副总。 项目经理:简称PM,公司的一种职务,一般由具备项目管理经验和行业经验人员承担,负责项目的管理活动。 项目负责人:简称PL,项目组组长,临时性职务,负责项目的开发活动,如无变更,生存周期与项目生存周期相同。 需求分析人员:简称RA,通常由项目组中成员承担此角色,可以是项目负责人也可以项目组中其他人员。 软件设计人员:简称SD。在公司一般指系统分析员和程序员(包括高级程序员); 在项目中指项目组中的设计人员。 软件质量保证:SQA,一种软件质量保证活动,在公司通常也用SQA代表质量保证活动者,目前由公司品管部执行此活动。 配置管理员:简称CC,在公司中负责所有项目的配置管理活动。 3进入准则 进入准则如下: ?来自客户的关于需求的文档经过公司审批; ?来自客户的标识有意进行某个项目的信函,并且经过公司审批; ?总经理对内部项目的授权,有相关文件(文档)表明是经过审批的; ?公司与客户签订的合同。 附注:满足其中任何一种条件均可。 4退出准则 退出准则如下: ?SRS的文档已准备好,经过评审和批准。

软件项目-配置管理总结-模板

XXX项目 配置管理总结模板 版本:V1.0 XXXX年XX月

1配置管理工作总结 (1) 1.1配置项按计划入库情况 (1) 1.2配置项变更情况 (1) 1.3配置管理工作统计 (1) 2经验教训 (2) 3好的实践 (2) 4对配置管理改进的建议 (2) 5模板补充说明 (2) 5.1关于字体 (2) 5.2关于页眉页脚 (2) 5.3关于图、表 (3)

1 配置管理工作总结 [介绍项目中的配置管理情况,与配置管理计划对比,进行总结,包括进行了什么培训、进行了什么审计、发现问题的情况、问题处理的情况,配置管理的工作量,工具支持、指导情况] 1.1 配置项按计划入库情况 表1-1 1.2 配置项变更情况 表1-2 1.3 配置管理工作统计 [包括进行了什么审计、进行了什么变更等]

[介绍在项目的配置管理中遇到了一些什么问题,并介绍如何解决] 3 好的实践 1、产生较好执行效果的过程或活动;好的方式、方法和技巧,尽可能具体,便于在公 司或其它项目组推广;好的经验 2、列出配置管理推荐出来的项目优秀范例或方法的清单 4 对配置管理改进的建议 [列出对配置管理的改进意见和建议] 5 模板补充说明 5.1 关于字体 ●封面题名项目计划一号黑体 ●大标题 1 项目目标黑体二号 ●一级节标题 1.1质量目标黑体三号 ●二级节标题 1.1.1过程质量黑体四号 ●三级节及以下标题 1.1.1.1测试过程质量黑体小四号 ●正文测试过程质量要求宋体小四号 ●表及表题表1-1 黑体五号 ●英文和数字字体采取Arial 5.2 关于页眉页脚 ●封面:没有页眉页脚; ●版本及目录:页眉为文档名称;页角中的页码采取罗马数字,从Ⅰ开始; ●正文:页眉与版本及目录一致,为文档名称;页码编号采取阿拉伯数字,从1开始。

【项目管理知识】从项目管理角度看软件配置管理

从项目管理角度看软件配置管理 项目的目地是为了创造一项产品或服务,因此,产品本身的生产工艺必然会成为项目管理过程的核心内容。无论在哪一种软件工程方法中,软件配置管理都是一项不可或缺的重要管理内容,特别是对于服务企业内部的信息技术部门来说,从产品生命周期出发,同时支持服务产品和软件产品,同时负责开发与运行,其管理复杂度很高,要想理顺各项工作的内部关系、理清各项工作之间的配合关系,都离不开配置管理这个基本手段,它是许多管理工作的“落地”部分。其实,配置管理并不是一个时髦的概念,在许多传统行业(例如制造业)中早已有之,软件行业只是在软件工程方法中继续延用了这一概念,它是一流软件开发企业所必备的基础设施。 在项目管理中,配置管理是一种重要的管理手段。在PMI的PMBOK中对于配置管理系统是这样描述的: 由此可见,配置管理是一个非常宽泛的概念,项目中只要是需要进行管理的任何特性,都可以纳入配置管理。配置管理不只是操作层面的问题,更是管理理念、管理方法的问题,是一个系统。 项目范围管理需要配置管理来落实 在项目范围管理中,需要识别和控制项目的交付成果,要描述交付物应有的各种特性。这些交付物及其特性,就是配置管理中的配置项。从项目管理的角度,WBS只需要分解到可管理(Manageable)的程度,而配置管理则要求分解到终可操作的程度,管理的粒度更为精细。因此,良好的配置管理机制,是项目范围管理得到终落实的保证。 在许多软件开发项目中,项目范围管理涉及三个方面:业务需求、技术结构、投产服务。编写哪些程序模块,实现哪些功能,部署到哪些地点,这其实

都是项目范围管理所要关注的内容,在配置管理中对应了产品的物理属性和功能属性以及服务的属性,都可以通过配置管理来识别、记录和跟踪。只有做好软件配置管理,才能真正把项目的范围管理做实。 业务需求决定了软件产品的功能特性,对软件产品的配置管理,首先就是对业务需求的管理。在业务需求中,要求软件产品所提供的各种功能和特性,包括界面风格、操作方式、处理流程、业务规则、数据逻辑等,也都是软件产品的配置项,这种对业务需求的分解、管理的过程,就是对业务需求中的配置项的管理过程。当项目中业务需求发生变更时,其实就是对这些配置项的变更管理。因此,在软件工程过程中,配置管理是需求管理的基本手段,通过科学、严谨的配置管理方法,对业务需求进行识别、分解、跟踪、控制,直接决定了对业务需求的管理能力。许多公司目前在需求管理方面还处于粗放型的管理,虽然基本能够满足项目管理的需要,但对于软件工程过程来说,管理粒度还比较粗,而且缺乏明确的配置项的定义,缺少有效的跟踪控制手段,还需要更精细的管理。 技术结构是软件产品的物理属性,软件产品的配置管理,也是对软件内部技术结构的管理。从技术方案到软件产品、再到产品内部结构,这也是项目范围不断分解、细化的过程。为了实现业务需求、满足产品外部特征的要求,软件产品应如何设计其内部结构,划分内部模块、定义模块接口、确定有多少个程序等等,产品分解到后,每一个程序都作为一个单独的配置项进行管理,在开发过程中对于程序的修改都纳入配置管理,跟踪程序变化过程。这种对软件产品从技术角度的不断分解和定义,就是基于技术结构的配置项管理,是与软件结构设计相对应的,配置项的划分是否合理,使用起来是否灵活、方便,哪些可以成为公共组件(Component),其实反映的都是软件设计的思想。在有的软件企业中,配置管理不只是程序员的操作工具,它已经成为工程技术管理的

需求管理研究报告

需求管理研究报告

第8章需求管理 (3) 8.1 介绍 (3) 8.2 需求确认 (5) 8.2.1目的 (5) 8.2.2角色与职责 (5) 8.2.3启动准则 (6) 8.2.4输入 (6) 8.2.5主要步骤 (6) [Step1] 非正式需求评审 (6) [Step2] 正式需求评审 (6) [Step3] 获取需求承诺 (7) 8.2.6输出 (7) 8.2.7结束准则 (7) 8.2.8度量 (8) 8.3 需求跟踪 (8) 8.3.1目的 (8) 3.3.2角色与职责 (8) 3.3.3启动准则 (8) 3.3.4输入 (8)

[Step1] 建立与维护需求跟踪矩阵 (9) [Step2] 查找不一致 (10) [Step3] 消除不一致 (10) 8.3.6输出 (10) 8.3.7结束准则 (10) 8.3.8度量 (11) 8.4 需求变更控制 (11) 8.4.1目的 (11) 8.4.2角色与职责 (11) 8.4.3启动准则 (11) 8.4.4输入 (12) 8.4.5主要步骤 (12) [Step1] 需求变更申请 (12) [Step2] 审批需求变更申请 (12) [Step3] 更改需求文档 (12) [Step4] 重新进行需求确认 (13) 8.4.6输出 (13) 8.4.7结束准则 (13)

8.5 实施建议 (13)

第8章需求管理 需求管理(Requirement Management, RM)的目的在客户与开发方之间建立对需求的共同理解,维护需求与其它工作成果的一致性,并控制需求的变更。 需求管理过程域是SPP模型的重要组成部分。本规范阐述了需求管理过程域的三个主要规程: ?需求确认 [SPP-PROC-RM-VALIDATE] ?需求跟踪 [SPP-PROC-RM-TRACKING] ?需求变更控制 [SPP-PROC-RM-CHANGE] 上述每个规程的”目标”、”角色与职责”、”启动准则”、”输入”、”主要步骤”、”输出”、”完成准则”和”度量”均已定义。 本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况(如商业目标、研发实力等)适当地修改本规范,然后推广使用。 8.1 介绍 我们把所有与需求相关的活动通称为需求工程。需求工程中的活动可分为两大类,一类属于需求开发,另一类属于需求管

国内外需求管理工具比较学习资料

需求管理(REQM,Requirements Management)属于成熟度2级(受管理级)的过程域,是其他许多过程域实施的前提。对于暂未实施CMMI的企业,同样也可以借鉴CMMI的原则,实施和优化需求管理。 许多IT企业都有过需求失控的痛苦经历,我们不难体会,没有好的需求管理会给我们带来什么: ?需求以失控的状态进入软件过程,从源头上失去了项目的质量保证; ?需求范围界定不清,使项目缺乏计划性,导致成本、研制周期失控; ?需求变更失控,使组织处于被动反应式的环境中,项目组成为救火队; ?需求管理不当,导致项目延期、士气低落,增加了项目的失败风险; ?…… 为了避免上述情况的出现,CMMI对需求管理提出了明确的目的:一是管理项目的产品和产品构件的需求;二是标识哪些需求与项目计划及工作产品之间不一致。通过适当的步骤,确保需求在项目的各个层面上动态地保持一致,一旦出现不一致,则启动相关的处理过程域,使其调整到一致。 需求管理的工具包括: ①需求及相关文档管理的工具; ②流程审批的流转电子化; ③溯源性矩阵的维护工具。 其中最大的难点是需求溯源性矩阵的维护工具,对此我们作重点分析。 需求溯源包括的三个方面,可看作是三个子矩阵,每个子矩阵对某个方面都具有双向溯源性。 ?需求向低层分解的双向溯源矩阵 ?需求沿生命周期纵向产品溯源矩阵 ?需求的水平溯源矩阵(跨系统功能间) 综上所述,需求管理要求建立和维护需求双向溯源表,而双向溯源表的关联关系非常复杂,因此: ①必须借助工具进行管理。对小的项目,可以用Excel等简单工具进行管理, 但对大型项目或组织级的需求管理,则应购买或自行开发专门的需求管 理工具。 ②必须建立一套编码体系,以便进行标识和检索。 ③需求管理工具可以与配置管理工具同时考虑,即综合设计成一个管理系 统。

软件配置管理规范流程

1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动,确保配置项正确地唯一标识并且易于存取,保证基线配置项的更改受控,明确基线状态,在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围 本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动,针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法,本文件以CVS(并行版本系统)配置管理工具为例,规定公司的配置管理办法,使用其他工具时也可对应本文件的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理(Software Configuration Management,SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项(Configuration Item,CI) 凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的。 每个配置项的主要属性有:名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里,确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线(Baseline) 在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”。每一

软件项目管理总结

软件项目管理过程的简单总结 学院:计算机学院 班级:软件11 姓名:雷莉莎 做任何事情都需要管理,好的管理出好的效益,开发软件项目也不例外。随着信息系统工程、网络工程、软件工程的发展,项目管理和软件工程的交汇越来越多,从而使“软件项目管理”发展起来,一个项目的成功与否,关键一点就是,看项目管理是否得当。所以,项目管理是项目的核心部分,是项目的灵魂。 软件项目管理的概述 所谓项目,就是在特定条件下,具有特定目标的一次性任务,是在一定时间内,满足一系列特定目标的多项相关工作的总称.项目具有一次性、独特性、目标的确定性、组织的临时性和开放性以及成果的不可挽回性等基本属性。 而软件项目管理是为了使软件项目能够按照预定的成本,进度、质量顺利完成,而对人员,产品,过程和项目进行分析和管理的活动。根本目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析,设计,编码到测试,维护全过程)都能在管理者的控制之下,以预定成本按期,按质完成软件交付用户使用。 软件项目的管理过程详解 在软件项目开发管理过程中,不仅要努力实现项目的范围、时间、成本和质量等目标,还必须协调整个项目过程,以满足项目参与者及其他利益相关者的需要和期望。随着软件规模和所涉及的领域不断扩大,软件项目的管理越来越困难。纵观所有失败的软件项目,基本原因是不能管理其软件过程,在无纪律、混乱的项目状态下,组织不可能从较好的方法和工具中获益。严谨的软件过程控制与管理不仅可以在每个阶段回顾和纠正项目的偏差,识别软件项目的风险甚至果断中止项目,而且可以将人才流动所带来的不利影响减少到最小。要进行有效的过程控制,必须明确软件项目管理流程。 下图即为软件项目管理流程: 接下来详细介绍项目管理过程的步骤包括: 项目立项——启动——规划——执行和控制——收尾阶段 1.软件项目立项包含5个环节:发起、评估、申请、审核、立项。 立项流程图 2. 项目的启动就是确定项目的目标范围,它主要包括开发和被开发双方的合同(或是协议),软件要完成的主要功能以及这些功能的量化范围,项目开发的阶段周期等。 PMBOK中明确指明项目启动阶段主要的工作是制定项目章程和识别项目干

需求管理

需求管理 摘要: 2011年7月,我参与了某企业“高清卡口式智能电子警察“项目的建设。在项目中担任项目经理职务,主要负责项目的管理工作。该项目是受某市公安局交警指挥中心的委托而开发的,目的是为了改善城市道路交通环境,提升公众出行安全系数。系统兼具电子警察和卡口功能。(121) 本文结合作者的经验,以“高清卡口式智能电子警察“项目为例,讨论了项目的需求管理过程以及采用的措施和方法。作为建设方的项目经理,我认为需求管理在信息系统项目中目的是确保项目各方对需求的一致理解,管理和控制需求的变更,实现从需求到最终产品的双向跟踪。在具体工作中,采取了利用头脑风暴法获取需求,利用业务流程分析、数据流图等进行需求分析,利用评审进行需求验证,制定双向跟踪矩阵进行需求管理等相关管理方案。通过这些措施和方法,有效地控制了项目范围和成本,成功地完成了项目,受到用户方的高度评价。 正文: 项目概述; 随着我国国民经济的持续快速发展,车辆剧增,由此导致交通阻塞,交通事故发生频率高,交通环境污染,交通治安混乱等一系列问题,严重影响了人民的生活。在城市交通的关键点——道路交叉口,由于汇聚了多个方向的交通流量,加上机动车非机动车混行等因素,成为城市路网中交通拥堵发生的重点地段。而车辆闯红灯等违法现象,更是成为引发道路交通事故的主要诱因之一。单纯依靠人为管理,浪费人力资源,效果也不明显。因此,向科技要警力,向管理要效益成为各个城市交通管理部门进行违法自动检测系统建设的动力。 为进一步利用科技手段实现对闯红灯、逆行等违法行为进行有力地治理,防止此类交通违章行为的发生,减少由此引起的事故,并促进交通秩序良性循环,提升公众出行安全系数,某市公安局交警指挥中心特委托我公司开发“高清卡口式电子警察”。 项目启动后,我被任命为该项目的项目经理,全面主持项目的管理工作。 该项目规模庞大,一期投资投资600万,要求在2012年1月1日前全面竣工并投入使用。该项目将负责某市110万辆机动车数据,涉及部门人员众多,涵盖的知识技术领域范围广,是一个大型、复杂的综合性项目。在有关领导的亲切关怀下,在项目干系人的配合与支持下,我与项目组全体组员并肩作战,通过近6个月的努力,终于在2011年12月20日全面通过验收。项目总成本为万原,比计划提前10天,为公司挣得万利润。 项目采用B/S架构,Windows为开发平台,c#,c++为开发语言,数据库使用的是oracle 10g。该项目除了具备实时监控功能外,还具有高清抓拍、大容量高速存储、自动检测车辆及车牌识别、全程轨迹跟踪、自动预警拦截等系统功能。项目涉及的子系统较多,主要包括车辆检测模块、图像采集模块、信息处理模块、数据检索模块、违章检测模块等几个部分。 该项目的成功与合理的需求管理以及项目干系人的大力支持是密不可分的,下面分别对项目需求管理过程中需求获取、需求分析、需求定义、需求验证、需求管理(制定需求管理计划、需求变更管理、需求跟踪)等几个方面加以简要论述。 需求管理和范围管理的关系: 需求开发、需求管理、范围管理的区别和联系主要如下: 1)首先通过需求开发来获取项目的需求,在此基础上确定项目的范围、进行项目范围管理。项目管理者联盟

软件配置管理计划

软件配置管理计划示例 计划名国势通多媒体网络传输加速系统软件配置管理计划 项目名国势通多媒体网络传输加速系统软件 项目委托单位代表签名年月日 项目承办单位北京麦秸创想科技有限责任公司 代表签名年月日 1 引言 1.1 目的 本计划的目的在于对所开发的国势通多媒体网络传输加速系统软件规定各种必要的配置管理条款,以保证所交付的国势通多媒体网络传输加速系统软件能够满足项目委托书中规定的各种原则需求,能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统(其中包括为本项目研制或选用的各种支持软件)时,都应该执行本计划中的有关规定,但可以根据各自的情况对本计划作适当的剪裁,以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1.2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1.3 参考资料

◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆国势通多媒体网络传输加速系统软件质量保证计划 2 管理 2.1 机构 在本软件系统整个开发期间,必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导,由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成,由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导,在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求,制订必要的规程和规定,以确保完全遵守本计划规定的所有要求。 2.2 任务

相关文档
最新文档