Software Development
Uploaded by
bassamwael6689Software Development
Uploaded by
bassamwael6689Software Development
A Practical Approach!
Hans-Petter Halvorsen
[Link]
[Link]
Software Development
A Practical Approach!
Hans-Petter Halvorsen - 2026-05-13
Software Development
A Practical Approach!
Hans-Petter Halvorsen
ISBN: 978-82-691106-0-9
Publisher Identifier: 978-82-691106
[Link]
ii
Preface
The main goal with this document:
• To give you an overview of what software engineering is
• To take you beyond programming to engineering software
What is Software development? It is a complex process to develop modern and professional
software today. This document tries to give a brief overview of Software development.
This document tries to focus on a practical approach regarding software development.
So why do we need software engineering? Here are some key factors:
• Understand Customer Requirements
o What does the customer needs (because they may not know it!)
o Transform Customer requirements into working software
• Planning
o How do we reach our goals?
o Will we finish within deadline?
o Resources
o What can go wrong?
• Design, Architecture and Implementation
o What kind of platforms and architecture should be used?
o Split your work into manageable pieces
iii
• Quality and Performance
o Make sure the software fulfills the customers’ needs
o Make sure the software is secure
We will learn how to build good (i.e., high quality) software, which includes:
• Project Planning and Management
• Requirements Analysis and Specification
• Technical Design and Architecture
• User Experience (UX) and Graphical User Interfaces (GUI)
• Code Quality and Implementation
• Security
• Software Testing
• Installation and Deployment
• System Documentation
• User Documentation
• etc.
iv
Table of Contents
Preface .................................................................................................iii
Part 1 : Introduction ........................................................................... 17
1 Introduction .................................................................................... 18
1.1 Background ...................................................................................................... 23
1.2 Topics ............................................................................................................... 24
1.3 Tools ................................................................................................................. 26
1.4 Tools for Application Life Management (ALM) ................................................ 29
1.4.1 Azure DevOps ................................................................................................................. 30
1.4.2 Atlassian Suite and Jira ................................................................................................... 31
1.4.3 GitHub ............................................................................................................................ 31
2 Software History ............................................................................. 32
2.1 Introduction ..................................................................................................... 32
2.2 Software Trends ............................................................................................... 34
3 Software Development ................................................................... 36
3.1 Challenges ........................................................................................................ 37
3.2 Software Systems ............................................................................................. 37
3.3 Documentation ................................................................................................ 39
3.4 Iterations and Releases .................................................................................... 40
Part 2 : Software Engineering ............................................................ 42
4 Development Teams ....................................................................... 43
4.1 Teams ............................................................................................................... 44
vi
4.2 Roles................................................................................................................. 44
4.2.1 Stakeholders................................................................................................................... 45
4.2.2 Project Manager ............................................................................................................. 45
4.2.3 System Architect ............................................................................................................ 45
4.2.4 UX Designer .................................................................................................................... 45
4.2.5 Programmer ................................................................................................................... 45
4.2.6 Software Tester .............................................................................................................. 45
5 Software Development Phases ....................................................... 47
5.1 Requirements................................................................................................... 48
5.2 Design .............................................................................................................. 49
5.2.1 Technical Design ............................................................................................................. 50
5.2.2 UX Design ....................................................................................................................... 50
5.3 Implementation ............................................................................................... 50
5.4 Testing.............................................................................................................. 51
5.5 Deployment ..................................................................................................... 51
6 Software Development Process ...................................................... 52
6.1 Plan-driven models .......................................................................................... 54
6.1.1 Waterfall model ............................................................................................................. 54
6.1.2 V-model .......................................................................................................................... 55
6.2 Agile Software Development ........................................................................... 56
6.2.1 The Manifesto for Agile Software Development ............................................................ 58
6.2.2 Burndown Chart ............................................................................................................. 59
6.2.3 Waterfall vs. Agile........................................................................................................... 60
6.2.4 eXtreme Programming (XP) ............................................................................................ 60
6.2.5 Scrum ............................................................................................................................. 63
Software Development - A Practical Approach!
vii
6.2.6 Kanban ........................................................................................................................... 65
6.3 Hybrid Process Models..................................................................................... 66
6.3.1 Unified Process (UP)/ Rational Unified Process (RUP) .................................................... 66
6.4 Summary .......................................................................................................... 67
6.5 Exercises........................................................................................................... 67
7 Scrum .............................................................................................. 69
7.1 The Scrum Process ........................................................................................... 70
7.2 Scrum Events.................................................................................................... 70
7.2.1 Daily Scrum Meeting ...................................................................................................... 71
7.3 Scrum Artifacts ................................................................................................. 72
7.4 The Scrum Team .............................................................................................. 72
7.5 Scrum Meetings ............................................................................................... 73
7.6 Scrum Terms .................................................................................................... 74
7.7 Tips and Tricks .................................................................................................. 76
7.8 Scrum Tools ...................................................................................................... 76
8 Project Management ...................................................................... 78
8.1 Project Planning ............................................................................................... 79
8.2 Kick-off/Brainstorming ..................................................................................... 80
8.3 Software Development Plan (SDP) ................................................................... 82
8.3.1 Project Plan and Gantt Chart .......................................................................................... 83
8.4 Meetings .......................................................................................................... 87
8.4.1 Meeting Agenda ............................................................................................................. 87
8.4.2 Minutes of Meeting ........................................................................................................ 88
8.5 Agile Project Planning and Tracking ................................................................. 88
Software Development - A Practical Approach!
viii
8.6 Microsoft Teams .............................................................................................. 91
8.7 Summary .......................................................................................................... 92
9 Requirements Engineering .............................................................. 93
9.1 User Requirements .......................................................................................... 95
9.2 System Requirements ...................................................................................... 95
9.3 Functional Requirements ................................................................................. 95
9.4 Non-Functional Requirements ......................................................................... 96
9.5 SRS ................................................................................................................... 96
9.6 Project Estimation ............................................................................................ 99
9.7 Exercises........................................................................................................... 99
10 User eXperience (UX) .................................................................. 101
10.1 UX Guidelines ............................................................................................... 102
10.2 GUI Mockup ................................................................................................. 103
10.3 Universal Design .......................................................................................... 104
10.3.1 Web Content Accessibility Guidelines (WCAG)........................................................... 105
10.3.2 Universal design in the development process ............................................................ 106
11 UML ............................................................................................. 108
11.1 Introduction ................................................................................................. 108
11.2 UML Software .............................................................................................. 109
11.3 Use Case ....................................................................................................... 109
11.4 Sequence Diagram ....................................................................................... 110
11.5 Class Diagram ............................................................................................... 111
11.6 Creating UML Diagrams ............................................................................... 111
11.7 UML in Agile/Scrum? ................................................................................... 112
Software Development - A Practical Approach!
ix
11.8 Summary ...................................................................................................... 113
11.9 Exercises....................................................................................................... 113
12 Software Implementation ........................................................... 115
12.1 Programming Style & Coding Guidelines ..................................................... 116
12.1.1 Naming Convention .................................................................................................... 117
12.2 Comments .................................................................................................... 117
12.3 Debugging .................................................................................................... 120
12.4 Code Reviews ............................................................................................... 121
12.5 Refactoring ................................................................................................... 123
13 Testing ......................................................................................... 124
13.1 Introduction ................................................................................................. 124
13.1.1 Test Levels .................................................................................................................. 129
13.1.2 Bug Tracking ............................................................................................................... 130
13.1.3 Software versioning.................................................................................................... 130
13.2 Test Categories ............................................................................................ 133
13.2.1 Black-box Testing........................................................................................................ 133
13.2.2 White-box Testing ...................................................................................................... 133
13.3 Test Levels .................................................................................................... 134
13.3.1 Unit Testing ................................................................................................................ 136
13.3.2 Regression Testing...................................................................................................... 139
13.3.3 Integration Testing ..................................................................................................... 139
13.3.4 System Testing/Validation Testing ............................................................................. 139
13.3.5 Acceptance Testing .................................................................................................... 139
13.4 Universal design and GDPR .......................................................................... 140
13.4.1 Universal design ......................................................................................................... 140
Software Development - A Practical Approach!
x
13.4.2 General Data Protection Regulation (GDPR) .............................................................. 141
13.5 Test Documentation .................................................................................... 141
13.5.1 Test Planning and Software Test Plan (STP)................................................................ 142
13.6 Bug Tracking Systems ................................................................................... 143
13.7 Test Environment ......................................................................................... 144
13.7.1 Virtualization .............................................................................................................. 147
13.8 Terms used in Testing .................................................................................. 148
13.8.1 Bugs ............................................................................................................................ 148
13.8.2 Debugging .................................................................................................................. 148
13.8.3 Code Coverage ........................................................................................................... 149
13.8.4 Eat your own Dog food ............................................................................................... 149
13.8.5 Code/Feature Freeze .................................................................................................. 150
13.8.6 Test-Driven Development (TDD) ................................................................................ 151
13.8.7 Development-Driven Testing (DDT) ............................................................................ 151
13.9 The 7 Principles of Testing ........................................................................... 152
13.10 Testing Summary ....................................................................................... 152
13.11 Exercises..................................................................................................... 153
14 Deployment and Installation....................................................... 155
14.1 Introduction ................................................................................................. 155
14.2 Releases ....................................................................................................... 156
14.3 Deployment ................................................................................................. 158
14.4 Test and Production Environment ............................................................... 159
14.4.1 Development Environment ........................................................................................ 160
14.4.2 Production Environment ............................................................................................ 160
14.4.3 Test Environment ....................................................................................................... 161
Software Development - A Practical Approach!
xi
15 Project Documentation ............................................................... 162
15.1 Process Documentation ............................................................................... 165
15.2 Product Documentation............................................................................... 166
15.2.1 System Documentation .............................................................................................. 166
15.2.2 User Documentation .................................................................................................. 168
15.3 Setup & Distribution .................................................................................... 170
16 Software Maintenance................................................................ 171
16.1 Introduction ................................................................................................. 171
16.2 Categories .................................................................................................... 171
Part 3 : Platforms & Architecture..................................................... 174
17 Software Platforms ..................................................................... 175
17.1 Introduction ................................................................................................. 175
17.2 Platform Vendors ......................................................................................... 176
17.3 Desktop ........................................................................................................ 176
17.3.1 Windows .................................................................................................................... 177
17.3.2 macOS ........................................................................................................................ 179
17.3.3 Linux ........................................................................................................................... 180
17.4 Web .............................................................................................................. 182
17.4.1 Web Servers ............................................................................................................... 184
17.4.2 Web Frameworks ....................................................................................................... 184
17.4.3 [Link] Core.............................................................................................................. 185
17.4.4 Django ........................................................................................................................ 186
17.4.5 Web Scripting Languages ........................................................................................... 186
17.4.6 Front-end Web Development Libraries and Frameworks ........................................... 187
Software Development - A Practical Approach!
xii
17.5 Mobile Devices ............................................................................................. 188
17.5.1 iOS .............................................................................................................................. 189
17.5.2 Android....................................................................................................................... 190
17.5.3 Native and Cross-platform App Development ............................................................ 193
17.6 Cloud Computing ......................................................................................... 195
17.7 Open Source................................................................................................. 195
18 Software Frameworks & Languages............................................ 197
18.1 Object-Oriented Programming (OOP) .......................................................... 197
18.2 Popular Programming Languages ................................................................ 198
18.2.1 C and C++ ................................................................................................................... 199
18.2.2 C# ............................................................................................................................... 199
18.2.3 Java and Kotlin ........................................................................................................... 200
18.2.4 Swift ........................................................................................................................... 200
18.2.5 Python ........................................................................................................................ 201
18.2.6 JavaScript ................................................................................................................... 202
18.2.7 SQL ............................................................................................................................. 202
18.3 Naming Convention ..................................................................................... 203
18.4 Defensive Programming ............................................................................... 204
18.4.1 Error Handling ............................................................................................................ 205
18.5 Software Frameworks .................................................................................. 206
18.5.1 .NET Framework ......................................................................................................... 206
18.5.2 [Link] ...................................................................................................................... 206
19 Software Architecture ................................................................. 208
19.1 API ................................................................................................................ 210
19.2 Client-Server ................................................................................................ 212
Software Development - A Practical Approach!
xiii
19.3 Web Services and Web APIs......................................................................... 213
19.3.1 SOAP Web Services .................................................................................................... 216
19.3.2 REST Web Services ..................................................................................................... 217
19.3.3 Creating Web Services with Visual Studio .................................................................. 217
19.4 3-tier Architecture ....................................................................................... 218
Part 4 : Management and Development Tools ................................ 223
20 Integrated Development Environment (IDE) .............................. 224
20.1 Visual Studio ................................................................................................ 224
20.2 Visual Studio Code ....................................................................................... 226
20.3 Xcode ........................................................................................................... 226
20.4 Android Studio ............................................................................................. 227
21 UML Software ............................................................................. 228
21.1 Enterprise Architect ..................................................................................... 228
21.2 StarUML ....................................................................................................... 228
21.3 UMLet and UMLetino................................................................................... 229
21.3.1 UMLet......................................................................................................................... 229
21.3.2 UMLetino.................................................................................................................... 230
22 Source Code Control (SCC) .......................................................... 231
22.1 Introduction ................................................................................................. 231
22.2 Azure DevOps............................................................................................... 233
22.3 SVN............................................................................................................... 233
22.4 CVS ............................................................................................................... 234
22.5 Git ................................................................................................................ 234
22.6 Others .......................................................................................................... 234
Software Development - A Practical Approach!
xiv
22.7 Cloud-based SCC Hosting Services ............................................................... 234
22.7.1 Azure DevOps ............................................................................................................. 235
22.7.2 GitHub ........................................................................................................................ 235
22.7.3 Bitbucket .................................................................................................................... 235
23 Bug Tracking Systems .................................................................. 236
24 Azure DevOps .............................................................................. 237
24.1 Source Code Control (SCC) ........................................................................... 238
24.2 Areas and Iterations ..................................................................................... 239
24.3 Work Items................................................................................................... 240
24.3.1 Queries ....................................................................................................................... 241
24.4 Taskboard..................................................................................................... 242
24.5 Agile (Scrum) Development in Azure DevOps .............................................. 242
24.5.1 Product Backlog Items in Azure DevOps ..................................................................... 243
24.5.2 Sprint Backlog Items in Azure DevOps ........................................................................ 244
24.5.3 Taskboard ................................................................................................................... 246
24.6 Software Testing in Azure DevOps ............................................................... 247
25 Databases .................................................................................... 249
25.1 SQL Server .................................................................................................... 249
25.2 ER Diagram ................................................................................................... 250
25.3 ERD Tools ..................................................................................................... 251
25.4 Structured Query Language ......................................................................... 251
25.4.1 Best Practice ............................................................................................................... 252
26 Unit Testing ................................................................................. 253
26.1 Unit Tests Frameworks ................................................................................ 253
Software Development - A Practical Approach!
xv
26.2 Unit Testing in Visual Studio ........................................................................ 253
26.3 Code Coverage ............................................................................................. 256
26.4 Exercises....................................................................................................... 257
27 Deployment in Visual Studio ....................................................... 258
27.1 Setup Creation Software .............................................................................. 259
27.2 [Link] Core Deployment........................................................................... 260
Part 5 : Cyber Security ...................................................................... 261
28 Cyber Security ............................................................................. 262
28.1 Introduction ................................................................................................. 262
28.2 Types of Cyber Security Attacks ................................................................... 263
28.2.1 Ransomware............................................................................................................... 264
28.2.2 Malware ..................................................................................................................... 264
28.2.3 Social Engineering ...................................................................................................... 264
28.2.4 Phishing ...................................................................................................................... 264
28.2.5 Spam .......................................................................................................................... 265
28.2.6 SQL Injection .............................................................................................................. 265
28.3 How to be Secure? ....................................................................................... 265
28.3.1 Passwords................................................................................................................... 266
28.3.2 Firewall ....................................................................................................................... 266
28.3.3 Web Application Firewall (WAF) ................................................................................. 266
28.3.4 Antivirus and Antimalware Software .......................................................................... 267
28.3.5 Access Control ............................................................................................................ 267
28.3.6 Two-factor Authentication ......................................................................................... 267
28.3.7 VPN............................................................................................................................. 268
28.3.8 Web Hosting Providers ............................................................................................... 268
Software Development - A Practical Approach!
xvi
28.3.9 Wi-Fi Network ............................................................................................................ 268
28.3.10 Operating System ..................................................................................................... 268
28.3.11 Education ................................................................................................................. 268
29 SQL Injection ............................................................................... 269
29.1 SQL Injection Examples ................................................................................ 269
29.2 Resources ..................................................................................................... 270
30 User Identity and Login ............................................................... 271
30.1 Password Security ........................................................................................ 271
30.1.1 Encryption and Decrypting ......................................................................................... 272
30.1.2 Hashing....................................................................................................................... 272
30.1.3 Rainbow Tables .......................................................................................................... 273
30.1.4 Salting ......................................................................................................................... 274
31 SQL Server Authentication .......................................................... 276
31.1 Introduction ................................................................................................. 276
31.2 Authentication ............................................................................................. 276
31.3 Create Logins in SQL Server ......................................................................... 277
Part 6 : Additional Resources ........................................................... 280
32 Glossary ....................................................................................... 281
References ....................................................................................... 284
Software Development - A Practical Approach!
Part 1 : Introduction
In this part, we discuss what software development is with some examples. We also give a brief
overview of the software history.
1 Introduction
What is Software Development? It is a complex process to develop modern and professional
software today. This document tries to give a brief overview of Software Development. Normally
we use the terms System Engineering or Software Engineering.
Software Engineering: [Link]
System Engineering: The process of analyzing and designing an entire system, including the
hardware and the software.
Software Engineering: The discipline for creating software applications. A systematic approach to
the design, development, testing, and maintenance of software.
A lot of systems today have a mix of hardware and software that is tightly integrated, like modern
smartphones, tablets, etc. Creating such systems involves a lot of different disciplines.
Software is any set of machine-readable instructions that directs a computer's processor to
perform specific operations. The term is used to contrast with computer hardware, the physical
objects (processors and related devices) that carry out the instructions. Computer hardware and
software require each other, and neither can be realistically used without the other, see Figure
1-1.
19 1 Introduction
Figure 1-1: Hardware and Software working together
In Figure 1-2 we see a typical network and infrastructure that the software relies on.
Figure 1-2: Typical Network and Infrastructure in Software Development
Part 1: Introduction
20 1 Introduction
Figure 1-3 we see the complexity of software development and different components that are
involved.
Figure 1-3: The Complexity of modern Software
In Figure 1-4 we see the different phases involved in the Software Development Lifecycle (SDLC).
Part 1: Introduction
21 1 Introduction
Figure 1-4: The Software Development Lifecycle
The main parts or phases in the software development process are:
• Planning
• Requirements Analysis
• Design
• Implementation
• Testing
• Deployment and Maintenance
In Figure 1-5 we see examples of some of the different activities involved in the different phases of
software development.
Part 1: Introduction
22 1 Introduction
Figure 1-5: Activities involved in the different Software Phases
As you see, software development involves a lot of phases, they are executed by different
disciplines and different people. We will discuss and explain all these things later in this document.
Figure 1-6: Have Reviews at all levels in the Development Cycle
Part 1: Introduction
23 1 Introduction
1.1 Background
Software and software systems are getting more and more complex, so it is important to have the
necessary “tools” in your “toolbox” to be able to create and maintain your software.
Software Development is a complex process, and it may involve a lot of money and a lot of people.
Here are some examples:
• Windows 7: A Team with 1000 Developers created Windows 7
• Number of Code Lines: Real systems may have millions of code lines
• Big money: 100+ million Development Projects
• Combination of Hardware and Software: Most of the projects involve both hardware and
software and integration between them.
• iPhone 1: Development period 2004-2007, 1000 Apple employees worked with the device,
Estimated cost: $150 mill.
All this need structure! - Software Engineering is the Answer!
Part 1: Introduction
24 1 Introduction
[[Link]
Project Planning and Management is important in Software Development, and we can use
different approaches to deal with Software Development, which we will cover in this document.
Especially so-called Agile approaches, such as Scrum, have become very popular today.
1.2 Topics
Below we list the different topics covered in this document. The Software Development Life Cycle,
shorted SDLC, involves distinct phases, such as:
• Market research
• Gathering requirements for the proposed business solution
• Analyzing the problem
• Create a plan or design for the software-based solution
• Implementation (coding) of the software
• Documentation in different ways
• Testing the software
• Deployment and Installation
• Maintenance and bug fixing
• Marketing
See also Figure 1-7 for topics involved in software development.
Part 1: Introduction
25 1 Introduction
There are different approaches (Software Development Processes) that deal with these phases,
such as:
• Waterfall model
• V-model
• Agile Software Development (such as Scrum, XP, etc.)
• Spiral model
• Rational Unified Process (RUP)
• etc.
We will learn more about these development processes later in this document.
Figure 1-7: Different Topics involved in Software Development
Software development also involves separate roles, which are organized in different teams (Figure
1-8). Typical roles are:
• Project Manager
• System Architect
• UX Designer
• Programmer, System Developer
• Tester
• Customer
It is crucial that the separate roles and teams can work together and collaborate.
The programmer or system engineer must deal with the fact that there exist hundreds of different
programming languages. Each language has pros and cons, so it is important to find out which
programming language is best suited in each situation.
Part 1: Introduction
26 1 Introduction
Figure 1-8: Distinct Roles involved in Software Development
In this document, we will learn how to build good (i.e., high quality) software, which includes:
• Requirements Specification
• Technical Design
• User Experience (UX)
• Improved Code Quality and Implementation
• Testing
• System Documentation
• User Documentation
• etc.
1.3 Tools
To create great software, as a software engineer you need a toolbox with proper tools, otherwise
you will not succeed in your job (see Figure 1-9).
Part 1: Introduction
27 1 Introduction
Figure 1-9: The Toolbox of a Software Engineer
When working with software development it is important to have good tools. The developer needs
of course to use a programming language and proper IDE (Integrated Development Environment).
In addition, a so-called ALM Tool should be used. ALM is short for Application Lifecycle
Management. An ALM tool typically facilitates and integrates things like:
• Requirements Management
• Architecture
• Coding
• Source Code Control (SCC)
• Testing
• Bug Tracking
• Release Management
• etc.
There exist a lot of such tools, e.g., Azure DevOps, Jira, GitHub, ClickUp, etc.
We will take a closer look at Azure DevOps in this document. Azure DevOps from Microsoft is
tightly integrated with Visual Studio.
Typically, you need to share the code with other developers or testers in your team or other
teams, so it is crucial that you have tools that can be used to share your code, that makes sure that
Part 1: Introduction
28 1 Introduction
old versions of your code will be stored, and can be restored, etc. Such a system is called a Source
Code Control (SCC) system.
Your software will also contain a lot of bugs that need to be found, tracked, and fixed, etc. To
handle that we need a so-called Bug Tracking system.
In Figure 1-10 we see some of the bug tracking functionality in Azure DevOps.
Figure 1-10: Bug Tracking System
In Figure 1-11 we see a typical software project with different platforms and frameworks involved.
Part 1: Introduction
29 1 Introduction
Figure 1-11: Typical Software Project with different Platforms and Frameworks involved
Typically, your software needs to be installed and be running on different devices, such as PCs,
tablets, smartphones, etc. You also need to store the data, typically in a database, such as
Microsoft SQL Server, MySQL, etc.
All these devices and data also need to communicate with each other over a network, either an
internal network (LAN, Local Area Network) or over Internet (WAN, Wide Area Network).
All these things make it very complicated to develop, test, deploy and install such systems. That’s
the reality for a modern software developer.
1.4 Tools for Application Life Management (ALM)
Application Lifecycle Management (ALM) tools provide integrated environments for managing
software projects from conception to retirement. These tools bridge the gap between
development, testing, and operations teams to improve quality, efficiency, and visibility.
An ALM tool typically facilitates and integrates things like:
• Requirements Management
• Architecture
• Coding
• Source Code Control (SCC)
Part 1: Introduction
30 1 Introduction
• Testing
• Bug Tracking
• Release Management
• etc.
Some examples of such ALM tools are Azure DevOps, Atlassian Suite (which includes Jira,
Confluence and Bitbucket), GitHub, etc.
1.4.1 Azure DevOps
Some examples of such tool are Azure DevOps from Microsoft (see Figure 1-12), which is the tool
used in this document. Azure DevOps is free for up to 5 users and stakeholders and it is a good
choice for small teams. It is also handy for personal use or students.
You use Azure DevOps through your web browser and as an integration in Visual Studio and Visual
Studio Code.
Azure DevOps is available here: [Link]
Figure 1-12: Azure DevOps
Note! Azure DevOps from Microsoft and Microsoft Azure are not the same!!
• Microsoft Azure is a cloud infrastructure where you can host Virtual Machines (VMs),
databases and websites, etc. Microsoft Azure can be compared to Amazon Web Services
(AWS) and Google Cloud Platform (GCP).
Part 1: Introduction
31 1 Introduction
• Azure DevOps is an ALM collaboration platform used during the planning and development
of your software where you can use code repositories, Scrum features, create the product
backlogs, task boards, etc. See chapter 24 for a detailed overview of Azure DevOps.
1.4.2 Atlassian Suite and Jira
Another ALM tool is the Atlassian Suite (which includes Jira, Confluence and Bitbucket), which
combines Jira for project tracking, Confluence for collaboration, and Bitbucket for source code
management to create a comprehensive ALM environment. Bitbucket is Git based source code
control system (SCC).
Jira and Confluence are free forever for 10 users.
Jira and Confluence are available here: [Link]
1.4.3 GitHub
GitHub started as a code hosting platform that was using Git as a repository but has grown to
include many ALM features. GitHub comes also in a free version and paid versions, including
GitHub Enterprise.
GitHub is available here: [Link]
Part 1: Introduction
2 Software History
2.1 Introduction
Computer and software history goes back to the beginning of the 1900 century. IBM was
established in 1911, Hewlet Packard (HP) was established in 1939, the transistor came in 1947, the
first Microprocessor came in 1972, etc. But “personal computing” started in 1981 with MS-DOS
and the IBM PC. In 1984 came the famous Macintosh from Apple. Windows 1.0 was released in
1985.
They found a bug (a moth) inside a computer in 1947 that made the program not behave as
expected. This was the “first” real bug.
In the 80s and 90s we saw the beginning of the personal computer era that started with Mac
computers from Apple (Macintosh, 1984) and IBM computers from IBM (or IBM compatible
computers from other vendors) with MS-DOS and later Windows installed (Figure 2-1).
Figure 2-1: The Beginning of Personal Computing
32
33 2 Software History
World Wide Web (WWW) was established in 1991. The first Web Browser, as we know it today,
came in 1994 (Netscape). Google was established as late as 1998. Facebook was first invented in
2004. The first smartphone was released in 2007 (iPhone).
In Figure 2-2 we see some of the people that have founded and shaped the modern software
industry.
Figure 2-2: Pioneers of modern Software Industry
The companies that they created still dominate the software industry today. Some of the people
are still active within these companies today, either as CEOs or members of the board.
Some of the largest software companies today are:
• Microsoft (established 1975), Bill Gates, Paul Allen
• MS DOS (1981), Office, Windows (1985), …
• Employees (2012): 94.000, Revenue (2012): $74 bill.
• Apple (Software and Hardware) (established 1976), Steve Jobs, Steve Wozniak
• Macintosh (1984), iPhone (1097), iPad (2012), iOS
• Employees (2012): 72.800, Revenue (2012): $158 bill.
• Google (established 1986), Larry Page, Sergey Brin
• Facebook (established 2004), Mark Zuckerberg
Part 1: Introduction
34 2 Software History
• More than 1 bill. users
In addition, we can mention companies like IBM, Oracle, Samsung (more hardware than software),
Amazon, SAP, Adobe, Symantec, VMware, etc.
2.2 Software Trends
The software industry has changed a lot since the 80s, and it is still changing very quickly. Figure
2-3 gives an overview of some important trends in the software industry today and tomorrow.
Figure 2-3: Software Trends
Apps and Mobil devices: Everybody has a mobile device today and fewer PCs are sold than ever
before. Licensing: You don’t buy, but lease software these days and all your information is stored
in the Cloud, and some software is running in the Cloud (so-called Cloud Computing). Security
challenges is very important in this case.
The companies that develop software need to face these facts and make the necessary changes to
survive.
“Softwear” and Wearable Computing: Now we have watches like Galaxy Gear, the Apple Watch,
Google Glass, etc.
Part 1: Introduction
35 2 Software History
In Figure 2-4 we see some examples of Software Trends.
Figure 2-4: Software Trends Examples
Part 1: Introduction
3 Software Development
In this chapter, we will give a short overview of software development, the challenges and what
kind of different software categories we have, what kind of documents that are needed and
created during the software development process, what kind of skills needed, etc.
Software Engineering: [Link]
Terms:
Software Development (also known as application development, software design, designing
software, software application development, enterprise application development, or platform
development) is the development of a software product.
Software Engineering (SE) is the application of a systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of software.
In Figure 3-1 we see how a software application typically interacts with users, the underlying
operating system and hardware.
Figure 3-1: Software Interaction with Hardware and Users
36
37 3 Software Development
3.1 Challenges
In Figure 3-2 we see some of the challenges in software development.
Figure 3-2: Challenges with Software Development
Collaboration and communication within the team and with stakeholders, etc. is crucial when it
comes to creating good software.
Creating software is complicated. It is important to understand the customers’ needs! In some
way, you need to find out what the customer needs.
Market research, etc. is a good start, but in the end, you need to go much deeper to understand
the customer. Most of the time the customer doesn’t even know what they need.
3.2 Software Systems
In software development we have different kinds of systems, such as:
• Stand-alone applications
Part 1: Introduction
38 3 Software Development
– These are application systems that run on a local computer, such as a PC. They
include all necessary functionality and do not need to be connected to a network.
• Interactive transaction-based applications
– Applications that are executed on a remote computer and are accessed by users
from their own PCs or terminals. These include web applications such as e-
commerce applications.
• Embedded control systems
– These are software control systems that control and manage hardware devices.
Numerically, there are probably more embedded systems than any other type of
system.
• Batch processing systems
– These are business systems that are designed to process data in large batches. They
process large numbers of individual inputs to create corresponding outputs.
• Entertainment systems
– These are systems that are primarily for personal use, and which are intended to
entertain the user.
• Systems for modeling and simulation
– These are systems that are developed by scientists and engineers to model physical
processes or situations, which include many, separate, interacting objects.
• Data collection systems
– These are systems that collect data from their environment using a set of sensors
and send that data to other systems for processing.
• Systems of systems
– These are systems that are composed of several other software systems.
We can split the software systems into 2 main categories:
Generic products
• Stand-alone systems that are marketed and sold to any customer who wishes to buy them.
• Examples – PC software such as graphics programs, project management tools; CAD
software; software for specific markets such as appointments systems for dentists.
Examples: Microsoft Office
Part 1: Introduction
39 3 Software Development
Customized products
• Software that is commissioned by a specific customer to meet their own needs.
• Examples – embedded control systems, air traffic control software, traffic monitoring
systems.
3.3 Documentation
Lots of documentation is involved in software development, see Figure 3-3. In this document, we
will go through all the documentation needed in the different phases involved in software
development.
Some important documents are:
• SRS – Software Requirements Specifications
o A document stating what an application must accomplish
• SDD – Software Design Document
o A document describing the design of a software application
• STP - Software Test Plan
o Documentation stating what parts of an application will be tested, and the schedule
of when the testing is to be performed
• STD - Software Test Documentation
o Contents: Introduction, Test Plan, Test Design, Test Cases, Test procedures, Test
Log, …, Summary
More about Software Documentation later in this document.
Part 1: Introduction
40 3 Software Development
Figure 3-3: Typical Documentation involved in Software Development
QA – Quality Assurance. Quality Assurance (QA) refers to the engineering activities implemented
in a quality system so that requirements for a product or service will be fulfilled.
3.4 Iterations and Releases
In Software Development, we typically have different iterations and releases, as shown in Figure
3-4.
Part 1: Introduction
41 3 Software Development
Figure 3-4: Software Iterations and Releases
Part 1: Introduction
Part 2 : Software
Engineering
In this part, we introduce the different features and topics involved in software engineering, such
as software teams, software development processes, software project management, etc.
42
4 Development Teams
A typical Software Team consists of the following roles:
• Project Manager
• System Architect
• UX Designer (Software Designer)
• Programmer
• Software Tester
In addition, we have Stakeholders or Customers that play an important role in the development.
In Figure 4-1 we see a typical Software Team.
Figure 4-1: Software Team
A System Engineer is a general person that could be a Programmer, Architect, Designer, Tester in
different phases in the project, or he could be a tester in one project and a programmer in another
project – all in one person. That is usually the case in small companies, while in larger companies
these roles (designer, tester, programmer) could be a full-time job.
43
44 4 Development Teams
4.1 Teams
To successfully create software, collaboration inside the team is essential.
Figure 4-2: Team Collaboration
It is important that the team collaborate. Communication as well!
4.2 Roles
A typical Software Team consists of the following roles:
• Project Manager
• System Architect
• UX Designer (Software Designer)
• Programmer
• Software Tester
Part 2: Software Engineering
45 4 Development Teams
In addition, we have Stakeholders or Customers that play an important role in the development.
We will discuss these roles in more detail below.
4.2.1 Stakeholders
All the people that have an interest in the outcome of the software are called Stakeholders. In
most cases the Stakeholders are referred to as “Customers” but others may also be referred to as
stakeholders, such as management, shareholders, etc.
4.2.2 Project Manager
The Project Managers have responsibility of the planning, execution and closing of the project.
More about Project management in a later chapter.
4.2.3 System Architect
With “Technical Design” we mean the Platform and Architecture Design, i.e., how to build the
software.
This is typically done by a so-called Software/System Architect.
4.2.4 UX Designer
UX Design is the Design of the User eXperience (UX) and the Graphical User Interface (GUI),
sometimes also called Human Machine Interface (HMI). This is what the end user of the software
sees.
This is typically done by a so-called UX Designer.
4.2.5 Programmer
The Programmer or the Developer is doing the actual implementation of the software, i.e., the
coding.
4.2.6 Software Tester
Before the customer can start using the software it needs to be properly tested. The
Developer/Programmer needs to test his software, but since software consists of several software
modules and components created by different developers, we need dedicated software testers
that can test the software on a higher level.
Part 2: Software Engineering
46 4 Development Teams
The Customers are/should also be involved in the testing as well.
Part 2: Software Engineering
5 Software Development
Phases
In software development, we have the following phases:
• Requirements (e.g., from Customer)
• Analysis and Design
• Implementation, Coding
• Documentation
• Testing
• Deployment, Installation and Maintenance
This chapter introduces these phases. Figure 5-1 shows an overview of the different phases
involved in Software Development:
Figure 5-1: Phases in Software Development
47
48 5 Software Development Phases
5.1 Requirements
In the requirements, we describe what the system should do. The requirements include both
functional requirements and non-functional requirements.
Functional Requirements: Statements of services the system should provide, how the system
should react to inputs and how the system should behave in different situations. May state what
the system should not do.
Non-Functional Requirements: Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development process, standards, etc. Often apply to
the system rather than individual features or services.
[[Link]
The requirements are often collected in a so-called “Software Requirements Specification (SRS)”
document.
The SRS could contain stuff like:
• Introduction
o Purpose
o Definitions
o System overview
o References
• Overall description
o Product perspective
▪ System Interfaces
▪ User Interfaces
▪ Hardware interfaces
▪ Software interfaces
Part 2: Software Engineering
49 5 Software Development Phases
▪ Communication Interfaces
▪ Memory Constraints
▪ Operations
▪ Site Adaptation Requirements
o Product functions
o User characteristics
o Constraints, assumptions, and dependencies
• Specific requirements
o External interface requirements
o Functional requirements
o Performance requirements
o Design constraints
▪ Standards Compliance
o Logical database requirement
o Software System attributes
▪ Reliability
▪ Availability
▪ Security
▪ Maintainability
▪ Portability
• Other requirements
The Requirements is normally given by the Customer if we deal with customized products. The
software requirements document is the official statement of what is required of the system. It
should include both a definition of user requirements and a specification of the system
requirements. It is NOT a design document. As far as possible, it should include a set of WHAT the
system should do rather than HOW it should do it.
5.2 Design
In the design phase, we use the specification and transform it into descriptions of how we should
do it.
In principle, requirements should state what the system should do, and the design should describe
how it does this – but in practice this is not so easy! - In practice, requirements and design are
inseparable.
We can divide design into 2 main groups:
• Technical Design – Platform and Architecture Design, i.e., how to build the software.
• UX Design – Design of User eXperience (UX) and the Graphical User Interface (GUI),
sometimes also called Human Machine Interface (HMI). This is what the end user of the
software sees.
Part 2: Software Engineering
50 5 Software Development Phases
5.2.1 Technical Design
Technical Design is Platform and Architecture Design, i.e., how to build the software. This is
typically done by a so-called Software Architect.
5.2.2 UX Design
UX Design is the Design of the User eXperience (UX) and the Graphical User Interface (GUI),
sometimes also called Human Machine Interface (HMI). This is what the end user of the software
sees. This is typically done by a so-called UX Designer.
5.3 Implementation
Implementation = Coding.
Software is usually designed and created (coded/written/programmed) in integrated development
environments (IDE) like Eclipse, Xcode or Microsoft Visual Studio that can simplify the process and
compile the program to an executable unit. Software is usually created on top of existing software
and the application programming interface (API) that the underlying software frameworks
provide, e.g. Microsoft .NET, etc.
Most of the software has a Graphical User Interface (GUI). Normally you separate the GUI design
and code into different layers or files.
[[Link]
More about implementation later in this document.
Part 2: Software Engineering
51 5 Software Development Phases
5.4 Testing
Testing can be performed on different levels and by different people. Testing is a very important
part of software development. About 50% of the software development is about testing your
software. Creating User-friendly Software is Crucial! More about Testing later in this document.
5.5 Deployment
What is Deployment?
Software deployment is all the activities that make a software system available for use.
Examples:
• Get the software out to the customers
• Creating Installation Packages
• Documentation, e.g., Installation Guide, etc.
• Installation
• etc.
Deployment strategies may vary depending on what kind of software we create, etc.
More about Deployment later in this document.
When the software is deployed, or installed, you normally go into a Maintenance phase. The
maintenance of software involves bug fixes of the software after the software is released, etc. At
some time, you also need to start planning new releases of the software.
Part 2: Software Engineering
6 Software Development
Process
There are lots of different software development processes or methods in use today, e.g.:
• Waterfall model
• V-model
• Spiral model
• Unified Process (UP)/ Rational Unified Process (RUP)
• Scrum
• eXtreme Programming (XP)
• Lean Software Development
• TDD (Test Driven Development)
• Lean Software Development
• Kanban
• etc.
These processes or models may be divided into 2 main categories: Plan-driven models and Agile
methods. The Waterfall model, V-model and Spiral model are so-called plan-driven models, while
Scrum and eXtreme Programming are so-called Agile methods.
[[Link]
52
53 6 Software Development Process
Traditionally plan-driven methods were used in software development, while today Agile methods
such as Scrum have become very popular, especially in smaller development teams.
Plan-driven models (e.g. Waterfall) generally produce more documentation than Agile models.
In Figure 6-1 we see an overview of some of the most used methods.
Figure 6-1: Software Development Methods
In Figure 6-2 we see the main difference between Agile development and ordinary plan-driven
development.
Figure 6-2: Plan-driven vs. Agile Development (Sommerville)
Part 2: Software Engineering
54 6 Software Development Process
[[Link]
6.1 Plan-driven models
We have different plan-driven models such as the Waterfall model, V-model, and Spiral model
which we will discuss in more detail.
6.1.1 Waterfall model
The Waterfall model consists of the following phases:
• Requirements specification (Requirements analysis)
• Software design
• Implementation and Integration
• Testing (or Validation)
• Deployment (or Installation)
• Maintenance
Traditionally with the Waterfall model, you can only start on the next phase when the previous
phase is finished. Therefore, it is called the Waterfall method, see Figure 6-3.
Part 2: Software Engineering
55 6 Software Development Process
Figure 6-3: Waterfall model
In practice, there is impossible to create perfect requirements and design before you start
implementing the code, so it is common to go back and update these phases iteratively.
6.1.2 V-model
The V-model is derived from the more traditional Waterfall model. The V-model is an extension of
the waterfall model, but it’s using a more flexible approach.
“The V-Model reflects a project management view of software development and fits the needs of
project managers, accountants and lawyers rather than software developers or users.”
Part 2: Software Engineering
56 6 Software Development Process
Figure 6-4: V-model [5]
As we see in Figure 6-4, the left side is about requirements and design, while the right-side of the
model is about testing and validating.
6.2 Agile Software Development
Agile software development is a group of software development methods based on iterative and
incremental development.
[[Link]
So, what is Agile development? – Here is a short summary:
• A group of software development methods
• Iterative approach
• Incremental: Software available to Customers every 2-4 weeks
Part 2: Software Engineering
57 6 Software Development Process
• Self-organizing and cross-functional Teams
• Refactoring
In Figure 6-5 we see some important Agile features and principles.
Figure 6-5: Agile Features and Principles
Examples of popular Agile methods:
• Scrum
• eXtreme Programming (XP)
In Figure 6-6 we see the key features with Agile Software Development.
Figure 6-6: Agile Software Development
Part 2: Software Engineering
58 6 Software Development Process
Figure 6-7 shows some main differences between Agile development and more traditional
development methods, such as, e.g., the Waterfall method.
Figure 6-7: Agile vs. Traditional Development (Wikipedia)
Agile Project Management Terms (PM Aspirant): [Link]
6.2.1 The Manifesto for Agile Software Development
In 2001, some software developers met to discuss development methods. They published the
Manifesto for Agile Software Development to define the approach now known as agile software
development.
The Manifesto for Agile Software Development is as follows:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work, we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Part 2: Software Engineering
59 6 Software Development Process
[[Link]
6.2.2 Burndown Chart
A burn down chart is a graphical representation of work left to do versus time. The outstanding
work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run
chart of outstanding work. It is useful for predicting when all the work will be completed.
It is often used in agile software development methodologies such as Scrum. However, burn down
charts can be applied to any project containing measurable progress over time.
In Figure 6-8 we see a typical Burndown chart.
Figure 6-8: Burndown Chart
Part 2: Software Engineering
60 6 Software Development Process
6.2.3 Waterfall vs. Agile
Agile is more flexible than traditional methods (like the waterfall).
Here are some key factors that separate the traditional waterfall method versus the more flexible
Agile methods, such as Scrum:
• Agile and Scrum is based on Iterations while Waterfall is Sequential
• Agile and Scrum focus on less documentation
• Agile is good for small projects – not so good for larger projects?
• If the Customer don’t know what he wants in detail – Scrum is a good approach
In Figure 6-9 we see some important differences between the traditional waterfall method and
the Agile Development approach. We see that Agile delivers value in each iteration of the
development.
Figure 6-9: Waterfall vs. Agile Development
Agile vs Waterfall: [Link]
6.2.4 eXtreme Programming (XP)
eXtreme Programming or shorted XP is a popular Agile method. Typical features in XP are as
follows:
• Pair Programming
• Code Reviews
• Refactoring
Part 2: Software Engineering
61 6 Software Development Process
• Unit Testing - In XP you start by writing Unit Tests before you start coding
• Standup Meetings
[[Link]
What is Extreme Programming (XP)? [Link]
In Figure 6-10 we see how XP works in practice.
Figure 6-10: eXtreme Programming
In XP, they practice so-called “Pair Programming” (Figure 6-11), meaning 2 developers working
together.
Part 2: Software Engineering
62 6 Software Development Process
Figure 6-11: Pair Programming (Wikipedia)
So, is Pair Programming Good or Bad? There exist various studies of the productivity of Pair
Programming (Sommerville):
• Study 1: Comparable with that of 2 developers who work independently
• Study 2: A significant loss in productivity compared with 2 developers working alone
A reasonable question is: Should the 2 developers have the same skills or not?
Newer less, there are benefits with XP:
• Collective Ownership for the code created and the results of the project.
• Continuous informal Review process because each code line is looked at by at least 2
people
• It supports Refactoring, which is a continuous process of software improvement
• Less time is spent on repairing bugs.
• Improved Code Quality
• It reduces the overall risk
Part 2: Software Engineering
63 6 Software Development Process
[[Link]
6.2.5 Scrum
Scrum is a so-called Agile method, and it has become very popular today. In Figure 6-12 we see an
overview of the Scrum method.
What is Scrum (PM Aspirant)? [Link]
Azure DevOps with Scrum: [Link]
Scrum is simple and easy to understand. The method is more flexible and more informal than plan-
driven methods.
Part 2: Software Engineering
64 6 Software Development Process
Figure 6-12: Scrum Overview
In short, Scrum is a Framework for Software Development.
• Agile Software Development method
• Simple to understand
• Flexible
• Extremely difficult to master!
• Self-organizing Teams (3-9 people)
• Scrum Team:
o Product Owner
o Scrum Master
o Development Team
Some important Scrum Events are:
• The Sprint (duration between 14-30 days)
• Sprint Planning Meeting (8 hours if 30 days’ sprint)
• Daily Scrum Meeting (Max 15 min, every day at the same time) (also called Standup
Meeting)
• Sprint Review (4 hours if 30 days’ sprint)
An example of a Daily Scrum Meeting is shown in Figure 6-13. It is normal to hold this meeting as a
“standup meeting”, where participants standing during the meeting.
Part 2: Software Engineering
65 6 Software Development Process
Figure 6-13: Example of a Daily Scrum Meeting (Standup Meeting)
Daily Scrum Meeting:
Important features of the Daily Scrum Meeting are as follows:
• Max 15 min.
• The meeting is held at the same time and place every day
• “Stand Up” Meeting
• Purpose:
o Synchronize activities and create a plan for the next 24 hours.
o Track Progress
• Agenda – Each Team member explains:
o What has been accomplished since the last meeting?
o What will be done before the next meeting?
o What obstacles are there in the way?
6.2.6 Kanban
Kanban is based on Lean and Toyota production principles and Just-in-Time principles. Kanban has
fewer “rules” than scrum. Kanban is flow-based, while Scrum is Time box-based (Sprints). Kanban
focuses on limiting the WIP (Work in Progress). Kanban has focus on estimation.
In Kanban, they use a Kanban board (Figure 6-14) to track the progress. The Kanban board is very
similar to the Task board/Scrum board used in Scrum.
Part 2: Software Engineering
66 6 Software Development Process
Figure 6-14: Example of a Kanban board
What is Kanban (PM Aspirant)? [Link]
Scrum vs. Kanban (PM Aspirant): [Link]
6.3 Hybrid Process Models
6.3.1 Unified Process (UP)/ Rational Unified Process (RUP)
The Unified Process (UP)/ Rational Unified Process (RUP) is a so-called hybrid process model
(Sommerville). It takes elements from many of the traditional plan drive methods as well
iterative/incremental delivery, which is an important part of Agile methods.
The RUP has been designed to work together with UML (Unified Modelling Language).
In Unified Process (UP) we have 4 different phases:
• Inception
• Elaboration
• Construction
• Transition
Part 2: Software Engineering
67 6 Software Development Process
Figure 6-15 shows these 4 phases.
Figure 6-15: Phases in Unified Process (UP) (Wikipedia)
6.4 Summary
Agile methods have become very popular today. Agile methods are good in some situations, while
more traditional methods are better in other situations.
To create great software, we need to combine the best of all these approaches and adjust them to
fit the needs of your company. There are lots of different kinds of software, and one method is not
fit to solve all these different situations.
Agile methods have less focus on documentation
6.5 Exercises
Make sure to discuss and reflect over the following:
1. What is a Software Development Process? Why is it important to have a good Software
Development Process?
2. Explain Plan-driven software development in general
3. Give some examples of such Plan-driven software development methods
4. Explain Agile software development in general
Part 2: Software Engineering
68 6 Software Development Process
5. Give some examples of Agile software development methods
6. Explain the Waterfall method
7. Explain the differences between Agile and plan-driven development. Give some examples in
each category
8. Explain some features used in eXtreme Programming (XP)?
9. What is Scrum?
10. Give examples of Advantages and Disadvantages with Scrum
11. What is a Daily Scrum Meeting?
12. What are the different phases involved in software engineering?
13. Suggest a Software Project where it may be beneficial to use the Waterfall model and another
where Scrum is the best choice
Part 2: Software Engineering
7 Scrum
Scrum is a so-called Agile method, and it has become very popular today. In Figure 7-1 we see an
overview of the Scrum method. Scrum is simple and easy to understand. The method is more
flexible and more informal than plan-driven methods.
What is Scrum (PM Aspirant)? [Link]
Azure DevOps with Scrum: [Link]
Figure 7-1: Scrum Overview
In short, Scrum is a Framework for Software Development.
• Agile Software Development method
• Simple to understand
• Flexible
• Extremely difficult to master!
• Self-organizing Teams (3-9 people)
• Scrum Team:
o Product Owner
o Scrum Master
o Development Team
69
70 7 Scrum
7.1 The Scrum Process
Figure 7-2 shows the Scrum Process.
Figure 7-2: Scrum Process [9]
7.2 Scrum Events
We have the following Scrum events and meetings:
• The Sprint (duration between 14-30 days)
• Sprint Planning Meeting (8 hours if 30 days’ sprint)
• Daily Scrum Meeting (Max 15 min, every day at the same time) (also called Standup
Meeting)
• Sprint Review (4 hours if 30 days’ sprint)
An example of a Daily Scrum Meeting is shown in Figure 7-3. It is normal to hold this meeting as a
“standup meeting”, where participants standing during the meeting.
Part 2: Software Engineering
71 7 Scrum
Figure 7-3: Daily Scrum Meeting (Standup Meeting) (Wikipedia)
7.2.1 Daily Scrum Meeting
Important features of the Daily Scrum Meeting are as follows:
• Max 15 min.
• The meeting is held at the same time and place every day
• “Stand Up” Meeting
• Purpose:
o Synchronize activities and create a plan for the next 24 hours.
o Track Progress
• Agenda – Each Team member explains:
o What has been accomplished since the last meeting?
o What will be done before the next meeting?
o What obstacles are there in the way?
Part 2: Software Engineering
72 7 Scrum
[[Link]
7.3 Scrum Artifacts
We have the following Scrum artifacts:
• Product Backlog
• Sprint Backlog
• Increment
Scrum’s artifacts represent work or value in various ways that are useful in providing transparency and
opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to
maximize transparency of key information needed to ensure Scrum Teams are successful in delivering a
“Done” Increment (The Scrum Guide - [Link]
7.4 The Scrum Team
The Scrum Team has the following members:
• Product Owner
• Scrum Master
• Development Team
In addition, we have the Stakeholders, but they are not part of the Scrum team itself.
Part 2: Software Engineering
73 7 Scrum
[[Link]
Project Manager vs Scrum Master (PM Aspirant): [Link]
7.5 Scrum Meetings
So, if we summarize, we have 4 different meetings in Scrum:
• Sprint Planning Meeting
• Daily Scrum Meeting
• Sprint Review Meeting
• Retrospective Meeting
Figure 7-4 summarizes the different meetings (purpose, duration, and frequency).
Part 2: Software Engineering
74 7 Scrum
Figure 7-4: Overview of Scrum Meetings
For Scrum meetings, we have the following guidelines:
• The meeting agenda should be clear.
• If team members start a discussion that does not address the purpose of the meeting, the
members should take the discussion offline, to be completed later. The Scrum Master
should identify and indicate when team members should take a discussion offline.
• All meetings should follow the basic structure that is described for that meeting.
• Meetings should start on time, even if some team members are late.
• Team members should be on time except in rare, unavoidable cases. If your schedule
prevents you from being on time regularly, the conflict should be resolved as soon as
possible. If necessary, the Scrum Master should adjust the meeting time to resolve the
conflict if the change does not unfairly inconvenience another member of the team.
• Each team member should come to the meeting prepared.
• Meetings should finish on time. In most cases, the length of the meeting is determined by
the length of the sprint. For example, take two hours for a sprint planning meeting if the
sprint is one week, and four hours if the sprint is two weeks long.
• Scrum enforces this meeting structure to a level that might make people uncomfortable.
This reaction comes from the pressure to be on time, the peer accountability that is
associated with making and keeping commitments, and the transparency that is required
to actively participate. Daily Scrum meetings are also usually a standup meeting.
7.6 Scrum Terms
Below we summarize the terms used in Scrum.
Scrum:
Scrum is a framework structured to support complex product development. Scrum consists of
Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the
framework serves a specific purpose and is essential to Scrum’s success and usage.
The Scrum Team:
Part 2: Software Engineering
75 7 Scrum
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum
Teams are self-organizing and cross-functional. Self-organizing teams choose best to accomplish
their work, rather than being directed by others outside the team.
Development Team:
The Development Team are the professionals who do the work of delivering a potentially
releasable Increment of “Done” product at the end of each Sprint. Development Teams are
structured and empowered by the organization to organize and manage their own work.
Product Owner:
The Product Owner is the person responsible for maximizing the value of the product, the work of
the Development Team, and management of the Product Backlog.
Scrum Master:
The Scrum Master is a servant-leader for the Scrum Team responsible for ensuring Scrum is
understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to
Scrum theory, practices, and rules.
Product Backlog:
The Product Backlog is an ordered list of everything that might be needed in the product and is the
single source of requirements for any changes to be made to the product. The Product Owner is
responsible for the Product Backlog, including its content, availability, and ordering.
Sprint Backlog:
The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for
delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by
the Development Team about what functionality will be in the next Increment and the work
needed to deliver that functionality.
Increment:
The Increment is the sum of all the Product Backlog items completed during a Sprint and all
previous Sprints.
Sprint:
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable,
and potentially releasable product Increment is created. Sprints have consistent durations
throughout a development effort. A new Sprint starts immediately after the conclusion of the
previous Sprint.
Sprint Planning Meeting:
Part 2: Software Engineering
76 7 Scrum
The work to be performed in the Sprint is planned at the Sprint Planning Meeting. This plan is
created by the collaborative work of the entire Scrum Team.
Daily Scrum:
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize
activities and create a plan for the next 24 hours. This is done by inspecting the work since the last
Daily Scrum and forecasting the work that could be done before the next one.
Sprint Review:
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product
Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about
what was done in the Sprint. Based on that and any changes to the Product Backlog during the
Sprint, attendees collaborate on the next things that could be done. This is an informal meeting,
and the presentation of the Increment is intended to elicit feedback and foster collaboration.
Sprint Retrospective:
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan
for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the
Sprint Review and prior to the next Sprint Planning Meeting. This is a three-hour time-boxed
meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints.
7.7 Tips and Tricks
Here are some Tips and Tricks when performing Agile/Scrum:
• Bring the Customer to the Daily Scrum Meetings
• Check out Pair Programming
• Use a Task Board (Whiteboard with Sticky Notes)
• Write Tests before you Write Code
• Continuously Integrate Changes and have Code Reviews and do continuous Code
Refactoring
• Prioritize the Product Backlog
• Have Demonstrations for the Customer during the Project
• Be sure to have a common understanding of Goals, Problems and Solutions
7.8 Scrum Tools
There exists lots of tools that’s support the Scrum methodology, Azure DevOps is one of them.
More about Azure DevOps later in this document.
Part 2: Software Engineering
77 7 Scrum
Azure DevOps with Scrum: [Link]
Part 2: Software Engineering
8 Project Management
Project management is the key factor in any software development projects. Project management
is the discipline of planning, organizing, motivating, and controlling resources to achieve specific
goals.
Making Gantt diagram with Microsoft Excel: [Link]
Planner App in Microsoft Teams: [Link]
In Figure 8-1 we see the well-known project triangle.
Figure 8-1: Project Triangle
Here are some Key factors for successful project management:
• Proper Planning
• Kick-off and Brainstorming
• Planning and Estimation
• Project Tracking
78
79 8 Project Management
• Communication and Collaboration
• Meetings
• Using proper Tools, such as e.g., Azure DevOps
Project Work consists of working with Project Management, Development and Documentation in
parallel.
If you remove one of these, the project will fail! Assume you have a table with 3 legs, see Figure
8-2. If you remove one of the legs from the table, the table will fall apart.
Figure 8-2: Project Management, Development and Documentation
8.1 Project Planning
Software development involves lots of activities that need to be planned and synchronized. To do
that we need good tools for these activities. The Gantt chart is probably the most used tool. In
addition, we need to have different meetings to plan and coordinate the different activities.
Agile Development also needs Project Management and Planning, which we will discuss in more
detail later in this chapter.
Part 2: Software Engineering
80 8 Project Management
[[Link]
In project work in general it is important that you complete the plans for this week so that you
don't fall behind and must do last week's work in addition to this week's work. Then there will be
increasingly more work to do every week. See Figure 8-3.
Figure 8-3: How to Work in a Project
8.2 Kick-off/Brainstorming
A Project should always start with a Kick-off meeting where a brainstorming session is important
of that meeting.
Part 2: Software Engineering
81 8 Project Management
During the brainstorming, you should:
• Involve all in the group
• Discuss what you are going to do in the project
• How are you going to solve the project?
• etc.
In addition to getting good ideas for solving the project, you should learn from previous projects.
Examples: Who are going to solve the different parts, what kind of Frameworks are you going to
use, what kind of development tools you use, etc.
[[Link]
Part 2: Software Engineering
82 8 Project Management
8.3 Software Development Plan (SDP)
Communication is the key to success! Below we list some examples of how to avoid
communication problems (E. J. Braude and M. [Link], Software Engineering: Modern
Approaches):
• Listen to all with concentration
• Don’t pre-judge
• Give all team members a turn
• See the value in every idea
• Don’t make assumptions
• Ask questions to clarify
• When in doubt, communicate
A good idea is to create a Software Development Plan. The Software Development Plan gives an
overview of all the communication within the project or within the team, i.e., what kind of
communication, how the communication should be done, etc.
Examples of Communication:
• Meetings: The Team will meet every Monday from …
• Standards: Which Word processor, Templates, etc.
• E-mail… or other communication platforms, …
• Collaboration: How will you communicate? Work together on Tuesdays, …
• Other Tools: Microsoft Project, …
• etc.
The Software Development Plan typically includes the following sections:
1. Introduction: This briefly describes the objectives of the project and set out the constraints
(e.g., budget, time, etc.) that affects the management of the project
2. Project Organization: This section describes how the development team is organized, the
people involved and their roles in the team.
3. Risk Analysis
4. Hardware and Software Resource Requirements
5. Work Breakdown (WBS, Work Breakdown Structure): Break down the project into
activities and identifies milestones
6. Project Schedule: Shows dependencies between activities, the estimated time required to
reach each milestone, allocation of people to activities. (5) and (6) is typically done in a
Gantt Chart (created in e.g., Microsoft Project)
Part 2: Software Engineering
83 8 Project Management
7. Monitoring and Reporting Mechanisms: Definition of the Management Report that should
be produced, when these should be produced, etc.
Other words for the Software Development Plan may be “Communication Plan” or “Project Plan”.
A Software Development Plan (SDP) is all about the Internal Communication within the
Development Team and how it Communicates with rest of the Organization, the Customers, etc.
8.3.1 Project Plan and Gantt Chart
A project plan provides a detailed overview of the work to be carried out and is used to monitor
and evaluate the project’s progress over time. A progress plan describes tasks, deadlines,
duration, responsible persons, and dependencies between tasks. The progress plan is therefore a
key tool that implements the overall plans defined in the project. Keep in mind that a progress
plan is not something you create and then “put in a drawer”, it must be actively used and updated
throughout the entire project period, continuously reflecting the project’s status.
A project plan should include an overview of the project’s main activities, duration, start and end
dates for each task, identification of dependencies between tasks, key milestones, allocation of
responsibilities, and an indicator of the status of the various activities to ensure control and
visibility. It must also show purpose and goals, and be realistic and flexible enough to handle
unforeseen events
One of the most used tools for project planning is the Gantt chart. The Gantt chart gives an
overview of tasks, subtasks, milestones, resources, etc. in a project. A Gantt chart is a project
management tool that visually represents a project plan over time. It uses horizontal bars to
illustrate the start and end dates of tasks, their duration, and their dependencies. You can use
Excel or, for example, a web-based alternative such as [Link].
In Figure 8-4 we see a Gant Chart example created with Microsoft Excel.
Part 2: Software Engineering
84 8 Project Management
Figure 8-4: Gant Chart Example created with Microsoft Excel
Making Gantt diagram with Microsoft Excel: [Link]
Tools for creating Gantt Charts: Microsoft Excel can be used, but there are also many other tools
that are more tailored to the task, including downloadable applications as well as web applications
such as ClickUp. Online tools make it much easier to share and collaborate on the progress plan
within a development team, share status updates with customers and management, etc. Other
alternatives include Canva, Miro and [Link].
A project plan and a Gantt chart are created to structure, visualize, and monitor the different
elements and tasks that are part of a project. They provide a clear overview of activities,
milestones, dependencies, and resource usage, which ensures better communication, progress
tracking, and a higher likelihood of achieving the project goals within time and budget constraints.
Main benefits of using a Gantt chart and project plan:
• Visual overview: Provides a “bird’s-eye view” of the entire project, where start and end
dates for various tasks are shown as horizontal bars on a timeline.
• Structured progress: Makes it easy to track progress by showing how far activities have
progressed (e.g., using colors or partially filled bars).
• Identification of dependencies: Clearly shows which tasks must be completed before
others can start, which is essential for planning.
• Resource management: Helps distribute and manage resources (people, equipment)
efficiently over time.
• Improved communication: Serves as a shared tool for the team and stakeholders (project
manager, customer, etc.), making it easier to understand the plan and manage changes.
• Milestone management: Highlights important checkpoints (milestones) in the project to
ensure that intermediate goals are achieved.
Part 2: Software Engineering
85 8 Project Management
In addition to a Gantt diagram the development team will typically use a Task board (which is
often called a Scrum board or a Kanban board) for development details.
What should be included in the Gantt chart?
A progress plan/Gantt chart typically includes:
• Project title
• Overview of available resources/personnel
• Project start and end dates
• Total number of hours available (School project: How many hours do you want to work per
week? Multiply by the number of weeks to calculate the total number of hours.)
In addition to the general project information above it should include a table with the following
information:
• Task – Work/task title or description
• Grouping/category
• Estimated hours per subtask (task)
• Rule of thumb: A task should not be too large, e.g., max 8 hours in duration. If tasks
become too large, they should be split into several smaller tasks.
• Resource/responsible person
• (Can be omitted if only one person is involved)
• Progress (%) for each subtask (This means the progress plan must be updated regularly, at
least once per week)
• Start and end dates for each task (Optionally, you can use week numbers instead,
depending on the level of detail required)
Important! It is important that project management is an active part of your software project. The
Gantt Chart should be used through the whole project; it is not something you create in the
beginning of the project and put in a drawer.
In Figure 8-5 we see the recommended way of working with the different project activities.
Part 2: Software Engineering
86 8 Project Management
Figure 8-5: Project Work
Here is an example of a Gantt chart created using [Link] (see Figure 8-6):
Figure 8-6: Gantt Chart created with [Link]
Part 2: Software Engineering
87 8 Project Management
Summary: With a Gantt chart you can determine how much work your team has completed and
how much work that remains. Project managers should routinely update and share a Gantt chart
with the project team. This allows all members to see how they are working together to achieve
the same outcomes. It becomes much easier to manage project dependencies and update plans
along the way. Communication is significantly improved by using it. Make sure to update the Gantt
chart regularly and share it continuously with everyone involved throughout the project. Always
create a Project Plan!
8.4 Meetings
It is necessary to have meetings when planning and creating software, but these meetings should
not be misused.
Below we list some typical meetings needed during the software development project:
• Kickoff and Planning Meetings
• Project Meetings
• Daily Scrum Meetings
• Review Meetings
• Meetings for Planning the next Sprint/Iteration
For meetings in general we have the following guidelines:
• The meeting agenda should be clear.
• All meetings should follow the basic structure that is described for that meeting.
• Meetings should start on time, even if some team members are late.
• Meetings should finish on time.
• Each team member should come to the meeting prepared.
Always be prepared before the meetings (otherwise you don’t need to be there)!
8.4.1 Meeting Agenda
A typical meeting agenda could be as follows:
• Project Plan, Gantt Chart (Project Manager)
• Work Items, Overview and Status (Test Manager)
• Demonstration of Applications/Coding (Individual)
• Short Status for each member (Individual)
o What have you done so far?
Part 2: Software Engineering
88 8 Project Management
o What shall the focus be the next weeks?
o Any Technical Challenges/Problems/Issues? (It is very important to get an overview
of the challenges in the project, or else the whole project will be at risk if you don’t
talk about them!)
o Other matters
• The meeting should last no longer than 60 minutes.
When you are finished with the meeting, write a short Minutes of Meeting as soon as possible.
8.4.2 Minutes of Meeting
Write a “Minutes of Meeting” (send on e-mail to team members and supervisor the same day!).
The purpose of this is twofold:
• Important decisions or agreements are recorded, so they are not forgotten!
• The second purpose is to record unsolved issues that require follow up action, so-called
action items. Each action item is assigned to one (preferred) or more team members with a
specific deadline for completion.
Always create a Minutes of Meeting!
The Minutes of Meetings should include a table like this:
Task Responsible Deadline
… … …
… … …
In this way, we can easily get an overview of the tasks agreed in the meeting, which is responsible
for the tasks, and a specific deadline for each task. This task list should be followed up in the next
meeting.
8.5 Agile Project Planning and Tracking
Successful projects often have the following characteristics:
• The needs of the customers drive the project.
• The team creates a high-level plan for delivering the project.
• The team develops the product over several iterations and refines the high-level plan over
time.
• The team has effective tools for adapting to changes that occur.
Part 2: Software Engineering
89 8 Project Management
Figure 8-7 shows the steps involved in Agile Project Planning and Tracking.
Figure 8-7: Agile Project Planning and Tracking
In Agile Project Planning and Tracking, everything is broken down to so-called iterations, as shown
in Figure 8-8.
Figure 8-8: Using Iterations in Agile Project Planning and Tracking
The Task board is a key tool in Agile Project Planning and Tracking, see Figure 8-9
Part 2: Software Engineering
90 8 Project Management
Figure 8-9: Task board used in Agile Software development
The Task board is used together with the Burndown chart, as shown in Figure 8-10.
Part 2: Software Engineering
91 8 Project Management
Figure 8-10: Burndown Chart
A burn down chart is a graphical representation of work left to do versus time. The outstanding
work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run
chart of outstanding work. It is useful for predicting when all the work will be completed.
It is often used in agile software development methodologies such as Scrum. However, burn down
charts can be applied to any project containing measurable progress over time.
Azure DevOps have all these features (Task board, Burndown chart, etc.) built in.
Azure DevOps is explained in detail in chapter 24.
8.6 Microsoft Teams
Microsoft Teams is a great tool for teamwork, collaboration and project work. Here you can chat,
share documents, have online meetings, etc. Microsoft Teams is also a good tool for Project
Planning and Management by using, e.g., Microsoft Planner.
Microsoft Planner App in Microsoft Teams: [Link]
Part 2: Software Engineering
92 8 Project Management
8.7 Summary
Here are some important keywords for successful project management:
• Software Project Management is important to keep the project on track
• Agile Project Management = less documentation
• Useful tools are in Project Management and Tracking are Gantt Chart, Task board,
Burndown Chart
• You should always create a Communication Plan
• You should always start the project with a Brainstorming session.
Part 2: Software Engineering
9 Requirements Engineering
Before you start to implement a software system, you need to understand what the system is
intended to do. This intended functionality is the “Requirements”. The process of creating these
requirements is called Requirement Analysis or Requirement Engineering. It is the process of
understanding what you want and what you need in your software.
Requirements Engineering (RE) refers to the process of formulating, documenting, and
maintaining software requirements.
The results of the Requirement Analysis or Requirement Engineering process is normally one or
more documents, called the Software Requirement Specification (shorted “SRS”).
The requirements are in some cases created by the customer, at least the overall requirements (it
defines “What” the customers want), while more details are normally created by architects and
developers in the software company that is going to develop the actual software. Here we can
have both “What” and “How” the software shall be designed or implemented.
The main challenges in Requirements Engineering are that the customers most often don’t know
what they want or are not qualified to know what they need.
In general, we can summarize the following:
• Stakeholders don’t know what they want.
• Stakeholder’s express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organizational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may emerge, and
the business environment may change.
In Figure 9-1 we see different types of requirements.
Figure 9-1: Software Requirements
93
94 9 Requirements Engineering
In Figure 9-2 and below we explain the different software requirements categories in more detail.
Figure 9-2: Software Requirements Categories Overview
User Requirements
Statements in natural language plus diagrams of the services the system provides and their
operational constraints. Written for customers.
System Requirements
A structured document setting out detailed descriptions of the system’s functions, services and
operational constraints. Defines what should be implemented so may be part of a contract
between client and contractor.
Figure 9-3: Requirements Users (Sommerville)
Functional Requirements
Statements of services the system should provide, how the system should react to inputs and how
the system should behave in different situations.
Part 2: Software Engineering
95 9 Requirements Engineering
May state what the system should not do.
Non-Functional Requirements
Constraints on the services or functions offered by the system such as timing constraints,
constraints on the development process, standards, etc.
They often apply to the system rather than individual features or services.
Since there are different people involved creating and reading the requirements documents, the
requirements are normally split into “High-Level Requirements” and “Detailed Requirements”
(Figure 9-4).
Figure 9-4: High-Level Requirements vs. Detailed Requirements
High-level requirements are for “business” people, while detailed requirements are for
developers, etc.
9.1 User Requirements
User requirements are statements in natural language plus diagrams of the services the system
provides and its operational constraints. User requirements are written for customers.
9.2 System Requirements
System requirements are setting out detailed descriptions of the system’s functions, services and
operational constraints. They define what should be implemented may be part of a contract
between client and contractor.
9.3 Functional Requirements
Functional Requirements are:
• Describe functionality or system services.
• Depending on the type of software, expected users and the type of system where the
software is used.
Part 2: Software Engineering
96 9 Requirements Engineering
• Functional user requirements may be high-level statements of what the system should do.
• Functional system requirements should describe the system services in detail.
9.4 Non-Functional Requirements
Non-Functional Requirements are:
• These define system properties and constraints e.g. reliability, response time and storage
requirements. Constraints are I/O device capability, system representations, etc.
• Process requirements may also be specified using an IDE, programming language or
development method.
• Non-functional requirements may be more critical than functional requirements. If these
are not met, the system may be useless.
9.5 SRS
Software Requirements Specifications (SRS) are:
• The software requirements document is the official statement of what is required of the
system developers.
• It should include both a definition of user requirements and a specification of the system
requirements.
• It is NOT a design document. As far as possible, it should set of WHAT the system should do
rather than HOW it should do it.
In practice, requirements and design are inseparable. Many don’t separate SRS and SDD (Software
Design Document) documents but include everything in a Requirements & Design Document. Such
a document could be called “Software Requirements and Design Document” (SRD).
In Figure 9-5 we see some typical contents of such a SRS/SDD document.
Part 2: Software Engineering
97 9 Requirements Engineering
Figure 9-5: Typical SRS/SDD Contents
In Figure 9-6 we see the different users involved in the SRS document.
Figure 9-6: Users of SRS (Sommerville)
Part 2: Software Engineering
98 9 Requirements Engineering
In Table 9-1 we see an example of what chapters that we can include in an SRS document.
Table 9-1: Example of Table of Contents for the SRS document (Sommerville)
Chapter Description
Preface This should define the expected readership of the document and
describe its version history, including a rationale for the creation of a
new version and a summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe
the system’s functions and explain how it will work with other systems.
It should also describe how the system fits into the overall business or
strategic objectives of the organization commissioning the software.
Glossary This should define the technical terms used in the document. You
should not make assumptions about the experience or expertise of the
reader.
User Requirements Here, you describe the services provided for the user. The
Definition nonfunctional system requirements should also be described in this
section. This description may use natural language, diagrams, or other
notations that are understandable to customers. Product and process
standards that must be followed should be specified.
System Architecture This chapter should present a high-level overview of the anticipated
system architecture, showing the distribution of functions across
system modules. Architectural components that are reused should be
highlighted.
System This should describe the functional and nonfunctional requirements in
Requirements more detail. If necessary, further details may also be added to the
Specification nonfunctional requirements. Interfaces to other systems may be
defined.
System Models This might include graphical system models showing the relationships
between the system components and the system and its environment.
Examples of possible models are object models, data-flow models, or
semantic data models.
Part 2: Software Engineering
99 9 Requirements Engineering
System Evolution This should describe the fundamental assumptions on which the
system is based, and any anticipated changes due to hardware
evolution, changing user needs, and so on. This section is useful for
system designers as it may help them avoid design decisions that would
constrain likely future changes to the system.
Appendices These should provide detailed, specific information that is related to
the application being developed, for example, hardware and database
descriptions. Hardware requirements define the minimal and optimal
configurations for the system. Database requirements define the
logical organization of the data used by the system and the
relationships between data.
Index Several indexes to the document may be included. As well as a normal
alphabetic index, there may be an index of diagrams, an index of
functions, and so on.
9.6 Project Estimation
Getting an overview of the total cost in a software project is important. The features and
requirements need to be broken down into manageable tasks by the team. Each Tasks then needs
to be estimated (Hours).
9.7 Exercises
Make sure to discuss and reflect over the following:
1. What are Software Requirements?
2. Requirements vs. Design – What is the main difference?
3. Different types of Requirements
4. What are User Requirements?
5. What are System Requirements?
Part 2: Software Engineering
100 9 Requirements Engineering
6. What are Functional Requirements?
7. What are Non-Functional Requirements?
8. Give some examples of Non-Functional Requirements
9. What is SRS?
10. Mention some Requirements Analysis Problems/Challenges?
Part 2: Software Engineering
10 User eXperience (UX)
Designing and creating the graphical user interface is a very important part of software
development. We have different names for it; User eXperience (UX), Graphical User Interface
(GUI) or Human Machine Interface (HMI).
GUI design has been in constant change since the first computers and software were created. In
Figure 10-1 we see some images of different Windows versions.
Figure 10-1: Examples of User Interface for different Windows versions
It is important that documents, GUI, code, etc. have the same “Look and Feel”, i.e. make sure to
use common guidelines, templates, etc.
In software design, look and feel is a term used in respect of a graphical user interface and
comprises aspects of its design, including elements such as colors, shapes, layout, and typefaces
(the "look"), as well as the behavior of dynamic elements such as buttons, boxes, and menus (the
"feel"). The term can also refer to aspects of an API, mostly to parts of an API that are not related
to its functional properties.
“Look and Feel”in operating system user interfaces serve two general purposes. First, it provides
branding, helping to identify a set of products from one company. Second, it increases ease of use,
since users will become familiar with how one product functions (looks, reads, etc.) and can
translate their experience to other products with the same look and feel.
101
102 10 User eXperience (UX)
It is the “UX Designer” that design the GUI, while the Programmer make sure to implement it in
the proper programming language (Figure 10-2).
Figure 10-2: UX Designer
10.1 UX Guidelines
Different platforms have different UX and UX guidelines, so it is important to follow these general
guidelines for the different platforms. The GUI is totally different on, e.g., Windows and Mac OS X.
The different platform vendors create their own guidelines that the developers should follow.
Figure 10-3 is an example from an old version UX Guidelines for macOS.
Part 2: Software Engineering
103 10 User eXperience (UX)
Figure 10-3: Examples of UX Guidelines (Apple)
Here are some examples of UX guidelines:
• Human Interface Guidelines from Apple: [Link]
interface-guidelines
• Android Material Design Guidelines: [Link]
10.2 GUI Mockup
Creating so-called GUI mockups is an important part of the process of creating user-friendly GUI.
Mockups and prototypes are not so cleanly distinguished in software and systems engineering,
where mockups are a way of designing user interfaces on paper or in computer images. A software
mockup will thus look like the real thing but will not do useful work beyond what the user sees. A
software prototype, on the other hand, will look and work just like the real thing. In many cases it
is best to design or prototype the user interface before source code is written or hardware is built,
to avoid having to go back and make expensive changes.
In Figure 10-4 we see an example of a GUI Mockup.
Part 2: Software Engineering
104 10 User eXperience (UX)
Figure 10-4: GUI Mockup Example
Be creative - Think outside the box! “Thinking outside the box” is a metaphor that means to think
differently, unconventionally, or from a new perspective.
10.3 Universal Design
Universal design (in Norwegian: Universell utforming - UU) is about designing and facilitating
products, environments, programs and services so that they can be used by all people, regardless
of age, disability or other factors.
The goal is to create inclusive solutions that provide equal opportunities for participation and
accessibility for all. That is, to create content and functionality that is accessible to everyone.
Creating applications that are easily navigable, have readable content, and support different ways
of accessing information.
It is important that everyone can use the software we make. Therefore, universal design of ICT
systems is a legal requirement for both public and private sectors. ICT is short for Information and
Communication Technology.
Why is universal design important? Here are some key elements:
• It generally makes the application or system more user-friendly and intuitive.
• Easier to navigate.
Part 2: Software Engineering
105 10 User eXperience (UX)
• More understandable content.
• Adapted to different devices and screen sizes.
• You reach a larger audience.
• Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
10.3.1 Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Understandable, and Robust. These POUR principles are as follows:
• Perceivable: Information must be presentable to users in ways they can perceive.
• Operable: Components and navigation must be operable.
• Understandable: Information and operation must be understandable.
• Robust: Content must be robust enough to work with current and future technologies.
Here you find information and resources for WCAG: [Link]
guidelines/wcag/
Here are some key elements of the WCAG standard:
• Structure – Easy to navigate.
• Navigation – easy to navigate the content.
• Contrast – I.e. use of colors, fonts, etc.
• User Interface – Good user interface, use of color, fonts.
• Keyboard – Able to navigate using keyboard.
The Web Accessibility Directive (WAD) is a European Union (EU) law that shall ensure that all
public websites and mobile applications are accessible to everyone, particularly people with
disabilities.
More information: [Link]
In Norway we have Uutilsynet. Uutilsynet (“Tilsynet for universell utforming av ikt” or in English:
“The Authority for Universal Design of ICT”) give guidelines and check that web solutions and apps
are available to everyone, in line with the regulations given.
Here is their website: [Link]
Here you will find the Norwegian Authority's guide for websites and apps:
[Link] - You can use this as a guide to
Part 2: Software Engineering
106 10 User eXperience (UX)
ensure that your systems meet the requirements of the WCAG standard and the authorities in the
EU and Norway.
10.3.2 Universal design in the development process
When you start developing a website or web application, a focus on universal design and
accessibility should be an important part of this process.
To create user-friendly websites or web applications, you need to create solutions that focus on
the user's needs. Which target groups are you targeting? After all, they are the ones who will use
what you create/develop. That is, it is important to take this into account already in the initial
phase of the project, when specifying what and how the system should be created.
An important part of the development work is to test how the solution works. When you test for
yourself, you can find a lot of problems that users may encounter. At the same time, by testing
yourself, the road to doing something about what you discover is short.
Elements that you should think about in connection with. The development and testing of the
website or web application include the following:
• Keyboard navigation – Does the solution support the use of a keyboard and not just mouse
use?
• Magnification and responsive design – Do the solution work well even when you enlarge
or shrink the page in the browser or drag the corners of the browser? Does the solution
work on both PC and mobile phone?
• Colors and contrast – Ensure good contrast between text and background. Some are also
color blind, so color alone should not convey information
• Headings – Good and clear headings make it easier for all users to orient themselves in the
text. Use the HTML headings <h1>, <h2> and <h3>.
• Links – It must be clear what are clickable links in the text.
• Images – Do all images have an alternative text?
• Forms – Forms are widely used on websites to enable the user to fill in different types of
information. Make sure to use good prompts, etc.
• Search function – Have you implemented a good search functionality so that it is easy to
find the desired information?
• Page titles – Have you implemented good page titles (HTML <title>) on all your web pages?
Page title is presented at the top of the window or in the tab of the browser and helps the
user find the right browser tab. Page title is also the name suggestion when saving a
bookmark or favorite in the browser.
• Code validation - Correct code is important to ensure that the website works correctly with
various browsers and aids. Your web page should meet the applicable HTML requirements,
syntax, and standards. I.e. check your website using e.g. WC3 Validator:
[Link]
Part 2: Software Engineering
107 10 User eXperience (UX)
For more information see the following resources given by the Norwegian Authority for Universal
Design of ICT (Uutilsynet):
• Universal design in the development process:
[Link]
• Check your website yourself: [Link]
selv/708
Important! Make sure to follow the guidelines given during the requirements analysis phase, the
design phase, the development phase and the testing phase.
Part 2: Software Engineering
11 UML
11.1 Introduction
UML is a modeling language used in software engineering. It is very popular among OOA, OOD,
OOP. UML was developed in the 1990s and adapted as an ISO standard in 2000. UML 2.2 has 14
different types of diagrams. See Figure 11-1.
Figure 11-1: UML Diagrams
We have 2 main categories of diagrams:
• Structure Diagrams
• Behavior Diagrams
o Interaction Diagrams (subcategory of Behavior Diagrams)
The diagrams available in UML are:
• Class Diagram
• Component Diagram
• Deployment Diagram
• Object Diagram
• Package Diagram
• Activity Diagram
108
109 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
110 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
111 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
112 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
113 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
114 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
115 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
116 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
117 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
118 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
119 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
120 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
121 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
122 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
123 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
124 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
125 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
126 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
127 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
128 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
129 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
130 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
131 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
132 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
133 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
134 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
135 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
136 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
137 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
138 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
139 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
140 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
141 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
142 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
143 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
144 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
145 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
146 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
147 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
148 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
149 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
150 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
151 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
152 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
153 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
154 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
155 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
156 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
157 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
158 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
159 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
160 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
161 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
162 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
163 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
164 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
165 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
166 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
167 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
168 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
169 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
170 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
171 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
172 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
173 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
174 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
175 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
176 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
177 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
178 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
179 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
180 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
181 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
182 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
183 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
184 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
185 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
186 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
187 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
188 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
189 0 Why is universal design important? Here are
some key elements:
It generally makes the application or system more user-friendly and intuitive.
Easier to navigate.
More understandable content.
Adapted to different devices and screen sizes.
You reach a larger audience.
Universal design is required by law.
Note! Universal design is required by law! So it is very important that all public services follow the
guidelines and regulations given by the authorities. See more information below.
Web Content Accessibility Guidelines (WCAG)
Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C
to make digital content accessible to people with disabilities, covering websites, applications, and
other digital materials. They are built on four principles (POUR): Perceivable, Operable,
Part 2: Software Engineering
12 Software Implementation
The goal of most software engineering projects is to produce a working program.
The act of transforming the detailed design into a valid program in some programming language,
together with all its supporting activities, is referred to as implementation.
Most of the text in this chapter is from (F. Tsui, O. Karam, and B. Bernal, Essentials of Software
Engineering).
The implementation phase involves more than just writing code. Code also needs to be tested and
debugged as well as compiled and built into a complete executable product (Figure 12-1).
We usually need to use a Source Code Control (SCC) tool to keep track of different versions of the
code.
Figure 12-1: Software Implementation (F. Tsui, O. Karam, and B. Bernal, Essentials of Software
Engineering)
In many cases the detailed design is not done explicitly (in the Design Phase) but is left as part of
the implementation. Doing the detailed design as part of the implementation is usually faster, but
it may result in a less cohesive and less organized design, because the detailed design of each
module will usually be done by a different person.
In small projects, the detailed design is usually left as part of the implementation. In larger
projects, or when the programmers are inexperienced, the detailed design will be done by a
separate person.
Here are some keywords for good implementation:
• Readability: The code can be easily read and understood by other programmers.
190
191 12 Software Implementation
• Maintainability: The code can be easily modified and maintained. Note that this is related
to readability, but it is not the same; for example, this involves the use of e.g., Hungarian
notation, in which variable names include abbreviations for the type of variable.
• Performance: All other things being equal, the implementation should produce code that
performs as fast as possible.
• Traceability: All code elements should correspond to a design element. Code can be traced
back to design (and design to requirements).
• Correctness: The implementation should do what it is intended to do (as defined in the
requirements and detailed design).
• Completeness: All the system requirements are met.
In this chapter, we will go through the following topics regarding implementation:
In this chapter, we will discuss the following:
• Programming Style and Coding Guidelines
• Comments
• Debugging
• Code Review
• Refactorization
12.1 Programming Style & Coding Guidelines
Almost all software development organizations have some sort of coding guidelines. These
guidelines usually specify issues such as naming, indentation, and commenting styles, etc.
It is strongly recommended that you be consistent in your notation to avoid confusion when
others are debugging or maintaining your code later. Especially in large software projects there
are usually some programming conventions. These conventions may seem to be of little value at
first, but they may become extremely helpful during the maintenance of the code.
Here are some recommendations:
• Naming: This refers to choosing names for classes, methods, variables, and other
programming entities.
• Separating words and capitalization: Many times, a name will be composed of more than
one word. In human languages, we use spaces to separate words, but most programming
languages will not allow us to do so. (“do_something”, “doSomething”, “DoSomething”)
Part 2: Software Engineering
192 12 Software Implementation
• Indentation and spacing: Indentation refers to adding horizontal spaces before some lines
to better reflect the structure of the code. Spacing refers to both spaces and blank lines
inserted in the code.
• Function/method size: Many studies have shown that large functions or methods are
statistically more error-prone than smaller ones.
• File-naming issues: Having a standard for specifying how to name the files, which files to
generate for each module, and how to locate a given file from a module is very
advantageous.
• Specific programming constructs: Different programming languages support different
features; although they usually have good reasons to include certain features, there are
many that can be misused and need special precautions.
12.1.1 Naming Convention
We have different naming convention/notation such as:
• Camel notation
• Pascal notation
• Hungarian notation
Camel Notation
For variables and parameters/arguments
Examples: “myCar”, “backColor”
Pascal Notation
For classes, methods, and properties
Examples: “ShowCarColor”
Hungarian Notation
For controls on your user interface, we either use “Pascal notation” or “Hungarian notation”, but
stick to one of them!
Examples: “txtName”, “lblName”
Acronyms
Examples: “DBRate”, “ioChannel”, “XmlWriter”, “htmlReader”
12.2 Comments
Part 2: Software Engineering
193 12 Software Implementation
Comments are very important and can significantly aid or hurt readability and maintainability.
There are two main problems with comments:
• they may distract from the actual code and make the program more difficult to read and
• they may be wrong.
[[Link]
We may classify comments into 6 different types:
1. Repeat of the code
2. Explanation of the code
3. Marker in the code
4. Summary of the Code
5. Description of the code intent
Part 2: Software Engineering
194 12 Software Implementation
6. External references
These are explained below:
• Repeat of the code
o These kinds of comments tend to be made by novice programmers and should be
avoided.
Bad Example:
// increment i by one
i++;
• Explanation of the code
o Sometimes, when the code is complex, programmers are tempted to explain what
the code does in human language.
o In almost every case, if the code is so complex that it requires an explanation, then
it should be rewritten.
1. Marker in the code
– It is common practice to put markers in the code to indicate incomplete items,
opportunities for improvement, and other similar information.
– We recommend using a consistent notation for these markers and eliminating all of
them before the code is in production.
– Sometimes programmers put markers in the code to keep track of changes and who
made them. We believe that information is better tracked with version
management software and recommend doing so.
3. Summary of the code
– Comments that summarize what the code does, rather than just repeating it, are
very helpful in understanding the code, but they need to be kept up to date.
– It is important to ensure that these comments are summarizing the code, not just
repeating, or explaining it.
– In many cases, the code that is being summarized can be abstracted into its own
function, which, if named correctly, will eliminate the need for the comment.
4. Description of the code intent
– These are the most useful kinds of comments; they describe what the code is
supposed to do rather than what it does.
Part 2: Software Engineering
195 12 Software Implementation
– These are the only kinds of comments that override the code. If the code does not
fulfill its intent, then the code is wrong.
5. External references
– These are comments that link the code to external entities, usually books or other
programs.
– Many times, these can be viewed as a kind of intent statement, as in, “This function
implements the XYZ algorithm, as explained in . . .,” but we believe such comments
require special attention.
– There may also be external prerequisites for the code, such as the existence of
initializing data in the database tables.
The trade-off that comments imply should be recognized. Comments can help clarify code and
relate it to other sources, but they also represent some level of duplication of the code.
6. Effort is invested in their creation and, above all, in their maintenance.
7. A comment that does not correspond to the actual code that it accompanies can cause
errors that are very hard to find and correct.
8. Another danger comments present is that they can be used to justify bad coding practices.
Many times, programmers will be tempted to produce code that is too complicated or too
hard to maintain, and add comments to it, rather than rewrite it to good standards.
9. In fact, many experts recommend avoiding comments completely and produce what is
called “self-documented code” - that is, code that is so well written that it does not need
any documentation.
10. Comments have their place, especially in the form of describing the programmer’s intent.
12.3 Debugging
Debugging is about different techniques for finding and fixing bugs (errors that make your code
not work as expected) in your code.
1. It is difficult to write code without errors (bugs), but e.g., Visual Studio and other tools
have powerful Debugging functionality (breakpoints, etc.)
2. The Compiler will also find syntax errors, etc.
3. For more “advanced” bugs other methods are required (Unit Testing, Integration Testing,
Regression Testing, Acceptance Testing, etc.).
Part 2: Software Engineering
196 12 Software Implementation
4. The focus here will be on these methods, while Debugging is something you learned in
Programming courses.
In debugging we have 4 phases:
• Stabilization/Reproduction - The purpose of this phase is to be able to reproduce the error
on a configuration, and to find out the conditions that led to the error by constructing a
minimal test case
• Localization - The process of localization involves finding the sections of the code that led
to the error. This is usually the hardest part, although, if the stabilization phase produces a
very simple test case, it may make the problem obvious.
• Correction - The process of correction involves changing the code to fix the errors.
Hopefully, if you understand what caused the error, you have a good chance of fixing the
problem.
• Verification - The process of verification involves making sure the error is fixed, and no
other errors were introduced with the changes in the code. Many times, a change in the
code will not fix the error or may introduce new errors.
12.4 Code Reviews
We are all human beings. You may make some mistakes irrespective of your experience in a
technology or module. If you just review your code with a second eye, those mistakes might have
caught at that time only. This way you can reduce the no. of bugs reported by the testers or end
users (Figure 12-2).
If you are working in a geographically distributed team, your coding conventions may differ and if
you have some strict coding guidelines, this code review process will make it possible to recheck
the standards in the code that you have written.
1. There are some possibilities of repetitive code block which can be caught during a code
review process. Refactoring can be done based on that.
2. Unused code blocks, performance metrics etc. are some additional check points of doing a
review.
3. If you are new to development, this code review process will help you to find out your
mistakes and help you to improve them. This is a perfect knowledge sharing mechanism.
4. Find out the defects and correct them at the beginning before it is committed to the source
control system.
Part 2: Software Engineering
197 12 Software Implementation
Figure 12-2: Why you should do reviews
[[Link]
Better code always starts with review process!
Here are some topics that should be checked during the Code Review process:
Part 2: Software Engineering
198 12 Software Implementation
• Readability: The code can be easily read and understood by other programmers.
• Maintainability: The code can be easily modified and maintained. Note that this is related
to readability, but it is not the same; for example, this involves the use of e.g., Hungarian
notation, in which variable names include abbreviations for the type of variable.
• Performance: All other things being equal, the implementation should produce code that
performs as fast as possible.
• Traceability: All code elements should correspond to a design element. Code can be traced
back to design (and design to requirements).
• Correctness: The implementation should do what it is intended to do (as defined in the
requirements and detailed design).
• Completeness: All the system requirements are met.
12.5 Refactoring
Even when using best practices and making a conscious effort to produce high-quality software, it
is highly unlikely that you will consistently produce programs that cannot be improved.
Refactoring is defined as
• the activity of improving your code style without altering its behavior
• a change made to the internal structure of software to make it easier to understand and
cheaper to modify without changing its observable behavior
Do you need to refactor your code? – here are some symptoms:
• Coding Style and Name Conventions not followed
• Proper Commenting not followed
• Duplicated code (clearly a waste)
• Long methods (excessively large or long methods perhaps should be subdivided into more
cohesive ones)
• Large class (same problem as long method)
• Switch statements (in object-oriented code, switch statements can in most cases be
replaced with polymorphism, making the code clearer)
• Feature envy, in which a method tends to use more of an object from a class different to
the one it belongs
• Inappropriate intimacy, in which a class refers too much to private parts of other classes
Any of these symptoms (and more) will indicate that your code can be improved. You can use
refactoring to help you deal with these problems.
You should Refactoring your continuously and especially after Code Reviews.
Part 2: Software Engineering
13 Testing
13.1 Introduction
Different people have come up with various definitions for Software Testing, but generally, the
goal of testing is:
• To ensure that the software meets the agreed requirements and design.
• The application works as expected.
• The application doesn’t contain serious bugs.
• Meets its intended use as per user expectations.
• The system must follow guidelines and regulations given by the authorities such as
universal design and GDPR.
Testing can be performed on different levels and by different people. Testing is a very important
part of software development. About 50% of the software development is about testing your
software.
Since modern software has become very complex, testing has become a very important part of
software development (see Figure 13-1).
Figure 13-1: Modern Software Testing has become very complex
199
200 13 Testing
Since testing of advanced software systems is quite complex, we need a systematic approach to
testing that involves different levels of testing (see Figure 13-2).
Figure 13-2: Systematic Testing
Since Software Development today involves different platforms, different devices, networks,
servers, and clients, etc., it has become very complex to test it. Today we have not only ordinary
Desktop Apps, but we also have Web Apps, Mobile Apps, Apps for TVs, etc.
The software we create is a layer between the user of the software and the hardware and the
operating system (Figure 13-3).
Part 2: Software Engineering
201 13 Testing
Figure 13-3: Components involved in Software Development & Testing
If we find bugs at the earlier stage, the cost to fix this will be less and thus it will reduce the overall
cost of the application (Figure 13-4).
Figure 13-4: Find Bugs at an early stage
Figure 13-5 illustrates the necessary steps involved in testing.
Part 2: Software Engineering
202 13 Testing
Figure 13-5: Software Testing
Testing is intended to show that a program does what it is intended to do and to discover program
defects before it is put into use. When you test software, you execute a program using artificial
data. You check for the presence of errors NOT their absence.
Testing is part of a more general verification and validation process, which also includes static
validation techniques.
What is the purpose of Testing?
The main purpose of testing is as follows:
• To demonstrate to the developer and the customer that the software meets its
requirements.
o For custom software, this means that there should be at least one test for every
requirement in the requirements document.
o For generic software products, it means that there should be tests for all the system
features, plus combinations of these features, that will be incorporated in the
product release.
• To discover situations in which the behavior of the software is incorrect, undesirable or
does not conform to its specification.
o This means undesirable system behavior such as system crashes, unwanted
interactions with other systems, incorrect computations, and data corruption.
The primary purpose of testing is to detect software failures so that defects may be discovered
and corrected.
If we summarize why we do Testing:
• Finding Bugs in the Software before it is released to the Customer
• Finding unwanted system behaviors
• Verify/Validate that the Software works as expected (according to the Specifications)
• Find bugs as soon as possible!
Part 2: Software Engineering
203 13 Testing
It is commonly believed that the earlier a defect is found the cheaper it is to fix it.
There are different steps involved in the software testing process.
The steps are as follows:
• Design Test Cases
• Prepare Test Data
• Run the Software with the necessary Test Data
• Compare the results with the Test Cases
The final output of this process is a Test Report.
Basically, we do the following: Planning the Test, then we execute the Tests, finally we document
the Test results.
Documents used in testing and documents created in the test process:
• SRS – Software Requirements Specifications: A document stating what at application must
accomplish. The documents are the basis for the test plan, etc.
• SDD – Software Design Document: A document describing the design of a software
application. The documents are the basis for the test plan, etc.
• STP - Software Test Plan: Documentation stating what parts of an application will be
tested, and the schedule of when the testing is to be performed
• STD - Software Test Documentation: Introduction, Test Plan, Test Design, Test Cases, Test
procedures, Test Log, …, Summary
We have the following stages in testing:
1. Development testing, where the system is tested during development to discover bugs
and defects. Development testing includes all testing activities that are carried out by the
team developing the system.
2. Release testing, where a separate testing team test a complete version of the system
before it is released to users.
3. User testing, where users or potential users of a system test the system in their own
environment.
Development testing: Development testing is the responsibility of the software development
team. A separate team should be responsible for testing a system before it is released to
customers.
Release testing: Release testing is the process of testing a release of a system that is intended for
use outside of the development team.
Part 2: Software Engineering
204 13 Testing
The primary goal of the release testing process is to convince the supplier of the system that it is
good enough for use. Release testing is usually a black box testing process where tests are only
derived from the system specification.
User testing: We have different types of user testing:
• Alpha testing - Users of the software work with the development team to test the software
at the developer’s site.
• Beta testing - A release of the software is made available to users to allow them to
experiment and to raise problems that they discover with the system developers.
• Acceptance testing - Customers test a system to decide whether it is ready to be accepted
by the system developers and deployed in the customer environment. Primarily for custom
systems.
13.1.1 Test Levels
In Figure 13-6 we see different test levels.
Figure 13-6: Levels of Testing
Short overview of the different Test levels in Figure 13-6 (more details later):
• Unit Tests are written by the Developers as part of the Programming. Each part is
developed, and Unit tested separately (Every Class and Method in the code)
• Regression testing is testing the system to check that changes have not “broken”
previously working code. Both Manually & Automatically (Re-run Unit Tests)
Part 2: Software Engineering
205 13 Testing
• Integration testing means the system is put together and tested to make sure everything
works together.
• System or validation testing is Black-box Tests that validate the entire system against its
requirements, i.e., checking that a software system meets the specifications
• Acceptance Testing: The Customer needs to test and approve the software before he can
take it into use. We have 2 types: FAT (Factory Acceptance Testing) and SAT (Site
Acceptance Testing).
13.1.2 Bug Tracking
A software bug is an error, flaw, failure, or fault in a computer program or system that produces
an incorrect or unexpected result, or causes it to behave in unintended ways
They found a bug (a moth) inside a computer in 1947 that made the program not behave as
expected. This was the “first” real bug.
13.1.3 Software versioning
Software versioning is used to separate different versions of the same software, both before it has
been released and for subsequent releases. See example in Figure 13-7.
Before the software is released:
• Alpha Release(s)
• Beta Release(s)
• RC - Release Candidate(s)
• RTM – Release To Manufacturing
Maintenance (after the software is released):
• Patches (small fixes)
• SP - Service Packs
(lots of small fixes and patches bundled together)
• …
• Start Planning next release
Part 2: Software Engineering
206 13 Testing
Figure 13-7: Software versioning
Software testing should be performed during the whole Software Development Life Cycle (SDLC)
as shown in Figure 13-8.
Part 2: Software Engineering
207 13 Testing
Figure 13-8: Testing during the Software Development Life Cycle (SDLC)
Sooner or later, you have to say enough is enough and release version 1.0 (see Figure 13-9).
Figure 13-9: When is the Software Finished?
One must define within the development company, development team or in dialogue with the
customer what is defined as "good enough".
Part 2: Software Engineering
208 13 Testing
Software will never be 100% complete or error-free (see Figure 13-10)!
Figure 13-10: When are you Finished with Testing?
13.2 Test Categories
We can divide testing into 2 different categories, which is:
• Black-box Testing
• White-box Testing
13.2.1 Black-box Testing
Black-box testing is a method of software testing that examines the functionality of an application
(what the software does) without going inside the internal structure (White-box Testing).
You need no knowledge of how the system is created. Black-box testing can be done by a person
who only knows what the software is supposed to do. You may compare to driving a car – you
don’t need to know how it is built to test it.
13.2.2 White-box Testing
Part 2: Software Engineering
209 13 Testing
In White-box Testing you need to have knowledge of how (Design and Implementation) the
system is built. White-box Testing is also called “Glass-box testing”.
In Figure 13-11 we see how White-box testing works.
Figure 13-11: White-box Testing
13.3 Test Levels
As mentioned earlier, we have different Levels of Testing (see Figure 13-12).
• Unit Testing
• Regression Testing
• Integration Testing
• System Testing
• Acceptance Testing
These are explained in more detail below.
Part 2: Software Engineering
210 13 Testing
Figure 13-12: Software Test Levels
Short explanations of these Test Levels:
• Unit Tests are written by the Developers as part of the Programming. Each part is
developed, and Unit tested separately (Every Class and Method in the code)
• Regression testing is testing the system to check that changes have not “broken”
previously working code. Both Manually & Automatically (Re-run Unit Tests)
• Integration testing means the system is put together and tested to make sure everything
works together.
• System testing is typically Black-box Tests that validate the entire system against its
requirements, i.e., Checking that a software system meets the specifications
• Acceptance Testing: The Customer needs to test and approve the software before he can
take it into use. FAT/SAT.
Part 2: Software Engineering
211 13 Testing
13.3.1 Unit Testing
Unit Testing (or component testing) refers to tests that verify the functionality of a specific section
of code, usually at the function level. In an object-oriented environment, this is usually at the class
and methods level.
Unit Testing in Visual Studio: [Link]
Unit Tests are written by the developers as part of the programming. They are automatically
executed by the system, e.g., Visual Studio and Azure DevOps have built-in functionality for Unit
Testing.
Sometimes the Unit Tests are written before you start programming, so-called Test-Driven
Development (TDD).
[[Link]
Since Unit testing is part of the development process, so-called Unit Tests Framework are usually
integrated with the IDE.
Part 2: Software Engineering
212 13 Testing
Unit Tests Frameworks:
• Visual Studio Unit Test Framework. Unit Tests are built into Visual Studio (no additional
installation needed)
• JUnit (Java)
• JUnit is a unit testing framework for the Java programming language.
• NUnit (.NET)
• NUnit is an open-source unit testing framework for Microsoft .NET. It serves the
same purpose as JUnit does in the Java world
• PHPUnit (PHP)
• LabVIEW Unit Test Framework Toolkit
• etc.
Unit Testing in Visual Studio:
Visual Studio has built-in features for Unit Testing. In the Solution Explorer you just add a “Test
Project” as part of your code (see Figure 13-13).
Figure 13-13: Unit Test Project in Visual Studio
In Figure 13-14 we see an example of how you create Unit Tests in Visual Studio and C#.
Part 2: Software Engineering
213 13 Testing
For Test classes, you need to use [TestClass] and for Test Methods you need to use [TestMethod].
You also need to add a reference to the code under test (select “Add Reference” in the Solution
Explorer and include “using <namespace>”) in your code.
Figure 13-14: Unit Test Principle in Visual Studio and C#
The basic concept in Unit Testing is to compare the results when running the Methods with some
Input Data (“Actual”) with some Known Results (“Expected”).
Example:
[Link](expected, actual, 0.001,”Test failed because...");
Unit Tests – Best Practice:
Here you see some basic best practice rules regarding unit tests:
• A Unit Test must only do one thing
• Unit Test must run independently
• Unit Tests must not be depending on the environment
• Test Functionality rather than implementation
• Test public behavior: private behavior relates to implementation details
• Avoid testing UI components
• Unit Tests must be easy to read and understand
• Create rules that make sure you need to run Unit Tests (and they need to pass) before you
can Check-in your code in the Source Code Control System
Part 2: Software Engineering
214 13 Testing
13.3.2 Regression Testing
Regression testing focuses on finding defects after a major code change has occurred. Specifically,
it seeks to uncover software regressions, or old bugs that have come back.
1. Regression testing is testing the system to check that changes have not “broken”
previously working code.
2. In a manual testing process, regression testing is expensive but, with automated testing, it
is simple and straightforward. All tests are rerun every time a change is made to the
program.
3. Tests must run “successfully” before the change is committed.
13.3.3 Integration Testing
Integration testing verifies the interfaces between components against a software design.
13.3.4 System Testing/Validation Testing
System Testing follows Integration Testing. It consists of Black-box Tests that validate the entire
system against its requirements. System Testing is about checking that a software system meets
specifications and that it fulfills its intended purpose. System Testing is often executed by an
independent group (QA group). QA is short for Quality Assurance.
Since system tests make sure the requirements are fulfilled, they must systematically validate each
requirement in the SRS (Software Requirements Specification).
13.3.5 Acceptance Testing
Customers test a system to decide whether it is ready to be accepted from the system developers
and deployed in the customer environment. It is primarily for custom systems.
In Figure 13-15 we see a typical acceptance test process.
Figure 13-15: Acceptance Testing (Sommerville)
The steps are:
Part 2: Software Engineering
215 13 Testing
• Define acceptance criteria
• Plan acceptance testing
• Derive acceptance tests
• Run acceptance tests
• Negotiate test results
• Reject/accept system
We have 2 main types of Acceptance Testing:
• FAT – Factory Acceptance Testing
• SAT – Site Acceptance Testing
FAT – Factory Acceptance Testing is usually performed in the Test Environment at the software
company.
SAT – Site Acceptance Testing is performed at the Customer in the actual Production Environment.
This is the final step to determine if the requirements of a specification or contract are met.
If the test is accepted, the software is officially handed over to the customer.
Note! Other terms and definitions are used as well in different literature.
13.4 Universal design and GDPR
The system must follow guidelines and regulations given by the authorities such as universal
design and GDPR. More about these things below.
13.4.1 Universal design
Universal design (in Norwegian: “Universell utforming” - UU) is about designing and facilitating
products, environments, programs and services so that they can be used by all people, regardless
of age, disability or other factors.
The goal is to create inclusive solutions that provide equal opportunities for participation and
accessibility for all. That is, to create content and functionality that is accessible to everyone.
Here you will find the Norwegian Authority's guide for websites and apps:
• [Link]
You can use this guide to ensure that your systems meet the requirements of the WCAG standard
and the authorities in the EU and Norway. More about universal design and WCAG in chapter
“10.3 - Universal Design”.
Part 2: Software Engineering
216 13 Testing
In general, make sure universal design is part of your test planning and testing procedures.
13.4.2 General Data Protection Regulation (GDPR)
GDPR is short for General Data Protection Regulation. Handling data security and GDPR
regulations (data protection and privacy) need to be a part of the requirements, design and the
testing of the system. GDPR) is a European Union (EU) law that sets strict rules on how
organizations handle personal data.
How to make sure you are GDPR compliant? Here are some important aspects:
• Collect and use personal data fairly and lawfully.
• Don’t collect more data than absolutely needed.
• Allow users to access, correct, and delete their data.
• Let users manage their data.
• Keep personal data safe and secure.
• Have a privacy policy that is easy to find and read.
In general, make sure GDPR is part of your test planning and testing procedures.
13.5 Test Documentation
In Figure 13-16 we see the steps involved in the software testing process.
Figure 13-16: The Software Testing Process
Part 2: Software Engineering
217 13 Testing
Documents involved:
• SRS – Software Requirements Specifications: A document stating what at application must
accomplish
• SDD – Software Design Document: A document describing the design of a software
application
• STP - Software Test Plan: Documentation stating what parts of an application will be
tested, and the schedule of when the testing is to be performed
• STD - Software Test Documentation: Introduction, Test Plan, Test Design, Test Cases, Test
procedures, Test Log, …, Summary
In addition to writing different documents in your test phase, you should have a Bug Tracking
System. With a Bug Tracking System, you can easily store all your bugs in a database system, set
priorities, use search to find bugs, use different statistics, etc. More about Bug Tracking Systems
below.
13.5.1 Test Planning and Software Test Plan (STP)
Test planning involves scheduling and estimating the system testing process, establishing process
standards, and describing the tests that should be carried out. As well as helping managers
allocate resources and estimate testing schedules, test plans are intended for software engineers
involved in designing and carrying out system tests. They help technical staff get an overall picture
of the system tests and place their own work in this context.
As well as setting out the testing schedule and procedures, the test plan defines the hardware and
software resources that are required. Test plans are not static documents but evolve during the
development process. Test plans change because of delays at other stages in the development
process. Test planning is particularly important in large software system development. For small
and medium-sized systems, a less formal test plan may be used, but there is still a need for a
formal document to support the planning of the testing process.
A Software Test Plan (STP) document typically answers the following:
Testing should be based on Requirements & Design Documents
• What shall we test?
• How shall we test?
• Hardware/Software Requirements
• Where shall we test?
• Who shall test?
• How often shall we test (Test Schedule)?
Part 2: Software Engineering
218 13 Testing
• How shall tests be documented? It is not enough simply to run tests; the results of the
tests must be systematically recorded. It must be possible to audit the testing process to
check that it has been carried out correctly
• System tests: This section, which may be separate from the test plan, defines the test cases
that should be applied to the system. These tests are derived from the system
requirements specification.
13.6 Bug Tracking Systems
All the results from the testing need to be documented, stored, and tracked.
For this purpose, we use a so-called Bug Tracking System.
Bug Reporting and Tracking with Azure DevOps: [Link]
Here are some popular Bug Tracking Systems in use today:
• Azure DevOps
• Jira
• Bugzilla
• ClearQuest
More about Bug Tracking Systems in Chapter 23 - Bug Tracking Systems.
We will focus on Azure DevOps in this document. The bug tracking features in Azure DevOps will
be discussed in another chapter.
In Azure DevOps we can add requirements, user stories, tasks, new features, bugs, etc. as so-called
“Work Items” (Figure 13-17).
Part 2: Software Engineering
219 13 Testing
Figure 13-17: Azure DevOps – Work Items
13.7 Test Environment
A testing environment is a setup of software and hardware on which the testing team is going to
perform the testing of the newly built software product.
VirtualBox - Installation of Windows 11 in a Virtual Machine:
[Link]
Install WinForm Desktop App in Virtual Test Environment using VirtualBox:
[Link]
Part 2: Software Engineering
220 13 Testing
Install [Link] Core Web App in Virtual Test Environment using VirtualBox:
[Link]
Here are also some other resources using VMware Workstation:
[Link] Core - Deploy to Virtual Test Environment: [Link]
Why do we need a Test Environment? Here are some reasons:
• “It works on my PC” says the Developer
• We need a Clean Environment when testing
• On the Developers PCs, we have all kind of Software installed that the Customer don’t
have, e.g., Development Tools like Visual Studio, etc.
• We need to test on different Platforms and Operating Systems
• Customers may use different Web Browsers
• Deployment: Test of Installation packages
• Make the software available for Testers
• etc.
This setup consists of a physical setup which includes hardware, and logical setup that includes
Server Operating system, client operating system, database server, front end running
environment, browser (if web application), IIS (version on server side) or any other software
components required to run this software product.
This testing setup is to be built on both the ends – i.e., the server and client.
To set up such environments, virtualization is the answer.
More about virtualization below.
Part 2: Software Engineering
221 13 Testing
Figure 13-18: Development, Test and Production Environment
Part 2: Software Engineering
222 13 Testing
[[Link]
13.7.1 Virtualization
To create test environments easily, virtualization is the answer. There exists lots of different
virtualization solutions on the market today.
Here are some examples:
• VirtualBox
• VMware Workstation
• VMware vSphere
• Microsoft Hyper-V
• VMware Fusion (Mac)
Part 2: Software Engineering
223 13 Testing
• Parallels Desktop (Mac)
• etc.
VirtualBox - Installation of Windows 11 in a Virtual Machine:
[Link]
Install WinForm Desktop App in Virtual Test Environment using VirtualBox:
[Link]
Install [Link] Core Web App in Virtual Test Environment using VirtualBox:
[Link]
VirtualBox is a free virtualization tool. VMware Workstation is another virtualization tool.
With such tools you can create so-called Virtual Machines (VM) where you can install and run all
kinds of software.
In this way, you can easily test your software without destroying your own computer and you can
easily test it in different operating systems, etc.
13.8 Terms used in Testing
Here we will discuss some terms used in software testing not covered earlier.
13.8.1 Bugs
A software bug is an error, flaw, failure, defect, or fault in a computer program or system that
produces an incorrect or unexpected result or causes it to behave in unintended ways.
They found a bug (a moth) inside a computer in 1947 that made the program not behave as
expected. This was the “first” real bug.
13.8.2 Debugging
Debugging is about different techniques for finding and fixing bugs (errors that make your code
not work as expected) in your code. It is difficult to write code without errors (bugs), but e.g.,
Visual Studio and other tools have powerful Debugging functionality (breakpoints, etc.). The
Compiler will also find syntax errors, etc.
Part 2: Software Engineering
224 13 Testing
For more “advanced” bugs other methods are required (Unit Testing, Integration Testing,
Regression Testing, Acceptance Testing, etc.). The focus here will be on these methods, while
Debugging is something you learned in Programming courses.
13.8.3 Code Coverage
Code coverage is a measure used in software testing. It describes the degree to which the source
code of a program has been tested.
Example:
int foo (int x, int y)
{
int z = 0;
if ((x>0) && (y>0))
{
z = x;
}
return z;
}
When we test this function, it depends on the input arguments which parts of the code will be
executed. Unit Tests should be written to cover all parts of the code.
13.8.4 Eat your own Dog food
“Eating your own dog food”, also called “dogfooding”, is a slang term used to reference a scenario
in which a company (usually, a computer software company) uses its own product to demonstrate
the quality and capabilities of the product.
Example: Microsoft uses Windows PCs and Visual Studio to create their software.
Part 2: Software Engineering
225 13 Testing
[[Link]
13.8.5 Code/Feature Freeze
The Developer cannot add new features to the software, only fix bugs. When it is very close to
release, they cannot fix bugs either.
[[Link]
Part 2: Software Engineering
226 13 Testing
13.8.6 Test-Driven Development (TDD)
In TDD coding and testing are done in parallel. The tests are normally written before the code. TDD
was introduced as part of eXtreme Programming (XP).
13.8.7 Development-Driven Testing (DDT)
DDT is all about giving more responsibility to developers specifically, and the development process
in general. It works especially well when using test cases as requirements, and having the
developers write these test cases. But it’s not DDT unless those tests are written near the end of
the process, when the code is checked in, and the developers figure they’re done.
The advantages of Development-Driven Testing are many. Instead of tests driving the
development, it’s developers driving the tests, so you get just a few tests, and they almost always
all pass. The project team can deliver on time for a change, with zero bugs found in every
iteration. This makes management happy, and isn’t that really the ultimate barometer of
success? Also, velocity is increased dramatically when using this process.
Development-driven testing makes all sense in the world for those who practice Agile.
[[Link]
Part 2: Software Engineering
227 13 Testing
13.9 The 7 Principles of Testing
The 7 Principles of Testing are as follows:
1. Testing shows the presence of Bugs: Software Testing reduces the probability of
undiscovered defects remaining in the software but even if no defects are found, it is not a
proof of correctness.
2. Exhaustive Testing is impossible: Testing everything is impossible! Instead, we need
optimal amount of testing based on the risk assessment of the application.
3. Early Testing: Testing should start as early as possible in the Software Development Life
Cycle (SDLC)
4. Defect Clustering: A small number of modules contain most of the defects/bugs detected.
5. The Pesticide Paradox: If the same tests are repeated, eventually the same test cases will
no longer find new bugs
6. Testing is Context dependent: This means that the way you test a e-commerce site will be
different from the way you test a commercial off the shelf application
7. Absence of Error is a Fallacy: Finding and fixing defects does not help if the system build is
unusable and does not fulfill the users’ needs and requirements
For more information about these 7 principles of testing, see the following:
7 Principles of Software Testing with Examples: [Link]
[Link]
13.10 Testing Summary
Figure 13-19 gives an overview of different Test Categories, Test Levels and Test Methods.
Part 2: Software Engineering
228 13 Testing
Figure 13-19: Test Categories, Test Levels and Test methods
13.11 Exercises
Make sure to discuss and reflect over the following:
1. Why do we need to test the software?
2. List different Test methods
3. We have 2 main categories of testing. Explain.
4. Explain the difference between a “Bug” and a “Feature”
5. What is Code/Feature Freeze?
6. What is “Dogfooding”?
7. What is a Code Review?
8. What Explain TDD and DDT?
Part 2: Software Engineering
229 13 Testing
9. What is Unit Testing?
10. What is the difference between Functional and Non-Functional Testing?
Part 2: Software Engineering
14 Deployment and
Installation
14.1 Introduction
Getting software out of the hands of the developers into the hands of the users. More than 50% of
commissioned software is not used, mostly because it fails at the deployment stage. 80% of the
cost of (commissioned) software comes at and after deployment.
Deploy a Windows Forms App using Visual Studio: [Link]
Virtualization Deployment:
Install WinForm Desktop App in Virtual Test Environment using VirtualBox:
[Link]
Install [Link] Core Web App in Virtual Test Environment using VirtualBox:
[Link]
Microsoft Azure Deployment:
Microsoft Azure - SQL Databases and App Services: [Link]
Software deployment is all the activities that make a software system available for use.
Examples:
• Get the software out to the customers
• Creating Installation Packages
• Documentation
o Installation Guide, etc.
• Installation
230
231 14 Deployment and Installation
• etc.
Deployment strategies may vary depending of what kind of software we create, etc.
14.2 Releases
Now we are finished with all the development and testing and are ready to start the deployment
process.
Typically, we have the following “Internal” releases (see also Figure 14-1):
• Alpha Release(s)
• Beta Release(s)
• RC - Release Candidate(s)
You are finished:
• RTM – Release To Manufacturing
• Your software is good enough and it is ready for Deployment!
Part 2: Software Engineering
232 14 Deployment and Installation
Figure 14-1: Software Releases before Releasing the Software
Below we see an example of the Windows 8 life cycle releases:
• Start planning and development of Windows 8, 2008/2009 (the planning started before
Windows 7 was released)
– Internal Builds xxxx…xxxx
– Internal Alpha versions, Alpha 1, 2, 3
– Internal Builds xxxx…xxxx
– Internal Milestone1 Release (build 7850), 2010.09.22
– Internal Milestone2 (build 7955), Milestone3 (build 7989)
• Developer Preview (build 8102), 2011.09.13
– Internal Builds xxxx…xxxx
• Consumer Preview (build 8250), 2012.02.29
– Internal Builds xxxx…xxxx
Part 2: Software Engineering
233 14 Deployment and Installation
• Release Preview (build 8400), 2012.05.28
– Internal Builds xxxx…xxxx
• RTM Release (build 9200), 2012.08.01
14.3 Deployment
What is Deployment?
Software deployment is all the activities that make a software system available for use.
Examples:
• Get the software out to the customers
• Creating Installation Packages
• Documentation
o Installation Guide, etc.
• Installation
• etc.
Deployment strategies may vary depending of what kind of software we create, etc.
Key Issues around Deployment:
• Business Processes: Most large software systems require the customer to change the way
they work.
• Training: No point in deploying software if the customers can't use it.
• Support: The need goes on, and on, and on.
• Deployment: How do you physically get the software installed.
• Equipment: Is the customer's hardware up to the job?
• Expertise: Does the customer have the IT expertise to install the software?
• Upgrades: Can't avoid them!
• Integration: Shall the software interact/integrate with other systems of the customer.
• Performance: The Customer may not have the same hardware as in the Development/Test
Environment
Part 2: Software Engineering
234 14 Deployment and Installation
14.4 Test and Production Environment
Typically, “everything” works on the computer that the developer of the code is using, but the
customer’s computer may use another OS, another version of the hardware, another version of a
3. party component or other software that your software relies on, etc. Therefore, it is very
important to test the software on other computers and other environments, different versions of
hardware, different versions of web browsers, etc.
During the software lifecycle, we have 3 different environments for the software we are creating:
• Development Environment
• Test Environment
• Production Environment
Figure 14-2 gives an overview of these different software environments.
Figure 14-2: Development-, Test- and Production Environment
Part 2: Software Engineering
235 14 Deployment and Installation
[[Link]
Test/Production Environment is an Infrastructure with Servers, Virtual Servers, Database Servers,
Web Servers, etc.
• Local Infrastructure with Servers & Virtualization
• Cloud-based Infrastructure (monthly payment), e.g.:
• Windows Azure [Link]
• Amazon Web Services (AWS) [Link]
• Google Cloud Platform [Link]
• etc.
14.4.1 Development Environment
This is where the developers create the code, typically the developer’s personal computer.
14.4.2 Production Environment
Production environment is a term used mostly by developers to describe the setting where
software and other products are put into operation for their intended uses by end users.
Part 2: Software Engineering
236 14 Deployment and Installation
A production environment can be thought of as a real-time setting where programs are run, and
hardware setups are installed and relied on for organization or commercial daily operations.
14.4.3 Test Environment
A testing environment is a setup of software and hardware on which the testing team is going to
perform the testing of the newly built software product.
This setup consists of a physical setup which includes hardware, and logical setup that includes
Server Operating system, client operating system, database server, front end running
environment, browser (if web application), IIS (version on server side) or any other software
components required to run this software product.
This testing setup is to be built on both the ends – i.e., the server and client.
Part 2: Software Engineering
15 Project Documentation
During the software development, a lot of documentation (Figure 15-1) is created in the different
phases of the development.
Figure 15-1: Example of Documentation during the SDLC
Write Technical Reports in Microsoft Word: [Link]
Figures and Equations in Word and PowerPoint: [Link]
Citation and referencing with Microsoft Word: [Link]
Some documents are for internal use inside the software company or inside the development
team, while other documents are important for the stakeholders and customers that are going to
use the software (Figure 15-2).
237
238 15 Project Documentation
Figure 15-2: Software Documentation
Some important documents in software engineering are:
• SDP – Software Development Plan
• SRS – Software Requirements Specifications
o A document stating what the application must accomplish.
• SDD – Software Design Document
o A document describing the design of a software application.
• STP - Software Test Plan
o Documentation stating what parts of an application will be tested, and the schedule
of when the testing is to be performed.
• STD - Software Test Documentation
o Introduction, Test Plan, Test Design, Test Cases, Test procedures, Test Log, …,
Summary
Part 2: Software Engineering
239 15 Project Documentation
See Figure 15-3 for an overview of documentation categories used in a project.
Figure 15-3: Software Project Documentation
Documentation produced during a software Project can be divided into 2 main categories:
• Process Documentation
– These documents record the process of development and maintenance, e.g., Plans,
Schedules (e.g., Gantt Charts), etc.
• Product Documentation
– These documents describe the product that is being developed. Can be divided into
2 subcategories:
• System Documentation
• Used by engineers developing and maintaining the system.
• User Documentation
• Used by the people that is using the system.
Part 2: Software Engineering
240 15 Project Documentation
Here are some Software Documentation Requirements:
• Should act as a communication medium between members of the Development Team
(Process Documentation)
• Information repository used by Maintenance Engineers (Product Documentation)
• Information for Management to help them Plan, Budget, and Schedule the Software
Development Process (Process Documentation)
• Some of the documents should tell users how to use and administer the system (Product
Documentation)
• Documents for Quality Control, System Certification, etc. (Process/Product Documentation)
Satisfying these requirements requires different types of documents from informal working
documents through professionally produced User Manuals
15.1 Process Documentation
Purpose:
1. Process Documentation is produced so that the development of the system can be
managed.
2. It is an essential component of plan-driven approaches (e.g., Waterfall)
3. Agile Approaches: The Goal is to minimize the amount of Process Documentation
We have different categories of Process Documentation:
• Plans, estimates, and schedules. These are documents produced by managers which are
used to predict and to control the software process.
• Reports. These are documents which report how resources were used during the process
of development.
• Standards. These are documents which set out how the process is to be implemented.
These may be developed by organizational, national, or international standards.
• Working papers. These are often the principal technical communication documents in a
project. They record the ideas and thoughts of the engineers working on the project, are
interim versions of product documentation, describe implementation strategies and set
out problems which have been identified. They often, implicitly, record the rationale for
design decisions.
Part 2: Software Engineering
241 15 Project Documentation
• E-mail messages, wikis, etc. These record the details of everyday communication between
managers and development engineers.
15.2 Product Documentation
Purpose:
• Describing the software product that shall be delivered
• Unlike most process documentation, it has a relatively long life. It must
• Evolve in step with the product that it describes. Product documentation includes.
– User documentation, which tells users how to use the software product,
– System Documentation, which is principally intended for maintenance engineers.
15.2.1 System Documentation
The system documentation describes how the system is designed and how it works in detail.
1. System documentation includes all the documents describing the system itself from the
requirements specification to the final acceptance test plan.
2. Documents describing the design, implementation and testing of a system are essential if
the program is to be understood and maintained.
3. Like user documentation, it is important that system documentation is structured, with
overviews leading the reader into more formal and detailed descriptions of each aspect of
the system.
In Figure 15-4 we see an overview of different product documentation and readers of such
documents.
Part 2: Software Engineering
242 15 Project Documentation
Figure 15-4: Product Documentation Types & Readers (Sommerville)
For large systems that are developed to a customer’s specification, the system documentation
should include:
• The requirements document.
• A document describing the system architecture.
• For each program in the system, a description of the architecture of that program.
• For each component in the system, a description of its functionality and interfaces.
• Program source code listings, which should be commented on, where the comments
should explain complex sections of code and provide a rationale for the coding method
used.
• If meaningful names are used and a good, structured programming style is used,
much of the code should be self-documenting without the need for additional
comments.
• This information is now normally maintained electronically rather than on paper
with selected information printed on demand from readers.
• Validation documents describing how each program is validated and how the validation
information relates to the requirements.
• These may be required for the quality assurance processes in the organization.
Part 2: Software Engineering
243 15 Project Documentation
• A System Maintenance Guide, which describes known problems with the system,
describes which parts of the system are hardware and software dependent and which
describes how evolution of the system has been considered in its design.
15.2.2 User Documentation
Users of a system are not all the same. The producer of documentation must structure it to cater
for different user tasks and different levels of expertise and experience.
It is particularly important to distinguish between end-users and system administrators:
• End-users use the software to assist with some tasks.
– This may be flying an aircraft, managing insurance policies, writing a book, etc. They
want to know how the software can help them. They are not interested in
computer or administration details.
• System administrators are responsible for managing the software used by end-users.
– This may involve acting as an operator if the system is a large mainframe system, as
a network manager is the system involves a network of workstations or as a
technical guru who fixes end-users software problems and who liaises between
users and the software supplier.
We have different user documentation, such as:
• User Manual
• Installation Guide
• Wiki
• etc.
Part 2: Software Engineering
244 15 Project Documentation
[[Link]
User Manual:
A user guide or user's guide, also commonly known as a manual, is a technical communication
document intended to give assistance to people using a system. It is usually written by a technical
writer, although user guides are written by programmers, product or project managers, or other
technical staff, particularly in smaller companies.
The sections of a user manual often include:
• A Cover page
• A Title page and copyright page
• A Preface, containing details of related documents and information on how to navigate the
user guide
• A Table of Contents page
• A guide on how to use at least the main functions of the system (Text + Screen Shots)
Part 2: Software Engineering
245 15 Project Documentation
• A troubleshooting section detailing possible errors or problems that may occur, along with
how to fix them
• A FAQ (Frequently Asked Questions)
• Where to find further help, and contact details
• A glossary and, for larger documents, an index
15.3 Setup & Distribution
As mentioned earlier we have two categories of software: generics products and customized
products.
If we have a generic product, it is especially important that the customers can install the software
you create.
For e.g., web products setup and distribution to the end user computers are not necessary, since
the software is installed on a Web Server and can be accessed through an ordinary web browser.
Installation is about:
• Package the software
• Executable files
• Create installation packages
• InstallShield, etc. (lots of tools available)
• Make it available (nowadays over Internet or on DVD)
• Give the customer turn-key installers, which will:
• Check the system for missing dependencies or drivers etc. (e.g., Your software may
need .NET X.x, etc.)
• Install the software on the system
• Set up any necessary license information, license managers, etc.
Part 2: Software Engineering
16 Software Maintenance
16.1 Introduction
Software Maintenance is about:
• Software has bugs (Bug /Support incidents need to be tracked and followed up -> A good
tool is needed).
• New features are required.
• Circumstances change. Therefore, the software has changed. Who changes it?
• Development teams have broken up, maintenance may be done by different company!
• Repeated change leads to architectural degradation. Old systems may have been degraded
from the start!
• Software rots. Even with no code changes, the systems change, and eventually you can't
compile the software.
Software Maintenance is defined as [12]: “The process of modifying a software system or
component after delivery to correct faults, improve performance or other attributes, or adapt to a
changed environment”.
40-90% of the software life cycle cost is about maintenance.
Examples:
• The Y2K problem
• New versions of the OS often require adjustment to your software
• New requirements and customer needs
We may divide into 2 different types of Maintenance:
• Repair
o Fixing defects/bugs
• Enhancement
o New Requirements
o Change in Design or Implementation (No functional change)
16.2 Categories
246
247 16 Software Maintenance
Again, we can divide maintenance into 4 categories:
• Corrective maintenance
• Adaptive maintenance
• Perfective maintenance
• Preventive maintenance
In Figure 16-1 we see an overview of the different software maintenance categories [12].
Figure 16-1: Software Maintenance Categories
In Table 9-1 we see the differences between these categories.
Table 16-1: Software Maintenance Overview
Maintenance Description
Corrective Repair of defects relative to existing requirements. These defects are typically
discovered by customers as they start using your software.
Adaptive Adapt your software to changes in the operating environment, e.g., when a
new OS is released or a new version of the hardware. As software systems
evolve, it is very likely that changes will happen in the external environment
(OS, hardware, etc.) your software depends on.
Perfective New features based on new user requests. The software must continuously
adapt to new needs, or your software will become useless.
Preventive Changes in your software to make it easier to maintain. Changes from
Corrective, Adaptive and Perfective make your software more complex, more
difficult to maintain, etc. Preventive maintenance in form of Refactoring
should be done on a regular basis
Part 2: Software Engineering
248 16 Software Maintenance
While Sommerville only divide into 3 different categories, see Figure 16-2.
Figure 16-2: Maintenance Categories (Sommerville)
Part 2: Software Engineering
Part 3 : Platforms &
Architecture
In this part, we give an overview of tools used (and needed) in modern software engineering, like
collaboration tools, source code control tools, programming platforms, frameworks, languages,
etc.
249
17 Software Platforms
17.1 Introduction
We have lots of different platforms today, here we will discuss the most common platforms used
today. They are:
• Desktop: We have different Desktop platforms such as Windows, Mac OS X, Linux, etc. To
create applications for Windows we can use, e.g., Visual Studio and C#. To create
applications for Mac OS X we can use, e.g., Xcode and Objective-C/Swift. LabVIEW exists for
both Windows, Mac OS X and Linux.
• Mobile: Today we have 3 major Mobile platforms: iOS (iPhone and iPad), Android (running
on different Smartphones and Tablets) and Windows 8 (Tablets)/Windows 8 Phone (Smart
Phones).
• Web: Web applications run inside a web browser, such as e.g., Internet Explorer, Chrome,
Safari, Opera or Firefox. In the simplest form we can use HTML. For more dynamic web
pages we can use [Link], PHP, JavaScript, AJAX, etc.
Here are some examples:
Desktop
• Windows
• Mac OS
• Linux
Web
• [Link]
• PHP
• IIS
• Apache
• HTML
• JavaScript
• AJAX
Mobile Devices
• iOS (iPhone, iPad, iPod)
• Android
• Windows Phone
250
251 17 Software Platforms
Server-side
• Databases
• Web Servers
Figure 17-1 shows some advantages and disadvantages with the different Platforms.
Figure 17-1: Advantages/Disadvantages with different Platforms
17.2 Platform Vendors
The 3 main vendors of such platforms are Microsoft, Apple, and Google. They all deliver platforms
for Desktop and Mobile systems, but they have different approaches.
17.3 Desktop
On the desktop, we have 3 main platforms, namely Windows, Linux and macOS. In addition, we
have Chrome OS from Google as a 4. alternative.
Part 3: Platforms & Architecture
252 17 Software Platforms
Figure 17-2: Desktop Platforms: Windows, Linux, macOS, Chrome OS
We have lots of development tools for these platforms, see Figure 17-3. These will be discussed in
more details later.
Figure 17-3: Development Tools available for different Desktop Platform
17.3.1 Windows
Microsoft Windows is a series of graphical interface operating systems developed, marketed, and
sold by Microsoft.
Part 3: Platforms & Architecture
253 17 Software Platforms
Figure 17-4: Windows Release History
There are a lot of Windows releases, some of the most important releases are:
• Windows 3
• Windows 95
• Windows NT
• Windows XP
• Windows 7
• Windows 8
• Windows 10
• Windows 11
In Figure 17-5 we see the first Windows version (Windows 1.0).
Part 3: Platforms & Architecture
254 17 Software Platforms
Figure 17-5: Windows 1.0
17.3.2 macOS
The operating system macOS (Figure 17-6) is developed by Apple Inc. macOS runs only on Mac
Computers from Apple. It is a UNIX-based OS based on NeXT OS (Apple bought NeXT, and Steve
Jobs returned to Apple as CEO) because Apples classic OS from 1984 (the first Macintosh) and later
(Mac OS 9) was lacking behind – they needed a fresh start.
In macOS software can be deployed to Mac App Store for easy installation.
A popular development platform on macOS is the Xcode IDE and the Swift programming language.
Part 3: Platforms & Architecture
255 17 Software Platforms
Figure 17-6: macOS
The previous releases of macOS were named after big cats like Puma, Jaguar, Tiger Leopard, Lion,
etc.
17.3.3 Linux
Linux is a UNIX-like operation system. It is a Free/Open-Source software platform. Linus Torvalds is
the founder of the Linux kernel. Linux was originally developed as a free operating system for
Intel x86-based personal computers. It has since been ported to more computer hardware
platforms than any other operating system.
From Figure 17-7 we see that both Linux and Mac OS X have their origins from the UNIX platform.
Part 3: Platforms & Architecture
256 17 Software Platforms
Figure 17-7: UNIX History
Different Vendors/different versions/distributions, e.g.:
• Fedora
• Red Hat Linux
• SUSE
• Mandriva
• Ubuntu
• etc.
The penguin symbol (Figure 17-8) is typical for Linux.
Part 3: Platforms & Architecture
257 17 Software Platforms
Figure 17-8: The Linux Mascot
17.4 Web
The Web has become increasingly important as a platform for developing software.
Here are some keywords:
• HTML, CSS and JavaScript
• Server-side frameworks like [Link], PHP and Django
• Client-side frameworks and libraries like React, Angular, Vue, etc.
• Web server software like Internet Information Services (IIS) and Apache
A Web Browser and HTML are the foundation for web pages. HyperText Markup Language (HTML)
is the main markup language for creating web pages and other information that can be displayed
in a web browser.
In Figure 17-9 we see the typical web architecture, including web browsers, HTML, CSS, JavaScript,
and a web server for hosting the web pages. Microsoft Edge is the new version of the previous
Internet Explorer.
Part 3: Platforms & Architecture
258 17 Software Platforms
Figure 17-9: Web Architecture
In Figure 17-10 we see the triangle of web programming. You cannot create a modern web page
without knowing the basics of HTML, CSS and JavaScript. They are the basic building blocks when
creating web pages.
Figure 17-10: The triangle of Web Programming
HyperText Markup Language (HTML) is the visual appearance of a Web Site. All Web Browser
understand HTML. The latest version is HTML 5. CSS (Cascading Style Sheets) define how to display
Part 3: Platforms & Architecture
259 17 Software Platforms
HTML elements. CSS is used to control the style and layout of multiple Web pages all at once.
JavaScript is the programming language of the Web. All modern HTML pages are using JavaScript.
Some relevant videos:
Web Programming: [Link]
TcK6Aqj3EF81bQiwHfQDzK_HPjTgg
17.4.1 Web Servers
Web Servers are used to host web sites and web pages. The web server can refer to either the
hardware (the computer) or the software (the computer application) that helps to deliver web
content that can be accessed through the Internet.
The following web servers (software) are very popular today:
• Internet Information Services (IIS) (included with Windows)
• Apache
• Nginx (pronounced "engine x")
See Figure 17-11.
Figure 17-11: Web Server
17.4.2 Web Frameworks
[Link] is a web application framework developed by Microsoft to allow programmers to build
dynamic web sites, web applications and web services.
[Link] is part of the Visual Studio package.
Part 3: Platforms & Architecture
260 17 Software Platforms
It was first released in January 2002 with version 1.0 of the .NET Framework and is the successor
to Microsoft's Active Server Pages (ASP) technology. [Link] is built on the Common Language
Runtime (CLR), allowing programmers to write [Link] code using any supported .NET language,
such as C# and [Link].
[Link] web pages or webpages, known officially as Web Forms], are the main building block for
application development. Web forms are contained in files with an “.aspx” extension.
See Figure 17-12.
Figure 17-12: [Link]
17.4.3 [Link] Core
The new .NET Core is a lightweight cross-platform subset of the full .NET Framework. See Figure
17-13.
Part 3: Platforms & Architecture
261 17 Software Platforms
Figure 17-13: [Link] Core
[Link] Core with Razor: [Link]
[Link] Core with Razor and SQL Server: [Link]
17.4.4 Django
Django is a Python web development framework. Django is a backend/server-side web framework
like [Link] Core. Django has support for databases like SQLite, MySQL/MariaDB and PostgreSQL.
Django includes an SQLite database, but for the others you need to install the database system
you want to use from their respective websites and in addition install a Python package/driver for
the specific database system. Django is free, open source and written in Python.
Django webpage: [Link]
17.4.5 Web Scripting Languages
A scripting language is a lightweight programming language. JavaScript and PHP is programming
code that can be inserted into HTML pages. JavaScript inserted into HTML pages, can be executed
by all modern web browsers.
JavaScript:
JavaScript is THE scripting language of the Web. JavaScript is used in billions of Web pages to add
functionality, validate forms, communicate with the server, and much more.
Part 3: Platforms & Architecture
262 17 Software Platforms
To insert a JavaScript into an HTML page, use the <script> tag. The <script> and </script> tells
where the JavaScript starts and ends. The lines between the <script> and </script> contain the
JavaScript. Below we see an example.
<!DOCTYPE html>
<html>
<head>
<script>
function myFunction()
{
[Link]("demo").innerHTML="My First JavaScript Function";
}
</script>
</head>
<body>
<h1>My Web Page</h1>
<p id="demo">A Paragraph</p>
<button type="button" onclick="myFunction()">Try it</button>
</body>
</html>
PHP:
PHP is a server scripting language and is a powerful tool for making dynamic and interactive Web
pages. PHP is free to use (open source) and it is widely used today.
The PHP code is merged between the HTML code, and the PHP code is executed on the web server
and translated to pure HTML syntax. Below we see an example.
<!DOCTYPE html>
<html>
<body>
<h1>My first PHP page</h1>
<?php
echo "Hello World!";
?>
</body>
</html>
Typically, you have a combination of PHP code, HTML and JavaScript on a web page.
PHP runs on different platforms (Windows, Linux, Unix, Mac OS X, etc.) and it is compatible with
almost all web servers used today (Apache, IIS, etc.). PHP has support for a wide range of
databases as well.
17.4.6 Front-end Web Development Libraries and
Frameworks
Part 3: Platforms & Architecture
263 17 Software Platforms
Here are some popular front-end libraries and frameworks:
• Angular
• React
• Bootstrap
• jQuery
• Vue
One of the most popular front-end libraries today is React. React is a front-end JavaScript library
for building user interfaces in web applications. Developed by Facebook in 2011. React is now free
and open source. Note! React is a front-end Library and not a Framework. So, you typically need a
Framework like [Link] or [Link] Core.
React webpage: [Link]
17.5 Mobile Devices
Today we have the following Mobile platforms:
• iPhone (iOS)/iPad OS
• Android
Below we will give a short overview of these platforms.
In general, we have 2 different kinds of apps for mobile devices (Figure 17-14), i.e., we can
distinguish between “native apps” and “web apps”. Web apps are created using HTML 5
technology and run inside a standard web browser, while native apps are created specifically for a
specific device or platform, such as an iOS device, Android device, etc. If you want to support more
than one platform, you need to develop and maintain one app for each of these platforms.
Different platforms need different programming methods and languages, but native apps provide
better performance and usability compared to web-based apps. Native apps can use APIs that is
provided by the vendor, they have access to built-in sensors, GPS, etc.
Part 3: Platforms & Architecture
264 17 Software Platforms
Figure 17-14: Native vs. Web Apps
Web apps are not real applications; they are websites that, in many ways, look and feel like native
applications, but are not implemented as such. They are run by a browser and typically written in
HTML5. Users first access them as they would access any web page: they navigate to a special URL
and then have the option of “installing” them on their home screen by creating a bookmark to that
page.
Web apps became popular when HTML5 came around and people realized that they can obtain
native-like–functionality in the browser. Today, as more and more sites use HTML5, the distinction
between web apps and regular web pages has become blurry.
Native Apps vs. Web Apps:
Some important aspects of native apps and web apps:
• Native apps live on the device and are accessed through icons on the device home screen.
• Native apps are installed through an application store (such as Google Play or Apple’s App
Store).
• They are developed specifically for one platform, and can take full advantage of all the
device features — they can use the camera, the GPS, the accelerometer, the compass,
contact list, etc.
• Native apps can use the device’s notification system and can work offline.
17.5.1 iOS
iOS (see Figure 17-15) is a mobile operating system developed and distributed by Apple Inc.
Created in 2007 together with the iPhone. It has been extended to support other Apple devices
such iPad (2010), etc.
Part 3: Platforms & Architecture
265 17 Software Platforms
Figure 17-15: iOS
iOS is derived from OS X, which is the operation system used on Apple Mac computers.
Apps can be downloaded from the App Store. To create Apps, you use the Xcode IDE and the
Objective-C or Swift programming language. You need the iOS SDK, which is included with Xcode.
Xcode is only available for Mac OS X, this means you need a Mac computer to create apps for the
iOS platform.
iOS App Development with Xcode and Swift: [Link]
17.5.2 Android
Android (see Figure 17-16) is a Linux-based operating system designed for mobile devices such as
smartphones and tablets. Android is developed by Google.
The first Android phone was sold in 2008.
Part 3: Platforms & Architecture
266 17 Software Platforms
Figure 17-16: Android
Android works on hardware from different vendors.
The source code for Android is available under a free and open-source software license, which
means everybody may change it and create their own version of it. Vendors like Samsung, etc. do
this.
You use the Eclipse IDE and Java programming language to create apps for Android. Apps can be
downloaded from Google Play, Amazon AppStore for Android, etc. Google Play is the official App
Store for Android.
Figure 17-17 gives an overview of the different Android versions:
Part 3: Platforms & Architecture
267 17 Software Platforms
Figure 17-17 Android Versions
Notice that all Android versions are named after a dessert, a cake, or other sorts of candy. They
are also in alphabetical order:
• C (Cupcake)
• D (Donut)
• E (Eclair)
• F (Froyo)
• G (Gingerbread)
• H (Honeycomb)
• I (Ice Cream Sandwich)
• J (Jelly Bean)
• K (KitKat) – Android 4.4x
• L (Lollipop) – Android 5.x
• M (Marshmallow) – Android 6
• N (Nougat) – Android 7
• O (Oro) – Android 8
• P (Pie) – Android 9
Now they have run out of cakes and cookies, and the latest versions are just called Android 10 11,
12, 13, 14, 15, etc.
Part 3: Platforms & Architecture
268 17 Software Platforms
More about Android for Developers here: [Link]
Here you can get detailed information about Android and download resources, development
tools, etc., including Android Studio, which is the tool you should use when developing Apps for
the Android platform.
Android Studio is the official IDE for developing Apps for Android, but you may use many other
IDEs as well. Especially, many use the Eclipse software. In that case, you need to download and
install the Android SDK Tools.
Android has become a widely used platform for many kinds of devices, including smartphones,
tablets, TV’s (Android TV), watches (Android Wear), and even cars (Android Auto).
Android Development with Android Studio: [Link]
17.5.3 Native and Cross-platform App Development
“App” is short for “Application”. When we talk about Apps, we normally mean Mobile Apps, i.e.,
Applications for smart phones like iPhone and Android phones. The term was introduced by Apple
in 2007 where they released iPhone and “App Store” in 2008. Apps are normally installed from an
“App Store” like Google Play of Apples App Store.
For native app development we use Xcode and Swift for iOS, for Android we use Android Studio
and Kotlin. See Figure 17-18.
Part 3: Platforms & Architecture
269 17 Software Platforms
Figure 17-18: Native App Development for iOS and Android
iOS App Development with Xcode and Swift: [Link]
Android Development with Android Studio: [Link]
For cross platform app development, we have many different options. See Figure 17-19.
Figure 17-19: Cross-platform App Development
Part 3: Platforms & Architecture
270 17 Software Platforms
17.6 Cloud Computing
Cloud computing (Figure 17-20) is the use of computing resources (hardware and software) that
are delivered as a service over a network (typically the Internet)
Examples:
1. iCloud
2. Microsoft Azure
3. Amazon Web Services (AWS)
4. Google Cloud Platform (GCP)
5. etc.
Figure 17-20: Cloud Computing (Wikipedia)
17.7 Open Source
Part 3: Platforms & Architecture
271 17 Software Platforms
For more information about Open Source, see the following: [Link]
source_software
Part 3: Platforms & Architecture
18 Software Frameworks &
Languages
There are probably thousands of different programming languages. Each of these programming
languages has good and bad qualities and is preferable in different situations. Some language is
good to use when you need to communicate with a database, while others are good to use when
you want to develop web applications, etc. So, in most situations you probably need to know and
use more than one programming language.
In this chapter, we will discuss some of the most used (probably) programming languages today.
18.1 Object-Oriented Programming (OOP)
Object-oriented programming (OOP) is a programming language model organized around
"objects" rather than "actions" and data rather than logic. Historically, a program has been viewed
as a logical procedure that takes input data, processes it, and produces output data.
The first step in OOP is to identify all the objects you want to manipulate and how they relate to
each other, an exercise often known as data modeling. Once you've identified an object, you
generalize it as a class of objects and define the kind of data it contains and any logic sequences
that can manipulate it. Each distinct logic sequence is known as a method. A real instance of a
class is called an “object” or an “instance of a class”. The object or class instance is what you run in
the computer. Its methods provide computer instructions, and the class object characteristics
provide relevant data. You communicate with objects - and they communicate with each other.
Important features with OOP are:
• Classes and Objects
• Inheritance
• Polymorphism
• Encapsulation
Simula was the first object-oriented programming language. Simula was developed in the 1960s
by Kristen Nygaard from Norway.
Java, Python, C++, Visual Basic .NET, and C# are popular OOP languages today.
272
273 18 Software Frameworks & Languages
Since Simula-type objects are reimplemented in C++, Java and C# the influence of Simula is often
understated. The creator of C++ (1979), Bjarne Stroustrup (from Denmark), has acknowledged that
Simula was the greatest influence on him to develop C++.
18.2 Popular Programming Languages
There are probably thousands of different programming languages today. In Figure 18-1 we see
some of them.
Figure 18-1: Programming Languages
Here is a list of some of the most popular programming languages in use today.
• C, C++
• C#
• Java/Kotlin
• Python
• JavaScript
• SQL
• Swift
• ..
Each of these programming languages has good and bad qualities and is preferable in different
situations. Some language is good to use when you need to communicate with a database, while
others are good to use when you want to develop web applications, etc. So, in most situations you
probably need to know and use more than one programming language.
Part 3: Platforms & Architecture
274 18 Software Frameworks & Languages
Some programming languages are interpreted (“interpreted language”), while others are compiled
(“compiled language”). Compiled languages need to be compiled and transform to “machine
code” before you can run the program. Interpreted languages translate the code step-by-step at
run-time.
Compiled languages are known in general to be faster than interpreted languages. Compiled
languages can also easily be compiled into executable programs that can run on their own, while
interpreted languages normally need to be run inside the development environment.
C, C++ and C# are typically compiled languages, while Python, PHP, MATLAB, etc. are so-called
interpreted languages.
Below we will give a very short introduction to some of the most popular programming languages.
18.2.1 C and C++
C is a general-purpose computer programming language developed between 1969 and 1973 by
Dennis Ritchie at the Bell Telephone Laboratories for use with the Unix operating system.
C is one of the most popular programming languages of all time and there are very few computer
architectures for which a C compiler does not exist.
C has greatly influenced many other popular programming languages, most notably C++, which
began as an extension to C. C is a procedural language, i.e., no object-oriented programming. C is a
compiled language.
C++ is a compiled, general-purpose object-oriented programming language. It is regarded as an
intermediate-level language, as it comprises a combination of both high-level and low-level
language features.
It was developed by Bjarne Stroustrup in 1979 as an extension to C. C++ is one of the most popular
programming languages and its application domains include systems software (such as Microsoft
Windows), application software, device drivers, embedded software, high-performance server and
client applications, and entertainment software such as video games.
Several groups provide both free and proprietary C++ compiler software.
18.2.2 C#
C# is pronounced “see sharp”. C# is an object-oriented programming language and part of the
.NET family from Microsoft. C# is intended to be a simple, modern, general-purpose, object-
oriented programming language. Its development team is led by Anders Hejlsberg.
C# is very like C++ and Java. C# is developed by Microsoft and works only on the Windows
platform. C# is based on the .NET Framework (pronounced “dot net”).
Part 3: Platforms & Architecture
275 18 Software Frameworks & Languages
.NET is a software framework that runs primarily on Microsoft Windows. The .NET Framework 1.0
and C# 1.0 were released in 2002 as part of Visual Studio .NET 2002.
Visual Studio is the Integrated Development Environment (IDE) you use when programming in C#
and the .NET platform.
Introduction to Visual studio and C#: [Link]
For more information about C#: [Link]
18.2.3 Java and Kotlin
Java is a programming language originally developed by James Gosling at Sun Microsystems (now
owned by Oracle Corporation) and released in 1995 as a core component of Sun Microsystems'
Java platform. The language derives much of its syntax from C and C++ but has a simpler object
model and fewer low-level facilities.
Java is currently one of the most popular programming languages in use and is widely used from
application software to web applications. Java applications are typically compiled, and it runs on
any Java Virtual Machine (JVM) regardless of the computer architecture. Java is a general-purpose
object-oriented. It is intended to let application developers “write once, run anywhere”.
Java is still one of the most popular programming languages, but a newer language called Kotlin
seems to be taken over for Java. Kotlin has among others replaced Java in Android programming.
Android Development with Android Studio and Kotlin: [Link]
18.2.4 Swift
Part 3: Platforms & Architecture
276 18 Software Frameworks & Languages
Swift is the new programming language created by Apple (now open source) and is now the
preferred language when creating Apps for the iOS platform and macOS.
iOS App Development with Xcode and Swift: [Link]
18.2.5 Python
Python is an interpreted high-level programming language and object-oriented programming, and
structured programming are fully supported. The reference implementation of Python (CPython) is
free and open-source software and has a community-based development model. In addition,
Python has alternative implementations.
Python logo:
Python interpreters are available for many operating systems, and Python programs can be
packaged into stand-alone executable code for many systems using various tools. Guido van
Rossum is the creator of Python (1989).
Python example:
>>> x = int(input("Please enter an integer: "))
Please enter an integer: 42
>>> if x < 0:
... x = 0
... print('Negative changed to zero')
... elif x == 0:
... print('Zero')
... elif x == 1:
... print('Single')
... else:
... print('More')
...
More
Python Programming: [Link]
For more information about Python:
[Link]
Part 3: Platforms & Architecture
277 18 Software Frameworks & Languages
18.2.6 JavaScript
JavaScript is an object-oriented scripting language that is dynamic, weakly typed. JavaScript is
primarily used in the form of client-side JavaScript, implemented as part of a web browser to
provide enhanced user interfaces and dynamic websites.
As in most scripting languages, types are associated with values, not with variables. For example, a
variable x could be bound to a number, then later rebound to a string. JavaScript uses syntax
influenced by that of C.
JavaScript copies many names and naming conventions from Java, but the two languages are
otherwise unrelated and have very different semantics. JavaScript was first shipped in 1995.
JavaScript very quickly gained widespread success as a client-side scripting language for web
pages.
Web Development – JavaScript: [Link]
18.2.7 SQL
SQL, often referred to as Structured Query Language, is a database computer language designed
for managing data in relational database management systems (RDBMS).
SQL has become the most widely used database language today. All popular Database Systems
support SQL, such as Oracle, SQL Server, etc. SQL was developed at IBM by Donald D. Chamberlin
and Raymond F. Boyce in the early 1970s.
SQL Server and Structured Query Language (SQL): [Link]
SQL Support all kind of CRUD (Create, Read, Update, Delete) operations on database systems.
Example of SQL Syntax:
insert into STUDENT (Name , Number, SchoolId)
values ('John Smith', '100005', 1)
select SchoolId, Name from SCHOOL
select * from SCHOOL where SchoolId > 100
update STUDENT set Name='John Wayne' where StudentId=2
delete from STUDENT where SchoolId=3
For more information about SQL, please see Chapter 25. You may also see the following resource:
Part 3: Platforms & Architecture
278 18 Software Frameworks & Languages
[Link]
18.3 Naming Convention
There are different name conventions for how to specify your variables, classes and Methods, etc.
Camel notation: For variables and parameters/arguments we normally use “Camel notation”.
Examples:
string myCar;
int number;
string backColor;
→ In Camel casing the first letter of an identifier is lowercase, and the first letter of each
subsequent concatenated word is capitalized.
Pascal notation: For classes, methods and properties, we normally use “Pascal notation”.
Examples:
class Car
{
void ShowCarColor()
{
…
}
}
→ In Pascal notation the first letter in the identifier and the first letter of each subsequent
concatenated word are capitalized.
For Namespaces we use Pascal casing and a dot separator.
Examples:
[Link]
[Link]
Controls: For controls on your user interface, we either use “Pascal notation” or “Hungarian
notation”, but stick to one of them!
Examples:
“Pascal notation”:
LoginName
LoginPassword
“Hungarian notation”:
Part 3: Platforms & Architecture
279 18 Software Frameworks & Languages
txtName
txtPassword
lblName
btnCancel
Where “txt” means that it is a Text Control, “lbl” a Label Control, “btn” a Button Control, etc.
Acronyms: The casing of acronyms depends on the length of the acronym. All acronyms are at
least two characters long. If an acronym is exactly two characters, it is considered a short acronym.
An acronym of three or more characters is a long acronym.
In general, you should not use abbreviations or acronyms. These make your names less readable.
Similarly, it is difficult to know when it is safe to assume that an acronym is widely recognized.
But if you must, the rules are as follows:
Short acronym Examples (two characters):
DBRate
A property named DBRate is an example of a short acronym (DB) used as the first word of a Pascal-
cased identifier.
ioChannel
A parameter named ioChannel is an example of a short acronym (IO) used as the first word of a
camel-cased identifier.
Long acronym Examples (three or more characters):
XmlWriter
A class named XmlWriter is an example of a long acronym used as the first word of a Pascal-cased
identifier.
htmlReader
A parameter named htmlReader is an example of a long acronym used as the first word of a
camel-cased identifier.
18.4 Defensive Programming
In programming error and exception handling is very important. C# has built-in and ready to use
mechanism to handle this. This mechanism is based on the keywords try, catch, throw and finally.
Exceptions are unforeseen errors that happen in your programs. Most of the time, you can, and
should, detect and handle program errors in your code. For example, validating user input,
Part 3: Platforms & Architecture
280 18 Software Frameworks & Languages
checking for null objects, and verifying the values returned from methods are what you expect, are
all examples of good standard error handling that you should be doing all the time.
However, there are times when you don't know if an error will occur. For example, you can't
predict when you'll receive a file I/O error, run out of system memory, or encounter a database
error. These things are generally unlikely, but they could still happen, and you want to be able to
deal with them when they do occur. This is where exception handling comes in.
18.4.1 Error Handling
Error handling is an important part of the coding process, making the applications robust when
some unexpected things happen.
Exception Handling: When exceptions occur, they are said to be “thrown”. C# uses the keywords
try, catch, throw and finally. It works like this: A method will try to execute a piece of code. If the
code detects a problem, it will throw an error indication, which your code can catch, and no
matter what happens, it finally executes a special code block at the end.
The syntax in C# is as follows:
MyMethod()
{
try
{
... //Do Something that can cause an Exception
}
catch
{
... //Handle Exceptions
}
finally
{
... //Clean Up
}
Example:
public void WriteDaqData(double analogDataOut)
{
Task analogOutTask = new Task();
AOChannel myAOChannel;
try
{
myAOChannel = [Link](
Part 3: Platforms & Architecture
281 18 Software Frameworks & Languages
aoChannel,
"myAOChannel",
0,
5,
[Link]
);
AnalogSingleChannelWriter writer = new
AnalogSingleChannelWriter([Link]);
[Link](true, analogDataOut);
}
catch (Exception e)
{
string errorMessage;
errorMessage = [Link]();
finally
{
[Link]();
}
18.5 Software Frameworks
Some popular software frameworks are:
• .NET Framework
• [Link]
They will be discussed in more detail below.
18.5.1 .NET Framework
The .NET Framework (pronounced “dot net”) is a software framework that runs primarily on
Microsoft Windows. It includes a large library and supports several programming languages which
allow language interoperability (each language can use code written in other languages). The .NET
library is available in all the programming languages that .NET supports. Programs written for the
.NET Framework execute in a software environment, known as the Common Language Runtime
(CLR), an application virtual machine that provides important services such as security, memory
management, and exception handling. The class library and the CLR together constitute the .NET
Framework.
18.5.2 [Link]
Part 3: Platforms & Architecture
282 18 Software Frameworks & Languages
[Link] is an open-source web framework, created by Microsoft, for building web apps and
services using the .NET Framework or the .NET Core. We have both [Link] and [Link] Core.
[Link] Core is the new approach built on .NET Core.
[Link] Core with Razor: [Link]
[Link] Core with Razor and SQL Server: [Link]
For more information about [Link]:
[Link]
Part 3: Platforms & Architecture
19 Software Architecture
When creating software, we use different architecture depending on the platform and the
purpose with the software.
In this document, we will focus on client-server, 3-tier architecture and creating and using Web
Services and APIs.
Figure 19-1: Software Architecture
In Figure 19-2 we see how a typical software application is interacting with the surrounding
environments, such as the users of the software and the underlying operating system (which is
also software) and hardware.
283
284 19 Software Architecture
Figure 19-2. Software Interaction with the Environment
Based on the fundamental interaction between the software and the environment we have
different kinds of software architecture.
Software Architecture Examples:
• Client – Server
• n-tier architecture, 3-tier architecture
• Model-View-Controller (MVC)
• Web Services
• Interfaces
• APIs
• Service-oriented architecture (SOA)
• Microservices
In Figure 19-3 we see some examples of different network and software architecture typically
used in software development.
Part 3: Platforms & Architecture
285 19 Software Architecture
Figure 19-3: Network/Software Architecture Examples
Make sure to document your system and your architecture in your documentation. You should
typically include several drawings and sketches of your architecture.
Make System Sketch in PowerPoint: [Link]
19.1 API
API - Application Programming Interface. An API is a specification of how some software
components should interact with each other. Typically, it is a library with functions, etc. you can
use in your code.
Examples:
• Windows API
• Java API
But you can also create your own API that you use internally in the team or an API that you expose
to others.
Part 3: Platforms & Architecture
286 19 Software Architecture
Creating APIs is good practice and makes it easy to reuse your code in other components or
applications. If all the developers in the team create the same code without thinking of reusing
code from others or creating code in such manners as it can’t be used by others, the software
project is doomed to fail.
Software Design without APIs:
Here are some pros and cons regarding APIs:
Pros:
• Fast to implement small projects.
• Agile – can serve as a starting point for API design.
• No need to consider how code interfaces with other software.
• Can be appropriate for small “dead end” projects.
Cons:
• Inappropriate for large projects.
• Code has a limited (as opposed to general) functionality.
• Code is not reusable.
• Code is hard to maintain/modify.
• Prone to errors and bugs.
Why a Good API is hard to Design?
Here are some examples:
• Forces designer to anticipate future usage of code.
• Requirements are incomplete (may never be complete).
• Requires abstraction.
• Requires modularization.
• Requires skills in programming languages.
• Requires code rewrites – time consuming and labor intensive.
Part 3: Platforms & Architecture
287 19 Software Architecture
[[Link]
When an API is used in a project, it
• Allows us to focus on the project.
• Saves development time.
• Reduces errors and debugging.
• Facilitates modular design.
• Provides a consistent development platform.
API driven design requires planning and programming skills. API driven design is costly initially, but
it pays in the long run. So, obviously, creating APIs is good software practice in most cases.
It is impossible to imagine how anyone would design a car today without taking advantage of
existing modules or vehicle subsystems – it is the same with software!
19.2 Client-Server
Client/server describes the relationship between two computer programs in which one program,
the client, makes a service request from another program, the server, which fulfills the request.
Although the client/server idea can be used by programs within a single computer, it is a more
Part 3: Platforms & Architecture
288 19 Software Architecture
important idea in a network. In a network, the client/server model provides a convenient way to
interconnect programs that are distributed efficiently across different locations.
19.3 Web Services and Web APIs
The “problem”: How do we share data between different devices in a network (see Figure 19-4)?
Figure 19-4: Data sharing between devices in a network
Direct connection between the database and the clients that need the data is normally not
possible, due to security, compatibility issues, etc. (firewalls, hacker attacks, etc.). Direct
connection in a local network (behind the firewall) is normally OK – but not over the Internet (see
Figure 19-5).
Figure 19-5: Limited access to the database in a network
Part 3: Platforms & Architecture
289 19 Software Architecture
The solution: Web Services. Web Services use standard web protocols like HTTP, etc. HTTP is
supported by all Web Browser, Servers, and many Programming Languages.
Today Web Services have been very popular. A Web service is a method of communication
between two devices over the World Wide Web and makes it easy to share data over a network or
the internet.
A Web Service is:
• A Web API
• A Standard defined by W3C
• Cross-platform and Platform-independent Communication
• Distributed Application Development
Web Services can be implemented and used in most Programming Languages (C#/[Link], PHP,
LabVIEW, Objective-C, Java, etc.)
Web services use standard web technology (web protocols) such as HTTP, REST, SOAP, XML,
WSDL, JSON, etc.
Figure 19-6: Web Services and Web APIs
Web services technology used in web services:
• HTTP - Hypertext Transfer Protocol
• XML – Extensible Markup Language
• WSDL - Web Services Description Language
• SOAP - Simple Object Access Protocol
• REST - Representational State Transfer
(We will not go into details)
Part 3: Platforms & Architecture
290 19 Software Architecture
A web service is typically deployed on a web server, similar as ordinary web pages, see Figure
19-7.
Figure 19-7: Web Service Infrastructure
We have 2 different types of web services:
• Web Services 1.0: SOAP Web Services
o “Complex”
• Web Services 2.0: REST web services or web APIs
o Lightweight and Flexible
o A new and simpler version of traditional web services
o All major web services or web APIs on the Internet today use REST
In Figure 19-8 we summarize Web Services 1.0 vs. 2.0.
Part 3: Platforms & Architecture
291 19 Software Architecture
Figure 19-8: Different kind of Web Services
This document only describes the basic principles of web services and web APIs.
19.3.1 SOAP Web Services
In Figure 19-9 we see the different “layers” a “SOAP Web Service” consists of.
Figure 19-9: SOAP Web Services Architecture
XML:
XML stands for eXtensible Markup Language. XML is designed to transport and store data.
Below we see an XML document example.
<?xml version="1.0"?>
Part 3: Platforms & Architecture
292 19 Software Architecture
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
19.3.2 REST Web Services
In Figure 19-10 we see the different “layers” a “REST Web Service” consists of.
Figure 19-10: REST Web Services Architecture
19.3.3 Creating Web Services with Visual Studio
Visual Studio has powerful features for creating Web Services and Web APIs (Figure 19-11).
Part 3: Platforms & Architecture
293 19 Software Architecture
Figure 19-11: Creating Web Services using Visual Studio and [Link]
19.4 3-tier Architecture
In general, we have so-called n-tier architecture, but the most common version is a 3-tier
architecture.
3-tier architecture is a client-server architecture in which the functional process logic, data access,
computer data storage and user interface are developed and maintained as independent modules
on separate platforms. Three-tier architecture is a software design pattern and a well-established
software architecture. Its three tiers are the presentation tier, application tier and data tier.
The 3 tiers or layers are as follows:
• Presentation Layer
• Business/Application Layer
• Data Access Layer
These layers may be on the same computer, but normally they are distributed on different
computers.
Part 3: Platforms & Architecture
294 19 Software Architecture
Figure 19-12: Software Architecture
A short description of the different layers:
Presentation Tier:
This is the topmost level of application. The presentation tier displays information related to such
services as browsing merchandise, purchasing, and shopping cart contents. It communicates with
other tiers by which it puts out the results to the browser/client tier and all other tiers in the
network.
In simple terms, it is a layer which users can directly access such as a web page, or an operating
systems GUI
Application tier:
(Other term used: Business logic, logic tier, data access tier, or middle tier) The application tier is
pulled out from the presentation tier and, as its own layer. It controls an application’s functionality
by performing detailed processing.
Data tier:
This tier consists of database servers. Here information is stored and retrieved. This tier keeps data
neutral and independent from application servers or business logic. Giving data its own tier also
improves scalability and performance.
Figure 19-13 shows a sketch of the typical logical layers or tiers in a 3-tier/layer architecture.
Part 3: Platforms & Architecture
295 19 Software Architecture
Figure 19-13: 3-tier Architecture
Figure 19-14 gives an overview of the 3-tier architecture and gives a short description of the
different layers.
In web development, 3-tiers are often common, including the following
• A Web Server
• An Application Server
• A Database
Web Services could be used for communication between the different layers.
Part 3: Platforms & Architecture
296 19 Software Architecture
Figure 19-14: 3-tier Overview
In Figure 19-15 we see an example of 3-layer architecture software.
Part 3: Platforms & Architecture
297 19 Software Architecture
Figure 19-15: Example of 3-layer Architecture Software
Part 3: Platforms & Architecture
Part 4 : Management
and Development Tools
In this part, we give an overview of tools used (and needed) in modern software engineering, like
collaboration tools, source code control tools, programming platforms, frameworks, languages,
etc.
298
20 Integrated Development
Environment (IDE)
What is an IDE? What is the difference between an IDE and a Programming Language?
Popular IDEs:
• Visual Studio
• Visual Studio Code
• Xcode
• Eclipse
• Android Studio
• Spyder
• etc.
Some of these will be discussed below.
20.1 Visual Studio
Microsoft Visual Studio (see Figure 20-1) is an integrated development environment (IDE) from
Microsoft.
299
300 20 Integrated Development Environment (IDE)
Figure 20-1: Visual Studio
It can be used to develop console applications and graphical user interface applications along with
Windows Forms applications, web sites, web applications, and web APIs, etc. Visual Studio Code is
also an alternative to Visual Studio.
Introduction to Visual Studio and C#: [Link]
Visual Studio is highly recommended for the following applications:
• Windows Forms Desktop Applications
• [Link] Core Web Applications
• .NET MAUI Mobile Apps
[Link] Core resources:
[Link] Core with Razor: [Link]
[Link] Core with Razor and SQL Server: [Link]
.NET MAUI resources:
Getting Started with .NET MAUI App Development: [Link]
Part 4: : Management and Development Tools
301 20 Integrated Development Environment (IDE)
20.2 Visual Studio Code
An open source and cross platform (Windows, MacOS and Linux) and simple and very downscaled
version of Visual Studio. It is very easy to use, it has IntelliSense, etc. Everything is done in code;
you cannot create your user interface graphically like you can do in Visual Studio. In Visual Studio
Code is the code in focus.
For more information: [Link]
20.3 Xcode
Xcode (see Figure 20-2) is the IDE created by Apple for developing software for Mac OS X and the
iOS platform (iPhone, iPad).
The programming languages used within the Xcode environment is Swift.
Swift is a new a general-purpose, high-level, object-oriented programming language that is based
on the C programming language and Objective-C, etc.
It is the main programming language used by Apple for the OS X and iOS and their respective APIs,
Cocoa and Cocoa Touch. Apple released a new programming language, called Swift. Swift has now
replaced Objective-C as the official language for iOS and Mac programming.
iOS App Development with Xcode and Swift: [Link]
Figure 20-2: Xcode
Part 4: : Management and Development Tools
302 20 Integrated Development Environment (IDE)
20.4 Android Studio
Google has released a new IDE for Android development called Android Studio (see Figure 20-3). It
was created to make it easier to develop Android Apps.
Android Studio is available on Windows, macOS and Linux.
Android Development with Android Studio: [Link]
Figure 20-3: Android Studio
Part 4: : Management and Development Tools
21 UML Software
There exist hundreds of different software for creating UML diagrams, here we mention just a few:
• Enterprise Architect
• StarUML
• UMLet and UMLetino
• Diagram tools like Lucidchart, Miro, [Link], etc.
• etc.
Some of these tools are explained in more detail below. For basic Use Case diagrams, you can also
use, e.g., Microsoft PowerPoint.
21.1 Enterprise Architect
Enterprise Architect is a modeling and design platform developed by Sparx Systems. This is
probably the most comprehensive UML software in use today. It is not free but can be used for
free for 30 days.
Enterprise Architect webpage: [Link]
21.2 StarUML
StarUML is cross-platform, which makes it possible to use it on Windows, Linux and macOS. You
can evaluate for free without time limit. Figure 21-1 show the StarUML software.
303
304 21 UML Software
Figure 21-1: StarUML
Web Site: [Link]
Download: [Link]
21.3 UMLet and UMLetino
UMLet and UMLetino are free UML tools that are easy to use. Se below.
21.3.1 UMLet
UMLet is a free, open-source UML tool with a simple user interface. UMLet includes a stand-alone
app for Windows, macOS, and Linux, or as Eclipse plugin. It is also available as web app called
UMLetino, and as extension to Visual Studio Code (Figure 21-2).
UMLet webpage: [Link]
Part 4: : Management and Development Tools
305 21 UML Software
Figure 21-2: UMLet Visual Studio Code Extension
21.3.2 UMLetino
UMLetino is a free online UML tool for fast UML diagrams. UMLetino runs in your web browser so
you don’t need to install it (see Figure 21-3). UMLetino is based on UMLet.
Figure 21-3: UMLetino Web Application
UMLetino webpage: [Link]
Part 4: : Management and Development Tools
22 Source Code Control (SCC)
22.1 Introduction
What is Source Code Control (SCC) or a version control system? A version control system keeps
track of all work and all changes in a set of files. It Allows several developers (potentially widely
separated in space and time) to collaborate.
In this chapter, we will give a short overview of some of the most popular source code control
(SCC) systems on the market today.
Azure DevOps with Git and Visual Studio: [Link]
Here is a list with some of the most popular SCC systems on the market today:
• Azure DevOps
• CVS
• SVN (Subversion)
• Git
• GitHub
• Mercurial
• Bazaar
• LibreSource
• Monotone
• BitKeeper
The focus will be on Azure DevOps from Microsoft because this software is tightly connected to
Visual Studio. Azure DevOps uses Git as a SCC repository. In addition, it has lots of other features
in addition to SCC.
Typical SCC Features:
• Checkout, Check-in/Commit
• Branching, Merging
• File Locking (avoid concurrent access)
• Label/Tag
• Change/Change List
• Conflict
• Revision, Iteration
306
307 22 Source Code Control (SCC)
We have two main kinds of SCC systems:
• Centralized/client–server architecture
• Distributed Version Control System (DVCS)
In Figure 22-1 we see an overview of which architecture the different SCC systems are using.
Figure 22-1: SCC Architecture
Centralized/Client–Server architecture:
A server stores the current version(s) of a project and its history, and clients connect to the server
to “check out” a complete copy of the project, work on this copy and then later “check in” their
changes.
Distributed Version Control System (DVCS):
With a distributed version control system, there isn’t one centralized code base to pull the code
from. Different branches hold different parts of the code. Git is a DVCS. Other version control
systems, such as SVN and CVS, use centralized version control, meaning that only one master copy
of the software is used. DVCS systems use a peer-to-peer approach.
In some cases, the SCC system is integrated in a so-called Application Lifecycle Management
system.
Application Lifecycle Management (ALM) systems are systems that take care of all aspects in
software development from planning, requirements, coding, testing, deployment, and
maintenance.
Part 4: : Management and Development Tools
308 22 Source Code Control (SCC)
ALM is short for Application Lifecycle Management. An ALM tool typically facilitates and integrate
things like:
• Requirements Management
• Architecture
• Coding
• Testing
• Bug Tracking
• Release Management
• etc.
22.2 Azure DevOps
Azure DevOps an Application Lifecycle Management (ALM) system, i.e., the system takes care of
all aspects in software development from planning, requirements, coding, testing, deployment
and maintenance.
Azure DevOps is a product designed specifically for software engineering teams with developers,
testers, architects, project managers, etc.
Azure DevOps is a Source Code Control (SCC), Bug Tracking, Project Management, and Team
Collaboration platform. Azure DevOps is tightly integrated with Visual Studio as Microsoft is the
vendor of both Visual Studio and Azure DevOps.
Here are some main features:
• SDLC Management (SDLC – Software Development Life Cycle)
• Software Team Collaboration
• Source Code Management
• Supports Agile, Scrum, CMMI
• Integrated Test Tools
• Automated Builds
• Built in Team Foundation Version Control (TSVC) + Support for Git repositories
• Built-in support for Azure DevOps in Visual Studio (Team Explorer)
• Plug-in for Eclipse (Team Explorer Everywhere)
• MSSCCI Provider for other IDEs like LabVIEW
• etc.
We will go through Azure DevOps in more detail in a later chapter.
22.3 SVN
Part 4: : Management and Development Tools
309 22 Source Code Control (SCC)
SVN or Subversion uses an Open-Source License. SVN was established in 2000. Subversion is
probably the version control system with the widest adoption today. Many different Subversion
clients are available (Tortoise SVN, Mac: Versions, Xcode (built-in support for SVN)).
SVN uses a Centralized/Client–Server architecture.
22.4 CVS
CVS, or Concurrent Versions System, was established between 1986-1990. It is free of charge. CVS
uses a client–server architecture. It is widely supported in different IDEs (Eclipse, Xcode, etc.).
22.5 Git
Git has become very popular today. Git is a Distributed Version Control System (DVCS). It was
initially designed and developed by Linus Torvalds (Linux Guru) in 2005. Git is free of use.
22.6 Others
Above we have discussed the most popular SCC systems today. Here are some other systems as
well:
• Mercurial
• Bazaar
• LibreSource
• Monotone
• BitKeeper
Look them up if you are interested!
22.7 Cloud-based SCC Hosting Services
For those who don’t want to install their own SCC repository in their own network, can use the
services in the cloud, either for free or for monthly payments.
Below we list some popular SCC hosting services:
• Azure DevOps
• GitHub
• Bitbucket
Part 4: : Management and Development Tools
310 22 Source Code Control (SCC)
22.7.1 Azure DevOps
Azure DevOps is an online SCC hosting service. You can configure and use Git repositories. You can
use this solution for free for up to 5 users, then you need to pay a monthly fee for additional users.
Web site: [Link]
22.7.2 GitHub
GitHub uses (as the name says) a Git repository.
Web site: [Link]
GitHub is now part of Microsoft.
22.7.3 Bitbucket
With Bitbucket you can either use a Mercurial or a Git repository. It is free for 5 users.
Web Site: [Link]
Part 4: : Management and Development Tools
23 Bug Tracking Systems
A software bug is an error, flaw, failure, or fault in a computer program or system that produces
an incorrect or unexpected result, or causes it to behave in unintended ways
They found a bug (a moth) inside a computer in 1947 that made the program not behave as
expected. This was the “first” real bug.
A “bug tracking system” or “defect tracking system” is a software application that is designed to
help keep track of reported software bugs in software development efforts.
Bug Reporting and Tracking with Azure DevOps: [Link]
Having a bug tracking system is extremely valuable in software development, and they are used
extensively by companies developing software products.
Here are some popular Bug Tracking Systems in use today:
• Azure DevOps
• Jira
• Bugzilla
• ClearQuest
• GitHub
We will focus on Azure DevOps in this document. The bug tracking features in Azure DevOps will
be discussed in another chapter
311
24 Azure DevOps
Azure DevOps is an Application Lifecycle Management (ALM) system, i.e., the system takes care of
all aspects in software development from planning, requirements, coding, testing, deployment,
and maintenance.
Azure DevOps is a product designed specifically for software engineering teams with developers,
testers, architects, project managers, etc.
It is free for up to 5 users and it is a good choice for small teams. It is also handy for personal use
or students.
Getting started with Azure DevOps:
• Goto [Link]
• Create an Account (You need a Windows Live ID) and specify an URL for your account
• Create a New Team Project
• You are ready to start
o Connect to Azure DevOps from Visual Studio
o Or use the Web based interface provided (except for SCC)
• Assign Team members
• Add Areas, Iterations, etc.
• Add your Source Code
• Check-in/Check-out your code
Azure DevOps with Scrum: [Link]
Azure DevOps with Git and Visual Studio: [Link]
Bug Reporting and Tracking with Azure DevOps: [Link]
Azure DevOps (see Figure 24-1) is a Source Code Control (SCC), Bug Tracking, Project
Management, and Team Collaboration platform. Azure DevOps is tightly integrated with Visual
Studio as Microsoft is the vendor of both Visual Studio and Azure DevOps.
312
313 24 Azure DevOps
Figure 24-1: Azure DevOps
Here are some main features:
• SDLC Management (SDLC – Software Development Life Cycle)
• Software Team Collaboration
• Source Code Management
• Supports Agile and Scrum
• Integrated Test Tools
• Automated Builds
• Support for Git repositories
• Built-in support for Azure DevOps in Visual Studio
• etc.
Azure DevOps has plenty of competitors. The main benefit of Azure DevOps is that all the systems
mentioned above is integrated in one package, normally you would need lots of different software
for this.
24.1 Source Code Control (SCC)
With Azure DevOps you may use Git as source code repositories, see Figure 24-2.
Git is a Distributed Version Control System (DVCS) that uses a local repository to track and version
files. Changes are shared with other developers by pushing and pulling changes through a remote,
shared repository.
Part 4: : Management and Development Tools
314 24 Azure DevOps
Figure 24-2: Start by creating a proper folder structure within your new Azure DevOps project
24.2 Areas and Iterations
Figure 24-3 shows an example of different Areas in Azure DevOps. The different software modules
could be divided into different Areas.
Figure 24-3: Azure DevOps Areas
Figure 24-4 shows an example of different Iterations in Azure DevOps. We can create Iterations for
the different releases/milestones, such as Alpha, Beta1, 2, 3, RC, RTM.
Part 4: : Management and Development Tools
315 24 Azure DevOps
Figure 24-4: Azure DevOps Iterations
24.3 Work Items
Work Items (Figure 24-5) are an important part of Azure DevOps. You may use Work Items to
register your requirements, user stories, bugs, tasks, etc.
Figure 24-5: Work Items in Azure DevOps
In Azure DevOps you can create different Work Items, such as:
• Task
Part 4: : Management and Development Tools
316 24 Azure DevOps
• Bug
• Feature
• Scenario
• Issue
• User Story
• Test Case
• etc.
These Work Items will be used at different level in your development cycle. When the Testers
reports bugs, they will, e.g., use the “Bug” Work Item, etc.
In Figure 24-6 we see how we can enter new Work Items using the Work Item Editor.
Figure 24-6: Work Item – New Bug
24.3.1 Queries
Queries are used to find existing Work Items. You may create different Queries to make it easy to
find the Work Items you need. Queries may be personal or visible for everybody in the project
You can use the Query Editor (Figure 24-7) to tailoring your own queries.
Part 4: : Management and Development Tools
317 24 Azure DevOps
Figure 24-7: Query Editor
24.4 Taskboard
In Agile development and Scrum the Taskboard feature (Figure 24-8) is very useful.
Figure 24-8: Taskboard
24.5 Agile (Scrum) Development in Azure DevOps
Azure DevOps has built-in Templates for Agile Development and Scrum.
Azure DevOps with Scrum: [Link]
Part 4: : Management and Development Tools
318 24 Azure DevOps
We have the Product Backlog, and the Sprint Backlog features (see Figure 24-9).
Figure 24-9: Product Backlog and Sprint Backlog in Azure DevOps
We also have a digital Taskboard available, see Figure 24-10.
Figure 24-10: Using a Taskboard in Azure DevOps
24.5.1 Product Backlog Items in Azure DevOps
To create the Product Backlog, we can add them in Azure DevOps as so-called Work Items. If you
use the Agile/Scrum templates a predefined Work Item Type “Product Backlog Item” is used for
this purpose.
Part 4: : Management and Development Tools
319 24 Azure DevOps
Figure 24-11: Create the Product Backlog in Azure DevOps
You may also group the items in the Product Backlog into “Features”.
24.5.2 Sprint Backlog Items in Azure DevOps
To create the Sprint Backlog, you just drag them to the proper Iteration.
Figure 24-12: Create the Sprint Backlog in Azure DevOps
To make that happen, you need to configure the different sprints as “Iterations” in Azure DevOps
(Figure 24-13). You also need to right-click and select “Set as Teams Backlog iteration”.
Part 4: : Management and Development Tools
320 24 Azure DevOps
Figure 24-13: Configure Iterations and Sprints in Azure DevOps
Break Sprint Backlog Items down into Tasks:
Finally, you break the Sprint Backlog Items into Tasks. In the Sprint Backlog click the sign to
add Tasks to the specific Backlog Item (see Figure 24-14).
Figure 24-14: Break Sprint Backlog Items down into Tasks
Then give the Task a name and estimate the work it will take (Remaining Work).
The results may look something like this (Figure 24-15):
Part 4: : Management and Development Tools
321 24 Azure DevOps
Figure 24-15: The Sprint Backlog divided into a hierarchical structure with Features, Backlog
Items and Tasks
24.5.3 Taskboard
Based on the Sprint Backlog Items and the Tasks created for each Sprint Backlog Items we can
start using the Taskboard features inside Azure DevOps.
The Taskboard is the heart of Daily Scrum Meetings. We can easily move tasks (drag and drop with
the mouse) on the task board to reflect their current state.
Part 4: : Management and Development Tools
322 24 Azure DevOps
Figure 24-16: Updating the Sprint Taskboard in Azure DevOps
We can also easily Assign/reassign people to the different tasks in addition to updating the
“Remaining Work” field before the Daily Scrum Meeting, see Figure 24-17.
Figure 24-17: Using the Taskboard to update the Sprint Tasks before/under the Daily Scrum
Meeting
24.6 Software Testing in Azure DevOps
Azure DevOps is a great tool for testing, for planning tests and it has advanced features for bug
reporting and bug tracking (see Figure 24-18).
Part 4: : Management and Development Tools
323 24 Azure DevOps
Figure 24-18: Software Testing in Azure DevOps/Visual Studio Team Services
Part 4: : Management and Development Tools
25 Databases
Almost any kind of software program uses a database for back-end storage, e.g., Facebook, etc.
Popular Database Systems:
• Microsoft SQL Server
• Oracle
• MySQL
• SQLite
• MS Access
• MariaDB
• PostgreSQL
• Etc.
The focus in this chapter will be Microsoft SQL Server.
25.1 SQL Server
SQL Server consists of a Database Engine and a Management Studio. The Database Engine has no
graphical interface - it is just a service running in the background of your computer (preferable on
the server). The Management Studio is graphical tool for configuring and viewing the information
in the database. It can be installed on the server or on the client (or both).
Figure 25-1: SQL Server
324
325 25 Databases
In Figure 25-2 we see the SQL Server Management Studio.
Figure 25-2: SQL Server Management Studio
25.2 ER Diagram
ER Diagram (Entity-Relationship Diagram) is used for design and modeling of databases. It specifies
tables and relationship between them (Primary Keys and Foreign Keys), see Figure 25-3.
Figure 25-3: ER diagram with Primary Keys and Foreign Keys relationships
Software Development - A Practical Approach!
326 25 Databases
In Figure 25-4 we see a typical ER diagram.
Figure 25-4: ER Diagram Example
25.3 ERD Tools
We can use a lot of different tools to create such ER diagrams. Some examples are DB Designer,
Lucidchart and erwin Data Modeler.
Database Design and Modelling using DB Designer: [Link]
25.4 Structured Query Language
Here we will only give a short introduction to Structured Query Language.
SQL Server and Structured Query Language (SQL): [Link]
SQL is a database computer language designed for managing data in Relational Database
Management Systems (RDBMS). In SQL, we have 4 different types of queries:
• INSERT
Software Development - A Practical Approach!
327 25 Databases
• SELECT
• UPDATE
• DELETE
Below we see some examples of typical SQL queries:
insert into STUDENT (Name, Number, SchoolId)
values ('John Smith', '100005', 1)
select SchoolId, Name from SCHOOL
select * from SCHOOL where SchoolId > 100
update STUDENT set Name='John Wayne' where StudentId=2
delete from STUDENT where SchoolId=3
These are referred to as CRUD – Create (Insert), Read (Select), Update and Delete.
25.4.1 Best Practice
Here are some “Best practice” recommendations for creating tables in a database system:
• Tables: Use upper case and singular form in table names – not plural, e.g., “STUDENT” (not
students)
• Columns: Use Pascal notation, e.g., “StudentId”
• Primary Keys:
– If the table name is “COURSE”, name the Primary Key column “CourseId”, etc.
– “Always” use Integer and Identity(1,1) for Primary Keys
• Specify Required Columns (NOT NULL) – i.e., which columns that need to have data or not
• Data Types: Standardize on these Data Types: int, float, varchar(x), datetime, bit
• Use English for table and column names
• Avoid abbreviations! (Use RoomNumber – not RoomNo, RoomNr, ...)
Software Development - A Practical Approach!
26 Unit Testing
Unit Testing (or component testing) refers to tests that verify the functionality of a specific section
of code, usually at the function level. In an object-oriented environment, this is usually at the class
and methods level. Unit Tests are written by the developers as part of the programming. Unit tests
are automatically executed (e.g., Visual Studio and Azure DevOps have built-in functionality for
Unit Testing).
Unit Testing in Visual Studio: [Link]
Here are some “best practice” rules regarding Unit Testing:
• A Unit Test must only do one thing
• Unit Test must run independently
• Unit Tests must not be dependent on the environment
• Test Functionality rather than implementation
• Test public behavior: private behavior relates to implementation details
• Avoid testing UI components
• Unit Tests must be easy to read and understand
• Create rules that make sure you need to run Unit Tests (and they need to pass) before you
can Check-in your Code in the Source Code Control System
26.1 Unit Tests Frameworks
Unit Tests are built into Visual Studio. Some other Unit Tests Frameworks are:
1. JUnit is a unit testing framework for the Java programming language.
2. Nunit: NUnit is an open-source unit testing framework for Microsoft .NET. It serves the
same purpose as JUnit does in the Java world
3. LabVIEW Unit Test Framework Toolkit
4. etc.
26.2 Unit Testing in Visual Studio
328
329 26 Unit Testing
Visual Studio has integrated possibilities for Unit Testing. In Figure 26-1 we see the Unit Test
Project that is built into Visual Studio.
Note! Some of the more advanced test features in Visual Studio are only available in the
Enterprise edition.
Figure 26-1: Unit Test Project used in Visual Studio
A typical Test Class in Visual Studio looks like this:
using System;
using [Link];
using BankAccount; //The Code that is going to be tested
namespace BankTest
{
[TestClass]
public class BankAccountTests
{
[TestMethod]
public void TestMethod1()
{
…
}
…
}
}
A test method must meet the following requirements:
• The method must be decorated with the [TestMethod] attribute.
Part 4: Management and Development Tools
330 26 Unit Testing
• The method must return void.
• The method cannot have parameters.
Example of a Unit Test written in C#:
[TestMethod]
public void Debit_WithValidAmount_UpdatesBalance()
{
// arrange
double beginningBalance = 11.99;
double debitAmount = 4.55;
double expected = 7.44;
BankAccount account = new BankAccount("Bryan Walton", beginningBalance);
// act
[Link](debitAmount);
// assert
double actual = [Link];
[Link](expected, actual, 0.001, "Account incorrectly");
}
We get an overview of all the Tests in the Test Explorer (Figure 26-2):
Figure 26-2: Test Explorer inside Visual Studio
Part 4: Management and Development Tools
331 26 Unit Testing
When you build the test project, the tests appear in the Test Explorer. If the Test Explorer is not
visible, choose Test on the Visual Studio menu, choose Windows, and then choose Test Explorer.
As you run, write, and rerun your tests, Test Explorer displays the results in default groups of
Failed Tests, Passed Tests, Skipped Tests and Not Run Tests.
You can choose to run the tests manually or automatically, e.g., every time you build the code, etc.
If you use Azure DevOps together with Unit Testing in Visual Studio you can also choose to force
Unit Testing before you can check-in the code.
26.3 Code Coverage
Code coverage is a measure used in software testing. It describes the degree to which the source
code of a program has been tested.
Example:
int foo (int x, int y)
{
int z = 0;
if ((x>0) && (y>0))
{
z = x;
}
return z;
}
When we test this function, it depends on the input arguments which parts of the code will be
executed. Unit Tests should be written to cover all parts of the code.
In Visual Studio (Ultimate or Premium) these features are built-in (see Figure 26-3).
Part 4: Management and Development Tools
332 26 Unit Testing
Figure 26-3: Code Coverage in Visual Studio
26.4 Exercises
Make sure to discuss and reflect over the following:
1. Explain the difference between unit testing and integration testing (or interface testing in
Sommerville)
2. Suggest “test cases” for the use case “Take out Money” from an ATM, i.e., give examples of
Unit Tests and Integration Tests
Part 4: Management and Development Tools
27 Deployment in Visual Studio
Getting software out of the hands of the developers into the hands of the users. More than 50% of
commissioned software is not used, mostly because it fails at the deployment stage. 80% of the
cost of (commissioned) software comes at and after deployment. Visual Studio has many built-in
features for deployment.
Deploy a Windows Forms App using Visual Studio: [Link]
Virtualization Deployment:
Install WinForm Desktop App in Virtual Test Environment using VirtualBox:
[Link]
Install [Link] Core Web App in Virtual Test Environment using VirtualBox:
[Link]
Microsoft Azure Deployment:
Microsoft Azure - SQL Databases and App Services: [Link]
Is it a Generic Software Product or a Tailor-made Software Solution? Different
Deployment/Installation preparations required!
We have
• Generic Software:
o Many Customers
o The Customers install the Software itself
• Tailor-made:
o Typically, only one Customer
o The Developer Company typically installs the software (at least server-side
components)
o If many Desktop Clients: A Setup is required
Different Deployment/Installation preparations required depending on what type of Apps you are
Developing.
333
334 27 Deployment in Visual Studio
Desktop Apps
– You need to create an .exe file and a Setup Package
– Setup packages can then be distributed on CDs/DVDs or downloaded from a Web
Page
– You use Setup to install the software on all the clients
– Time consuming, cumbersome, depends on local components that might not be
installed, version conflicts, etc. This makes it difficult (and a lot of work and testing)
to create robust setup packages
– Mac: You can deploy to Mac App Store, Windows 8: You can deploy to Windows
Store
Web Apps
• No client installation is needed!
• Installed on a Web Server (IIS, Apache)
• Accessed on the Clients using only a Web Browser
• Easy, simple to deploy new versions, bugfixes, etc. (Customers don’t need to do
anything)
• But make sure your App supports all major Web Browsers (Internet Explorer,
Chrome, Firefox, Opera, Safari)
Mobile Apps
• Deployed to "App Stores" like Apple App Store, Google Play, Windows Store
(Windows 8)
Server-side (Database, Web Services, etc.)
• Typically, a setup package that installs this, or manually if it is a tailor-made solution
27.1 Setup Creation Software
Here are some examples:
• InstallShield Professional/Premium
– InstallShield is professional software for creating installers, Price €2000+
• WiX Toolset (Windows Installer XML)
Part 4: Management and Development Tools
335 27 Deployment in Visual Studio
– Used to create Windows Installer packages ("MSI files)
– The WiX toolset builds Windows installation packages from XML source code.
– Free and Open Source
– Used by e.g., Microsoft to create Setup packages for Office, SQL Server, Visual
Studio, etc. Apple also uses it.
• Inno Setup
– Free of charge Installer for Windows programs
• NSIS (Nullsoft Scriptable Install System)
– Professional open-source system to create Windows installers.
• etc.
27.2 [Link] Core Deployment
[Link] Core is a framework for creating professional web applications and it is fully integrated
with Visual Studio.
Microsoft Azure - SQL Databases and App Services: [Link]
Part 4: Management and Development Tools
Part 5 : Cyber Security
In this part, Cyber Security will be discussed in the context of Software Engineering and Software
Development.
336
28 Cyber Security
28.1 Introduction
Cybersecurity is the practice of protecting systems, networks, and programs from digital attacks.
These cyberattacks are usually aimed at accessing, changing, or destroying sensitive information,
extorting money from users, or interrupting normal business processes.
With the good comes the bad. Since the Internet connected all devices together a new era of our
life was a fact.
The Internet is great for many things, but it is also a great place for criminals.
Figure 28-1 we see the evolution of computers and internet from the early begging and until
today.
Figure 28-1: The Evolution of Computers and Internet
You probably use hundreds of different Internet services. Is your personal data safe within these
companies?
• Is the data well protected (from hackers)?
• Is the data sold to other companies (advertising purposes)?
• Can you get an overview of the information stored on you?
• Is it possible to delete it?
Some terms:
337
338 28 Cyber Security
Data Security: Protect digital data (e.g., data in a database) from destructive forces and from the
unwanted actions of unauthorized users (e.g., hackers, etc.).
Data Privacy: Issues regarding your personal data stored.
Cyber Security is the practice of protecting systems, networks, and programs from digital attacks.
Cybersecurity, or computer security, is a catchall term for any strategy for protecting one’s system
from malicious attacks aimed at stealing money, personal information, system resources
(cryptojacking, botnets), and a whole host of other bad things. The attack might occur on your
hardware or software, or through social engineering.
GDPR: General Data Protection Regulation. EU directive. Purpose: Protect privacy and the data
stored, i.e., protection of your digital life.
Figure 28-2 shows an overview of Cyber Security Issues.
Figure 28-2: An overview of Cyber Security Issues
28.2 Types of Cyber Security Attacks
Different types of Cyber Security threats:
• Ransomware
• Malware
• Social engineering
• Phishing
• SQL Injection
• Etc.
Part 5: Cyber Security
339 28 Cyber Security
These will be discussed in more detail below.
28.2.1 Ransomware
Ransomware is a type of malicious software. It is designed to extort money by blocking access to
files or the computer system until the ransom is paid.
These include, e.g., email phishing and malvertising (malicious advertising). After it is distributed,
the ransomware encrypts selected files and notifies the victim of the required payment.
Paying the ransom does not guarantee that the files will be recovered, or the system will be
restored.
The most "famous" Ransomware is the WannaCry Ransomware.
28.2.2 Malware
Malware is a type of software designed to gain unauthorized access or to cause damage to a
computer. Malware is short for “malicious software”.
Examples of common malware include viruses, worms, Trojan viruses, spyware, adware, and
ransomware.
28.2.3 Social Engineering
Social engineering is a tactic that adversaries use to trick you into revealing sensitive information.
They can solicit monetary payment or gain access to your confidential data. Social engineering can
be combined with any of the threats listed above to make you more likely to click on links,
download malware, or trust a malicious source.
28.2.4 Phishing
Phishing is the practice of sending fraudulent emails that resemble emails from reputable sources.
The aim is to steal sensitive data like credit card numbers and login information, or to install
malware on the victim’s machine.
Phishing is the most common type of cyber-attack.
You can help protect yourself through education (teach them not to click on links, etc. from
untrusted sources) or a technology solution that filters malicious emails.
Types of phishing attacks:
Part 5: Cyber Security
340 28 Cyber Security
• Deceptive phishing - Deceptive phishing is the most common type of phishing. In this case,
an attacker attempts to obtain confidential information from the victims. Attackers use the
information to steal money or to launch other attacks. A fake email from a bank asking you
to click a link and verify your account details is an example of deceptive phishing.
• Spear phishing - Spear phishing targets specific individuals instead of a wide group of
people. Attackers often research their victims on social media and other sites. That way,
they can customize their communications and appear more authentic. Spear phishing is
often the first step used to penetrate a company’s defenses and carry out a targeted
attack.
• Whaling - When attackers go after a “big fish” like a CEO, it’s called whaling.
• Pharming - pharming sends users to a fraudulent website that appears to be legitimate.
However, in this case, victims do not even have to click a malicious link to be taken to the
bogus site.
28.2.5 Spam
Spam is unsolicited and unwanted junk email sent out in bulk to an indiscriminate recipient list.
Typically, spam is sent for commercial purposes. It can be sent in massive volume by botnets and
networks of infected computers.
Often, spam email is sent for commercial purposes. While some people view it as unethical, many
businesses still use spam. The cost per email is incredibly low, and businesses can send out mass
quantities consistently. Spam email can also be a malicious attempt to gain access to your
computer.
Spam email can be difficult to stop, as it can be sent from botnets. Botnets are a network of
previously infected computers. As a result, the original spammer can be difficult to trace and stop.
Spam email can be dangerous. It can include malicious links that can infect your computer with
malware (see What is malware?). Do not click links in spam. Dangerous spam emails often sound
urgent, so you feel the need to act.
28.2.6 SQL Injection
A Structured Query Language (SQL) injection occurs when an attacker inserts malicious code into a
server that uses SQL and forces the server to reveal information it normally would not.
An attacker could carry out a SQL injection simply by submitting malicious code into a vulnerable
website search box.
28.3 How to be Secure?
How can you avoid cyber-attacks in general?
Part 5: Cyber Security
341 28 Cyber Security
What can you do as a company or a private person?
Here are some examples:
• Passwords
• Firewall
• Antivirus and antimalware software
• Access control
• VPN
• Wi-Fi Network
• Education
These will be discussed in more detail below.
28.3.1 Passwords
Make sure to use secure passwords, don’t use the same password for all your services and
software systems.
28.3.2 Firewall
A firewall is a network security device that monitors incoming and outgoing network traffic and
decides whether to allow or block specific traffic based on a defined set of security rules.
Firewalls are the first line of defense in network security.
A firewall can be hardware, software, or both.
28.3.3 Web Application Firewall (WAF)
A web application firewall (WAF) is an application firewall for HTTP applications. It applies a set of
rules to HTTP conversation. Generally, these rules cover common attacks such as cross-site
scripting (XSS) and SQL injections.
The WAF software (or hardware) is installed on the server that runs the web applications or web
sites.
A WAF is used for protection of a specific web application or set of web applications.
A WAF creates a shield between the web application and the Internet, which can avoid many
common attacks.
A WAF helps protect web applications by filtering and monitoring HTTP traffic between a web
application and the Internet. It typically protects web applications from attacks such as cross-site
forgery, cross-site-scripting (XSS), file inclusion, and SQL injection, among others.
Part 5: Cyber Security
342 28 Cyber Security
Most professional hosting platforms offer WAP solutions, like Amazon Web Services.
In addition, there are many types of WAF software you can buy and use, e.g., Imunify360.
References:
[Link]
[Link]
[Link]
28.3.4 Antivirus and Antimalware Software
“Malware”, which is short for “malicious software”, includes viruses, worms, Trojans, ransomware,
and spyware. Sometimes malware will infect a network but lie dormant for days or even weeks.
The best antimalware programs not only scan for malware upon entry, but also continuously track
files afterward to find anomalies, remove malware, and fix damage.
The Windows 10 operating system has built in antivirus software called "Windows Defender".
The name “Antivirus” software is a little old, because viruses are just one kind of malware in
today’s world of cyber threats. Though viruses still exist, there are other forms of malware that are
more common these days, as mentioned in an earlier chapter.
28.3.5 Access Control
Not every user should have access to your network. To keep out potential attackers, you need to
recognize each user and each device.
28.3.6 Two-factor Authentication
Two-factor authentication (also known as 2FA) is a type, or subset, of multi-factor authentication.
It is a method of confirming users' claimed identities by using a combination of two different
factors: 1) something they know, 2) something they have, or 3) something they are.
A good example of two-factor authentication is the withdrawing of money from an ATM; only the
correct combination of a bank card (something the user possesses) and a PIN (something the user
knows) allows the transaction to be carried out.
All the large providers of internet services, like Facebook, Google, Apple, etc. offers Two-factor
authentication, you just need to turn it on.
References:
Part 5: Cyber Security
343 28 Cyber Security
[Link]
28.3.7 VPN
A virtual private network encrypts the connection from an endpoint to a network, often over the
Internet.
28.3.8 Web Hosting Providers
Make sure to use professional Web hosting companies for your web sites.
You have large Cloud platform providers like Amazon Web Services (AWS), Microsoft Azure, Oracle
Cloud and Google Cloud Platform.
These large providers have a high level of security, they continuously update the systems with new
security patches, etc.
28.3.9 Wi-Fi Network
Use only secure Wi-Fi networks, not open Wi-Fi network that do not need password, etc.
28.3.10 Operating System
Make sure your PC and the operating system is up to date.
28.3.11 Education
Learning more about cyber security threats and how you can protect yourself as a private person
or a company is crucial.
Part 5: Cyber Security
29 SQL Injection
A Structured Query Language (SQL) injection occurs when an attacker inserts malicious code into a
server that uses SQL and forces the server to reveal information it normally would not.
An attacker could carry out a SQL injection simply by submitting malicious code into a vulnerable
website search box.
SQL Injection - with Practical Examples using [Link] Core and C#:
[Link]
29.1 SQL Injection Examples
Below you find some basic SQL Injection examples.
Web Site:
<form action="/cgi-bin/login" method=post>
Username: <input type=text name=username>
Password: <input type=password name=password>
<input type=submit value=Login>
SQL query executed by the web site for getting the user information:
select * from Users where (username = 'submittedUser' and password =
'submittedPassword');
SQL Injection Example #1:
For example, if an application accepts and processes user-supplied data without any validation, an
attacker could submit a maliciously crafted username and password. Consider the following string
sent by an attacker:
username=admin%27%29+--+&password=+
The SQL query executed by the web site for getting the user information will be:
select * from Users where (username = 'admin') -- and password = ' ');
In this example, an attacker could successfully log in to the application using the admin account
without knowledge of the password to that account.
Note that the string of two dash characters (--) indicates to the database server that the remaining
characters in the SQL statement are a comment and should be ignored.
344
345 29 SQL Injection
SQL Injection Example #2:
A hacker might get access to user names and passwords in a database by simply inserting " OR
""=" into the user name or password text box:
The SQL query executed by the web site for getting the user information will be:
select * from Users where Name ="" or ""="" AND Pass ="" or ""=""
The SQL above is valid and will return all rows from the "Users" table, since OR ""="" is always
TRUE.
References:
[Link]
29.2 Resources
Here are some other resources regarding SQL injections:
• SQL Injection: [Link]
• SQL Injection Wikipedia: [Link]
• SQL Injection W3Schools: [Link]
Part 5: Cyber Security
30 User Identity and Login
Here we will give an overview of user identity and login features in modern applications.
The concepts will be exemplified using web technology and the [Link] Core web framework
from Microsoft.
[Link] is an open-source web framework, created by Microsoft, for building web apps and
services using the .NET Framework or the .NET Core. We have both [Link] and [Link] Core.
[Link] Core is the new approach built on .NET Core.
In this chapter we will see how we can create and use login functionality in your [Link] Core
Web Applications.
Typically, you need to create functionality for User Registration, Login, etc. Here you will see how
this can be done from scratch. If you do it from scratch, you will have full control of your code.
If you use something called “[Link] Core Identity” (which will be explained and demonstrated in
the next chapter) lots of “magic” happens behind the curtains. If something is not working, it may
be more complicated to figure out why.
Below you will find some useful [Link] resources.
[Link]
30.1 Password Security
Keeping your passwords safe is important and all software systems should take this seriously.
Password security mechanism:
• Encryption and Decrypting
• Hashing
• Salting
• 2 Factor Authentication
• Etc.
These password security mechanisms will be described in more detail below.
346
347 30 User Identity and Login
30.1.1 Encryption and Decrypting
Encryption is the practice of scrambling information in a way that only someone with a
corresponding key can unscramble and read it.
Encryption is a two-way function. When you encrypt something, you are doing so with the
intention of decrypting it later.
To encrypt data, you use an algorithm. Many different encryption algorithms do exist
Figure 30-1 gives an overview of the concepts of Encryption and Decryption.
Figure 30-1: Encryption and Decryption
When should encryption be used? Here are some examples:
• Encryption is a two-way function.
• You encrypt information with the intention of decrypting it later.
• Examples when to use encryption:
• Protecting Files and Information on your Computer
• Protecting your Cloud data
• Transmitting Data between 2 Computers
• Etc.
The key is that Encryption is reversible. Hashing is not.
30.1.2 Hashing
Hashing is the practice of using an algorithm to map data of any size to a fixed length. Encryption is
a two-way function. Hashing is a one-way function.
While it is technically possible to reverse-hash something, the computing power required makes it
unfeasible. Hashing is one-way. See Figure 30-2.
Part 5: Cyber Security
348 30 User Identity and Login
Encryption is meant to protect data in transit, hashing is meant to verify that a file or piece of data
has not been altered—that it is authentic. In other words, it serves as a checksum. Every hash
value is unique.
Figure 30-2: Hashing
30.1.3 Rainbow Tables
Is it possible to for a hacking to get access to Hashed Passwords?
By using something called “Rainbow Table” the hacker can get access to your hashed password,
see Figure 30-3.
Figure 30-3: Using Rainbow Table for Hacking your Hashed Password
Part 5: Cyber Security
349 30 User Identity and Login
If a hacker gets access to this Database, he can see that Mike and Peter have the same password,
but he does not know the actual password. If the Hacker has access to a so-called “Rainbow table”
(which is essentially a pre-computed database of hashes), he may also be able to find the
Password, as seen in Figure 30-3. If you have a complicated password, it is less likely that your
password is in such a Rainbow table.
30.1.4 Salting
Salting is a technique typically used for Password Hashing. It is a unique value that can be added to
the end of the password to create a different hash value. The additional value is referred to as a
“salt”. This is done to make it even more secure. Typically, the Hashing Algorithm uses a Random
salt. This prevents an attacker from seeing whether users have the same password. See Figure
30-4.
Figure 30-4: Salting
Is it possible to hack “Hashing with Salt”?
Assume Mike and Peter use the same Password, see Table 30-1. If a hacker gets access to this
database, he cannot see that Mike and Peter have the same password. This is because a random
Salt has made these 2 Hashed Passwords different!
Table 30-1: Examples of Hashed Passwords with Salt
User Name Hashed Password with Salt
Mike 4420d1918bbcf7
Part 5: Cyber Security
350 30 User Identity and Login
Bob 73fb51a0c9be7d
Peter 4520d1818cbcf7
Figure 30-5 shows a typical Flow when Creating User and Login.
Figure 30-5: Typical Flow when Creating User and Login
Part 5: Cyber Security
31 SQL Server Authentication
31.1 Introduction
SQL Server is a Database System from Microsoft. SQL Server comes in different editions, for basic,
personal use
SQL Server Express is recommended because it is simple to use, and it is free.
Web:
[Link]
Videos:
Introduction to SQL Server: [Link]
SQL Server Express Installation: [Link]
SQL Server and Structured Query Language (SQL): [Link]
31.2 Authentication
SQL Server has 2 different types of authentications:
• Windows Authentication
• SQL Server Authentication
Using “Windows Authentication” the Connection String looks like this:
DATA SOURCE=<SQL Server Name>;DATABASE=<Database Name>;Integrated Security = True;
Using “SQL Server Authentication” the Connection String looks like this:
DATA SOURCE=<SQL Server Name>;DATABASE=<Database Name>;UID=sa;PWD=<Your Password>;
Replace <SQL Server Name> with the name of your SQL Server, typically
"<YourComputerName>\SQLEXPRESS" if you are using SQL Server Express.
351
352 31 SQL Server Authentication
UID is a SQL Server user, here you can create your own SQL Server user inside SQL Server
Management Studio or use the built-in sa user (sa=System Administrator). During the setup of SQL
Server, you need to select "Mixed Mode" and enter the password for your sa user.
It may look something like this:
DATA SOURCE=HPPCWORK\\SQLEXPRESS;DATABASE=MEASUREMENTS;UID=sa;PWD=Password123;
You can also turn on “SQL Server Authentication” in SQL Server Management Studio (SSMS) after
installation of SQL Server. See Figure 31-1.
Figure 31-1: SQL Server Authentication
To change security authentication mode, do the following steps:
• In SQL Server Management Studio Object Explorer, right-click the server, and then click Properties.
• On the Security page, under Server authentication, select the new server authentication mode, and
then click OK.
• In the SQL Server Management Studio dialog box, click OK to acknowledge the requirement to
restart SQL Server.
• In Object Explorer, right-click your server, and then click Restart. If SQL Server Agent is running, it
must also be restarted. Or just restart your computer.
31.3 Create Logins in SQL Server
“sa” (short for System Administrator) is a built-in Login in SQL Server. You can also create your
own SQL Server Logins. Normally you should do that rather than using the “sa” login. “sa” have
access to “everything” and in context of Data Security that is unfortunate. In general, you should
make your own Logins that have access to only what is strictly necessary. See Figure 31-2.
Part 5: Cyber Security
353 31 SQL Server Authentication
Figure 31-2: Create Logins in SQL Server
We can select login type, see Figure 31-3.
Figure 31-3: New Login
Select access levels, see Figure 31-4.
Part 5: Cyber Security
354 31 SQL Server Authentication
Figure 31-4: Login - Select Access Level
Part 5: Cyber Security
Part 6 : Additional
Resources
In this part, additional resources, references, and appendices are available.
355
32 Glossary
Below we will give a short overview of some important topics in software development.
Term Description
Agile Agile software development is a group of software development methods
Development based on iterative and incremental development.
Agile Manifesto The philosophy behind Agile methods is reflected in the Agile Manifesto.
ALM Application Lifecycle Management. An ALM system takes care of all
aspects in software development from planning, requirements, coding,
testing, deployment, and maintenance. Azure DevOps is an example of an
ALM system.
API Application Programming Interface. API specifies how some software
components should interact with each other. In most of the cases an API
is a library of different classes, methods/functions, etc. that a developer
can use.
Burn Down A burn down chart is a graphical representation of work left to do versus
Chart time. The outstanding work (or backlog) is often on the vertical axis, with
time along the horizontal. That is, it is a run chart of outstanding work. It
is useful for predicting when all the work will be completed.
It is often used in agile software development methodologies such as
Scrum. However, burn down charts can be applied to any project
containing measurable progress over time.
Code No changes in the code can be made, except bugs.
Freeze/Feature
Freeze
Code Review Code inspections to check if code is properly written, and useful to avoid
bugs in your code.
Daily Scrum In Scrum Development they have daily 15 minutes meetings within the
Software Team. The Meeting is usually a Stand-up meeting.
DDT Development-Driven Testing
356
357 32 Glossary
Dog-fooding Computer software companies use its own product to demonstrate the
quality and capabilities of the product.
GUI Graphical User Interface. The part of the software the user sees and
interacts with.
HA High Availability. Some software needs to run 24-7.
HMI Human Machine Interface. Another term for Graphical User Interface.
IDE Integrated Development Environment. A software application that helps
developers create, edit, compile, and run their code.
Internal Server Typical errors from web pages. The Web server (running the Web Site)
Error encountered an unexpected condition that prevented it from fulfilling the
request by the client.
Pair 2 developers working together.
Programming
QA Quality Assurance. QA refers to the engineering activities implemented in
a quality system so that requirements for a product or service will be
fulfilled.
Refactoring Code refactoring is used in software development to improve existing
code without changing its functionality. The goal is to make the code
more robust and easier to maintain.
SCC Source Code Control or Version Control. A version control system keeps
track of all work and all changes in a set of files. Allow several developers
(potentially widely separated in space and time) to collaborate and share
code.
SDD Software Design Document. A document describing the design of a
software application.
SDK Software Development Kit. An SDK is typically a set of software
development tools that allows for the creation of applications for a
certain software package, software framework, hardware platform,
computer system, operating system, or similar development platform.
SDLC Software Development Life Cycle. The process of creating software.
Software Waterfall, Agile, etc.
Development
Process
Part 6: Additional Resources
358 32 Glossary
Software The discipline for creating software applications. A systematic approach to
Engineering the design, development, testing, and maintenance of software.
SRS Software Requirements Specifications. A document stating what at
application must accomplish.
STD Software Test Documentation. Contents: Introduction, Test Plan, Test
Design, Test Cases, Test procedures, Test Log, …, Summary.
STP Software Test Plan. Documentation stating what parts of an application
will be tested, and the schedule of when the testing is to be performed.
TDD Test-driven development (TDD) is a software development process that
relies on the repetition of a very short development cycle: first the
developer writes an (initially failing) test case that defines a desired
improvement or new function, then produces the minimum amount of
code to pass that test, and finally refactors the new code to acceptable
standards.
Azure DevOps Azure DevOps is a Source Code Control (SCC), Bug Tracking, Project
Management, and Team Collaboration platform from Microsoft
UML Unified Modeling Language. Language used in Software modeling.
XP eXtreme Programming. XP is an Agile Software Development method. It’s
based on Unit Testing, Code Reviews and Pair Programming.
Part 6: Additional Resources
References
• Sommerville, Software Engineering, 10 ed.: Pearson, 2016.
• Wikipedia. Software Requirements Specification. Available:
[Link]
• Wikipedia. Software Development Process. Available:
[Link]
• Wikipedia. Waterfall Model. Available: [Link]
• Wikipedia. V-Model (Software Development). Available: [Link]
Model_(software_development)
• Wikipedia. Agile Software Development. Available:
[Link]
• Agile. Agile Manifesto. Available: [Link]
• Wikipedia. Pair Programming. Available: [Link]
• Wikipedia. Scrum Development. Available:
[Link]
• Wikipedia, "Unified Process," 2017.
• K. Schwaber and J. Sutherland. 2011, The Scrum Guide. Available: [Link]
• E. J. Braude and M. E. Bernstein, Software Engineering: Modern Approaches, 2 ed.: Wiley,
2011.
• Microsoft. Windows 8 UX Guidelines. Available: [Link]
US/library/windows/apps/hh465424
• Apple. Mac OS X UX Guidelines. Available: [Link] -
documentation/userexperience/conceptual/applehiguidelines/UEGuidelines/UEGuidelines.
html
• Wikipedia. GUI Mockups. Available: [Link]
• F. Tsui, O. Karam, and B. Bernal, Essentials of Software Engineering, 3 ed.: Jones & Barlett
Learning, 2014.
• H.-P. Halvorsen. [Link] and Web Programming. Available: [Link]
• [18] H.-P. Halvorsen. Introduction to Visual Studio and C#. Available:
[Link]
• H.-P. Halvorsen. Structured Query Language. Available: [Link]
• L. Malka. API. Available: [Link]
• H.-P. Halvorsen. Introduction to Web Services. Available: [Link]
• E. Blankenship, M. Woodward, G. Holliday, and B. Keller, Professional Team Foundation
Server 2012: Wiley, 2013.
• H.-P. Halvorsen. Introduction to Database Systems. Available: [Link]
359
Hans-Petter Halvorsen
E-mail: [Link]@[Link]
Web: [Link]
[Link]
Software Development
A Practical Approach!
Hans-Petter Halvorsen
Copyright ©
ISBN: 978-82-691106-0-9
Publisher Identifier: 978-82-691106
[Link]
Software Development
You might also like
- Software Engineering Overview and MethodsNo ratings yetSoftware Engineering Overview and Methods29 pages
- Agile Scrum Integration Project OverviewNo ratings yetAgile Scrum Integration Project Overview4 pages
- Biru Simpel Laporan Perusahaan Bisnis PresentasiNo ratings yetBiru Simpel Laporan Perusahaan Bisnis Presentasi10 pages
- Effective Product Management StrategiesNo ratings yetEffective Product Management Strategies37 pages
- Software Development Best Practices GuideNo ratings yetSoftware Development Best Practices Guide87 pages
- Multimedia Application Development GuideNo ratings yetMultimedia Application Development Guide73 pages
- Blue and Purple Casual Corporate Tech Roadmap PresentationNo ratings yetBlue and Purple Casual Corporate Tech Roadmap Presentation1 page
- Motorbike Shopping Web App Project PlanNo ratings yetMotorbike Shopping Web App Project Plan27 pages
- Orthogonal Views in Software DevelopmentNo ratings yetOrthogonal Views in Software Development80 pages
- Software Development Life Cycle OverviewNo ratings yetSoftware Development Life Cycle Overview89 pages
- Software Development Life Cycle OverviewNo ratings yetSoftware Development Life Cycle Overview50 pages
- Delivering Beautiful Software Web Products EfficientlyNo ratings yetDelivering Beautiful Software Web Products Efficiently16 pages
- Integrated CRM and ERP Software DevelopmentNo ratings yetIntegrated CRM and ERP Software Development4 pages
- Agile Sprint Planning and RetrospectivesNo ratings yetAgile Sprint Planning and Retrospectives3 pages
- Key Steps in Software Development ProcessNo ratings yetKey Steps in Software Development Process1 page
- Online Selling Platform Development RoadmapNo ratings yetOnline Selling Platform Development Roadmap4 pages
- Software Process Characteristics 07072026No ratings yetSoftware Process Characteristics 0707202610 pages
- Salesforce Development Lifecycle OverviewNo ratings yetSalesforce Development Lifecycle Overview3 pages
- Software Verification and Validation: Module 1 - Introduction To Software EngineeringNo ratings yetSoftware Verification and Validation: Module 1 - Introduction To Software Engineering61 pages
- Understanding the Software Development Life CycleNo ratings yetUnderstanding the Software Development Life Cycle9 pages
- Software Development Life Cycle ExplainedNo ratings yetSoftware Development Life Cycle Explained7 pages
- Traditional vs Agile Methodologies GuideNo ratings yetTraditional vs Agile Methodologies Guide7 pages
- J-Park Simulator for Eco-Industrial ParksNo ratings yetJ-Park Simulator for Eco-Industrial Parks10 pages
- OCTA-ReVA: Open-Source Retinal Analysis ToolNo ratings yetOCTA-ReVA: Open-Source Retinal Analysis Tool12 pages
- Deep Learning for Network Intrusion DetectionNo ratings yetDeep Learning for Network Intrusion Detection25 pages
- Exporting Firewall Rules with PowerShellNo ratings yetExporting Firewall Rules with PowerShell9 pages
- Federal University, Ndufu-Alike Ikwo (Funai) : CSC 102: Introduction To Problem Solving (Lecture Note)No ratings yetFederal University, Ndufu-Alike Ikwo (Funai) : CSC 102: Introduction To Problem Solving (Lecture Note)21 pages
- Cyber Security - Network Intrusion Case StudyNo ratings yetCyber Security - Network Intrusion Case Study9 pages
- Use Case, Process Modeling and Process Description: Systems Analysis and DesignNo ratings yetUse Case, Process Modeling and Process Description: Systems Analysis and Design68 pages
- Heterogeneous Catalysis for Bioactive HeterocyclesNo ratings yetHeterogeneous Catalysis for Bioactive Heterocycles2 pages
- Command Line Guide for Nero 9 InstallationNo ratings yetCommand Line Guide for Nero 9 Installation18 pages