1 Software and Software Engineering
1.1 Software Definition
Software is:
- (1) instructions (computer programs) that when executed provide desired features, function, and performance;
- (2) data structures that enable the programs to adequately manipulate information and
- (3) documentation that describes the operation and use of the programs.
1.2 SE Definition
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.
1.3 SE Core Element
- tools
- methods
- process model
1.4 SE General Principles
- The Reason It All Exists
- KISS (Keep It Simple, Stupid!)
- Maintain the Vision
- What You Produce, Others Will Consume
- Be Open to the Future
- Plan Ahead for Reuse
- Think!
2 Process Model
2.1 Software Process Definition
A process is a collection of activities, actions, and tasks that are performed when some work product is to be created.
1. Framework Activities
- Communication
- Planning
- Modeling
- Analysis of requirements
- Design
- Construction
- Code generation
- Testing
- Deployment
2. Umbrella Activites
2.2 The Waterfall Model
Waterfall model is a classic linear model driven by document. Divided into a series of stages, each stage has a document saving, the purpose is to save the work, find problems, and solve our problems as soon as possible.
- The Waterfall model proposes a systematic, sequential approach to software development, starting from the specification of user requirements, through the process of planning, modeling, building and deployment, and finally providing complete software support.
Disadvantages
- Real projects rarely follow the sequential work flow that the model proposes.
- It is often difficult for the customer to state all requirements explicitly at the beginning of most projects.
- The customer must have patience because a working version of theprogram(s) will not be available until late in the project time span.
- Major blunders may not be detected until the working program is reviewed.
Suitable
- Suitable for products that require little change.
2.3 Prototyping Process Model
A prototype is an executable version of the intended system that reflects a selected subset of the system's properties (e.g. functionality, computation results, etc.).
Advantages
- Quickly develop a demonstrable system to facilitate customer communication.
- Adopting iterative techniques enables developers to gradually get to the real needs of customers.
Disadvantages
- Developers may not consider software quality and long-term maintainability, which may make imperfect choices an integral part of the system.
Suitable
- Suitable for software with ambiguous requirements.
2.4 Evolutionary Models: The Spiral
The spiral model is a risk-driven process model driver that adds to the risk assessment
Suitable
- Suitable for large internal projects with more risks.
2.5 The Incremental Model
Suitable
- Suitable for lack of developers and strict deadlines.
2.6 The Unified Process (UP)
UML（Unified Modeling Language）
UP Work Products
2.7 Comparison of Models
3 AGILITY AND PROCESS
3.1 Manifesto for Agile Software Development
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
3.2 Advantages and Disadvantages
- Advantages: The ability to reduce the cost of changes through software processes; High speed; Accept changes; High flexibility
- Weaknesses: It is difficult to carry out accurate resource planning; It's hard to define lightweight documents; It is difficult to predict a finite end point
Agile processes use incremental development strategies, delivering software increments in short time intervals to accommodate the pace of change.
Agile processes can reduce the cost of change, and change can be better controlled within the increment.
3.3 Scrum
The Scrum team is a self-organizing interdisciplinary team consisting of a product owner, a Scrum master, and a small (three to six people) development team. The principle Scrum artifacts are the product backlog, the sprint backlog, and the code increment. Development proceeds by breaking the project into a series of incremental prototype development periods 2 to 4 weeks in length called sprints.
3.4 Extreme Programming (XP)
3.5 Kanban
3.6 DevOps
4 Software Maintenance
4.1 Definition
After the software is accepted and delivered in the end-user environment, the activities necessary to keep the software running continue until the end of the software lifecycle.
4.2 Four Types
- Corrective maintenance (21%)
- Adaptive maintenance (25%)
- Perfective maintenance (50%)
- Preventive maintenance (4%)
5 Requirements Engineering
5.1 Definition
Requirements engineering refers to the large number of tasks and techniques dedicated to continuously understanding requirements.
5.2 Seven Tasks
Inception, Elicitation, Elaboration, Negotiation, Specification, Validation, and Requirements Management.
6 Requirements Modeling
6.1 Requirements Modeling
- Scenario-based
- Data
- Class-oriented
- Flow-oriented
- Behavioral
6.2 UML
- Classes Diagram
- Use-Cases Diagram
- State Diagram
- Sequence Diagram
7 Design Concepts
7.1 Quality Guidelines
- A design should exhibit an architecture that (1) has been created using recognizable architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashion
- A design should be modular; that is, the software should be logically partitioned into elements or subsystems
- A design should contain distinct representations of data, architecture, interfaces, and components.
- A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns.
- A design should lead to components that exhibit independent functional characteristics.
- A design should lead to interfaces that reduce the complexity of connections between components and with the external environment.
- A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.
- A design should be represented using a notation that effectively communicates its meaning.
7.2 Cohesion (High is Better)
1. 功能内聚（Functional Cohesion）
- 如果一个模块内所有处理元素完成一个，而且仅完成一个功能，则称为功能内聚。
- 功能内聚是最高程度的内聚。但在软件结构中，并不是每个模块都能设计成一个功能内聚模块。
2. 顺序内聚（Sequential Cohesion）
- 如果一个模块内处理元素和同一个功能密切相关，而且这些处理元素必须顺序执行，则称为顺序内聚。
3. 通信内聚（Communicational Cohesion）
- 如果一个模块中所有处理元素都使用同一个输入数据和（或）产生同一个输出数据，称为通信内聚。
4. 过程内聚（Procedural Cohesion）
- 如果一个模块内的处理元素是相关的，而且必须以特定的次序执行，称为过程内聚。
- 过程内聚与顺序内聚的区别是：顺序内聚中是数据流从一个处理单元流到另一个处理单元，而过程内聚是控制流从一个动作流向另一个动作。
5. 时间内聚（Temporal Cohesion）
- 如果一个模块包含的任务必须在同一段时间内执行，称为时间内聚。也称为瞬时内聚。
6. 逻辑内聚（Logical Cohesion）
- 如果模块完成的任务在逻辑上属于相同或相似的一类，称为逻辑内聚。
7. 偶然内聚（Coincidental Cohesion）
- 如果一个模块由完成若干毫无关系的功能处理元素偶然组合在一起的，就叫偶然内聚。
7.3 Coupling (Low is better)
1. 内容耦合（Content Coupling）
如果发生下列情形，两个模块之间就发生了内容耦合。
- 一个模块直接访问另一个模块的内部数据；
- 一个模块不通过正常入口转到另一模块内部；
- 两个模块有一部分程序代码重叠(只可能出现在汇编语言中)；
- 一个模块有多个入口。
2. 公共耦合（Common Coupling）
若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
3. 控制耦合（Control Coupling）
如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
4. 印记耦合（Stamp Coupling）
如果一组模块通过参数表传递记录信息，就是标记耦合。它是某一数据结构的子结构，而不是简单变量。
5. 数据耦合（Data Coupling）
如果一个模块访问另一个模块时，彼此之间是通过数据参数（不是控制参数、公共数据结构或外部变量）来交换输入、输出信息的，则称这种耦合为数据耦合。
6. 非直接耦合（Nondirect Coupling）
如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最强。
8 Architectural Design
8.1 Definition
Architectural design represents the structure of data and program components that are required to build a computer-based system. It considers the architectural style that the system will take, the structure and properties of the components that constitute the system, and the interrelationships that occur among all architectural components of a system.
8.2 Importance
- Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system.
- The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.
- Architecture “constitutes a relatively small, intellectually graspable mode of how the system is structured and how its components work together” [BAS03].
8.3 Architectural Styles
- Data-centered architectures
- Data flow architectures
- Call and return architectures
- Object-oriented architectures
- Layered architectures
8.4 MVC Architecture
- MVC is the Model (Model), View (View), Controller (Controller) shorthand, is a software design specification.
- is a way to organize code by separating business logic, data, and display.
9 Component-Level Design
9.1 Definition
- A complete set of software components is defined during architectural design. But the internal data structures and processing details of each component are not represented at a level of abstraction that is close to code.
- Component-level design defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each soft-ware component.
9.2 Basic Design Principles
- The Open-Closed Principle (OCP).
- The Liskov Substitution Principle (LSP).
- Dependency Inversion Principle (DIP).
- The Interface Segregation Principle (ISP).
- The Release Reuse Equivalency Principle (REP).
- The Common Closure Principle (CCP).
- The Common Reuse Principle (CRP).
9.3 Component Level Design
- Step 1. Identify all design classes that correspond to the problem domain.
- Step 2. Identify all design classes that correspond to the infrastructure domain.
- Step 3. Elaborate all design classes that are not acquired as reusable components.
- Step 3a. Specify message details when classes or component collaborate.
- Step 3b. Identify appropriate interfaces for each component.
- Step 3c. Elaborate attributes and define data types and data structures required to implement them.
- Step 3d. Describe processing flow within each operation in detail.
- Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage them.
- Step 5. Develop and elaborate behavioral representations for a class or component.
- Step 6. Elaborate deployment diagrams to provide additional implementation detail.
- Step 7. Factor every component-level design representation and always consider alternatives.
9.4 Modeling design
- IOC pseudo-code description
- AOP pseudo-code description
10 Software Testing Component-Level
10.1 Unit Testing Module to be Tested
- interface
- local data structures
- boundary conditions
- independent paths
- error handling paths
10.2 White-Box Testing
- Test internal logic, internal perspective.
- Basic path testing: Drawing flow diagrams, calculating ring complexity, finding independent paths, designing test cases
10.3 Black-Box Testing
- Test software running, external perspective.
- Equivalence class partition, boundary value analysis.
11 Software Testing Integration-Level
11.1 Nonincremental Integration
11.2 Incremental Integration
1. Top Down Integration
Start with the master module, the modules belonging to the master module are integrated into the structure in a depth-first or breadth-first manner.
2. Bottom-Up Integration
Start with the atomic module to build and test.
11.3 Continuous Integration (Smoke Testing)
Continuous integration is the practice of merging components into the evolving soft-ware increment once or more each day.
Advantages
- Accelerate feedback, improve quality, reduce risk, and improve reporting
11.4 Regression Testing
- Regression testing may be conducted manually, by re-executing a subset of all test cases or using automated capture/playback tools.
High Order Testing
- Validation testing - Focus is on software requirements
- System testing - Focus is on system integration
- Alpha/Beta testing - Focus is on customer usage
- Recovery testing - forces the software to fail in a variety of ways and verifies that recovery is properly performed
- Security testing - verifies that protection mechanisms built into a system will, in fact, protect it from improper penetration
- Stress testing - executes a system in a manner that demands resources in abnormal quantity, frequency, or volume
- Performance Testing - test the run-time performance of software within the context of an integrated system
12 Software Configuration Management
12.1 SCM Definition
Software Configuration Management (SCM) is a set of activities for managing change.
12.2 Four Elements
- Component elements
- Process elements
- Construction elements
- Human elements
12.3 Baseline Definition
A baseline is a milestone in the development of software that is marked by the delivery of one or more software configuration
12.4 Repository Features
- Versioning.
- Dependency tracking and change management.
- Requirements tracing.
- Configuration management.
- Audit trails.
12.5 Version Control
Version control combines procedures and tools to manage different versions of configuration objects that are created during the software process
A version control system implements or is directly integrated with four major capabilities:
- a project database (repository) that stores all relevant configuration objects
- a version management capability that stores all versions of a configuration object (or enables any version to be constructed using differences from past versions);
- a make facility that enables the software engineer to collect all relevant configuration objects and construct a specific version of the software.
- an issues tracking (also called bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object.
12.6 Change Control
13 Creating a Viable Software Plan
13.1 The Project Planning Process
- Establish project scope
- Determine feasibility
- Analyze risks
- Define required resources
- Determine require human resources
- Define reusable software resources
- Identify environmental resources
- Estimate cost and effort
- Decompose the problem
- Develop two or more estimates using size, function points, process tasks or use-cases
- Reconcile the estimates
- Develop a project schedule
- Establish a meaningful task set
- Define a task network
- Use scheduling tools to develop a timeline chart
- Define schedule tracking mechanisms
- Repeat steps 1 to 6 to create a detailed schedule for each prototype as the scope of each prototype is defined.
13.2 Scheduling Principles
- Compartmentalization — define distinct tasks
- Interdependency — indicate task interrelationship
- Time allocation — each task must be allocated some number of work units( person-day of effort)
- Effort validation — be sure resources are available
- Defined responsibilities — people must be assigned
- Defined outcomes — each task must have an output
- Defined milestones — review for quality
13.3 Schedule Tracking
- Conduct periodic project status meetings in which each team member reports progress and problems.
- Evaluate the results of all reviews conducted throughout the software engineering process.
- Determine whether formal project milestones have been accomplished by the scheduled date.
- Compare actual start-date to planned start-date for each project task listed in the resource table .
- Meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon.
- Tracing the project velocity.
