大型软件项目的软件工程管理方法Word文档格式.docx
《大型软件项目的软件工程管理方法Word文档格式.docx》由会员分享，可在线阅读，更多相关《大型软件项目的软件工程管理方法Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。
对于一个软件企业或者一个软件开发团队来说，可能遇到过或者正在被版本难以控制的问题所困扰。
一个软件往往由许多的模块组成，在不同的阶段（基础功能、新增功能），很可能为了适应不同的环境（如不同的操作系统），并根据不同客户的要求开发了特点各异的版本，这些版本之间有大量的共享模块，以及属于自己的模块。
当最后将这些模块组装成系统的某个版本时，会发现所需模块版本无法确定。
此外，还可能会有团队中并行开发引起的冲突问题。
例如：
编程人员A和B共同修改同一个模块，两人经过几个昼夜的奋战之后，又都回存到服务器上，但到了程序试运行的时候，才发现有一个人的修改被冲掉了，这会造成劳动力的严重损失。
因此，需要在软件企业中实施软件配置管理，简称为SCM（SoftwareConfigurationManagement）。
SCM是一套规范、高效的软件开发基础结构，早已被发达国家软件产业的发展和实践所证明是管理软件开发过程的有效方法。
SCM可以系统地管理软件系统中的多重版本；
全面记载系统开发的历史过程；
管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化；
SCM对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。
软件配置管理作为软件开发过程的必要环节和软件开发管理的基础，支持和控制着整个软件生命周期，同时对软件开发过程的宏观管理，即项目管理，也有重要的支持作用。
良好的配置管理能使软件开发过程有更好的可预测性，使软件过程具有可重复性，使用户和主管部门对软件质量和开发小组有更强的信心。
若要有效地实施软件配置管理，必须要培养软件开发者的管理意识，结合开发组织的实际情况制订出相应的配置管理规范，由开发人员依据规范，通过专业化的配置管理工具来实现。
在这里，基于CVS工具实现软件配置管理，对文档和源代码进行访问和版本控制。
CVS（ConcurrentVersionsSystem，并行版本系统）是基于TCP/IP协议的版本控制工具，也是当前OpenSource中最重要的开发工具之一。
CVS是典型的Client/Server结构的软件，它分为服务器端和客户端两部分，不过大多数CVS软件中将它们和二为一了。
在CVS服务器端包含一个仓库（repository），用于存放处于版本控制下的所有目录和所有各种版本的文件，它保存了对项目源码每一次改动的记录，和改动的一些注释。
CVS会完成对仓库的查询和更新，在任何时候，你都可以找到仓库中任何文件的任何版本。
它容许几个人同时工作在同一个文件，在他们提交文件时来合并他们所做的修改。
在修改冲突时会发出警告来通知用户，是否确定将此文件的更新版本放入仓库内，并且是否由某人解决发生的冲突。
使用CVS，最基本的开发流程如下所述：
●某个用户把他的所有代码导入（import）到CVS中，生成一个新的模块，然后其他人可以导出（check
out）源码树的一个工作拷贝；
●每个人都工作在自己的本地计算机中，当源码树发生了改变，例如增添了一个新的功能时，他们必须更新（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命令就会完成提交操作。
而对于带冲突的情况，则需要手动地进行修改。
例如文件xImage.h在库中的版本为1.4，文件内容为：
while
（1）
i++;
本地的xImage.h版本为1.1，假设我们做了如下的修改
while（I<
0）
那么在执行update命令之后，文件图标如图1所示。
从图中可以看出版本号已为库中版本号，文件状态为Conflict，修改时间改为Result
of
merge，这说明发生了冲突，我们打开文件，文件内容如下：
<
xImage.h
while（i<
0）=======
1.4
在此CVS用<
=========和>
强调修改的相同部分，剩下的事情就看用户怎么办了。
在去掉这些标志，并改成所需要的文件之后，就可以进行commit了。
这时版本号又将升一级。
图1WinCVS中对于带冲突的文件显示
CVS中还提供了分支功能，分支是基于软件的版本稳定性和开发的延续性考虑的。
一个软件产品会有一个比较稳定的版本（一般是正式发布版），这个版本之前是不稳定的，而之后要对它继续开发，新的功能不断加入，问题也肯定不断出现，在加入新功能的版本还没有比较稳定之前，这时用户可能对开发者提出要求（比如发现了发布版中的问题要求修改），此时就应该进行分支。
举个例子来说，假定某一软件的1.0发布版已完成，开发者正在继续开发过程，计划在2个月后发行1.1的版本。
然而在不久以后，用户开始抱怨说1.0版的代码有些问题，开发者检查了一下1.0的发行版,并且找到了这个错误。
但是，当前处于开发中的版本处于一个不稳定的状态，并且在下一个月才能有希望稳定下来。
这样就没有办法去发行一个最新的现有版本去更正问题。
这时就可以去创建基于这棵版本树1.0版的分支，可以修改这棵树的分支而不影响到主干。
当修订完成时，开发者可以选定是否要把它同主干合并或继续保留在这个分支里。
CVS允许你独立出一个派生的代码到一个分离的开发版本。
当你改变一个分支中的文件时（修改了一些BUG），这些更改不会出现在主开发版本和其它分支版本中，而这些BUG在主干（或叫主开发版本）中肯定存在（可能在别的分支中也存在），那么就必须在主干中也要对这些BUG进行修改，这就增加了额外的开销。
在CVS中，可以使用合并（merging）把这些变更从一个分支移动到另一个分支（或主开发版本）。
综上所述，利用CVS的commit可以解决并行开发中的冲突问题，实现有效的访问控制；
利用CVS中的分支和合并可以实现对软件灵活有效的版本控制。
CVS为软件开发的配置管理提供了一个可靠的工具。
3．用软件工程管理系统实现软件项目过程管理
在软件项目的开发过程中，会存在资源变化频繁的问题。
某些开发人员在软件项目开发的过程中离去，由于他负责使用或维护的文档或者资源不完善，使得后续人员接手他的工作时困难重重，造成开发过程的停滞；
由于没有控制好软件变化过程，消耗了大量人力物力，导致项目严重超期、预算超支；
项目经过了几次大改动，几乎记不起原来是什么样子了，或者说，根据用户提出的多次变更要求更改后的成型软件，与用户的需要相距甚远；
软件变化未经控制进入开发或维护活动之中，引入更严重的问题，例如某程序员未经正常的软件变化申请，自行修改软件中的某一错误，虽然局部错误是改正了，但由于没有考虑到局部改动对全局的影响，使得整个系统不能正常工作。
为了减小资源变化频繁问题对软件项目的影响，更有效地控制软件质量，需要对软件项目过程进行监控。
这里设计了一套软件工程管理系统，它主要针对于软件生成过程的管理和软件质量控制。
这个系统包括以下三个部分：
任务管理系统、Bug管理系统和用户认证系统。
这个系统应当具有Browser/Server的结构，用html、JSP和SQLServer实现。
3.1任务管理系统
任务管理系统主要用于软件生产的过程管理，对软件生产进行模块化管理，并将软件产品生产的工作细化为不同的任务，比如代码实现、程序测试和文档写作等；
这样的系统便于细化工作，明确工作目的，同时也便于管理者对生产过程进行管理，能够有效地把握产品的开发进度。
该系统从软件生产的特点出发，针对软件生产的特点进行设计。
在该系统中，最大管理单元是项目，最小管理单元是任务，在项目和任务之间有模块，这样的划分能够使项目执行更加有效。
在任务之下有所有的具体工作记录，包括Checkin（工作提交）、BugFix（Bug修复）、Comment（相关注释和评论）等。
通过项目能从整体上把握项目的执行情况，通过模块划分明确产品的结构和分工，通过任务能明确具体工作的目标，便于工作开展，通过记录反映具体的工作。
这种结构也便于项目的逐级管理，即项目有项目负责人，模块有模块负责人，任务有任务负责人，实行单人负责的策略，管理范围由大到小、由整体到细节；
并且在项目执行过程中可以随时对项目、模块、任务进行调整。
需要注意的是该系统为每个项目、模块都会生成一个相应的管理任务（项目管理的任务、模块管理的任务），强调了管理工作在软件开发过程中的重要性；
在任务管理系统中明确地提出管理任务，便于管理人员在项目执行过程中进行管理。
另外，在任务管理系统中包含了一个"
周报告"
子系统，工作人员可以在周报告中提交每一周的工作情况，工作计划等，并在系统中做记录，方便工作者记录和汇报自己的工作情况和下一阶段的工作安排；
并提供周报告查询功能，同时系统还可以对各个周报告进行汇总，以便管理者查阅。
这个系统中主要实现的功能包括：
创建项目、查询项目、创建模块、查询模块、创建任务、查询任务、提交多种记录、查询记录、提交工作报告以及系统管理等。
任务管理系统用于记录、跟踪和管理项目开发的每个过程、报告工作的进展情况和帮助公司的管理和决策人员对资源进行合理分配。
通过管理系统对软件工程项目的管理，可以避免软件公司因为人员的流动对公司造成的巨大损失。
同时因为管理系统记录了项目的详细过程信息，也为项目以后的升级和完善提供了宝贵的可供查询的第一手资料。
此系统应该具有如下的特点：
●项目分级管理：
将一个项目分解为小的模块，再将模块分解为具体的任务，通过逐层细化，将工作落实到个人；
●以任务为中心：
整个系统的最终管理归结为人与任务的一一对应，明确责任；
●任务分类：
按照任务的性质进行分类，同一个任务又可以通过从管理任务、开发任务、测试任务到文档任务进行不同的任务分工；
●记录细节：
将与整个项目开发中相关的每一条信息记录到系统中，产生一个包括完成项目过程和记录的报告，这就是一份可供查询的，记录整个开发过程的原始资料；
●工作汇总：
通过周报告子系统及时反映所有人员的工作进展和完成情况，以便对人员进行评估；
●项目控制：
可以实时了解整个项目的完成情况和所有人员当前负责的具体工作；
●Email自动发送：
项目系统中任何一个添加和更改操作都会同时通过Email告知相关人员。
3.2Bug管理系统
Bug管理系统主要用于对软件的Bug进行管理，是软件测试和软件开发的工程管理工具，这对提高软件产品的质量至关重要。
Bug管理系统能实时反应出Bug的出现、确认、修复、验证等各个阶段的情况。
软件产品中存在Bug是正常情况，没有Bug的软件是不存在的。
软件的规模越大，Bug出现的机会就越大，Bug的数量也就越多，如果开发人员难以对付这些成百上千的Bug，那么软件的质量就很难得到保证。
为了有效地管理Bug和修复Bug，需要一个强大的工具对软件中的Bug进行科学有效的管理。
Bug管理系统是存储、处理Bug的工具，也是开发人员，测试人员交流讨论的场所，同时也是项目管理、工作评定的重要工具。
Bug管理系统主要用于提交Bug，并记录每个Bug的变化过程。
每一个Bug都有负责人，或者可以被指定一个负责人对其进行修复，这样有利于及时地处理Bug；
如果软件产品的每一个Bug都严格地利用Bug管理系统管理，随着系统中的Bug一个一个被清除，产品也将一步一步走向健壮。
Bug管理系统应具有如下的特点：
●Bug的流程控制：
对一个软件中的Bug进行从提交、确认、修复、测试到最后关闭整个过程的管理；
Bug管理系统中任何一个添加和更改操作都要同时通过Email告知Bug的负责人及相关人员，提醒大家对此Bug的关注；
●定期Bug汇总：
根据条件产生统计报表，并可以通过图表的方式来描述在一个时期内，Bug的增加和修复情况，这为产品的开发和控制提供了依据；
●Bug提醒：
将Bug管理系统中的Bug按照级别进行划分，定期发送给每一个Bug的所有者和它的部门负责人，提醒Bug的所有者及时修复Bug。
3.3用户认证系统
用户认证系统用于对整个系统中的用户进行统一管理，包括注册用户、为用户发放其他系统使用许可等功能；
还可以存放员工的其他信息，比如简历等等。
使用用户认证系统，可以管理整个系统中的用户，即用户只需要注册一次，在获得其他系统的使用许可以后，就可以使用其他系统（例如CVS服务器登录权限、项目管理系统和Bug管理系统），不必为每一个系统都注册用户。
这样使得用户管理更加集中、方便。
用户认证系统主要包括用户注册、用户授权、组管理、部门管理、系统管理等功能。
4．进行有效的软件测试工作
软件测试的基本过程是通过对软件功能的实际使用，观察使用的实际效果，然后把实际结果和期望值进行比较，找出它们之间的差距。
整个的软件测试过程可以大致分为两部分：
设立期望值。
软件应该具备的功能，实际上在编程之前就确定好了。
软件设计可以理解为设立软件的期望值。
对于测试人员来说，根据软件设计文档和用户手册，可以整理出具体的，细化的期望值。
这些期望值是评估软件质量的标准、依据。
这也附带说明了文档的重要性。
获得实测值。
通过在特定的条件下运行软件，采集运行结果。
然后把结果和期望值进行比较，产生测试报告。
通常讲的软件测试主要是指这部分的工作。
对于大型软件项目来说，其软件测试项目包含的具体任务大致有以下这几项。
1．建立自动测试运行体系
对于一个稍具规模的软件，自动运行测试程序是必不可少的。
因为测试程序的代码量远远大于被测程序的代码量，不可能采用人工运行测试，比较结果。
自动测试体系的主要功能是运行测试程序，收集运行结果，把结果和标准答案比较，并最后产生测试的结果和bug报告。
2．设计测试方案
首先要建立测试环境。
有些时候建立测试环境是一件很困难的事情，例如网络环境，和某些极限环境，例如测硬盘溢出时的处理情况，设置线程之间的竞争条件，等等。
在设计测试时，一般是根据“假定环境正确”的原则。
要测一个程序，需要假定测试程序中的辅助部分是正确的。
例如测文件read（）时，假定open（），close（）都是好的。
否则的话在测试程序中对于open（）和close（）的结果要检查，要处理文件打开有误的各种意外情况，使得测试程序非常臃肿，读起来使人不得要领。
设计测试方案时还需要考虑结果的测量方法。
一般情况下收集程序的输出结果就够了，这样做也比较容易。
但是有些测试的结果是很难测量的，例如要测一个程序占用内存大小的峰值。
3．设计测试情况
这是测试工作的主要部分。
一般来说，一个软件不可能被“彻底”测试。
只能是尽量涵盖常用的功能和运行条件。
常用的测试情况设计思路为：
首先考虑正常条件下正常工作，其次是错误条件下正确处理，包括给出相应的错误码和错误信息。
但是，考虑到软件的效率和复杂性，并不是每一种错误都必须处理。
所以软件手册里可以说明在某些输入条件下，结果不可预见，或者引起软件崩溃。
其中，由于边界是软件容易出错的地方，所以要特别注意进行边界测试。
例如整数中的0和65535，指针中的空指针和指到无效地址的指针等。
以上所述为对程序进行正确性测试，通常还要进行性能测试，例如系统的响应时间，容量等等。
极限测试也很重要，例如，系统内最多可创建多少个进程，应用程序最多可以使用的内存等等。
4．编写测试程序
设计了测试情况之后，就可以编写测试程序。
这是测试程序库的主要来源。
需要一支测试队伍，系统、全面、深入地编写测试程序。
5．测试的运行
运行测试的方法可以分为人工运行和自动运行两种。
在不少情况下人工测试是不可避免的。
例如收集标准答案时，要人工检查是否符合预期的值，如果符合预期值，就保存起来作标准答案。
有些程序有特殊的运行环境，例如人机交互方式，需要操作某些外部设备。
最常见的是有图形界面的程序，很难进行自动测试。
真正有用的是自动运行。
测试程序通常都和daily
build相连，例如每天build两遍，从源程序开始build，然后运行程序获得报告，这等于监护源程序，因此只有自动运行才能满足测试周期短的要求。
还有的时候需要子集运行，测试程序特别多的时候有可能运行较长时间，在某些情况下每次只能运行一个子集。
6．测试的结果和Bug报告
最常见的测试结果是测试报告：
列出成功，失败统计报表，失败详情，输入情况，出错现象等。
有时候根据测试结果要立即采取行动。
紧急情况要紧急抢修，关闭源程序树，停止改动。
解决两个纠缠在一起的问题比单独解决它们更难，因为那样将无法发现新问题。
所以要避免在一个有问题的系统上进行改动和开发新程序。
测试队伍担负着质量纠察队的角色，测试中发现新问题时，要登录bug，填写bug报告，并要跟踪此bug的解决情况。
测试人员要对最终发布产品的质量负责。
5．组件技术以及基于组件技术的软件工程学方法
按照组件化程序设计的思想，复杂的应用程序被设计成一些小的、功能单一的组件模块，这些组件模块可以运行在同一台机器上，也可以运行在不同的机器上，甚至可以运行在跨越太平洋的两台机器上。
在理想的情况下，每台机器的运行环境可以不同，甚至可以是不同的操作系统。
为了实现这样的应用软件，组件程序和组件程序之间需要一些极为细致的规范，只有组件程序遵守了这些共同的规范，软件系统才能正常运行。
为此OMG（ObjectManagementGroup，对象管理组织）和Microsoft分别提出了CORBA（CommonObjectRequestBreakerArchitecture，公共对象请求中介体系结构）和COM（ComponentObjectModel，组件对象模型）标准，目前CORBA模型主要应用于UNIX操作系统平台上，而COM则主要应用于MicrosoftWindows操作系统平台上。
随着Internet时代的到来，COM技术已经应用于越来越多的分布式系统当中。
COM规范具有如下的一些特点。
●语言无关性：
这是指COM规范的定义不依赖于特定的语言，编写组件对象所使用的语言与编写客户程序使用的语言可以不同，只要它们都能够生成符合COM规范的二进制代码；
●进程透明特性：
COM所提供的服务组件对象在实现时有进程内对象和进程外对象两种进程模型，如果是进程内对象，则组件在客户进程空间运行，如果是进程外对象，则组件运行在同一机器上的另一个进程空间或者在远程机器的进程空间中，但这种区别对于客户来说是透明的，这就是COM的透明特性；
●可重用性：
COM的可重用性是建立在二进制代码级的，与C++中所说的可重用性不同，它使复杂的系统简化为一些简单的对象模块；
对
升级会员 