Software Engineering (CS2800)

Version Control System (VCS)

A software tool that keeps track of and manages changes/updates made to files within a directory.

Benefits of Version Control Systems (VCS)

• Facilitates collaboration and contribution among multiple developers

• Can seamlessly store different versions of the same work

• Compares changes between different project versions

• Provides a history of changes

• Enables branching and merging of code.

Local Version Control Systems (VCS)

A type of version control system where all data, including the project’s version history, is stored locally on the user’s device.

An example of a local VCS is the Revision Control System (RCS).

Benefits of Local Version Control Systems (VCS)

• Allows for easy offline productivity

• Can merge or push local changes to the public repository

• Able to download/clone files from the public repository to use in your local machine

Possible disadvantages of Local Version Control Systems (VCS)

• Because it was fully local, user won’t get support from team collaboration

• This risks data inconsistencies between different versions of works

• If local changes were later pushed to repository, it will be difficult for multiple users to tack and manage changes.

Centralised Version Control System (CVCS)

A type of version control, where a single, central server stores all project files and their version history. Clients will check out these files from this central server.

Benefits of Centralised Version Control System (CVCS)

• Enables easy collaboration on shared projects

• Provides a single source to find and view all versioned history of the project

Disadvantages of Centralised Version Control System (CVCS)

• Performance degrades significantly after many revisions (limited scalability)

• No work can be done if the server is unavailable

Distributed Version Control System (DVCS)

A type of version control where every developer has a complete copy of the entire codebase, including its full history, on their local machine.

Examples of DVCS include Git and Mercurial

Benefits of Distributed Version Control System (DVCS)

• Developers can work offline and later synchronise their changes with others through commits, branching, and merges.

• Easily scalable, even for huge teams

• Server failures don’t prevent work from continuing

• Enables working on multiple tasks simultaneously

Delta-based Version Control System

Stores file data as a base file plus a series of sequential changes (delta or differences) over time. It will store only file changes, making it more storage-efficient for large projects but potentially slower for full restores.

What kinds of projects are recommended if you want to use the Delta-based VCS method?

Storage-efficient, large projects

Snapshot-based Version Control System

Stores entire projects states with every commit, allowing for faster file restoration but consuming more storage space as a result.

What kinds of projects are recommended if you want to use the Snapshot-based VCS method?

Simple, localised workflows with a quick full-system recovery plan

Git

An open-source version control software tool that aims to save and manage different versions of your file and code. Programmers use this popular tool for their large projects.

Benefits of Git

• Makes it easier for collaborative projects while still being able to keep track changes

• Helps undo mistakes easily

• Manage their source files over time

Git Commit

• A save point in your project, recording a snapshot of your files within a certain period.

• A message can also be attached to the commit to describe what changes/updates you made to each file.

Components of a Git Commit

• Commit ID

• Tree (representation of the project snapshot)

• Parent

  • Could be none (first commit), 1 (normal commit), or more (merged commit)

• Author

  • Name, email, timestamp of the user who made the changes

• Committer

  • Name email, and timestamp of the user who committed the changes

• Commit Message

  • Brief description of the changes

Git Branch

A separate workspace that won’t affect the main project.

Benefits of a Git Branch

• Allows programmers to work on different parts of a project without any major consequences

• Opens the project up for more experimentation without breaking/affecting the main project branch

  • For new features or bug fixes

Git special pointer (HEAD)

Used to identify the current commit and the branch the programmer is currently on. This also includes detached commits (detached HEAD).

Git Merge

Combining the changes from one branch into another

Benefits of Git Merge

• Allows programmers to work together after working separately on different features/bug fixes.

• Seamlessly converges changes across multiple branches

Certain Hiccups that come from Git Merges

• Git Merge only works if there are no conflicts between the branches

  • Branches do not contain overlapping changes.

• This is sadly unavoidable when working within a team

• Git tries to merge these conflicts automatically;

  • However, if it fails, it will show a message highlighting the conflict contents

  • You will then need to resolve the conflicts and continue the merge manually.

GitLab

Started as a Git repository hosting service, and then became a well-known competitor of GitHub.

Software Licensing

Legal agreement that grants or refuse users the rights to use software under specific conditions.

This enables software suppliers and device manufacturers to monetise and protect their products and services.

Software Licence Agreement

A legal contract between the supplier and the user specifying the rights and obligations of both parties

