软件工程新技术研究探讨.docx

软件工程新技术研究探讨.docx

《软件工程新技术研究探讨.docx》由会员分享，可在线阅读，更多相关《软件工程新技术研究探讨.docx（11页珍藏版）》请在冰豆网上搜索。

软件工程新技术研究探讨

软件工程新技术研究探讨

——敏捷开发技术

摘要:

Agile开发方法（敏捷开发）是近年来软件开发界提出的一种新的开发方法。

敏捷开发是轻量型的开发方法，它反对传统、庞大、重型的过程；强调与人交流的重要性，提倡用高质量的软件代替文档，具有能够适应需求变化，进行快速开发的能力。

这类方法以快捷、轻便的思维方式，迅速解决了一些传统软件开发中存在的问题，提高了软件企业的生产效率，得到了迅速的推广。

论文介绍了敏捷开发，并分析了敏捷开发的平台技术，并对敏捷开发的优势进行了分析。

目录

1.敏捷开发介绍4

1.1价值观4

1.2原则5

1.2.1主张简单5

1.2.2拥抱变化5

1.2.3你的第二个目标是可持续性5

1.2.4递增的变化5

1.2.5令Stakeholder投资最大化5

1.2.6有目的的建模6

1.2.7多种模型6

1.2.8高质量的工作6

1.2.9快速反馈7

1.2.10软件是你的主要目标7

1.2.11轻装前进7

2敏捷开发平台的分析与设计7

2．1开发流程分析与设计7

2．2开发平台的分析8

2．3开发平台的设计9

3敏捷开发的优势分析10

3．1与迭代式开发相比的优势10

3．2与瀑布式开发相比的优势10

3．3与螺旋式开发相比的优势10

4.结束语10

5.参考文献11

1.敏捷开发介绍

简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。

在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。

换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

1.1价值观

敏捷建模（AgileModeling，AM）的价值观包括了XP（ExtremeProgramming：

极限编程）的四个价值观：

沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：

谦逊。

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。

除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。

（一）沟通：

建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的projectstakeholder之间的沟通。

简单画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键。

这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进。

（二）反馈：

KentBeck在ExtremeProgrammingExplained中有句话讲得非常好：

“过度自信是编程的职业病，反馈则是其处方。

”通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事。

（三）勇气：

勇气非常重要，当你的决策证明是不合适的时候，你就需要做出重大的决策，放弃或重构（refactor）你的工作，修正你的方向。

（四）谦逊：

最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。

事实上，无论是开发人员还是客户，甚至所有的projectstakeholder，都有他们自己的专业领域，都能够为项目做出贡献。

一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被考虑。

（五）尊重：

敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。

其中一些原则是从XP中借鉴而来，在ExtremeProgrammingExplained中有它们的详细描述。

而XP中的一些原则又是源于众所周知的软件工程学。

复用的思想随处可见！

基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待[4]。

1.2原则

1.2.1主张简单

当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。

不要过分构建（overbuild）你的软件。

用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。

要有这样的勇气：

你现在不必要对这个系统进行过分的建模（over-model），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。

尽可能的保持模型的简单。

1.2.2拥抱变化

需求时刻在变，人们对于需求的理解也时刻在变。

项目进行中，Projectstakeholder可能变化，会有新人加入，也会有旧人离开。

Projectstakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化。

这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。

1.2.3你的第二个目标是可持续性

即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的－－实现Projectstakeholder的需求，其中就包括你的系统应该要有足够的鲁棒性（robust），能够适应日后的扩展。

就像AlistairCockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛。

可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持。

要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。

你要考虑很多的因素，包括你现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度。

简单的说，你在开发的时候，你要能想象到未来。

1.2.4递增的变化

建模相关的一个重要概念是你不用在一开始就准备好一切。

实际上，你就算想这么做也不太可能。

而且，你不用在模型中包容所有的细节，你只要足够的细节就够了。

没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型。

这就是递增的思想。

1.2.5令Stakeholder投资最大化

你的projectstakeholder为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。

