软件调试和应用软件开发模式

根据软件代码规模,应用软件的开发大致分为三 种模式。

程序员个人开发的小软件

用例图

这种模式和早期的软件开发模式类似。 小软件开发用例图如图所示。

软件调试的特点

发现问题(测试)、定位问题和提出解决问题方 案、修改程序代码、验证全部由程序员负责。

软件调试 可以分为静态调试与动态调试。

1、静态调试。 源程序代码编译时同时对源代码进行静态检查, 编译器提供了源代码各种编程错误和错误所在的位 置。 静态调试就是程序员逐条修改编译器提示的错 误,通过代码编译这一关。

2、动态调试。 动态调试分为查错和纠错。 查错就是对程序进行 功能性能测试,查找各种不符合设计要求的各种问题; 纠错就是根据发现的问题,查找原因,修改程序源代 码。 这里的软件调试工作包括软件测试。 动态调试通 常采用以下两种方式:

  • 仔细分析发现的问题,通过推理来查找发生 问题的原因。 程序员对程序的架构设计、编码实现十 分熟悉,往往能比较快地定位和处理问题。 这种方式 通常具有全局观念,可以避免解决问题过程中诱导出 现其他问题。
  • 通过调试工具采用人机交互方式调试代码。 这种方式是逐条执行和跟踪程序代码,观察各种状态 和变量的变化,检查是否符合程序设计的要求来定位 问题。 这种方式有助于查找程序代码的微观错误,要 求程序员对程序代码的实现十分熟悉。 这两种方式是互补的,综合应用调试程序代码。

3、版本管理。 版本管理通常采用小型软件配置管理工具VSS, 也可采用文件存储的方式

程序组软件开发

这种模式与软件开发中期的开发模式类似。 通常 软件分为多个软件模块,每个程序员仅负责自己开发 的软件模块。 这种开发模式通常用于中、小型软件的 开发。

角色和用例图

软件设计人员:负责软件设计,提供设计规格 文档。

程序开发组:程序代码编写和程序调试,负责软件 的版本管理和集成构建。

测试人员:负责软件功能、性能测试。 程序组开发的软件用例图如图所示

软件调试的特点

1、软件的设计工作和大部分测试工作从程序组 工作中分离出去。 设计人员负责软件设计,程序员负 责程序代码的实现,定位问题和提出解决问题方案往 往由设计人员和程序组共同合作处理,程序员负责软 件纠错(程序代码修改),测试人员负责测试工作。

2、调试分为两个阶段:

(1)、开发组自己测试软件。 程序员完成程序源代码的编写,程序代码的静态 检查,使用调试工具对程序代码进行功能点的调试。 所有的功能点都调试完成后,通过组内代码评审之后, 将源代码合入版本库。 开发组组长指定某个程序员负责程序代码的集成 构建,编译过程中发现的问题,反馈给相关的程序员进 行处理。 源代码完成集成构建之后,打包提交给测试 人员测试。

(2)、测试人员测试软件。 测试人员根据设计规格文档设计测试用例,测试 提交过来的软件包。 测试人员发现的各种问题反馈给 程序开发组进行软件调试处理。 程序开发组和设计人 员确定发生问题的原因,确定修改方案,分配给相关的 程序员进行代码纠错处理。 对于比较复杂的问题,软 件设计人员需要提供实现编码的设计文档。 程序代码修改后,进行验证和确认。

3、版本管理通常采用软件配置管理工具 SVN。 通过版本管理工具对程序员提交的代码进行冲突检 查,通过调试处理保证代码的兼容性和一致性。

项目组开发的软件

软件通常由多个模块组成,每个模块由若干开发 单元组成。 开发单元分配给程序员编写程序代码。 这 种开发模式通常用于大型软件的开发。

角色和用例图

1、软件设计组:提供总体和各模块的设计规格 文档。

2、软件开发组:按模块分为开发小组,开发小组 将开发单元分配给程序员进行程序编码。

3、软件配置管理员:负责基线和版本库的管理。

