第一篇：软件工程重点总结
软件工程复习重点总结
1.(P-2)
Analysis:
decompose a large problem into smaller, understandable pieces，(一个大问题分解成更小的、可以理解部分)abstraction is the key Synthesis:
build(compose)software from smaller building blocks,(生成撰写软件从较小的构造块)composition is challenging 2Software Engineering Solving Problems(continued)：(P-4)
method： refers to a formal procedure（指的是一个正式的程序）
tool：an instrument or automated system for accomplishing something in a better way procedure（过程）：a combination of tools and techniques to produce a product（工具和技术来生产一种产品的组合）
paradigm（范例）：philosophy or approach for building a product 3.(P-6)
A fault: occurs when a human makes a mistake, called an error, in performing some software activities（在执行某些软件活动）;
A failure: is a departure（偏差）from the system’s required behaviour;
Error can lead to fault；fault can lead to failure。4.participates in a project：(P-15)
Customer:
the company, organization, or person who pays for the software system Developer:
the company, organization, or person who is building the software system User: the person or people who will actually use the system
5.Activities and objects(P-16)– An activity is an event initiated by a trigger（活动是由一个触发器的事件）– Objects or entities are the elements involved in the activities（Objects 或实体是要素参与活动的）
6.Relationships and the system boundaries(P-17)– A relationship defines the interaction among entities and activities（A 关系定义实体和活动的相互作用）
– System boundaries determine the origin of input and destinations of the output（边界确定输入的来源与目的地的输出）
7.a system as a collection of things :(P-17)a set of entities(一组实体), a set of activities , a description of the relationships among entities and activities and a definition of the system.8.The development of software includes the following activities(P-24)• • • • Requirements analysis and definition System design Program design Writing the programs • Unit testing • Integration testing • System testing • System delivery • Maintenance 9.developer roles(P-26)Analyst
Designer
Programmer
Tester
Trainer 10.(P-45)A process: a series of steps involving activities, constrains, and resources that produce an intended output of some kind（一系列步骤涉及活动，受到了限制，及资源，产生一预期的输出）
A process involves a set of tools and techniques 11.(P-46)
Software life cycle:
Implementation ,delivery ,use, and maintenance（实施、发布、使用及维修）
When a process involves building a software, the process may be referred to as software life cycle – – – – – – – Requirements analysis and definition System(architecture)design Program(detailed/procedural)design Writing programs(coding/implementation)Testing: unit, integration, system System delivery(deployment)Maintenance
12．software process models：（P-48）
Waterfall model
V model Prototyping model(原型化)Operational specification model Transformational model（转化）
Phased development（阶段化开发）: increments and iterations（反复递增）Spiral model（螺旋模型）Agile methods（敏捷方法）
13.Prototyping is useful for verification(确认)and validation（验证）（P-51）14.Elements of a process are viewed in terms of seven types（P-64）
Activity – Sequence – Process model 过程模型 – – – – Resource Control Policy Organization
15.Project schedule(P-83)Describes the software-development cycle for a particular project by
enumerating the phases or stages of the project(枚举阶段或项目的阶段)
breaking each phase into discrete tasks or activities to be completed(每个阶段分成离散任务或活动，以完成)
Portrays(描绘)the interactions(相互影响)among the activities and estimates(估算)the times that each task or activity will take
16.Activity and milestone(P-83)Activity: takes place over a period of time
Milestone: completion of an activity--a particular point in time
17.Critical Path Method(CPM)(P--87)
见作业
18.Key activities requiring personnel（P-95）
requirements analysis system design program design program implementation（实现，执行）testing training maintenance
quality assurance（保证）
19.risk（P—119）
is an unwanted event that has negative consequences(消极结果)
20.Risk impact(影响):（P--120）
the loss associated with the event与该事件关联的损失
Risk probability(概率):
the likelihood that the event will occur事件发生的可能性
Risk control(控制):
the degree to which we can change the outcome我们可以更改结果的程度
Quantify(量化)the effect of risks：
Risk exposure =(risk probability)x(risk impact)
21.Risk management：（P--121）
risk assessment（评估）
risk control
22.（P--143）
A requirement：
is an expression of desired behaviour是所需行为的表达式 A requirement deals with ：
objects or entities，the states they can be in，and the functions that are performed to change states or object characteristics
23.Process for Capturing Requirements（P--144）
Elicitation（引入）
Analysis
Specification Validation（验证）
////构成了software requirements specification(说明书)
24.functional requirement（P---148）
describes required behavior in terms of required activitie描述所需的活动所需的行为s Quality requirement or nonfunctional requirement describes some quality characteristic that the software must possess(拥有)
Design constraint(约束):
a design decision such as choice of platform or interface components设计的平台或界面组件如选择决策 Process constraint: a restriction on the techniques or resources that can be used to build the system 对技术或可用于构建系统的资源限制
25.Prioritization might separate requirements into three categories（P--152）
Essential(基本): absolutely must be met绝对需要满足的需求
Desirable(合意): highly desirable but not necessary非常理想，但不必须的 Optional(可选): possible but could be eliminated但可能被淘汰
26.Requirements definition:（P--154）
a complete listing of everything the customer wants to achieve完整列表的客户希望实现的一切
Describing the entities in the environment where the system will be installed
描述在将安装在系统环境中的实体 Requirements specification:
restates（重申）the requirements as a specification of how the proposed（提出）system shall behave
27.ER diagram have three core constructs（P--158）ER 图表有三个核心构造
An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors描述为一个的矩形表示一个实际
的对象的集合 具有公共属性和行为
A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying（指定）the type of relationship描述为一个两个实体之间的边缘
An attribute: an annotation(注解)on an entity that describes data or properties associated with the entity描述数据或与该实体相关联的属性的实体上的注释
28.（P--172）
A data-flow diagram(DFD)models functionality and the flow of data from one function to another数据流关系图 DFD 模型的功能和数据到另一个函数的流
– A buble represents a process一个 buble 表示一个流程 – An arrow represents data flow一个箭头表示数据流量
– A data store: a formal repository(仓库)or database of information –
Rectangles represent actors: entities that provide input data or receive the output result矩形表示参与者： 实体提供输入的数据或接收输出结果
–
29.(P--223)Design: is the creative process of transforming the problem into a solution The description of a solution is also known as design 是创造过程的问题转化为解决方案的描述称为设计
30.Design is a two-part interactive process(P—224)– Conceptual design(system design)(概念性设计)– Technical design(技术性设计)
–
31.(P—228)Modules or components: 组件
composite parts of design A system is modular when
– each activity of the system is performed by exactly one component活动的系统由一个组件执行
– inputs and outputs of each component are well-defined
• all inputs to it are essential to its function输入其功能至关重要
• all outputs are produced by one of its actions输出由其动作之一制作
32.Architectural Styles and Strategies Three Design Levels:(P—229)
Architecture（系统结构）
Code design
Executable design（执行设计）
33.Architectural Styles and Strategies Design Styles（P—230）
Pipes and filters(管道/过滤器)Object-oriented design Implicit invocation(隐式调用)Layering（分层设计）Repositories(数据仓库)Interpreters(解释器)Process control(过程控制)Client-server(客户/服务器)
34.Component independence（P--248）
Coupling(耦合度)Cohesion(内聚度)Highly coupled when there is a great deal of dependencies Loosely coupled components have some dependency, but the interconnections among components are weak（大多数采用松散）
Uncoupled components have no interconnections at all
35.We can measure coupling along a range of dependence（P--249）
Characteristics of Good Design Coupling: Types of Coupling
Content(内容)coupling
Common(公共)coupling Control(控制)coupling Stamp(标记)coupling Data(数据)coupling 36.Exceptions can be handled in one of three ways：（P—255）异常处理
– Retry(重试)– Correct(更正)– Report(报告)
37.program component involves at least three major aspect:(P---340)
Control structures ,algorithms,and data structure 38.making the codeefficiency(效率)may have hidden costs(代价)(P--342)– cost to write the code faster – cost to test the code – cost to understand the code – cost to modify the code
39.Software Faults and Failures types of Faults(P--367)软件故障及故障的类型的故障
Algorithmic fault算法
Computation and precision fault 计算和精度 Documentation fault Stress or overload faults Capacity or boundary faults 容量边界 Timing or coordination faults(协调)Throughput(吞吐量)or Performance faults Recovery fault 恢复故障
Hardware and system software fault Standards and procedures fault
40.Testing Organization（P—371.）
Module testing, component testing, or unit testing(单元测试)Integration testing(集成测试)The next step is ensuring that the interfaces among the components are defined and handled properly.Performance testing(性能测试)Compares the system with the remainder of these software an hardware requirements.41.Testing steps（P--372）
42.Integration Testing集成测试（P--390）具体实例见作业
Bottom-up(自底向上)
Merging components to test the larger system
Top-down(自顶向下)
Big-bang(大棒)
Sandwich testing(多层结构测试)
Modified top-down(改性自上而下)
Modified sandwich(改性多层结构测试)
43.Principles of System Testing Regression Testing Steps（P—425）系统测试回归测试步骤的原则
• Inserting the new code • Testing functions known to be affected by the new code • Testing essential function of m to verify that they still work properly整体 • Continuing function testing m + 1
44.Types of Performance Tests（P--436）性能测试
Stress tests(压力)Volume tests(容量)Configuration tests(配置)Compatibility tests(兼容)
Regression tests(回归)Security tests(安全)Timing tests(响应时间)Environmental tests(环境)Quality tests(质量)Recovery tests(恢复)Maintenance tests(可维护性)Documentation tests(文档)Human factors(usability)tests(使用)
45.Software reliability:
operating without failure under given condition for a given time interval 无故障下经营给予指定的时间间隔内的条件 Software availability:
operating successfully according to specification at a given point in time 成功经营，依法规范在指定点的时间 Software maintainability:
for a given condition of use, a maintenance activity can be carried out within stated time interval, procedures and resources 为给定的使用条件，维护活动可以内进行既定的时差 过程资源
注意：作业是重点，必考！这个翻译（长字段的）仅供参考，要结合软件工程的角度加以分析理解！
第二篇：软件工程重点总结
1、什么是软件危机？
软件危机泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
2、软件危机的主要表现
（1）对软件开发成本和进度的估计常常很不准确
（2）用户对“已完成的”软件系统不满意现象经常发生
（3）软件产品质量往往靠不住
（4）软件往往是不可维护的（5）软件通常没有适当的文档资料
（6）软件成本在计算机系统总成本中所占的比例逐年上升
（7）软件开发生产效率提高的速度，远远跟不上计算机应用迅速普及深入的趋势
3、软件危机产生的原因
(1)来自软件自身的特点
是软件系统的逻辑部件，缺乏可见性，管理和控制软件开发过程相当困难；规模庞大、复杂，修改、维护困难。
(2)软件开发与维护的方法不当
忽视需求分析；认为软件开发等于程序编写；轻视软件维护。
4、如何消除软件危机？
（1）对计算机软件有一个正确的认识(软件≠程序）
（2）必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目
（3）推广使用在实践中总结出来的开发软件的成功技术和方法
（4）开发和使用更好的软件工具
5、面向对象的三种模型：对象模型 动态模型 功能模型 P2166、模块独立性的两个标准：耦合 内聚 P977、软件测试方法：黑盒测试 白盒测试 P1518、软件调试的途径：蛮干法 回溯法 原因排除法 P1789、可行性研究：确定问题是否有行得通的解决办法 P3510、需求分析：准确地回答“系统必须干什么”这个问题 P5511、软件成分的重用级别：代码重用 设计结果重用 分析结果重用
可被重用的软件成分有：项目计划，成本估计，体系结构，需求模型和规格说明，设计，源代码，用户文档和技术文档，用户界面，数据，测试用例。
12、软件可靠性的定义：软件在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。
软件可用性的定义：程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。可靠性与可用性之间的主要差别是，可靠性意味着在0到t这段时间内系统没有失效，而可用性只意味着在时刻t，系统是正常运行的。P17913、白盒测试：逻辑覆盖 控制结构测试 P162
黑盒测试：等价划分 边界值分析 调试 P171
环形复杂度的计算：复杂度=边数-点数+2P13714、面向对象的3个子模式：对象模型 动态模型 功能模型 P232
对象模型的5个层次：主题层 类与对象层 结构层 属性层 服务层 P23215、软件定义阶段干什么事：确定软件开发工程必须完成的总目标；确定工程的可行性；导
出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该工程需要的资源和成本，并制定工程进度表。
16、类和对象的关系：类是具有相同数据和相同操作的一组相似对象的定义，也就是说，类
是对具有相同属性和行为的一个或多个对象的描述。类是支持继承的抽象数据类型，而对象就是类的实例。P21117、UML有哪些图？ P2171、用例图：展示系统外部的各类执行者与系统提供的各种用例之间的关系
2、类图：展示系统中类的静态结构
3、对象图：是类图的一种实例化图
4、状态图：描述一类对象具有的所有可能的状态及其转移关系
5、时序图：展示对象之间的一种动态协作关系
6、合作图：从另一个角度展示对象之间的动态协作关系
7、活动图：展示系统中各种活动的执行流程
8、构件图：展示程序代码的物理结构
9、配置图：展示软件在硬件环境中的配置关系
18、能力成熟度模型（CMM）：初始级 可重复级 已定义级 已管理级 优化级 P31119、什么是软件生命周期模型?试比较瀑布模型、快速原型模型、增量模型和螺旋模型的优
缺点，说明每种模型的适用范围。P33习题1.720、软件的可维护性定义：维护人员理解、改正、改动或改进这个软件的难易程度。决定可维护性的因素：可理解性 可测试性 可修改性 可移植性 可重用性。
文档是影响可维护性的决定性因素。P19521、如何评价软件规格说明书？
从四个方面：一致性 完整性 现实性 有效性 P7022、层次图 P10223、深度：软件结构中控制的层数 P100
宽度：软件结构中同一个层次上的总数的最大值
扇出：一个模块直接控制（调用）的模块数目
散入：一个模块被多少个上级模块直接调用
24、面向数据流的设计方法 P10425、类构件的重用方式：实例重用 继承重用 多态重用
1.什么是软件工程？软件工程和计算机科学有何区别？
软件工程是指导计算机软件开发和维护的一门工程学科。
计算机科学研究的是构成计算机和软件系统基础的有关理论和方法，而软件工程则是研究软件制作中的实际问题。
2、流程图与数据流图有什么主要区别？
（1）数据流图（date flow diagram , DFD），是SA方法中用于表示系统逻辑模型的一种工具，它以图形的方式描绘数据在系统中流动和处理的过程，由于它只反映系统必须完成的逻辑功能，所以它是一种功能模型，是从数据的角度来描述一个系统的；而流程图则是从对数据加工的角度来描述系统的；
（2）数据流图中的箭头是数据流，而流程图中的箭头则是控制流,它表达的是程序执行的次序；
（3）数据流图适合于宏观地分析一个组织业务概况,而程序流程图只适合于描述系统中某个加工的执行细节。
（4）数据流程图应该重点描述了数据加工的过程，主要是模块内部，数据流图则是描述模块之间的关系。
3．软件需求分析的任务是什么？有哪些主要步骤？
需求分析的基本任务是深入描述软件的功能和性能、确定软件设计的约束和软件同其它系统元素的接口细节、定义软件的其它有效性需求，总之，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。
主要步骤：
1.问题识别
(1)功能需求：明确所开发的软件必须具备什么样的功能。
(2)性能需求：明确待开发的软件的技术性能指标。
(3)环境需求：明确软件运行时所需要的软、硬件的要求。
(4)用户界面需求：明确人机交互方式、输入输出数据格式。
2.分析与综合，导出软件的逻辑模型
分析人员对获取的需求，进行一致性的分析检查，在分析、综合中逐步细化软件功能，划分成各个子功能。用图文结合的形式，建立起新系统的逻辑模型。
3.编写文档
(1)编写“需求规格说明书”，把双方共同的理解与分析结果用规范的方式描述出来，作为今后各项工作的基础。
(2)编写初步用户使用手册，着重反映被开发软件的用户功能界面和用户使用的具体要求，用户手册能强制分析人员从用户使用的观点考虑软件。
(3)编写确认测试计划，作为今后确认和验收的依据。
(4)修改完善软件开发计划。在需求分析阶段对待开发的系统有了更进一步的了解，所以能更准确地估计开发成本、进度及资源要求，因此对原计划要进行适当修正。
4．简述结构化分析、设计的要点：
结构化分析方法适合于数据处理类型软件的需求分析。
其要点是“自顶向下” 地开发系统,由整体到各组成部分,由表及里,由抽象到具体,逐步求精.(1)模块化
(2)由顶向下,逐步求精.(3)上层模块分解为下层模块,有三种不同的结构形式,即顺序结构,选择结构和循环结构.5．数据字典包含哪些主要内容？
数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分.据字典内容包括：
数据库中所有模式对象的信息，如表、视图、簇、及索引等。
分配多少空间，当前使用了多少空间等。
列的缺省值。
约束信息的完整性。
用户的名字。
用户及角色被授予的权限。
用户访问或使用的审计信息。
其它产生的数据库信息。
6．软件测试的目标是什么，有哪几种主要有测试方法？
软件测试的目标：
(1)测试是为了发现程序中的错误而执行程序的过程；
(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
(3)成功的测试是发现了至今为止尚未发现的错误的测试。
软件测试的方法有黑盒测试、白盒测试。
7．白盒测试主要有哪些覆盖？
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、点覆盖、边覆盖、路径覆盖
8、选择一种程序设计语言的主要有哪些依据？
为了使程序容易测试和维护以减少生命周期的总成本，选用的高级语言应该有理想的模块化机制，以及可读性好的控制结构和数据结构；为了便于调试和提高软件可靠性，语言特点应该使编译程序能够尽可能多地发现程序中的错误；为了降低软件开发和维护的成本，选用的语言应该有良好的独立编译机制。上述这些要求是选择语言的理想标准，但是在实际选用语言时不能仅仅考虑理论上的标准，还必须同时考虑实用方面的各种限制。
(1)系统用户的要求
(2)可以使用的编译程序
(3)可以得到的软件工具
(4)系统规模
(5)程序员的知识
(6)软件可移植性要求
(7)软件的应用领域
9．软件的维护的目标是什么，有哪几种维护类型？
纠正在使用过程中暴露出来的错误而进行的改进性维护，适应外部环境的变化而进行的适应性维护，改进原有的软件而进行的完善性维护，以及改进将来的可维护性和可靠性而进行的预防性维护。
软件维护主要划分为纠错性维护、适应性维护和完善性维护。
(1)纠错性维护。由于前期的测试不可能揭露软件系统中所有潜在的错误，用户在使用软件时仍将会遇到错误，诊断和改正这些错误的过程称为纠错性维护。
(2)适应性维护。由于新的硬件设备不断推出，操作系统和编译系统也不断地升级，为了使软件能适应新的环境而引起的程序修改和扩充活动称为适应性维护。
(3)完善性维护。在软件的正常使用过程中，用户还会不断地提出新的需求。为了满足用户新的需求而增加软件功能的活动称为完善性维护。
10．简述提高软件质量的主要措施。
复审：是在软件生命周期每个阶段结束之前，都采用一定的标准对该段产生的软件配置成分进行严格的正式或非正式的检测。
复查：是检查已有的材料，以断定在软件生命周期某个阶段的工作是否能够开始或继续。管理复审：是向开发组织或使用部门的管理人员提供有关项目的总体状况、成本和进度等方面的情况，以便他们从管理角度对开发工作进行审查。
测试：包括测试计划、测试过程和测试结果3个阶段。
11．面向对象如何实现模块独立性，其偶合和内聚的含义是什么？
因为对象是由数据及可以对这些数据施加的操作所组成的统一体，而且对象是以数据为中心的，操作围绕对其数据所需做的处理来设置，没有无关的操作。因此，对象内部各种元素彼此结合得很紧密。内聚性相当强，由于完成对象所需要的元素（数据和方法）基本上都被封装在对象内部，它与外界的联系自然就比较少。因此，对象之间的耦合通常比较松。总之，面向对象使用对象、类、继承和消息的方法，既使用类和继承等机制，而且对象之间仅能通过传递消息实现彼此通信来实现模块的独立性。
12．面向对象和面向过程软件工程有哪些区别？
（1）面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。（2）面向过程是把一件事一项工程分解成为一个个小的功能,用一个个函数来实现.面向对象是把事情看成是一个个小的对象组成的,或者说一个个小部分组成的,这些对象之间的相互关系,构成了整个项目.在面向对象的思想中，万物皆对象。而“类”，就是对象的抽象或者说是概括。
13.简述对象、类、消息、方法的基本概念。
(1)对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。
(2)类是具有相同或相似性质的对象的抽象。对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象。类具有属性，它是对象的状态的抽象，用数据结构来描述类的属性。类具有操作，它是对象的行为的抽象，用操作名和实现该操作的方法来描述。
(3)对象之间进行通信的结构叫做消息。在对象的操作中，当一个消息发送给某个对象时，消息包含接收对象去执行某种操作的信息。发送一条消息至少要包括说明接受消息的对象名、发送给该对象的消息名（即对象名、方法名）。一般还要对参数加以说明，参数可以是认识该消息的对象所知道的变量名，或者是所有对象都知道的全局变量名。
(4)类中操作的实现过程叫做方法，一个方法有方法名、参数、方法体。
14．简述面向对象分析设计的三个模型。
答：三个模型：对象模型、动态模型、功能模型
（1）对象模型描述系统的静态结构，包括类和对象，它们的属性和操作，以及它们之间的关系。构造对象模型的目的在于找出与应用程序密切相关的概念。对象模型用包含对象及对象的关系图表示。
（2）动态模型着重于系统的控制逻辑，考察在任何时候对象及其关系的改变，描述这些涉及时序和改变的状态。动态模型包括状态图和事件跟踪图。状态图是一个状态和事件的网络，侧重于描述每一类对象的动态行为。事件跟踪图则侧重于说明系统执行过程中的一个特点“场景”，也叫做脚本(scenarios)，是完成系统某个功能的一个事件序列。脚本通常起始于一个系统外部的输入事件，结束于一个系统外部的输出事件。
（3）功能模型着重于系统内部数据的传送和处理。功能模型表明，通过计算，从输出数据能得到什么样的输出数据，但不考虑参加计算的数据按什么时序执行。功能模型由多个数据流图组成，它们指明从外部输出，通过操作和内部存储，直到外部输出的整个数据流情况。功能模型还包括了对象模型内部数据间的限制。功能模型中的数据流图往往形成一个层次结构，一个数据流图的过程可以由下一层的数据流图作进一步的说明。
第三篇：软件工程重点总结
软件的定义：软件是计算机系统中与硬件相互依存的另一部分，软件包括程序、数据及其相关文档的完整集合。
在结构化程序设计时代，程序的最小单位是向对象程序设计时代，程序的最小单位是类，在类中封装了相关的数据及指令代码。软件的特性：形态特性、智能特性、开发特特性、维护特性、废弃特性、应用特性。软件的分类：系统软件、应用软件、支撑软 软件危机的表现：软件开发周期长、成本高、软件危机发生的原因：（1）缺乏软件开发的工作的计划很难制定。（2）软件人员与用户的交流存在障碍。（3）软件开发过程不规范，缺少方法论和规范的指导，开发人员各自为战，缺少整体的规划和配合，不重视文字资料工作，软件难以维护。（4）随着软件规模的增大，其复杂性往往会呈指数级升高。（5）缺少有效的软件测评手段，提高用户的软件质量差，在运行中暴露出大量的问题，轻者影响系统的正常使用，重者发生事故，甚至造成生命财产的重大损失。
首次提出“软件工程”的概念的时间是1968年。
按工程化的原则和方法组织软件开发工作是 软件工程的定义：软件工程是指导软件开发和维护的工程性学科，它以计算机科学理论和其他相关学科的理论为指导，采用工程化的概念、原理、技术和方法进行软件的开发和维护，把经过时间考验而证明是正确的管理技术和当前能够得到的最好的技术方法结合起来，以较少的代价获得高质量的软件并维护它。
软件工程的目标是运用先进的软件开发技术 衡量软件的质量的六个特性：功能性、可靠
软件生存期的三个时期：软件定义、软件开定义时期的主要任务是解决“做什么”的问地满足用户的需要。
开发过程中的典型文档包括：软件需求规格计说明书、用户手册。
各个阶段所要完成的基本任务：问题定义与可行性研究、需求分析、软件设计、程序编码和单元测试、集成测试和系统测试、软件运行和维护。
典型的软件生存期模型包括瀑布模型、原型模型、增量模型、螺旋模型等（喷泉模型）。
瀑布模型的特点：1）阶段间具有顺序性和依赖性。2）推迟实现的观点。3）质量保证的观点。
瀑布模型的优点：①可强迫开发人员采用规范化的方法。②严格地规定了每个阶段必须提交的文档。③要求每个阶段交出的所有产品都必须是经过验证（评审）的。
瀑布模型的缺点：①由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异，就会发生这种情况。②瀑布模型只适用于项目开始时需求已确定的情况。
快速原型模型的优点：①有助于满足用户的互而得到验证，据此产生的规格说明文档能够正确地描述用户需求。③软件产品的开发基本上是按线性顺序进行。④因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。⑤开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。⑥快速原型的本质是“快速”。开发人员应该尽可能快地创造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型可以抛弃，当然也可以在原型的基础上进行开发。
增量模型的优点：①能够在较短的时间内向构件交付之日起，用户就能做一些有用的工作。②逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少全新的软件可能给用户组织带来的冲击。③项目失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件将能够成功地交付给客户。④优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。一个必然的事实是：最重要的系统服务将接受最多的测试。这意味着系统最重要的部分一般不会遭遇失败。
螺旋模型的优点：①对可选方案和约束条件软件质量作为软件开发的一个重要目标。②减少了过多测试或测试不足所带来的风险。③在螺旋模型中，维护只是模型的另一个周期，因而在维护和开发之间并没有本质区别。螺旋模型的缺点：螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还以为一切正常。
方法学：通常把在软件生命周期全过程中使用的一整套技术的集合称为方法学，也称为范型。
软件工程方法学三个要素：方法、工具和过传统方法也称为生命周期方法或结构化范项任务。这种方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地逐步完成每个阶段的任务。每个阶段的开始和结束都有严格的标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。在每个阶段结束之前都必须进行正式评审，评审通过之后这个阶段才结束，否则就需要返工，返工之后还要评审。评审的一条主要标准就是每个阶段都应该交出高质量的工作产品，其中，前面阶段的工作产品主要是文档，如需求规格说明书、软件设计说明书等。
面向对象方法的基本原则，是尽量模拟人类习惯的思维方式，使开发软件的方法和过程尽可能接近人类认识问题和解决问题的方法与过程，从而使描述问题的问题空间与其解空间在结构上尽可能一致。
封装的定义：封装是一种信息隐蔽技术，就作封装在一起。①清楚的边界②接口③受保护的内部实现
软件需求分析阶段的主要工作产品有“软件需求规格说明书”和“初步的用户手册” 需求获取的主要任务是与客户或用户沟通，想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作
需求获取产生困难的原因：系统的目标或范围问题，需求不准确性问题，需求的易变问题
需求获取活动需解决的问题：1.发现和分析问题，并分析问题的原因/结果关系2.与用户进行各种方式的交流，并使用调查研究方法收集信息3.按照三个成分即数据、过程和接口观察问题的不同侧面4.将获取的需求文档化，形式有例图、决策表、决策树等 软件需求分析阶段的工作4个步骤：需求获取，需求分析，需求定义，需求验证
数据字典以词条方式定义在数据模型、功能息的特性，给出它们的准确定义
设计是技术世界和人类的目标世界结合在一
软件设计的原则：(1)分而治之(2)模块独立(4)复用性设计(5)灵活性设计
模块独立性，是指软件系统中每个模块只涉
复用是指同一事物不做修改或稍加修改就可质量及生产率的重要方法，软件复用已不再局限于软件代码的复用，复用范围已经扩展到软件开发的各个阶段，包括需求模型和规格说明、设计模型、文档、测试用例等复用。模块间的耦合和内聚两个准则来度量模块独的紧密程度）的度量，内聚是模块功能强度（一个模块内部各个元素彼此结合的紧密程度）的度量。模块独立性比较强的模块应是高度内聚、松散耦合的模块。
在最高的抽象层次上，可以使用问题所处环境的语言概括地描述问题的解决方法：在较低的抽象层次上，采用更过程化的方法，将面向问题的术语和面向实现的术语结合起来描述问题的解法；在最低的抽象层次，则用某种程序设计语言来描述问题的解法。从工商管理的角度，可以将软件设计分为两个阶段：概念设计阶段和详细设计阶段。结构图是精确模块结构的图形表示工具。清联系。(1)模块的条用关系和接口(2)模块间的信息传递(3)辅助符号(4)结构图的形态特征(结构图的深度、宽度、扇入和扇出)过程描述工具有：图形工具、表格工具、语
自顶向下、逐步求精方法的优点：1)自顶向遍规律，可提高软件开发的成功率和生产率2)用先全局后局部、先整体后细节、先抽象后具体的逐步求精的过程开发出来的程序具有清晰地层次结构，因此程序更容易阅读和理解3)程序自顶向下，逐步细化，分解成树形结构4)程序清晰和模块化，使得在修改和重新设计一个软件时，可复用的代码量最大5)程序的逻辑结构清晰，有利于程序正确性证明6)每一步工作尽在上层结点的基础上做不多的设计扩展，便于检查7)有利于设计的分工和组织工作
软件测试：在软件投入生产性运行之前，对复审，是软件质量控制的关键步骤。软件测试是为了发现错误而执行程序的过程。
软件测试的目的：①测试是程序的执行过程，目的在于发现错误；②一个好的测试用例在于能发现至今未发现的错误；③一个成功的测试是发现了至今未发现的错误的测试。软件测试的目标是想以最少的时间和人力系 软件测试的原则：
1、尽早地和不断地进行软之对应的预期输出结果这两部分组成；
3、程序员应避免检查自己的程序。测试过程需要三类输入：软件配置、测试配控制流图是描述程序的控制流的一种图示方
环路复杂性V（G）的计算方法：
1、环路复
2、设E为控制流图的边数，N为图中的结点数，则V（G）=E-N+2；
3、设P为控制流图中的判定结点数，则V(G)=P+1.独立路径：是指包括一组以前有没有处理的语句或条件的一条路径。等价类划分是一种典型的黑盒测试方法。有效等价类：是指对于软件的规格说明来说，合理的、有意义的输入数据构成的集合。利用它可以检查程序是否实现了规格说明预先规定的功能和性能。无效等价类：是指对于软件的规格说明来说，软件测试过程的4步骤：单元测试、组装测试、确认测试和系统测试。
驱动模式：相当于被测模块的主程序。它接受测试数据，把这些数据传送给被测模块，最后再输出实测结果。桩模块：也叫存根模块。用以代替被测模块 把模块组装为系统的方式通常有：一次性组确认测试又称有效性测试。它的任务是验证软件的有效性，即验证软件的功能和性能及其他特征是否与用户的要求一直。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。
面向对象分析模型由3个独立的模型构成：用类和对象表示的静态模型（对象模型）；有状态图和顺序图表示的动态模型（交互模型）。
以上3个模型的重要程度是不同的。用例模型是整个后续工作的基础，也是测试与验收的依据。由于面向对象系统中，类、接口、及对象是软件的基本组成单元，因此对象模型是必须建立的，也是核心模型，几乎解决任何一个问题都需要从客观世界实体及实体间的相互关系抽象出极有价值的对象模型；当问题涉及交互作用和时序是，动态模型是重要的。
复杂的大型系统的对象模型由5个层次组 在系统分析阶段，对象建模的主要任务是建世界中的类与对象以及它们之间的关系，而非实际的软件类或实际构件。
软件维护类型：改正性维护，适应性维护，影响维护工作量的因素：1.系统规模；2.系4.数据库技术的应用水平；5.所采用的软件开发技术及软件开发工程化的程度；6.其他。针对三种典型的维护，提出策略以控制维护成本。改正性维护的策略方法：数据库管理高级（第四代）语言。软件维护性定义：指当对软件实施各种类型能力。软件维护性子特性：易分析性，易变更性，提高软件维护性的开发技术和工具：1.使用2.实施开发阶段产品的维护性审查；3.改进文档。
第四篇：软件工程复习重点总结
第一章
软件过程：需求设计实现发布
软件过程三要素: 过程+方法+工具
瀑布rup scrum Iconix
Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Product Owner、Scrum Master、Team Product Backlog、SprintBacklog、Burndown Chart、Sprint、Sprint Planning Meeting、Daily Standup Meeting、Review Meeting、Retrospective Meeting ICONIX软件开发过程
愿景、业务建模、需求分析、健壮性分析、系统设计„„
思想是重点；过程是方式；方法和工具是载体
第二章
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏
捷是一种思想•Scrum是一个框架
敏捷开发过程知多少？
•Scrum、•极限编程（XP）、•Crystal Methods（水晶方法族）
•特性驱动开发（FDD）
•动态系统开发（DSDM）
•轻量型统一过程（RUP）
调查结果：敏捷开发方法—Scrum最流行！
Scrum的适用场景
•7人，+or-2
•偏小一些会更适合•最好能坐在一起
•客户参不度高
•快速移动互联网项目
•自主性研发的产品
第三章
软件项目是为了改善某个组织的某些方面
–老大就是要改善的组织中最有权力的干系人。
用户建模四步曲列出尽可能多的用户识别关键用户（购买决策者/主要使用者）分类，合并次要用户
4添加虚拟和极端用户
第四章
•产品backlog是Scrum的核心
产品功能列表格式
•ID（标示符）
–统一标识符
•Name（标题）
–简短的、描述性的故事名
•Story（故事）
–故事内容描述
•Priority（重要性）
–产品负责人评出一个数值，指示这个故事有多重要
•Initial estimate（初始估计）
–团队的初步估算，表示不其他故事相比，完成该故事所需的工作量
•How to demo（如何做演示）
–它大略描述了这个故事应该如何在sprint 演示上进行示范
•Notes（注解）
–相关信息、解释说明和对其它资料的引用等等
产品功能列表由谁来写？
•思考：由谁来写？
–主要是Product Owner
–Team也有权利，但最终由PO进行取舍。
用户故事是一种敏捷的需求挖掘方式，其侧重点不是将需求书写出来，而是将需求讨论出来。
按“作为一个„„，可以„„，以便„„”样式和思路写成的用户需求，就是用户故事。
用户故事的三个变量
范围，重要性，估算
好故事的准则
•独立的（Independ）
•可讨论的（Negotiable）
•对用户戒客户有价值的（Valuable）
•可估计的（Estimatable）
•小的（Small）
•可测试的（Testable）
Sprint会议如何迚行
–确定Sprint目标及长度
–讲解Story、估算时间、任务分解
–决定 sprint 要包含的故事
–一些其他问题
第六章
什么是界面原型
•界面原型指使用工具根据客户需求及软件分析人员的理解，将头脑中的界面快速的反映到介质上。
界面原型的目的•尽早验证需求
•尽早明确不确定性的因素
•方便沟通交流
•为后续界面设计提供基础
第八章
ICONIX过程
•ICONIX过程的规模介于RUP和XP之间
•适合中小型的、需求相对明确的软件项目
•ICONIX核心思想
•开源！节流！
ICONIX软件过程是用例驱动的软件过程。
ICONIX过程中的第一步：明确愿景
•愿景是确保项目成功的第一步；
•愿景必须来自老大；
•愿景必须是可度量。
如何获取软件项目的愿景
•获取软件项目愿景的三步曲：
•第一步：找到软件项目的“老大”；
•第二步：得到“老大”对项目的期望（愿景）；
•第三步：描述出愿景的度量指标；
要点：系统要改善哪个组织的流程？
老大就是要改善的组织中最有权力的干系人
第九章
业务建模的目的：从组织的角度来定位系统的价值。
业务建模
•业务建模的目的是把视角从系统转向组织，站在客户角度看问题。
•业务用例是对组织为外部业务执行者提供的价值的建模。
•现状业务序列图是对组织价值内部实现流程（业务工人与业务实体的协作）的建模 •改迚业务序列图是对新系统为组织提供的改良的建模。
业务建模的步骤：
1.明确我们为谁服务（选定愿景要改进的组织）。
2.要改进的组织是什么现状（业务用例图、现状业务序列图）。
3.我们如何改进（改进业务序列图）。
第十章
域建模的步骤
第一步：提取名词或名词短语
第二步：排除重复、相似
第三步：排除系统范围外
第四步：画出第一版域模型图
第五步：整理第一版域模型
域模型之间的关系
•泛化[Generalization]，一般元素和特殊元素的关系。
•关联[Association]，两个类乊间存在着某种语义上的联系。
系统需求分析的目的是把视角转向新系统，站在最织
用户（及其它干系人）的角度看问题。
•系统用例是对（新）系统为系统执行者提供的价值的建模
系统用例建模步骤
1.绘制系统用例图
2.编写系统用例描述
3.更新域模型
绘制系统用例图
1.确定系统边界
2.识别系统执行者
3.识别系统用例
4.确定用例间的关系
用例描述的作用
•用例图描述总体，用例文档描述绅节。
•每个用例必须对应有用例描述。
用例描述的基本组成•干系人利益
•基本路径
•扩展路径
•业务觃则
软件产品的典型非功能性需求(RUPS)
•可靠性[Reliability]。
•可用性[Usability]。
•性能[Performance]。
•可支持性[Supportability]。
需求获取的方法
•研究文档。
•问卷调查。
•访谈。
•观察。
•研究竞争对手。
需求分析结果复核
•形式：面对面会议。
•参会人：甲乙双方在需求分析阶段的主要参与者。
•被审材料：域模型、用例图、用例描述、非功能性需求；
•过程：需求分析师主持，最终需求分析成果，所有参与者交流讨论，达成统一理解和确认。•结论：所有参与者签字确认。（当然，也有可能是未达成共识，需要返工。）
•注意：后续的工作基本不需要用户的参不了。
第十一章
健壮性分析的步骤
第一步：创建一个空的健壮性图。
第三步：从基本路径的第一句话开始画健壮性图。
第二步：直接将用例文本粘贴到图上（基本路径和扩展路径）。
第四步：贯串整个用例基本路径，一次一个句子，画执行者、适当的边界对象和实体对象以及控制器，和各元素乊间的连线。
第五步：将每一个扩展路径画在健壮性图上，并以红色标示出。
在用例驱动的开发模式中，用例的准确完整性是关键；
•健壮性分析技术两个主要的价值：其一帮助完善用例分析结果；其二完善域模型，做为需求分析走向系统设计的过度技术；
•丌要花费太多的精力和时间在本阶段，本阶段的成果也仅起到过度作用，不纳入最终文档； 第十二章
关键设计是功能性需求的设计，成果为类图和序列图；
•关键设计还没考虑真实实现的平台相关因素，因此不能基于这个阶段的设计成果开始编码； •关键设计的方法就是在域模型、用例描述和健壮性分析的基础上，迭代生成类图和序列图；
关键设计的步骤
•第一步：将现有的域模型直接作为第一版静态类模型；
•第二步：基于用例描述和健壮性分析结果，画出每个用例的序列图；
•健壮性图中的控制类会转化为方法；
•如果也转化为控制类，那么就添加到类图中（注意：边界类丌添加到类图中）； •第三步：整理静态类图和序列图；
•第四步：关键设计复核，迭代更新用例图、类图和序列图；
高内聚、低耦合。是判断设计好坏的标准。
关键设计复核的指导建议
•确保关键设计的“如何做”和需求阶段的“做什么”匹配。也就是说每个用例都要和序列图匹配，包含了用例的基本流程和分支流程。
•复核设计的品质。应该至少有一个设计与家在场。
•检查消息的连贯性。检查时序图上消息箭头的指向，有时我们会发现对象乊间缺少消息而造成跳跃，我们必须消除这些逻辑跳跃。
•确保方法分配给了适当的类，类视图中的每一个类拥有适当的方法和属性。
第五篇：软件工程重点整理
可以把软件开发的本质概括为：不同抽象层术语之间，以及不同抽象层处理逻辑之间的映射 需求分析产生的正式文档是需求规约
在结构化分析方法中，表示“数据的静态结构”的术语是数据存储
对模块的宽度影响最大的因素是模块的扇出 下列术语，可用于抽象客观世界中事物的是类
大学由若干专业系构成，则大学与专业的关系是组合
下列软件测试技术中，依据程序逻辑结构的是白盒测试技术 单元测试期间，通常考虑模块的重要的执行路径
软件基本过程指那些与软件生产直接相关的活动集，可分为供应过程、开发过程、运行过程、维护过程和获取过程
在常见的软件开发模型中，适用于项目的开发风险很大或客户不能确定系统需求的模型是螺旋模型
CMMI 能力等级中的 3 级是已定义级
软件生产率、软件质量满足不了社会发展的需求，并成为其发展的制约因素，这一现象被称为软件危机
对于单一的一个需求，必须具有的基本性质：必要的、无歧义的、可测试的、可跟踪的以及可测量的。
需求规约的基本性质包括重要性和稳定性程度、可修改的、完整的和一致的
在结构化分析方法中，可采用结构化自然语言、判定表和判定树描述加工
用于定义数据流图包含的所有数据流和数据存储的数据结构，直到给出构成以上数据的各数据项的基本数据类型的工具是数据字典
在 UML 中，用于描述关联的一定“内涵”的术语是关联名 RUP 利用 UML 提供的术语和工具定义了需求获取层、系统分析层、设计层和实现层，并给出了实现各层模型之间映射的基本活动以及相关的指导
软件测试是一个有程序的过程，包括测试设计、测试执行以及测试结果比较等
由于软件错误的复杂性，在软件工程测试中，应综合运用测试技
术，并且应实施合理的测试序列：
单元测试、集成测试、有效性测试和系统测试
《IS0/IEC 软件生存周期过程 12207—1995》标准按过程主体把软件生存周期过程分为基本过程、支持过程和组织过程 针对开发的 CMMI 是一个有关产品和服务的过程改善的成熟度模型，集成了 3 个源模型：软件 CMM、系统工程 CMM和产品集成开发 CMM
CMMI 中，遵循一个过程可达到的预期结果的程度是指过程能力
CMMI 模型基于过程途径思想，通过过程把软件质量的 3 个支撑点：受训的人员、规程和方法、工具和设备进行集成，以开发所期望的系统/产品
请简述计算机软件的概念以及提出软件工程概念的目的
（1）计算机软件一般是指计算机系统中的程序及其文档（2）其中，程序是计算机任务的处理对象和处理规则的描述（3）文档是为了理解程序所需的阐述性资料（4）软件工程概念的提出，其目的是倡导以工程的原理、原则和方法进行软件开发，以解决出现的软件危机。
请简述初始发现需求的常用技术（1）自悟（2）交谈（3）观察（4）小组会（5）提炼
请叙述信息隐藏的概念及其意义
（1）信息隐藏是指在每个模块中所包含的信息不允许其他不需要这些信息的模块访问（2）它是实现模块低耦合的一种有效途径（3）但是，如果一个模块是“绝对”信息隐藏的，那么这种模块对系统而言是毫无意义的
什么是验证和确认？请叙述它们的区别
（1）验证就是证实一个过程或项目的每一软件工作产品/服务是否正确地反映了所规约的需求（2）确认就是证实所期望使用的软件工作产品是否满足其需求（3）区别：验证是通过提供的客观证据，证实规约的需求是否得以满足；确认是通过提供的客观证据，证实有关特定期望的使用或应用的需求是否得以满足
点击咨询 