Software Engineering Essentials: Concepts & Methodologies

Posted on Jul 10, 2025 in Software Engineering

Software Engineering Fundamentals

Software consists of computer programs and associated documentation. It can be developed for a particular person or a general market.

What is Software?

Software refers to computer programs and their associated documentation. It can be tailored for a specific individual or designed for a general market.

Software Attributes

Software should provide the required functionality and performance for the user. It must also be maintainable, dependable, and usable.

Software Engineering Defined

Software Engineering (SE) focuses on creating, developing, and maintaining software systems.

SE Activities

• Specification: Defining what the software should do.
• Development: Building the software.
• Validation: Checking if the software meets requirements.
• Evolution: Adapting the software to new needs.

Computer Science vs. Software Engineering

• Computer Science (CS) focuses on the theory and fundamentals of computing.
• Software Engineering (SE) focuses on the practicalities of developing software.

System Engineering

System Engineering is part of a more general process, focusing on all aspects of computer-based systems, including hardware, software, and process engineering.

Key Challenges in SE

• Managing diverse systems.
• Reducing the time to create software.
• Ensuring software is trustworthy.

Attributes of Good Software

• Maintainability: Should be written in a way that allows it to evolve easily.
• Security: Systems should be designed to prevent physical or economic damage if they fail.
• Efficiency: Should be efficient and not waste system resources.
• Acceptability: Should be understandable, usable, and compatible with other systems.

General Software Issues

• Heterogeneity
• Business change
• Security concerns
• Scale of development

Software Application Types

• Stand-alone applications
• Interactive transaction-based systems
• Embedded control systems
• Batch processing systems
• Entertainment software
• Modeling and simulation software
• Data collection systems
• Systems of systems

ACM/IEEE Code of Ethics

Professionals from the US cooperate to create a code of ethics based on 8 principles:

1. Public: Act with the public interest in mind.
2. Client and Employer: Act in the best interests of the client and employer.
3. Product: Strive to meet the highest possible standards for the product.
4. Judgment: Maintain integrity and independence in professional judgment.
5. Management: Subscribe to and promote an ethical approach to management.
6. Profession: Advance the integrity and reputation of the profession, with the public interest.
7. Colleagues: Be fair and supportive to colleagues.
8. Self: Commit to lifelong learning.

The Software Development Process

The software process involves specification, development, validation, and evolution.

Software Process Phases

• Specification: Defining what the software should do.
• Development: Building the software.
• Validation: Checking if the software meets requirements.
• Evolution: Adapting the software to new needs.

Plan-Driven vs. Agile Processes

• Plan-Driven: Processes are planned extensively in advance.
• Agile: Planning is incremental, and the process is easier to change and adapt.

Software Process Models

• Waterfall Model (Plan-Driven):
  • Pros: Simple management model.
  • Cons: Difficult to change artifacts and products once defined.
• V-Model:
  • Pros: Explicitly shows dependency between development and Verification & Validation (V&V) activities.
  • Cons: Similar rigidity to the Waterfall model.
• Incremental Development:
  • Pros: Easier to accommodate changes, easier to get feedback, rapid delivery and development.
  • Cons: Process visibility can be low, system structure may degrade as new increments are added.
• Integration and Configuration:
  • Pros: Cheaper and less risky as components are pre-existing, faster development.
  • Cons: The system may not fully meet unique requirements, potential loss of control over evolution.

Software Design & Implementation

This stage involves turning the requirements into a working program.

Design Activities

• Architectural design
• Database design
• Interface design
• Component selection and design

Software Validation

Software validation checks if the software works correctly and meets its specified requirements.

Software Evolution

Software evolution involves updating the software to meet new needs. Processes may be structured into iterative development and delivery to ensure changes do not disrupt the system.

Agile Software Development

Rapid Software Development

Rapid software development is often the most important requirement for software systems. While plan-driven essentials are sometimes necessary, the primary aim is to reduce development time.

Agile Development Principles

In Agile development, program specification, design, and implementation are interleaved. Software is developed as a series of versions, with minimal documentation focused on delivering working code. Key aspects include:

• User stories for system specification.
• Frequent software releases.
• Continuous software improvement.
• Test-first development.
• Customer participation in the development team.

Key Agile Techniques

Extreme Programming (XP)

XP introduced various agile methods and techniques, taking an an extreme approach to iterative development. Its principles include:

• Incremental planning
• Small releases
• Simple design
• Test-first development
• Refactoring
• Pair programming
• Collective ownership
• Continuous integration
• Sustainable pace
• On-site customer presence

SCRUM Methodology

SCRUM is an agile method focused on iterative development, rather than specific agile practices. It is centered around a set of sprints, which are fixed periods during which a system increment is implemented. Phases include:

• Initial phase
• Sprint cycle
• Project closure

SCRUM Terminology

• Development Team: Cross-functional team responsible for delivering the product increment.
• Potentially Shippable Product Increment: The result of a sprint, a usable and potentially releasable product.
• Product Backlog: A prioritized list of features, functions, requirements, enhancements, and fixes.
• Product Owner: Represents the stakeholders and is responsible for maximizing the value of the product.
• SCRUM: The framework itself.
• SCRUMMaster: Facilitates the SCRUM process and removes impediments.
• Sprint: A time-boxed period (typically 2-4 weeks) during which a ‘Done’, usable, and potentially releasable product increment is created.
• Velocity: A measure of the amount of work a team can accomplish in a single sprint.

