Introduction to Software Engineering Review Notes

Software Engineering Introduction Review#

Chapter 0#

Software Engineering Proposal Time: 1968

In 1968, computer scientists from the North Atlantic Treaty Organization (NATO) held an international conference in West Germany to discuss the software crisis and formally proposed "Software Engineering."

Chapter 1#

The nature of software
Developed / Deteriorates / Custom built / Complex

Chapter 2#

Definition of Software Engineering
1. The application of a systematic,
  disciplined, quantifiable approach to the
  development, operation, and maintenance
  of software; that is, the application of
  engineering to software.
2. The study of approaches as in (1).
Software Process
- why: Timely feedback is needed
- Process framework
  - Framework activities
    - Communication
    - Planning
    - Modeling
      1. Requirements Analysis
      2. Design
    - Construction
      1. Code
      2. Testing
    - Deployment
  - Umbrella Activities
    - Software project tracking and control
    - Risk management
    - Software quality assurance
    - Technical reviews
    - Measurement
    - Software configuration management
    - Reusability management
    - Work product preparation and production
Software Lifecycle
- Software has a life cycle of conception, birth, growth, maturity, and decline. This process is known as the software lifecycle.
- why need
  - To decompose the complex issues of software development and maintenance from a time perspective, dividing the long lifecycle of software into several stages, each with relatively independent tasks, and then gradually completing the tasks of each stage.
  - To provide a common framework for software professionals to facilitate mutual communication.

Chapter 4#

Evolutionary Models
- Prototype
  - Types
    - Exploratory Prototyping: Clarifying requirements
    - Experimental Prototyping: Validating solutions
    - Evolutionary Prototyping
  - Characteristics
    - Can be run practically
    - It does not have a fixed lifespan. It may be discarded or become part of the final product.
    - Can prototype for different goals
    - Fast, inexpensive
    - Is an integral part of the iterative process, modified and run after each user evaluation, continuously repeating until both parties agree.

Chapter 5#

Agile Manifesto
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

Chapter 7#

Requirements Engineering#

Inception
Elicitation
Elaboration
Negotiation
Specification
- Based on the results of requirements investigation and analysis, further define accurate product requirements, producing the "Product Requirements Specification."
Validation
Requirements management

Quality Function Deployment#

Function Deployment - Determine the value of system functions
Information Deployment - Identify data objects and events
Task Deployment - Define system behavior
Value Analysis - Determine the priority of requirements

Non-Functional Requirements#

Quality attribute
Performance attribute
Security attribute
General system constraint

Diagrams#

Use-case / Class / State / Activity

Chapter 11#

Analysis Model
- Focus on describing required data, function, and behavior

Design Model#

Provide detail about software data structure, architecture, interfaces, and components
4 kinds
- Data/Class Design - Transform analysis classes into implementation classes and data structures
- Architectural Design - Define relationships between major software structural elements
- Interface Design - Define how software elements, hardware elements, and end users communicate
- Component-Level Design - Describe the process of transforming structural elements into software components

Concepts#

Architecture - The overall structure of the software
- Reflects the system's modularity, abstraction, information hiding, and interface design
- Examples
  - Client-Server Architecture
  - Microservices Architecture
  - Event-Driven Architecture
  - Layered Architecture
Pattern
- The goal of a pattern: easy to reuse.
- Types:
  - Architecture Pattern
    - B/S, C/S
  - Design Pattern
  - Idiom
    - A low-level pattern specific to a programming language
Functional Independence
- Cohesion
  - An indication of the relative functional strength of a module
  - Functional cohesion, layer cohesion, communication cohesion, sequential cohesion, procedural cohesion, temporal cohesion, utility cohesion (ranked from high to low)
- Coupling
  - An indication of the relative interdependence among modules
  - Non-direct coupling, data coupling, label coupling, control coupling, external coupling, shared coupling, content coupling (ranked from low to high)
- Goal: High cohesion, low coupling

Chapter 12 Behavioral Modeling#

What
The structure of the system, which comprises the software components, the externally visible properties of those components, and the relationships among them
The Importance of Architecture
- For communication between all parties (stakeholders)
- Highlights early design decisions
- Constitutes a relatively small, intellectually graspable model
What is the use of architecture
- Analyze the effectiveness of design in meeting its specified requirements
- Consider architectural alternatives more easily during the relatively early stages of design changes
- Reduce risks associated with software construction

