技术标签: 软件 软件危机 软件模型 软件工程导论 软件工程
软件是计算机系统中与硬件相互依存的另一部分,它是包括程序,数据及其相关文档的完整集合。
其中,程序是按事先设计的功能和性能要求执行的指令序列;数据是使程序能正常操纵信息的数据结构;文档是与程序开发,维护和使用有关的图文材料。
与之相似的是,在1983年IEEE组织对软件下的定义是:计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。
比软件定义更重要的是,必须充分认识到软件开发不是某种个体劳动的神秘技巧,而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
软件有以下七个特点:
软件的分类并没有一个绝对的标准,但一般情况下都会用软件规模来对软件进行分类,如下表:
类别 | 参加人员数 | 研制期限 | 产品规模(源程序行数) |
---|---|---|---|
微型 | 1 | 1~4周 | 0.5K |
小型 | 1 | 1~6月 | 1K~2K |
中型 | 2~5 | 1~ 2年 | 5K~50K |
大型 | 5~20 | 2~3年 | 50K~ 100K |
甚大型 | 100~1000 | 4~5年 | 1M |
极大型 | 2000~5000 | 5~10年 | 1M~10M |
软件发展的四个时期及其特点
特点\时期 | 基本软件期 | 程序设计方法时代 | 软件工程时期 |
---|---|---|---|
软件所指 | 程序 | 程序及说明书 | 程序、文档、数据 |
主要程序设计语言 | 汇编及机器语言 | 高级语言 | 软件语言 |
软件工作范围 | 程序编写 | 设计、编码和测试 | 软件周期 |
软件使用者 | 程序设计者本人 | 少数用户 | 市场用户 |
软件开发组织 | 个人 | 开发小组 | 开发小组及大中型软件开发机构 |
软件规模 | 小型 | 中小型 | 大中小型 |
决定质量的因素 | 个人编程技术 | 小组技术水平 | 技术水平及管理水平 |
开发技术和手段 | 子程序和程序库 | 结构化程序设计 | 数据库,开发工具,开发环境, 工程化开发方法,标准和规范, 网络及分布式开发面向对象技术及软件复用 |
维护责任者 | 程序设计者 | 开发小组 | 专职维护人员 |
硬件特征 | 价格高、存储容量小、工作可靠性差 | 速度、容量及工作可靠性有明显提高 | 向超高速,大容量,微型化及网络化方向发展 |
软件特征 | 完全不受重视 | 软件技术的发展不能清足需要,出现软件危机 | 开发技术有进步,但未获突破性进展,价格高未完全摆脱软件危机 |
1968年在西德Garmish召开的国际软件工程会议上正式提出软件危机的概念:计算机软件的开发和维护过程所遇到的一系列严重问题。
软件危机一般表现在以下五个大方面:
客观原因:软件本身特点,例如逻辑部件复杂、规模庞大等等。
在软件开发和维护的过程中存在这么多严重问题,一方面与软件本身的特点有关,另一方面也和软件开发与维护的方法不正确有关。软件不同于硬件,它是计算机系统中的逻辑部件而不是物理部件,在运行过程中不会因为使用时间过长而被"用坏",如果运行中发现了错误很可能是遇到了一个在开发时期引入的,在测试阶段没能检测出来的错误。
软件不同于一般程序,它的一个显著特点是规模庞大,而且程序复杂性将随着程序规模的增加而呈指数上升。
主观原因:程序员不正确的开发方法,忽视需求分析,并且错误地认为软件开发等于程序编写,轻视软件维护。
主观上的错误认识和作法主要表现为忽视软件需求分析的重要性,认为软件开发就是写程序并设法使之运行,轻视软件维护等。目前相当多的软件专业人员对软件开发和维护还有不少其他的糊涂观念,在实践过程中或多或少地采用了错误的方法和技术,这可能是使软件问题发展成软件危机的主要原因。
对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。另一方面还必须认识到程序只是完整的软件产品的一个组成部分,一个软件产品必须由一个完整的配置组成,主要包括程序、文档和数据等成分,他们缺一不可。
软件问题要尽早解决
作好软件定义时期的工作,是降低软件,成本提高软件质量的关键。在实际的软件开发中,在软件开发的不同阶段进行修改需要付出的代价是很不相同的,大约如下图所示,它表示了错误发现的越晚,付出的代价越高。
因此可以说,轻视维护是一个巨大的错误。统计数据表明,实际上用于软件维护的费用占软件总费用的55%~70%。软件工程学的一个重要目标就是提高软件的可维护性,减少软件维护的代价。
软件危机案例:
IBMOS/360操作系统被认为是一个典型的案例,到现在为止,它仍然被使用在360系列主机中。这个经历了数十年,极度复杂的软件项目甚至产生了一套不包括在原始设计方案之中的工作系统。
IBM公司开发OS/360系统,共有4000多个模块,约100万条指令,投入5000人年,耗资数亿美元,结果还是延期交付,在交付使用后的系统中仍发现大量(2000个以上)的错误,造成无法估计的安全隐患。
实际上就目前的手段而言,软件工程只能解决主观上造成软件危机的原因,对于软件本身特点,例如逻辑部件复杂、规模庞大等客观原因,软件工程是无能为力的。
主观危机的解决途径主要有两条:1、组织管理。2、技术措施
在组织管理可以采用工程项目管理方法;
在技术措施上提升软件开发技术与方法,灵活运用软件工具。应该推广使用在实践中总结出来的开发软件的成功的技术和方法,并且研究探索更好更有效的技术和方法,尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。并且应该开发和使用更好的软件工具,在软件开发的每个阶段都有许多繁琐重复的工作需要做,在适当的软件工具辅助下,开发人员可以把这类工作做得既快又好。
为了消除软件危机,首先应该对计算机软件有一个正确的认识,首当其冲的就是彻底消除"软件就是程序"的错误 观念,要明确一个软件必须由一个完整的配置组成,是程序、数据及相关文档的完整集合。
软件工程学是在1968年,北约计算机科学会议上由Fritz Bauer提出的,他给出的软件工程学的定义为:用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法。其中包含了三个要素:方法、工具、过程。
软件工程学的中心思想是把软件当作一种工业产品,要求采用工程化的原理与方法对软件进行计划、开发和维护。因此可以说,软件工程学是一门指导计算机软件开发和维护的工程学科,它包含了开发技术和工程管理两方面。
软件工程的目的是为了实现按预期的进度和经费完成软件生产计划,提高软件的生产率和可靠性。
具体来说就是要达到以下几个主要的目标:
但是软件工程的各个目标是不可能全部满足的,下图表示了软件工程目标之间的关系,可见,软件工程的最终目标只能是实现一个均衡的系统。
软件工程关注于大型程序的构造
"大"与"小"的分界线并不十分清晰。通常把一个人在较短时间内写出的程序称为小型程序,而把多人合作用时半年以上才写出的程序称为大型程序。
软件工程的中心课题是控制复杂性
软件所解决的问题十分复杂,通常不得不把问题分解,使得分解出的每个部分是可理解的,而且各部分之间保持简单的通信关系。用这种方法并不能降低问题的整体复杂性,但是却可使它变成可以管理的。
软件经常变化
绝大多数软件都模拟了现实世界的某一部分。现实世界在不断变化,软件为了不被很快淘汰,必须随着所模拟的现实世界一起变化。因此,在软件系统交付使用后仍然需要耗费成本,而且在开发过程中必须考虑软件将来可能的变化。
开发软件的效率非常重要
目前,社会对新应用系统的需求超过了人力资源所能提供的限度,软件供不应求的现象日益严重。因此,软件工程的一个重要课题就是,寻求开发与维护软件的更好更有效的方法和工具。
和谐地合作是开发软件的关键
软件处理的问题十分庞大,必须多人协同工作才能解决这类问题。为了有效地合作,必须明确地规定每个人的责任和相互通信的方法。纪律是成功地完成软件开发项目的一个关键。
软件必须有效地支持它的用户
开发软件的目的是支持用户的工作。软件提供的功能应该能有效地协助用户完成他们的工作。
有效地支持用户意味着必须仔细地研究用户,以确定适当的功能需求、可用性要求及其他质量要求(例如,可靠
性、响应时间等)。有效地支持用户还意味着,软件开发不仅应该提交软件产品,而且应该写出用户手册和培训材料。
在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人
软件工程师是诸如Java程序设计、软件体系结构、测试或统一建模语言(UML)等方面的专家,他们通常并不是图书馆管理、航空控制或银行事务等领域的专家,但是他们却不得不为这些领域开发应用系统。缺乏应用领域的相关知识,是软件开发项目出现问题的常见原因。
有时候,软件开发者通过访谈、阅读书面文件等方法了解到用户组织的“正式”工作流程,然后用软件实现这个工作流程。但是,决定软件系统成功与否的关键问题是,用户组织是否真正遵守这个工作流程
著名的软件工程专家B.W.Boehm综合学者们的意见,于1983年在一篇论文中提出了软件工程的七条基本原理。这七条原理是确保软件产品质量和开发效率的原理的最小集合。
这七条原理是互相独立的,其中任意6条原理的组合都不能代替另一条原理。同时这七条原理又是相当完备的,虽然不能用数学方法严格证明它们是一个完备的集合,但是可以证明在此之前已经提出的一百多条软件工程原理都可以由这七条原理的任意组合蕴含或派生。
七条基本原理:
软件工程包括技术和管理两方面的内容,是技术与管理紧密结合所形成的工程学科。通常把在软件生命周期全过程中使用的整套技术方法的集合称为方法学(Methodology),也称为范型(Paradigm)。
软件工程方法学包含3个要素:
目前使用得最广泛的软件工程方法学有传统方法学(面向数据流/结构化方法学) 和 面向对象方法学。他们分别代表了两种程序设计方法:即结构化程序设计(程序=数据结构+算法) 和 面向对象程序设计(程序=对象+请求消息)
两种方法学的软件开发流程如下所示:
传统软件工程:软件分析→总体设计→详细设计→面向过程的编码→测试。会有一个清楚的流程体系。
面向对象软件工程:软件分析与对象抽取→对象详细设计→面向对象的编码→测试。
所谓软件生命周期,软件从产生、发展到成熟,直至衰亡为止的整个过程。
它由八个小阶段组成:
国标《计算机软件开发规范》将软件生存周期分为可行性研究与计划、需求分析、总体设计、详细设计、实现(编码和单元测试)、集成测试、确认测试、使用和维护共八个小阶段
这八个小阶段又可以分为三个时期:
实际从事软件开发工作时,软件规模、类型、开发环境及技术方法等因素会影响到阶段划分,及各阶段的执行顺序,形成不同生存周期模型,又称过程模型。也就是说以上的三个时期所包含的阶段不一定非要按照国标来进行,应当按照实际情况灵活安排软件周期。
软件开发模型实际上是软件工程三要素中"过程"要素的展开,下面介绍几种经典的软件开发模型
瀑布模型一直是唯一被广泛采用的生命周期模型,现在它仍然是软件工程中应用得最广泛的文档驱动的过程模型。如下图所示为传统的瀑布模型
瀑布模型区别与其他模型最大的特点有三个:
传统的瀑布模型过于理想化了,事实.上,人在工作过程中不可能不犯错误。实际的瀑布模型是带"反馈环"的,如下图所示。
实际的瀑布模型当在后面阶段发现前面阶段的错误时,需要沿图中左侧的反馈线返回前面的阶段,修正前面阶段的产品之后再回来继续完成后面阶段的任务。
快速原型模型是低成本的,进行循环需求分析的一个快速开发模型。它的基本结构如图所示。
原型是值快速建立起来的可以在计算机上运行的程序,它所能完成的功能往往是最终产品能完成的功能的一个子集,然后在用户的不断使用中探明用户需求,不断对原型进行改进,最终完成需求分析。
因此它的两个最大的优点就是:
增量模型也称为渐增模型。使用增量模型开发软件时,把软件产品作为一系列的增量构件来设计、编码、集成和
测试。每个构件由多个相互作用的模块构成,并且能够完成特定的功能。开发流程如下图所示
下图是每一个增量构建的实现过程图:
增量模型能在较短时间内向用户提交可完成部分工作的产品。逐步增加产品功能可以使用户有较充裕的时间学
习和适应新产品,从而减少一个全新的软件可能给客户组织带来的冲击。
但是它也是有缺陷的,增量模型面临的最大困难就是必须保证在把每个新的增量构件集成到现有软件体系结构中时,必须不破坏原来已经开发出的产品。必须把软件的体系结构设计得便于按这种方式进行扩充,向现有产品中加入新构件的过程必须简单、方便,也就是说,软件体系结构必须是开放的。
螺旋模型的基本思想是,使用原型及其他方法来尽量隆低风险。理解这种模型的一个简便方法,是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。从本质上来讲,螺旋模型就是一个加入了风险分析的快速原型模型。
螺旋模型的主要优势在于,它是风险驱动的。它的开发过程如图所示:
一个螺旋式周期包括下面4个完整步骤:
构建集成模型是一个典型的面向对象开发模型,它的一个典例就是各种开发IDE,例如Visual Studio,可以查找加载各种构建。
构建集成模型有着以下五个特点:面向对象、基于构件库、融合螺旋模型特征、支持软件开发的迭代方法、软件重用
文章浏览阅读2.5w次,点赞6次,收藏50次。官方解释是,docker 容器是机器上的沙盒进程,它与主机上的所有其他进程隔离。所以容器只是操作系统中被隔离开来的一个进程,所谓的容器化,其实也只是对操作系统进行欺骗的一种语法糖。_docker菜鸟教程
文章浏览阅读5.7k次,点赞3次,收藏14次。该如何避免的,今天小编给大家推荐两个下载Windows系统官方软件的资源网站,可以杜绝软件捆绑等行为。该站提供了丰富的Windows官方技术资源,比较重要的有MSDN技术资源文档库、官方工具和资源、应用程序、开发人员工具(Visual Studio 、SQLServer等等)、系统镜像、设计人员工具等。总的来说,这两个都是非常优秀的Windows系统镜像资源站,提供了丰富的Windows系统镜像资源,并且保证了资源的纯净和安全性,有需要的朋友可以去了解一下。这个非常实用的资源网站的创建者是国内的一个网友。_msdn我告诉你
文章浏览阅读1.2k次。vue2封装对话框el-dialog组件_
文章浏览阅读4.7k次,点赞5次,收藏6次。MFC 文本框换行 标签: it mfc 文本框1.将Multiline属性设置为True2.换行是使用"\r\n" (宽字符串为L"\r\n")3.如果需要编辑并且按Enter键换行,还要将 Want Return 设置为 True4.如果需要垂直滚动条的话将Vertical Scroll属性设置为True,需要水平滚动条的话将Horizontal Scroll属性设_c++ mfc同一框内输入二行怎么换行
文章浏览阅读832次。检查Linux是否是否开启所需端口,默认为6379,若未打开,将其开启:以root用户执行iptables -I INPUT -p tcp --dport 6379 -j ACCEPT如果还是未能解决,修改redis.conf,修改主机地址:bind 192.168.85.**;然后使用该配置文件,重新启动Redis服务./redis-server redis.conf..._redis-server doesn't support auth command or ismisconfigured. try
文章浏览阅读4.9k次。济大数电实验报告_数据选择器及其应用
文章浏览阅读236次。1研究内容消费在生产中占据十分重要的地位,是生产的最终目的和动力,是保持省内经济稳定快速发展的核心要素。预测河南省社会消费品零售总额,是进行宏观经济调控和消费体制改变创新的基础,是河南省内人民对美好的全面和谐社会的追求的要求,保持河南省经济稳定和可持续发展具有重要意义。本文建立灰色预测模型,利用MATLAB软件,预测出2019年~2023年河南省社会消费品零售总额预测值分别为21881...._灰色预测模型用什么软件
文章浏览阅读1.2k次。12.4-在Qt中使用Log4Qt输出Log文件,看这一篇就足够了一、为啥要使用第三方Log库,而不用平台自带的Log库二、Log4j系列库的功能介绍与基本概念三、Log4Qt库的基本介绍四、将Log4qt组装成为一个单独模块五、使用配置文件的方式配置Log4Qt六、使用代码的方式配置Log4Qt七、在Qt工程中引入Log4Qt库模块的方法八、获取示例中的源代码一、为啥要使用第三方Log库,而不用平台自带的Log库首先要说明的是,在平时开发和调试中开发平台自带的“打印输出”已经足够了。但_log4qt
文章浏览阅读786次。全局观思维模型,一个教我们由点到线,由线到面,再由面到体,不断的放大格局去思考问题的思维模型。_计算机中对于全局观的
文章浏览阅读330次。一、CountDownLatch介绍CountDownLatch采用减法计算;是一个同步辅助工具类和CyclicBarrier类功能类似,允许一个或多个线程等待,直到在其他线程中执行的一组操作完成。二、CountDownLatch俩种应用场景: 场景一:所有线程在等待开始信号(startSignal.await()),主流程发出开始信号通知,既执行startSignal.countDown()方法后;所有线程才开始执行;每个线程执行完发出做完信号,既执行do..._countdownluach于cyclicbarrier的用法
文章浏览阅读508次。Prometheus 算是一个全能型选手,原生支持容器监控,当然监控传统应用也不是吃干饭的,所以就是容器和非容器他都支持,所有的监控系统都具备这个流程,_-自动化监控系统prometheus&grafana实战
文章浏览阅读4.7k次。输入关键字,可以通过键盘的搜索按钮完成搜索功能。_react search