4、持续集成工程师:负责软件的持续集成工作,搭建的集成构建工程,通过制定定时任务来自动 完成从版本库更新代码、静态检查、编译、出包、冒烟测 试等任务。 冒烟测试也称为预测试,对集成构建成功 的软件包的主要功能进行快速自动化测试。 构建成 功,可以获得最新Build版本,建立新的编码基线。 持 续集成工程师进行全量构建生成内部转测试版本,提 交测试组进行的测试工作。

5、软件测试组:对软件转测试版本进行功能、性 能测试,通过后产生测试(Tested)基线。 为持续集成 工作提供进行冒烟测试的自动化测试用例脚本包,搭 建相应的测试环境。 项目组开发软件(通常为大型软件)用例图如图 所示。

软件调试的特点

1、软件设计人员和软件测试人员增加了,有的软 件项目测试人员比开发人员还要多。 软件测试不仅要 发现程序编码中的问题,而且测试软件设计中的问题。 设计中的问题自然由设计人员处理,程序编码中的问 题由设计人员和开发人员共同处理。

2、软件的版本管理和集成构建工作由专人负责,实行基线和版本库的管理。 基线管理[13-14]为全体开 发人员提供统一的开发基点,统一的程序接口。 通过 控制集成构建的频率,有助于及时发现程序代码问题。

3、软件调试分为三个阶段:

(1)、开发人员调试自己开发软件单元。 程序开发人员每天从版本库检出需要的文件,放 在本地作为工作副本开始工作。 在工作副本上进行查 看、修改、编译、运行、调试等操作。 为了提供高质量的 代码,需要对编写好的代码进行单元测试,静态走码检 查,冲突处理和本地构建工作,处理发现的各种问题。 最后将评审过的代码提交到版本库。 开发人员向版本 库提交时,要添加注释、说明、CR单号、修改原因等,以 保证可追溯。

(2)、处理持续集成工程师发现的问题。 通常持续集成工作包括静态测试、编译、链接和冒 烟测试,每一步发现问题都要反馈给相关开发人员处 理,直到通过集成构建。

(3)、处理测试组发现的问题。 测试组测试转测试版本,将测试结果反馈给相关 人员,对存在的问题逐一定位,查找原因,修改程序,对 每个软件缺陷问题进行跟踪管理,直到问题解决为止。

4、设计人员和程序员共同处理反馈的各种问题, 定位问题和提出解决问题方案。 程序员负责程序代码 修改,测试人员负责验证和确认工作。

5、版本管理可以选择SVN、ClearCase、Git等软件 配置管理工具。 通过版本管理工具进行软件的版本管 理、基线管理和代码冲突检查。

6、软件开发过程中采用持续集成和基线管理技 术,可以更有效地进行开发和调试工作。

原文地址:https://www.cnblogs.com/yilang/p/12092772.html

时间: 2024-10-10 01:28:49

软件调试和应用软件开发模式的相关文章

我所理解的软件开发模式

在写这篇博客之前,提到软件开发我所能讲出来的只有个人开发团队开发之类的,于是我去百度,得知软件开发模式有:边做边改模型,瀑布模型,迭代模型,快速原型模型,增量模型,螺旋模型,敏捷软件开发,演化模型,喷泉模型,智能模型,混合模型等. 好吧,你赢了. 在读了邹欣老师在知乎发表的Build To Win的文章之后,我对软件开发的模式有了一定新的认知: 软件开发的目地决定了软件开发的模式. 每个人开发软件都是有目地的,我作为学生,写一些小的程序是为了练习,是一个学习的过程,就是邹欣老师在文章中提到的Bu

软件开发模式

软件的开发无非是这样几个环节 需求分析.设计.编码.集成.测试.维护 所有的开发模式都是在此基础上的变化 1.传统的瀑布式开发 由W.W.Royce在1970年最初提出的软件开发模型 典型特征是每个步骤都按照100%的进度来往下进行,不适应过程中的变化.要求每个环节做到完美,因此这种开发模式是效率最低,后期变化情况下基本上不可行. 2.迭代式开发    是一种与传统的瀑布式开发相反的软件开发过程,它弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率. 实际上是一种主体开发,然后在此基础上完

