首页>>技术前沿>>B/S,C/S软件系统开发
一个软件项目的成功,不是只是取决于软件开发人员
作者:西安软件开发公司 | 原创 来源:西安软件开发公司 | 时间:2013年12月21日| 点击:0次 | 【评论】

在西安软件开发公司中,往往很多公司都会遇到,开发的软件不满足客户的需求问题,事实上也是这样。其实这种问题,不仅仅是在西安软件开发公司中出现,全国的软件开发公司也有这种问题。一个软件项目的成功,不是只是取决于软件开发人员,这不仅需要客户的配合、软件测试人员的配合、业务员的配合等。

西安软件开发公司

1.人员参与需求评审,确保需求的可测试性

需求的描述要详细到可测试的程度,所谓可测试即测试人员阅读了需求以后可以编写出测试用例,能够识别出输入、操作流程、处理逻辑及预期的输出。测试人员参与需求的评审关注的就是需求的可测试性,如果一个需求不可测试,则说明该需求描述的不够明确。

2.功能点方法度量软件规模,确保需求描述的明确性

功能点方法不仅仅是一种规模度量的方法,还是一种需求验证的方法,如果存在两个人功能点分析师对同一需求计算出的功能点不一致,往往是由于需求的描述不够明确而导致的。在需求阶段,通过度量软件的规模可以促进对需求的沟通、理解从而发现需求中模糊、有争议的地方。

3.给客户讲解需求及演示界面原型的方式让客户确认需求

需求每经过一个传递,就会发生一次误传,要么信息有遗漏,要么信息有错误,通过需求的确认可以及时发现这些错误,及时纠正这些错误。开发人员给客户讲解对需求的理解、给客户演示界面原型以及在开发过程中阶段性的演示半成品都是需求确认的方式。人们只有在看到实际的软件时才能提出更多的需求,这是客观的现实,因此应该多采用原型法来确认需求,这也是敏捷方法中频繁交付这条实践的来源。

对客户的需求可以确认多次,比如首先是初步的需求访谈记录确认,然后是界面原型的确认,再进行高保真的界面原型确认,在项目开发过程中,可以不断的对半成品的软件进行确认,直至最后的验收确认。

4.大小需求的变更都应纳入变更控制的流程

需求总是渐变的,对于大变更、小变更都纳入需求变更的流程,很多项目往往忽略了对小变更的控制,积少成多,最终导致需求、设计、代码的不一致。需求的变更可以分级控制,明确划分不同级别的需求变更,级别不同审批的流程与权限可以不同。

此内容DOC下载 此内容PDF下载

【全文完】
0 (0)
0 (0)

版权声明:

1、陕西弈聪网站内容中凡注明“来源:XXX(非陕西弈聪网站)”的作品,转载自其它媒体,转载目的在于传递更多信息,其中涉及的网站建设,网站优化,百度关键词优化,西安软件开发等技术细节并不代表本站赞同支持其观点,并不对其真实性负责。对于署名“陕西弈聪”的作品系本站版权所有,任何人转载请署名来源,否则陕西弈聪将追究其相关法律责任。

2、本站内容中未声明为“原创”的内容可能源自其它网站,但并不代表本站支持其观点,对此带来的法律纠纷及其它责任与我方无关。如果此内容侵犯了您的权益,请联系我方进行删除。