stakeholder应该可以选取最好的方式投资，也可以要求你的团队不浪费资源。

并且，他们还有最后的发言权，决定要投入多少的资源。

如果是这些资源是你自己的，你希望你的资源被误用吗。

1.2.6有目的的建模

对于自己的artifact，例如模型、源代码、文档，很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确。

你不应该毫无意义的建模，应该先问问，为什么要建立这个artifact，为谁建立它。

和建模有关，也许你应该更多的了解软件的某个方面，也许为了保证项目的顺利进行，你需要和高级经理交流你的方法，也许你需要创建描述系统的文档，使其他人能够操作、维护、改进系统。

如果你连为什么建模，为谁建模都不清楚，你又何必继续烦恼下去呢？

首先，你要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。

一旦一个模型实现了目标，你就可以结束目前的工作，把精力转移到其它的工作上去，例如编写代码以检验模型的运作。

该项原则也可适用于改变现有模型：

如果你要做一些改变，也许是一个熟知的模式，你应该有做出变化的正确理由（可能是为了支持一项新的需求，或是为了重构以保证简洁）。

关于该项原则的一个重要暗示是你应该要了解你的受众，即便受众是你自己也一样。

例如，如果你是为维护人员建立模型，他们到底需要些什么？

是厚达500页的详细文档才够呢，还是10页的工作总览就够了？

你不清楚？

去和他们谈谈，找出你想要的。

1.2.7多种模型

开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，“要开发现今的商业应用，我们该需要什么样的模型？

”考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术（关于artifact的清单，可以参阅AM的建模artifact）。

有一点很重要，你没有必要为一个系统开发所有的模型，而应该针对系统的具体情况，挑选一部分的模型。

不同的系统使用不同部分的模型。

比如，和家里的修理工作一样，每种工作不是要求你用遍工具箱里的每一个工具，而是一次使用某一件工具。

又比如，你可能会比较喜欢某些工具，同样，你可会偏爱某一种模型。

有多少的建模artifact可供使用呢，如果你想要了解这方面的更多细节，我在BeRealisticAbouttheUML中列出了UML的相关部分，如果你希望做进一步的了解，可以参阅白皮书TheObjectPrimer--AnIntroductiontoTechniquesforAgileModeling。

1.2.8高质量的工作

没有人喜欢烂糟糟的工作。

做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。

1.2.9快速反馈

从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。

和其他人一共开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。

和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会。

1.2.10软件是你的主要目标

软件开发的主要目标是以有效的方式，制造出满足projectstakeholder需要的软件，而不是制造无关的文档，无关的用于管理的artifact，甚至无关的模型。

任何一项活动（activity），如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。

1.2.11轻装前进

你建立一个artifact，然后决定要保留它，随着时间的流逝，这些artifact都需要维护。

如果你决定保留7个模型，不论何时，一旦有变化发生（新需求的提出，原需求的更新，团队接受了一种新方法，采纳了一项新技术...），你就需要考虑变化对这7个模型产生的影响并采取相应的措施。

而如果你想要保留的仅是3个模型，很明显，你实现同样的改变要花费的功夫就少多了，你的灵活性就增强了，因为你是在轻装前进。

类似的，你的模型越复杂，越详细，发生的改变极可能就越难实现（每个模型都更“沉重”了些，因此维护的负担也就大了）。

每次你要决定保留一个模型时，你就要权衡模型载有的信息对团队有多大的好处（所以才需要加强团队之间，团队和projectstakeholder之间的沟通）。

千万不要小看权衡的严重性。

一个人要想过沙漠，他一定会携带地图，帽子，质地优良的鞋子，水壶。

如果他带了几百加仑的水，能够想象的到的所有求生工具，一大堆有关沙漠的书籍，他还能过得去沙漠吗？

同样的道理，一个开发团队决定要开发并维护一份详细的需求文档，一组详细的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型，那他们很快就会发现，他们大部分的时间不是花在写源代码上，而是花在了更新文档上[5]。