Architecture Style#

Definition Content
- A set of components that perform the required functions of the system
- A set of connectors that enable "communication, coordination, and cooperation among components"
- Define constraints on how components integrate to form the system
- Semantic model that allows designers to understand the overall properties of the system by analyzing the known characteristics of its components
Types
- Data Flow Architecture - Batch processing, pipes, and filters
- Call and Return Architecture - Main program/subprogram, object-oriented systems, layered systems
- Independent Component Architecture - Event systems, triggers, monitors
- Virtual Machine Architecture - Interpreters, rule-based systems
- Repository Architecture - Database systems, blackboard systems, etc.

Chapter 13 Component Level Design#

A modular, deployable, replaceable part of the system that encapsulates implementation and exposes a set of interfaces.

Basic Design Principles#

Open/Closed Principle (OCP) - A module [component] should be open for extension but closed for modification
Liskov Substitution Principle (LSP) - "Subclasses should be able to replace their base classes."
Dependency Inversion Principle (DIP) - Depend on abstractions. Do not depend on entities
- High-level modules should depend on abstractions (interfaces or abstract classes)
- Abstractions should not depend on concrete implementations; concrete implementations should depend on abstractions
Interface Segregation Principle (ISP) - Many specialized interfaces are better than one general-purpose interface
Release Reuse Equivalence Principle (REP) - The granularity of reuse is the granularity of release
Common Closure Principle (CCP) - Classes that change together should be packaged together
Common Reuse Principle (CRP) - Classes that cannot be reused together should not be packaged together

Chapter 14 User Interface Design#

Golden Rules
- User controls operations
- Reduce user memory load
- Keep the interface consistent

Chapter 15-16 Software Quality#

What is Software Quality
An effective software process that creates a useful product in a way that provides measurable value to those who produce and use it
McCall’s Triangle of Quality
- Product modification
- Product transition
- Product operation
The Cost of Quality
- The cost of correcting errors and defects during testing and maintenance phases increases dramatically
- Types:
  1. Prevention costs (COP)
  2. Appraisal costs (COA)
  3. Internal failure costs
  4. External failure costs

Chapter 17-19. Testing Strategy & Techniques#

Verification vs. Validation
- Verification: Ensures the software can perform specific functions building the product right
- Validation: Ensures the software is traceable to customer requirements building the right product
Testing Strategy - From small to large
- Unit Testing
- Integration Testing
- System Testing
- Acceptance Testing
  - α testing conducted by end users at the developer's site
  - ß testing conducted at the end user's site

Testing Strategy for Unit Testing#

Content:
- Interfaces
- Local data structures
- Boundary conditions
- Independent paths
- Error handling paths
Stub - Replaces the lower level
Driver - Replaces the top level
- Provides a framework for setting input parameters, environment, and executing the unit

Testing Strategy for Integration Testing#

Top Down Integration
- Advantage
  - A skeletal version of the program can exist early and allows demonstrations
  - Design errors may be found sooner.
  - Reduces the need for test drivers
  - It tends to make fault location easier
- Disadvantage
  - Stubs could be expensive to build.
Bottom-Up Integration
- Advantage
  - Particularly useful for objects and reuse.
  - Requiring no structural design information
- Disadvantage
  - The program as a whole does not exist until the last module is added.
  - Requires test drivers, not test stubs.

Testing Strategy for System Testing - Fully Utilize Computer-Based Systems#

Purpose:
- Test the entire system in the real environment where it will run
- Ensure the system meets overall operational requirements
- Also test aspects beyond system functionality
- Results are sometimes used for system acceptance
- Validate the software user manual
- Estimate reliability and maintainability

Testing Methods#

Black Box Testing (Functional)
White Box Testing (Structural)

Chapter 21 Software Configuration Management#

The SCM Process#

Identification
Change Control
Version Control
Configuration Auditing
Reporting

Software Configuration Item

Chapter 22 Project Management Concept#

4 P's#

People
Product
- Scopes
  1. Context
  2. Information objectives
  3. Function and performance
