《天津理工大学软件工程总结考试.docx》由会员分享,可在线阅读,更多相关《天津理工大学软件工程总结考试.docx(19页珍藏版)》请在三一办公上搜索。
1、天津理工大学软件工程总结考试软件过程的步骤或基本活动:1.软件描述 2.软件设计和实现 3.软件有效性验证 4.软件进化 软件生命周期或软件需求过程 1.需求分析和定义2.系统和软件设计3.实现和单元测试4.集成和系统测试5.运行和维护 增量式开发过程的好处是:1客户无需等到整个系统的实现。第一个增量会满足他们大多数关键的需求,因此,软件马上就能使用。2.客户可以将早期的增量作为原型,从中获得对后面系统增量的需求经验。3.项目总体性失败的风险比较低。虽然可能在一些增量中遇到问题,但是其他一些增量将会成功的交付给客户4.因为具有最高优先权的服务被首先交付,而后面的增量也不断被集成进来,这就使得最
2、重要的系统服务肯定接受了最多的测试。这就意味着在系统的最重要的部分,客户不太可能遇到软件失败。 第一章 软件工程和计算机科学的区别: 计算机科学侧重理论和基础,而软件工程则侧重于软件开发和交付的实际活动 软件工程和系统工程的区别: 系统工程侧重基于计算机系统开发的所有方面,包括硬件,软件,和处理工程。软件工程只是它的一部分 1.软件是计算机程序和所有使程序正确运行所需要的相关文档和配置信息 软件产品分为:Generic通用、Bespoke (custom)定制 2、软件工程是一门工程学科,涉及软件生产的各个方面。软件工程人员运用的是系统的、有组织的工作方法。 6、软件过程模型 从特定角度提出的
3、软件过程的简化表示形式 Examples of process perspectives are 工作流模型 数据流或活动模型 角色/动作模型 软件开发模型 Waterfall瀑布型开发方法 Iterative development迭代式开发方法 Component-based software engineering基于组件的软件工程 7、the costs of software engineering软件工程的成本 软件开发成本约占60%,测试成本占40%。对于定制软件而言,进化成本常常高于开发成本。 8、software engineering methods软件工程方法: .软件开
4、发的结构化研究方法,包括:系统模型、标记法、规划、设计忠告和过程指南 9、CASE (Computer-Aided Software Engineering)计算机辅助软件工程: 旨在使软件过程活动自动化的软件系统。CASE常用作方法支持 10、the attributes of good software优良软件的特点:软件应具有用户所需的功能与性能,而且应该可维护、可靠、可用 11、key challenges facing software engineering软件工程面临的主要挑战: Legacy遗留 Heterogeneity多样性挑战 delivery交付上的挑战 trust信任
5、的挑战 2Software engineering cost analysis 软件工程成本分析 定制软件: 对于瀑布模型,系统描述、设计、实现和集成的成本独立测算,其中系统集成和测试活动所需的费用最高,约占40%。 对于迭代式开发,系统描述、设计和开发之间没有严格的划分界限,但系统描述的成本降低。在软件开发活动中,系统描述、实际、实现、集成和测试是并行的。 基于组件的软件开发,描述部分约20%,开发成本约30%,集成和测试约50% 除系统开发成本之外,在软件投入使用后软件的变更也需要成本。进化成本对许多使用期限长的软件系统而言,有可能超过开发成本的34倍。相对于小的业务系统就降低许多了。 为
6、个人计算机配置的软件产品 - 1 - 这类产品通常基于一个概要描述,用进化式开发方法开发。描述成本相对较低,但由于要用在不同的配置中,所以测试成本比较多。 通用软件产品 进化成本很难估算。多数情况下,产品的进化过程并不大。通用软件的进化成本不能像定制软件一样独立评估,而是作为该系统的下一个版本的开发成本。 第二章 1System engineering process 系统工程过程 需求定义 系统退役 系统设计 系统进化 子系统开发 系统安装 系统集成 2System modeling 系统建模 在系统需求和设计活动中,系统被建模成一系列组件和组件间的关系。通常是以图的形式描述在系统体系结构模
7、型中。系统体系结构模型通常以方块图来描述,展现一些主要的子系统以及这些子系统之间的关联。 3System evolution 系统进化 大型和复杂的系统都会有一个非常长的生存期。在整个生存期内,必须改进原有的系统需求中的错误进而满足出现的新需求。使用系统的机构可能重新改组并且因此一种不同的方式使用系统 4System procurement process 系统采购过程 系统的采购过程主要是对机构以最佳方式获得系统做出决策并决定系统的最佳提供商 调整需求 选择系统 发出招标请求 选择供应商 对现有系统 做市场调查 发出招标请求 选择投标人 合同谈判 签订开发合同 第四章 进化式开发有两个基本类
8、型; 探索式开发 其目标是与用户一起工作,共同探索系统需求,知道最后交付系统。这类开发是从需求较清楚的部分开始,根据用户的建议逐渐向系统中添加功能。 抛弃式原型 这种开发方法的目标是理解用户需求,然后在给系统需求有更深刻理解时,能够很快在软件过程的好处是描述可以不断地补充完整。 基于进化式方法的软件过程的好处是描述可以不断地补充完善 - 2 - 存在两个问题 1.过程不可见 管理者需要经常性得交付来把握进度,如果系统开发速度很快,要产生每个版本的文档来反应变更就很不划算了 一、软件工程模型software process model 二、waterfall model瀑布模型:直到上一阶段完成
9、,下一阶段才能启动 Evolutionary development进化式开发:优势:描述可以不断补充完善 劣势:过程不可见;系统结构通常较差 进化式开发的两种基本类型:Exploratory development 探索式开发、Throw-away prototyping抛弃式原型 Component-based software engineering基于组件的软件工程其过程模型如下图: 三、Spiral development螺旋式开发 它不是将软件过程用一系列活动和活动间的回溯来表示,而是将过程用螺旋线表示。每个回路表示软件过程的一个阶段。 2、四部分:目标设置 风险评估和规避、开发和
10、有效性验证、规划. 四、Software validation软件有效性验证:是要看系统是否符合它的描述以及系统是否符合客观的预测目标。 5、 测试过程的阶段:组件测试、系统、接收测试 五、Activities in CASE (Computer-aided software engineering) 六、CASE classification分类:从功能角度看;从过程角度看;从集成角度看 Fuggetta提出的分类:工具,工作平台,环境 第五章 一、 Management activities管理活动 .提出书面建议 .项目规划和调度 .项目成本 项目监督和审评 .人员选择和评价 .写作并-
11、 3 - 称述工作报告 二、 Types of planning计划的类型 质量计划、有效性验证计划、配置管理计划、维护计划、人员开发计划 三、 Milestones in the requirements process需求过程里程碑: 四、 Project scheduling process项目调度 五、 three main project management: 项目风险 产品风险 业务风险 types of risk in project management:技术风险、人员风险、机构风险、需求、估算. 第六章 1Functional requirement and example
12、s 功能需求和举例 功能需求描述系统所预期提供的功能或服务。取决于开发的软件类型,软件未来的用户以及开发的系统类型。 LIBSYS-大学图书馆系统几种功能需求: 用户能从总的数据库中查询或者是选择其中的一个子集 系统能提供适当的浏览器供用户阅读馆藏文献 每次借阅能对应一个独特的识别符(order_id),可拷贝到用户账户的常备储存区内 2Non-functional requirement and examples 非功能需求和举例 对系统提供的服务或功能给出的约束,与系统的总体特性相关。 图书馆系统的LIBSYS的产品需求,机构需求和外部需求的实例: 产品需求:它应该能将所有APSE和用户之
13、间的必须的通信用标准的Ada字符集表达 机构需求:系统开发过程和可交付的文档将遵照XYZCo-SP-STAN-95中的相关定义 外部需求:系统不应该对系统的操作人员公开客户出名字和索引代码之外的任何个人的信息 三、types of Non-functional requirement - 4 - Non-functionalrequirementsProductrequirementsOrganisationalrequirementsExternalrequirementsEfficiencyrequirementsReliabilityrequirementsPortabilityrequ
14、irementsInteroperabilityrequirementsEthicalrequirementsUsabilityrequirementsDeliveryrequirementsImplementationrequirementsStandardsrequirementsLegislativerequirementsPerformancerequirementsSpacerequirementsPrivacyrequirementsSafetyrequirements四、metrics in Non-functional requirement Requirements meas
15、ures非功能需求度量 性质 速度 度量方法 每秒处理的事务 用户/事件响应时间 屏幕刷新时间 K字节 RAM芯片数 培训时间 帮助画面数 失败平均时间 无效的概率 失败发生率 有效性 失败之后的重启次数 事件引起失败的百分比 失败中数据崩溃的可能性 依赖于目标的语句百分比 目标系统数 规模 易用性 可靠性 鲁棒性 可移植性 5Documents used in software requirements 软件需求文档 软件需求文档是对系统开发者应当实现的内容的正式陈述。包括系统的用户需求和一个详细的系统需求描述。需求文档中内容的详细程度,取决于所要开发的系统的类型,以及所使用的开发过程。 第
16、七章 1The process of requirement engineering 需求工程的过程 系统可行性研究;需求导出和分析;需求描述;需求有效性验证 - 5 - 可行性研究 需求导出 和分析 需求描述 需求有效性验证 可行性报告 系统模型 用户需求和系统需求 需求文档 2The main content of feasibility studies 可行性研究的主要内容 进行一项可行性研究包括信息评估,信息汇总和报告生成 3Process activities in requirement elicitation and analysis 需求导出和分析的过程活动 需求发现;需求分类
17、和组织;优先排序和冲突解决;需求文档编制 4Requirement validation techniques(three) 需求有效性验证技术 需求评审;原型建立;测试用例生成 5Requirement change management 需求变更管理 三个基本阶段: 问题分析和变更描述过程:始于一个被识别的需求问题或是一份明确的变更提议 变更分析和成本计算:使用可追溯性信息和系统需求的一般知识对被提议的变更产生的影响进行评估 变更实现:必要的话,需求文档,系统设计和实现都要做修改 第八章 * 1Principle system model 上下文模型context model 行为模型 B
18、ehavioural models 数据模型 data model 对象模型 object model 结构化方法 structured methods 2Examples of system models(5) 系统模型实例 数据流模型(data processing model);组成模型(composition model);体系结构模型(architectural model);分类模型(classfication model);激励-响应模型(stimulate/response model) 3Definition of data-flow models 数据流模型的定义 数据流模
19、型是从功能角度来看待系统而得到的模型表示,对数据的每一个变换用一个函数或过程来描述,描述了所发生的完整的行动序列,从对输入的处理到系统的响应。 第十一章 1 Content of architectural models 体系结构模型的内容 静态结构模型;动态结构模型;接口模型;关系模型;分布模型 2 Major components of Client-sever model 客户机/服务器模型的主要组成部分 一组给其他子系统提供服务的单机服务器;一组向服务器请求服务的客户机;一个连接客户机和服务器的网站 第十七章 1 Describe incremental development and
20、 prototyping by figure 用图形描述增量式开发和原型构造 - 6 - 进化式开发 概要需求 抛弃式原型构造 交付的系统 可执行原型+系统描述 2 Tools included in a Rapid Application Development 快速应用开发的工具 数据库编程语言;界面生成器;与办公应用的连接;报告生成器 第二十三章 1Model of the software testing process 软件测试过程的模型 系统测试;组件测试;测试用例设计;测试自动化 测试用例 测试数据 测试结果 测试报告 设计测试用例 准备测试数据 用测试数据运行程序 将结果与测试
21、用例进行比较 2Structural testing 结构化测试 结构化测试是根据软件的结构知识和实现知识导出测试的测试用例设计方法,又称为“白盒测试” 一、软件需求分析 1、需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的 “做什么” 的问题。 2、结构化分析方法 l 面向数据流进行需求分析的方法 l 结构化分析方法适合于数据处理类型软件的需求分析 l 具体来说,结构化分析方法就是用抽象模型的概念,按照软件内部数据传递、变换的关系,自顶向下逐层分解,直到找到满足功能要求的所有可实现的软件为止 描述银行取款过程的数据流图: 4、结构花英语:是一种介于自然语言和形
22、式化语言之间的语言,语言的正文用基本控制结构进行分割,加工中的操作用自然语言短语来表示 - 7 - 其基本控制结构有三种: 简单陈述句结构:避免复合语句; 重复结构:while_do 或repeat_until 结构。 判定结构:if_then_else 或case_of 结构; 例子:商店业务处理系统中“检查发货单”: if 发货单金额超过$500 then if 欠款超过了60天 then 在偿还欠款前不予批准 else 发批准书,发货单 else if 欠款超过60天 then 发批准书,发货单及赊欠报告 else 发批准书,发货单 5、判定表:如果数据流图的加工需要依赖于多个逻辑条件的
23、取值,使用判定表来描述比较合适。 例子:以“检查发货单”为例 二、软件设计方法 1、 软件设计的目标和方法 根据用信息域表示的软件需求,以及功能和性能需求,进行数据设计、系统结构设计、过程设计。 软件设计任务:从工程管理角度来看,软件设计分两步完成 l 概要设计,将软件需求转化为数据结构和软件的系统结构。 l 详细设计,即过程设计。通过对结构表示进行细化,得到软件的详细的数据结构和算法 2、 软件设计过程 制定规范 软件系统结构的总体设计 处理方式设计 数据结构设计 可靠性设计 编写概要设计阶段的文档 概要设计评审 3、 信息隐藏:是指每个模块的实现细节对于其它模块来说是隐蔽的。也就是说,模块
24、中所包含的信息不允许其它不需要这些信息的模块使用。 4、 模块独立性:是指软件系统中每个模块只涉及软件要求的具体的子功能, 而和软件系统中其它的模块的接口是简单的 例如, 若一个模块只具有单一的功能且与其它模块没有太多的联系, 则称此模块具有模块独立性 - 8 - 一般采用两个准则度量模块独立性。即模块间耦合和模块内聚 耦合是模块之间的互相连接的紧密程度的度量。 内聚是模块功能强度(一个模块内部各个元素彼此结合的紧密程度)的度量。 模块独立性比较强的模块应是高内聚低耦合的模块。 5、 变换型系统结构:变换型数据处理问题的工作过程大致分为三步,即取得数据,变换数据和给出数据。相应于取得数据、变换
25、数据、给出数据,变换型系统结构图由输入、中心变换和输出等三部分组成。 6、 事务性系统结构:它接受一项事务,根据事务处理的特点和性质,选择分派一个适当的处理单元,然后给出结果。 在事务型系统结构图中,事务中心模块按所接受的事务的类型,选择某一事务处理模块执行。各事务处理模块并列。每个事务处理模块可能要调用若干个操作模块,而操作模块又可能调用若干个细节模块。 7、 变换分析方法由以下四步组成: l 重画数据流图; l 区分有效(逻辑)输入、有效(逻辑)输出和中心变换部分; l 进行一级分解,设计上层模块; l 进行二级分解,设计输入、输出和中心变换部分的中、下层模块。 8、 文件设计 文件设计过
26、程主要分为两个阶段。第一个阶段是文件的逻辑设计,主要在概要设计阶段实施。一般要根据文件的特性,来确定文件的组织方式。 顺序文件:连续文件、串联文件。 直接存取文件:无关键字直接存取文件、带关键字直接存取文件、桶式直接存取文件。 索引顺序文件:其基本数据记录按顺序文件组织,记录排列顺序必须按关键字值升序或降序安排,且具有索引部分,也按同一关键字进行索引。 分区文件:这类文件主要用于存放程序。它由若干称为成员的顺序组织的记录组和索引组成。 二、程序编码 1、 结构化程序设计 结构化程序设计主要包括两方面: l 在编写程序时,强调使用几种基本控制结构,通过组合嵌套,形成程序的控制结构。尽可能避免使用
27、GOTO语句。 l 在程序设计过程中,尽量采用自顶向下和逐步细化的原则,由粗到细,一步步展开。 2、程序设计风格:程序实际上也是一种供人阅读的文章,有一个文章的风格问题。应该使程序具有良好的风格。 源程序文档化、 数据说明、 语句结构、 输入输出方法 3、程序复杂性度量 程序复杂性主要指模块内程序的复杂性。它直接关联到软件开发费用的多少,开发周期的长短和软件内部潜伏错误的多少。 减少程序复杂性,可提高软件的简单性和可理解性,并使软件开发费用减少,开发周期缩短,软件内部潜藏错误减少。 三、软件测试 1、 软件测试目的: 基于不同的立场,存在着两种完全不同的测试目的: 从用户的角度出发,普遍希望通
28、过软件测试暴露软件中隐藏的错误和缺陷,以考虑是否- 9 - 可接受该产品。 从软件开发者的角度出发,则希望测试成为表明软件产品中不存在错误的过程,验证该软件已正确地实现了用户的要求,确立人们对软件质量的信心。 测试的目的是 l 想以最少的时间和人力,系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试,我们就能够发现软件中的错误。 l 测试的附带收获是,它能够证明软件的功能和性能与需求说明相符合。 l 实施测试收集到的测试结果数据为可靠性分析提供了依据。 l 测试不能表明软件中不存在错误,它只能说明软件中存在错误 2、 测试与软件工程各阶段的关系 n 软件开发过程是一个自顶向下,逐步
29、细化的过程 n 软件计划阶段定义软件作用域 n 软件需求分析建立软件信息域、功能和性能需求、约束等 n 软件设计 n 把设计用某种程序设计语言转换成程序代码 3、 黑盒测试 这种方法是把测试对象看作个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。 黑盒测试又叫做功能测试或数据驱动测试。 n 黑盒测试方法是在程序接口上进行测试,主要是为了发现以下错误: u 是否有不正确或遗漏了的功能? u 在接口上,输入能否正确地接受? 能否输出正确的结果? u 是否有数据结构错误或外部信息(例如数据文件)访问错误? u 性能上是否能够满
30、足要求? u 是否有初始化或终止性错误? n 用黑盒测试发现程序中的错误,必须在所有可能的输入条件和输出条件中确定测试数据,来检查程序是否都能产生正确的输出。 4、 白盒测试:此方法把测试对象看做一个透明的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。 通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。 软件人员使用白盒测试方法,主要想对程序模块进行如下的检查: u 对程序模块的所有独立的执行路径至少测试一次; u 对所有的逻辑判定,取“真”与取“假”的两种情况都至少测试一次; u
31、在循环的边界和运行界限内执行循环体; u 测试内部数据结构的有效性,等。 5、 逻辑覆盖:逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。语句覆盖、 判定覆盖、条件覆盖判定条件覆盖、 条件组合覆盖、 路径覆盖。 - 10 - L1 ( a c e ) = (A1) and (B=0) and (A=2) or (X/A1) = (A1) and (B=0) and (A=2) or (A1) and (B=0) and (X/A1) = (A=2) and (B=0) or (A1) and (B=0) and (X/A1) L2 ( a b d ) = not(A1)
32、 and (B=0) and not(A=2) or (X1) = not (A1) or not (B=0) and not (A=2) and not (X1) = not (A1) and not (A=2) and not (X1) or not (B=0) and not (A=2) and not (X1) L3 ( a b e) = not (A1) and (B=0) and (A=2) or (X1) = not (A1) or not (B=0) and (A=2) or (X1) = not (A1) and (A=2) or not (A1) and (X1) or n
33、ot (B=0) and (A=2) or not (B=0) and (X1) L4 ( a c d ) = (A1) and (B=0) and not (A=2) or (X/A1) = (A1) and (B=0) and not (A=2) and not (X/A1) - 11 - 6、 软件测试策略 测试过程按4个步骤进行,即单元测试、组装测试、确认测试和系统测试。 l 开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能 l 组装测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。 l 确认测试则是要检查
34、已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。 l 系统测试把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。 数据流图 假设一家工厂的采购部每天需要一张定货报表,报表按零件编号排序,表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据:零件编号,零件名称,定货数量,目前价格,主要供应者,次要供应者。零件入库或出库称为事务,通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。 状态转换图 - 12 - ASP检索程序流程图: - 13 - - 14 - - 15 -