虽然本科的时候学过软件工程，但是知识早已忘光。因此我希望将这学期所学到的内容记录下来。

Week 1

1. Evolution of Software Engineering:
   • Waterfall Approach;
   • Iterative & Incremental Approach:
     • Work is prioritized based on risk;
     • Examples: Spiral, Rational Unified Process (RUP).
   • Agile Approach:
     • Work is prioritized based on value;
     • Examples: XP, Scrum, Feature-Driven Development (FDD), Dynamic System Development Method (DSDM), Adaptive Software Development (ASD), Crystal Method.
     • Key barrier: Inability to change organization culture.
   • Lean Approach:
     • Optimize flows by reducing waste; Main prioritization criteria is still value;
     • From Toyota;
     • Examples: Lean, Kanban.
   • Hybrid Approach:
     • Examples: Scrumban, Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD).
2. Agile:

1. XP:
   • Test first, pair programming, incremental design.
2. Other:
   • Scrum has “product owner”, “development team” and “Scrum master”, while Kanban has no roles;

Week 2

1. Iron Triangle for Planning (Project Constraints):
   • Fixed-scope: Then variables are time and cost;
   • Fixed-date: Then varaible is scope.

1. Definition of “Done” (DOD): two columns: Task/Action, Quality Check, or just one column like the ones on Trello;
2. People usually underestimate by a factor of 2;
3. Planning Poker combines analogy, disaggregation and expert judgment.

Week 3

1. Four principles of OO:
   • Abstraction: Essential characteristics of an entity relative to certain perspective; Manage complexity by eliminating details;
   • Encapsulation: Facilitate information hiding; Manage complexity by grouping related elements into a single entity;
   • Hierachy: Ranking or ordering entities into a tree-like structure; Manage complexity by organizing into this tree-like structure:
     • Aggregation: is-part-of;
     • Inheritance: is-a-kind-of, implements polymorphos, which means having many forms;
   • Modularity: Manage complexity by breaking large entities into smaller, independent and cohesive modules (low coupling, high cohesion).
2. Apart from aggregation and inheritance, there’s association (knows-about relation);

Week 4

1. Analysis vs Design:
   • Analysis:
     • Focus on understanding the problem: WHAT;
     • Define behavior and structure;
     • Analysis classes, interaction diagrams, class diagrams.
   • Design:
     • Focus on understanding the solution: WHY;
     • System design: Define a robust architecture (Use case view, logical view, development view, process view, deployment view);
     • Object design: Refine the design of components and classes for easy implementation (Design patterns).
   • OOAD is architecture-centric. OOAD toolset can be leveraged as needed to create “good enough” models.
2. View of Participating Classes (VOPC).

Week 5

1. Design patterns: Singleton; Bridge; Observer; Composite; Facade; Strategy; Factory Method; Adapter.
2. Hierarchy in Design Pattern (most basic mechanisms): Inheritance and Delegation;
3. SOLID Principles:
   • Single responsibility;
   • Open-closed principle: Open to extension, closed to modification;
   • Liskov’s substitution: One class can only be treated as a subtype of another if it can be substituted for the super class in every context;
   • Interface segregation: interfaces should be small and specialized;
   • Dependency Inversion;
4. Other Principles:
   • Dependency injection: link;
   • Inversion of control principle: Traditionally, we write main function which controls the flow; Now we use framework, we just fill in the blanks. Framework controls the flow.
5. 7 ± 2 Rules: Number of subsystems, partitions, layers, functions per subsystem, components per subsystem should be no more than 9.
6. Architectural styles and patterns:
   • Architectural styles: Emphasize on organization, control flow, communication; More high level; Examples: Layered, pipe-and-filter, repository, client-server, peer-to-peer, event-based, hybrid/heterogeneous: compiler, REST, MVC;
   • Architectural patterns: Solve problems like security, federation, integration…;
7. Decomposition: Partitioning should increase cohesion, and layering should reduce coupling.

Week 6

1. Technical practices: Pair programming, in-process testing, refactoring, version control (Diff based: CVS, SUBVERSION, file-based: git, mercurial / Centralized, distributed), continuous integration, incremental delivery.

Week 7

1. Testing is a whole-team responsibility;
2. Components:
   • Entity Under Test (EUT);
   • Fixture: Test driver, test stub;
   • Test case:
     • Inputs or stimuli (triggers);
     • Oracle (expected behavior);
     • Outputs or results;
     • Assessment;
     • Verdict (pass or fail).
3. Others:
   • Test suite: collection of test cases;
   • Not all testing needs an oracle;
   • White-box testing misses unimplemented behaviors;
   • Black-box testing may miss unexpected behaviors;

Week 8

1. Only intentional short-term focused debt and intentional long-term debt are healthy.

Week 9

1. Defect repairs (maintenance) are usually the largest annual cost;
2. Fight against defects:
   • Defect prevention: Reuse, formal inspection;
   • Pre-test defect removal: Formal inspection, static analysis, Scrum daily stand-up meetings;
   • Testing defect removal: Software testing has low defect removal efficiency;
3. Best practice: Review fewer than 200-400 lines of code at a time, no more than 60-90 minutes at a time, inspection rate less than 300-500 LOC / hour at a time.

Week 10

1. Requirements Envisioning:
   • Functional Requirements: Using Use Cases or User Stories;
     • INVEST criteria for stories: Independent, Negotiable, Valuable, Estimable, Small, Testable;
     • SMART criteria for tasks: Specific, Measurable, Achievable, Relevant, Time-boxed;
   • Non-Functional Requirements: Using Shall Statements or User Stories;
   • Validation: Using Prototypes;
   • Planning: Using Roadmaps and Backlogs;
2. Requirements Elaboration (just-in-time elaboration):
   • Use Case Specification (Basic Flow, Alternatives Flows);
   • User Story Acceptance Criteria (Given / When / Then);
   • Planguage for Non-Functional Requirements;

Week 11

1. External Qualities (Performance) & Internal Qualities (Testability);
2. Qualities Attributes of Architectural Styles:

1. Design patterns generally improve the expandability of code, and decrease reusability;
2. Quality Attribute Tradeoffs are asymmetric.

Others

1. The behavior of the system can be modeled using a UML Use-case diagram, Sequence diagram and Communication diagram.
2. The Facade pattern needs only delegations.
3. ES6 does not support class­-based inheritance.
4. Refactoring is enabled by in-process testing.
5. To be able to effectively test asynchronous behavior, we must isolate the behavior in a function, and make the side effect accessible to a test.
6. Technical debt is not incurred to save money in the long term.
7. “Feature debt”, or features in the backlog is not a type of technical debt.
8. Grace Hopper first came up with the term “bug”.
9. Latent defects: unknown defects, fixed defects, unfixed known defects.