基于成熟网管平台的网管软件开发模式

随着计算机网络的迅速发展,特别是国际互联网的不断地推广,计算机网络的使用越来越广泛,人们的生产生活学习对计算机网络的依赖也越来越大.同时,随着计算机网络的网络规模的不断扩大和连入网络的设备越来越多样,网络的复杂性也越来越高,网络的异构性也越拉越高.于是,网络管理就成为了一个重要的研究课题. 网络管理是对硬件.软件.人力的综合使用和协调,对网络资源进行监视.测试.配置.分析.评价和控制,从而以合理的价格满足网络的需求,如实时运行性能.服务质量等.从定义中可以看出,网络管理包含了两个重要的任务,一是

TDD、BDD、ATDD、DDD 软件开发模式

TDD.BDD.ATDD.DDD 软件开发模式 四个开发模式意思: TDD:测试驱动开发(Test-Driven Development) BDD:行为驱动开发(Behavior Driven Development) ATDD:验收测试驱动开发(Acceptance Test Driven Development) DDD:领域驱动开发(Domain Drive Design) 1.TDD:测试驱动开发(Test-Driven Development) 测试驱动开发是敏捷开发中的一项核心实践和

软件开发模式:瀑布与敏捷

瀑布和敏捷不是什么新概念,这里只是个人在团队合作中不得不去思考而做的归纳和总结,同时记录自己曾经踩过的坑,新瓶装旧酒,希望对你有所启发. 瀑布模式 瀑布模型是比较传统一种开发模式,特别是在2B的传统企业,包括ERP,MES,WMS,CRM,OA,IBMS等系统当中可以经常见到他们的影子.现在这种模式仍然流行在一些大的项目或者是外包的一些项目当中. 如上图所示,瀑布模型优缺点都很突出. 优点明显: 阶段清晰.从计划到开发最后到上线运行,三个阶段非常清晰. 时间顺序.每个阶段顺序必须是从上到下,严格

<读书笔记>软件调试之道 :从大局看调试-零容忍策略

声明:本文档的内容主要来源于书籍<软件调试修炼之道>作者Paul Butcher,属于读书笔记.欢迎转载! -------------------------------------------------------------------------------------------- 缺陷优先 如何使缺陷修复与软件开发相结合? 如何估计缺陷修复花费的时间? 如何确保项目不会陷入<人月神话>中所描述的无数缺陷修复的焦油坑中呢? 缺陷优先 要采用早起缺陷修复原则,并且基于以下两

&lt;读书笔记&gt;软件调试之道 :问题的核心-修复后的反思

声明:本文档的内容主要来源于书籍<软件调试修炼之道>作者Paul Butcher,属于读书笔记.欢迎转载! -------------------------------------------------------------------------------------------------- 有时尽管修复设计的是一个孤立的代码区,但你还是需要大局观,在修复缺陷之后花时间反思一下! 一旦确定了错误的来源,就可以采取措施避免它再发生!有些情况下,只不过是告诉你未来在在这一方面要更加小心

js架构设计模式——理解javascript中的MVVM开发模式

理解javascript中的MVVM开发模式 http://blog.csdn.net/slalx/article/details/7856769 MVVM的全称是Model View ViewModel,这种架构模式最初是由微软的MartinFowler作为微软软件的展现层设计模式的规范提出,它是MVC模式的衍生物,MVVM模式的关注点在能够支持事件驱动的UI开发平台,例如HTML5,[2][3] WindowsPresentation Foundation (WPF), Silverligh

《软件调试的艺术》学习笔记——GDB使用技巧摘要

<软件调试的艺术>学习笔记——GDB使用技巧摘要 <软件调试的艺术>,因为名是The Art of Debugging with GDB, DDD, and Eclipse. 作者是美国的Norman Matloff和Peter Jay Salzman,中文版由张云翻译.是人邮出版社图灵程序设计丛书初版.这里称为"艺术",个人觉得有点过了,但是其中关于gdb以及在gdb基础之上集成的DDD和Eclipse调试技巧的整理确实是做的很好,对于Linux/开源社区下的