在软件开发的V模型中,应该在()阶段制定单元测试计划。
A、需求...
单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。
对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如C语言中单元指一个函数,Java里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等。
总的来说,单元就是人为规定的最小的被测功能模块。
单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
所以答案选C
最小工作单元是什么?
所谓招标采购合同规划中的最小工作单元是指在工程建设项目或政府采购项目中,具备独立工作流程、能够单独实施的工作单元,具体体现为施工活动中的某项工作任务、设计活动中的某项专业设计工作,或者某货物的采购等。
最小工作单元通常应该具备不可再分解性,不同行业领域、不同种类的工程建设项目或政府采购项目,其最小工作单元不尽相同。
应用软件是怎样设计的?
软件系统的开发是按阶段进行的,一般划分为以下阶段:可行性讨论;需求分析;系统设计(概要设计、详细设计);程序开发;编码,单元测试;系统测试;系统维护。
软件开发过程中要明确各阶段的工作目标、实现该目标所必需的工作内容以及达到的标准。
只有在上一个阶段的工作完成后,才能开始下一阶段的工作。
1.可行性讨论 明确系统的目的、功能和要求,了解目前所具备的开发环境和条件,论证的内容有:① 在技术能力上是否可以支持;② 在经济上效益如何;③ 在法律上是否符合要求;④ 与部门、企业的经营和发展是否吻合;⑤ 系统投入运行后的维护有无保障。
可行性讨论的目的是判定软件系统的开发有无价值。
分析和讨论的内容形成“系统开发计划书”,主要内容有: (1) 开发的目的及所期待的效果; (2) 系统的基本设想,涉及的业务对象和范围; (3) 开发进度表,开发组织结构; (4) 开发、运行的费用; (5) 预期的系统效益; (6) 开发过程中可能遇到的问题及注意事项。
2、系统需求分析 系统需求分析是软件系统开发中最重要的一个阶段,直接决定着系统的开发质量和成败,必须明确用户的要求和应用现场环境的特点,了解系统应具有哪些功能、数据的流程和数据之间的联系。
需求分析应有用户参加,到使用现场进行调研学习,软件设计人员应虚心向技术人员和使用人员请教,共同讨论解决需求问题的方法,对调查结果进行分析,明确问题的所在。
需求分析的内容编写成“系统需求分析报告”。
3.系统设计 可根据系统的规模分成概要设计和详细设计两个阶段。
概要设计包括:① 划分系统模块;② 每个模块的功能确定;③ 用户使用界面概要设计;④ 输入输出数据的概要设计;⑤ 报表概要设计;⑥ 数据之间的联系、流程分析;⑦ 文件和数据库表的逻辑设计;⑧ 硬件、软件开发平台的确定;⑨ 有规律数据的规范化及数据惟一性要求。
系统的详细设计是对系统的概要设计进一步具体化,其主要工作有:① 文件和数据库的物理设计;② 输入输出记录的方案设计;③ 对各子系统的处理方式和处理内容进行细化设计;④ 编制程序设计任务书。
程序说明书通常包括程序规范、功能说明、程序结构图,通常用HPIPO(Hierarchy Plus Input Process Output)图描述。
4、程序开发 根据程序设计任务书的要求,用计算机算法语言实现解题的步骤,主要工作包括:① 模块的理解和进一步划分;② 以模块为单位的逻辑设计,也就是模块内的流程图的编制;③ 编写代码,用程序设计语言编制程序;④ 进行模块内功能的测试、单元测试。
程序质量的要求包括:① 满足要求的确切功能;② 处理效率高;③ 操作方便,用户界面友好;④ 程序代码的可读性好,函数、变量标识符合规范;⑤ 扩充性、维护性好。
降低程序的复杂性也是十分重要的。
系统的复杂性由模块间的接口数来衡量,一般地讲,n个模块的接口数的最大值为n(n-1)/2;若是层次结构,n个模块的接口数的最小值为n-1。
为使复杂性最小,对模块的划分设计常常采用层次结构。
要注意编制的程序或模块应容易理解、容易修改,模块应相互独立,对某一模块的修改应对其他模块的功能不产生影响,模块间的联系尽可能少。
5.系统测试 测试是为了发现程序中的错误,对于设计的软件,出现错误是难免的。
系统测试通常由经验丰富的设计人员设计测试方案和测试样品,并写出测试过程的详细报告。
系统测试是在单元测试的基础上进行的,包括:① 测试方案的设计;② 进行测试;③ 写出测试报告;④ 用户对测试结果进行评价。
6、文档资料 文档包括开发过程中的所有技术资料以及用户所需的文档,软件系统的文档一般可分为系统文档和用户文档两类。
用户文档主要描述系统功能和使用方法,并不考虑这些功能是怎样实现的;系统文档描述系统设计、实现和测试等方面的内容。
文档是影响软件可维护性、可用性的决定因素,有句话讲,系统编程人员的每一张纸片都要保留,所以文档的编制是软件开发过程中的一项重要工作。
系统文档包括:开发软件系统在计划、需求分析、设计、编制、调试、运行等阶段的有关文档。
在对软件系统进行修改时,系统文档应同步更新,并注明修改者和修改日期,如有必要应注明修改原因,应切记过时的文档是无用的文档。
用户文档包括:① 系统功能描述;② 安装文档,说明系统安装步骤以及系统的硬件配置方法;③ 用户使用手册,说明使用软件系统方法和要求,疑难问题解答;④ 参考手册,描述可以使用的所有系统设施,解释系统出错信息的含义及解决途径。
7、系统的运行与维护 系统只有投入运行后,才能进一步对系统检验,发现潜在的问题,为了适应环境的变化和用户要求的改变,可能会对系统的功能、使用界面进行修改。
要对每次发现的问题和修改内容建立系统维护文档,并使系统文档资料同步更新。
软件复杂度的复杂度的种类
有模块、类和程序三类复杂度。
模块复杂度包含了关于模块的复杂度信息;类复杂度是针对那些使用McCabe面向对象特性的程序,它包含了关于类的复杂度信息;程序复杂度包含了关于程序的复杂度信息。
集成复杂度报告 对应于三种复杂度的是三种复杂度报告。
如果一个报告的复杂度信息不只一种,那么就把这些复杂度信息组合成新的报告。
集成复杂度信息只收集一个部件及其下级的信息。
例如:如果一个程序级报告包含一个类复杂度,那么只报告组成程序的类的信息,而不包含类组成的信息。
McCabe复杂度是对软件结构进行严格的算术分析得来的,实质上是对程序拓扑结构复杂性的度量,明确指出了任务复杂部分。
McCabe复杂度包括:圈复杂度、基本复杂度、模块设计复杂度、设计复杂度、集成复杂度、行数、规范化复杂度、全局数据复杂度、局部数据复杂度、病态数据复杂度。
McCabe复杂度的用途 在软件工程中,有三种使用McCabe复杂性度量的方式。
作为测试的辅助工具。
McCabe复杂性度量的结果等于通过一个子程序的路径数,因而需要设计同样多的测试案例以覆盖所有的路径。
如果测试案例数小于复杂性数,则有三种情况一是需要更多的测试;二是某些判断点可以去掉;三是某些判断点可用插入式代码替换。
作为程序设计和管理指南。
在软件开发中,需要一种简单的方式指出可能出问题的子程序。
保持子程序简单的通用方法是设置一个长度限制,例如50行或2页,但这实际上是在缺乏测试简明性的有效方法时无可奈何的替代方法。
不少人认为McCabe度量就是这样一种简明性度量。
但是要注意,McCabe度量数大的程序,不见得结构化就不好。
例如,Case语句是良结构的,但可能有很大的McCabe度量数(依赖于语句中的分支数),这可能是由于问题和解决方案所固有的复杂性所决定的。
使用者应当自己决定如何使用McCabe度量所提供的信息。
作为网络复杂性度量的一种方法。
Hall和Preiser提出了一种组合网络复杂性度量,用于度量可能由多个程序员组按模块化原理建立的大型软件系统的复杂性。
他们提出的组合度量公式为 式中 C1,...,Ck是各个模块的复杂性;CN是网络复杂性;W1和W2为权值。
McCabe复杂度即可用于度量各个模块的复杂性,也可用于度量网络复杂性。
圈复杂度是用来衡量一个模块判定结构的复杂程度,数量上表现为独立路径的条数,即合理的预防错误所需测试的最少路径条数,圈复杂度大说明程序代码可能质量低且难于测试和维护,经验表明,程序的可能错误和高的圈复杂度有着很大关系。
独立路径组成的集合称为基本路径集合,独立路径数就是指基本路径集合中路径的数量。
基本路径集合不是唯一的,独立路径数也就不唯一。
因此,圈复杂度是最大独立路径数。
计算方法 节点是程序中代码的最小单元,边代表节点间的程序流。
如果一个模块流程图有e条边n个节点,它的圈复杂度V(G)=e-n+2,典型的V(G)max=10。
图1中示例的圈复杂度是2。
优点 避免软件中的错误倾向;指出极复杂模块,这样的模块也许可以进一步细化;度量测试计划,确定测试重点;在开发过程中通过限制程序逻辑,指导测试过程;指出将要测试的区域;帮助测试人员确定测试和维护对象;与所用的高级程序设计语言类型无关。
应用 圈复杂度指出为了确保软件质量应该检测的最少基本路径的数目。
在实际中,测试每一条路经是不现实的,测试难度随着路径的增加而增加。
但测试基本路径对衡量代码复杂度的合理性是很必要的。
McCabe & Associates建议圈复杂度到10,因为高的圈复杂度使测试变得更加复杂而且增大了软件错误产生的概率。
提示:圈复杂度度量是测量在一个软件模块中的分支数目,在所有的开发周期中都要使用。
圈复杂度度量以软件的结构流程图为基础。
控制流程图描述了软件模块的逻辑结构。
一个模块在典型的语言中是一个函数或子程序,有一个入口和一个出口,也可以通过调用/返回机制设计模块。
软件模块的每个执行路径,都有与从模块的控制流程图中的入口到出口的节点相符合的路径。
“Cyclomatic”来源于非直接连接基本测试周期的数目,更重要的是,也通过直接相连的图表给出独立路径的数目。
通过图表的相关性,一个节点可到达另一个节点。
圈复杂度度量也可作为模块基本流程图路径的数目,其重点在于模块线形组合后,所产生的路径数目是最小的。
对圈复杂度的限制 现在有许多好方法可以用来限制圈复杂度。
过于复杂的模块容易出错,难于理解、测试、更正,所以应当在软件开发的各个阶段有意识地限制复杂度,许多开发者已经成功地实现把对软件复杂度的限制作为软件项目的一部分,尽管在确切的数目上略微有些争议。
最初支持的数目是10,现在支持数目可达15。
但是,只应当在条件较好的情况下使数目大于10,例如开发者非常有经验,设计合乎正式标准,使用现代化的程序语言、结构程序、代码预排和先进的测试计划。
换句话说,开发团队可以选择超过10的限制数目,但是必须根据经验进行一些取舍,把精力花在比较复杂的模块上。
基本复杂度是用来衡量程序非结构化程度的,非结构成分降低了程序...
应用软件是怎样设计的?
软件系统的开发是按阶段进行的,一般划分为以下阶段:可行性讨论;需求分析;系统设计(概要设计、详细设计);程序开发;编码,单元测试;系统测试;系统维护。
软件开发过程中要明确各阶段的工作目标、实现该目标所必需的工作内容以及达到的标准。
只有在上一个阶段的工作完成后,才能开始下一阶段的工作。
1.可行性讨论 明确系统的目的、功能和要求,了解目前所具备的开发环境和条件,论证的内容有:① 在技术能力上是否可以支持;② 在经济上效益如何;③ 在法律上是否符合要求;④ 与部门、企业的经营和发展是否吻合;⑤ 系统投入运行后的维护有无保障。
可行性讨论的目的是判定软件系统的开发有无价值。
分析和讨论的内容形成“系统开发计划书”,主要内容有: (1) 开发的目的及所期待的效果; (2) 系统的基本设想,涉及的业务对象和范围; (3) 开发进度表,开发组织结构; (4) 开发、运行的费用; (5) 预期的系统效益; (6) 开发过程中可能遇到的问题及注意事项。
2、系统需求分析 系统需求分析是软件系统开发中最重要的一个阶段,直接决定着系统的开发质量和成败,必须明确用户的要求和应用现场环境的特点,了解系统应具有哪些功能、数据的流程和数据之间的联系。
需求分析应有用户参加,到使用现场进行调研学习,软件设计人员应虚心向技术人员和使用人员请教,共同讨论解决需求问题的方法,对调查结果进行分析,明确问题的所在。
需求分析的内容编写成“系统需求分析报告”。
3.系统设计 可根据系统的规模分成概要设计和详细设计两个阶段。
概要设计包括:① 划分系统模块;② 每个模块的功能确定;③ 用户使用界面概要设计;④ 输入输出数据的概要设计;⑤ 报表概要设计;⑥ 数据之间的联系、流程分析;⑦ 文件和数据库表的逻辑设计;⑧ 硬件、软件开发平台的确定;⑨ 有规律数据的规范化及数据惟一性要求。
系统的详细设计是对系统的概要设计进一步具体化,其主要工作有:① 文件和数据库的物理设计;② 输入输出记录的方案设计;③ 对各子系统的处理方式和处理内容进行细化设计;④ 编制程序设计任务书。
程序说明书通常包括程序规范、功能说明、程序结构图,通常用HPIPO(Hierarchy Plus Input Process Output)图描述。
4、程序开发 根据程序设计任务书的要求,用计算机算法语言实现解题的步骤,主要工作包括:① 模块的理解和进一步划分;② 以模块为单位的逻辑设计,也就是模块内的流程图的编制;③ 编写代码,用程序设计语言编制程序;④ 进行模块内功能的测试、单元测试。
程序质量的要求包括:① 满足要求的确切功能;② 处理效率高;③ 操作方便,用户界面友好;④ 程序代码的可读性好,函数、变量标识符合规范;⑤ 扩充性、维护性好。
降低程序的复杂性也是十分重要的。
系统的复杂性由模块间的接口数来衡量,一般地讲,n个模块的接口数的最大值为n(n-1)/2;若是层次结构,n个模块的接口数的最小值为n-1。
为使复杂性最小,对模块的划分设计常常采用层次结构。
要注意编制的程序或模块应容易理解、容易修改,模块应相互独立,对某一模块的修改应对其他模块的功能不产生影响,模块间的联系尽可能少。
5.系统测试 测试是为了发现程序中的错误,对于设计的软件,出现错误是难免的。
系统测试通常由经验丰富的设计人员设计测试方案和测试样品,并写出测试过程的详细报告。
系统测试是在单元测试的基础上进行的,包括:① 测试方案的设计;② 进行测试;③ 写出测试报告;④ 用户对测试结果进行评价。
6、文档资料 文档包括开发过程中的所有技术资料以及用户所需的文档,软件系统的文档一般可分为系统文档和用户文档两类。
用户文档主要描述系统功能和使用方法,并不考虑这些功能是怎样实现的;系统文档描述系统设计、实现和测试等方面的内容。
文档是影响软件可维护性、可用性的决定因素,有句话讲,系统编程人员的每一张纸片都要保留,所以文档的编制是软件开发过程中的一项重要工作。
系统文档包括:开发软件系统在计划、需求分析、设计、编制、调试、运行等阶段的有关文档。
在对软件系统进行修改时,系统文档应同步更新,并注明修改者和修改日期,如有必要应注明修改原因,应切记过时的文档是无用的文档。
用户文档包括:① 系统功能描述;② 安装文档,说明系统安装步骤以及系统的硬件配置方法;③ 用户使用手册,说明使用软件系统方法和要求,疑难问题解答;④ 参考手册,描述可以使用的所有系统设施,解释系统出错信息的含义及解决途径。
7、系统的运行与维护 系统只有投入运行后,才能进一步对系统检验,发现潜在的问题,为了适应环境的变化和用户要求的改变,可能会对系统的功能、使用界面进行修改。
要对每次发现的问题和修改内容建立系统维护文档,并使系统文档资料同步更新。
【在软件开发的V模型中,应该在()阶段制定单元测试计划.A、需求...
应该选C .V模型中单元测试是和详细设计相对应的,所以单元测试的计划应该在详细设计阶段指定.其他选项的分析:需求分析,概要设计的时候你还不知道代码长什么样,所以没办法设计单元测试.代码编写时再设计单元测试就太晚了.应该用你的单元测试计划来帮助你编码.
什么是数字图形与图像中能被单独处理的最小基本单元
单元测试的对象是软件设计的最小单位——模块。
单元测试的依据是详细设描述,单元测试应对模块内所有重要的控制路径设计测试用例,以便发现模块内部的错误。
单元测试多采用白盒测试技术,系统内多个模块可以并行地进行测试。
单元测试任务 单元测试任务包括:1 模块接口测试;2 模块局部数据结构测试;3 模块边界条件测试;4 模块中所有独立执行通路测试;5 模块的各条错误处理通路测试。
模块接口测试是单元测试的基础。
只有在数据能正确流入、流出模块的前提下,其他测试才有意义。
测试接口正确与否应该考虑下列因素: 1 输入的实际参数与形式参数的个数是否相同; 2 输入的实际参数与形式参数的属性是否匹配; 3 输入的实际参数与形式参数的量纲是否一致; 4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同; 5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配; 6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致; 7 调用预定义函数时所用参数的个数、属性和次序是否正确; 8 是否存在与当前入口点无关的参数引用; 9 是否修改了只读型参数; 10 对全程变量的定义各模块是否一致; 11是否把某些约束作为参数传递。
如果模块内包括外部输入输出,还应该考虑下列因素: 1 文件属性是否正确; 2 OPEN/CLOSE语句是否正确; 3 格式说明与输入输出语句是否匹配; 4缓冲区大小与记录长度是否匹配; 5文件使用前是否已经打开; 6是否处理了文件尾; 7是否处理了输入/输出错误; 8输出信息中是否有文字性错误; 检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。
局部数据结构往往是错误的根源,应仔细设计测试用例,力求发现下面几类错误: 1 不合适或不相容的类型说明; 2变量无初值; 3变量初始化或省缺值有错; 4不正确的变量名(拼错或不正确地截断); 5出现上溢、下溢和地址异常。
除了局部数据结构外,如果可能,单元测试时还应该查清全局数据(例如FORTRAN的公用区)对模块的影响。
在模块中应对每一条独立执行路径进行测试,单元测试的基本任务是保证模块中每条语句至少执行一次。
此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。
此时基本路径测试和循环测试是最常用且最有效的测试技术。
计算中常见的错误包括: 1 误解或用错了算符优先级; 2混合类型运算; 3变量初值错; 4精度不够; 5表达式符号错。
比较判断与控制流常常紧密相关,测试用例还应致力于发现下列错误: 1不同数据类型的对象之间进行比较; 2错误地使用逻辑运算符或优先级; 3因计算机表示的局限性,期望理论上相等而实际上不相等的两个量相等; 4比较运算或变量出错; 5循环终止条件或不可能出现; 6迭代发散时不能退出; 7错误地修改了循环变量。
一个好的设计应能预见各种出错条件,并预设各种出错处理通路,出错处理通路同样需要认真测试,测试应着重检查下列问题: 1输出的出错信息难以理解; 2记录的错误与实际遇到的错误不相符; 3在程序自定义的出错处理段运行之前,系统已介入; 4异常处理不当; 5错误陈述中未能提供足够的定位出错信息。
边界条件测试是单元测试中最后,也是最重要的一项任务。
众的周知,软件经常在边界上失效,采用边界值分析技术,针对边界值及其左、右设计测试用例,很有可能发现新的错误。
单元测试过程 一般认为单元测试应紧接在编码之后,当源程序编制完成并通过复审和编译检查,便可开始单元测试。
测试用例的设计应与复审工作相结合,根据设计信息选取测试数据,将增大发现上述各类错误的可能性。
在确定测试用例的同时,应给出期望结果。
应为测试模块开发一个驱动模块(driver)和(或)若干个桩模块(stub),下图显示了一般单元测试的环境。
驱动模块在大多数场合称为“主程序”,它接收测试数据并将这些数据传递到被测试模块,被测试模块被调用后,“主程序”打印“进入-退出”消息。
驱动模块和桩模块是测试使用的软件,而不是软件产品的组成部分,但它需要一定的开发费用。
若驱动和桩模块比较简单,实际开销相对低些。
遗憾的是,仅用简单的驱动模块和桩模块不能完成某些模块的测试任务,这些模块的单元测试只能采用下面讨论的综合测试方法。
提高模块的内聚度可简化单元测试,如果每个模块只能完成一个,所需测试用例数目将显著减少,模块中的错误也更容易发现。
展开
如何提高软件的质量?
一、什么是质量? 作为软件产品的销售人员,市场人员或维护人员经常会受到客户这样那样的指责或抱怨,客户说:你们产品的质量太差,不稳定等等。
那么什么是质量呢?我们该如何来衡量质量呢? 质量具有三个维度: ?? 符合目标。
目标是客户所定义的,符合目标即判断我们是不是在做需要做的事情。
?? 符合需求。
即产品是不是在做让它做的事情。
?? 符合实际需求。
实际的需求包括用户明确说明的和隐含的需求。
ISO 关于质量的定义表示如下: “ 一个实体(产品或服务)的所有特性,基于这些特性可以满足明显的或隐含的需要。
” 注意,在这个定义中包含明显的需求和隐含的需求。
而往往我们会忽略隐含的需求。
因此在控制一个产品的质量的过程中必须关注这些隐含的需求,并给予应有的验证。
另一方面因为我们的产品是为客户提供服务的,因此凡是不满足客户需求的,我们都认为是一个失效( failure )。
所以我们的产品必须始终围绕着客户的需求进行开发和验证。
这里我们谈到客户,其实在一个软件的需求收集过程中需要关注客户和用户。
而我们经常会忽略客户与用户之间的区别。
那么谁是客户?谁是用户呢?简单的来说,客户是真正能够决定是否购买你软件的人,而用户是实际使用软件的人。
了解了这个区别,对于你在分析需求的重要性的时候就可以进行参考。
同时在产品质量验证的时候也可以做出不同的权衡。
另一方面我们在考虑我们用户需求的时候,往往只考虑了实际使用软件的人员,而忽略了其它一些人员对软件的要求或对软件造成的潜在竞争,这包括维护人员的要求、系统管理人员的要求、软件上下游人员的要求、先前版本的情况、市场上竞争对手的软件情况等。
每个人提到质量的时候,经常会遇到下列矛盾,在这些矛盾中隐含着对质量的承诺【 5 】: ?? 质量需要一个承诺,尤其是高层管理者的承诺。
但为了得到质量,高层管理者必须和其雇用的员工进行紧密合作; ?? 许多人相信没有缺陷的产品和服务是不可能的。
但是控制在一定级别的缺陷数是正常并可接受的; ?? 质量经常是和成本紧密联系在一起,一个高质量的产品同时也意味着高投入。
这是设计的质量和一致性质量的一个矛盾; ?? 一个高的质量要求需求规格说明书足够详细,以便产品可以根据这些规格说明书进行定量的分析。
然而许多组织没有能力或者不愿意产生如此详细程度的规格说明书; ?? 技术人员经常相信规范和标准会束缚他们的创造力,因此就不遵照标准做事。
然而如果要得到高质量的产品,就必须遵循良好定义的标准和过程。
二、流程对质量的贡献 好了,既然已经了解了什么是质量,那么怎么才能改进软件产品的质量呢?从一个企业的长远发展来看,首先应当从流程抓起,规范软件产品的开发过程。
这是一个软件企业从小作坊的生产方式向集成化、规范化的大公司迈进的必经之路,也是从根本上解决质量问题,提高工作效率的一个关键手段。
软件产品的开发同其它产品(如汽车)的生产有着共同特性,即需要按一定的过程来进行生产。
在工业界,流水线生产方式被证明是一种高效且能够比较稳定地保证产品质量的一种方式。
通过这种方式,不同的人员被安排在流程的不同位置,最终为着一个目标共同努力,这样可以防止人员工作间的内耗,极大的提高工作效率。
并且由于其过程来源于成功的实例,因此其最终的产品质量能够满足过程所设定的范围要求。
软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中,这就形成了软件工程过程,简单的说就是开发流程。
无论做什么事情,都有一个循序渐进的过程,从计划到策略再到实现。
软件流程就是按照这种思维来定义开发过程,它根据不同的产品特点和以往的成功经验,定义了从需求到最终产品交付的一整套流程。
流程告诉我们该怎么一步一步去实现产品,可能会有那些风险,如何去避免风险等等。
由于流程来源于成功的经验,因此,按照流程进行开发可以使得我们少走弯路,并有效的提高产品质量,提高用户的满意度。
目前流行的流程方法有很多种,不同的过程模型适合于不同类型的项目。
瀑布模型是应用的最为广泛的一种模型,也是最容易理解和掌握的模型,然而它的缺陷也是显而易见的。
遗漏的需求或者不断变更的需求会使得该模型无所适从。
然而,对于那些容易理解但很复杂的项目,采用瀑布模型会是比较适合的,因为你可以按部就班的去处理复杂的问题。
在质量要求高于成本和进度要求的时候,该模型表现的尤其突出。
螺旋模型是也是一个经典模型,它关注于发现和降低项目的风险【 8 】。
螺旋型项目从小的规模开始,然后探测风险,制定风险控制计划,接着确定下一步项目是否还要继续,然后进行下一个螺旋的反复。
该模型的最大优点就是随着成本的增加,风险程度随之降低。
然而螺旋模型的缺点是比较复杂,且需要管理人员有责任心,专注以及有管理方面经验。
RUP ( Rational Unified Process )是 Rational 公司提出的一套开发过程模型,它是一个面向对象软件工程的通用业务流程【 9 】。
它描述了一系列相关的软件工程流程,它们具有相同的结构,...