Benefits of SCRUM

• The product is broken into manageable and understandable chunks.
• Increased communication due to everyone having access to information.
• Customers see on-time delivery, fostering trust.

Scaling Agile

• Scale Up: Applying agile methods to build large, complex software systems.
• Scale Down: Using agile methods within a large company with an established software history.

Core Agile Principles

• Customer involvement
• Embrace change
• Incremental delivery
• Maintain simplicity
• Focus on people, not just processes

Requirements Engineering

Defining Software Requirements

Requirements explain what a software system should do and any rules governing its operation. They are typically categorized into two types:

• User Requirements: High-level statements of what the user needs.
• System Requirements: Detailed descriptions of the system’s functions and constraints.

Functional Requirements

Functional requirements describe the specific tasks the system must perform. These depend heavily on the type of software being developed.

Non-Functional Requirements

Non-functional requirements set rules for how the system works. These can often be more critical than functional requirements, covering aspects like speed, security, reliability, and usability.

Requirements Engineering Process

The requirements engineering process is a repeating cycle that iterates between:

• Elicitation: Discovering what the system needs to do.
• Specification: Writing those needs down clearly.
• Validation: Checking that the specified requirements are correct and feasible.

Requirements Elicitation

Elicitation is a cyclical process involving:

• Discovering needs.
• Organizing them.
• Discussing and agreeing on them.
• Writing them down.

Methods to Gather Requirements

You can gather requirements using various techniques:

• Interviewing stakeholders.
• Ethnography (observing users in their natural environment).
• Creating user and system needs documents.

Requirements Specification

Requirements specification involves writing down what the system does based on user and system needs. The requirements must be understandable, and system requirements, in particular, must be detailed.

Specification Formats

Requirements can be written in various ways:

• Natural language
• Structured natural language
• Design descriptions
• Graphical notation (e.g., UML diagrams)
• Mathematical specifications

Requirements vs. Design

• Requirements: State what the system does.
• Design: Describes how the system does it.

Requirements Validation

Requirements validation involves checking that all requirements make sense, are complete, realistic, and can be tested.

Requirement Management

Requirement management is the process of tracking and handling business and requirements changes throughout the software lifecycle.

System Modeling in Software Engineering

Purpose of System Modeling

System modeling is used to illustrate the operational context of systems. It helps analysts understand the system and provides models for communication with customers.

System Perspectives

System models can be viewed from different perspectives:

• External: Showing the system’s context.
• Interaction: How the system interacts with users or other systems.
• Structural: The organization of the system’s components.
• Behavioral: How the system acts over time.

UML Diagram Types

Common UML (Unified Modeling Language) diagram types include:

• Activity diagrams
• Use case diagrams
• Sequence diagrams
• Class diagrams
• State diagrams

Context Models

Context models show how systems connect to their environment. Social and organizational concerns may affect where to position system boundaries.

System Boundaries

System boundaries explain what is inside and outside of the system. The position of these boundaries significantly affects the system requirements.

Interaction Models

Interaction models are crucial for understanding system behavior:

• Modeling user interaction helps identify user requirements.
• Modeling system-to-system interaction highlights potential communication problems.
• Modeling component interaction helps assess if the system design will work well and reliably.

Use Case Modeling

Use case modeling was originally developed to support requirements elicitation and is incorporated into UML. It shows how users and the system interact to achieve specific goals.

Structural Models

Structural models display the organization of a system in terms of its components and their relationships.

Class Diagrams

Class diagrams are used when developing an object-oriented system model to show the classes within a system and the associations between these classes.

Generalization

Generalization is a common technique used to manage complexity by identifying commonalities among different entities.

Behavioral Models

Behavioral models describe how the system acts over time.

• Activity Diagrams: Show steps in a process or workflow.
• State Diagrams: Illustrate how the system reacts to events and changes state.

Model-Driven Architecture (MDA)

MDA was a precursor to more general model-driven engineering. It uses models to automatically generate code, streamlining the development process.

Software Architectural Design

Architectural Design Overview

Architectural design is concerned with understanding how a system should be organized and designing its overall structure. The output of this process is an architectural model that describes how the system is organized as a set of communicating components.

Architectural Views

Architecture is typically shown in different views:

• Conceptual View: Provides a high-level, big-picture idea of the system.
• Logical View: Shows how parts of the system are connected and interact.
• Process View: Describes how the system runs and its runtime components.
• Development View: Illustrates how the system is built and maintained.

Architecture Patterns

Architecture patterns are reusable solutions for typical design problems. Patterns should include information about when they are useful and when they are not.

Model-View-Controller (MVC)

• Pros: Changes to data or appearance do not affect each other; the same data can be shown in different ways.
• Cons: Can introduce more code and increase complexity.

Layered Architecture Pattern

• Pros: A layer can be replaced without changing others.
• Cons: Can be hard to keep layers strictly separate; performance may slow down if there are too many layers.