• Covers key aspects of expected performance, such as software availability and reliability

Copyright Law

a legal framework that gives creators exclusive rights to control, use, and distribute their original creative works.

This protection is automatically set on a property, even if it doesn’t have a licence built in for it.

Why should you use a software licence as a developer/company?

• Legal Protection

  • Protects intellectual properties

• Software Control

  • Determine how your software can be modified, distributed, and commercialised

• Liability Limitations

  • Include disclaimers that limit the creator’s liability

• Revenue Generation: Enables monetisation

Why should you use a software licence as a user/organisation?

• Legal Compliance

  • Using software without proper licensing can result in lawsuits and fines

• Understanding rights

  • Clarifies what you can do with the software (use commercially)

• Risk Management

  • Helps avoid incorporating incompatible licences in projects

• Transparency

  • Open-source licences promote code reviews and security auditing

Types of Software Licences

• Proprietary (Closed Source) Licences

• Open-Source Licences

  • Copyright Licences (most restrictive)

  • Permissive Licences

  • Public-Domain-Equivalent Licences (least restrictive)

Propriety (Closed Source) Licences

A legal contract that gives a creator/company full control over software

1. Source code is kept secret

2. Strict restrictions on use, modification, and distribution

3. Acquiring a licence typically requires payment and accepting terms

Open-Source Licences

A legal contract which tells people how they can use, change, or share a software’ project’s source code.

1. Users can view, modify, and distribute source code

2. Different licences apply different levels of restrictions.

Copyright Licences

Inverts Intellectual Property Law so that protections for keeping code closed are now used instead to keep it open.

1. They require derivative works to use the same licences

2. Often called “reciprocal” or “viral” licences (they self-replicate)

3. Ensure software remains free and open

4. Varying degrees of strength

Permissive Licences

Introduced by institutions (such as universities) that wish to share their work with the public.

1. Minimal restrictions on reuse

2. Allow proprietary derivatives

3. Primarily requires attribution

4. No requirement to share modifications

Public Domain Equivalent Licences

• Creative Commons Zero

• Unlicensed

Creative Commons Zero

1. Enables users to reuse, distribute, remix, adapt, and build upon the product in any medium or format, with no conditions

2. Primarily for non-software content, but sometimes used for documentation

3. Strong, clear wording with patent waiver, but no patent protection

4. It cannot be revoked

5. Use when you want to gift your work to the public, with strong legal protections suitable for professional settings

Unlicensed

1. Relinquishes all copyright

2. Simple wording

3. No restrictions whatsoever, but keep liability protection

4. Use when you want to “gift” your work to the public and total simplicity (or making a statement).

Licence Compatibility

A legal framework that combines software and other works under different licences into a single product.

This is done while ensuring they are compatible for distribution together. Some licences cannot be legally mixed or contradict each other.

What should you consider when choosing a licence for your product?

1. Do you want to allow for commercial use?

   1. Yes, go for a weak copyleft, permissive, or public-domain licence

   2. No, go for a strong copyleft or non-commercial CC

2. Do you want derivatives to remain open source?

   1. If yes, go for copyleft (GPL, AGPL)

   2. If no, go for permissive (MIT, Apache) and public-domain-like licences.

3. Are you concerned about patents?

   1. If yes, go for Apache 2.0, GPL v3, or AGPL

   2. If no, go for MIT, BSD, or CC0

What are the best practices for licensing a project?

• Always include a LICENCE file in your project root

• Add copyright notices to source files when required

• Document third-party licences if you use external code

• Use SPDX identifiers for clarity

• Consider your community (GPL attracts certain developers, MIT attracts others)

• Review periodically as your project evolves; licensing needs might change

Maintainable Code

High-quality, readable, and well-structured code that easy to understand, modify, and extend without causing any further problems.

This is a huge requirement for team-based projects to avoid any complications.

Key characteristics shown in maintainable code

• Clarity — easy to read and understand

• Simplicity — solves problems without unnecessary complexity

• Consistency — follows predictable patterns and conventions

• Good Structure — organised in logical, modular pieces

• Documentation — clear comments and documentation when needed

• Testability — easy to verify that it worked correctly

Benefits of having maintainable code

• Improved readability

• Reduce costs of poorly maintained code (technical debt)

• Future-proofing your code so it can be adaptable to new requirements/features

• Bug-proofing

• Upskilling your programming skills

Automation Tools

