软件开发流程和关键质量控制点(软件开发流程和关键质量控制点的区别)
软件开发(系统开发)的质量管理与硬件的开发管理完全不同。
原因在于,不可能像硬件产品那样,在客户手中检查已完成软件的质量。 软件的质量只能通过观察软件在计算机中的运行情况或通过编程语言编写的源代码来检查。
本文介绍了软件开发的基础知识以及各开发阶段的品质管理控制要点。
1.1软件开发的种类和方法
软件开发主要有两种方法。
一种是瀑布式(Waterfall)开发手法。 另一种是敏捷型(Agile)。
具体的开发方法进一步区分说明。
1)Waterfall型开发手法
- 需求定义:是指在开始软件开发等项目之前,以易于理解的方式将必要的功能和需求整合在一起的过程。
- 设计:在确定软件必要的功能和要求后,确定软件的行为和详细功能,并将其写入文档。
- 实施:为了实现设计所定下的软件动作或功能,实际上进行的编程动作。 在这个过程中,程序员使用编程语言编写源代码。
- 测试:这是检查所开发的程序是否能顺利运行,是否存在缺陷(Bug)的过程。 如果发现缺陷,则予以纠正。
- 发行:这是将开发好的软件提供给客户的过程。 在这一阶段,客户可以自己操作软件。
所谓瀑布型,是因为开发是“瀑布的水从上到下依次前进”而得名。在软件开发之初,将客户的要求规格汇总,然后按照设计、实施的顺序进行。最后实施各种确认测试并发布软件。(参照图1)
这种方法是软件的主流开发方法,从大型项目开发到小规模系统,在很多情况下都被使用。
询问客户的要求和规格,将其整理成软件系统,整理成一份文件(“要求定义书”)。
《瀑布式的特点》
瀑布型有以下优缺点:
- 基于 "需求定义文件"(有时也称为 "系统设计文件"),可以开发设计文档("基本设计文件"或 "详细设计文件"),以确定软件的行为和功能。
- 在设计文档的基础上,可以创建程序并进行运行测试。
- 由于软件规格在一开始就已确定,因此质量、交付和成本更易于管理。
- 但缺点是,如果在这一过程中对规格进行修改,工时("工时 x 天")将大幅增加,因为这涉及到大量的设计和程序修改。
在实践中的一个具体例子是,这种方法通常用于保证可靠性的大型系统和开发(如银行系统、运输系统等)。
(2) 敏捷型(Agile)开发方法。
敏捷(英语:Agile)是一种开发方法,意为 "快速 "或 "积极"。
敏捷开发是一种在短时间内多次重复开发周期(设计→实施→测试),最终完成软件的方法。
当软件开发开始时,客户的规格要求只是部分功能时,这种方法尤其适用。 (见图 2)。
敏捷开发的核心特质:
1. **迭代开发**:每个软件功能都可在多个短暂的开发循环中逐步完善。
2. **灵活性**:允许根据客户反馈和市场动态调整规格,确保产品与时俱进。
3. **紧密协作**:开发者与客户间的频繁交流,确保需求的准确理解和实时更新。
然而,这也带来了一些挑战:
– **进度不确定性**:频繁的变更可能会影响开发时间表。
– **文档不足**:过于依赖口头沟通可能导致详细的设计文档缺乏,对质量控制和工时管理构成考验。
敏捷方法在面对需求快速变动的行业领域展现出显著优势。比如,日本航空(JAL)的预订和票务系统开发便成功运用了敏捷实践,充分展示了其适应变化的能力。
2.2 软件开发流程
软件开发一般遵循图 3 所示的流程(开发过程)。
定义需求和设计具体化系统概念和整体形象的过程被称为 "上游过程",而编码(实施)和测试过程通常被称为 "下游过程"。
评审记录是对软件开发过程中创建的文档和源代码的评审(评价和改进建议)记录。 具体来说,它描述了评审过程中的讨论内容、指出的问题和提出的改进建议。 在各种设计和测试中出现错误时,会记录进度状态和参与成员(如会议时间),并将其用作审查文件。
(1) 需求定义和设计
本节介绍确定软件开发设计规范的上游过程,包括如何进行和所需的管理要点。
软件设计一般分为以下三个主要步骤:
- 需求定义
- 基本设计
- 详细设计(*有些人认为详细设计是 "下游流程 "的一部分)
(i) 需求定义
需求定义是明确待开发软件的需求(功能、规格、性能、质量、交付、成本、开发时 间等)的过程。 如果这些要求没有得到明确定义,日后可能会出现 "额外规格 "或 "相互矛盾的功能",这将大大增加交付时间和成本。
因此,有必要在与客户和其他相关方充分讨论后,完成一份 "需求定义文件"。
(2) 设计过程(基本设计、详细设计)
在基本设计中,根据 "需求定义 "编写 "基本设计文件",详细概述系统的结构和规格。 这份 "基本设计文件 "可能包括所有系统功能、数据库配置(表定义和 ER 图)、屏幕和表单布局以及测试计划。
在详细设计中,设计必要的组件(小程序单元)处理、批处理等。 它还包括屏幕和表单周围的细节设计、系统处理的数据文件的规格设计、详细的数据库设计(物理设计)等,以及 "详细设计文件 "的编写。
在这些设计过程中,对每份设计文件进行审查(评估并指出改进之处)非常重要。
此外,还要检查上层设计文件的内容是否转移到下层设计文件中,各设计文件之间是否存在遗漏或矛盾。
(2) 编码(实施)
编码是根据上述详细设计文件编写程序的过程。
根据结构,确定必要的变量、函数和控制语句(如 if)。 此外,还要根据与数据库的联系,选择使用函数和处理变量的方式。
在代码审查中,代码是否编写得清晰易读? 代码是否易于测试? 是否存在任何安全问题? 是否存在安全问题?
(3) 测试流程
V 型模型的流程如图 4 所示,是测试过程的一个缩影。
软件开发测试与验证
这个 "V "形模型展示了软件开发从 "需求定义 "到 "系统测试 "的步骤顺序。
V 型的左侧按降序描述了从 "需求定义 "流程开始的上游流程;V 型的右侧按升序描述了测试流程;通过比较 V 型的左右部分,可以了解每个测试流程要验证哪个设计流程,以及测试的重点是什么。
在每个测试流程中,要检查的测试项目是通过分析每个设计流程的要求和设计细节来设计的。 这就是 "测试设计"。
(i) 单元测试
单元测试是检查由软件源代码最小单元组成的每个程序(模块)是否按详细设计运行的测试。
具体来说,需要确认使用的数据、使用程序和操作方法。 通过这种测试,可及早发现和纠正程序中的错误(故障)。它确定是否存在任何问题,
(ii) 组合测试
组合测试是检查开发的软件是否按基本设计运行的测试。 它将已完成单元测试的所有模块结合起来,检查所需功能是否正常工作。
具体来说,主要目的是检查在与生产环境相同的使用环境中,组合模块的功能是否存在缺陷。 通过这种测试,可以将模块连接在一起,并发现和修复模块内部的错误。
(iii) 系统测试(又称 "全面测试)
系统测试是软件开发过程的最后一步,确认软件整体的行为和功能符合需求定义中的规格。 有时也称为 "全面测试"。
系统测试在单元测试和耦合测试之后进行。
具体来说,系统测试是假定由客户操作的测试,是在向客户发布软件前进行的最后检查。
(iv) 各测试过程的质量控制。
测试过程中的质量控制是解决每次测试中出现的问题(如错误)并防止其再次发生的活动。
应提出以下问题:每次测试过程中发现的错误是否超出事先预测的目标值? 我们还要分析趋势,如其他模块出现类似错误的情况。
此外,上述错误的原因和遗漏错误的原因都要追溯到设计过程以及更高层次的检查和编码过程。
3. 提高文档质量和 bug 收敛是关键点
以下三点在软件开发质量控制中尤为重要。
(1)在每次设计评审中,拥有优秀的评审人员和充足的评审时间对防止出现 Bug 非常重要。
2)在代码审查过程中,除了对每段代码本身进行审查外,还需要对代码进行验证,以防止出现安全漏洞。
(3)测试过程的目的是避免发布后出现问题。 因此,不仅要关注每次测试中是否存在错误及其补救措施,还要关注潜在错误的检测。
在软件质量控制中,上游文档的质量和测试过程中的错误关闭状态是重要的控制点。
测试结果为发布后不出现问题提供了保证。