软件工程期末论文.docx
- 文档编号:29270697
- 上传时间:2023-07-21
- 格式:DOCX
- 页数:26
- 大小:256.13KB
软件工程期末论文.docx
《软件工程期末论文.docx》由会员分享,可在线阅读,更多相关《软件工程期末论文.docx(26页珍藏版)》请在冰豆网上搜索。
软件工程期末论文
期末论文设计
摘要
经过软件行业几十年的发展,软件系统变得越来越复杂,传统的软件工程理论使“软件危机”越来越严重。
过长的开发周期、超出预算的开发成本、令人担忧的软件质量、频繁流动的开发人员、官僚的体系制度、迅速变化的市场环境等因素,让繁冗、笨重的软件开发过程越来越不能适应现实的需要,软件项目的失败率很高。
而敏捷开发就是在这种背景下应运而生的。
敏捷是一种关注价值、消除浪费、以人为核心、迭代、循序渐进的开发方法。
本文主要介绍了敏捷开发和软件复用的原理、方法和应用,并分析了两者的共存关系和功能。
关键词:
软件开发;开发方法;敏捷开发
ABSTRACT
Afterdecadesofdevelopmentofthesoftwareindustry,thesoftwaresystemisbecomingmoreandmorecomplex.Thetraditionalsoftwareengineeringtheorymakesthesoftwarecrisismoreandmoreserious.Longdevelopmentcycle,beyondthebudgetofthedevelopmentcosts,worryingsoftwarequality,frequentmobilityofdevelopers,bureaucraticsystem,rapidlychangingmarketenvironmentandotherfactors,letcumbersomeandbulkysoftwaredevelopmentprocessandcannotadapttotheneedsofthereality,thesoftwareprojectfailurerateisveryhigh.Andagiledevelopmentisinthisbackgroundcameintobeing.Agilityisakindofmethodtopayattentiontovalue,eliminatewaste,anddevelopthecore,iterativeandincremental.
Thispapermainlydescribestheprinciple,methodandapplicationofagiledevelopmentandsoftwarereusearedescribed,andthecoexistencerelationshipandfunctionofthetwoareanalyzed.
Keywords:
agiledevelopment;softwarereuse;coexistencerelationship
目录
第一章敏捷开发4
1.1敏捷开发简介4
1.1.1敏捷的起源5
1.1.2敏捷方法体系5
1.1.3敏捷宣言及原则6
1.1.4为什么要敏捷6
2.1敏捷系列7
2.2交付与管理8
2.3实践9
2.3.1持续集成(Continuousintegration)9
2.3.2隐喻9
2.3.3编码标准9
2.3.4集体拥有代码10
2.3.5稳定高速的步伐(40-HourWeek)10
2.4敏捷开发的编程方法10
2.4.1测试驱动开发(TDD)10
2.4.2重构11
2.4.3简单设计11
2.4.4结对编程12
2.4.5SCRUM12
3.1敏捷开发误区13
第二章软件重用14
1.1软件重用定义14
1.2软件重用的好处15
1.3软件重用的形式15
1.4软件重用分类16
1.5软件重用技术16
1.6软件重用的过程与意义17
第三章敏捷开发与软件重用18
1.1共存关系及作用18
1.2敏捷开发方法进行软件重用19
第一章敏捷开发
1.1敏捷开发简介
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。
在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。
换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
敏捷开发是一种面临迅速变化的需求快速开发的能力,它有四个核心思想:
第一是强调面对面的沟通,也就是强调沟通的重要性,人和人的相互交流胜于任何流程和工具;
第二是要把精力集中在可执行的程序上,可以运行的产品胜于编制综合性文档,也就是强调了原型、模型、Demo等的重要性;
第三个是团队合作和团队激励,合作胜于谈判,敏捷开发能将需求、开发、测试等全部团队成员融合成一个整体,大家都是一条线上的蚂蚱;
第四个是超强的适应能力,适应变化胜于按部就班,敏捷开发的特点就是快速。
敏捷软件开发团队就好比一支橄榄球队:
他们有明确的最高目标,而且每时每刻都朝着目标努力;他们熟悉最佳实践,高度自我管理,高度协作,高度灵活地面对各种挑战。
大量的调查统计表明,敏捷开发确实大大提高了软件开发效率和软件质量,帮助软件企业提高了效益,并更利于个人的成长。
敏捷开发能够缩短项目的反馈周期,因其将项目分成了若干个迭代周期,每个迭代周期结束都能立即反馈。
通过不断的沟通,还能减少理解上的偏差,配合反馈,减少误解,从而降低修正错误的代价。
且每个迭代周期的结束都能接受验证,从而能快速的适应变化,及时的适应新的需求,保证产品的正确性。
\
1.1.1敏捷的起源
上世纪90年代,萌芽--产生敏捷方法,敏捷方法是从上个世纪90年代开始发展起来的一组方法学的总称,包括极限编程等等。
这些方法学之间有一些差异,但是差异不是特别大。
2001年,正规—成立敏捷联盟,每种方法学的领导人共同起草了敏捷软件开发宣言,总结出方法之间的共同点,最终就是价值,并且用敏捷这个词给这种方法学一个统称
2004年,发展—开始广为流行,500强公司中众多公司应用敏捷;如HP,Microsoft,IBM等
1.1.2敏捷方法体系
XP-eXtremePrograming极限编程:
思想源自KentBeck和WardCunningham在软件项目中的合作经历。
SCRUM:
是一种迭代的增量化过程,用于产品开发或工作管理。
水晶方法Crystal:
由AlistairCockburn在1990年代末提出。
把不同类型的项目采用不同的方法。
FDD-特性驱动FeatureDrivenDevelopment:
由PeterCoad、JeffdeLuca、EricLefebvre共同开发,是一套针对中小型软件开发项目的开发模式。
它强调的是简化、实用、易于被开发团队接受,适用于需求经常变动的项目。
DSDM-DynamicSystemDevelopmentMethodology:
它倡导以业务为核心,快速而有效地进行系统开发,在英国等欧洲国家比较流行。
ASD-AdaptiveSoftwareDevelopment:
由JimHighsmith在1999年正式提出。
ASD强调开发方法的适应性(Adaptive)
敏捷开发包括很多方法,例如XP和FDD,同重量级的文档驱动的开发过程相比较,敏捷方法在灵活性等方面更有吸引力。
这个方法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些实践。
很多方法很难独立的使用。
如:
测试驱动的开发,结对开发,计划调整周期以及持续改进,不过,后来的结果证实,这些方法都取得了成功。
使用这些方法并不能保证一定成功。
开发者的经验和技术仍旧是影响开发结果的最主要因素。
对于合适的人,基于敏捷原则的开发方法可以产生更好的结果,同时形成一个愉快地、有激情的工作环境最重要的是通过尽早和不断交付有价值的软件满足客户需要。
1.1.3敏捷宣言及原则
我们欢迎需求的变化,即使在开发后期。
敏捷过程能够驾驭变化,保持客户的竞争优势。
经常交付可以工作的软件,从几星期到几个月,时间尺度越短越好。
业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务。
在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
(pdf13原文:
presentsoftwareindustry.Theaimofalltheprocessmodelsistodeliverqualityproductwithreducedtimeofdevelopment,andInternationalManuscriptreducedcost.Still,nosingleprocessmodeliscompleteinitself.Softwareindustryismovingtowardsnewmethodologies,suchas,AgileMethodology.Agileprocessesprovidearoomforrapidchangingrequirementsthroughoutthedevelopmentcycle.Italsohelpsinprovidingeffectiveconversationbetweensoftwaredevelopersandcustomersandalsohelpsinearlyproductdeliverytoo.Agilemethodologyhasadoptedsomedifferentprinciplestoshowitseffectivepresence.FollowingaretheprinciplesfollowedinAgileDevelopment在后文中将不再出现原文,以免篇幅太长)
敏捷过程提倡可持续开发。
出资人、开发人员和用户应该总是维持不变的节奏。
对卓越技术与良好设计的不断追求将有助于提高敏捷性。
简单——尽可能减少工作量的艺术至关重要。
最好的架构、需求和设计都源自自我组织的团队。
每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为以下是跟随在敏捷开发原则
1)最高优先级是请客户通过早期和持续交付有价值的软件。
2)欢迎变化的需求,即使在开发后期。
敏捷流程利用改变为客户的竞争优势。
3)频繁交付可工作的软件,从几个星期到几个月,更短的时间跨度。
4)业务人员和开发人员必须每天一起工作在整个项目。
围绕被激励起来的个人构建项目。
给他们的环境和支持他们所需要的。
5)最有效的和最有效的传达信息的方法和在一个
开发团队,面对面的交谈。
6)可工作的软件是进度的主要措施。
7)敏捷过程促进可持续发展。
赞助商,开发人员和用户应该能够无限期维持一个恒定的速度。
8)持续关注提高敏捷的技术优势和良好的设计。
9)简单。
10)最好的架构、需求和设计产生于自组织的团队。
等
1.1.4为什么要敏捷
项目为什么失败?
软件工程试图解决这些问题:
1.对用户需求理解得不清楚,甚至有错误;
2.用户需求变化;
3.软件很难维护或扩展;
4.在项目后期阶段发现很严重的设计缺陷;
5.软件质量或性能不合格;
6.Test-Build-Release过程的可操作性、可维护性很差;
7.人员流动;
……
为了规范化开发过程,引进传统工程的概念(瀑布型);
为了理解需求,提出原型法;
为了提高设计开发的效率和扩展性,提出重用和面向对象等思想;
为了让开发过程更灵活,提出了开发框架的概念;
为了降低风险,提出了风险评估、成本控制和增量开发等思想;
部门:
1)培养团队合作精神,稳定开发队伍;
2)提高开发人员的水平;
3)提高项目成功率,降低开发成本,提升软件开发效率
项目经理:
1)更好地和用户沟通,更清晰地理解用户需求;
2)更充分地使用资源,更科学地调配资源,更精确地掌握开发进度。
系统分析设计:
1)设计更加完善;
2)更有效地更新知识,得到其他成员更多的尊重。
程序员:
1)学习系统设计和项目管理;Fortune500公司中成功应用XP的公司包括FordDaimler-Chrysler,FirstUnionNationalBank,IBM,HP等等。
通信业NS,Ericsson,Alcatel等都号称在转向敏捷更多是小规模开发队伍(小规模开发队伍小规模项目)越来越多的公司开始使用敏捷开发过程
•
2.1敏捷系列
在敏捷的两个门派:
XP、Scrum中,整理归纳了很多可以用于协助软件开发的实践,后面统称为敏捷实践。
XPisalightweightmethodologyforsmalltomediumsizedteamsdevelopingsoftwareinthefaceofvagueorrapidlychangingrequirements.
--Kent
XP是软件开发过程中的纪律,它规定你:
必须在编程前些测试,必须两个人一起编程,必须遵守编程规范……XP是把最好的实践经验提取出来,形成了一个崭新的开发方法
极限的含义:
软件开发中的优点发挥到极致(KentBeck).
XP:
给程序员提供了明确的方法,使得程序员尽管面对需求的改变,却能够从容应对,即使着重变化发生在项目的后期,仍然能够编出代码。
XP核心:
沟通、简明、反馈和勇气
XP重视沟通,客户、开发人员、管理者共同组成团队。
XP是一个实践系统13个实践
XP方法的贡献:
以拥抱变化的思想,协作的团队,简单的规则等为原则的13个具体实践
是知名度最高的敏捷开发方法
2.2交付与管理
1.Product Manager/Project manager2.Coach3.Team lead4.Developers5.Tracker6.Tester
(On-Site)Customers所有的小组成员应在同一个工作地点工作。
成员中必须有一个用户代表(On-siteUser),由他/她来提出需求,确定开发优先级,把握开发的动向。
通常还设一个教练(Coach)角色,来指导XP方法的实施及与外部的沟通协调等。
小组每个成员都应围绕用户代表,充分贡献自己的技能。
客户是Team成员,在开发现场和开发人员一起工作。
传统的客户任务一般是讲解需求,运行验收测试,接收发布的系统。
XP新增加的任务:
(1)写UserStory
(2)评估UserStory的商业优先级
(3)为每个UserStory定义验收测试
(4)计划开发内容
(5)调控开发过程
(6)建立商业模型,把隐藏在客户需求下的原则传授给开发人员
(8)程序员分担任务的过程支解了对他们商业模型的理解
(9)参加设计过程
(10)和程序员一起找出Metaphor,导引设计方向
(11)在Metaphor的帮助下,定义更有效更实际的功能测试,给程序员的设计制定了规范
2.3实践
2.3.1持续集成(Continuousintegration)
持续集成指不断地把完成的功能模块整合在一起。
目的在于不断获得客户反馈以及尽早发现BUG。
随时整合,越频繁越好;集成及测试过程的自动化程度越高越好。
1.自动化编译质量度量2.自动化测试3.持续反馈
2.3.2隐喻
“Thesystemmetaphorisastorythateveryone-customers,programmers,andmanagers- cantellabouthowthesystemworks.”—KentBeck
Team将Domain/Sub-DomainModel,Design/Sub-DesignModel以及一些关键概念等等抽象化为比喻。
通过这些比喻,加强客户和程序员之间的相互理解,消化积累知识,指导设计开发的方向。
Metaphor可以帮助减少“知识泄露”和“支解知识”。
Metaphor是设计过程的航标——真正灵活有效的设计是针对商业原则的设计,而不是针对商业原则表现形式的设计,更不是脱离商业需求目的的学术设计。
随着开发的继续,Team会找到更好的Metaphor。
这是知识细化、深化的结果,是“持续学习”(Continuouslearning)的过程;是对商业模型和设计模型的持续重构。
2.3.3编码标准
编码标准的目的:
防止团队被一些无关紧要的愚蠢争论搞得不知所措。
7大原则:
1.不要预先花费太多时间2.目标应该是团队中没有人辨认各自的代码3.以团队为单位对某一标准达成协议,然后遵守这一标准4.不是事无巨细的规则列表,而是确保代码可交流的指导方针5.编码标准开始时应很简单,然后根据团队经验逐步进化6.创建能够工作的最简单标准,然后逐步发展7.只制订适合本团队的
2.3.4集体拥有代码
我们”的代码,而不是“我”的代码。
任何人可以改动任何一段代码,但改动后的代码必须通过所有相关的测试。
简单设计,编码标准和结对编程,使阅读和修改Team内其他人的代码变得实际可行。
2.3.5稳定高速的步伐(40-HourWeek)
“每天早晨都感到有活力有激情,每天晚上都感到疲惫而满足。
”
---KentBeck
2.4敏捷开发的编程方法
2.4.1测试驱动开发(TDD)
2.4.2重构
1.减少重复设计,优化设计结构,提高技术上的重用性和可扩展性。
2.在Metaphor指引下的重构,是为商业模型服务的。
不要把重构变成不断的盲目精简代码。
3.重构和编程前的计划型设计(PlannedDesign)结合,使XP的简单设计可行有效。
4.XP提倡毫不留情的重构(Refactormercilessly
5.任何人可以重构任何代码,前提是重构后的代码一定要通过100%测试单元测试后才能被Check-in。
6.可以根据需要,将一个迭代的全部目标定为重构。
7.不要太在意什么是最简单的设计——愿意在最后重构,比知道如何做简单的设计重要得多。
2.4.3简单设计
简单设计Dothesimplestthingthatcouldpossiblywork;Youaren’tgoingtoneedit如果没有它和众多惯例规则之间的耦合,XP的演化设计就蜕化成CODE-FIX。
XP的演化设计是在Up-frontdesign和Refactoring之间找到新的平衡。
标准(依重要性):
通过所有测试,可读性高的代码,避免重复,最少数量的类别或方法。
SystemMetaphor给设计提供了指引,加强Team对设计的理解;第一个迭代搭建了基本的系统框架。
以后的迭代过程,是在反馈和编程的基础上做交互式设计,减少了设计的投机性。
迭代过程中的CRC卡帮助Team交流设计思想,简化了设计文档。
构对设计进行优化。
XP认为设计非常重要,因此应该是一个持续的事务。
我们总是先尝试使用能够工作的最简单的设计,然后随着现实的不断显现来更改它。
对简单设计的需求并不是说所有设计都很小,也不表示它们是无足轻重的。
它们只不过需要尽可能简单,但是仍能工作。
2.4.4结对编程
所有设计决策都牵涉到至少两个人,至少有两个人熟悉系统的每一部分,几乎不可能出现两个人同时疏忽测试或其它任务,改变各对的组合在可以在团队范围内传播知识,代码总是由至少一人复查,结对的编程比单独编程更有效。
2.4.5SCRUM
SCRUM来源于橄榄球运动,指:
“在橄榄球比赛中,双方前锋站在一起紧密相连,当球在他们之间投掷时他们奋力争球。
”Scrum提供了一种经验方法,它使得团队成员能够独立地,集中地在创造性的环境下工作。
它发现了软件工程的社会意义。
这一过程是迅速,有适应性,自组织的,它代表了从顺序开发过程以来的重大变化。
(KenSchwaber)
Scrum是一种灵活的软件管理过程,它可以帮助驾驭迭代、递增的软件开发过程。
Scrum于1995年提出,并在2001年同其他方法论一起组成“敏捷联盟(AgileAlliance)”。
Scrum这个轻量的过程可以作为包装器,也就是说你可以把Scrum与其它灵活的过程框架组合起来。
1.Scrum团队:
5-7个人的小项目团队,团队的负责人可能担负起ScrumMaster的角色。
2.Backlog:
急待完成的一系列任务,包括:
未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等,按优先级定义出来,这些任务可能不是完整的,甚至可能随时会更改或添加。
3.Sprint(冲刺):
通常为30天的迭代时间,把Backlog中的每一项安排在Sprint中,由团队估算出所需要的时间(按小时记)。
每一次Sprint之后,一定要有可以交付使用的功能。
4.Scrum会议:
这是与传统方式最大的区别,每天15-20分钟的Scrum会议,通常在每天的同一时间和同一个房间内举行。
Scrum团队所有人都参加,也可以有旁听者(但不允许旁听者指手划脚)。
在这个15分钟的会议上,ScrumMaster会询问每个成员三个问题:
a)自上次Scrum会议后的1天里你做了什么?
b)从现在到下次Scrum会议的1天时间里你准备做什么?
c)你在工作中遇到了哪些困难?
每个成员在Backlog条目上所花费的时间会被记录到Springbacklog中。
ScrumMaster在会上对存在的问题提出即时的解决方案或指导,使团队不断向着目标前进。
Scrum会议不同于项目会议,对团队来说,它起到了快速简报的作用。
5.通过SprintBacklog的分析,可以了解Backlog的进度,尽早的了解所发生的问题
6.管理者不在是项目或者团队的``老板",而是帮助团队解决问题的``协调者"或是``助手"。
7.每一次Sprint之后要review,团队按照既定的SprintBacklog目标来演示完成的内容。
3.1敏捷开发误区
误区一:
敏捷是"一个”过程:
敏捷不是一个过程,是一类过程的统称,它们有一个共性,就是符合敏捷价值观,遵循敏捷的原则。
误区二:
敏捷仅是个软件过程:
敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上,正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。
涉及到人的问题,就已经不再是过程所能覆盖的了,就到了企业管理的层面上了,包括企业的价值观和文化。
这也是敏捷在国内实施的最大障碍:
把客户当作合作伙伴而不是对手,从客户角度出发去想问题,充分的跟客户沟通,而不是出了问题推诿责任。
目标是让软件实现客户的价值,而不是收钱就完事儿。
把人的能动性调动起来,给动力而不是给压力。
要实用而不是要规范。
让开发人员理解并实施,体验到敏捷的好处,而不是盲目机械地实施规范。
没有绝对的权威,每个人都有可取之处。
误区三:
敏捷是反文档的,文档只是为了达成目标的一种手段,如果这种手段是
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 期末 论文
![提示](https://static.bdocx.com/images/bang_tan.gif)