Tools which rely on computer programs and algorithms to execute pre-defined steps: like rules, conditions, or scripts that tell the system what to do.

Examples: Katalon Studio for Java, Robot Framework for Python, Appium for C#, Apache Maven

Build Lifecycle

Consists of sequence phases that define the steps for building a project from initial setup to final deployment.

Apache Maven Build Lifecycle

• validate

  • Check if all information necessary for the build is available

• compile

  • Compile the source code

• test

  • Run unit tests

• package

  • Package into a distributable format (e.g, an executable JAR)

• install

  • Install the package (dependency) into the local repository

• deploy

  • Copy the package to the remote repository

Phases are executed sequentially from validate to deploy and back full circle again.

If you run mvn test (test phase), the command executes validate and compile in order before executing the test.

Integrated Development Environment (IDE)

Software application that combines the necessary tools for software development (code editor, debugger, build automation tool, etc.) into a single, user-friendly interface.

Coding Standards

A set of guidelines that a developer/team follows to write clean, consistent, and maintainable code. However, they are non-functional requirements.

Benefits of Coding Standards

• Improves readability

• Reduces the chances of bugs

• Enhances collaboration

• Supports software security, reliability, and potential scalability

Software Testing

The process of verifying and validating software to ensure that it meets the specified requirements and is free of bugs/errors.

The different levels of Software Testing

• Unit Testing - for individual units of software

• Integration Testing - for groups of units of software

• System Testing - for the entire system of software

Unit Testing

Involves a block of code that verifies the accuracy of a smaller, isolated block of application code, typically a function/method.

Unit tests should focus on the logic of each unit.

Test Driven Development (TDD)

A software development technique where tests are written before functional code. TDD guides software development in coding, testing, and design are tightly interwoven.

Process of Test Driven Development (TDD)

1. Write a failing test

2. Write code to make it pass

3. Repeat steps 1 and 2

4. Along the way, refactor aggressvely

5. When you cannot think of any more tests, you are done

Does TDD makes software development slower?

• In the short term, yes. All investements have an initial cost

• In the long term, the overall development process will be more stable and faster.

• Some IDE features (e.g., code completion, code navigation, code generation) can make TDD easier.

Why use Test Driven Development (TDD)?

• Tests indicate intent for the project

• Tests are another important part of the documentation

• Tests makes sure the programs accounts for all possible user interactions

JavaDoc

A tool where the programmer can describe a function/method/class with special comments in Java source code.

Developers write comments starting with /** and ended with **/.

JavaDoc Tags

@author - the name(s) of the developer

@version - the version of the class or interface

@param - the description of each parameter

@return - the description of the return value of the method

@throws - the description of the return value of the method/the description of a potential exception

Static Analysis

An automated method of debugging and software testing that examines source code without executing the program.

They should be used as gatekeepers as they stop builds if they find any potential issues in your code.

Checkstyle

An open-source development tool for Java that ensures code adheres to defined coding standards.

SpotBugs

An open-source static analysis tool for Java that detects over 400 bug patterns (such as null pointer deferences, infinite loops, and deadlocks) by inspecting bytecode.

Continuous Integration (CI)

The standard working practice of automating the integration of code changes from multiple developers.

Merged code are then put into a central repository, trigerring automated builds and tests.

Continuous Deployment (CD)

Software devleopment practice where code changes that passes automated testing (multiple test stages) is automatically deployed to production without manual interventions.

Issue Tracking System

Software that manages, records, and tracks the lifecycle of bugs, tasks, and requests.

Each of these things would be classified as an issue, which is a small task.

Components of an Issue

• Title - a summary of the task

• Description - a detailed description of the task. It must clearly explain:

  • The required actions by the assignee

  • Expected deliverables

• Assignee - a person who is working/will work/has worked on the task

• Status - current status of the issue (e.g. open or resolved)

• Unique ID - an allocated number (#12, etc.) which makes it easy to locate them.

Issues can also be linked to each other, using the following labels:

• relates to: an issue that has a relation to another

• blocks: an issue that prevents others from being solved

• is blocked by: an issue that cannot be solved due to other open issues

Code Review

A work of practice where code changes are audited by someone other than the change author.

Where in team settings, it is a good practice to have it reviewed by other colleages.

Benefits of Code Reviews

• Finding bugs

• Making improvements (alternative solutions, better readability, and maintainability)

• Sharing knowledge within the team

• Promoting social communication