Process
- Consider project characteristics
- Determine the degree of rigor required
- Define a task set for each software engineering activity
Project
1. Start work from the right foundation - first by understanding the problem to be solved, then setting realistic goals and expectations
2. Maintain motivation - project managers must provide incentives, keep personnel turnover to a minimum, and the team should emphasize quality in every task they perform, while senior management should stay as far away from the team as possible
3. Track progress - as part of quality assurance activities, progress will be tracked as work products (e.g., models, source code, test case sets) are generated and approved (using formal technical reviews).
4. Make informed decisions - decisions made by project managers and software teams should be "keep it simple"
5. Conduct post-mortem analysis - establish a consistent mechanism to extract lessons learned from each project

W5HH#

Why is the system being developed? - Why
What will be done? - What
When will it be accomplished? - When
Who is responsible? - Who
Where are they organizationally located? - Where are others' organizational structures located
How will the job be done technically and managerially? - How to complete technical and managerial work
How much of each resource (e.g., people, software, tools, database) will be needed? - How much of each resource is needed

Task Set =#

Software engineering tasks
Work products
Quality assurance points
Milestones

Software Engineering Activity#

Requirements Analysis
Design
Software Development
Software Deployment
Software Maintenance
Project Management
Quality Assurance
Configuration Management
Documentation

Chapter 23 Process and Project Metrics#

Significance
1. Assess the status of ongoing projects
2. Track potential risks
3. Identify risks before they cause adverse effects
4. Adjust workflows or tasks
5. Assess the project team's ability to control the quality of software work products

Process Measurement#

Measurement is based on a series of data obtained during the process or the characteristics of software engineering tasks.
Software Process Improvement (SPI)
5 Metrics
- Quality-related
- Productivity-related
- Statistical SQA data
- Defect removal efficiency
- Reuse data

Project Metrics#

Three aspects
- Timeliness
- Quality
- Cost

Chapter 24-25 Project Estimation & Scheduling#

Scope#

Scope refers to all the work involved in creating the products of the project and the processes used to create them. It defines what is or is not to be done.
Content of project scope
- Functions and features delivered to the end user
- Input and output data
- "Content" presented to users due to the use of software
- Performance, constraints, interfaces, and the reliability of the constrained system

Work Breakdown Structure (WBS)#

Five methods for conducting WBS
1. Use guidelines: Guidelines provided by some organizations
2. Analogous method: Review the WBS of similar projects and customize it for our project.
3. Top-down approach: Start with the largest projects in the project and break them down
4. Bottom-up approach: Start with detailed tasks and aggregate them
5. Mind mapping method: Write down tasks in a nonlinear format, then create the WBS structure

Estimation Methods#

Line of code-based estimation
- Advantages: Easy to measure, easy to automate
- Disadvantages: Limited to code, cannot be used for design, depends on language, does not consider the complexity of functionality, tied to the quality of design
Function point-based estimation
- Advantages:
  1. Can be used in the earliest stages of requirements
  2. Independent of programming language, product design, or development style
  3. User view, rather than implementation view
  4. Can be used to measure non-coding activities
  5. A wealth of historical data exists
  6. Well-documented
- Disadvantages:
  1. Cannot directly calculate the FP content of existing products (source code)
  2. Difficult to automate
  3. FP does not reflect differences in language, design, or style
  4. FP is designed for estimating commercial data processing applications
  5. Subjective counting

Project Scheduling#

Why do projects get delayed?
Unrealistic deadlines
Changes in requirements
Underestimating workload
Unpredictable risks
Technical challenges
Human difficulties
Poor communication
Failure to recognize that the project is behind schedule or lack of corrective action
Principles of scheduling
Decomposition - Define multiple distinct tasks
Interdependencies - Clarify the relationships between tasks
Workload confirmation - Ensure human resources are available
Determine responsibilities - Clarify who is responsible
Define output results - Determine the outcomes of activities
Identify milestones - Conduct quality reviews
Steps in scheduling
1. Define task set - WBS
2. Arrange activities
3. Draw project network diagram
4. Critical path analysis
5. Schedule using Gantt charts
6. Track progress

Chapter 26 Risk Management#

Reactive Risk Management
Proactive Risk Management
- Formal risk analysis is performed
- Corrects the root causes of risk
Risk Management Paradigm
1. Risk identification
2. Risk analysis
3. Risk planning
4. Risk monitoring
RMMM
- Mitigation
- Monitoring
- Management

Common Diagrams#

Use Case Diagram
Class Diagram
Activity Diagram
- Variant: Swimlane Diagram
Sequence Diagram