Bonky
Neither beliver nor reject anything, because any other person has rejected of believed it. Heaven has given you a mind for judging truth and error, Use it.
By Thomas Jefferson

软件工程 – 概述

主讲老师:周杨(东软公司)

考核标准:作业 20% + 实验成绩 20% + 考试60%

实验内容:包括以下四个方面:

  • 需求分析:系统流程图
  • 系统设计:界面原型(墨刀)
  • 系统测试:对实际系统的功能进行测试
  • 项目管理:项目过程文档

软件发展

四个阶段:程序设计→程序系统→软件工程→第四阶段

  • 程序设计阶段:规模小编写者和使用者同一个人,无文档材料保存。
  • 程序系统阶段:产生了很多软件作坊,沿用早期个体化软件开发方法。
    • 导致了软件危机,软件维护工作耗费大量资源
  • 软件工程阶段:工程化的设计原则、方法和标准。
  • 第四阶段(八十年代到现在):软件架构发生变化。产生了C/S和B/S模式。

软件危机

软件工程的产生是为了缓解软件危机所产生的一门学科。软件危机,即在计算机软件开发和维护过程中遇到的一系列严重问题。主要表现有:

  1. 开发成本和进度估计不准。
  2. 用户对已交付软件不满意。开发人员对用户信息交流不充分,产品不符合用户需求。
  3. 软件产品质量靠不住。软件产品保证技术(审查、复审、测试)没有贯彻于应用软件开发全过程。
  4. 软件可维护性差。开发时未考虑,很多错误难以改正。
  5. 软件没有适当文档资料。文档资料应在软件开发过程中产生,保证最新。

软件工程

定义:把系统化、规范化、可度量的途径应用于软件开发、运行和维护过程中,研究其实现途径。

软件工程主要包括技术和管理两个部分:

  • 软件工程技术
    • 软件开发方法学
    • 软件开发过程
    • 软件工具和软件工程环境
  • 软件工程管理
    • 软件管理学
    • 软件经济学
    • 软件心理学(比如说请第三方或者用户进行测试)

软件生存周期

国标计算机软件开发规范,分8个阶段,下面是八个阶段的内容和所有需要的工程报告:

  • 可行性研究与计划:解决问题是什么?有行得通解决方法?粗略计划。
    • 问题定义报告:问题性质、工程目标、工程规模。
    • 可行性研究报告:经济、技术、社会(操作)可行性。
    • 项目开发计划:粗略。
  • 需求分析:目标系统必须作什么?比可行性研究详细地多。
    • 需求规格说明书:目标系统需求。这个文档是最重要的内容,说明了未来这个软件要做的所有的事情(用户验收也根据这个来验收)。
  • 总体设计:怎样实现目标系统?根据需求设计方案,分析推荐最佳方案。
    • 总体设计说明书:记录总体设计结果。
  • 详细设计:该怎样具体实现系统?设计每个模块的算法和数据结构。
    • 详细设计说明书: 用适当表达工具表达算法和数据结构。
  • 实现(编码和单元测试):用适当表达工具表达算法和数据结构。
    • 程序清单(manifest):即项目的元数据。描述了程序的名称,版本号和组成文件等等。

    • 单元测试报告:测试每个单元是否工作正常。类似如下:

    image-20200519092015796

  • 集成测试:将经过单元测试模块组装起来进行测试。

    • 测试报告:测试计划、测试方案、测试结果。
  • 确认测试(验收测试):由用户按需求规格说明书规定进行测试。
    • 测试报告:测试计划、测试方案、测试结果。
  • 使用和维护:通过必要维护活动使系统持久满足用户要求。
    • 改正性维护:软件运行过程中发现错误,进行维护。
    • 适应性维护:软件运行软硬件环境变化,进行的维护。
    • 完善性维护:用户要求改进或扩充软件,进行的维护。
    • 预防性维护:为将来的维护作准备。

过程模型

常见的模型有:瀑布模型,快速原型模型,增量模型,螺旋模型,喷泉模型,Rational统一过程(RUP),微软过程和敏捷开发模型。

瀑布模型

image-20200519093046830

阶段间具有顺序性和依赖性。比如需求分析结束之后,才能进行规格说明。每一个阶段必须实现其文档,每一个阶段输出的文档是下一个阶段文档的输入。

推迟实现。瀑布模型在编码前设置系统分析、系统设计,推迟程序物理实现,保证前期工作扎实。

质量保证。一、每阶段都必须完成完整、准确的文档。软件开发时人员间通信、运行时期维护的重要依据。二、每阶段结束前对文档评审。

当然一般来说不太可能不出错误,所以往回改正还是很重要的,所以一般就是使用的是带反馈环的瀑布模型:

image-20200519093818037

瀑布模型的优点是提高软件质量,降低维护成本,缓解软件危机。缺点是模型缺乏灵活性,无法解决需求不明确问题。用户不经过实践提出完整准确需求不切实际,因为瀑布模型需要用户尽可能提出所有的需求。

快速原型模型

快速建立反映用户主要需求的原型系统,反复由用户评价修正需求,开发出最终产品。因为实际上要用户想出所有的需求还是不太可能的,因为用户不知道自己要什么(引用乔教主),但不过我们做出的一个原型,用户对于吹毛求疵还是很容易的。特别适合那种用户啥都不懂,需求不明确的任务(非贬义:->)。

  • 优点:确定需求上优于瀑布模型(通过原型与用户交互) ;有的软件原型可以成为最终产品的一部分。
  • 缺点:快速建立的系统结构加连续修改可能导致产品质量低下,原型系统的内部结构可能不好。

