kok电子竞技

软件工程第一章软件工程概述学习目标软件危机和软件工程的起源软件生命周期和软件过程模型传统软件生命周期敏捷过程begin

sensor_get(vertical_veloc_sensor);

sensor_get(horizontal_veloc_sensor);

vertical_veloc_bias:=integer(vertical_veloc_sensor);

horizontal_veloc_bias:=integer(horizontal_veloc_sensor);

...

exception

whennumeric_error=>calculate_vertical_veloc();

whenothers=>use_irs1();

end;航空：控制惯性导航系统的计算机向控制引擎喷嘴的计算机发送了一个无效数据，仅仅将一个64位浮点数转换成16位有符号整数时，产生的溢出，表明在将一个64位浮点数转换成16位有符号整数时，产生了溢出。溢出值测量的是火箭的水平速率，这比早先的Ariane4火箭所能达到的高出了5倍。在设计Ariane4火箭的软件时，他们小心地分析了数字值，并且确定水平速率绝不会超出一个16位的数。不幸的是，他们在Ariane5火箭的系统中简单地重新使用了这一部分，而没有检查它所基于的假设。这个错误导致1996年6月4日，Ariane5火箭初次发射后仅仅37秒，火箭偏离它的飞行路径，解体并爆炸了。火箭上载有价值5亿美元的通信卫星。6亿美元付之一炬。

发生在我们身边的事件医疗：最广为人知的是加拿大原子能公司制造的Therac－25线性加速放射器致人死亡事件。该机器由计算机控制，耗资百万元以上，由于5次连续性的错误造成放射过量，5位病人死亡，2人重伤。死亡病人接受了超过正常剂量100倍以上的放射。

证券：因市场数据分配系统出现故障，日本东京证券交易所2012年2月2日中断241支股票的早盘交易。东京证交所２０１０年１月耗资１３０亿日元（约合１.７亿美元）引进名为“箭头”的高速交易系统。这套系统处理每单交易耗时大约千分之二秒。由于2005年东京交易所的系统故障致使瑞穗证券公司蒙受了巨额损失，东京地方法院2011年12月判处东京交易所赔偿瑞穗证券公司107亿日元。。

2007-10-30日由于官方票务网站流量曾瞬时达到每小时800万次，超过了系统设计的每小时100万次的承受量。启动后第一小时从各售价渠道瞬时提交到票务系统的门票达到20万张(每秒56张)，也超过了系统设计的每小时销售15万张(每秒42张)的票务处理能力。北京奥组委不得不作出停止售票的决定。从初步的情况分析，并不是带宽的问题，主要还是系统后台的数据库的处理能力，在设计、规划方面，还有待改进。123061.1软件危机软件危机的表现软件开发费用和进度失控。软件的可靠性差。生产出来的软件难以维护。软件危机的背后软件的类型变得更多，从简单的嵌入式系统到复杂的全球信息系统技术、业务和社会的快速变革导致不断增长的需求大规模应用带来影响独立的应用、交易为特征的交互式应用、嵌入式控制系统、批处理系统、娱乐系统建：头抡嫦低、数据采集系统、集成系统1.2软件工程的概念今天，计算机系统开发成本的分配发生了戏剧性的变化。软件，而不是硬件，是最大的成本项。管理者和很多开发人员面临着同样的问题为什么需要那么长时间才能结束开发？什么样的开发过程才能保证软件的质量？这些问题以及其它许多问题都表明了对软件及其开发的方式是必须关注了——这种关注最终导致了软件工程实践的出现。软件工程的定义起源1968年北约组织在德国幕尼黑召开的一次关于软件的学术会议上提出了“软件危机”问题,并提出了软件工程的概念.什么是软件工程软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而确立和使用的健全的工程原理（方法）。”--FeitzBauer软件工程的定义软件工程的几种定义B.W.Boehm(1981):运用现代科学技术来设计并构造计算机程序,以及开发、运行和维护这些程序所必需的相关资料.IEEE(1993)：软件工程将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程,即将工程化应用于软件中.软件工程的定义将各种定义的共性归纳有下几点：针对软件而言；研究对象涉及到软件的开发和维护过程；重视规范化的文档和资料.传统软件工程的特点:规范化:多人共同开发和维护软件时,人人都必须遵循相同的约束规范.文档化:在软件开发的各阶段都要有相关的文档,用于描述设计思想、设计过程和具体实现技术等信息,以便开发和维护时参考.工程化:按照工程化的思想开发和维护软件产品.软件工程的定义(Cont.)软件工程的本质关注于大型软件产品的构造控制软件的复杂性提高开发软件的效率在开发软件过程中合作满足用户的需求软件工程的多样性软件类型的多样性独立的应用、交易为特征的交互式应用、嵌入式控制系统、批处理系统、娱乐系统、建：头抡嫦低、数据采集系统、集成系统不同类型的系统可能需要不同的软件工程技术涉及到人身安全的系统，其安全性和可靠性要求极高；某些嵌入式控制系统，其测试成本昂贵。软件工程的基本原理著名软件工程专家B.W.Boehm综合软件专家、学者们提出的关于软件开发的意见,并结合其在TRW公司多年开发软件的经验,于是1983年在一篇论文中提出了软件工程的7条基本原理.(1)用分阶段的生命周期计划严格管理把软件生命周期划分成若干个阶段;制定切实可行的计划;严格按照计划对软件开发和维护进行管理.(2)坚持进行阶段评审在每个阶段完成时都要进行严格的评审;尽早发现并改正错误.(3)实行严格的产品kok电子竞技本控制在开发和维护过程中,不允许随意修改软件成份;必须对软件进行修改时,实施严格的配置管理,以保证软件各成份的一致性.(4)采用现代程序设计技术结构化程序设计技术结构分析(SA)与结构设计(SD)技术面向对象程序设计技术构件程序设计技术(5)结果便于审查(文档支持)软件产品是一种逻辑产品,其可见性差,难以度量;为了更好地进行管理和评价,应明确规定开发组织的责任和产品标准,使所得到地结果能够清楚地审查.(6)人员少而精开发组人员素质高;人数越少越好.(7)承认不断改进软件工程实践的必要性积极主动地采纳新的软件技术;软件积极主动地采纳新的软件技术;不断总结经验.1.3软件生命周期生命周期(lifecycle)：当过程涉及到建造某种产品时,常将过程称之为“生命周期”.软件生命周期SLC(SoftwareLifeCycle):

