软件工程范围.docx
- 文档编号:27761788
- 上传时间:2023-07-04
- 格式:DOCX
- 页数:9
- 大小:20.85KB
软件工程范围.docx
《软件工程范围.docx》由会员分享,可在线阅读,更多相关《软件工程范围.docx(9页珍藏版)》请在冰豆网上搜索。
软件工程范围
第一章:
1.Definitionofsoftware(软件定义)
(1)软件是计算机指令的集合,通过执行这些指令可以满足预期的特征、功能和性能需求
(2)他是数据结构,他使程序能够充分利用信息。
(3)他描述程序操作和使用的文档。
2.CharacteristicsofSoftware(软件特性)
(1)软件是设计开发的,而不是传统意义上生产制造的。
(2)软件不会磨损。
(3)根据实际的客户需求设计的。
3.Thedifferenceofsoftwareandhardware(软硬件区别)
硬件制造阶段中的质量问题对于软件来说是不存在的或者已于纠正的,二者的人员和工作成果之间的对应关系是完全不同的。
产品构建的方法不同。
软件是设计开发的,而不是传统意义上生产制造的。
软件不会磨损,硬件会磨损。
磨损的硬件部分可以用备用的构件替换,而软件却不存在备用构件。
软件维护比硬件维护更为复杂。
4.Thechangingnatureofsoftware(软件特性的变化)
①系统软件②应用软件③工程科学软件④嵌入式软件⑤产品线软件⑥WEB应用软件⑦人工智能软件⑧遍在计算⑨网络资源(11)开源软件(12)“新经济”
5.Thequalityoflegacysoftware(遗留软件的质量)
质量差,涉及难以掌握,代码令人费解,文档混乱甚至根本没有,测试用例和结果从未归档变更的历史混乱。
需要再工程以适应未来的多样性。
6.Evolutionofsoftware(软件的进化)
变更(软件维护)推动了软件进化:
程序纠错,调整软件以适应新的环境,满足用户新特征和功能的需求,对软件实施再工程以便在现代应用中发挥作用。
规律有:
①持续变化规律②复杂变化规律③自我调控规律④组织稳定性守恒规律⑤保证通晓性规律⑥持续增长规律⑦反馈系统规律
第二章:
1.ThedefinitionofSoftwareengineering(软件工程定义)
软件工程是一种层次化技术,是将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护,即将工程化方法应用于软件。
软件工程的根基在于质量关注点。
2.ThegoalofSoftwareengineering
软件工程的基础是过程层,合理的及时的开发计算机软件。
3.Layer:
tools,methods,processandaqualityfocus(自顶向下)
工具:
为过程和方法提供自动化或半自动化的支持。
方法:
为建造软件提供技术上的解决方法。
包括沟通、需求分析、涉及建模、编程、测试和支持。
过程:
软件工程的基础。
过程层将各个技术层次结合在一起,并适时合理的及时的开发计算机软件。
过程定义一个框架,为有效交付软件工程技术,这个框架必须建立。
软件过程构成了软件项目管理控制的基础,并建立了一个环境以便于技术方法的采用、工作产品的产生、里程碑的建立、质量的保证、正常变更的正确管理。
质量关注点:
软件工程的根基。
4.Thegeneric(通用的)processframework:
communication,planning,modeling,constructionanddeployment
沟通:
这个框架活动包含了与客户之间大量的交流和协作,还包括需求获取以及其它相关活动。
策划:
指为后续的软件工程工作制定计划,他描述了需要执行的技术任务,、可能的风险、资源需求、工作产品和工作进度计划。
建模:
包括创建模型和设计两方面。
创建模型有助于客户和开发人员更好地理解软件需求;设计可以实现需求。
部署:
软件交付到用户,用户对其进行测试并给出反馈意见。
5.ThedefinitionofCMMI
CMMI:
capabilitymaturitymodelintegration.软件能力成熟度模型集成。
帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力,从而能按时地、不超预算地开发出高质量的软件。
只要集中精力持续努力去建立有效的软件工程过程的基础结构,不断进行管理的实践和过程的改进,就可以克服软件开发中的困难。
CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。
6.ThelevelsofCMMI
0:
不完全集。
1:
已执行级。
2:
已管理级。
3:
已定义级。
4:
已定量管理级。
5:
优先级。
7.PSP:
personalsoftwareprocess:
强调对产品及产品质量的的个人测量。
五个框架:
测划;高策设计;高层设计评审;开发;后验。
8.TSP:
teamsoftwareprocess团队软件过程建立一个能够“自我管理”的团队,团队能自我组织进行高质量的软件开发。
团队软件过程:
①建立自我管理团队来评划跟踪其工作,确定目标,建立团队自己的过程和计划。
②指示管理人员如何指导激励其团队,并保持团队的嘴角表现。
③使CMM第五位行为常规化,并以此约束员工。
④协商成熟度的软件组织提供改进制度⑤协助大学传授工业级团队技能。
第三章:
1.Thefunctionofprocessmodels
为活动提供稳定性、控制和有组织性。
为了改变软件开发的混乱状况,是软件开发更加有序。
2.Understandthesignification(意义)andcharacteristics(特点)oftheprocessmodels
3.Thewaterfallmodel
瀑布模型(经典生命周期):
提出一个系统的顺序的软件开发方法,从用户需求规格说明开始,通过规划,建模,构建和部署的过程,最终提供一个完整的软件并提供持续的技术支持。
瀑布模型适用于:
①问题很好理解、需求明确②交付日期明确实际③工作能够采用线性的方式完成。
4.Incrementalmodel(增量模型)
以迭代的方式运用瀑布模型,每个阶段运用线性序列。
增量模型可以规避技术风险。
5.RADmodel
RapidApplicationDevelopment(快速应用程序开发):
是一种侧重于短暂的开发周期的增量软件过程模型。
6.Prototyping(原型模式)
解决:
客户提出软件的基本功能但没有详细定义输入、处理、和输出需求。
开发人员对算法的效率、操作系统的兼容性和人机交互的形式等情况不确定。
他可以作为一项技术;也可以作为一个系统。
适用:
客户提出了软件的基本功能,没有详细定义输入处理和输出需求,开发人员对算法效率、OS的兼容性不确定。
7.SpiralModel(螺旋模型)
是一种演进式软件过程模型,它结合了原型的迭代性质和瀑布模型的系统性和可控制性的特点。
它具有快速开发越来越完善软件版本的潜力。
8.Componentbaseddevelopment(基于构件开发模型)
具有许多螺旋模型的特点,本质上是演化模型,需要以迭代方式构建软件,它能够使软件复用。
9.Object-orientedprocessmodels(形式化方法模型)
主要活动是生成计算机软件形式化的数学规格说明,能够使软件工程师改正一些错误。
第七章:
1.Thedefinitionofrequirementsengineering
他必须适应过程、项目、产品、和工作人员的要求。
是一个软件工程动作,开始于沟通并持续到建模。
他在设计和建造之间建立起联系的桥梁。
2.Requirementsengineeringtasks
过程活动:
起始、导出、精化、协商、规格说明、确认
3.Initialingtherequirementsengineeringprocess(启动需求工程过程)
4.Elicitingrequirements(导出需求)
5.Developinguser-case(开发用例)
第八章:
1.Thethreegoalsofanalysismodeling
①描述客户需要什么②为软件设计奠定基础③定义在软件完成后可以被确认的一组需求。
2.Theconceptsofanalysismodeling
分析模型是一组模型,是系统的第一个技术表示。
其所有元素都可以直接跟踪到设计模型。
软件域分析是识别、分析和详细说明来自某个特定的应用领域的公共需求,特别是在那些应用领域很多个项目重复使用的。
3.Theprinciplesofmodeling
①结构化分析:
考虑数据和处理的分析建模方式②面向对象的分析:
关注于定义类和影响客户需求的类之间的协作方式。
4.E-Rdiagram
实体关系图形象化的;表示这些对象关系对。
用来表示数据对象及其关系。
同时识别一组基本元素:
市局对象,属性,关系,以及各种类型的指示符。
5.Datadictionary
6.Use-CasesinUML:
use-casediagram/activitydiagram/statediagram/classdiagram
7.Creatingabehavioralmodel
第九章:
1.abstraction,architecture,patterns,modularity,informationhiding,functionalindependence,refinement,refactoring,designclass
抽象:
分为过程抽象和数据抽象,过程抽象是指具有明确和优先功能的指令序列。
数据抽象是描述数据对象的冠名数据集合。
体系结构:
程序构建的结构或组织、这些构件交互的形式以及这些构件所用数据的结构。
模式:
描述了在某个特定的场景与可能影响模式应用和使用方式的影响力中解决某个特定的设计问题的设计结构。
模式化:
软件被划分为独立命名的、可寻址的构件(有时可称为是模块)把这些构件集成到一起可以满足问题的需求。
信息隐蔽:
要求模块应该详细说明且精心设计以求在某个模块中包含的信息(算法和数据)不被不需要这些信息的其他模块访问。
通过定义一系列独立的模块,独立模型相互之间只交流实现软件功能所必须的那些信息。
功能独立:
是模块化、抽象概念和信息隐蔽的直接结果,是优秀设计的关键。
求精:
是一种自顶向下的设计策略,是一个细化的过程。
通过连续精化层次结构的程序细节来实现程序的开发。
重构:
是一种重新组织的技术,可以简化构件的设计(或代码)而无需改变其功能或行为。
设计类:
通过提供设计细节精化分析类,这些设计细节将促成类的实现,创建一组新的设计类,该设计类实现了软件的基础设施以支持业务解决方案。
分为:
用户接口类、业务域类、过程类、持久类、系统类。
2.theconceptsofthedesignprocess:
DataDesign,ArchitecturalDesign,InterfaceDesign,Component-LevelDesign
数据设计:
创建在高抽象级上表示的数据模型和信息模型。
体系结构设计:
等效于房屋的平面图提供了软件的整体视图。
接口设计:
告诉我们信息如何流入和流出系统以及被定义为体系结构一部分的构件之间是如何通信的。
(三个重要元素:
用户界面-UI;外部接口;各种设计构件之间的内部接口。
)
构件级设计:
完整的描述了每个软件构件的内部细节,(为此构件级设计为所有本地数据对象定义数据结构,为所有在构件内发生的处理定义算法细节,并定义允许访问所有构件操作的接口。
)
3.4characteristicsofawell-formeddesignclass:
Completeandsufficient,Primitiveness,Highcohesion,Lowcoupling
完整和充分,原始性,高凝聚力,低耦合
第十章:
1.Thedefinitionofarchitectural
分析设计在满足规定需求方面的有效性,在设计变更相对容易的阶段,考虑体结构可能的选择方案,降低与软件构造相关联的风险。
2.ThegoalofDataDesignintheArchitecturalDesign
把在分析模型中定义的数据对象转化成软件构件级的数据结构,并且在必要时转化为应用程序级的数据库体系结构。
3.(10.3)components(构件),connectors(连接器),constraints(约束),semanticmodels(语义模型);Data-centered(数据中心),Data-flow(数据流),Callandreturn(调用返回),Object-oriented(面向对象),Layeredarchitectures(层次体系结构)
构件:
完成系统需要的某种功能;连接器:
使构件间实现通信合作和协调;约束:
定义构件如何集成一个系统。
语义模型:
使设计者通过分析系统的构成成分的性质来理解系统的整体性质。
4.ArchitecturalPattern:
concurrency,persistence,distribution
体系结构模式---并发性:
应用程序以一种并行的方式操作多个任务。
持久性:
数据从创建它的进程执行以来一直存在。
分布性:
系统或系统中构件在一个分布的环境中相互通信的方式。
5.Architecturalcomplexity:
dependencies
第十一章:
Whatisacomponent:
构件是计算机软件中的一个模块化的结构快,系统中某一定型化的、可配置的和可替换的部件,该部件封装了实现并暴漏一系列接口。
1.OOview(面向对象的观点)
①传统观点②过程相关的观点
2.Conventionalview常规观点
3.Basicdesignprinciples基本设计原则
①开关原则:
模块应该对外延具有开放性,对修改具有封闭性。
②Liskov替换原则:
子类可以替换它们的基类。
③依赖倒置原则:
依赖于抽象,而非具体实现。
④接口分离原则:
多个用户专用接口比一个通用接口要好。
⑤发布复用等价性原则:
复用的粒度就是发布的粒度。
⑥公同封装原则:
一同变更的类应该合在一起。
⑦共同复用原则:
不能一起复用的类不能被分到一组。
4.Cohesion&Coupling内聚耦合
内聚性(按级别排序):
功能、分层、通信、顺序、过程、暂时、使用内聚。
耦合性;内容、共用、控制、印记、数据、例程调用、类型使用、包含或者导入、外部耦合。
5.ThestepsofOOComponent-levelDesign实施构件级设计的步骤:
①标示出所有与问题域相对应的设计类②确定所有与基础设施域相对应的设计类③细化所有不能作为复用构件的设计类④说明持久数据源(数据库和文件)并确定管理数据源所需要的类⑤并发并且细化类或构件的行为表示⑥细化部署图以提供额外的实现细节⑦考虑每一个构件级设计表示,并且时刻考虑其他选择。
6.flowdiagram流程图
7.decisiontable表格式设计
十二章:
1.TheGoldenRules
①置用户于控制之下②较少用户的记忆负担③保持界面一致
2.useranalysis,taskandworkenvironmentanalysis,Interfacedesign,Interfacevalidation
用户分许、任务和环境分析、界面设计、界面确认、
3.Stepsofinterfaceanalysis
4.InterfacedesignSteps
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 范围