增量模型

image-20200519094945799

开发软件时将软件产品作一系列增量构件设计、编码、集成和测试。做完一个构件就给用户,然后用户可以在这段时间就可以学习和使用软件(比如导入数据库等等)。

区别于瀑布和快速原型模型:瀑布和快速原型模型是一次把满足所有需求产品提交给用 。
增量模型是分批向用户提交产品。

  • 优点:较短时间向用户提交可完成有用工作产品;用户有充裕时间学习适应产品;
    软件结构必须开放,方便向现有产品加入新构件。
  • 缺点:做到第三个优点比较困难,需要有像乔教主一样的大佬设计(误)。

同样地,如果想更快地完成任务,我们有一种风险更大的增量模型,各个构件并行实现,有点像 CPU 指令流水线的感觉,但不过万一哪个部分设计有问题就 GG 了,所以除非特别赶,那就不要用。

image-20200519095415755

螺旋模型

在软件设计的过程中,加入了风险分析。常见的风险有:规定的时间可能无法完成;预算不够了,软件还没做完,钱就用完了(和某些大学生如出一辙);行业竞争,比如说你做个游戏,做到一半腾讯就抄完发布了,那么劝你还是放弃(我:不能向黑恶势力低头,TXNMSL ❤️)。

image-20200519100146688

笛卡尔坐标四象限表达四方面活动:

  • 制定计划:确定目标、选定方案、设定约束条件。
  • 风险分析:评估方案,识别和消除风险。
  • 实施工程:软件开发。
  • 客户评估: 评价开发工作,计划下一阶段工作。沿螺线自内向外每旋转一圈开发出更完善新版本。

螺旋模型优缺点包括:

  • 优点:大型软件开发项目有较好的风险控制;
  • 缺点:需要风险评估的经验。普及不如前述模型。

喷泉模型

image-20200519100902289

面向对象生命周期模型,体现迭代和无缝特性,特别适合面相对象的编程。迭代指的是对于前面的实现每次改进。无缝指的是分析、设计、编码各阶段间不存在明显边界。

  • 优点:无缝, 可同步开发,提高开发效率,节省开发时间,适应面向对象软件
  • 缺点:可能随时加各种信息、需求与资料,需严格管理文档,审核的难度加大。比如我模块改了点,然后牵涉到这个模块的东西都要改,很有可能遗漏。

Rational 统一过程(RUP)

RUP总结了经过多年商业化验证的6条最有效的软件开发经验,这些经验被称为“最佳实践”,是现在很多公司使用的软件开发模型。RUP 的每个阶段的侧重点不同(PS:UML 也是 Rational 这家公司发明的)。

RUP有9个核心工作流,包括6个核心过程工作流和3个核心支持工作流。RUP有4个连续阶段,每个阶段有明确目标,通过一次或多次迭代完成。

image-20200519101544627

不断的版本发布成为一种团队日常工作的真正驱动力,将发现问题、制定方案和解决过程集成到下一次迭代,降低了风险。

微软过程

image-20200519102012660

分为五个阶段,每个阶段都有其里程碑。比如项目得到认可,代表着规划阶段结束了,那么可以进行下一个设计阶段。注意这各圆不是封闭的,这代表版本更新是递进式的。比如我版本发布后,发现问题,然后又可以及时反馈到下一个版本。

image-20200519102306406

敏捷开发

image-20200519102853326

敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。说到敏捷开发我们不得不说说其核心思想:敏捷宣言。现在敏捷开发是最主流的开发模型。

首先四个核心价值观是,但不过需要强调的是,尽管右项有其价值,我们更重视左项的价值(一个敏捷宣言错误的理解是,右边的是无价值的,所以不需要去做):

  • 个体和互动 高于 流程和工具。这就好比如果你想组个乐队,与其想配上最好的乐器,不如先磨合团队,促进团队之间的交流和协作,这才是最重要的。
  • 工作的软件 高于 详尽的文档。个人理解是,因为编制众多的文档需要花费大量的时间,并且使这些文档和代码保持同步,要花费更多的时间,所以与其把文档写的非常详细,还不如就先把项目实现出来。但不过这个并不是说文档没有价值,必要的接口文档还是很有必要的。
  • **客户合作 ** 高于 合同谈判。让软件的客户和开发团队密切地工作在一起,并尽量经常地提供反馈。
  • **响应变化 ** 高于 遵循计划。

然后还存在着12条原则:

  • 尽早和持续的交付有价值的软件使客户满意。
  • 经常交付可运行软件,交付时间间隔越短越好。
  • 软件全生命周期欢迎需求变更:竞争优势。
  • 项目开发期间业务人员和开发人员必须每天在一起工作。
  • 围绕有积极性的个体构建项目,提供所需的环境和支持,信任。
  • 团队内部采用最优效果和效率的面对面交谈
  • 可运行的软件是首要度量标准。
  • 可持续的开发进度,长期稳定。
  • 不断关注优秀的技能和良好的设计。
  • 简单:减少不必要的工作,例如不必要的文档。
  • 最好的架构、需求和设计出自团队内部
  • 每隔一定的时间总结,优化和调整
Share

You may also like...

发表评论

电子邮件地址不会被公开。 必填项已用*标注