Week 1 -- Introduction
failure reason
professional software development***
maintain, security, efficiency, acceptability
two kinds***: generic, customized
software deterioration 软件退化
reduce changes/ side effects after changes
software engineering approaches 软件工程方法***
4 fundamental activities:s,d,v,e(迭代优化) Lec1 p24
•软件规范（Software specification）（需求明确）
•软件开发（Software development）
•软件验证（Software validation）
•软件进化（Software evolution）（软件迭代）
开发方法
• 顺序开发（Sequential）
• 迭代开发（Iterative）
ethics***
软件开发的风险（SOFTWARE DEVELOPMENT RISK） 风险***
minimize risks -- communicate
Week 2 --software process
a set of related activities
•软件规范（Software specification）
•软件设计和实现（Software design and implementation）
•软件验证（Software validation）
•软件进化（Software evolution）
classification***
plan driven/ agile process
process models 软件过程模型 p12
•瀑布模型（The waterfall model）
This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on.
*document produced in each stage
* free parts
原则上，瀑布模型应该只在需求被很好地理解并且在系统开发期间不太可能发生根本变化的情况下使用
•增量开发（Incremental development）
This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.
优点：
成本低，快速，客户及时反馈
缺点：
•进程不可见。
•随着新增量的增加，系统结构趋于退化（错误越来越多） 。
•面向重用的软件工程（Reuse-oriented software engineering）
This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch.
注意：这些模型**不是相互排斥（mutually exclusive）**的，并且经常一起使用，特别是对于大型系统开发。
e.g web服务， 包，standalone software
优点：
less work/cost/risks
faster
缺点
· 然而，需求妥协（requirements compromises）是不可避免的，这可能导致系统不能满足用户的真正需求。
• 此外，由于可重用组件的新版本不在使用它们的组织的控制之下，因此失去了对系统演化的一些控制（新版本上线，有些东西不能用了）
SOFTWARE PROCESS ACTIVITIES 软件过程活动
定义***现实的软件过程是技术、协作和管理活动的交错序列，其总体目标是指定、设计、实现和测试软件系统****（specifying, designing, implementing, and testing a software system）
•在瀑布模型中，它们按顺序组织（in sequence）
•在增量开发中，它们是交错的（interleaved)
SOFTWARE SPECIFICATION
requirement engineering
- 2level high level/ detailed level
-4 activities p35
需求工程过程的目的是产生一个商定的需求文档 ，该文档指定了一个满足涉众需求的系统。
SOFTWARE DESIGN AND IMPLEMENTATION 软件设计和实现
•软件开发的实现阶段是将系统规范转换为可执行系统的过程 。
•它总是涉及软件设计和编程过程 ，但是，如果使用增量开发方法 ，也可能涉及软件规范的****细化（refinement of the software specification） 。
•软件设计是对要实现的软件结构、系统使用的数据模型和结构、系统组件之间的接口，有时还包括所使用的算法的描述 。
*迭代设计
输入：平台信息。需求规范说明，数据描述
输出：软件结构，数据库规范描述，接口规范描述，组件规范描述
design activity 设计活动
体系结构设计（Architectural design）
接口设计（Interface design）
组件设计（Component design）
数据库设计（Database design）
Software Validation 软件验证
• a system both conforms to its specification
• it meets the expectations of the system customer
Validation techniques 验证技术
三个阶段的测试过程包括对系统组件的测试(testing for system component) ，然后是对集成系统的测试( testing for an integrated system) ，最后是使用客户数据对系统进行测试(testing of the system with the customer's data)
开发测试(Development testing)
组件测试,独立
系统测试（System testing）
组件交互
验收测试（Acceptance testing）
用户数据
Week 3 -- Agile methods
Rapid Software Development 快速软件开发
The software is not developed as a single unit but as a series of increments, with each increment including new system functionality.
fundamental characteristics: interleaved， Minimum documentation，series of version with system stakeholders involvement， interactive development system
Principle
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
Challenge
-
require: a customer who is willing and able to spend time with the development team and who can represent all system stakeholders
-
Individual team members may not have suitable personalities for the intense involvement
-
Prioritizing changes difficult
-
contract difficult - time paid
-
responsibility
-maintain continuity
Maintenance 维护
正式的文档应该能简化系统的演化和维护。然而，在实践中，正式文档通常是不更新的，在系统可维护性方面也是如此（对文档的不重视性可能导致维护性差）
system requirements document **
Plan-driven and Agile development 计划驱动和敏捷开发
10个问题
• Detail specification and design needed?
• Is incremental strategy realistic?
• How large is the system?
• What type of system being developed?
• System life span?
• Available technologies and tools?
• Organization of the team?
• Cultural issues?
• Available skillsets?
• External regulation?
Week 4 -- Requirement Engineering
是software specification这个阶段的任务哦！
高层描述（high-level description） User requirements；
细节描述（detail description） System requirements
Functional requirement
**·**功能需求
These are statements of services the system should provide. How the services should react and behave in certain condition. In some cases, the functional requirements may also explicitly state what the system should not do.
完整性(Completeness)，一致性(Consistency)
类型：
通用性需求；状态驱动的需求；事件驱动的需求；可选功能需求；异常行为需求；复杂需求
Non-functional requirement*****
**·**非功能需求
These are constraints on the services or functions offered by the system. Non-functional requirements often apply to the system as a whole, rather than individual system features or services.
系统属性（System properties）
重要： 如可靠性、安全性和机密性需求（reliability, safety, and confidentiality）
1. failing the unfunctional requirement means the whole system is unuseable
2. affect overall architecture
3 may generate a number of related functional requirements
非功能分类↓
• Product requirements - These requirements specify or constrain the behavior of the software.
• Organizational requirements - These requirements are broad system requirements derived from policies and procedures in the customer's and developer's organization.
• External requirements - This broad heading covers all requirements that are derived from factors external to the system and its development process
定量地（quantitatively）
软件需求文档（The Software Requirements Document）
软件需求文档(有时称为软件需求说明书（software requirements specification）或SRS)是系统开发人员应该实现的正式文档。 应该包括系统的****用户需求和系统需求的详细规格说明
需求稳定的
质量特性：correct，complete，unambiguous，verificable， consistent， ranked for importance/stability, modifiable, traceable
需求工程过程（Requirements Engineering Processes）
和软件过程活动是一张图居然
4 high-level activities
-(可行性研究，feasibility study)
需求发现(获取和分析，elicitation and analysis),
转换成某种标准形式(规范，specification),
(验证，validation)
需求获取与分析（Requirements Elicitation and Analysis）
需求规范（Requirements specification）：需求被记录下来，并输入到螺旋的下一轮中。如第4.3节所述，可能会产生正式或非正式的需求文件
挑战 p39
-
unreachable
-
customer use their own terms
需求发现（Requirements discovery/elicitation）
This is the process of interacting with stakeholders of the system to discover their requirements
stakeholders--
interviews （close/open）a springboard question, a requirements proposal, a prototype system 来自访谈的信息补充了 来自描述业务流程或现有系统的文档、用户观察等有关系统的其他信息。
observation
scenarios
prototypes
1.采访（Requirements Discovery - Interview）
2.场景（Requirements Discovery - Scenarios）
示例交互会话（example interaction sessions）,标识了系统与其用户或其他系统之间的单独交互
一般情况下，一个场景可能包括1.2.3.4.5
3.用例（Requirements Discovery - Use case）
4.人类学（Requirements Discovery -- Ethnography）
站在需求方考虑，不是完整的启发（elicitation）的方法，用来填补其他方法
需求规范（Requirements Specification） p60
清晰的、无歧义的、容易理解的、完整的和一致的
在写用户的 需求规范时，应1.2.3.4
-
需求规范---自然语言规范（Natural Language Specification）
-
结构化规范（Structured Specification）
结构化自然语言是一种使用自然语言****在预定义的结构或模板中编写系统需求 的方法
需求验证（Requirements Validation）
•Requirements validation is the process of checking that requirements correctly define the system that the customer really wants
types of checks
有效性检查（Validity checks）
一致性检查（Consistency checks）
完整性检查（Completeness checks）
真实性检查（Realism checks）
可验证性（Verifiability）
techniques
需求评审（Requirements reviews）
原型设计（Prototyping）
测试用例生成（Test-case generation）
重要性：不适当的 validation 可能导致rework
Week5 -- System Modeling
构成元素 elements
系统建模是开发系统抽象模型的过程，每个模型表示该系统的不同视图或视角
建模通过将复杂系统抽象成适当层次 的细节来简化复杂系统
使用某种图形符号来表示系统 ，现在几乎总是基于统一建模语言(UML)中的符号
系统视角（System perspectives）
external/interaction/structural/behavioral models
UML 图
这玩意我单独写一篇博客
活动图（Activity diagrams） ，显示流程或数据处理 中涉及的活动。
用例图（Use case diagrams） ，显示系统与其环境之间的交互。
序列图（Sequence diagrams） ，显示参与者和系统之间以及系统组件之间的交互。
类图（Class diagrams） ，显示系统中的对象类 和这些类之间的关联。
状态机图（State machine diagrams） ，显示系统如何对内部和外部事件作出反应。
上下文建模（Context models）
illustrate the operational context of a system - they show what lies outside the system boundaries.
social & organisational may affect System boundaries
1.生成一个简单的体系结构模型（a simple architectural model）
交互模型（Interaction models）
Modeling user interaction/system-to-system interaction/component interaction
用例图和顺序图（Use case diagrams and sequence diagrams）用于描述系统中用户和系统之间的交互（交互模型（Interaction models））。
用例图描述系统和外部参与者之间的交互;
序列图通过显示系统内部的对象之间的交互向这些图添加了更多的信息。
结构模型（Structural models）
static -- the structure of the system design
dynamic -- the organization of the system when it is executing
类图（class diagrams**）** 用于定义系统中类的静态结构及其关联。
generalization 底层类是继承父类的属性和操作的子类,泛化显示为指向更通用类的箭头（三角箭头）
aggregation一个对象(整体)由其他对象(部分)组成,整体的类旁边使用一个菱形（菱形箭头）
行为模型（Behavioral models）
系统对来自环境的刺激(data/events)作出反应时发生了什么或应该发生什么
数据驱动模型（Data-driven modeling）
关于事件驱动的建模（Event-driven modeling）
活动图（Activity diagrams）和序列图可用于对数据处理建模（data-driven models） ，其中在活动图，每个活动表示一个过程步骤。
状态图（State diagrams）用于对系统响应内部或外部事件的行为进行建模（event-driven models）。
Week 8--Design Concepts
analysis 做什么
design 怎么做
analysis:
goal
• Firmness (no bugs)
• Commodity (useful or valuable)
• Delight (pleasurable experience)
Design in the SE context
四个层次，由总到细，由高到低
Component level design
transforms structural elements of the software architecture into a procedural description of software components.
Interface design
describes how the software communicates with systems that interoperate with it, and with humans who use it
Architectural design
defines the relationship between major structural elements of the software, the architectural styles and patterns that can be used to achieve the requirements defined for the system, and the constraints that affect the way in which architecture can be implemented.
data design/class design
transforms class models into design class realizations and the requisite data structure required to implement it.
Quality control in the design progress*
3 goals : satisfy implicit/explicit requirement/readable/complete picture
8 technical criteria p9 - architecture, modular, distinct representation, appropriate data structures, independent, repeatable, notation
Quality -- FURPS***
Functionality, Usability, Reliability, Performance, Supportability
Design concepts***
idea: foundation, partition, technical quality
Abstraction
Abstraction simply means to hide the details to reduce complexity and increases efficiency or quality.
procedural abstraction: a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed.
data abstraction: a named collection of data that describes a data object.
Modularity
better organize complex system
Functional independence: coupling &cohesion
coupling: refers to the degree of interdependence between software modules
sol: interface--, cohesion++
cohesion: the degree of how closely the elements of a module are related to each other
object-oriented design
designing object classes
objects are created dynamically from these class definitions.
Elements in design model
Data
abstract → refined
Program-component level
Application level
Business level
Architectural
floor to the house
resources:
application domain
model elements
availability
Interface
doors and windows
UI, external, internal
Component-Level
detailed
UML-diagram
Deployment-Level
physical
Week 9--Architecture, Component-Level and Interface
Architecture Design
Architectural design is concerned with understanding how a system should be organized and designing the overall structure of that system. It identifies the main structural components in a system and the relationships between them. The output of this design process is a description of the software architecture.
affects: performance, robustness, distributability, and maintainability
Individual component -- implement functional requirements
System architecture -- fulfill non-functional requirement
advance： stakehoder communication, system analysis, reuse
Architecture View
**·**Logical
shows the key abstractions in the system as objects or object classes.
**·**process
shows how, at run-time, the system is composed of interacting processes.
**·**development （模块）
shows how the software is decomposed for development.
**·**physical
shows the system hardware and how software components are distributed across the processors in the system.
scenarios：
用用例将另外几个视图串联
Aechitectural Patterns************
Patterns are means of representing, sharing and reusing knowledge. A stylized description of good design practice,
**·**MVC （Model-View-Controller)
Model: central component of the pattern that directly manages the data, logic and rules of the application
View：can be any output representation of information, such as a chart or a diagram.
Controller: accepts input and converts it to commands for the model or view, enables the interconnection between the views and the model
· Layered Patterns
the system functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it.
supports the incremental development , not efficient
**·**Repository Patterns
**·**Client-Server Patterns
**·**Pip and filter Patterns
Component-level Design
Component-level design occurs after the first iteration of architectural design has been completed.
A complete set of software components is defined during architectural design.
define data structures, algorithms, interface characteristics, and communication mechanisms
intermediate representations
➢ A software component is a modular building block for computer software.
➢ It can be used to review for correctness and consistency with other components.
Views of Component
**·**面向对象视角（object-oriented view）
Centers on objects as the fundamental building blocks of software. An object encapsulates both data and behavior, representing entities or concepts.
• 面向对象视图侧重于将系统建模为一组相互作用的对象 ，每个对象都封装了与在线购物相关的数据和行为。
**·**传统视角（conventional view）
• 传统观点将系统构建为一系列执行特定任务的过程或功能 ，如添加产品、下订单和处理付款。
· 流程视角（process view）
• 流程视图根据系统的运行时行为来查看系统 ，特别是它如何处理订单和支付流，以及如何管理并发性和系统资源。
User Interface Design
golden rules
- Place the User in control
does not force
flexible interaction
interruptible and undoable
direct interaction on screen
visibility
- Reduce the Users' Memory Load
Reduce demand on short-term memory.
default
realworld
- make the interface consistant
process 
iterative
issues
Response time: length, variability
Help facilities
Error handling
Application accessibility
Internationalization
evaluation
Week 10--Software Testing
Testing basics
validation vs defect
validation testing 验证：
You expect the system to perform correctly using a given set oftest cases that reflect the system's expected use.
A successful test shows that the system operates as intended
defect testing 缺陷：
The test cases are designed to expose defects. The test cases indefect testing can be deliberately obscure and need not reflecthow the system is normally used
A successful test is a test that makes the system performincorrectly and so exposes a defect in the system.
verification vs validation
meeks specification and delivers functionality
verification: functional and non-functional requirements
validation: meets the customer's expectations
software inspections vs software testing
inspection : Concerned with analysis of the static system representation to discover problems(static V&V)
adavantage: ignore error interaction, no additional cost, border quality
testing : Concerned with exercising and observing product behavior (dynamic V&V)
stages of testing
Development testing
the system is tested during development to discover bugs and defects
Unit testing
where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods.
unit : Object classes with several attributes and methods
automated test: setup, call, assertion
testing strategies
partition testing(类似的组合测试); single value, different size, boundaries, midpoint, zero length
guideline-based testing（容易出错地方的测试）
Component testing
several individual units are integrated to create composite components. Component testing should focus on testing component interfaces. * not individual components
interface testing
interface misuse: A calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order
interface misunderstanding: A calling component embeds assumptions about the behavior of the called component which are incorrect
timing errors: The called and the calling component operate at different speed sand out-of-date information is accessed
extreme ends, null pointers, component failure
System testing
where some or all of the components in a system are integrated and the system is tested as a whole System testing should focus on testing component interactions
use-case testing
testing policies
Release testing
a separate testing team test a complete version of the system before it is released to users
system: bugs / release: check requirements
requirement based testing
scenario testing
performance testing - operational profile/ Stress testing
User testing
users or potential users of a system test the system in their own environment
alpha - user and team at developer's site
beta - user experiment
acceptance-Customers
Week 11--Junit Testing
JUnit
AssertTrue/AssertFalse
AssertSame/AssertNotSame
AssertEquals/AssertNotEquals
AssertArrayEquals
AssertThrows
life circle
@BeforeAll
@BeforeEach
@AfterAll
@AfterEach
@DisplayName
@Timeout
@RepeatedTest
Week12 Project Management
Challenges
intangible, one-off, variable and organization-specific
Risk management
• Project risks: Risks that affect the project schedule or resources (e.g., loss of an experienced designer).
• Product risks: Risks that affect the quality or performance of the software being developed (e.g., failure of a purchased component to perform as expected).
• Business risks: Risks that affect the organization developing or procuring the software (e.g., a new product from competitors).
阶段
• Risk identification: identify possible project, product, and business risks
• Risk analysis: assess the likelihood and consequences of these risks
probability
seriousness
• Risk planning: plans to address the risk, either by avoiding it or minimizing its effects on the project
Avoidance strategies, Minimization strategies, Contingency plans
• Risk monitoring: regularly assess the risk and your plans for risk mitigation and revise these when you learn more about the risk
managing people
4 critical factors: Consistency, Respect, Inclusion, Honesty
people type: Task/Self/Interaction-oriented people
Software team
a closed/random/open/synchronous paradigm
efficiency influence by: Group size/Group structure/Group composition/The physical work environment/ The available communication channels