软件工程
软件工程定义：
①将系统的、规范的、可量化（成体系，有步骤，量化的的方法）的方法应用于软件的开发、运行和维护，即将工程化应用于软件；
Applying engineering to software
②对①中所述方法的研究
软件开发活动（需求-设计-构造-测试-交付-维护）Software development activities
①需求开发（Demand development）
②软件设计（Software design）
③软件构造（Software construction）
④软件测试（Software testing）
⑤软件交付与维护（Software delivery and maintenance）
软件质量模型：
记忆线索：功能可靠，易用效率，移植维护
功能性
可靠性
易用性
效率
可维护性
可移植性
需求：
-
1）用户为了解决问题或达到某些目标所需要的条件或能力
-
The conditions or capabilities needed by the user to solve a problem or achieve certain goals
-
-
2）系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力
-
3）对 1） 或 2）中的一个条件或一种能力的一种文档化表述
需求的三个层次：
①业务需求：为什么要开发系统，描述高层级的解决方案，定义系统特性。确定系统边界
Business requirements: why the system is developed, describe high-level solutions, define system characteristics. Determination of system boundaries
商业目标：系统使用几个月后，销售额提高20%
②用户需求：具体任务的期望。特点：模糊。需要充分的问题域知识
User needs: expectations for specific tasks. Features: vague. Adequate problem domain knowledge is required
③系统级需求：系统行为的期望。每个系统级需求反映了一次外界与系统的交互行为。一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求
System-level requirements: expectations of system behavior. Each system-level requirement reflects the behavior of an outside party interacting with the system at one time. A series of system behaviors linked together can help users complete tasks and meet business needs
需求谱系：P75
项目需求：
成本在60万元以下
6个月内完成
过程需求：
开发中，开发者要提供文档与报告
使用持续集成的办法开发
其他需求：与人力资源相关的需求以及软件、硬件、人力之间协同的需求被称为其他需求
软件需求的分类：
①功能需求Functional requirements
②非功能需求Non-functional requirements
非功能需求：
①性能需求：速度，容量，吞吐量，负载，实时性
Performance Requirements
②质量需求：（靠安全维护移植使用）
Quality requirements
可靠性：在规定的时间和条件下，系统执行功能的能力
reliability: The ability of the system to perform its functions at the specified time and under the conditions
CS通信时，如果网络故障，系统不能发生故障
可用性：软件在投入使用时，可操作可访问的程度，能实现指定系统功能的概率
Usability: the degree to which the software is operable and accessible at the time it is put into use, the probability that the specified system functions will be achieved
QA2：系统的可用性要达到98%
安全性：软件阻止对其程序和数据进行未授权访问的能力
Security: the ability of the software to block unauthorized access to its programs and data
QA3：收银员只能查看，不能修改会员信息
可维护性：为维护软件而修改软件系统或部件的容易程度
Maintainability: the ease of modifying software systems or components to maintain the software
系统加新的特价属性，要在2个人月内完成
可移植性
portability
系统要能在1个人月内更换操作系统
③对外接口：用户界面，硬件，软件，网络通信
External interfaces: user interface, hardware, software, network communication
④约束：进行系统构造时需要遵守的约定。环境，标准，商业规则
Constraints: Conventions that need to be followed when constructing a system. Environment, standards, business rules
系统要用Java语言进行开发
数据需求：功能需求的补充
需求工程活动
-
需求开发
-
需求获取
-
需求分析
-
需求规格说明
-
需求验证
-
-
需求管理
验证需求的方法
①评审
②开发系统测试用例
③度量
软件设计的核心思想：分解和抽象。
The core idea of software design: decomposition and abstraction
分解是横向上将系统分割为几个相对简单的子系统以及各子系统之间的关系。
Decomposition is the horizontal division of a system into several relatively simple subsystems and the relationships between each subsystem.
分解之后每次只需关注经过抽象的相对简单的子系统以及相互之间的关系，从而降低了复杂度。
Reduced complexity.
抽象则是在纵向上聚焦各子系统的接口（与实现相对）。接口是各子系统之间交流的契约，是整个系统的关键所在。
软件工程设计的三个层次和主要思想：高层、中层、低层设计。
高层设计：体系结构设计，关注部件、连接件和配置
High-level design: architecture design
中层设计：关注组成构件的模块的划分、导入和导出、过程之间调用关系或者类的协作。
Mid-level design: focus on the division of the modules
低层设计：深入模块和类的内部，关注具体的数据结构、算法、类型、语句和控制结构等。
Low-level design: getting inside the modules and classes
体系结构风格：
-
主程序/子程序
-
面向对象式
-
分层
-
MVC
Architecture style：
-
Main program/subprogram
-
object-oriented
-
Hierarchical
-
MVC
四大关注点（修理开复）
主程序/子程序：适用于按层次分解为多个顺序执行步骤的系统
优点：
流程清晰，易于理解
更能控制程序的“正确性”
缺点：
难以修改和复用
产生不必要的公共耦合
master program/subprogram：for systems with hierarchical breakdowns into multiple sequential steps
Advantages：
Clear and easy to understand process
More control over the "correctness" of procedures
Disadvantages：
Difficult to modify and reuse
Creating unnecessary public coupling
面向对象式：适用于能够基于数据信息分解和组织的软件系统
优点：
内部实现的可修改性
易开发，易理解，易复用
缺点：
无法消除接口的耦合性
标识的耦合性：一个方法要与其他对象交互，就必须知道其他对象的标识
副作用。引入了面向对象的副作用
object-oriented：For software systems that can be decomposed and organized based on data information
Advantages：
modifiability
Easy to develop, easy to understand, easy to reuse
disadvantages：
Unable to eliminate coupling of interfaces
Coupling of signatures：for a method to interact with other objects, it must know the signatures of other objects
Side effects. Introduction of object-oriented side effects
Hierarchical：
Advantages：
①The mechanism is clear and easy to understand
②Supports parallel development
③Better reusability and internal modification
Disadvantages：
①Interaction agreements are difficult to modify
②performance loss
③Difficulty in determining the number of layers
Applicability：
Ability to decompose tasks at different levels of abstraction
Ability to establish stable interaction protocols between different levels
There are no very high real-time requirements.
MVC：适用于网络系统开发
优点：
①易开发性
②视图和控制的可修改性
③适宜于网络系统开发的特征
缺点：
①复杂性
②模型修改困难
MVC：suitable for network system development
Advantages：
①Ease of development
②Modifiability
③Characteristics suitable for network system development
Disadvantages：
①Complexity
②Difficulty in modifying the model
软件体系结构设计过程：
①需求分析
②选择体系结构风格
③抽象设计
④物理设计
⑤完善
⑥定义构件接口
⑦迭代③~⑥
体系结构开发集成测试用例：（桩Stub、驱动Driver）
桩：自顶向下集成，下层的模块使用伪装的具有相同接口的桩。
驱动：自底向上集成，从底层的模块集成起，测试的时候上层的模块使用伪装的相同接口的驱动。
集成测试用例：模拟实现。
集成：单元测试后，将所有模块组合起来形成整个软件原型系统
Integration: after unit testing, all modules are combined to form the entire software prototype system
集成的目的：逐步让各个模块合成为一个系统来工作，从而验证整个系统的功能、性能、可靠性等需求。进行黑盒测试
The purpose of integration: to gradually allow the individual modules to work together as a system, thus validating the functionality, performance, reliability, etc. requirements of the entire system. Conduct black box testing.
集成策略：
①大爆炸式
②增量式
Integration strategy：
①Big Bang
②Incremental
增量式：
①自顶向下
②自底向上
③三明治式
④持续集成
Incremental：
①Top-down
②Bottom-up
③sandwich style
④Continuous integration
大爆炸式：一次性组合。
优点是短时间内迅速完成集成测试。
缺点是问题的定位和修改比较困难。
适合应用于一个维护型项目或被测试系统较小的情况
自顶向下：
优点：
①按深度优先可首先实现和验证一个完整的功能需求
②只需要最顶端一个驱动
③利于故障定位
缺点：
①桩的开发量大
②底层验证被推迟，底层组件测试不充分
适用于控制结构比较清晰和稳定、高层接口变化比较小、底层接口未定义或经常可能被修改、控制组件具有较大的技术风险的软件系统
From top to bottom：
Advantages：
①A complete functional requirement can be implemented and validated first according to depth priority
②Only the top driver is needed
③Facilitates fault location
Disadvantages：
①Large amount of stub development
②The underlying validation was delayed and the underlying components were not adequately tested
Suitable for software systems where the control structure is clear and stable, where there is little variation in the high-level interface, where the underlying interface is not defined or can often be modified, and where the control components carry a high technical risk
自底向上
优点：
①对底层组件行为较早验证
②底层组件开发可以并行
③桩的工作量小
④利于故障定位
缺点：
①驱动的开发量大
②高层验证被推迟，高层的错误不能及时被发现
适用于底层接口比较稳定、高层接口变化频繁、底层组件较早被完成的软件系统
bottom-up
Advantages：
①Early validation of the underlying component behavior
②The development of the underlying components can be done in parallel
③Low workload of Stubs
④Facilitates fault location
Disadvantages：
①Large amount of development driven
②high-level errors are not caught in time
Suitable for software systems where the underlying interface is stable, the high-level interface changes frequently, and the underlying components are completed earlier
持续集成：
提倡尽早集成和频繁集成
尽早集成：开发之初就拿stub集成起来
频繁集成：每次完成一些开发任务以后，就用开发结果替换stub，进行集成和测试
优点：
①防止软件开发中出现无法集成与发布的情况
②有利于检查和发现集成缺陷
必须使用版本控制工具和持续集成工具
Continuous integration：
Promote early and frequent integration
Integrate early: take the stub and integrate it from the beginning of development
Frequent integration: every time you complete some development tasks, replace the stub with the development results for integration and testing
Advantages：
①Prevent the inability to integrate and release in software development
②Facilitates inspection and detection of integration defects
Version control tools and continuous integration tools must be used
人机交互设计的目标——易用性：
①易学性
②易记性
③效率
④出错率
⑤主观满意度
人机交互设计原则：
①简洁设计
②一致性设计
③低出错率设计
④易记性设计
人机交互设计的人类因素：
①精神模型：隐喻
②差异性：新手用户，专家用户，熟练用户
人机交互设计的计算机因素：可视化
The computer element of human-computer interaction design: visualization
人机交互设计的交互性：导航，反馈
Interactivity in human-computer interaction design: navigation, feedback
协作式设计：人和计算机是人机交互的两方，其中人的因素是比较固定的，一定时期内不会发生大的变化，所以要让二者交互顺畅，就需要让计算机更多地适应人的因素，这也是人机交互设计以用户为中心的根本原因。这种调整计算机因素以更好地适应并帮助用户的设计方式被称为协作式设计。
Collaborative design: Making computers more adaptable to the human factor
耦合：（高→低）
-
内容耦合：GOTO，直接改别的模块的数据
-
公共耦合：全局变量
-
重复耦合：一样的代码
-
控制耦合：传参控制另一个模块
-
印记耦合：传一个数据结构，模块只用了一个字段
-
数据耦合：传递一个字段
-
耦合越高越不利于软件变更。
Coupling: (high→low)
-
Content coupling: GOTO, directly changing the data of other modules
-
Public coupling: global variables
-
Repeated coupling: same code.
-
Control coupling: Pass-through control of another module
-
marker coupling: pass a data structure, the module uses only one field
-
Data coupling: passing a field
-
Higher coupling is less conducive to software changes.
内聚：（高→低）
-
信息内聚：栈
-
功能内聚：需求就这么写的
-
通信内聚：相同的数据结构上进行
-
过程内聚：与顺序有关
-
时间内聚：与时间有关
-
逻辑内聚：几个方法间没有必然的联系
-
偶然内聚：没啥关系
-
内聚越低越不易实现变更。
Cohesion: (high→low)
-
Information cohesion: the stack
-
Functional cohesion: that's what the requirements say.
-
Communication coalescence：相同的数据结构上进行
-
Process cohesion: sequence-related
-
Time coalescence: related to time
-
Logical coalescence: there is no necessary connection between several approaches
-
Occasional coalescence
模块化原则：
1）全局变量有害
2）To be Explicit
3）不重复
降低访问耦合的方法：
4）针对接口编程
5）接口最小化/接口分离原则
6）访问耦合的合理范围/迪米特法则
降低继承耦合的方法
7）Liskov Substitution Principle（LSP） Liskov替换原则（P235）
8）Favor Composition Over Inheritance 使用组合代替继承
提高内聚的方法
9）Single Responsibility Principle（SRP） 单一职责原则
10）集中信息与行为
The principle of modularity：
1）Global variables are harmful
2）To be Explicit
3）No duplication
Methods to reduce access coupling:
4）Programming for interfaces
5）Interface minimization/interface separation principle
6）Reasonable scope for access coupling/Dimetric rule
降低继承耦合的方法
7）Liskov Substitution Principle（LSP）
8）Favor Composition Over Inheritance
提高内聚的方法
9）Single Responsibility Principle（SRP） 单一职责原则
10）Focusing information and behaviour
六大原则
-
单一职责原则
-
原因：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
-
-
OCP
-
LSP
-
DIP
-
接口隔离
-
迪米特法则
封装：
1）将数据和行为同时包含在类中
2）分离对外接口和内部实现
Package.
1) Include both data and behavior in the class
2) Separation of external interface and internal implementation
OCP： Open Close Principle 开闭原则
好的设计应该对“扩展”开放，好的设计应该对“修改”关闭。即发生变更时，好的设计只需要添加新的代码就能实现变更。
Good design should be open to "extensions" and good design should be closed to "modifications". That is, when a change occurs, a good design can implement the change simply by adding new code.
DIP： Dependency Inversion Principle 依赖倒置原则
抽象不应该依赖于细节，高层模块不依赖于低层模块，都应依赖于抽象。
The abstraction should not depend on details, the higher level modules should not depend on the lower level modules, all should depend on abstraction.
多态：不同类型的值能够通过统一的接口来操纵
Polymorphic: different types of values can be manipulated through a unified interface
可修改性：
包含的质量：
可修改性
可扩展性
灵活性
方法： 需要能够将接口和实现分离
工厂模式应用场景：
比如数据库连接，底层到底是用mysql还是sql server，使用类不需要关心
简单工厂：最简单，最直接，能满足大部分日常需求，不足是工厂类太简单——无法满足开闭原则，对多个产品的扩展不利
工厂方法模式，有了进步，把工厂类进行改进，提升为一个抽象类（接口），把对具体产品的实现交给对应的具体的子类去做，解耦多个产品之间的业务逻辑。
针对每一种产品提供一个工厂类
设计模式（Design Pattern）：P263
策略模式Strategy Model：
抽象Strategy，实现不同的ConcreteStrategy方法，Context拥有Strategy的一个引用。
优点
减少算法类与使用算法类之间的耦合
提供可重用方法
简化单元测试
扩展性好
缺点
策略类增多
策略需要对外暴露
抽象工厂模式：
AbstractFactory声明接口，ConcreteFactory实现对产品的创建。
AbstractProduct定义产品接口，ConcreteProduct实现具体工厂创建出来的产品，实现接口。
Client使用AbstractFactory和AbstractProduct来创建。
抽象工厂是应对产品族概念的。
优点
易于交换产品系列
具体的创建实例过程与客户端分离（不知道用的到底是SQL还是mysql）
符合OCP
缺点
扩充困难
单件模式：
Singleton提供访问单件的接口，负责实现单件。
Client通过getInstance使用单件。
迭代器模式：
Iterator定义访问和遍历的接口，ConcreteIterator实现接口。
Aggregate定义创建相应迭代器对象的接口，ConcreteAggregate实现接口。
观察者模式Observer model
白盒测试和黑盒测试：（给出一个场景，判断应该使用哪种测试方法，如何去写）
黑盒测试：把测试对象看做一个黑盒子，完全基于输入和输出来判断测试对象的正确性
优点 ：
1) 比较简单，不需要了解程序的内部的代码及实现
2) 与软件的内部实现无关
3) 从用户的角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题
4) 基于软件开发文档，所以也能知道软件实现了文档中的哪些功能
5) 在做软件自动化测试时较为方便
缺点：不可能覆盖所有的代码
常见方法：
1）等价类划分
2）边界值分析
3）决策表
4）状态转换
Black box testing: Think of the test object as a black box and judge the correctness of the test object based entirely on input and output
优点 ：
1) relatively simple, no need to understand the internal code and implementation of the program
2)Irrelevant to the internal implementation of the software
3)it is easy to know what functions users will use and what problems they will encounter.
4)Based on the software development documentation, so you can also know which functions the software implements in the documentation
5)It is easier to do software automation testing
缺点：Impossible to cover all codes
Common methods：
1）Equivalence category division
2）Boundary value analysis
3）Decision table
4）State transition
白盒测试：把测试对象看做透明的，按照测试对象内部的程序结构来设计测试用例进行测试工作
优点：帮助软件测试人员增大代码的覆盖率
缺点：
不可能覆盖所有的代码
测试基于代码，只能测试开发人员做的对不对，而不能知道设计是否正确，可能会漏掉一些功能需求
系统庞大时，测试开销会非常大
（能解释并区别白盒测试三种不同的方法）
常见方法：
1）语句覆盖：保证每一行代码都至少执行一次。
2）分支覆盖：保证每个判断结果都至少满足一次。
3）路径覆盖：保证每条独立的执行路径都至少执行一次。
Whitebox testing: the test object is treated as transparent and the test cases are designed according to the internal structure of the test object to test work.
Advantage: Helps software testers increase code coverage
Disadvantages：
It's impossible to cover all the codes.
may leave out some functional requirements
When the system is big, the testing overhead can be huge.
Common methods：
1）Statement coverage: ensure that every line of code is executed at least once.
2） Branch coverage: ensure that each judgment is satisfied at least once.
3）Path coverage: ensure that each separate execution path is executed at least once.
软件生命周期模型：需求工程→软件设计→软件实现→软件测试→软件交付→软件维护
Software Life Cycle Model:
-
Requirements Engineering
-
Software Design
-
Software Implementation
-
Software Testing
-
Software Delivery
-
Software Maintenance
需求工程：建立解决方案
主要任务：（获取，分析，规格说明，验证，管理）
需求开发：需求获取，需求分析，需求规格说明，需求验证
需求管理
方法：
结构化分析方法：DFD，ERD
面向对象分析方法：用例图，概念类图，行为模型（顺序图、状态图）
Requirements engineering: building solutions
Main tasks: (acquisition, analysis, specification, validation, management)
Requirements development: requirements acquisition, requirements analysis, requirements specification, requirements validation
Demand management
Methodology
Structured analysis methods: DFD, ERD
Object-oriented analysis methods: use case diagrams, conceptual class diagrams, behavioural models (sequence diagrams, state diagrams)
软件设计：如何完成功能
体系结构设计：高层设计
结构化方法：结构图
面向对象：包图，构件图，部署图
主要制品：软件体系结构原型，软件体系结构设计模型，软件体系结构设计文档（概要设计文档）
详细设计
结构化方法：结构图
面向对象：包图，类图，顺序图
主要制品：软件详细设计模型，软件详细设计文档
人机交互设计：设计交互机制，具有易用性
Software design: how to complete the functionality
Architecture design: high-level design
Structured approach: structural diagram
Object-oriented: package diagrams, deployment diagrams
Main products: software architecture prototype, software architecture design model, software architecture design document (outline design document)
detailed design
Structured approach: structural diagram
Object oriented: package diagram, class diagram, sequence diagram
Main products: software detailed design model, software detailed design documentation
Human-computer interaction design: designing interaction mechanisms
软件构造：构件软件
编程，集成，测试，调试
软件测试：保障产品质量
单元测试
集成测试
系统测试
方法：白盒与黑盒
软件交付：产品交付用户
安装与部署，用户培训，文档支持
软件维护：
完善性维护，适应性维护，修正性维护，预防性维护
逆向工程，再工程，遗留资产处理
构建-修复模型（Build-Fix Model）：
缺点：没有考虑最基本的生命周期。没有分析需求的真实性。没有考虑软件结构的质量。没有考虑可维护性。
适用范围：软件规模很小、质量要求不高、对后期维护要求不高的程序可以使用。
Waterfall Model：
-
follows an ordered sequence of transformations from one stage to another. Require that every activity be validated.
-
Allowing iterations to occur, the results of each activity must be verified, "document driven"
-
Requirements engineering → software design → software implementation → software testing → software delivery → software maintenance (can be iterative).
-
Disadvantages：
-
High expectations for documentation
-
Linear presets for development activities
-
Insufficient client-user engagement
-
Milestone granularity is too coarse
-
-
Scope of application: Projects with very mature and stable requirements, reliable technology and moderate complexity.
瀑布模型（Waterfall Model）：按照一个阶段到另一个阶段的有序的转换序列。要求每一个活动必须进行验证。
允许出现迭代，每个活动的结果必须验证，“文档驱动”
需求工程→软件设计→软件实现→软件测试→软件交付→软件维护（可以迭代反复）。
缺点：对文档的高期望、对开发活动的线性预设、客户用户参与不够、里程碑粒度过粗。
适用范围：需求非常成熟稳定、技术可靠、复杂度适中的工程。
增量迭代模型：
长的开发周期分成多个迭代，每个迭代结束时提交产品的一个部分，所有迭代集合起来共同交付完整产品
将开发活动组织为多个迭代、并行的瀑布式开发活动。“需求驱动”
目的：迭代，渐进交付，并行开发
优点：
有更好的适用性
并行开发可以帮助缩短软件产品的开发时间
渐进交付可以加强用户反馈
降低开发风险。
缺点：加入构件不能破坏已经构造的部分，需要完备清晰的项目前景。
适用范围：相对稳定、成熟的领域。
Incremental iterative model：
-
The long development cycle is divided into multiple iterations, with one part of the product being submitted at the end of each iteration, and all iterations coming together to deliver the full product
-
Organize development activities into multiple iterative, parallel waterfall development activities. "Demand-driven."
-
Purpose:
-
Iteration
-
incremental delivery
-
parallel development
-
-
Advantages：
-
There is better suitability
-
Parallel development can help reduce development time for software products
-
Progressive delivery can enhance user feedback
-
Reduce development risk
-
-
Disadvantages
-
The addition of building blocks does not destroy the already constructed parts
-
requires a complete and clear project vision
-
-
Scope of application: relatively stable, mature field
演化模型：
-
在初始开发迭代中，澄清和明确系统的核心需求，建立和交付核心系统。在得到核心系统后，用户在使用的过程中发现变更需求、澄清不确定性需求，反馈给开发人员。开发人员根据用户反馈规划后续迭代，精化和增强系统。
-
多个迭代、并行的瀑布式开发活动。
-
优点：
-
迭代式开发
-
并行开发
-
渐进交付加强用户反馈
-
-
缺点
-
无法确定项目范围
-
整体项目计划不好把握
-
后续迭代容易蜕变为Build-Fix模式。
-
-
适用范围：变更比较频繁，不稳定领域的大规模系统开发。
Evolutionary models：
-
During the initial development iteration, clarify and specify the core requirements of the system and build and deliver the core system. After getting the core system, users discover change needs and clarify uncertainty needs in the process of using it and feed it back to developers. Developers plan subsequent iterations to refine and enhance the system based on user feedback.
-
Multiple iterative, parallel waterfall development activities
-
Advantages：
-
iterative development
-
parallel development
-
Progressive delivery to enhance user feedback
-
-
drawback
-
Inability to define project scope
-
Poor grasp of the overall project plan
-
Subsequent iterations easily morph into Build-Fix patterns
-
-
Scope of application: Large-scale system development in the field of frequent changes and instability.
原型模型（Prototyping）：注重使用抛弃式原型（不确定部分）而不是演化式原型（成为产品的一部分的原型）。
-
需求开发部分迭代（抛弃式原型）：原型需求→设计原型→构件原型→评估原型。
-
优点：加强了客户用户的交流，适用于新颖的领域。
-
缺点：原型方法在避免风险时候带来新的风险，不舍得抛弃原型。
-
适用范围：不确定性较多的软件开发。
Prototyping：
-
focuses on using discarded prototypes (indeterminate parts) rather than evolutionary prototypes (prototypes that become part of the product)
-
Requirements development partial iteration (discarded prototype): prototype requirements → design prototype → building blocks prototype → evaluate prototype
-
Advantages: Enhanced client-user communication, suitable for novel areas.
-
缺点：The prototype approach introduces new risks when it comes to avoiding them and is not willing to abandon the prototype.
-
Scope of application: Software development with high uncertainty.
螺旋模型（Spiral Model）：为了尽早解决比较高的风险。风险驱动。
是迭代与瀑布的结合，使用原型解决需求的不确定性
优点：可以降低风险，减少项目因风险造成的损失。
缺点：自身带来风险，模型过于复杂。
适用范围：高风险的大规模软件系统开发。
Spiral Model：To address the higher risks as early as possible. Risk-driven
is a combination of iteration and waterfall, using prototypes to solve the uncertainty of the need
Benefit: Reduces risk and reduces project losses due to risk.
Disadvantages: Self-imposed risk, overly complex model.
Scope: High-risk, large-scale software system development.
设计模式了解吗？
-
简单工厂，抽象工厂，工厂方法
-
策略模式
-
迭代器
-
观察者模式
软件详细设计
-
封装
-
透明
-
LSP
-
OCP
-
DIP
-
多态
什么是模块化，模块化的原则
内聚与耦合。对应的种类
需求分析会用到哪些图
-
用例
-
类图
-
顺序图
-
状态图
-
E-R图
-
DFD
软件设计的核心思想
-
分解
-
抽象
软件体系结构风格有哪些
Chapter9-10-软件体系结构
软件开发过程模型
-
瀑布模型
-
增量模型
-
演化模型
-
螺旋模型
-
原型模型
白盒测试与黑盒测试
软件生命周期模型