软件开发和维护的过程称之为软件生命周期,它描述了软件产品从设想到实现、提交、使用和维护的过程.软件开发通常包括的几个阶段：

软件定义阶段问题定义可行性分析项目估算项目计划建模需求分析软件设计构建编码测试部署维护安装交付支持维护软件生命周期与开发模型有关.在开发一个较大规模的软件项目时,必须首先确定生命周期的过程模型(开发模型)。在开发过程中,严格按照过程模型进行。一个成熟的软件公司,对于每类软件项目都应有固定的过程模型,以及过程模型的标准和范本.1.3.1软件过程模型软件过程是指软件整个生命周期，从需求获。枨蠓治，设计，实现，测试，发布和维护一个过程模型。一个软件过程定义了软件开发中采用的方法，但软件工程还包含该过程中应用的技术——技术方法和自动化工具。区别一个过程是为达到目标的部分按序排列步骤的集合；在软件工程中，目标是构造一个软件产品，或增强一个现存产品；过程工程的目标是开发一个和增强一个过程。软件工程的层次(Cont.)SoftwareEngineeringSoftwareEngineeringaqualityfocusprocessmethodstools方法:开发软件的技术.工具:在方法中使用的自动化或半自动化支撑环境.过程:获得高质量软件所需要的一系列活动、约束和资源.软件工程方法学的三要素软件过程模型软件开发过程模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。软件开发过程模型也常称为：软件过程模型软件生命周期模型软件工程范型1.3.2瀑布模型问题定义需求分析可行性研究软件项目计划总体设计详细设计测试发布与实施瀑布模型维护传统生命周期线性顺序模型瀑布模型“瀑布”模型(WaterfallModel)是最早使用的模型,是由WinstonRoyce于1970年提出的,该模型的出现成为软件开发史上的一个重要转折点.瀑布模型就象瀑布一样,一级一级地实现.下一个阶段开始之前,前一个阶段必须完成。瀑布模型从一种较高的观点看待软件开发,必须事先将每一个阶段都安排好,开发时只需按模型的顺序进行即可。每个阶段都是一个里程碑(Milestone)或基线(Baseline),在每个里程碑处都有明确的评价标准,并进行严格的评审与审计,通过后才能进入下一个阶段,这样项目经理就能控制好项目的开发进度、成本和质量.瀑布模型(Cont.)瀑布模型的优点:结构简单,强调软件开发过程的阶段性和顺序性;对软件开发管理严格,文档齐全(里程碑驱动或称文档驱动),注重复审,保证了软件的质量;软件开发的支持工具比较齐全;支持推迟实现的观点,尽可能将编码向后推迟.瀑布模型的缺点:实际项目很少按照该模型给出的顺序进行重视需求规格说明,然而获得一个完整的规格说明是非常困难的,导致了开发出来的系统最终需求与最初需求不一致,大大地降低了实用性.由于强调软件开发的阶段性,反馈信息慢,拖延了开发进度;由于是文档驱动的,因此耗费了太多的时间和精力;错误具有放大效应推迟实现加大了失败的风险瀑布模型选择瀑布模型的条件：在开发时间内需求不变化或变化较少的项目;分析设计人员对应用领域较熟悉的项目;低风险的项目;用户使用环境相对稳定的项目;尽管有许多不足,尽管有许多新的过程模型出现,瀑布模型仍是使用最广泛的过程模型。有效应用瀑布模型的策略：微软公司：严格的里程碑制度CMM：严格的过程管理加入原型特征：允许反复原型模型原型模型(PrototypeModel)由客户和开发者进行初步需求分析后,产生初步的系统规格说明书,根据该规格说明书快速产生一个可运行的原型产品.向客户展示该原型产品,对客户进行培训,让客户试用,与客户一起评价规格说明书的完整性、准确性和一致性;根据评价结果,进一步修改规格说明书;根据修改过的规格说明书,对原型进行修改,产生一个新的原型,让客户试用,再与客户一起评价该原型,……这一过程可重复多次,直到最终的规格说明演化成与用户和客户一致的、可执行的系统为止.原型需求、设计或试用的次数：取决于原型的目标原型模型的总体目标：降低开发的风险和不确定因素原型法的分类：抛弃式模型、进化式模型1.抛弃式模型(ThrowawayModel)由H.Gomaa于1981年提出的,该模型用于确认需求和设计,而不是设计实际可用的系统。首先制定一个开发计划,然后进行需求分析、设计、编码、测试,由用户或客户评价,如果不满意再返回需求分析部分或设计部分或编码部分,直到满意为止.该模型开发的结果不是为最后使用,而是为了理解需求和开发方法,验证那些：、没有把握的需求.任务完成后该模型被抛弃,真正的系统开发将依据该模型的结果从头开始.2.进化式模型(EvolutionaryModel)首先设计一个全局性框架,然后建立一个初始的稳定模型,运行该原型,并反复添加、修改和完善,逐步向目标系统进化.每一次进化,都产生一个逼近目标的新kok电子竞技本.该模型在进化过程中,始终强调可靠性、可维护性、适应性和效率等软件质量问题.该模型的最终成果就是投入使用的系统.这种方法的优点是客户可跟踪开发过程,及时了解并建议修改开发的过程,最终系统能令用户满意,但开发进度和成本难以控制.修改表修改表修改表原型需求测试原型实现原型设计修订原型用户/客户审查系统需求(有时是非正式的,或未完成的）提交的系统丢弃型原型进化型原型原型模型(Cont.)原型模型(Cont.)原型模型的优点：使客户了解最终产品的大致状况;使客户和开发人员深入理解项目的实质;共同讨论一些双方难以达成一致的部分;降低软件开发的风险.原型模型的缺点：由于有了一个原型产品,不利于开发人员的创新;开发进度可能难以控制.原型模型(Cont.)选择原型模型的条件:用户定义了软件的一组一般性目标，但不能标识出详细的输入、处理及输出需求；开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式。投标时向客户展示产品的框架;为对于不熟悉的领域或行业开发项目;快速原型法用进化式原型法快速开发规模不大的软件产品.1.3.2演化软件过程模型背景：业务和产品需求随着开发的发展常常发生改变，想找到最终产品的一条直线路径是不可能的；紧迫的市场期限使得难于完成一个完善的软件产品，但可以先提交一个有限的kok电子竞技本以对付竞争的或商业的压力；只要核心产品或系统需求能够被很好地理解，而产品或系统的细节部分可以进一步定义。要求：在这些情况及其他类似情况下，软件工程师需要一个过程模型，以便能明确设计，同时又能适应随时间演化的产品的开发。

模型：演化模型是利用一种迭代和增量的思想方法。它的特征是使软件工程师渐进地开发，逐步完善的软件kok电子竞技本。增量模型增量模型(IncrementalModel)根据需求规模说明书将系统按功能分解成若干个子系统.开始开发一个子系统的功能,经过设计、实现、集成、测试后交付使用,然后再开发其他子系统,再加入已有的系统中,逐渐构成能完成全部功能的完整系统.规格说明设计实现和集成交付客户规格说明设计实现和集成交付客户规格说明设计实现和集成交付客户增量1增量2增量3增量n增量模型(Cont.)增量模型的优点:项目可以分解为多个子系统,子系统之间边界清楚;任务或功能模块驱动,可分阶段提交产品;系统本身具有良好的模块化特征,模块内部高内聚,模块之间低耦合,模块本身信息隐蔽;增量模型的缺点:不适合各部分联系紧密的项目;系统整体结构的一致性可能较差;各子系统风格可能不一致.选择增量模型的条件：在整个开发过程中,需求都可能发生变化,客户接受分阶段交付产品的项目;分析设计人员对应用领域不熟悉的项目;中高等风险项目;用户可参与到整个开发过程中的项目;使用面向对象语言或第四代语言开发的项目;软件公司自己有较好的类库,构件库;大型软件系统。开发周期较长(超过1年).分批投资的项目.螺旋模型螺旋模型(SpiralModel)是Boehm提出来的,他从风险角度看待软件开发过程,建议螺旋模型将风险管理结合到开发活动中,以最小化风险并可控制风险.先进行需求分析和生命周期计划,包括预算、方案、约束,进行评审,然后进行风险分析,建立原型1,明确操作方法.修正预算、方案和约束,再评审,进行风险分析,建立原型2,明确软件需求,确认需求,制定开发计划.修正预算、方案和约束,再评审,进行风险分析,建立原型3,进行软件设计,确认并验证设计,做集成和测试计划.修正预算、方案和约束,再评审,进行风险分析,建立原型4,进行详细设计,编码,单元测试,系统测试,验收测试,实现计划.螺旋模型(Cont.)螺旋模型的优点：强调风险管理,开发大型软件时可降低风险.实际上是一个过程管理模型，而非开发模型每一次循环可以采用不同的模型，适应风险变化模型的缺点：开发进度可能难以控制.RUPRUPRUP（RationalUnifiedProcess）统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品kok电子竞技本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。RUP现在软件产业界普遍认为，开发复杂软件项目必须采用:基于UML的以构架为中心用例驱动和风险驱动相结合的迭代式增量开发过程RUP具有很多长处提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。但同时它也存在一些不足：RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；此外，它没有支持多项目的开发结构敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。人和交互

重于

过程和工具。可以工作的软件重于

求全责备的文档。客户协作

重于

合同谈判。随时应对变化

重于

遵循计划。敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.对比迭代模型相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。对比瀑布模型两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。敏捷方法的适用性从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：组织文化必须支持谈判人员彼此信任人少但是精干开发人员所作决定得到认可环境设施满足成员间快速沟通之需要最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍。大规模的敏捷软件开发尚处于积极研究的领域。主要敏捷方法有水晶方法，CrystalScrum极限编程，XPExtremeProgramming极限编程极限编程（英语：eXtremeProgramming，缩写为XP），是一种软件工程方法学，是敏捷软件开发中最富有成效的几种方法学之一。原则快速反馈、假设简单、增量变化、包容变化最佳实践客户参与、及早交付、结对编程、测试驱动、验收测试、持续集成、集体所有权、可持续的开发速度、开放的工作空间、计划游戏简单设计、重构、隐喻iconixICONIX尽早进入编码阶段，缩短分析设计周期的软件开发方法合理的简化统一过程(RUP)，基于极限编程(XP)和敏捷软件开发的思想.与XP和敏捷方法的区别ICONIX过程与UML和RUP相比，是轻量级的过程。不同于XP和敏捷方法，ICONIX提供充足的需求和设计文档，但不过度分析设计。ICONIX过程从把需求文档变成可运作的代码过程只需四步，使用四张UML图（用例图、健壮性图、时序图、类图）。