大型软件项目的软件工程管理方法Word文档格式.docx
《大型软件项目的软件工程管理方法Word文档格式.docx》由会员分享，可在线阅读，更多相关《大型软件项目的软件工程管理方法Word文档格式.docx（14页珍藏版）》请在冰豆网上搜索。
项目的成功往往是通过工作组的杰出努力来达到的，这种仅仅建立在依赖特定高素质开发人员基础上的成功，不能保证
全组织的持续稳定的软件生产和质量的长期提高。
因此，要降低软件开发过程的风险、保证软件产品质量，就必须加强管理，而软件配置管理是企业过程改善和能力提升的基础。
本文中采用CVS作为软件项目中进行配置管理的工具，禾I」用它来对项目文档和源代码实现有效的管理。
软件项目监控的目的是通过建立对软件项目过程的可视性，使项目管理者在
软件项目性能与软件计划出现偏差时采取有效的纠正措施，以确保软件过程的质
量满足要求。
优秀的软件过程管理平台是实现在整个项目生命周期中进行项目过程监控的工具保证，这一点尤其在现在大型软件协作开发中至关重要。
本文中设
计了一个软件工程管理系统，它由项目管理系统、Bug管理系统和用户认证系统
三部分组成，利用这个系统，开发者和项目管理者可以更好地了解到整个项目的工作情况，对整个项目过程进行有效地监控。
信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的质量自然成为人们共同关注的焦点。
软件开发商为了占有市场，必须把产品质量作为企业的重要目标之一，以免在激烈的竞争中被淘汰出局。
进行软件测试是质量控制的必要步骤，建立起一套有效的自动测试系统，在软件的开发过程中对软件经常地进行测试，这对软件的开发过程具有非常重要的意义。
最后，组件化的程序设计方法对于软件项目的开发也有着不少的帮助，采用组件技术，可以带来软件模块二进制级的复用。
近几年来，组件在软件开发中得到了广泛的应用，尤其是J2EE和.NET技术将组件应用于Internet，进行各种事务处理，显示出了强大的功能。
本文将对组件技术和基于组件技术的软件工程学方法进行简要介绍。
2.基于CVSC具实现软件配置管理
对于一个软件企业或者一个软件开发团队来说，可能遇到过或者正在被版本难以控制的问题所困扰。
一个软件往往由许多的模块组成，在不同的阶段（基础功能、新增功能），很可能为了适应不同的环境（如不同的操作系统），并根据不同客户的要求开发了特点各异的版本，这些版本之间有大量的共享模块，以及属于自己的模块。
当最后将这些模块组装成系统的某个版本时，会发现所需模块版
本无法确定。
此外，还可能会有团队中并行开发引起的冲突问题。
例如：
编程人员A和B
共同修改同一个模块，两人经过几个昼夜的奋战之后，又都回存到服务器上，但到了程序试运行的时候，才发现有一个人的修改被冲掉了，这会造成劳动力的严重损失。
因此，需要在软件企业中实施软件配置管理，简称为SCM（Software
ConfigurationManagement）。
SCM是一套规范、高效的软件开发基础结构，早已被发达国家软件产业的发展和实践所证明是管理软件开发过程的有效方法。
SCh可以系统地管理软件系统中的多重版本；
全面记载系统开发的历史过程；
管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化；
SCM对开发
过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。
软件配置管理作为软件开发过程的必要环节和软件开发管理的基础，支持和控制着整个软件生命周期，同时对软件开发过程的宏观管理，即项目管理，也有重要的支持作用。
良好的配置管理能使软件开发过程有更好的可预测性，使软件过程具有可重复性，使用户和主管部门对软件质量和开发小组有更强的信心。
若要有效地实施软件配置管理，必须要培养软件开发者的管理意识，结合开发组织的实际情况制订出相应的配置管理规范，由开发人员依据规范，通过专业化的配置管理工具来实现。
在这里，基于CVS工具实现软件配置管理，对文档和源代码进行访问和版本控制。
CVS（ConcurrentVersionsSystem，并行版本系统）是基于TCP/IP协议的版本控制工具，也是当前OpenSource中最重要的开发工具之一。
CVS是典型的Client/Server结构的软件，它分为服务器端和客户端两部分，不过大多数CVS软件中将它们和二为一了。
在CVS服务器端包含一个仓库（repository），用于存放处于版本控制下的所有目录和所有各种版本的文件，它保存了对项目源
码每一次改动的记录，和改动的一些注释。
CVS会完成对仓库的查询和更新，在
任何时候，你都可以找到仓库中任何文件的任何版本。
它容许几个人同时工作在同一个文件，在他们提交文件时来合并他们所做的修改。
在修改冲突时会发出警告来通知用户，是否确定将此文件的更新版本放入仓库内，并且是否由某人解决
发生的冲突。
使用CVS最基本的开发流程如下所述：
某个用户把他的所有代码导入（import）到CVS中,生成一个新的模块，然后其他人可以导出（checkout）源码树的一个工作拷贝；
每个人都工作在自己的本地计算机中，当源码树发生了改变，例如增添了一个新的功能时，他们必须更新（update）他们的本地拷贝来保持和当前版本同步。
他们也会提交（commit）他们改变的文件到仓库中以生成新的软件版本。
在提交时出现的问题CVS都会产生警告，然后用户必须仔细检查出问题的文件并手工解决冲突。
在文件中，改动的部分会在前面以“>
>
”
显示，并且列出两个版本的不同之处。
由用户来决定是删除旧版本还是做一些相应的修改。
WinCVS是CVS的一个客户端软件，它运行在Windows上，用来在Windows上登录CVS服艮务器，然后进行一些CVS相关的操作与管理。
由于当前很多的企业内部都采用Linux/Unix做为服务器，用Windows做客户端，所以，WinCVS与在Linux上配置的CVS服务器配合使用将组成强有力的版本控制与管理的系统。
WinCVS的一些常用功能包括配置、登录、文件上传、文件下载、编辑文件、文件比较、更新本地文件、合并文件、添加文件、删除文件、创建文件标签、查看文件状态等等。
其中，WinCVS提供了修改后提交（commit）的功能，用户从服务器端拷贝文件的某个版本，在本地修改后利用commit命令即可将最新的文件保存到服务端，并且文件版本号会自动加1。
当一个开发者试图commit某一修改的文件时，通常会发生如下两种情况之
。
对于此修改的文件，如果CVS在库中没有检测到新的版本，那么直接commit，就可在库中产生一新的版本；
如果CVS在库中检测到新的版本（比如多个人同时对相同的文件进行修改，在你之前已有人将他的修改commit而产生了新的版本），那么CVS此时将给出警告并中断commit操作。
对于第二种情况，在CVS中断了commit操作后，必须调用更新本地文件命令update，而调用update命令后，会有两种情况发生，一种是不带冲突，另外是带有冲突。
冲突的产生是由于多人在修改同一个文件的时候修改了文件中的相同的地方（如某一行）。
在CVS中冲突几乎很少发生，而一旦发生了冲突，很大的原因可能是开发小组的开发成员之间没有协调好。
另外对于冲突需要强调一点，所谓的冲突仅是文本性的，而非逻辑性的。
对于不带冲突的情况，在执行update命令将本地版本与服务器上的新版本合并以后，直接执行commit命令就会完成提交操作。
而对于带冲突的情况，则需要手动地进行修改。
例如文件xlmage.h在库中的版本为1.4，文件内容为：
while
（1）
i++；
本地的xImage.h版本为1.1，假设我们做了如下的修改
while（I<
0）
i++;
那么在执行update命令之后，文件图标如图1所示。
从图中可以看出版本号已为库中版本号，文件状态为Conflict，修改时间改为Resultofmerge,这说明发生了冲突，我们打开文件，文件内容如下：
vvvvvvvxImage.h
while（i<
0）=======
1.4
在此CVS用vvvvvv,=========和》»
虽调修改的相同部分，剩下的事情就看用户怎么办了。
在去掉这些标志，并改成所需要的文件之后，就可以进行commit了。
这时版本号又将升一级。
Folder
Fokfer
Fgldgr
Fotdor
NlonCvsFile
14.LI
・kb
Binary
l.i
=kb
i.H
File
1.36
■kb
1.3
1.20
（Image,n
Conflict
1.2D
FriDet2007:
16:
462002
FrlD«
2007:
29:
122002
MenDec2309!
31:
013002
WedDec2SM:
57:
322fl02
ThuDec1908:
37:
302M2
ThuDec3611:
3S:
522M2
Resultofmerge
图1WinCVS中对于带冲突的文件显示
CVS中还提供了分支功能，分支是基于软件的版本稳定性和开发的延续性考虑的。
一个软件产品会有一个比较稳定的版本（一般是正式发布版），这个版本之前是不稳定的，而之后要对它继续开发，新的功能不断加入，问题也肯定不断出现，在加入新功能的版本还没有比较稳定之前，这时用户可能对开发者提出要求（比如发现了发布版中的问题要求修改），此时就应该进行分支。
举个例子来说，假定某一软件的1.0发布版已完成，开发者正在继续开发过程，计划在2
个月后发行1.1的版本。
然而在不久以后，用户开始抱怨说1.0版的代码有些问题，开发者检查了一下1.0的发行版,并且找到了这个错误。
但是，当前处于开发中的版本处于一个不稳定的状态，并且在下一个月才能有希望稳定下来。
这样就没有办法去发行一个最新的现有版本去更正问题。
这时就可以去创建基于这棵版本树1.0版的分支，可以修改这棵树的分支而不影响到主干。
当修订完成时，开发者可以选定是否要把它同主干合并或继续保留在这个分支
升级会员 