软件工程的学习心得

以下是自各个网站文献中整理而来的软件工程的最新成果及其应用等。首先是土耳其MilSOFT公司的最新成果，该公司开发了无人机控制软件。defenseworld 网 站 2020 年 11 月 20 日报道，土耳其 MilSOFT 公司开发的无人机控制软件可与人 工智能无人机协同使用，实现对最 多 50 架无人机组成的无人机蜂群 平 台 的 控 制。MilSOFT 无人机蜂 群控制软件可控制载机 / 其他平台 发射蜂群无人机。无人机获取的图 像数据能够通过中继实现蜂群内共 享。同时，基于 MilSOFT 控制软 件，蜂群无人机能够接收载机指令， 实施正面攻击或作战支援。另外， MilSOFT 公司还提供了人工智能无 人机通信解决方案，通信距离可达 500 米。公司表示，有能力提供 10 公里范围内的无人机数据传输网络 解决方案。未来还将实现对海用、 水下、陆地无人平台的控制 / 通信 解决方案。

    随后将目光投向国内，赵淑君硕士提出了一种弹上软件开发生命周期模型，说到软件开发模型，我们可以先回顾软件开发模型内容。

1.传统软件开发模型简介

     传统的软件开发模型有原型、瀑布型、迭代型/ 增量型［2］等。 原型一般用于软件项目早期，此时需求不明 确，需要快速形成软件产品，但对软件产品可靠性 要求不高，通常用于功能演示验证; 瀑布模型一般 用于需求明确的项目，是一种理想的文档驱动型的 开发方式; 迭代型/增量型介于二者之间，但是软件 需求的变更需要受到严格的控制，每一次迭代都类似一个瀑布过程，整个开发周期比较长，管理活动 消耗时间较多。 近年来提出的敏捷开发方法，在许多行业和领 域得到了广泛的关注和应用［3 － 5］，它的本质是一种 “关注产品本身胜于过程和文档”的观点，它的 4 句 宣言“个体和交互胜过过程和工具、可以工作的软 件胜过面面俱到的文档、客户合作胜过合同谈判、 响应变化胜过遵循计划”［6］强调开发者之间以及开 发者与客户之间面对面地交流，强调以人为核心， 强调快速响应，它的开发特点类似于迭代型或者增 量型，但是敏捷开发方法更侧重于给出了很多操作 层面的方法和步骤，如用户故事、每日站会、冲刺、 回顾、燃尽图、结对编程等［7］，但它对文档的要求相 对较弱，通常在高层级描述系统结构和行为以及关 键的设计原理［8］

2 .弹上软件的特点

 弹上软件有其专门的应用场景，既遵循软件的 一般研制规律，必须经过系统分析与设计( 用户需 求开发) 、软件需求分析、软件设计和实现、单元测 试/单元集成测试、配置项测试、软硬件集成测试、 验收交付和运行维护等多个阶段［11］，同时又具有自 己的特点，主要表现在 3 个方面。 ( 1) 需求不稳定 武器装备有其自身的研制规律，需要创新和突 破，研制过程是一个不断探索发现、不断深化认识 的过程，因此软件需求必然也是一个循序渐进、不 断迭代和完善的过程，很难一次明确到位。在这个 过程中由于需求不断变化，软件技术状态始终在一个 动态的变化当中，需求变更呈现常态化，特别是整个 研制阶段的初期和中期，为了系统功能的改进和性能 的优化，软件经常需要不断地修改和完善。频繁的更 改不仅影响软件的质量也影响开发的进度。 ( 2) 对缺陷“零容忍” 弹上设备任务具有一次性的特点，软件质量好 坏直接关系到任务的成败，因此对于软件缺陷“零 容忍”。因为一个小小的软件疏忽就会导致任务的 失败，造成非常严重的损失和后果，这不是通常软 件“bug”修复就可以的。通常弹上软件具有很高的 安全关键等级，“一次做对”、“零缺陷”是弹上软件 质量的最高目标，也是弹上软件过程控制的最高 目标。 ( 3) 研制节点紧迫 弹上软件作为武器系统的一部分，它的研制进 程与武器系统的研制进度紧密相关，经常要求研制 节点“后墙不倒”。时间紧，任务重，对软件质量是 一个极大的挑战。因此，在需求不稳定不明确的情 况下如何有效开展软件研制工作，从而既保证软件 质量又要满足武器系统的进度要求，就成为一个引 人思考的问题。 弹上软件的上述特点表明，其面临一个矛盾， 需求很难一次明确，但是又要求产品可靠性高，原 型和瀑布型无法满足要求，采用迭代型/增量型又因 为频繁的需求变更使得软件过程控制复杂繁琐，无法 满足进度要求，敏捷开发中对于文档需求的弱化同样 也不能满足弹上软件开发的文档标准［12］要求。 本文针对弹上软件的上述特点，提出了一种基 于原型 + 快速瀑布模型的弹上软件开发模型，解决 在需求不稳定的情况下，通常的软件开发模型无法 同时满足质量和进度要求的问题，并对该模型的各 个阶段主要工作内容和要求进行了阐述。该模型 同样适用于具有类似特点的其他软件。

