- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
软件工程知点
软件危机
“软件危机”(Software crisis)的出现是由于软件的规模越来越大,复杂度不断增加,软件需求量增大。而软件开发过程是一种高密集度的脑力劳动,软件开发的模式及技术不能适应软件发展的需要。致使大量质量低劣的软件涌向市场,有的花费大量人力财力,而在开发过程中就夭折。
“软件危机”主要表现在两个方面:
(1)软件产品质量低劣,甚至开发过程就夭折。
(2)软件生产率低,不能满足需要。
软件工程的定义
软件工程是一门新兴的边缘学科,涉及的学科多,研究的范围广,研究的主要内容有以下几方面:
软件开发方法、技术
软件开发工具及环境
软件管理技术
软件规范(国际规范)
软件生命周期
以瀑布模型为例:
软件包括程序及软件开发过程所产生的所有文档。
常见的软件过程模型
目前典型的软件开发模型有:
瀑布模型、增量模型、螺旋模型、喷泉模型、变换模型和基于知识的模型等。
不同的开发方法有不同的软件过程模型。
瀑布模型、
瀑布模型在软件开发的前期起到重要作用,但逐渐暴露出其缺陷,即将充满回溯的软件开发过程硬性分割为几个阶段。
增量模型、
增量模型是一种非整体开发的模型。是一种进化式的开发过程。
根据增量的方式和形式的不同,分为:
基于瀑布模型的渐增模型
基于原型的快速原型模型
该模型具有较大的灵活性,适合于软件需求不明确、设计方案有一定风险的软件项目。
螺旋模型、
对大型软件,需要多个原型描述系统的生存期,螺旋模型将瀑布模型与原型化模型结合起来,并加入了风险分析。
螺旋模型将开发过程分为几个螺旋周期,每个螺旋周期可分为4个工作步骤:
第一,确定目标、方案和限制条件;
第二,评估方案、标识风险和解决风险;
第三,开发确认产品;
第四,计划下一周期工作。
喷泉模型、
该模型是由B.H.Sollers和J.M.Edwards于1990年提出。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性,喷泉模型使开发过程具有迭代性和无间隙性。适宜面向对象的方法。
其特点如下:
1. 开发过程有分析、系统设计、软件设计和实现4个阶段。
2.各阶段相互重叠,它反映了软件过程并行性的特点。
3.以分析为基础,资源消耗成塔型。
4.反映了软件过程迭代性的自然特性,从高层返回低层无资源消耗。
5.强调增量开发,整个过程是一个迭代的逐步提炼的过程。
速成原型模型
速成原型的工作模型是一个循环的模型。
1.快速分析 快速确定软件系统的基本要求,确定原型所要体现的特征(界面、总体结构、功能、性能)
2.构造原型 考虑主要特征,快速构造一个可运行的系统。有三类原型:用户界面原型、功能原型、性能原型。
3.运行和评价原型
4.修改与改进
循环模型
为了对瀑布模型进行改进,描述软件开发过程中可能的回溯,采用循环模型。
智能模型(intelligent model)
也称为基于知识的软件开发模型,是知识工程与软件工程相结合的软件开发模型。
需求分析的重要性和必要性
软件需求无疑是当前软件工程中的关键问题,没有需求就没有软件。
应用领域的广泛性,它的实施无疑与各个应用行业的特征密切相关。
非功能性需求建模技术的缺乏,及其与功能性需求有着错综复杂的联系,大大增加了需求工程的复杂性。
沟通上的困难,由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景,给需求工程的实施增加了人为的难度
可行性研究
可行性研究的目的不是解决问题,而是确定问题是否值得去解决
可行性研究实质上是要进行一次大大压缩简化了的系统分析和设计的过程,也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。
可行性研究最根本的任务是对以后的行动方针提出建议
可行性研究需要的时间长短取决于工程的规模。一般说来,可行性研究的成本只是预期的工程总成本的5%~10%。
主流的软件体系结构(分布式结构、分布式对象结构、中间件)
件体系结构确定了系统的组织结构和拓扑结构,显示了系统需求和构成系统的元素之间的对应关系,提供了一些设计决策的基本原理。
体系结构的设计过程的主要活动:
1.系统分解—将系统分解为若干相互作用的子系统。
2.控制建模—建立系统各部分间控制关系的一般模型。
3.模块分解 — 将子系统进一步划分为模块。
注意:往往子系统与模块之间没有明显界限.
一、仓库模型(The repository model)
也称“容器模型 ”,是一种集中式的模型。中央数据仓库存储各个子系统共享的数据,其它的子系统可以直接访问这些共享数据。子系统之间紧密耦合。
各子系统共享中央数
文档评论(0)