收藏 分享(赏)

软件过程的改进(参考).doc

上传人:a****2 文档编号:3278345 上传时间:2024-02-19 格式:DOC 页数:2 大小:28.50KB
下载 相关 举报
软件过程的改进(参考).doc_第1页
第1页 / 共2页
软件过程的改进(参考).doc_第2页
第2页 / 共2页
亲,该文档总共2页,全部预览完了,如果喜欢就下载吧!
资源描述

1、论软件过程改进 摘要 本文以我近期参加的一个进销存的信息管理系统为背景,讨论一下软件过程的改进。近年来对软件产品质量要求日益提高,而且软件越来越复杂。为了提高软件质量,许多厂家都在改进自己的软件生产过程。改进软件产品的生产过程能够改进软件产品质量,是基于生产中的产出物(包括各种文档、代码等)能够保证质量,生产出的软件产品也就能够保证质量。 此系统的用户为一家大型外企,它要把产品从国外运到国内出售,此系统就是负责管理进货、销售、库存各环节。另外,它还要跟用户国外工厂的系统有联系,本公司在软件项目管理有些问题,针对这些问题谈下体会。 正文 这是一个进销存的系统,我在项目中担任系统分析和设计。用户为

2、一大型外企,系统是有两部分,一部分是进销存的管理系统,一部分是接口。由于国外工厂是按定单生产的,所以这边需要把采购的定货信息及时发到国外工厂,以便工厂进行生产。国外工厂的系统与用户国内的SAP系统有接口,所以此系统是通过SAP系统与国外工厂的系统交互数据。SAP是一种大型企业信息管理系统,用户的SAP系统还与用户其它的系统有接口,所以此系统设计时需要符合它们的公共规范。此系统还会从SAP接收共用的基础数据,有四种数据是发给SAP的,有五种数据是从SAP接收过来的,两个系统的通信是通过wbi的MQ来实现的。而wbi与SAP系统和此系统是通过文本来交互数据,在指定时间SAP将要传给本系统的数据生成

3、文本放到指定目录。在检测到文本文件后,wbi将会生成MQ,MQ发到本系统服务器上的wbi,wbi会把MQ转成文本文件,本系统将其数据读入到数据库。同样,本系统也会通过同样的方式把数据发到SAP。 在进销存管理部分,业务人员会根据系统提供的库存,销售的信息,制定定购的数据,这些定购数据会在固定的日期(每周五)发到SAP系统,通过它传到工厂系统里。 本公司在软件项目管理存在一些问题,现说明其中两点: 1、 需求管理问题 需求管理一直是个重要问题,为用户开发的系统最终是给用户用的,如果做出的产品不是用户要的,那项目肯定就是失败的,在这个方面,公司以前的项目存在丙个方面问题。 (1)项目成员之间对需求

4、理解不一致 在做需求分析时,大家会将要求记录下来。由于某些原因,如:用户的需求会不断变化,有可能转变成以前舍去的需求,还有项目组成成员考虑事件的立足点不一样,这些都会造成理解的不一致。虽然大家可以看文档,但这就存在版本冲突的问题。由于理解不一样,使得项目组之间时常出现争论,以致时间不必要的浪费。 举例如下: 在用户发给国外工厂的定单中有两种,一种是真实的定单,就是说用户需要定这么多货,不会再更改。另一种就是定未来的货。定单的发送是有周期的,如果某种产品定货周期为一周,那么就是这周要定下一周的货,这是确定不会再更改的,但是对于下周以后的货就算是未来的定单了。用户后来想把未来的定单也加到真实的定单

5、里,以便工厂能准备多一点产品,但是用户又改变主意,不加了。项目组组员,关于加还是不加这个未来定单产生分歧,发生讨论、争辩,其实问题并不复杂,只是白白浪费了时间。 所以在此次项目,我们引进了Rational工具。当然Rational是个集成了很多功能的工具,我们使用需求管理这块功能,可以将需求分类、统计、关连有关系的需求,能追溯需求变更的历史。有了这个工具,项目组就很少讨论、争辩,大家都能共享这些数据随时取得最新最正确的需求。 (2)用户需求变更 用户需求经常变动,是很常见的。究其原因,是用户向我们提供的需求经常是片面的,因为用户没有亲身体验最终系统,他们也无法知道那些具体的需求是他们要的。通常

6、我们会拿需求规格说明书与用户讨论每个细节问题。由于是基于文字,有时效果不好。因此我们做了个原型让用户先期体验,虽然作原型花费了些时间,但是值得的。因为用户通过对原型的了解,就能更进一步的确定自己所需求的最终产品,而不必总是用空洞文字来描述具体产品的模型。 还有一些需求变更,是用户自身原因,如他们当初没有考虑清楚,随便跟我们谈了,事后又觉得不妥,要求更改设计。如:用户跟我们讨论如何跟国外工厂接口时,工厂需要这边在固定的时间把数据发过去,要求的是每月第四个工作日,当初给我们提到是第四个工作日,是按用户自己内部的日历计算的。一直到集成测试时,我们才发现工厂要求的第四个工作日是按照自然日历计算的。由于

7、我们使用了Rational需求工具,通过查询,查出原来客户的需求,用户最终承认没有说清楚,使我们能拿到时间去修改新的需求。 2.程序Bug的跟踪 从程序开始单元测试直到最后的用户测试,都伴随着对程序Bug的查找和修改。但是在项目组里同样的Bug重复出现。这中间的问题有可能是没有按照编程规范造成的,也有碰上了技术上的问题。就如COM对象的释放问题。在.Net里,托管程序是不会去释放外部引用的COM类的对象的,需要手工释放,并要手工调用垃圾回收,否则,每个COM对象都没有释放,一直占据着内存,直至内存不足至系统崩溃。 更多的问题,是有些程序员碰到过的一些问题,他自己已经解决了,后来这些问题又出现在

8、其他程序员身上,其他的程序员不知道这些问题已经解决了,而去花费了很多时间去找解决方法。特别是到了工程后期,陆陆续续完成工作的成员会撤出,会给继续工作的成员带来不必要的时间上的花费。 为此,为了跟踪Bug及各种未完事项,我们引进了Jtrac工具,它是个开源的Bug跟踪工具,通过它,我们可以在发现Bug后,将它们详细记录在Jtrac的数据库里,此工具还能通过email,把Bug的相关信息发给相关人。在解决完这些Bug后,记录下详细的解决过程,并将关闭这些Bug记录,会自动归类到已解决的Bug类里,同时也会发email给相关人员。在今后发现Bug时,可以通过其搜索功能检索是否已经出现过类似问题,并找

9、到其解决方法。此工具能对Bug进行各种分类、统计等功能。 虽然Rational也有Bug跟踪工具,由于Rational比较昂贵,而Jtrac是开源而且免费的,自然就选用Jtrac,当然,开源免费的Bug工具不止这一个,还有很多。 在基于以上的讨论,在我们改进软件过程中,使用有效的工具管理是很有必要的。Rational是个很不错的工具,它提供了从需求、分析到设计的功能,还能生成程序的框架。Rational不足的地方是它比较贵,在小型项目上使用不是很经济的。 以上讨论的关于两个在软件过程中需要改进的地方,只是软件过程改进中的一部分,在整个项目中还会有许多需要改进的,需要我们在实践的基础上,发现它们,并找到解决方法,改进它们。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 教育教学 > 考试真题 > 新建文件夹 (4)

copyright@ 2008-2023 wnwk.com网站版权所有

经营许可证编号:浙ICP备2024059924号-2