The Repository Pattern

• Pros: Components are independent; changes are shared automatically.
• Cons: If the repository fails, the whole system can fail; can be slow; hard to split the repository across multiple computers.

Application Model Systems

Application model systems help in comparing systems, checking if a design is good, and reusing large parts in other projects.

Transaction Processing Systems

Transaction processing systems allow many users to work with a database simultaneously, ensuring data consistency.

Language Processing Systems

Language processing systems take a language and convert it into another, typically using a translator and an abstract machine.

Software Design and Implementation

Design and Implementation Stage

This is the stage in the software engineering process at which an executable software system is developed.

Design Models

Design models show the objects, object classes, and relationships between these entities, often including structural and dynamic models.

Object-Oriented Design Process

The object-oriented design process involves:

• Designing the overall architecture.
• Identifying the objects the system needs.
• Creating models to represent these objects and their interactions.
• Clearly defining interfaces so that components can work together seamlessly.

Interface Specifications

Object interfaces must be specified so that objects and other components can be designed in parallel, facilitating concurrent development.

Design Pattern Elements

Elements typically found in a design pattern description include:

• Name
• Problem description
• Solution description
• Consequences of applying the pattern

Applying Design Patterns

To effectively use patterns, you need to recognize that any design problem you face may have an associated pattern that can be applied. Examples include:

• Observer Pattern
• Facade Pattern
• Iterator Pattern
• Decorator Pattern

Software Reuse and Components

Software reuse aims to reduce effort and time by incorporating existing software components into new projects.

Host-Target Development

In host-target development, code is usually written on one computer (the host) and then run on another (the target) system, often for embedded systems.

Open Source Development

Open source development allows anyone to suggest changes to the code. This encourages collaboration and improvements from a global community. Examples of open-source systems include Linux, Java, Apache, and MySQL. For businesses, this method can be cheaper and quicker.

Open Source License Models

Common open-source license models include:

• GPL (General Public License)
• LGPL (Lesser General Public License)
• BSD (Berkeley Software Distribution)

Software Testing and Validation

Purpose of Software Testing

Testing is intended to be used before software deployment to find defects. It is a crucial part of the Verification & Validation (V&V) process. The primary goal is to demonstrate that the software meets its requirements and to identify problems.

Software Inspections

Software inspections involve people examining the source code to find errors. This method can reveal errors that might hide other mistakes and generally improves the quality of the code.

Stages of Testing

Software testing typically occurs in three main stages:

• Development testing
• Release testing
• User testing (Acceptance testing)

Development Testing

Development testing includes all testing activities carried out by the development team.

Unit Testing

Testing individual components or program units in isolation.

Object Class Testing

Testing operations with objects, including setting and interrogating object attributes, and exercising the object’s behavior.

Automated Testing

Using a test automation framework to write and run tests programmatically. Automated tests typically consist of three components:

• Setup: Preparing the test environment.
• Call: Invoking the code to be tested.
• Assertion: Verifying the expected outcome.

Testing Strategies

When testing, the goal is to try and break the software by using test cases likely to reveal problems.

Partition Testing

Identifying groups of inputs with similar characteristics that should be processed in the same way, and then selecting test cases from each partition.

Guideline-Based Testing

Using testing guidelines to choose test cases. It is highly recommended to write automated tests that run automatically whenever the code changes.

Component Testing

Software components are often composite, made up of several interacting objects. Testing involves accessing them through their defined component interface.

Interface Testing

Types of interface testing include:

• Parameter interface testing
• Shared memory interface testing
• Procedural interface testing
• Message passing interface testing

System Testing

System testing involves integrating components to create a version of the complete system and then testing it. The focus is on testing the interactions between components.

Use Case Testing

Use cases, developed to identify system interactions, can be used as a basis for deriving test cases.

Test-First Development

An approach to development where tests are written before the code to be tested, driving the implementation.

Scenario Testing

Involves inventing typical usage scenarios and using these to derive test cases.

Acceptance Testing

A user testing process where the aim is to decide if the software is good enough to be deployed and used in its operational environment.

Key Software Engineering Concepts

Common Design Patterns

• Observer Pattern: Lets many objects know when another object changes its state.
• Facade Pattern: Provides a simplified interface to a group of related patterns or a complex subsystem.
• Iterator Pattern: Provides a standard way to traverse items in a collection without exposing its underlying structure.
• Decorator Pattern: Adds new functionality to an object without changing its structure.

Non-Functional Requirements Categories

• Product Requirements:
  • Usability
  • Efficiency (Performance, Space)
  • Dependability
  • Security
• Organizational Requirements:
  • Environmental
  • Operational
  • Development
• External Requirements:
  • Regulatory
  • Ethical
  • Legislative (Security, Safety)

Software Metrics Examples

• Speed: Screen refresh time
• Size: Number of ROM chips
• Ease of Use: Training time
• Reliability: Mean time to failure
• Robustness: Time to restart after failure
• Portability: Number of target systems supported

Types of System Models

• Structural models
• Dynamic models

Software Process Activities

• Specification
• Development
• Validation
• Evolution