软件工程复习

软件的特性软件是一种规律实体，而不是具体的物理实体。它具有抽象性软件的开发设计、生产、维护与硬件不同在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题大多数软件是定制的软件的开发和运行常常受到计算机系统的限制对计算机系统有着不同程度的依靠性软件开发至今尚未完全摆脱手工艺的开发方式软件是简单的软件本钱相当昂贵相当多的软件工作涉及到社会因素软件危机的表现、缘由软件危机---主要表现：对软件开发本钱和进度的估量不准确用户不满足软件质量不高、牢靠性差软件常常不行维护、错误难以改正缺乏适当的文档资料软件本钱占系统总本钱的比例逐年上升〔1985 90%〕软件开发速度跟不上计算机进展速度归结为主要为三方面--“时间、本钱、质量”软件危机--缘由：软件规模日渐浩大〔数量、功能、本钱、质量、时间〕软件开发治理困难。规律部件而不是物理部件。发的质量也较难评价。因此，治理和掌握软件开发过程相当困难。开发人员错误的观念、方法和技术重编程、轻需求。生产方式落后：个体手工方式。开发技术落后\开发工具落后无视软件开发前期的需求分析开发过程缺乏统一的、标准化的方法论的指导文档资料不齐全或不准确无视与用户之间、开发组成员之间的沟通无视测试的重要性不重视维护或由于上述缘由造成维护工作的困难需求变化预料缺乏用例归约用例规约--进展用例阐述用例规约：更进一步的精度用例文档的核心，而用例图作为用例文档的总图进一步的精度：有层次的文档文档中每一句话都有其价值用例规约组成用例名称：处理销售用例标识涉及的参与者涉及的用例描述用例的规格说明前置条件与后置条件正常大事流备选大事流其它非功能需求、设计约束、尚存在的问题举例(非正式型)处理退货主要成功场景：顾客带着商品到收款处退货，出纳员使用POS终端记录每一件。。可选场景：假设系统中找不到商品标识，那么就通知出纳员并建议他手工输入商品标识码〔或许商品的标识已经破损之间的通信失败，那么就。正式型用例UC1：处理销售主要参与者：出纳员受益人及其利益：出纳员：需要准确、快速的输入，并且不消灭支付错误销售人员：需要销售款得到更顾客：需要购置并花费最小的精力得到快速的效劳，并需要支持退货功能公司：需要准确地记录交易并满足客户的利益。需要支付授权效劳记录可承受的支付。需要一些容错功能。需要账目和存货清单得到自动的快速更政府税务机构：需要从每一次销售中收税。支付授权效劳：需要用正确的格式和协议传来的数字授权恳求。需要准确计算它们可支付给商店的款额前置条件：出纳员需要身份识别并授权后置条件：存储了销售状况，正确地计算了税金，更了账目和存货清单，记录了销售额，打印了收据主要成功场景：POS终端出预备购置出纳员开头一次的销售出纳员输入商品标识码计算所应付的款额。出纳员重复步骤34，始终处处理完全部商品为止。系统给出所应支付的总款额并计算税金出纳员告知顾客总价并恳求付款顾客付款，系统处理支付及存货清单系统系统打印收据顾客带着收据和商品离开类与类图类及类之间的关系案例李小平是一个爱书之人，家里各类书籍已过千册，而寻常又时常有朋友外借，因此需要一个个人图书治理系统。该系统应当能够将书籍的根本信息按计算机类、表打印。另外，还期望能够对书籍的购置金额、册数按特定时间周期进展统计。觉察类李小平是一个爱书之人家里各类书籍朋友外个人图书治理系统根本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能书籍时系统会自动按规章生成书号修改信息记录，可对外借状况列表购置金额、册数按特定时间周期进展统计。筛选备选类也无须对其进展建模；很明显“书籍”是一个很重要的类，而“书名属性，因此“规章”可以作为编写“书籍”类构造函数的指南。“根本信息”则是书名、作者、类别等描述书籍的根本信息统称字”则是代表其中之一，因此无需对其建模；关词语，并不是问题域的本质，因此先可以将其淘汰掉；筛选修选类建模，并改名为“计算机类书籍”和“非计算机类书籍借状况将组成“外借状况列表友”—借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考了能够更好地表述，将“外借状况”改名为“借阅记录模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分就是执行统计的主体。得到候选类在使用“名词动词法”查找类的时候，很多团队会在此消耗大量的时间，特别建立概要的了解，无需太过咬文嚼字关联分析建模多重性分析建模职责分析书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是增、修改、查询〔按关键字查询、统计〔按特定时限统计册数与金额。借阅记录类：借阅人〔朋友、借阅时间。借阅记录列表类：主要职责就是添加记录〔借出、删除记录〔归还〕以及打印借阅记录挨次图SequenceDiagram〔用例分析和设计阶段。描述对象是如何交互的，即描述消息如何在对象间发送和接收。纵轴时间、横轴对象描述了对象之间传送消息的时间挨次，用来表示用例中的行为挨次显示了交互的参与者以及参与者之间的消息挨次全部或局部用例而与参与者交互。留意：一个大事流一个挨次图挨次图例如-还书挨次图例如-POS机软件测试白盒测试也称玻璃盒测试建立在对程序的构造和语句的了解，以及对程序代码内部构造的了解的根底上测试掩盖率测试的目标两种测试方法掌握构造测试条件测试数据流测试循环测试根本路径测试测试掩盖率承受白盒法进展测试时，考虑的是测试用例对程序内部规律的掩盖程度。最彻底的白盒法是掩盖程序中的每一条路径，但这往往大到无法实现。因此承受其它一些标准来量度掩盖的程度，并期望掩盖程度尽可能高些。条件测试错误缘由布尔运算符错误布尔变量错误布尔括号错误关系运算符错误算术表达式错误策略分支测试：每个分支至少执行一次3-4个用例白盒测试的目标黑盒测试黑盒测试定义又称功能测试或数据驱动测试，主要关注软件的整体功能要在软件的接口处进展，不考虑程序内部的规律构造和内部特性觉察错误类型是否有不正确或遗漏的功能界面错误输入能否正确地承受，能否输出正确的结果是否有数据构造错误或外部信息〔如数据文件〕访问错误性能上是否满足要求是否有初始化或终止性错误比照测试(背靠背测试)也称“背靠背”测试、比较测试比照测试法主要用于处理被认为格外关键的系统时，在比照测试法中，将开发同一软件的两个独立但一样的版本不同的团队将开发这两个版本度AlphaBeta测试的定义与区分承受Alpha测试和Beta测试来觉察只有最终用户才能觉察的问题Alpha(α )测试：由一个用户在开发者的场所、在开发者指导下进展测试Beta(β )测试：由最终用户在一个或多个用户场所单独地进展测试测试停顿测试只能觉察软件中的错误和缺陷，不能证明软件没有错误和缺陷停顿策略：单位时间内觉察的错误数法缺陷密度法缺陷池方法缺陷引入法缺陷密度缺陷密度可以定义为每行代码的错误数0.003这样的数字10003一个更有用的方法是将缺陷密度设置为每千行代码〔KLOC〕的缺陷数我们可以使用缺陷密度度量来确定是否可以公布正在开发的软件的某个特定版本缺陷池这种方法中，我们将使用两个池，例如池X和池Y来跟踪缺陷现在，让池XDxYDy软件中觉察的唯一缺陷总数如下：唯一缺陷总数=Dx+Dy-XY中觉察的缺陷数软件中的缺陷总数可以估量为：缺陷总数=(Dx*Dy)/在XY中觉察的缺陷数缺陷池—mysoft3.0X池 475错误Y池 370错误125个缺陷同时消灭在X、Y池中唯一缺陷总数=475+370-125=720缺陷总数=475*370/125=1406可能剩余缺陷=1406-720=686隐蔽缺陷密度=686/1406=48.79%缺陷引入在此方法中，一组测试人员有意将缺陷埋入软件中另一组测试人员将试图发现这些缺陷这么做的主要目的是估量被检测到的引入的缺陷数与有意埋入的缺陷总数之比这使我们可以了解在此过程中未被觉察的不是有意埋入的缺陷的总数缺陷引入例如75个缺陷检测到引入缺陷总数：DS=35觉察的不是引入的缺陷：DUF=520软件中的缺陷总数=75/35*520=1114没有觉察的缺陷数=1114-520=594工程治理工程打算P315面对规模的度量：LOC、KLOCLOC作为面对规模的度量最为大家生疏，它们是直接可以测量的〔进展比较面对规模的度量是对软件以及开发软件过程的直接测量这些度量包括花费的精力和金钱、KLOC〔千行代码、创立的文档页数、错误数以及工程中的开发人员数面对规模的度量面对功能的度量：FP功能点度量的优势需求阶段可以估量工程的规模。推测实现软件功能所需源语句的数目语言无关多种语言工程中测量工程的生产率MIS应用程序不适用实时软件、嵌入式系统、数学软件可以使用功能部件的度量FP功能点的公式 FP=UFC*TCF 〔UFC：未调整功能点计数杂度因子〕UFC-未调整功能点计数功能计数项：外部输入外部输出

