-
Linux下如何删除非空目录
2009-10-18 23:04:16
一个很Basic的问题，却一下想不起来，也许是之前的工作一直没有接触过linux了。
使用rm -rf 目录名
参数-f表示force.强制删除
-
柴氏语录
2009-09-15 22:41:12
柴氏语录：
1.抬起你高傲的头，骄傲的活着。
2.对付贱人，如果做不到比他更贱，那就忽略他，无视他。把他当个屁放了。
3.人有时候变得冷漠，不是因为无情，可是被伤害的太多次，学会了自我保护。
4.我不会去主动伤害别人，但我也不会让别人来伤害我。
5.你表现的越软弱，别人越会欺负你，你越强势，别人越不敢招惹你。
6.爱情就是一场追逐游戏，不是男的追着女的跑，就是女的追着男的跑。
7.矛盾就是一种循环，从一个矛盾跳到下一个矛盾，永远不停的矛盾下去。
目前暂时就这些，以后再有继续补充！
-
博客荒废了好久
2009-08-12 10:13:10
工作将近半年了，自从工作后，博客就一直荒废到现在。突然有种想要重新开始的感觉。现在的工作主要是手机功能测试。这个工作让我对前途很迷茫。有时候我很害怕，害怕如果做几年手机测试以后，就跳不出这个行业。无法再去选择自己喜欢的。纯做手机的功能测试，技术含量比较低，很容易被取代，感觉竞争力很低。让我很多时候都有一种危机感。
所以想趁现在入进行时间不是很久，找一个相对来说技术含量高一些，自己比较感兴趣的工作。机会总是留给有准备的人。现在只能自己先好好自学一些知识。这样将来的找一份自己喜欢的把握会大一些。
明白心中所想，专注手中所做。为自己的将来好好谋划！
-
grub与lilo的区别
2008-10-05 15:12:38
grub 是一个多重启动管理器。grub是GRand Unified Bootloader的缩写，它可以在多个操作系统共存时选择引导哪个系统。它可以引导的操作系统包括Linux,FreeBSD,Solaris,NetBSD,BeOSi,OS/2,Windows95/98,Windows NT,Windows2000。它可以载入操作系统的内核和初始化操作系统（如Linux,FreeBSD），或者把引导权交给操作系统（如Windows 98）来完成引导。
grub可以代替lilo来完成对Linux的引导，特别适用于linux与其它操作系统共存情况，与lilo相比，它有以下特点：
支持大硬盘
现在大多数Linux发行版本的lilo都有同样的一个问题：根分区(/boot分区)不能分在超过1024柱面的地方，一般是在8.4G左右的地方，否则lilo不能安装，或者安装后不能正确引导系统。而grub就不会出现这种情况，只要安装时你的大硬盘是在LBA模式下，grub就可以引导根分区在8G以外的操作系统。
支持开机画面
grub支持在引导开机的同时显示一个开机的个性化开机画面；对于PC厂商，这样可以在开机时显示电脑的一些信息和厂商的标志等。grub支持640x480,800x600,1024x768各种模式的开机画面，而且可以自动侦测选择最佳模式，与Windows320x400的开机画面不可同日而语。
两种执行模式
grub不但可以通过配置文件进行例行的引导，还可以在选择引导前动态改变引导时的参数，还可以动态加载各种设备。例如你在Linux下编译了一个新的核心，但不能确定它能不能工作，你就可以在引导时动态改变grub的参数，尝试装载这个新的核心进行使用。Grub的命令行有非常强大的功能，而且支持如bash或doskey一样的历史功能，你可以用上下键来寻找以前的命令。
菜单式选择
在lilo下，你需要手工输入操作系统的名字来引导不同的操作系统。而grub使用一个菜单来选择不同的系统进行引导。你还可以自己配置各种参数，如延迟时间，默认操作系统等。
分区位置改变后不必重新配置
lilo是通过读取硬盘上的绝对扇区来装入操作系统，因此每次分区改变都必须重新配置lilo，例如你用PQ magic调整了分区的大小，那lilo在你重新配置好之前就不能引导这个分区的操作系统了。而grub是通过文件系统直接把核心读取到内存，因此只要操作系统核心的路径没有改变，grub就可以引导系统。
除此之外，Grub还有许多非常强大的功能。例如支持多种外部设备，动态装载操作系统内核，甚至可以通过网络装载操作系统核心。Grub支持多种文件系统，支持多种可执行文件格式，支持自动解压，可以引导不支持多重引导的操作系统等。 -
linux 下忘记root密码怎么办?
2008-10-05 14:04:33
如果选择的引导程序是grub
方法如下 :
第一步:按CTRL+ALT+DEL重启。
第二步:出现GRUB引导界面后，按键盘上的“e”键
第三步:用上下键选中你平时启动的那一项（类似kernel /...........root=LABEL=/）然后按“e”在这项的后面添加“ single”注意single前面必须加空格，然后按回车完成修改
第四步:最后点击键盘上面的“b”键启动后直接进入linux命令行
第五步:然后用passwd -d root清除密码，也可以直接passwd root 重设密码。
如果选择的引导程序是LILO
方法如下 :
第一步：启动到引导程序界面，看到LILO：的页面时候进入第二步；
第二步：输入LINUX single，回车；
第三步：在第二步的基础上进入/etc/shadow文件，把文件中以root开头的一行中位于root:和紧跟的一个冒号（：）之间的内容删除掉，然后保存退出；
第四步：重新启动，这个时候root的密码为空；
注意：如果在执行第三步没有成功报错的话，就把第三步用第五步代替
第五步：执行passwd root
同样的，无论你用的哪种方式寻找回丢失的root密码，在安装的过程中都不能在对引导程序设置密码处，设置了密码，否则，在这个密码也忘记的情况下就没有办法了。
-
SVN学习总结
2008-10-03 12:24:20
一、svn 安装
Windows
--subversion
--Tortoisesvn客户端
1.安装tortoisesvn时,按提示步骤执行
2.安装subversion时候必须在安装时选择complete,因为只有选complete后在SlikSvn\bin下才会出现svnserver.exe
3.安装完成后,要在自己的机上建立版本库E:\svndemo\repository
4.在sliksvn\bin下输入命令行 svnserve -d –r E:\svndemo\repository
5.在repository\conf\svnserve.conf文件修改权限
这时我们先采用匿名方式登录进去将#anon-access=read改成 anon-access=write
后面第四点会讲到如何进行用户管理.
二、建立版本库（Repository）
运行Subversion服务器需要首先要建立一个版本库（Repository），可以看作服务器上存放
创建SVN版本库
# svnadmin create E:\svndemo\repository数据的数据库，在安装了Subversion服务器之后，可以直接运行，如：
svnadmin create就会在目录E:\svndemo\repository下创建一个版本库。我们也可以使用TortoiseSVN图形化
的完成这一步：
在目录E:\svndemo\repository下"右键->TortoiseSVN->Create Repository here...“， 然后可以选择版本库模式， 这里使用默认即可，然后就创建了一系列目录和文件。
三、运行独立服务器
在任意目录下运行：
svnserve -d -r E:\svndemo\repository
我们的服务器程序就已经启动了。四、初始化导入
来到我们想要导入的项目根目录，在这个例子里是E:\svndemo\initproject，目录下有一个
readme.txt文件：
右键->TortoiseSVN->Import...
URL of repository输入“svn://localhost/trunk”
ok
完成之后目录没有任何变化，如果没有报错，数据就已经全部导入到了我们刚才定义的版本库中。
五、基本客户端操作
取出版本库到一个工作拷贝：
来到任意空目录下，在本例中是E:\svndemo\wc1，运行右键->Checkout，在URL of
repository中输入svn://localhost/trunk（版本库中要拷贝的文件所在的目录），这样我们就得到了一份工作拷贝。
在工作拷贝中作出修改并提交：
打开readme.txt，作出修改，然后右键->Commit...，这样我们就把修改提交到了版本库，我
们可以运行。
察看所作的修改：
readme.txt上右键->TortoiseSVN->Show Log，这样我们就可以看到我们对这个文件所有的提交。在版本1上右键->Compare with working copy，我们可以比较工作拷贝的文件和版本1的区别。
六、配置仓库，用户及权限管理
SVN的svnserve对于每个仓库，有一个独立的配置文件和独立的用户、权限管理。
在这里仍然要保持配置文件svnserve.conf的独立，但是用户、权限管理是用统一的一个文件来存储。
这样方便以后的管理和维护。
另外要注意，即使svnserve服务已经运行，修改配置文件或者用户、权限管理文件，保存后马上生效，不需要重启服务。svnserve下的配置文件
E:\svndemo\repository
├─conf
├─dav
├─db
│ ├─revprops
│ ├─revs
│ └─transactions
├─hooks
└─locks在conf目录下有三个文件authz，passwd，svnserve.conf
其中的“svnserve.conf”是这个版本库的配置文件，当使用svnserve时，这个配置文件决定了使用什么认证和授权文件
password-db = passwd
authz-db = authz下面一个例子是使用用户登录,但没有给用户分组,也没有设置权限.
来到E:\svndemo\repository\conf目录，修改svnserve.conf：
# [general]
# password-db = passwd改为：
[general]
password-db = passwd然后修改同目录的passwd文件，去掉下面三行的注释：
# [users]
# harry = harryssecret
# sally = sallyssecret最后变成：
[users]
harry = harryssecret
sally = sallyssecret采用上面的修改之后,你再进行操作,这时候进行操作都需要输入用户,密码.
另一种方法,可以不用版本库中已经有的passwd,authz,svnserve.conf文件
全部自己重新创建
你可以直接删除默认的svnserve.conf文件，然后使用下面的配置：
# vi svnserve.conf
[general]
anon-access = none
auth-access = write
password-db =svn-user.conf
authz-db = svn-authz.conf说明：
anon-access = none #不允许匿名用户访问
auth-access = write #通过验证的用户可以读和写
password-db =svn-user.conf #用户保存文件
authz-db = svn-authz.conf #权限管理文件创建用户存储文件
# vi svn-user.conf
设置用户帐号
[users]
harry = harryssecret
sally = sallyssecret
bote = botessecret说明：
[users] //是必须的，标记为用户配置开始
harry = harryssecret //harry 是用户名 ， harryssecret是密码。注意，是明文密码
sally = sallyssecret // 同上
bote = botessecret // 同上往后所以仓库的用户都在这里记录就可以了。至于那个用户，允许访问那个仓库，在权限管理里限制。
创建权限管理文件
# vi svn-authz.conf设置权限管理
[groups]
source1 = harry
source2 = sally[source1:/]
@source1 = rw
@source2 = r
[source2:/]
@source2 = rw
@source1=r对于管理多个不同的版本库，使用svnserve时，为了管理的方便，应该使用相同的认证和授权文件，所以应该让所有版本库的配置文件svnserve.conf指向同一个password-db和authz-db文件。下面是一个多版本库的目录：
E:\svndemo\repository
├─project1
│ ├─conf
│ ├─dav
│ ├─db
│ │ ├─revprops
│ │ ├─revs
│ │ └─transactions
│ ├─hooks
│ └─locks
└─project2
├─conf
├─dav
├─db
│ ├─revprops
│ ├─revs
│ └─transactions
├─hooks
└─locksProject1和project2是两个不同的版本库，它们有着相同的文件结构，如果要统一管理，我们可以将它们的验证和认证文件指到一个相同的地方；在E:\svndemo\repository目录下拷贝authz和passwd，修改两个版本库的svnserve.conf文件，使其验证文件都指到E:\svndemo\repository下的authz和passwd，
password-db =.. /.. /../passwd
authz-db =.. / ../../authz
修改passwd文件添加新的用户，格式为：用户名=密码 例如：user1=user1
[users]
user1=user1
user2=user2
user3=user3
user4=user4
user5=user5
user6=user6修改authz文件可以为用户赋予相应的访问权限
[groups]
# 定义组信息group1 = user1
group2 = user2
group3 = user3
group4 = user4
group5 = user5
group6 = user6[/]
# 指定所有的版本库默认只读，root可读写
* = r
root = rw[project1:/]
# 指定对版本库project1根目录的权限
@group1 = rw #读写
@group2 = r #读[project1:/trunk]
# 指定对版本库project1的/trunk根目录的权限，
@group2 = rw
@group3 = r如果希望管理的目录结构中包含有中文目录，使用UltraEdit-32
[groups]
# harry_and_sally = harry,sally
group1 = user1
group2 = user2
group3 = user3
group4 = user4
group5 = user5
group6 = user6[/]
* = r
root = rw[project1:/]
@group1 = rw
@group2 = r[project1:/01项目]
@group2 = rw
@group3 = r[project1:/01项目/会议纪要]
@group3 = rw
@group4 = r[project1:/03私有分支]
@group4 = rw
@group5 = r[project2:/]
@group1 = rw
@group2 = r[project2:/09发布包]
@group2 = rw
@group3 = r[project2:/09发布包/V1.0]
@group3 = rw
@group4 = r这样我们根据设定的权限在客户端检入检出的时候就可以针对不同的中文目录进行操作。
七、SVN软件配置
忽略文件
在SVN 的[Setting]的[General]中，设置需要忽略的文件以便忽略掉一些临时的、无用的文件，常被忽略的文件有*.opt *.ncb *.suo *.plg *.pch *.idb *.pdb *.scc *.obj Debug Release *.o *.bin *.out *.ilk *.aps debug release *.clw *.bak。每个程序员可以根据自己的需要进行修改忽略文件，上面只是使用VC++与Tornado编程时常用的一些忽略文件。
八、SVN仓库目录结构SVN仓库的负责人规划好仓库的目录结构。推荐的目录结构如下图所示。
E:\svndemo\repository
├─code
│ ├─branch
│ │ ├─lzj_051201
│ │ ├─xw_051206
│ │ └─xw_051208
│ └─trunk
└─doc
├─branch
└─trunk
仓库的一级目录只有两个，分别为code和doc。其中，doc主要用来放置先期的文档，code主要用来放置工程的代码，也可以包含后期的文档。
仓库的二级目录只可以是branch与trunk两个目录，分别存放分支与主干。trunk目录下直接存放工程文件。branch目录下包括一些子目录分别对应各个分支。
本地目录结构
从SVN仓库中取出代码时，一定不要把整个仓库取出来，而应该只取出trunk目录，或只取出branch下的某个分支目录（比如上图中的svn:\\code\branch\xw_051206）。
九、合作开发方法
合作开发基本流程
一个项目会有多个人共同合作开发完成。基本流程是：各开发成员建立自己的分支，并在此分支上开发
各开发成员把分支合并到主干上并形成较为稳定
各个成员重新从主干上建立新的分支，在此分支上开发(即回到第一步)
循环往复，直到工程结束。
下面我用一个例子来说明合作开发的基本流程。
现在xb与lzj两个开发人员要共同开发一个工程onlytest分支的建立
xb与lzj分别在onlytest这个工程中建立两个分支，分别为xb _051115和lz_051115。
在这里分支命名要采用[姓名缩写_6个数的日期_后缀(可选)]的形式，比如xb_051208_1，xb_051212之类的。创建完分支后我们可以看到这个工程的目录结构如下所示：├─code
│ ├─branch
│ │ ├─lzj_05115
│ │ └─test_SVN.txt
│ │ ├─xb_05115
│ │ └─test_SVN.txt
│ ├─trunk
│ └─test_SVN.txt└─doc
├─branch
└─trunk
建完之后， xb和lzj分别在本地取出对应的分支进行开发。
分支的合并
当程序到达一个比较稳定的阶段，就需要把分支合并到主干上，下面讲述一下合并的流程。
在本节中继续使用上一节中所示的工程与SVN仓库讲解。
1.xb与lzj分别修改自己分支上的代码
现在，主干上的test_SVN.txt是空文档。
由xb与lzj修改提交后，两个分支中test_SVN.txt分别如下所示：xb_1
xb_2
lzj_1
lzj_3
2.xb将xb_051129分支合并到主干
xb先把主干check out到本地。然后在主干的目录上右键选择svn->merge，弹出如下窗口：
然后直接点击merge进行合并，你也可以通过dry run来看是不是两者之间有差异。由于没有其它人修改主干，所以合并的很顺利，下图是xb_051115与主干合并后的结果。合并完毕之后，由xb对主干进行提交。xb_1
xb_2
3.lzj将lzj_051129分支合并到主干，解决冲突
xb合并完毕之后，lzj要将他的分支合并到主干上去，方法同上。但是由于xb已经修改过主干，所以产生了冲突，会弹出一个冲突对话框。双击对话框中的产生冲突的文件名，就可以调出工具对此文件进行合并。 首先比较第一个窗口与第二个窗口，把结果修改合并到第二个窗口。
然后确保光标处于第二个窗口时，点击相应的按钮。这样会把第二个窗口的内容全部复制到第三个容口。之后保存，退出。
然后在工程目录上点右键，进行SVN->Resolved。这样会删除无用的临时文件。
最后提交所作的修改，并添加详细的注释。
十一、其它注意事项
SVN中的标签
与CVS不同，使用SVN时不用专门为目录添加标签，因为SVN也对目录进行版本管理。
我们在提交时写好注释（比如重要的版本提交时使用051201之类的日期作为开头），就可以通过注释来查找比较重要的目录版本号，相当于CVS或VSS中的标签。
另外，每个工程都会有一个版本说明文件，通过此文件可以查找关键版本。
文件的删除、移动与重命名
你可以重命名、移动或删除你的文件或文件夹，但请使用SVN进行这些操作，否则之前的版本信息会丢失。
使用SVN删除、移动与重命名文件夹的方法是在文件/文件夹上点右键进行SVN操作，或直接在资源浏览器中使用右键拖放（会弹出SVN选项）。
文件的删除、移动与重命名之前，必须保证工作目录是最新的版本；进行这些操作之后，需要进行提交。
版本的回退
在代码的编写过程中，难免会有不尽人意的地方，你也许需要回退到某一个版本，但是在这个过程中可能有一些文件你想保留，也有一些文件你不想保留，这就牵扯到很复杂的版本管理过程，在这里给大家推荐几种方法。
1. 若是你编辑了工程，在没有提交的前提下，你想放弃这些修改，你可以直接选择revert就可以更新到工程的最新的版本。
2. 若是你想退回到某一个版本，你就可以直接选择update to reversion这样我们就可以把我们的版本回退到你选中的版本去，这种情况下SVN并没有显示出有什么冲突，并且新建立的文件也还在，但是在这种情况下你并不能直接在你回退后的版本上进行编辑，因为SVN的版本控制还是在最新的主干上。我们需要 update并解决冲突。
3. 你可以直接选择revert changes from this revision如图，这样的话你可以直接解决冲突并提交。不过这种方法的不足是，你新建的文件都没有了，整个工程都回退到之前的版本了。
4. 我推荐的一种方法是，直接export一个你需要的版本，然后用你export的版本覆盖你的最新的版本，这样你就可以不丢失你新建的文件，同时获得head的SVN控制文件。
提交的时机
每个工程会有很多个小模块，当某个模块达到稳定的时候，你就需要提交一次，以免写下个模块代码的时候出现不可恢复的错误。
每一次提交需要前，需要通过pclint检查，保证是一个编译没有错误的版本。当提交比较稳定的版本的时候，同时要修改你的版本号。
提交的时候要添加注释，若多人共同修改同一段代码我们就需要为注释添加上更加详细的说明
版本说明文件
版本说明文件为xml表格，可用excel编辑，它会记录下关键的版本信息。
版本说明文件内容如下表。发布版本是指用户对外公布的版本号，后文中有详细描述；Revision是SVN内部的工程文件夹的版本号。一个发布版本可能对应多个Revision： -
QC安装总结
2008-09-24 23:16:15
QC9.0可以安装在XP上
QC9.2必然安装在服务器上
本人安装的为QC9.0
1、请确认你机器上是否已经安装了数据库,如果你安装了是SQL2000,请先检查下版本号.看是否已经打了SP4的补丁.(查看方法,打开SQL企业管理器,点击数据库属性,其中有个产品版本如果为8.00.2039(sp4)
则说明你已经打了SP4的补丁。
2、点击SETUP后，会出现群集配置，请选择“第一个节点/独立”
3、应用服务器配置中选择JBoss应用服务器
4、JBOSS服务键入WINDOWS登录用户名，密码和域。要注意的是域这里我们就填WORKGROUP。
5、WEB服务器配置可以选IIS也可以选JBOSS内部WEB服务器。
6、在邮件服务器属性中，因为我们没有用到邮件服务所以选择无。
7、数据库服务器配置中键入数据库信息。服务器名称你可以打开SQL服务管理器查看。
8、之后输入你的站点管理员用户名，密码。
基本上在安装的时候就这些地方比较容易出错。 -
为sql2000打sp4补丁
2008-09-24 22:20:25
昨天本来是要装QC9.0的，可是连接数据的时候怎么都连不上，把我气的不行了。然后再网上查了下，还有小孩也告诉我要给SQL2000打SP4的补丁,太伤心了然后今天放学回来，就来装SP4的补丁。昨天好笨，我只是把SQL2000-KB884525-SP4-x86-CHS.EXE解压出来而已。我就以为装上了。
然后去查了下数据库的属性才发现SP4根本没有打上去。今天回来后，我又点击setup.bat文件,运行安装. 可是安装到一半又说“写时无法打开指定文件”，又伤心了一下。一气之下，我就把SQL2000给卸载了，然后重新安装。
安装完后，点击setup.bat文件,运行SP4补丁安装.
出现如下语句
以前的某个程序安装已在安装计算机上创建挂起的文件操作。运行安装之前，必须重新启动计算机解决办法：
a、重启机器，再进行安装，如果发现还有该错误，请按下面步骤
b、在开始->运行中输入regedit (一般不必重启,直接从这步开始)
c、到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager 位置
d、选择文件->倒出,保存
e、在右边窗口右击PendingFileRenameOperations，选择删除，然后确认 (到这里其实ok了.)终于费了九牛二虎之力我终于把SP4补丁打上去了。
然后查看数据库的属性终于看到了产品版本中出现了SP4。
虽然只是一个很简单的问题，但是解决了还是很开心的。
-
svnserve.conf:12: Option expected的问题解决方法
2008-09-16 11:00:45
昨天配置基于svnserve的subversion服务器后，
在客户端访问subversion版本库时出现这个错误：
svnserve.conf:12: Option expected
为什么会出现这个错误呢，就是因为subversion读取配置文件svnserve.conf时，无法识别有前置空格的配置文件，如
### This file controls the configuration of the svnserve daemon, if you
### use it to allow access to this repository. (If you only allow
### access through http: and/or file: URLs, then this file is
### irrelevant.)
### Visit http://subversion.tigris.org/ for more information.
[general]
### These options control access to the repository for unauthenticated
### and authenticated users. Valid values are "write", "read",
### and "none". The sample settings below are the defaults.
anon-access = read
auth-access = write
像上面的配置文件中，anon-access是顶行的，没问题，而auth-access就存在前置空格，会导致这个错误。
要避免出现这个错误，应该在去掉这些行前的#时，也要顺手去掉前面的空格 -
CMMI标准名词术语
2008-09-15 21:16:10
CMMI标准名词术语
1 AT Assessment Team 评审小组
2 ATM Assessment Team Member 评审小组成员
3 BA Baseline Assessment 基线评审
4 CAR Causal Analysis and Resolution 原因分析与决策
5 CBA CMM-Based Appraisal 基于CMM的评价
6 CBA-IPI
CMM-Based Appraisal for Internal Process
Improvement
为内部过程改进而进行的基于CMM的评价（通常
称为CMM评审）
7 CC Configuration Controller 配置管理员
8 CF Common Feature 公共特性
9 CFPS Certified Function Point Specialist 注册功能点专家
10 CI Configuration Item 配置项
12 CMM Capability Maturity Model 能力成熟度模型
13 CMMI Capability Maturity Model Integration 能力成熟度集成模型
14 COTS Commerce off the shelf 商业现货供应
15 DAR Decision Analysis and Resolution 决策分析与制定
16 DBD Database Design 数据库设计
17 DD Detailed Design 详细设计
18 DP Data Provider 数据提供者
19 DR Derived Requirement 派生需求
20 EPG Engineering Process Group 工程过程小组
21 FP Function Point 功能点
22 FPA Function Point Analysis 功能点分析
23 FR Functional Requirement 功能性需求
24 GA Gap Analysis 差距分析
25 ID Interface Design 接口设计
26 IFPUG International Function Point Users Group 国际功能点用户组织
27 IPM Integrated Project Management 集成项目管理
28 IR Interface Requirement 接口需求
29 KPA Key Process Area 关键过程域
30 KR Key Requirements 关键需求
31
32 MA Measurement and Analysis 测量与分析
33 MAT Metrics Advisory Team 度量咨询组
34 MCA Metrics Coordinator and Analyst 度量专员
35 ML matreraty library 度量数据库
36 NFR Non-functional Requirement 非功能性需求
37 OC Operational Concept 操作概念
38 OID Organizational Innovation and Deployment 组织革新与部署
39 OPD Organizational Process definition 组织过程定义
40 OPF Organizational Process focus 组织过程焦点
41 OPL Organizational Process Assets 组织过程财富
42 OPP Organaizational Process Perormance 组织过程性能
43 OSSP Organization’s Set of Standard Process
组织标准过程集合
44 OT Organizational Training 组织级培训
45 PA Process Areas 过程域
46 PAT Process Action Team 过程行动小组
47 PB Process Assets Library 过程财富库
48 PD Preliminary Design 概要设计
49 PDSP Project Defined Standard Processes 项目定义标准过程
50 PI Produce Integration 产品集成
51 PLC Product Life Cycle 产品生命周期
52 PMC Project Monitoring and Control 项目监控
53 PP Project Planning 项目策划
54 PPQA Process and Product Quality Assurance 过程与产品质量保证
55 PPR Price Performance Ratio 性能价格比
56 QA Software Quality Assurance 软件质量保证
57 QA Quality Assurance 质量保证
58 QAP Software Quality Assurance Plan 质量保证计划
59 QPM Quantitative Project Management 量化项目管理
60 RD Requirements Development 需求开发
61 RM/ReqM Requirements Management 需求管理
62 RSKM Risk Management 风险管理
63 RTM Requirement Traceability Matrix 需求跟踪矩阵
64 SAM Supplier Agreement Management. 供应协议管理
65 SC Steering Committee 指导委员会
66 SCAMPI
Standard CMMI Assessment Method for
Process Improvement 过程改进CMMI标准评审方法
67 SCCB Software Configuration Control Board 软件配置管理控制委员会
68 SCM Software Configuration Management 软件配置管理
69 SDP Software Development Plan 软件开发计划
70 SEI Software Engineering Institute (美国)软件工程学院
71 SEPG Software Engineering Process Group 软件工程过程组
72 SPI Software Process Improvement 软件过程改进
73 SPP Software Project Planning 软件项目策划
74 SPTO Software Project Tracking and Oversight 软件项目跟踪与监控
75 SR System Requirements 系统需求
76 SRS Software Requirement Specification 软件需求规格
77 SSM Software Subcontract Management 软件分包管理
78 SSR Software System Requirement 软件系统需求
79 TS Technical Solution 技术解决方案
80 UC Use Case 用例
81 UID User Interface Design 用户界面设计
82 VAL Validation 确认
83 VER Verification 验证
84 WBS Work Breakdown Structure 工作分解结构
85 WP Work Products 工作产品
86 Pre-assessment 预评审
87 Baseline 基线
88 Quality Attribute 质量属性
89 Scenario 场景 -
软件开发中常见英文缩写
2008-08-28 14:26:24
文档名称
英文简写
Statement Of Work(工作任务说明书)
SOW
Process Handbook (项目过程手册)
PHB
Estimation Sheet (估计记录)
EST
Project Plan (项目计划)
PPL
Software Management Plan( 配置管理计划)
CMP
Software Quality Assurance Plan （软件质量保证计划）
QAP
Software Risk Management Plan （软件风险管理计划）
RMP
Test Strategy（测试策略）
TST
Work Breakdown Structure （工作分解结构）
WBS
Business Requirement Specification(业务需求说明书)
BRS
Software Requirement Specification(软件需求说明书)
SRS
System Testing plan (系统测试计划)
STP
System Testing Cases （系统测试用例）
STC
High Level Design(概要设计说明书)
HLD
Integration Testing plan (集成测试计划)
ITP
Integration Testing Cases （集成测试用例）
ITC
Low Level Design (详细设计说明书)
LLD
Unit Testing Plan ( 单元测试计划)
UTP
Unit Testing Cases （单元测试用例）
UTC
Unit Testing Report （单元测试报告）
UTR
Integration Testing Report （集成测试报告）
ITR
System Testing Report （系统测试报告）
STR
Requirements Traceability Matrix (需求跟踪矩阵)
RTM
Configuration Status Accounting （配置状态发布）
CSA
Change Request Form （变更申请表）
CRF
Weekly Status Report （项目周报）
WSR
Quality Weekly Status Report （质量工作周报）
QSR
Quality Audit Report(质量检查报告)
QAR
Quality Check List(质量检查表)
QCL
Phase Assessment Report （阶段评估报告）
PAR
Closure Report （项目总结报告）
CLR
Review Finding Form (评审发现表)
RFF
Minutes of Meeting （会议纪要）
MOM
Metrics Sheet （度量表）
MTX
ConsistanceCheckForm（一致性检查表）
CCF
Baseline Audit Form（基线审计表）
BAF
Program Trace Form（问题跟踪表）
PTFCapability Maturity Model for software(能力成熟度模型)
CMM
Pesonal Software Process(个体软件过程)
PSP
Team Software Process(群体软件过程)
TSP
Key Process Area(关键过程域)
KPA
-
CMM概述
2008-08-28 12:37:21
CMM概述
CMM简介
CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMM是是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。
CMM是由美国卡内基梅隆大学软件工程研究所1987年研制成功的，是目前国际上最流行最实用的软件生产过程标准和软件企业成熟度等级认证标准。目前，我国已有软件企业通过了CMM标准认证 。
SW-CMM(Capability Maturity Model For Software 软件生产能力成熟度模型,以下简称"CMM"),是87年由美国卡内基梅隆大学软件工程研究所（CMU SEI）研究出的一种一种用于评价软件承包商能力并帮助改善软件质量的方法，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。
其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件生产中的困难。CMM它是目前国际上最流行、最实用的一种软件生产过程标准，已经得到了众多国家以及国际软件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容。
CMM目前通用流行的版本是1．1（Version1．1）。《按照软件工程研究所（SEI）的原来计划，CMM的改进版版本2．0（V2．0）是要在1997年的11月完成的。但是，美国国防部办公室要求软件工程研究所（SEI）延迟发放公布CMM版本2．0，直至他们完成另一个更为紧迫的项目-CMMI。
CMMI(Capability Maturity Model Integration能力成熟度模型集成)，是美国国防部的一个设想。他们希望把所有现存的与将被发展出来的各种能力成熟度模型，集成到一个框架中去。这个框架用于解决两个问题：第一，软件获取办法的改革；第二，从集成产品与过程发展的角度出发,建立一种包含健全的系统开发原则的过程改进。
CMM为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架；它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序，一步一步的做好这些工作而使软件组织走向成熟。
CMM发展
CMM框架用5个不断进化的层次来评定软件生产的历史与现状：其中初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程。任何单位所实施的软件过程，都可能在某一方面比较成熟，在另一方面不够成熟，但总体上必然属于这5个层次中的某一个层次。而在某个层次内部，也有成熟程度的区别。在CMM框架的不同层次中，需要解决带有不同层次特征的软件过程问题。因此，一个软件开发单位首先需要了解自己正处于哪一个层次，然后才能够对症下药地针对该层次的特殊要求解决相关问题，这样才能收到事半功倍的软件过程改善效果。任何软件开发单位在致力于软件过程改善时，只能由所处的层次向紧邻的上一层次进化。而且在由某一成熟层次向上一更成熟层次进化时，在原有层次中的那些已经具备的能力还必须得到保持与发扬。
软件产品质量在很大程度上取决于构筑软件时所使用的软件开发和维护过程的质量。软件过程是人员密集和设计密集的作业过程：若缺乏有素训练，就难以建立起支持实现成功是软件过程的基础，改进工作亦将难以取得成效。CMM描述的这个框架正是勾列出从无定规的混沌过程向训练有素的成熟过程演进的途径。
CMM包括两部分"软件能力成熟度模型"和"能力成熟度模型的关键惯例"。"软件能力成熟度模型"主要是描述此模型的结构，并且给出该模型的基本构件的定义。"能力成熟度模型的关键惯例"详细描述了每个"关键过程方面"涉及的"关键惯例"。这里"关键过程方面"是指一组相关联的活动；每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程方面，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域，反之有非关键过程域是指对达到相应软件成熟度等级的目标不起关键作用。归纳为：互相关联的若干软件实践活动和有关基础设施的一个集合。而"关键惯例"是指使关键过程方面得以有效实现和制度化的作用最大的基础设施和活动,对关键过程的实践起关键作用的方针、规程、措施、活动以及相关基础设施的建立。关键实践一般只描述"做什么"而不强制规定"如何做"。各个关键惯例按每个关键过程方面的5个"公共特性"（对执行该过程的承诺，执行该过程的能力，该过程中要执行的活动，对该过程执行情况的度量和分析，及证实所执行的活动符合该过程）归类，逐一详细描述。当作到了某个关键过程的的全部关键惯例就认为实现了该关键过程，实现了某成熟度级及其以低级所含的全部关键过程就认为达到到了了该级。
上面提到了CMM把软件开发组织的能力成熟度分为5个的等级。除了第1级外，其他每一级由几个关键过程方面组成。每一个关键过程方面都由上述5种公共特性予以表征。CMM给每个关键过程了一些具体目标。按每个公共特性归类的关键惯例是按该关键过程的具体目标选择和确定的。如果恰当地处理了某个关键过程涉及的全部关键惯例，这个关键过程的各项目标就达到了，也就表明该关键过程实现了。这种成熟度分级的优点在于，这些级别明确而清楚地反映了过程改进活动的轻重缓急和先后顺序。能力等级
特点
关键过程
第一级 基本级
软件过程是混乱无序的,对过程几乎没有定义,成功依靠的是个人的才能和经验,管理方式属于反应式
第二级 重复级
建立了基本的项目管理来跟踪进度.费用和功能特征,制定了必要的项目管理,能够利用以前类似的项目应用取得成功
第三级 确定级
已经将软件管理和过程文档化,标准化,同时综合成该组织的标准软件过程,所有的软件开发都使用该标准软件过程
组织过程定义,组织过程焦点,培训大纲,软机集成管理,软件产品工程,组织协调,专家审评
第四级 管理级
收集软件过程和产品质量的详细度量,对软件过程和产品质量有定量的理解和控制
定量的软件过程管理和产品质量管理
第五级 优化级
软件过程的量化反馈和新的思想和技术促进过程的不断改进
缺陷预防,过程变更管理和技术变更管理
对于CMM的作用归纳两个主要方面: 科学地评价软件开发单位的软件能力成熟等级; 帮助软件开发单位进行自检，了解自己的强项和弱项，从而不断完善和改进单位的软件开发过程，确保软件质量，提高软件开发能效率。
由于CMM并未提供有关实现CMM关键过程域所需的具体知识和技能，因此，美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI) 以W.S.Humphrey为首主持研究与开发了个体软件过程PSP（Personal software process）和群组软件过程TSP(Team Software Process)，形成CMM/PSP/TSP体系。
PSP 个体软件过程（Personal Software Process）是由美国Carnegie Mellon大学软件工程研究所(CMU/SEI)的Watts s. Humphrey领导开发的，于1995年它的推出，在软件工程界引起了极大的轰动，可以说是由定向软件工程走向定量软件工程的一个标志。PSP是一种可用于控制、管理和改进个人工作方式的自我改善过程，是一个包括软件开发表格、指南和规程的结构化框架。 PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。在软件设计阶段， PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计结束准则，而不是设计方法的选择。PSP保障软件产品质量的一个重要途径是提高设计质量。
PSP能够说明个体软件过程的原则；帮助软件工程师作出准确的计划；确定软件工程师为改善产品质量要采取的步骤；建立度量个体软件过程改善的基准；确定过程的改变对软件工程师能力的影响。
TSP群组软件过程(Team Software Process)指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍。始终以最佳状态来完成工作。TSP实施集体管理与自己管理自己相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对群组开发过程的定义、度量和改进。
TSP致力于开发高质量的产品，建立、管理和授权项目小组，并且指导他们如何在满足计划费用的前提下，在承诺的期限范围内，不断生产并交付高质量的产品。
CMM是过程改善的第一步，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式。企业只有开始CMM改善后，才能接受需要规划的事实，认识到质量的重要性，才能注重对员工经常进行培训,合理分配项目人员,并且建立起有效的项目小组。然而，它实现的成功与否与组织内部有关人员的积极参加和创造性活动密不可分。
PSP能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过PSP学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用PSP，从而有助于CMM目标的实现。
TSP结合了CMM的管理方法和PSP的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与 组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项 目的管理，向组织展示如何应用CMM的原则和PSP的技能去生产高质量的产品。
总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。
CMM的体系结构
一个企业软件能力类似于一个人在一个特定领域的能力，是逐步获得和增长的。如果一个人在其领域的发展过程中能得到一个很好的指南，那么他或她就会不断达到一个个设定的目标，并变得成熟起来，否则可能会盲目发展，离自己的目标越来越远，甚至南辕北辙。一个企业的软件能力发展也同样需要一个良好的指南，SW-CMM正是这样一个指南，它以几十年产品质量概念和软件工业的经验及教训为基础，为企业软件能力不断走向成熟提供了有效的步骤和框架。
框架
SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级实际上是一个起点，任何准备按CMM体系进化的企业都自然处于这个起点上，并通过这个起点向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一个级别迈进。CMM体系不主张跨越级别的进化，因为从第二级起，每一个低的级别实现均是高的级别实现的基础。
1.初始级
初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。2.可重复级
根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐进化和成熟。第二级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。其中项目管理分为计划过程和跟踪与监控过程两个过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。3.定义级
在第二级仅定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出与项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。4.管理级
第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量(包括工作产品和提交给用户的产品)需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正变成为一种工业生产活动。5.优化级
第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果一个企业达到了这一级，那么表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。结构
除第一级外，SW-CMM的每一级是按完全相同的结构构成的。每一级包含了实现这一级目标的若干关键过程域(KPA)，每个KPA进一步包含若干关键实施活动(KP)，无论哪个KPA，它们的实施活动都统一按五个公共属性进行组织，即每一个KPA都包含五类KP。
1.目标
每一个KPA都确定了一组目标。若这组目标在每一个项目都能实现，则说明企业满足了该KPA的要求。若满足了一个级别的所有KPA要求，则表明达到了这个级别所要求的能力。2.实施保证
实施保证是企业为了建立和实施相应KPA所必须采取的活动，这些活动主要包括制定企业范围的政策和高层管理的责任。3.实施能力
实施能力是企业实施KPA的前提条件。企业必须采取措施，在满足了这些条件后，才有可能执行KPA的执行活动。实施能力一般包括资源保证、人员培训等内容。4.执行活动
执行过程描述了执行KPA所需求的必要角色和步骤。在五个公共属性中，执行活动是唯一与项目执行相关的属性，其余四个属性则涉及企业CMM能力基础设施的建立。执行活动一般包括计划、执行的任务、任务执行的跟踪等。5.度量分析
度量分析描述了过程的度量和度量分析要求。典型的度量和度量分析的要求是确定执行活动的状态和执行活动的有效性。6.实施验证
实施验证是验证执行活动是否与所建立的过程一致。实施验证涉及到管理方面的评审和审计以及质量保证活动。
在实施CMM时，可以根据企业软件过程存在问题的不同程度确定实现KPA的次序，然后按所确定次序逐步建立、实施相应过程。在执行某一个KPA时，对其目标组也可采用逐步满足的方式。过程进化和逐步走向成熟是CMM体系的宗旨。 -
上善若水
2008-08-26 09:48:29
上善若水
成语释义
词 目：上善若水 朴实无华现本性 无须出世无须入世 跳出三界外,不在五行中
发 音：shàng shàn ruò shuǐ
出 处：老子的《道德经第八章》:上善若水。水善利万物，而不争；处众人之所恶，故几于道。居善地，心善渊，与善仁，言善信，政善治，事善能，动善时。夫唯不争，故无尤。
[译文]
最善的人好像水一样。水善于滋润万物而不与万物相争，停留在众人都不喜欢的地方，所以最接近于“道”。最善的人，居处最善于选择地方，心胸善于保持沉静而深不可测，待人善于真诚、友爱和无私，说话善于恪守信用，为政善于精简处理，能把国家治理好，处事能够善于发挥所长，行动善于把握时机。最善的人所作所为正因为有不争的美德，所以没有过失，也就没有怨咎。
[注释]
①上善若水：上，最的意思。上善即最善。这里老子以水的形象来说明"圣人"是道的体现者，因为圣人的言行有类于水，而水德是近于道的。
②处众人之所恶：即居处于众人所不愿去的地方。
③几于道：几，接近。即接近于道。
④渊：沉静、深沉。
⑤与，善仁：与，指与别人相交相接。善仁，指有修养之人。
⑥政，善治：为政善于治理国家，从而取得治绩。
⑦动，善时：行为动作善于把握有利的时机。
⑧尤：怨咎、过失、罪过。
[引语]
在上一章以天地之道推及人道之后，这一章又以自然界的水来喻人、教人。老子首先用水性来比喻有高尚品德者的人格，认为他们的品格像水那样，一是柔，二是停留在卑下的地方，三是滋润万物而不与争。最完善的人格也应该具有这种心态与行为，不但做有利于众人的事情而不与争，而且还愿意去众人不愿去的卑下的地方，愿意做别人不愿做的事情。他可以忍辱负重，任劳任怨，能尽其所能地贡献自己的力量去帮助别人，而不会与别人争功争名争利，这就是老子“善利万物而不争”的著名思想。
[评析]
老子在自然界万事万物中最赞美水，认为水德是近于道的。而理想中的"圣人"是道的体现者，因为他的言行有类于水。为什么说水德近于道呢？王夫之解释说："五行之体，水为最微。善居道者，为其微，不为其著；处众之后，而常德众之先。"以不争争，以无私私，这就是水的最显著特性。水滋润万物而无取于万物，而且甘心停留在最低洼、最潮湿的地方。在此后的七个并列排比句中，都具有关水德的写状，同时也是介绍善之人所应具备的品格。老子并列举出七个"善"字，都是受到水的启发。最后的结论是：为人处世的要旨，即为"不争"。也就是说，宁处别人之所恶也不去与人争利，所以别人也没有什么怨尤。
《荀子·宥坐》记载了孔子答第子子贡问水的一段对话："孔子观于东流之水。子贡问于孔子曰：君子之所以见大水必观焉者，是何？孔子曰：夫水，偏与诸生而无为也，似德。其流也埤下，裾拘必循其理，似义。其洮洮乎不屈尽，似道。若有决行之，其应佚若声响，其赴而仞之谷不惧，似勇。主量必平，似法，盈不求概，似正。淖约微达，似察。以出以入，以就鲜洁，似善化。其万折也必东，似志。是故君子见大水必观焉。"在此处，孔子以水描述了他理想中的具备崇高人格的君子形象，这里涉及到德、义、道、勇、法、正、察、志以及善化等道德范畴。这其中的观点与道家有显而易见的区别，但也有某些相似之处。可以此段引文与《道德经》第八章参照阅读。 -
遇到任何事情都要挺住
2008-08-23 21:22:22
暂无
