一个专家级问题

newwp 2001-08-21 05:41:55

在整个软件过程中，贯穿其中的有一个过程就是变更控制，请问各位大吓在变更控制上有什么好的流程介绍一下！

...全文

179 点赞收藏 24

写回复

24 条回复

切换为时间正序

当前发帖距今超过3年，不再开放新的回复

发表回复

newwp 2001-08-24

OK
我现在开始给分，大家看看有没有收到

回复赞

FireKylin 2001-08-24

你要先回复一篇文章，然后就可以给相应的帖子加分了，分配好分数后，在给分按钮边上

要输入密码，然后点击给分按钮就OK了，呵呵。

回复赞

FireKylin 2001-08-23

我们这里测试主要是黑盒测试，基本上是根据功能清单写测试规程、编写测试用例。

没有具体的编写规定（还是很不规范的）

回复赞

newwp 2001-08-23

FireKylin(冷)　
非常感谢你提出的这个变更控制流程，我会先试用一下，如果工作中出现什么难题，希望还能向你请教。。
对了，不知贵公司对于在测试控制时中的测试用例文档有没有规定编写呢？

回复赞

bland 2001-08-23

TO　newwp(风之狼)　：呵呵，我也是昨天才知道，把分给到“得分”，然后到贴顶端，有一给分按钮

回复赞

newwp 2001-08-23

FireKylin(冷)　
谢了，我该如何给分呢？

回复赞

FireKylin 2001-08-23

需求变更一般是由新增功能和发现故障，这里的Duplicated状态主要是针对故障而言的，

有些故障现象可能反映的是同一个问题（通过对故障现象进行分析），这时候就把这类

变更请求转入Duplicated状态，并指明与先前哪个变更关联。

回复赞

newwp 2001-08-23

to 安妮
在项目时间比较紧的情况下，一般都是采取开发后补文档的方法，因为文档是一定要留下的，这是方便日后的维护和升级。
或许有些公司有专门的部门管理而效果一般，但现在要按着这个趋势走下去，毕竟管理是一门太难的学问，只有不断实践，才能见到效果。

回复赞

xxn_xxn 2001-08-23

看看XP是如何对付需求变更的——
XP的开发者拥抱需求变更，条件是客户必须随时在编程现场。客户可随时调整需求，变更优先级，在任何时候都可提出需求变更意见。交流的方式是 :将User Story 写在卡片上。

任何时候需求的变化都是不可避免的。文档和程序代码脱节是太平常的事。规范公司行为能解决问题吗？不能，只能应付开发时间宽裕的项目。而现在的项目开发时间往往很紧，怎么办？肯定要舍文档而顾代码了，毕竟代码才是真正需要运行的东西。

我想关键在项目经理这边。
不过公司有专门的部门进行管理。效果一般。

回复赞

newwp 2001-08-23

FireKylin(冷)　
不好意思，关于最后那个Duplicated状态还有点不清楚，当前变更与以往变更请求同一内容是指同一项目软件过程中吗？如果是的话，当前变更或许相同内容，但是所冒风险和资源消耗可能不同，难道单纯复制就行了吗？

回复赞

024h 2001-08-22

需求变更是正常不过的，开发过程中不大可能会如你所写的那个变更控制流程发生变更，实际永远是实际。事情是离散的，我的感觉是把握一个基准：目标软件或者软件开发过程的最终目的，考虑变更可能的影响，（如将一个石筷扔进水里，整个湖面都会发生变化。）还有稳定下来的过程，不要企求一步到位。科学全面的考虑，以开发过程中发生的实际为基础，理论为指导（通过理论知道该做哪些事和推荐的方法）。

回复赞

AutoAsm 2001-08-22

软件过程本身所产生的变更？是对软件过程的改进吗？采用新的开发流程？
公司方面在整体调整时所提出的变更？请具体解释一下。

回复赞

newwp 2001-08-22

对了，其实在下有一个原始的变更控制流程，不过总觉得在实际上不能得到一个很好的实施。
变更控制流程如下，希望得到各位大吓的指教：
提出变更请求——》收集变更请求——》变更分析评估——》审批——》变更执行——》版本出库——》变更确认——》版本严整——》变更发布

回复赞

newwp 2001-08-22

　AutoAsm()　
我想你对我说的变更可能有一点概念上的分歧，我所说的变更来源于三个方面，一个当然就是你所说的客户需求变更，一般这类型的变更如果得到领导批准所引发的连锁反应就包括了需求分析变更，详细设计变更，代码变更，可能包括概要设计变更。
但是另外两个变更来源就是软件过程本身所产生的变更，和公司方面在整体调整时所提出的变更。这两种变更对于整个软件过程的影响较前种小，但也不可忽视。从上回答可看出你在软件工程上有一定的研究，不知你是否有对于软件变更控制的一个流程呢？

回复赞

bland 2001-08-22

。规范公司行为很重要。
一件事出来了，怎么处理，如果公司有规程，按照执行就行；如果没有，那就只能完全靠管理人员当时的能力状态动机等等来处理，这样常常容易失控
。在规范公司行为的基础上严格执行。
对于系统开发成立专门的独立质量检测组，发现小问题，及时协调项目管理者内部解决，发现流程不对，马上向高层报告，整体协调解决。任何人想修改原流程，必须得到主管许可，特别是项目变更控制小组许可，严禁私自随意修改。
//项目变更控制小组成员一般有项目负责人，系统分析员，质量检查负责人，软件版本管理负责，测试组负责日兼职管理

回复赞

FireKylin 2001-08-22

怎么保存后与原先的不太一样了，有点错位，可以把上面内容拷贝出来放到notepad里看，就好多了。

回复赞

bland 2001-08-22

to AutoAsm()：　佩服！

回复赞

FireKylin 2001-08-22

我们的变更流程大概是这样：
------>postpone--------------
| ^ |
| |<--rejected |
| | | V
submitted-->Assigned-->Opened-->resolved-->closed
| | | |
| V | |
---------------->Duplicated<-----------
其中，目前无法完成的变更或者是没有必要完成的变更进入PostPone状态，
有些变更可能与以往的变更请求是同一个内容，则进入Duplicated状态。
上面是相应Action完成后变更请求所处的状态。
这个流程经过长期实践还是比较有效的。

回复赞