国内项目中可以采用的软件工程手段

国内项目中可以采用的软件工程手段 51Testing软件测试网'W/Icd6UN

CSDN 10jqkA（原作） 
)uz v/C|7F|R0
!obchlka0关键字软件工程CCB开发 51Testing软件测试网g Y*d@8E$mP
51Testing软件测试网c{x R*W8f5^
51Testing软件测试网hvpsP/n
51Testing软件测试网;|\uZ,]gD5?J4P
前言51Testing软件测试网8VJW~F6`x
为更好地开发软件，必须在项目组中引入一些软件工程手段和方法。本文试讨论了无论公司情况如何，一个项目经理都应该可以在项目组中实行的一些手段和方法；当然，公司情况良好则有更加可行的、更多的方法可以选择；这里只讨论了最差情况下可以采用的方法。
TMK:O2D)Y.U0
,VXo6ua0本文按照最简单的瀑布模式的各个阶段分别列举了一些方法，在其他模式中应该也可以采用。51Testing软件测试网ohi'u%[ R3C
51Testing软件测试网b]P*woAm@
需求阶段
\yJl-@!wm-@`B(R0需求的管理应该是贯穿整个开发过程。在这个阶段，可以采用的方法有：
M@0| F@dD
M{R:`2r5?051Testing软件测试网9erEo4]7[r&B
** CCB(变更控制委员会)
)MnoR0ji[$^&T0建立CCB（change control board）是需求管理的前提，否则需求管理将成为一句空话。
&xt.Y%wA'cZE0
#flB'U}y)Le0CCB必须包含客户方的决策人士，项目经理，项目经理的领导，关键设计人员，测试负责人，SQA.等，以5-7人左右为宜。51Testing软件测试网#C4GSW8V'?@.~*n%e9@

9cw6RPK5q8i)r0需求确认，发生变更等活动必须由CCB以会议形式批准。
]4haM[C'N1KN.b051Testing软件测试网lsUd&}^rsR%G4~
CCB对整个项目有最高权力（不仅负责需求变更，还负责听取项目经理汇报、关键中间工作产品评审等重要决策）
[7U E
x3ra2U0
4AO?9[9hVH%|0**需求评审，纳入基线
7hEAhB^{1I0原始需求必须形成文档，被CCB评审，然后纳入基线管理，所有变更都需要CCB评审。51Testing软件测试网?C+AJ9a

S8J Xq3T.h;q0该评审一般步骤：51Testing软件测试网P_ o%FGk D
51Testing软件测试网:v:I"Z6T:R p$b
1.项目经理提出被评审对象，指出受影响、被牵涉对象，评估影响（主要是带来的规模、工作量、成本），提出计划和计划执行人，举出可能风险；
.z p^0?+vv\q0
2}G6a*k0\#I:CZq;~02. CCB来决定是否同意或要求项目经理修改上述项；
[2H0^Du*N051Testing软件测试网\1w%s\8J-G
3.之后，项目经理提交执行情况汇报。51Testing软件测试网GY)j5AX"b/}&apL"L

9a6{;F/R X/a04.最后，CCB指定代表或由SQA进行核实。
u]p-QR.Zc$p^t3M0
"WT:zhtvD0如果变更过小，过多，可以进行周汇总评审。
Q h(v5^q0
0fr9M W2x-I&F0项目计划阶段
Y)E,o;Lv"d4[0{0项目计划是开发的指导或脚本，事实上，在每一个阶段开始时，都应该重新、小范围修订一下计划。
(j
UE;l;X*?)hf,@Y051Testing软件测试网e"`#LXo+H
**选择合适的软件开发生命周期51Testing软件测试网eZ-V#e\
关于生命周期的选择上，一直有而且会有很多争议。目前，国内运用最多的是纯瀑布生命周期；本人的看法是：一定有更好的选择，但这是一个最安全、最少在实际中有争议的选择。
aO'J(E-J:u D3i0
oP3Y;a+F1t;Y0选择合适的生命周期的要点是：一定要有选择原因的陈述—本项目的特点，团队特点，开发特点和公司或部门的特点；该问题必须事先在项目组中、CCB内被讨论过并得到一定认可。
1T5e9[%hN \h051Testing软件测试网I?+Cv X4Jh^
**划分阶段--小里程碑51Testing软件测试网_B{8OI*H"I
根据选定的生命周期模型，考虑到可以投入的人员，各个开发阶段就呼之欲出了。每个阶段的结束一定是一个里程碑。如果里程碑超过一个月，那么应该在每经过一个月左右选择合适的点作为小里程碑。
jj B-E faM h0Q$H hH0
&w@YT7lCQ0每达到一个里程碑时，项目经理应该提交本阶段工作报告，一般应该包括：
ri?3E,Q8S[051Testing软件测试网([w+_%SM5c(S/g
1.本阶段活动统计和估计的数值和它们差异的原因
#ez*PIva"x0
m~}#T9B/B;Puxqh02.工作产品完成情况51Testing软件测试网!n\-oPPHX:V8}:yy
51Testing软件测试网SSLlTe
3.需求变更情况统计51Testing软件测试网,N$dn+z)f4Hqj
51Testing软件测试网QQ9wKS
4.问题及其解决情况的统计
7g(o
PoDo(?0
)tw2||(@r
a05.总结优点和缺点，指出对下一步工作的影响
:ni,@Yd)rM051Testing软件测试网
D7gvEEU
CCB听取该报告并评价该阶段工作。
5EEY:Z"}w051Testing软件测试网nWFW|7S
小里程碑可以防止项目失控，使项目经理、项目组和其上的管理层能够正确认识到项目进展情况，并能协助项目开展、出谋划策，项目可视化好；避免项目发生大问题。
!~$eq J0\U)Y*_051Testing软件测试网 K4Rxvw+U
**决定工作产品和含中间工作产品51Testing软件测试网DSBn4?K.d,X
在最混乱的项目中，工作产品和中间工作产品都没有被明确定义，或者可以朝令夕改，随意添加或去除产品。决定工作产品和中间工作产品，是为了确定各个产品的重要性，计算其上的工作量以合理地投入足够的、合适人员来开发它。51Testing软件测试网x:r6|7?6rb'X*y2h

LX"L6E:gO5iu^x0**项目工作分解51Testing软件测试网![I} a3H C3FO
一般是将系统分解成模块甚至更细，要分多细由项目经理或分析员根据实际对项目产品的认识和人力、进度的压力而定；一个忠告：开始做的细、做的认真，以后的工作都会相应容易很多。
!@8Ma8i1f+l1X0v051Testing软件测试网Kk(XG@'k"m
一般人只分解产品。实际上，管理工作也应该分解的，而且也比较容易作。51Testing软件测试网p-RVD s-vLZ
51Testing软件测试网*B2t I1K{/c.E%X`S
**估计51Testing软件测试网6x*j7T6qs#_)m
估计常常被忽略掉，因为估计的结果往往会严重超出预算，让人大吃一惊。而到了最后，结果又往往接近当初估计的数字。51Testing软件测试网2l^+}
|5Oz

`{C'RO;J'Q0估计应该每个阶段作为更新计划的一部分进行一次，每个新的估计都会更加准确。51Testing软件测试网l-a2z `3N(C(n

%G(I!]Q R5n6|4s8e0估计应该选取有经验的人士参与，应该选择合适的方法51Testing软件测试网 Igr @VI-}?7t
g(H
51Testing软件测试网ZM2pbS
估计的结果应该用于指导编制下一阶段的计划，即使不被正式接受，项目组也不应该忘记这些数字，时刻作为参照。
8Jxc5D1}+`?_M2y0
^#ps2Jm;a0**明确职责—团队建设51Testing软件测试网#i?6fCR)iNH
根据项目特点和人员特点，应该选择合适的模式来组建团队进行开发，每个人都应该有明确的责任和工作。
KVw]9]cuk:F0
E#P4H(vzQ(J*R(?3H0最低限度，每个人都应该有明确的责任和工作。51Testing软件测试网3}1Hxax?d;@

C`T3}V V^0**约定沟通方式、渠道51Testing软件测试网"N$W:I(] r ARxp
建立沟通渠道这一条可以不成文，但要成规矩。沟通渠道应该开放，畅通。为每个人指定汇报的领导、汇报的周期、汇报的方式和越级汇报的领导、条件和方式。
!]tp[#dJ9pK0
~6lfj] H1kNc0o2p0建议在项目中开展项目日志，周报制度，具体的方式方法可以参考PSP,TSP。该制度的要点是：日志首先是对自己负责，不能作为评价员工的依据，它是属于成员“开放的隐私“。如果要求每天填满8小时工作，这样的日志没有任何意义；事实上，在本人的项目组中，根据日志，一般没有人每周投入工作的时间超过35小时，平均只有28小时左右—当然，你依然可以看到他们每天都很忙碌的样子，有时还有加班呢。51Testing软件测试网 x@P S
P+p |E
51Testing软件测试网/E,f o.Xo#RI sh
周例会制度是本文推荐最有可行性的软件开发管理手段。每周用1-1.5小时左右，每个人简要汇报本周工作和下周计划的工作，工作中的问题和难点，这时，他会得到整个项目组的建议和帮助；项目经理可以印证了解到的项目进展情况；团队气氛由此加强。如果还有很多富余的时间，项目组可以讨论一下开发技术、技巧，进行一些技术交流。
m b m%dl
J0
d`n7J&b6N
p0总之，沟通不足是软件开发中很大的问题，而且越是大项目就越严重。
{#iu1`&x/u5{051Testing软件测试网 j{#{[+uO8E:y+O8t
**约定开发纪律、规范51Testing软件测试网7} [ZMf5n(x
没有规矩，不成方圆。项目组一定要有一些纪律，不能完全依靠自律。51Testing软件测试网'f
CrVPHbN?6X

'fY\|0p0这方面，有公司文化、氛围积淀为基础是最好，否则就应该制订一些规矩了。51Testing软件测试网h#e7Qs+NFk

6C4X8j$gO^0这也是保持团队的重要组成部分。51Testing软件测试网D+\nH3~#RC#E
51Testing软件测试网 Ur7y7Qm~\p y
至于开发规范，根据项目不同而有所不同，要点是：必须有，哪怕不完美！51Testing软件测试网|[.J&]%~ O;n

uTU8A~M,y0而且，应该开诚布公，尽早公示。51Testing软件测试网9?@yexzX,Ck

4a0_.g0q \6L0**风险估计和预备应对计划
CI3{1_ |EC0风险估计应该每个阶段都进行一次，一般是根据风险列表，大家一起来估计。51Testing软件测试网 Wq'S;Jt-K cz
51Testing软件测试网 ^ B*A.~.c7~ n6y4z
其实也是让大家充分认识到项目的处境和潜在的困难。51Testing软件测试网7v.i2r8P&yl

^6^4k0L5lSt'wJ0这件事，做了总比不做好。
/D`~o'_!rO5j0
J3c8WN;V0** CCB评审项目计划
c4I C~.^'^G0项目计划必须得到CCB会议形式的认可，否则一定会有问题！
hUIB)U,i [&`;RK0
PCO+HL"R(J0设计阶段
m+FgROd%z"H$j0**周期性内部评审和走查
,NR4PK(Z:A1`
c$mS0在这个阶段，周期性内部评审和走查的目的更多是为了交流，检查模块间是否能够协作、是否有矛盾和遗漏，作为平时非正式沟通的一个强有力的补充，大家取长补短，集思广益，几个人的脑袋总比一个脑袋强；第二个目的是质量控制。第三个目的才是控制进度。
M]~}-nX:p-A;@051Testing软件测试网n pj+O T4Oh`
根据上述特点，评审自然应该采用会议方式，也许会有人觉得冗长、拖沓，浪费了一些人不必要的时间；但是该方式的效费比非常好，是值得的；至于组织会议的人，一般是项目经理，应该多动脑子，调动大家的积极性。有人会提出使用checklist的方式，本人的经验是：该方式削弱了沟通量，而且需要良好的制度的支持，否则容易走形式。
v9oMa*K,H.m2S;l0
VXv!F6y0**项目跟踪
7K\h:~-Q6l$F9k0项目计划制订后，项目跟踪工作就要开始了。跟踪表应该每周填写，这样项目中的问题会被及时发现；而且最好不要用project跟踪，而是自己制作一张或寻找合适的软件。一般是根据项目计划制订，有下列内容：任务包，计划的规模、工作量、进度，实际的规模、工作量、进度，二者的误差以及原因分析。
*v~;i"Vs c0
0qR#[#[md2KlD0任务包完成的百分比应该如何填？本人的标准是：如果只是听成员汇报，没有100%完成的都是0%，是0-100原则；听了成员汇报，自己简单察看过工作产品的，是0-50-100原则；仔细检查过的，可以参照成员的汇报，按0-25-50-75-100原则填写。如果一个5工作日的工作包，上边写着完成43%，那是一点意义也没有的。
E)C+t?V {0
T3hh3Rmw;JD0项目跟踪的结果用于分析项目进展情况，里程碑报告，务必真实。51Testing软件测试网/y0QSr(^ Mv s
51Testing软件测试网oHI%r)}M!W2z:n)Q
**变更控制51Testing软件测试网\/a?x3q]W9q,Y)\w
变更控制的具体手段请参照需求阶段的原则。在本阶段，一般只是开发人员发现需求不合理，或相互设计矛盾而要求变更。一些非基线变更的控制不需要那么严格，意思是不需要CCB评审，但项目经理要根据实际情况决定是否召集项目组内相关人员的评审。51Testing软件测试网~2~S|S0g_/K4Yn(B\8o&{

lQ%of1NkC k0同时，应该在这个阶段让大家养成遵守变更规定的习惯。
'HU"YLh$C/K?I$aK051Testing软件测试网6t^Heg3h&VP
编码阶段51Testing软件测试网y4d-["a sckP
**重新进行工作估计，有必要时修订计划51Testing软件测试网9LzKrQ
进入到编码阶段，对项目的认识已经非常清晰了。根据设计，甚至可以计算出未来的代码行数。重新进行工作估计，可以更好地分配人员到合适各人技术特点和兴趣的方面，提高项目组的积极性；同时，可以使管理层清晰认识到项目进展的真实情况，做出正确的决定或避免他们做出错误的决定。51Testing软件测试网^Y*e1Z*B1EqV
51Testing软件测试网$c~R8ME
51Testing软件测试网#Szh$[F0k
51Testing软件测试网
]ub8g4V
**标准制订和培训
6~k+TD)D!kV'LCa0编码的标准在现在已经逐渐趋向统一，但是仍然有必要在项目组中推行或制订编码标准。51Testing软件测试网'Qf$]%EC:J!ck7G.l

a#U$t7K,^,~0统一的编码标准，可以使项目组内可以容易地互相协助、交流，为走查、测试等工作奠定良好的基础。
_:IIihzc9U0
'V}-cyX9X8t}0编码标准制订后，首先要进行项目组内培训。不过与其说是培训，不如说是讨论和统一认识，建立未来强制执行和检查的前提。（不教而诛谓为虐，教而后诛谓为化）
O:gg'm$g@"y051Testing软件测试网] x;o[^vkx1q t
**周期性走查51Testing软件测试网5S&EI/Pla8g9P,e
根据经验和一些统计数字，走查的效果要优于测试。
+e5o;X$m5Er0
dw(Y/D`kN0走查要以统一的编码标准为基础，反过来，统一的编码标准也是通过走查而在项目组中建立起来的。本人的经验是：开始时，安排每周2次走查，每次1小时，只检查一个人的一个功能，重点是编码标准，其次是BUG；大家可以通过走查学习他人的优良风格，改正自己的不足；两周后整个项目组基本上风格就统一了，这之后就应该把重点放在程序功能上，其次是BUG。
2Px7~5q|+nZ0
`:t*bgA0**周创建或日创建51Testing软件测试网y!WF V4a/O
**项目跟踪
k+@-G ISm9q0项目跟踪在本阶段较容易，因为量化的东西比较多，虚的东西比较少。基本方法与上个阶段相同。通过跟踪，已经可以看出那些模块在上个阶段没有设计好。
_*M$rp8L.ca5n_2v#y){0
5P7`P7n7T,kE0跟踪要有分析，分析有了结果要有行动。51Testing软件测试网+`/q
X,l:`/c|9@
51Testing软件测试网6e2A1zC}DA(c
**变更控制51Testing软件测试网en0G/LJz+k
在这个阶段，一般是开发人员在实现时发现一些设计错误而要求变更；这时，就要求项目经理严格把关，与设计人员、开发人员一起研究是否真的需要变更，还是实现者没有领会设计者的意图。如果需要变更，则要谨慎地研究影响范围，评估损失。51Testing软件测试网F,\$Q7c f$B C

,[8o-v]m G)j6x0在这个阶段的中、后期，随着部分产品逐渐成形，客户会提出变更要求；此时要注意原则，同时要搞好关系，当然，首先是原则—CCB同意。
FbS%k:] l051Testing软件测试网%yg*S(V"B
**版本控制
kn#[o[TQ0事实上，版本控制在项目一开始时就应该展开，但未必所有的项目组都能够做到，能做好的就更加寥寥无几了。但在编码阶段，则最好要进行版本控制了，良好的控制机制可以减少很多无用功，甚至避免一些灾难。51Testing软件测试网0kb DL/r0J/xvly9j;?

hpO`!I0良好的版本控制不是来自好的版本控制工具软件，而是版本变更控制的制度以及因此形成的良好习惯。建立一个成文的规定或规范并保证它的实行，才能使版本控制不流于形式。
j4\b:G*Cr\0
|Wfk4d8@&Q0如果进行了版本控制，则建议推行MISRA Rule 10--不得残留被注释掉的废代码。51Testing软件测试网?5m#O,r-f9W0|z Z

#hy:ot#V[N'\0常用的版本控制工具有VSS,CVS,rational套件中的clearcase也很好，只是会用会配置的人不多；UNIX下开发时，它自带的SCCS也是很好用的。51Testing软件测试网{otOV UK{tI
51Testing软件测试网;\}5mY,jkC
测试阶段
`9cA2F:Ey1J5k$L0**制订返工标准和重申纪律
c#m*L$^L0一个糟糕的程序总是会不断地被要求修改，测试工作大部分是由少数几个程序或个别程序员完成的程序引起的。不断地修改的产品无论改多少次都不会变成好产品。51Testing软件测试网O| x(a)`
A)[Y A
51Testing软件测试网z~@$T5~D}
因此，应该制订程序返工标准，一个可以参照的值是15BUG/1000Line。达到了这个标准，直接删除该程序，要求程序员重写；新程序再次达到这个标准时，就换人。而且，应该严格执行这条规定—前提是：该规定在编码阶段就通知了大家。
,FK|`P!]0
hG;\-f p0**日创建
l!a$}/P;I5~6kT0测试阶段的日创建简直是被迫进行的，特别是在初期；否则测试简直进行不下去。
~4J}X\*g&gH0
M1b$GVi3~0但是注意不要丧失原则，为了赶进度破坏了版本控制。
%v8u;I `+g}%v%c#F0

c2EXl
AX1^"H0**变更控制
"o/Yhv]P#k7D6iT0测试阶段是客户提出变更最多的时候，注意不要丧失原则，要坚持CCB评审。必要的变更是必须进行的，但是要仔细评估其影响。匆匆进行的变更既破坏了规矩，也往往破坏了产品。记住一句名言：如果厨师做菜的时间长了，那是因为他想把菜做的更好。
Tu}TM|c051Testing软件测试网0M\*gx-K0g3G~G
**版本控制51Testing软件测试网{/KDz a:r,m`
如果在这个阶段没有一个良好的版本控制行动的话，测试工作一定会有一种混乱的感觉；而且，这是日创建的前提。
Uvj1`~eR"y:m051Testing软件测试网8JqY.j0PF7a
**项目跟踪51Testing软件测试网E7{k5]/`;?+}I A"n/l
项目跟踪在这个阶段是最困难的。因为事情往往琐碎而且交织在一起。项目经理既当裁判，又作记分员，还要是教练、队长，必要时还要亲自上阵。一个好的产品，在测试阶段一定不会一团糟的。
,B S cpe+t|y0
BB?(g?|(VX0但是，需要坚持项目跟踪；积累这个阶段的数据，才能真正评价项目、项目组每个成员、项目采用的技术（包括管理技术）优点和缺点，为公司、个人积累起经验。所以，虽然这个时候项目经理很忙、很累、有很多重要的事情要处理，但还是应该坚持项目跟踪。51Testing软件测试网~T#kHC-ma
51Testing软件测试网pl"[/c)e mJO0])E
项目收尾
W!s5L$Pl.KRZ5H~/H;P0项目收尾时应该进行项目总结，主要是评价项目产品、采用的技术、管理方法、优势、缺点和项目组每个成员。
.VnZ]*F,L051Testing软件测试网&}#H.KaPgRa8y
通过项目跟踪获得的数据可以作为评价的基础，但是不能做量化的评定（分级或者打分），只能是定性的评价—一个尽量详尽的文字说明。总结的目的是面向未来的新项目，而不是惩戒某些人，定量的评价对于下一个全新的任务基本上没有任何帮助。51Testing软件测试网;Z9w!Fh4G

_-S!I.A q'eb0如何能够正确地评价和使用人，依然是一个管理学难题。51Testing软件测试网0b8nq){w x&j4mI