软件工程复习

软件的特性1. 软件是一种逻辑实体，而不是具体的物理实体。它具有抽象性2. 软件的开发设计、生产、维护与硬件不同3. 在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题4. 大多数软件是定制的5. 软件的开发和运行常常受到计算机系统的限制对计算机系统有着不同程度的依赖性6. 软件开发至今尚未完全摆脱手工艺的开发方式7. 软件是复杂的8. 软件成本相当昂贵9. 相当多的软件工作涉及到社会因素软件危机的表现 、原因软件危机-主要表现：1. 对软件开发成本和进度的估计不准确2. 用户不满意3. 软件质量不高、可靠性差4. 软件常常不可维护、错误难以改正5. 缺乏适当的文档资料6. 软件成本占系统总成本的比例逐年上升（1985-90%）7. 软件开发速度跟不上计算机发展速度归结为主要为三方面-“时间、成本、质量”软件危机-原因：1. 软件规模日渐庞大（数量、功能、成本、质量、时间）2. 软件开发管理困难。逻辑部件而不是物理部件。在写出程序代码并在计算机运行之前，软件开发过程的进展情况较难衡量，软件开发的质量也较难评价。因此，管理和控制软件开发过程相当困难。3. 开发人员错误的观念、方法和技术重编程、轻需求。生产方式落后：个体手工方式。开发技术落后开发工具落后4. 忽视软件开发前期的需求分析 5. 开发过程缺乏统一的、规范化的方法论的指导6. 文档资料不齐全或不准确7. 忽视与用户之间、开发组成员之间的交流8. 忽视测试的重要性9. 不重视维护或由于上述原因造成维护工作的困难10. 需求变化预料不足用例归约用例规约-进行用例阐述用例规约：更进一步的精度用例文档的核心，而用例图作为用例文档的总图进一步的精度：有层次的文档文档中每一句话都有其价值用例规约组成1. 用例名称：处理销售2. 用例标识3. 涉及的参与者4. 涉及的用例5. 描述6. 用例的规格说明前置条件 与 后置条件 正常事件流备选事件流7. 其它非功能需求、设计约束、尚存在的问题举例(非正式型)处理退货主要成功场景：顾客带着商品到收款处退货，出纳员使用POS终端记录每一件被退回的商品。可选场景：如果系统中找不到商品标识，那么就通知出纳员并建议他手工输入商品标识码（或许商品的标识已经破损）；如果系统检测到和外部税金计算系统之间的通信失败，那么就。正式型1. 用例 UC1：处理销售2. 主要参与者：出纳员3. 受益人及其利益：1) 出纳员：需要精确、快速的输入，并且不出现支付错误2) 销售人员：需要销售款得到更新3) 顾客：需要购买并花费最小的精力得到快速的服务，并需要支持退货功能4) 公司：需要精确地记录交易并满足客户的利益。需要支付授权服务记录可接受的支付。需要一些容错功能。需要账目和存货清单得到自动的快速更新5) 政府税务机构：需要从每一次销售中收税。6) 支付授权服务：需要用正确的格式和协议传来的数字授权请求。需要精确计算它们可支付给商店的款额4. 前置条件：出纳员需要身份识别并授权5. 后置条件：存储了销售情况，正确地计算了税金，更新了账目和存货清单，记 录了销售额，打印了收据6. 主要成功场景：1) 顾客带着商品到POS终端出准备购买2) 出纳员开始一次新的销售3) 出纳员输入商品标识码4) 系统记录销售的商品并给出商品的描述、单价和折扣，并根据某些价格规则计算所应付的款额。出纳员重复步骤3和步骤4，一直到处理完所有商品为止。5) 系统给出所应支付的总款额并计算税金6) 出纳员告诉顾客总价并请求付款7) 顾客付款，系统处理支付8) 系统记录下已完成的销售，并将销售和支付信息发送给外部的账目系统以及存货清单系统9) 系统打印收据10) 顾客带着收据和商品离开类与类图类及类之间的关系案例李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。发现类李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。 筛选备选类l “李小平”、“人”、“家里”很明显是系统外的概念，无须对其建模；l 而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；l 很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。l “基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模；l “功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；筛选修选类l “计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；l “外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；l “购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类书籍列表，也就是执行统计的主体。得到候选类在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无需太过咬文嚼字 关联分析建模多重性分析建模职责分析l 书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。l 书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是新增、修改、查询（按关键字查询）、统计（按特定时限统计册数与金额）。l 借阅记录类：借阅人（朋友）、借阅时间。l 借阅记录列表类：主要职责就是添加记录（借出）、删除记录（归还）以及打印借阅记录 顺序图l 定义：也可叫作序列图、时序图Sequence Diagraml 以可视化方式为系统中逻辑的流程建模，通常用于（用例）分析和设计阶段。l 描述对象是如何交互的，即描述消息如何在对象间发送和接收。l 纵轴时间、横轴对象l 描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序l 显示了交互的参与者以及参与者之间的消息顺序，也显示了系统为了执行全部或部分用例而与参与者交互。l 注意：一个事件流一个顺序图顺序图示例-还书顺序图示例-POS机软件测试白盒测试1) 也称玻璃盒测试建立在对程序的结构和语句的了解，以及对程序代码内部结构的了解的基础上2) 测试覆盖率3) 测试的目标4) 两种测试方法l 控制结构测试条件测试数据流测试循环测试l 基本路径测试测试覆盖率l 采用白盒法进行测试时，考虑的是测试用例对程序内部逻辑的覆盖程度。l 最彻底的白盒法是覆盖程序中的每一条路径，但这往往大到无法实现。l 因此采用其它一些标准来量度覆盖的程度，并希望覆盖程度尽可能高些。条件测试错误原因布尔运算符错误布尔变量错误布尔括号错误关系运算符错误算术表达式错误策略分支测试：每个分支至少执行一次域测试：为每个关系运算符使用3-4个用例白盒测试的目标 黑盒测试 黑盒测试定义又称功能测试或数据驱动测试，主要关注软件的整体功能已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求要在软件的接口处进行，不考虑程序内部的逻辑结构和内部特性发现错误类型是否有不正确或遗漏的功能界面错误输入能否正确地接受，能否输出正确的结果是否有数据结构错误或外部信息（如数据文件）访问错误性能上是否满足要求是否有初始化或终止性错误对比测试(背靠背测试)l 也称“背靠背”测试、比较测试l 对比测试法主要用于处理被认为十分关键的系统时， 在对比测试法中，将开发同一软件的两个独立但相同的版本l 不同的团队将开发这两个版本l 执行比较测试期间，使用相同的测试用例来评估对软件功能规格说明的符合程度Alpha测试和Beta测试的定义与区别采用Alpha测试和Beta测试来发现只有最终用户才能发现的问题Alpha( )测试：由一个用户在开发者的场所、在开发者指导下进行测试Beta( )测试：由最终用户在一个或多个用户场所单独地进行测试测试停止测试只能发现软件中的错误和缺陷，不能证明软件没有错误和缺陷停止策略：l 单位时间内发现的错误数法l 缺陷密度法l 缺陷池方法l 缺陷引入法缺陷密度缺陷密度可以定义为每行代码的错误数应是一个象0.003 这样的数字这个数字实际上表示每1000 行代码中的缺陷密度是3一个更有用的方法是将缺陷密度设置为每千行代码（KLOC）的缺陷数我们可以使用缺陷密度度量来确定是否可以发布正在开发的软件的某个特定版本缺陷池l 这种方法中，我们将使用两个池，例如池X 和池Y来跟踪缺陷l 现在，让池X 中的缺陷数为Dx，池Y 中的缺陷数为Dyl 软件中发现的唯一缺陷总数如下：l 唯一缺陷总数= Dx + Dy - 在X 和Y 中发现的缺陷数l 软件中的缺陷总数可以估计为：l 缺陷总数= (Dx*Dy) / 在X 和Y 中发现的缺陷数缺陷池mysoft3.0l X池-475错误l Y池-370错误l 有125个缺陷同时出现在X、Y池中l 唯一缺陷总数=475+370-125=720l 缺陷总数=475*370/125=1406l 可能剩余缺陷=1406-720=686l 隐藏缺陷密度= 686/1406=48.79%缺陷引入l 在此方法中，一组测试人员故意将缺陷埋入软件中 另一组测试人员将试图发现这些缺陷l 这么做的主要目的是估计被检测到的引入的缺陷数与故意埋入的缺陷总数之比l 这使我们可以了解在此过程中未被发现的不是故意埋入的缺陷的总数缺陷引入示例l 有意埋入75个缺陷l 检测到引入缺陷总数：DS=35l 发现的不是引入的缺陷：DUF=520l 软件中的缺陷总数=75/35*520=1114l 没有发现的缺陷数=1114-520=594项目管理项目计划 P315面向规模的度量：LOC、KLOCLOC 作为面向规模的度量l 最为大家熟悉，它们是直接可以测量的l 可以很容易地测量源代码行数，并将其与缺陷发生率、开发时间和花费的钱数（美元、人民币）进行比较面向规模的度量是对软件以及开发软件过程的直接测量l 这些度量包括花费的精力和金钱、KLOC（千行代码）、创建的文档页数、错误数以及项目中的开发人员数面向规模的度量面向功能的度量：FP功能点度量的优势l 需求阶段可以估计项目的规模。l 预测实现软件功能所需源语句的数目l 语言无关l 多种语言项目中测量项目的生产率l 最初用在商业应用程序和MIS应用程序l 不适用实时软件、嵌入式系统、数学软件可以使用功能部件的度量功能点FP功能点的公式FP =UFC*TCF（UFC：未调整功能点计数TCF：技术复杂度因子）UFC-未调整功能点计数功能计数项：1. 外部输入2. 外部输出3. 外部查询4. 外部文件5. 内部文件成本估算模型：COCOMO COCOMO由Barry Boehm开发的(南加州大学)COCOMO 81 COCOMO II 模型系列COCOMO 81模型类别：基本COCOMO：静态单变量模型中等COCOMO：考虑影响因素，调整模型高级COCOMO：考虑各个步骤的影响项目类型：有机: Organic嵌入式: Embedded半有机: Semidetached有机: Organic，各类应用程序，例如数据处理、科学计算 等受硬件的约束比较小，程序的规模不是很大 嵌入式: Embedded系统程序，例如实时处理、控制程序等 紧密联系的硬件、软件和操作的限制条件下运行，软件规模任意 半有机: Semidetached各类实用程序，介于上述两种软件之间，例如编译器（程序） 规模和复杂度都属于中等或者更高 Bohem模型：？工作量=（平均最大规模+最小规模+4*最可能的规模）/6甘特图、PERT网络图风险管理风险分析l 在软件项目中，风险指的是对软件开发的成本、质量或进度安排造成负面影响的可能性l 这些因素还可以用于风险分析l 风险分析中还必须考虑如程序应用程序的实现操作方法、使用的工具类型、参与人数等其它因素风险确定l 风险通常按照标题分组，例如项目风险、技术风险和商业风险等l 项目风险涉及到进度安排问题、人员问题、资源问题、需求问题等l 技术风险涉及到技术、平台、环境的选择以及有关可移植性、安全性、可靠性等问题l 商业风险涉及到关于投资回报和达到收支平衡必需