2敏捷开发平台的分析与设计

2．1开发流程分析与设计

每一个信息系统开发项目都有其自身的需求与特点，在开发过程中应结合信息系统项目的实际特点和团队的优势，构建有针对性的软件开发模式，本文所涉及的敏捷开发平台，最适合的构架是J2EE的MVC模式。

如图1所示为敏捷开发流程的设计方案。

由图1可知，在信息系统开发伊始，先从源代码存储数据库里读出软件系统所需的全部源代码，接着以这些源代码为基础，对单元测试代码与信息系统的程序代码进行编写，这样的模式有助于单元测试的顺利进行以及程序编译的顺利通过。

代码编写完毕之后需要进行提交，所提交的全部码将存储于源代码库。

引入“CruiseControl”模块作为信息系统的集成模块，一旦该控制器接收到源代码库的代码更新后，便会触发Ant功能，Ant对源代码库的目录进行刷新，从而把旧的目录替代掉，并为新编写的源代码构建新的目录、提示为这些代码的目录执行测试工作。

测试通过之后，将以上代码编译并生成目标类，打成WAR包进行发布[3]。

图1敏捷开发流程的设计方案

2．2开发平台的分析

在开发平台的设计中，源代码的管理和存储，是以管理软件的形式实现的，这样的做法优势在于，能够使信息系统项目团队中的每一个成员均能够得到系统完成的所有源代码。

这一步骤的重要环节便是管理软件的自动化，结合系统预先所设置的周期，在代码库中自动检测和读取已经更新的代码，同时把这些新代码存储于一个日志属性的文件之中，信息系统开发团队的所有成员均能够接收到新代码的详细内容。

为适应敏捷管理，系统采用B／s结构，以Spring来实现系统所需的服务，并引入ESB技术作为中介，通过为J2EE结构中的业务逻辑层底部补充服务层，实现系统对具体参与调用的软件代码的封装。

基于以上方式所构建的平台，其最终用户是软件开法者，开发团队在以上平台的支持下，将更多的精力投入到对软件核心业务逻辑的分析、对用户需求的重构以及开发的效率，因此使得所开发产品的伸缩性和灵活性都有较大的改善。

2．3开发平台的设计

本研究在构建敏捷开发软件平台时，选用框架是MVC，并创新性地引入了SOA体系结构，借鉴二者之长，构建高效、稳定的敏捷软件开发管理系统构架。

在s0A中，通过模型对三个角色进行了描述，分别是：

服务提供者、注册库以及请求者。

服务提供者角色如果从用户的角度而言，属干一项服务的所有者。

而从开发团队的角度而言，则属于一种接受访问服务的具体的平台。

服务注册中心角色属于服务发现的支持者，服务注册中心拥有一个可用服务的存储库，该存储库可以支持搜索，也支持服务描述。

该存储库可供服务提供者发布其具体的描述，此外服务请求者还能够从不属于服务注册库的渠道获取服务描述，这些渠道包括文件、FTP等。

服务请求者角色如果从企业的角度而言，属于一项服务的使用者。

而加入从系统结构的角度而言，则属于一种寻找并调用服务的具体的平台。

由于软件开发平台系统使用的是层次化结构，因此系统分属于不同层次的组件互相独立，能够方便地增加、更新。

这个特点为系统的维护带来许多方便。

此外因为不同组件之间的关系是互相独立的，假如需要更换组件，并不会对系统另外部分的组件产生任何影响，所以对系统进行更新或者维护的时候就会安全和可靠。

此外由于系统引入了层次化结构，可以让系统开发拆分为专业化分工。

信息系统的开发小组能够结合具体的层次进行划分，每一个专业小组只需要结合不同层次之间的协议。

单独负责自己层次的内容即可实现这个系统。

因此，以专业化的分工对系统的开发团队进行细化，便能够让开发小组成员充分发挥其专项技能。

结合前文所述的基于MVC的结构特征，本设计在信息系统引入MVC结构所具有的优势包括。

（1）在软件用户的视角：

