软件工程
考点:
1.软件开发的生命周期模型
2.项目管理基础
3.软件质量管理基础
4.需求分析与设计基础
5.结构化分析和设计
6.测试及维护
7.软件过程改进
(CMM
)
软件开发的生命周期
瀑布模型:理想化的开发模型,要求有明确的需求分析,而达到这一点在现实中几乎不可能。(结构化的开发方法)
设计阶段依次是:概要设计、详细设计
测试阶段依次是:单元测试、集成测试(系统测试)、(客户参与的)确认测试。但是各阶段的测试计划制定是逆向的,即先设计集成测试计划(概要设计阶段)、再设计单元测试计划(详细设计阶段)在编码的时候需要同步进行单元测试
演化模型(原型法):动态定义需求的方法,不需要明确的需求,通过不断地试用对原型进行优化迭代。螺旋模型:结合瀑布模型和演化模型,每一个螺旋为一个周期(制定计划、风险分析、实施工程、用户评估),并产生一个原型。最初的第一个螺旋是从概念项目开始的。喷泉模型:最核心的特点就是迭代,所有的开发活动没有明显的边界,允许各种开发活动个交叉进行。
项目管理基础
核心问题:成本、质量、进度项目管理的主要活动:启动软件项目、度量、估算、风险分析、进度安排、追踪和控制开发过程中三个阶段:项目启动阶段、项目实施阶段、项目关闭阶段软件估算:软件规模估算、软件工作量估算、软件成本估算项目的组织和管理
Gannt图 PERT技术和CPM方法:PERT技术叫做计划评审技术,CPM方法叫做关键路径方法 项目组织和计划
计划的制定:人员职责矩阵和甘特图进度监控和计划的修正:EVA分析法 配置管理
制定配置管理计划实施变更管理:需要借助配置数据库和基线实施版本管理:对系统不同版本进行标识和跟踪的过程发行管理 风险管理
风险识别:项目风险、技术风险、商业风险风险估计风险驾驭
软件质量管理
ISO/IEC 9126软件质量模型的质量特性(6点)
功能性:与功能及其指定性质有关的一组软件质量(互操作性:同其他系统协同工作的能力)可靠性:衡量在规定的一段时间内和规定条件下维护性能水平的一组软件质量易用性:使用难易程度及规定或隐含用户对使用方式所做的评价相关的属性效率:衡量规定条件下软件的性能水平和所用资源量之间的关系的属性可维护性:与软件维护的难易程度相关的一组软件属性(改正性维护、完善性维护、适应性维护、预防性维护)
包括可理解性(良好的编程风格)、可修改性(信息的隐蔽原则)、可测试性 可移植性:与从某一个环境转移到另一个环境的能力有关的属性 Mc Call软件质量模型的质量特性
运行
正确性:是否做了该做的事?可靠性:总能准确地工作吗?效率:需要的资源多吗?完整性(安全性):是否安全?使用性:可使用吗? 修正
维护性:可调整吗?测试性:可测试吗?灵活性:可修改吗? 移植
移植性:可以在另一台机器使用吗?复用性:可以重复使用它的某些部分吗共运行性:能与外系统连接吗?
软件需求分析与设计
需求分析解决的是“做什么”的过程,系统设计则是解决“怎么做”的问题。需求分析包括:功能、性能、数据、界面、保密性等。分析过程:面向数据流的结构性分析方法、面向数据结构的Jackson方法等分析原则:表达和理解系统的数据域和功能域、自顶向下逐层分解、给出系统的逻辑视图和物理视图需求的分类:功能需求、非功能需求(性能需求)、设计约束软件设计:概要设计和详细设计软件设计的四个活动:体系结构设计、接口设计、数据设计和过程设计
结构化分析与设计
结构化分析:一种面向数据流的需求分析方法数据流图数据字典模块化原则
内聚:模块内部各个元素相互结合的紧密程度
巧合内聚:当模块中凑巧有一些程序段代码相同,又没有明确表现出独立的功能,把这些代码独立出来建立的模块即为巧合内聚模块。它是内聚程序最低的模块,缺点是模块的内容不易理解、不易维护和修改。逻辑内聚:这种模块把几种相关的功能的组合在一起,每次被调用时,由传送给模块的控制型参数来确定该模块应执行哪一种功能。时间内聚(经典内聚):这种模块大多为多功能模块,但要求模块的各个功能必须在同一时间段内执行。(初始化代码)过程内聚:通过流程图来确定模块划分,把流程图中的某一部分划出组成模块,就得到过程内聚模块。通信内聚:如果一个模块内各功能部分都使用了相同的输入数据,或产生了相同的输出数据,则称之为通信内聚模块。通常,通信内聚模块是通过数据流图来定义的。信息内聚(顺序内聚):这种模块完成多个功能,各个功能都在同一个数据结构上操作,每一项功能有一个唯一的入口点。可以看成多个功能内聚模块的组合,并达到信息的隐蔽,即把某个数据结构、资源或设备隐蔽在一个模块中,不为别的模块所知晓。功能内聚:一个模块中各个部分都是为完成一项具体功能而协同工作,紧密联系,不可分割的。功能内聚是内聚性最强的模块。 耦合:模块之间相互连接的紧密程度
内容耦合:如果一个模块直接访问另一个模块的内部数据;或者而两个模块有一部分程序代码重叠,则两个模块之间发生内容耦合。在内容耦合的情形下,被访问模块的任何变更或使用不同编译器的再编译都可能造成程序出错。公共耦合:若一组模块都访问同一个公共数据环境,则它们之间的耦合就是公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。外部耦合:一组模块都访问同一个全局简单变量则称之为外部耦合。(区别公共耦合)控制耦合:如果一个模块通过传送开关、标志、名字等控制信息,明显地选择另一模块的功能就是控制耦合。标记耦合:如果一组模块通过参数表传递记录信息,就是标记耦合。事实上,这一组模块共享了某一数据结构的子结构,而不是简单变量。数据耦合:如果一个模块访问另一个模块,彼此之间是通过数据参数来交换输出、输入信息的,则称为数据耦合。非直接耦合:如果两个模块之间没有直接关系,它们之间的联系完全是通过主模块的控制和调用来实现,就是非直接耦合。 扇入和扇出
扇入:本模块被其他模块调用的的次数,宜提高扇出:本模块调用其他模块的次数,宜减少
软件测试与维护
软件测试的基础
测试用例:测试数据和预期结果组成测试的目的:尽可能的发现软件存在的错误测试的原则:
尽早地、不断地进行软件测试,把软件测试贯穿于开发过程的始终所有测试都应该能够追溯到用户需求从小规模到大规模远在测试实施之前制定测试计划根据Pareto原理,80%的错误可能出现在20%的程序模块中,测试的关键就是找出这20%的模块应该由独立的第三方从事测试工作对非法和非预期的输入数据也要像合法和预期的输入数据一样编写测试用例检查软件是否做了应该做的事只是成功了一般,另一半是看软件是否做了不该做的事测试只能证明软件中有错误,不能证明软件中没有错误 测试的分类:单元测试、集成测试、确认测试、系统测试测试方法:
静态测试:程序不在机器上运行,采用个人工测试或计算机辅助分析,通过对静态结构的检查找出程序在编译阶段不能发现的错误(代码的逻辑合理性)动态测试:通过运行程序发现错误,分成白盒测试和黑盒测试回归测试:一旦发现程序中的错误后,还应选择部分或者全部原先已经测试通过的测试用例,对修改后的程序重新测试。 软件测试的步骤
单元测试:
着重关注:模块接口、局部数据结构、重要的执行通路、出错处理、边界条件等,通常采用白盒测试驱动模块和桩模块:很多情况下,被测模块不是直接使用的,而是存在上层的驱动模块,也存在下层的桩模块,因此要联合在一起测试 集成测试:发现模块间的接口和通信问题
集成测试主要发现设计阶段产生的错误,通常采用黑盒测试非增殖式:所有模块一次性组装进行集成测试增殖式:一个一个地增加模块进行集成测试,自顶向下/自底向上等 确认测试:检查软件的功能、性能和其他特征是否与用户需求一致
以需求规格说明书为依据,通常采用黑盒测试步骤:有效性测试、软件配置审查、验收测试a测试:用户在开发环境中(开发人员和测试人员监控下)的测试。类似于内测版b测试:用户在实际环境中的测试。类似于公测版 系统测试:把软件放在实际的硬件和网络环境中进行测试,主要测试软件的非功能需求和质量属性是否得到满足
根据系统方案说明书来设计测试用例,通常采用黑盒测试常见的系统测试主要有恢复测试、安全性测试、强度测试、性能测试、可靠性测试和安装测试等 调试:根据测试时发现的错误,找出原因和具体位置,进行改正
主要由程序开发人员来进行,谁开发的程序就由谁来调试常见的调试方法:试探法、回溯法、对分查找法、归纳法、演绎法 黑盒测试:将软件看成一个黑色盒子,完全不考虑软件的内部结构和处理算法,而只是检查软件功能是否按照软件规格说明书那样正常运行
等价类划分:将所有可能的输入值,划分为等价的部分,然后从每个部分中选取少数有代表性的数据作为测试用例
有效等价类:合理的、有意义的数据集。一个新的测试用例应该尽可能多地覆盖尚未覆盖的有效等价类。无效等价类:不合理的、无意义的数据集。一个新的测试用例应仅覆盖一个尚未覆盖的无效等价类。步骤:划分等价类、 从划分的等价类中选择测试用例 边界值分析:选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。(边界值更容易发现错误)错误推测法:列举出程序中所有可能的错误和容易发生错误的特殊情况,根据它来选择测试用例因果图:根据输入条件和输出结构的因果关系来设计测试用例 白盒测试(逻辑驱动测试):在已知产品内部工作过程的基础上,通过测试证明每种内部操作是否符合设计规格要求。
最常见的方法是逻辑覆盖法:(覆盖程度从弱到强)
语句覆盖:每条语句至少执行一次判定覆盖:每个判断的判定分支至少执行一次条件覆盖:每个判断的每个条件的可能取值至少执行一次(判定覆盖与条件覆盖不存在包含关系)判定-条件覆盖:既满足判定覆盖,有满足条件覆盖条件组合覆盖:每个判断的所有可能的条件组合都要执行一个路径覆盖:覆盖程序中所有可能的路径 一般题目可以通过真值表法去解决 软件维护
软件维护的类型:
改正性维护:改正使用过程中发现的隐蔽错误而做的维护适应性维护:为了适应变化的环境而做的维护完善性维护:为了扩充或完善系统的功能和性能而做的维护预防性维护:为了提高软件的可靠性和可维护性而做的维护 软件的可维护性:理解、改正、改进软件的难易程度 软件过程改进(CMM)
软件过程成熟程序的分级标准:
初始级可重复级已定义级已管理级优化级