TCF：技术复外部查询外部文件内部文件本钱估算模型：COCOMOCOCOMOBarryBoehm开发的(南加州大学)COCOMO81COCOMOII模型系列COCOMO81模型类别：根本COCOMO：静态单变量模型COCOMO：考虑影响因素，调整模型COCOMO：考虑各个步骤的影响工程类型：有机:Organic嵌入式:Embedded半有机:Semidetached有机:Organic，各类应用程序，例如数据处理、科学计算等受硬件的约束比较小，程序的规模不是很大嵌入式:Embedded系统程序，例照实时处理、掌握程序等严密联系的硬件、软件和操作的限制条件下运行，软件规模任意半有机:Semidetached各类有用程序，介于上述两种软件之间，例如编译器〔程序〕规模和简单度都属于中等或者更高Bohem模型：？？？工作量=〔平均最大规模+最小规模+4*最可能的规模〕/6甘特图、PERT网络图风险分析风险治理风险分析影响的可能性这些因素还可以用于风险分析风险分析中还必需考虑如程序／应用程序的实现／操作方法类型、参与人数等其它因素风险确定风险通常依据标题分组，例如工程风险、技术风险和商业风险等工程风险涉及到进度安排问题、人员问题、资源问题、需求问题等性等问题商业风险涉及到关于投资回报和到达收支平衡必需的时间的问题风险推测风险推测中主要包括四个活动测量风险发生的概