客户的需求可

以通过将不一样的服务组合起来进行实现。

举例来讲，一个客户在查询服务的时候还要另外提供一些服务，则此时客户可以把这部分服务进行组合，从而形成新的可供调用的服务。

通过这样的方法就能够使得在并发请求数目比较多的时候，不至于使系统的速度减慢。

（2）从开发者的视角而言：

一些需要访问信息平台的外部用户同样申请相同的服务。

这样的模式有利于效率更高地整合软件开发所涉及到的业务流程。

从服务提供的视角而言，本研究所开发的系统一方面能够作为其他系统提供服务的角色出现。

另一方面也能够充当服务的使用者。

在本研究的功能模块里，通过这样的方法就能够通过调用查询服务去获取一个具体敏捷软件开发情况。

（3）本研究所开发的系统之中所存在的业务逻辑可以全部以第三方提供的服务来实现具体的功能。

相关的业务逻辑服务组件由服务提供者进行开发之后，可以给整个信息系统的所有用户提供相关的业务服务，其他信息系统的用户通过对这些逻辑内容进行组合，便可以实现这些用户所需的业务服务。

从服务使用者的视角而言，要想获取网络服务，只要以符合相关标准的接口来申请即可，而该服务具体采用的是什么系统平台则不是用户所关心的，在服务的提供方的视角，需要关注的只限于怎样对服务进行重新组合，从而满足新产生的业务需求。

3敏捷开发的优势分析

3．1与迭代式开发相比的优势

敏捷开发与迭代式开发有着共同之处，即对于信息系统开发周期的要求发出严格。

而迭代式开发由于迭代周期过长，迭代期间不允许客户提交变化需求，因此导致了项目估算准确度下降；与之相比，敏捷开发模式特有的短周期与高度协作，能够更好地契合客户不断变化的需求，也能使客户需求更加明晰，通过及时的沟通与交流实现效率的提升。

3．2与瀑布式开发相比的优势

瀑布式开发遵循预见性的原则，对开发过程的先后顺序非常严格，导致信息系统开发过程中的灵活性与自由度大打折扣；与之相比，敏捷开发模式特有的迭代方式，使得信息系统已开发出的部分模块永远处于可用状态，敏捷开发把一个系统划分为一些相互独立的子系统，以尽可能短的周期进行迭代，大大增加了效率，提升了客户满意度。

3．3与螺旋式开发相比的优势

螺旋式的开发模式结合了快速原型模型与瀑布模型二者，并将开发过程中的风险评估放在比较重要的位置，因此对于一些较大型的信息系统而言，由于其复杂度很高，螺旋式的开发模式比较适合。

螺旋式的开发模式所针对的风险，强调了可预见部分，却难以应付不可预见的随机风险，在这一点上，敏捷开发的理念更加重视系统在不可预知的风险面前的适应性因而更好地规避了风险[1]。

4.结束语

虽然说敏捷开发是一种新方法，但是事实上我们看到，他是一综合了多种传统开发方法的优点，整理出来的一套开发组织方法。

因此敏捷开发是一个新的思路，它不一定是所有软件开发的终极选择。

它也存在一些问题，但只要我们遵循敏捷开发最基本的务实精神，用变化的而不是死板的观点来思考，我们相信问题肯定可以解决。

在理解这种新方法的过程中，了解其他方法的优缺点，然后适应变化而做出改进。

最后，笔者将深入并持续去认识敏捷，了解它背后的思想基础，并且尝试不同的实践去加深理解。

5.参考文献

1.敏捷开发管理实践与应用傅成聪（通联支付网络服务股份有限公司上海200136）

2.刍议敏捷开发在项目管理中的应用王冠甲北京迈腾顺风科技有限公司

3.敏捷开发平台的设计李新（中国科学院计算机网络信息中心ARP中心，北京100190）

4.使用软件工程殷人昆清华大学出版社

5.敏捷开发环境下软件可靠性分析及相关问题研究王晓华贵州大学博士研究生学位论文