赞
踩
软件开发和维护过程中所遇到的各种问题称为“软件危机”。
软件工程是指应用计算机科学、数学及管理科学等原理,以工程化的原则和方法来解决软件问题的工程,其目的是提高软件生产率、提高软件质量、降低软件成本。
计算机软件是指计算机系统中的程序及其文档。
程序是计算任务的处理对象和处理规则的描述。
文档是为了便于了解程序所需的阐述性资料。
分类 | 说明 |
---|---|
系统软件 | 系统软件是一整套服务于其他程序的程序。特点:和计算机硬件大量交互;多用户大量使用;需要调度、资源共享和复杂进程管理的同步操作;复杂的数据结构以及多种外部接口 |
应用软件 | 应用软件是解决特定业务需要的独立应用程序。 |
工程/科学软件 | 这类软件通常带有“数值计算”算法的特征 |
嵌入式软件 | 嵌入式软件存在于某个产品或系统中,可实现和控制面向最终使用者和系统本身的特性和功能(刹车系统) |
产品线软件 | 产品为多个不同用户的使用提供特定功能。 |
Web应用 | Web 应用 (WebApp) 是一类以网络为中心的软件,其概念涵盖了宽泛的应用程序产品。 |
人工智能软件 | 人工智能软件利用非数值算法解决计算和直接分析无法解决的复杂问题(机器人) |
开放计算 | |
网络资源 | |
开源软件 | 开源软件就是开放系统应用程序的代码,使得很多人能够为软件开发做贡献 |
这条基本原理意味着应该把软件生命周期划分成若干个阶段,并相应地制订出切实可行的计划,然后严格按照计划对软件的开发与维护工作进行管理。
六类计划:
软件开发中所遵循的路线图称为“软件过程”。
研究目的是提供一种评价软件承接方能力的方法,同时它可以帮助软件组织改进其软件过程。
CMM是对软件组织进化阶段的描述。
级别 | 说明 |
---|---|
初始级(Initial) | 软件过程的特点是杂乱无章,有时甚至很混乱,几乎没有明确定义的步骤 |
可重复级(Repeatable) | 建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性,有必要的过程准则来重复以前在同类项目中的成功。 |
已定义级(Defined) | 管理和工程两方面的软件过程已经文档化、标准化,并综合成整个软件开发组织的标准软件过程 |
已管理级(Managed) | 制定了软件过程和产品质量的详细度量标准 |
优化级(Optimized) | 加强了定量分析,通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。 |
CMMI 是若干过程模型的综合和改进,能适应现代工程的特点和需要,能提高过程的质量和工作效率。
CMMI 提供了两种表示方法:阶段式模型和连续式模型
阶段式模型的结构类似于 CMM,它关注组织的成熟度。
连续式模型关注每个过程域的能力,一个组织对不同的过程域可以达到不同的过程域能力等级 (Capability Level,CL)。CMMI 中包括 6个过程域能力等级,等级号为 0~5。
也叫软件开发模型。
典型的模型有瀑布模型、增量模型、演化模型(原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式化方法模型等。
瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型,包括需求分析、设计、编码、测试、运行与维护。它规定了由前至后、相互衔接的固定次序,如同瀑布流水逐级下落。
瀑布模型是以文档作为驱动、适合于软件需求很明确的软件项目的模型。
优点:容易理解,管理成本低;强调开发的阶段性早期计划及需求调查和产品测试。
缺点:客户必须能够完整、正确和清晰地表达他们的需要: 在开始的两个或 3个阶段中,很难评估真正的进度状态;当接近项目结束时,出现了大量的集成和测试工作;直到项目结束之前,都不能演示系统的能力。
瀑布模型的一个变体是 V模型
增量模型融合了瀑布模型的基本成分和原型实现的迭代特征
演化模型特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型等。
原型模型开始于沟通,其目的是定义软件的总体目标,标识需求,然后快速制订原型开发的计划,确定原型的目标和范围,采用快速射击的方式对其进行建模,并构建原型。被开发的原型应交付给客户使用,并收集客户的反馈意见,这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进,或者需要扩展其范围的时候,进入下轮原型的迭代开发。
分为探索型原型、实验型原型和演化型原型
螺旋模型将瀑布模型和演化模型结合起来,加入了两种模型均忽略的风险分析,弥补了这两种模型的不足。
喷泉模型是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。
基于构件的开发是指利用预先包装的构件来构造应用系统。
包括领域工程和应用系统工程两部分。
领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。
应用系统工程的目的是使用可复用构件组装应用系统。
形式化方法是建立在严格数学基础上的一种软件开发方法,其主要活动是生成计算机软件形式化的数学规格说明。
统一过程模型是一种“用例和风险驱动,以架构为中心,迭代并且增量”的开发过程,由UML 方法和工具支持。
统一过程定义了 4 个技术阶段及其制品。
敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意
敏捷过程的典型方法有很多,每一种方法基于一套原则,这些原则实现了敏捷方法所宣称的理念(敏捷宣言)。
由价值观、原则、实践和行为4个部分组成,通过行为贯穿于整个生存周期。
敏捷统一过程 (Agile Unified Process,AUP)采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。
软件需求指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
包括
需求工程是一个不断反复的需求定义、文档记录、需求演进的过程,并最终在验证的基础上冻结需求。
需求工程可以细分为:
“怎么做”
主要目的:就是为系统制定蓝图,在各种技术和实施方法中权衡利弊,精心设计,合理地使用各种资源,最终勾画出新系统的详细设计方案。
主要内容:包括新系统总体结构设计、代码设计、输出设计、输入设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。
常用的设计方法有以下两种:面向数据流的结构化设计方法 (SD)、 面向对象的分析方法(OOD)
系统设计的基本任务大体上可以分为概要设计和详细设计两个步骤
系统测试是为了发现错误而执行程序的过程,成功的测试是发现了至今尚未发现的错误的测试。
测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。
信息系统测试应包括软件测试、硬件测试和网络测试。
有效的软件测试实际上分为 4 步进行,即单元测试、集成测试、确认测试和系统测试。
也叫模块测试。单元测试侧重于模块中的内部处理逻辑和数据结构。
由于模块不是独立运行的程序,各模块之间存在调用与被调用的关系。在对每个模块进行测试时,需要开发两种模块。单元测试环境如图 5-9 所示。
集成测试就是把模块按系统设计说明书的要求组合起来进行测试。
集成测试有两种方法:一种是非增量集成,一种是增量集成。
自顶向下集成测试是一种构造软件体系结构的增量方法。
模块的集成顺序为从主控模块(主程序) 开始,沿着控制层次逐步向下,以深度优先或广度优先的方式将从属于 (或间接从属于) 主控模块的模块集成到结构中。
自底向上集成测试就是从原子模块(程序结构的最底层构件) 开始进行构造和测试。由于构件是自底向上集成的,在处理时所需要的从属于给定层次的模块总是存在的,因此,没有必要使用桩模块。
在集成测试策略的环境下,回归测试是重新执行已测试过的某些子集,以确保变更没有传播不期望的副作用。
回归测试要执行的测试子集包含以下3 种测试用例。
冒烟测试是一种常用的集成测试方法。
确认测试始于集成测试的结束,那时已测试完单个构件,软件已组装成完整的软件包,且接口错误已被发现和改正。
软件确认是通过一系列表明与软件需求相符合的测试而获得的。
确认过程的一个重要成分是配置评审,主要是检查软件(源程序、目标程序)、文档 (包括面向开发和用户的文档) 和数据(程序内部的数据或程序外部的数据) 是否齐全以及分类是否有序。确保文档、资料的正确和完善,以便维护阶段使用。
α
\alpha
α测试是由有代表性的最终用户在开发者的场所进行。软件在自然的环境下使用,开发者站在用户的后面观看,并记录错误和使用问题。
α
\alpha
α测试在受控的环境下进行。
β
\beta
β测试在一个或多个最终用户场所执行。与
α
\alpha
α测试不同,开发者通常不在场,因此,
β
\beta
β测试是在不被开发者控制的环境下软件的“现场”应用。最终用户记录测试过程中遇见的所有问题(现实存在的或想象的),并定期地报告给开发者。接到 测试的问题报告之后,开发人员对软件进行修改,然后准备向最终用户发布软件产品。
β \beta β 测试的一种变体称为客户验收测试,有时是按照合同交付给客户时进行的。客户执行一系列的特定测试,试图在从开发者那里接收软件之前发现错误。
系统测试是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起,进行信息系统的各种集成测试和确认测试,其目的是通过与系统的需求相比较,发现所开发的系统与用户需求不符或矛盾的地方。
对于面向对象软件,测试的基本目标仍然是在现实的时间范围内利用可控的工作量找出尽可能多的错误
面向对象软件的类测试是由封装在该类中的操作和类的状态行为驱动的。
由于面向对象软件没有明显的层次控制结构,因此面向对象环境中的集成测试有两种策略
维度 | 说明 |
---|---|
内容 | 在语法及语义层对内容进行评估 |
功能 | 对功能进行测试,以发现与客户需求不一致的错误 |
结构 | 对结构进行评估,以保证它正确地表示 WebApp 的内容及功能,是可拓展的,并支持新内容、新功能的增加 |
可用性 | 对可用性进行测试,以保证接口支持各种类型的用户,各种用户都能够学会及使用所有需要的导航语法及语义 |
导航性 | 对导航性进行测试,以保证检查所有的导航语法及语义,发现任何导航错误 (例如,死链接、不合适的链接、错误链接等) |
性能 | 在各种不同的操作条件、配置及负载下对性能进行测试 |
兼容性 | 在客户端及服务器端,在各种不同的主机配置下通过运行 WebApp 对兼容性进行测试 |
安全性 | 对安全性进行测试,通过评定可能存在的弱点试图对每个弱点进行攻击 |
软件测试方法分为静态测试和动态测试。
静态测试是指被测试程序不在机器上运行,而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。
动态测试是指通过运行程序发现错误。在对软件产品进行动态测试时可以采用黑盒测试法和白盒测试法。
黑盒测试也称为功能测试,在完全不考虑软件的内部结构和特性的情况下,测试软件的外部特性。
白盒测试也称为结构测试,根据程序的内部结构和逻辑来设计测试用例,对程序的路径和过程进行测试,检查是否满足设计的需要。
调试发生在测试之后,其任务是根据测试时所发现的错误找出原因和具体的位置,进行改正。调试工作主要由程序开发人员进行,谁开发的程序就由谁来进行调试。
调试过程通常得到以下两种结果: 发现问题的原因并将其改正、未能找到问题的原因
在进行新旧系统转换以前,首先要进行新系统的试运行
。新系统试运行成功之后,就可以在新系统和旧系统之间互相转换
。
系统的可维护性:维护人员理解、改正、改动和改进这个软件的难易程度。
提高可维护性是开发软件系统所有步骤的关键目的。
文档是软件可维护性的决定因素。
软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法,并不关心这些功能是怎样实现的;系统文档描述系统设计、实现和测试等各方面的内容。
维护应该针对整个软件配置,不应该只修改源程序代码。
系统维护主要包括硬件维护、软件维护和数据维护
硬件维护
软件维护
软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部修改。内容包括:
数据维护
数据维护工作主要是由数据库管理员来负责,主要负责数据库的安全性和完整性以及进行并发性控制。
信息系统的评价分为广义和狭义两种。
广义的信息系统评价是指从系统开发的一开始到结束的每一阶段都需要进行评价。
狭义的信息系统评价则是指在系统建成并投入运行之后所进行的全面、综合的评价。
按评价的时间与信息系统所处的阶段的关系又可从总体上把广义的信息系统评价分成:立
项评价、中期评价(里程碑式评价)和结项评价。
将项目管理思想引入软件工程领域,就形成了软件项目管理。
软件项目管理是指软件生存周期中软件管理者所进行的一系列活动,其目的是在一定的时间和预设范围内有效地利用人力、资源、技术和工具,使软件系统或软件产品按原定计划和质量要求如期完成。
人员(Person)、产品(Product)、过程(Procedure)和项目 (Project)。
人员是软件工程项目的基本要素和关键因素,可以分为以下 5 类。
在进行项目计划之前,应该首先进行项目定义,也就是定义项目范围,其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等。
软件开发者和客户必须一起定义产品的目的和范围。
软件范围是通过回答下列问题来定义的:
软件过程提供了一个项目团队要选择一个适合于待开发软件的过程模型
进行有计划和可控制的软件项目是管理复杂性的一种方式。
常用的估算方法有3种:
COCOMO 模型是一种精确的、易于使用的成本估算模型。COCOMO 模型按其详细程度分
为基本 COCOMO 模型、中级 COCOMO 模型和详细 COCOMO 模型。
E
=
a
(
L
)
b
E = a(L)^b
E=a(L)b
D
=
c
(
E
)
d
D = c(E)^d
D=c(E)d
E表示工作量,D表示开发时间,L是项目的源代码行数估值。a、b、c、d是常数。
E
=
a
(
L
)
b
E
A
F
E = a(L)^bEAF
E=a(L)bEAF
E表示工作量,EAF是调节因子,L是项目的源代码行数估值,单位是千行。a、b是常数。
它将软件系统模型分为系统、子系统和模块 3 个层次,除包括中级模型所考虑的因素外,还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响。
层次结构的估算模型,被分为 3 个阶段性模型
COCOMOⅡ模型也需要使用规模估算信息,体系结构阶段,在模型层次结构中有3种不同规模估算选择,即: 对象点、功能点和代码行。应用组装模型使用的是对象点;早期设计阶段模型使用的是功能点,功能点可以转换为代码行。体系结构模型把工作量表示为代码行数。
L
=
C
k
E
1
/
3
t
d
4
/
3
L=C_kE^{1/3}t_d^{4/3}
L=CkE1/3td4/3
L 表示源程序代码行数 (LOC);
t
d
t_d
td表示开发持续时间(年);
E 是包括软件开发和维护在整个生存期所花费的工作量 (人年);
C
k
C_k
Ck:表示技术状态常数,其值依赖于开发环境
C k 的典型值 C_k的典型值 Ck的典型值 | 开发环境 | 开发环境举例 |
---|---|---|
2000 | 差 | 没有软件开发方法学的支持,缺少文档和评审,采用批处理方式 |
8000 | 一般 | 有软件开发方法学的支持,有适宜的文档和评审,采用交互式处理方式采用 |
11000 | 较好 | CASE 工具和集成化 CASE 环境 |
目的是确保软件项目在规定的时间内按期完成。
指导软件进度安排的基本原则:
为监控软件项目的进度计划和工作的实际进展情况,表示各项任务之间进度的相互依赖关系,需要采用图示的方法。在图中明确标明如下内容。
进度安排的常用图形描述方法有 Gantt 图(甘特图)和项目计划评审技术(Program Evaluation &Review Technique,PERT) 图。
Gantt图是一种简单的水平条形图,它以日历为基准描述项目任务
PERT 图是一个有向图,图中的箭头表示任务,它可以标上完成该任务所需的时间
在软件项目组织中,其组织原则:
根据项目的分解和过程的分解,软件项目可以有以下多种组织形式。
1 、按项目划分的模式
按项目将开发人员组织成项目组,项目组的成员共同完成该项目的所有开发任务,包括项目的定义、需求分析、设计、编码、测试、评审以及所有的文档编制,甚至包括该项目的维护。
2、按职能划分的模式
按软件过程中所反映的各种职能将项目的参与者组织成相应的专业组,如开发组 (可进步分为需求分析组、设计组、编码组)、测试组、质量保证组、维护组等。
3、矩阵模式
这种模式是上述两种模式的组合,它既按职能组织相应的专业组,又按项目组织项目组。每个软件人员既属于某个专业组,又属于某个项目组。每个软件项目指定一个项目经理,项目中的成员根据其所属的专业组的职能承担项目的相应任务。
主要是指从事软件开发活动的小组,有以下 3 种不同的组织形式
软件配置管理 (Software Configure Management,SCM)用于整个软件工程过程。其主要目标是标识变更;控制变更;确保变更正确地实现;报告有关变更。
基线是软件生存周期中各开发阶段的一个特定点,它的作用是使各开发阶段的工作划分更加明确,使本来连续的工作在这些点上断开,以便于检查与肯定阶段成果。
软件配置项(Software Configure Item,SCI)是软件工程中产生的信息项,它是配置管理的基本单位,对于已经成为基线的 SCI,虽然可以修改,但必须按照一个特殊的、正式的过程进行评估,确认每一处修改。以下的 SCI是 SCM的对象,并可形成基线。
在图中各个结点是一个完全的软件版本。软件的每一个版本都是 SCI(源代码、文档、数据)的一个汇集,而且各个版本都可能由不同的变种组成。
软件工程过程中某一阶段的变更均要引起软件配置的变更,这种变更必须严格地加以控制和管理,保持修改信息,并把精确、清晰的信息传递到软件工程过程的下一步骤。
风险是指损失或伤害的可能性。一般认为软件风险包含两个特性:不确定性和损失。
风险 | 说明 |
---|---|
项目风险 | 项目风险威胁到项目计划。项目风险是指预算、进度、人员、资源、利益相关者、需求等方面的潜在问题以及它们对软件项目的影响。项目复杂度、规模及结构不确定性也属于项目风险因素。 |
技术风险 | 技术风险威胁到要开发软件的质量及交付时间。技术风险是指设计、实现、接口、验证和维护等方面的潜在问题。此外,规格说明的歧义性、技术的不确定性、技术陈旧以及“前沿”技术也是技术风险因素。 |
商业风险 | 商业风险威胁到要开发软件的生存能力,且常常会危害到项目或产品。市场风险、策略风险、销售风险、管理风险、预算风险 |
风险识别试图系统化地指出对项目计划(估算、进度、资源分配等) 的威胁。
识别风险的一种方法是建立风险条目检查表。该检查表可用于风险识别,并且主要用来识别下列几种类型中的一些已知风险和可预测风险。
风险预测又称风险估计,它试图从两个方面评估一个风险: 风险发生的可能性或概率;如果风险发生了所产生的后果。
风险显露度(Risk Exposure, RE),
R
E
=
P
∗
C
RE = P*C
RE=P∗C
(
r
i
l
i
x
i
)
(r_il_ix_i)
(rilixi)
其中
r
i
r_i
ri表示风险,
l
i
l_i
li表示风险发生的概率,
x
i
x_i
xi表示风险产生的影响。
一种对风险评估很有用的技术就是定义风险参照水准。成本、进度和性能。
风险控制的目的是辅助项目组建立处理风险的策略。一个有效的策略必须考虑以下 3 个问题:
软件质量:指反映软件系统或软件产品,满足规定或隐含需求的能力的特征和特性全体。
软件质量管理:对软件开发过程进行独立的检查活动,由质量保证、质量规划和质量控制3 个主要活动构成。
利用软件质量模型来描述软件质量特性,例如 ISO/IEC 9126 软件质量模型和 Mc Call 软件质量模型。
ISO/IEC 9126 软件质量模型由 3 个层次组成:第一层是质量特性,第二层是质量子特性:第三层是度量指标。
Mc Call 软件质量模型从软件产品的运行、修正和转移 3 个方面确定了 11 个质量特性。第一层是质量特性,第二层是评价准则,第三层是度量指标
软件质量保证是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划有组织的活动,其目的是生产高质量的软件。在软件质量方面强调以下 3 个要点:
软件质量保证包括了与以下 7 个主要活动相关的各种任务:
通常,把“质量”理解为“用户满意程度”。为了使得用户满意,有以下两个必要条件。
(1) 设计的规格说明书符合用户的要求,这称为设计质量。
(2) 程序按照设计规格说明所规定的情况正确执行,这称为程序质量。
设计质量评审的对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明,以及在软件概要设计阶段产生的软件概要设计说明书等。通常从以下几个方面进行评审。
程序质量评审通常是从开发者的角度进行评审,与开发技术直接相关。它是着眼于软件本身的结构、与运行环境的接口以及变更带来的影响而进行的评审活动。
软件的结构如下:
运行环境包括硬件、其他软件和用户,主要检查项目:
提高软件质量和可靠性的技术大致可分为两类,一类是避开错误;另一类是容错技术。
实现容错的主要手段是冗余。包括结构冗余、信息冗余、时间冗余、冗余附加技术。
分类 | 说明 |
---|---|
结构冗余 | 结构冗余是通常采用的冗余技术,按其工作方法可以分为静态、动态和混合冗余3种 |
信息冗余 | 为检测或纠正信息在运算或传输中的错误需外加一部分信息,这种现象称为信息冗余 |
时间冗余 | 时间冗余是指以重复执行指令或程序来消除瞬时错误带来的影响 |
冗余附加技术 | 为实现上述冗余技术所需的资源和技术,包括程序、指令、数据、存放和调动它们的空间和通道等 |
软件度量用于对产品及开发产品的过程进行度量。
分类 | 定义 | 举例 |
---|---|---|
外部属性 | 指面向管理者和用户的属性,体现了软件产品/软件过程与相关资源和环境的关系 | 如成本、效益、开发人员的生产率 |
内部属性 | 指软件产品或软件过程本身的属性 | 可靠性、可维护性等 |
软件度量有两种分类方法:
第一种分类是将软件度量分为面向规模的度量、面向功能的度量和面向人的度量;
第二种分类是将软件度量分为生产率度量、质量度量和技术度量。
面向规模的度量是通过对质量和生产率的测量进行规范化得到的,而这些量都是根据开发过的软件的规模得到的。
度量 | 表示及含义 |
---|---|
LOC 或 KLOC | 代码行数或千行代码数 |
生产率 P | P= LOC / E,E 为开发的工作量(常用人月数表示) |
每行代码平均成本 C | C=S / LOC,S为总成本 |
文档代码比 D | D= Pe / KLOC,Pe 为文档页数 |
代码错误率 EOR | EOR=N / KLOC,N为代码中的错误数 |
应用最广泛的面向功能的度量是功能点(Function Point,FP)。功能点是根据软件信息域的特性及复杂性来计算的。
信息域的值用下列方式定义。
利用下面的关系式计算功能点:
F
p
=
总计
∗
[
0.65
+
0.01
∗
∑
(
F
i
)
]
Fp= 总计*[0.65 + 0.01 * \sum(F_i)]
Fp=总计∗[0.65+0.01∗∑(Fi)] 其中,“总计”是所有 Fp项的总数。
F
i
(
i
=
1
14
)
F_i(i=1~14)
Fi(i=1 14)是值调整因子
软件复杂性是指理解和处理软件的难易程度。软件复杂性度量的参数主要有:
程序复杂性度量是软件度量的重要组成部分。
又称环路度量
V
(
G
)
=
m
−
n
+
2
V(G) = m-n+2
V(G)=m−n+2
其中V(G)是G中的环路书,m是G中的有向弧数,n是G中的节点数。
计算机辅助软件工程(Computer Aided Software Engineerin, CASE)是指使用计算机及相关的软件工具辅助软件开发、维护、管理等过程中各项活动的实施,以确保这些活动能高效率、高质量地进行。
用来辅助软件开发、运行、维护、管理和支持等过程中的活动的软件称为软件工具。
对应于软件开发过程的各种活动,软件开发工具通常有需求分析工具、设计工具、编码与排错工具、测试工具等。
工具 | 定义 | 分类 |
---|---|---|
需求分析工具 | 用于辅助软件需求分析活动的软件 | 1、基于自然语言或图形描述的工具;2、基于形式化需求定义语言的工具 |
设计工具 | 用于辅助软件设计活动的软件 | 1、概要设计工具;2、详细设计工具;3、基于形式化描述的设计工具; 4、面向对象的分析与设计工具 |
编码和排错工具 | 辅助程序员进行编码活动的工具有编码工具和排错工具 | 1、编码工具;2、排错工具 |
测试工具 | 用于支持软件测试的工具称为测试工具 | 1、数据获取工具;2、静态分析工具;3、动态分析工具;4、模拟工具;5、测试管理工具 |
辅助 软件维护过程中活动 的软件称为软件维护工具。
主要有:
软件管理和软件支持工具用来辅助管理人员和软件支持人员的管理活动和支持活动,以确保软件高质量地完成。
主要有:
软件开发环境:指支持软件产品开发的软件系统,它由软件工具集和环境集成机制构成。
工具集用于支持软件开发的相关过程、活动和任务;环境集成机制为工具集成和软件开发、维护和管理提供统一的支持。
分类 | 说明 |
---|---|
数据集成 | 为各种相互协作的工具提供统一的数据模式和数据接口规范,以实现不同工具之间的数据交换 |
界面集成 | 指环境中的工具的界面使用统一的风格,采用相同的交互方法,提供一种相似的视感效果,这样可以减少用户学习不同工具的开销 |
控制集成 | 用于支持环境中各个工具或开发活动之间的通信、切换、调度和协同工作,并支持软件开发过程的描述、执行与转换 |
平台集成 | 指在不同的硬件和系统软件之上构造用户界面一致的开发平台,并集成到统一的环境中 |
方法与过程集成 | 指把多种开发方法、过程模型及其相关工具集成在一起 |
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。