3 弹上软件开发模型组成 3． 1 模型组成框图 弹上软件开发模型的组成如图 1 所示。

（图1）

说明: 一次软件开发过程以完成软件验收交付活动作为结束标志，后续运行维护 ( 包含武器系统联试) 过程中，如果需要进行软件修改，执行软件更改升级过程。基于原型 + 快速瀑布模型的弹上软件开发模 型，包括: 原型功能验证、快速需求固化、快速设计 优化、快速代码优化、软件内部测试、软硬件集成测 试/三方评测和验收交付等阶段。 ( 1) 原型功能验证: 是通过需求分析、设计、实 现和测试验证的快速迭代过程形成初步的软件产 品，并放到所属系统中完成初步验证，以便引出正 式的软件需求，也即开发软件需求的过程。 ( 2) 快速需求固化: 是根据原型功能验证结果， 将软件需求进行固化，形成正式软件需求文档的 过程。 ( 3) 快速设计优化: 是根据正式的软件需求文 档，对软件初步设计方案进行优化，形成正式软件 设计方案的过程。 ( 4) 快速代码优化: 是根据正式的设计方案对 代码的实现进行优化的过程。 ( 5) 软件内部测试: 是对优化后的代码进行详 细的单元测试、单元集成测试和配置项测试的过程。 ( 6) 软硬件集成测试/三方评测: 软硬件集成测 试是将软件置于所属系统与硬件及外部设备或其 他软件进行集成测试以确定软硬件及本软件与其 他软件之间的工作是否相协调一致的过程，同时在 此阶段还要视需要开展软件第三方评测工作并最 终通过软件第三方评测。 ( 7) 验收交付: 是将通过软硬件集成测试和三 方评测的软件完成正式验收交付的过程。

此模型的需求代码和测试部分不再赘述。

本学期的软件工程导论学习现在以及基本告一段落了，这一学期的学习，老师结合课本，通过各种实验让我们体验了软件工程的一系列过程，让我们体会到了设计一个软件不仅仅是敲代码这么简单，在实践过程中，我们先后进行了竞品分析、前景和范围分析，后来开始实践制作可行性分析以及需求分析两大方面内容，最后我们进行了详细设计和总体设计文档的编写，最后也在答辩中尽我们所能向同学们展示了我们这个学期的成果。在各个实验中最让人印象深刻或者说头疼的是各个数据流图和系统流程图的画法和设计，因为在此前我们都没有接触过这方面的内容，在老师上课讲解之后其实也是一知半解，比如我们组设计的物联图书借阅系统中我所负责的借阅者的相关流程图，我发现网上给的例子和老师所给的例子并不是完全一致，甚至有的差距比较大，导致我第一次做的时候信心满满的交给组员审核的时候发现和别人做的相去甚远。后面通过组长的指导和查阅各种资料才勉强完成了流程图，但结果也不甚满意，这不断的尝试和交流中我们组员也基本出色的完成了任务。

在实践的过程中我们加深了对相关知识点的记忆，按照模板及书中所标内容进行摸索，其中也进行了小组的合作，才能完成一份完整的可行性分析或者需求分析报告。在制作报告的过程中我们也暴露出了很多问题，比如对很多图的定义和画法不熟悉导致画图不标准，以及在画图过程中将数据流图和系统流程图弄混等，还有在团队的配合上出现了失误，比如每个人所完成的报告部分不统一，导致在报告过程中造成报告前后出现有的功能没有具体体现等失误，导致各种报告前后不一致的问题出现。很多图第一次接触出现了各种各样的问题，有大有小，这不仅需要我们个人加强对图文的理解以及多费精力，也需要团队之间加强沟通，避免各部分内容不统一的情况出现。虽然有着这样那样的问题，但是团队的每个人都很认真负责，都在为了更好地完成任务而努力。

此外，在一个学期的学习之后，我认识到了软件工程的前期准备和后期的维护都是十分重要的，一个出色的软件远远不止代码的编写，还有前期一系列的分析和后期的功能完善和维护升级等，这些都不比编写代码容易或者说相对而言更为重要。学习完这门课，我觉得主要的不仅是让我们学会了初步编写各种分析报告，更重要的是给我们打开了很多新的前景，比如个人不是很擅长编写代码或者说对于领导或决策更为擅长的人来说可以选择当软件分析或者测试员，以及整个环节非常重要的项目经理。