Software Development
Software Development
Software Development
A Practical Approach!
Hans-Petter Halvorsen, 2016.01.06
http://home.hit.no/~hansha
Preface
The main goal with this document:
This document tries to focus on a practical approach regarding Software Development.
ii
We will learn how to build good (i.e. high quality) software, which includes:
• Requirements Specification
• Technical Design
• Good User Experience (UX)
• Improved Code Quality and Implementation
• Testing
• System Documentation
• User Documentation
• etc.
http://home.hit.no/~hansha/?tutorial=software_development
iii
http://home.hit.no/~hansha
iv
Table of Contents
Preface ...................................................................................................................... ii
v
vi Table of Contents
7 Scrum ................................................................................................................ 64
7.1 The Scrum Process ......................................................................................................... 64
vii Table of Contents
11 UML ............................................................................................................... 95
Part 1 : Introduction
In this part we discuss what software development is with some examples. We also give a short
overview of the software history.
15
1 Introduction
What is Software Development? It is a complex process to develop modern and professional
software today. This document tries to give a short overview of Software Development. Normally
we use the terms System Engineering or Software Engineering.
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. To create such systems, involve a lot of different disciplines.
Figure 1-1: Hardware and Software working together
16
17 1 Introduction
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
Figure 1-3 we see the complexity of software development and different components that are
involved.
Figure 1-3: The Complexity of Software.
Part 1: Introduction
18 1 Introduction
In Figure 1-4 we see the different phases involved in the Software Development Lifecycle (SDLC).
Figure 1-4: The Software Development Lifecycle
• 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
19 1 Introduction
Figure 1-5: Activities involved in the different Software Phases
As you see, software development involves lot of phases the 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
20 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 involves a lot of money and a lot of
people. Here are some examples:
• Number of Code Lines: Real systems may have millions of code lines
• Combination of Hardware and Software: Most of the projects involves 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 needs some kind of structure! - Software Engineering is the Answer!
Part 1: Introduction
21 1 Introduction
Project Planning and Management is important in Software Development and we can use different
approaches to deal with the Software Development, which we will cover in this document.
Especially so-called Agile approaches, such as Scrum has 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 different 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
There are different approaches (Software Development Processes) that deal with these phases,
such as:
Part 1: Introduction
22 1 Introduction
• 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 different 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 different roles and teams are able to work together and collaborate.
The Programmer or System Engineer has to deal with that there exists 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 a given situation.
Part 1: Introduction
23 1 Introduction
Figure 1-8: Different 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
In order 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
24 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 facilitate and integrate 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. Team Foundation Server (TFS), Jita, etc.
We will take a closer look at TFS in this document. TFS from Microsoft, since it is tightly integrated
with Visual Studio.
Typically, you need to share the code with others 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
25 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 lots of bugs that needs to be found, tracked and fixed, etc. In
order to handle that we need a so-called Bug Tracking system.
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
26 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 the 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.
Part 1: Introduction
2 Software History
2.1 Introduction
The 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 (actually a moth) inside a computer in 1947 that made the program not
behaving 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
27
28 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.
• Apple (Software and Hardware) (established 1976), Steve Jobs, Steve Wozniak
Part 1: Introduction
29 2 Software History
In addition, we can mention companies like IBM, Oracle, Samsung (more hardware than software),
Amazon, SAP, Adobe, Symantec, VMware, etc.
Figure 2-3: Software Trends
Apps and Mobil devices: Everybody have 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 actually running in the Cloud (Cloud Computing). The security
challenges is very important in this case.
The companies that develop software needs to face these facts and make the necessary changes
in order to survive.
“Softwear” and Wearable Computing: Now we have watches like Galaxy Gear, the Apple Watch,
Google Glass, etc.
Part 1: Introduction
30 2 Software History
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.
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
31
32 3 Software Development
3.1 Challenges
In Figure 3-2 we see some of the challenges in software development.
2"
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.
• Stand-alone applications
Part 1: Introduction
33 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.
– Applications that execute on a remote computer and are accessed by users from
their own PCs or terminals. These include web applications such as e-commerce
applications.
– These are software control systems that control and manage hardware devices.
Numerically, there are probably more embedded systems than any other type of
system.
– 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.
– These are systems that are developed by scientists and engineers to model physical
processes or situations, which include many, separate, interacting objects.
– 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 a number of other software systems.
Generic products
• Stand-alone systems that are marketed and sold to any customer who wishes to buy them.
Part 1: Introduction
34 3 Software Development
Customized products
• 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.
o Documentation stating what parts of an application will be tested, and the schedule
of when the testing is to be performed
o Contents: Introduction, Test Plan, Test Design, Test Cases, Test procedures, Test
Log, …, Summary
Part 1: Introduction
35 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.
Part 1: Introduction
36 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.
37
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 the Stakeholders or Customers that play an important role in the
development.
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.
38
39 4 Development Teams
4.1 Teams
In order to create successfully software, collaboration inside the team is essential.
Figure 4-2: Team Collaboration
4.2 Roles
A typical Software Team consists of the following roles:
• Project Manager
• System Architect
• UX Designer (Software Designer)
• Programmer
• Software Tester
In addition, we have the Stakeholders or Customers that play an important role in the
development.
4.2.1 Stakeholders
All the people that has 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.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
see.
4.2.5 Programmer
The Programmer or the Developer is doing the actual implementation of the software, i.e., the
coding.
modules and components created by different developers, we need dedicated software testers
that can test the software on a higher level.
5 Software Development
Phases
In software development we have the following phases:
This chapter gives an introduction to these phases. Figure 5-1 shows an overview of the different
phases involved in Software Development:
Figure 5-1: Phases in Software Development
42
43 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 [1].
Functional Requirements: Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave in particular situations. May
state what the system should not do.
The requirements are often collected in a so-called “Software Requirements Specification (SRS)”
document.
• Introduction
o Purpose
o Definitions
o System overview
o References
• Overall description
o Product perspective
§ System Interfaces
§ User Interfaces
§ Hardware interfaces
§ Software interfaces
§ 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 [1].
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.
• 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 see.
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
see.
5.3 Implementation
Implementation = Coding.
Most of the software has a Graphical User Interface (GUI). Normally you separate the GUI design
and code in different layers or files.
5.4 Testing
Testing can be performed on different levels and by different persons. Testing is a very important
part of software development. About 50% of the software development is about testing your
software.
5.5 Deployment
What is Deployment?
Software deployment is all of the activities that make a software system available for use.
Examples:
• Installation
• etc.
Deployment strategies may vary depending of what kind of software we create, etc.
When the software is deployed or installed, you normally goes 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.
6 Software Development
Process
There are lots of different software development processes or methods in use today [3], 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 in 2 main categories; Plan-driven models and Agile
methods. The Waterfall model, V-model and the Spiral model is so-called plan-driven models,
while Scrum and eXtreme Programming are so-called Agile methods.
47
48 6 Software Development Process
Traditionally plan-driven methods where 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.
Figure 6-1: Software Development Methods
In Figure 6-2 we see the main difference between Agile development and ordinary plan-driven
development.
Plan-based development
Requirements change
requests
Agile development
Figure 6-2: Plan-driven vs. Agile Development [1]
Traditionally with the Waterfall model, you can only start on the next phase when the previous
phase is finished. This is why it is called the Waterfall method, see Figure 6-3.
Figure 6-3: Waterfall model [4]
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 [5] is derived from the more traditional Waterfall model.
The V-model is an extension of the waterfall model, but its 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.”
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.
So what is Agile development? – Here is a short summary:
Figure 6-5: Agile Features and Principles
• Scrum
• eXtreme Programming (XP)
In Figure 6-6 we see the key features with Agile Software Development.
Figure 6-6: Agile Software Development
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 [6]
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.
That is, while there is value in the items on the right, we value the items on the left more.
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 of 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.
Figure 6-8: Burndown Chart
Here are some key factors that separates the traditional waterfall method versus the more flexible
Agile methods, such as Scrum:
In Figure 6-9 wee 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
• Pair Programming
• Code Reviews
• Refactoring
• Unit Testing - In XP you start by writing Unit Tests before you start coding
• Standup Meetings
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.
Figure 6-11: Pair Programming [8]
So is Pair Programming Good or Bad? There exists various studies of the productivity of Pair
Programming [1]:
A reasonable question is: Should the 2 developers have the same skills or not?
• 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
6.2.3 Scrum
Scrum [9] 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.
Scrum is fairly simple and easy to understand. The method is more flexible and more informal than
plan-driven methods.
Figure 6-12: Scrum Overview
• Daily Scrum Meeting (Max 15 min, every day at the same time) (also called Standup
Meeting)
An example of a Daily Scrum Meeting is shown in Figure 6-13. It is normal to held this meeting as a
“standup meeting”, where participants actually standing during the meeting.
Figure 6-13: Daily Scrum Meeting (Standup Meeting) [9]
• Max 15 min.
• The meeting is held at the same time and place every day
• Purpose:
– Track Progress
6.2.4 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 focus on limit the WIP (Work in Progress). Kanban has focus on estimation.
In Kanban they use a Kanban board (Figure 6-14) in order to track the progress. The Kanban board
is very similar to the Task board used in Scrum.
Figure 6-14: Kanban board
The RUP has been designed to work together with UML (Unified Modelling Language).
• Inception
• Elaboration
• Construction
• Transition
Figure 6-15: Phases in Unified Process (UP) [10]
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.
6.5 Exercises
7. Explain the differences between Agile and plan-driven development. Give some examples in
each category
9. What is Scrum?
13. Suggest a Software Project where it may be beneficial to use the Waterfall model and another
where Scrum is the best choice
7 Scrum
Scrum [9] 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 fairly simple and easy to understand. The method is more flexible and more informal than
plan-driven methods.
Figure 7-1: Scrum Overview
64
65 7 Scrum
Figure 7-2: Scrum Process [9]
• Daily Scrum Meeting (Max 15 min, every day at the same time) (also called Standup
Meeting)
An example of a Daily Scrum Meeting is shown in Figure 7-3. It is normal to held this meeting as a
“standup meeting”, where participants actually standing during the meeting.
Figure 7-3: Daily Scrum Meeting (Standup Meeting) [9]
• Max 15 min.
• The meeting is held at the same time and place every day
• Purpose:
– Track Progress
• 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 [11].
• Product Owner
• Scrum Master
• Development Team
In addition, we have the Stakeholders, but they are not part of the Scrum team itself.
Figure 7-4 summarizes the different meetings (purpose, duration and frequency).
Figure 7-4: Scrum Meetings
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 how 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.
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.
• Continuously Integrate Changes and have Code Reviews and do continuous Code
Refactoring
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.
Figure 8-1: Project Triangle
• Proper Planning
• Kick-off and Brainstorming
• Planning and Estimation
• Project Tracking
• Communication and Collaboration
• Meetings
• Using proper Tools, such as e.g., TFS
72
73 8 Project Management
Agile Development needs also some kind of Project Management and Planning, which we will
discuss in more detail later in this chapter.
8.2 Kick-off/Brainstorming
A Project should always start with a Kick-off meeting where a brainstorming session is important
of that meeting.
• etc.
In addition to get 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 shall you use, etc.
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:
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
5. Work Breakdown (WBS, Work Breakdown Structure): Break down the project in 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)
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.
Figure 8-2: Gant Chart Example – Microsoft Project
It is important that the 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-3 we see the recommended way of working with the different project activities.
Figure 8-3: Project Work
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 meeting needed during the software development project:
Always be prepared before the meetings (otherwise you don’t need to be there)!
o Other matters
When you are finished with the meeting, write a short Minutes of Meeting as soon as possible.
… … …
… … …
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.
Figure 8-4 shows the steps involved in Agile Project Planning and Tracking.
Figure 8-4: Agile Project Planning and Tracking
In Agile Project Planning and Tracking, everything is broken down to so-called iterations, as shown
in Figure 8-5.
Figure 8-5: Using Iterations in Agile Project Planning and Tracking
The Task board is a key tool in Agile Project Planning and Tracking, see Figure 8-6
Figure 8-6: Task board used in Agile Software development
The Task board is used together with the Burndown chart, as shown in Figure 8-7.
Figure 8-7: 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 of 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.
Team Foundation Server (TFS) have all these features (Task board, Burndown chart, etc.) built-in.
8.6 Summary
Here is some important keywords for successful project management:
• Useful tools are in Project Management and Tracking are: Gantt Chart, Task board,
Burndown Chart
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 is that the customers most often don’t know
what they want or are not qualified to know what they need.
Figure 9-1: Software Requirements
83
84 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 its
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.
Client managers
System end-users
User
Client engineers
requirements
Contractor managers
System architects
System end-users
System Client engineers
requirements System architects
Software developers
Figure 9-3: Requirements Users [1]
Functional Requirements
Statements of services the system should provide, how the system should react to particular
inputs and how the system should behave in particular situations.
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 as a whole 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 requirements are for “business” people, while Detailed Requirements
are for developers, etc.
• Depend on the type of software, expected users and the type of system where the
software is used.
• Functional user requirements may be high-level statements of what the system should do.
• These define system properties and constraints e.g. reliability, response time and storage
requirements. Constraints are I/O device capability, system representations, etc.
9.5 SRS
Software Requirements Specifications (SRS) are:
• The software requirements document is the official statement of what is required of the
system developers.
• 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).
Figure 9-5: Typical SRS/SDD Contents
In Figure 9-6 we see the different users involved in the SRS document.
In Table 9-1 we see an example of what chapters that we can include in a SRS document.
Table 9-1: Example of Table of Contents for the SRS document [1]
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 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.
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.
9.7 Exercises
9. What is SRS?
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).
The GUI design has been in constant change since the first computers and software were created.
In Figure 10-1 we see the difference between Windows 1 and Windows 8.
Figure 10-1: User eXperience – UX
It is important that Documents, GUI, Code, etc. have the same “Look and Feel” – Use Common
Templates, APIs, 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.
91
92 10 User eXperience(UX)
Look and feel in operating system user interfaces serves 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.
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: Mac OS X UX Guidelines [14]
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 [15].
Figure 10-4: GUI Mockup Example
10.3 Creativity
Be creative - Think outside the box!
“Thinking outside the box” is a metaphor that means to think differently, unconventionally, or
from a new perspective.
11 UML
11.1 Introduction
UML is a modeling language used in software engineering. It is very popular within 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.
Figure 11-1: UML Diagrams
• Structure Diagrams
• Behavior Diagrams
o Interaction Diagrams (sub category of Behavior Diagrams)
• Class Diagram
• Component Diagram
• Deployment Diagram
• Object Diagram
• Package Diagram
• Activity Diagram
95
96 11 UML
• Sequence Diagram
• Communication Diagram
• Use Case Diagram
• State Machine Diagram
• Composite Structure Diagram
• Interaction Overview Diagram
• Timing Diagram
• Design:
o Forward Design: doing UML before coding. Makes it easier to create the code in a
structured manner
o Backward Design: doing UML after coding as documentation
• Code
o Some tools can autoAuto-generate Code from UML diagrams
• Visio
• Enterprise Architect
• Visual Studio (Enterprise)
These diagrams are available from the “Architecture” menu in Visual Studio.
Figure 11-2: Create UML diagrams with Visual Studio Ultimate
Register Export
patient statistics
View Manager
personal info. Generate
Medical receptionist
report
View record
Nurse
Doctor
Edit record
Setup
consultation
Figure 11-3: Use Case example
Figure 11-4 Sequence Diagram Example
Figure 11-5: Class Diagram Example
11.6 Summary
You should create Design and Specifications (including UML) before you start Coding. UML
diagrams is a general method/standard to do just that. But UML can also be used to document
your code afterwards (so-called Reverse Engineering).
UML makes it easier to create structured code and a good way to document your code properly.
UML should also be part of the code refactoring process and UML should be as part of the
continuous code improvements process. Note! If you update the code, make sure to update the
UML and vice versa!
11.7 Exercises
1. What is UML?
2. Give example of some types of UML diagrams (in total we have 14 different types)?
5. Create a Class Diagram for a typical School including Classes Teacher, Student, Course, Grade,
etc.
12 Software Implementation
The ultimate 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.
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 in order to keep track of different
versions of the code.
Figure 12-1: Software Implementation [16]
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.
• 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 exactly the same; for example, this involves the use of e.g.,
Hungarian notation, in which variable names include abbreviations for the type of variable.
101
102 12 Software Implementation
• 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 of the system requirements are met.
• Comments
• Debugging
• Code Review
• Refactorization
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.
• 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)
• 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.
• Particular 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.
• Camel notation
• Pascal notation
• Hungarian notation
Camel Notation
Pascal Notation
Examples: “ShowCarColor”
Hungarian Notation
For controls on your user interface we either use “Pascal notation” or “Hungarian notation”, but
stick to one of them!
Acronyms
12.2 Comments
Comments are very important and can significantly aid or hurt readability and maintainability.
• they may distract from the actual code and make the program more difficult to read and
We may classify comments into 6 different types:
6. External references
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.
– 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.
– 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 really 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.
– These are the most useful kinds of comments; they describe what the code is
supposed to do rather than what it does.
– 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.
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 (break-points, etc.)
3. For more “advanced” bugs other methods are required (Unit Testing, Integration Testing,
Regression Testing, Acceptance Testing, etc.) .
4. The main focus here will be on these methods, while Debugging is something you learned
in Programming courses.
• Stabilization/Reproduction
• 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.
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 commits to the source
control system.
Figure 12-2: Why you should do reviews
Better code always starts with review process!
Here are some topics that should be checked during the Code Review process [12]:
• 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 exactly 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).
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
• Long method (excessively large or long methods perhaps should be subdivided into more
cohesive ones)
• 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.
13 Testing
13.1 Introduction
Different people have come up with various definitions for Software Testing, but generally, the
goal with 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
Testing can be performed on different levels and by different persons. 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
111
112 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, network,
servers and clients, etc., it has become very complex to test it. Today we have not only ordinary
Desktop Apps, we have Web Apps, Mobile Apps, Apps for TVs, etc.
The software we creates is a layer between the user of the software and the hardware and the
operating system (Figure 13-3).
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: 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.
• To demonstrate to the developer and the customer that the software meets its
requirements.
• For custom software, this means that there should be at least one test for every
requirement in the requirements document.
• For generic software products, it means that there should be tests for all of 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.
• This means undesirable system behavior such as system crashes, unwanted
interactions with other systems, incorrect computations and data corruption.
A primary purpose of testing is to detect software failures so that defects may be discovered and
corrected.
It is commonly believed that the earlier a defect is found the cheaper it is to fix it.
Basically we do the following: Planning the Test, then we execute the Tests, finally we document
the Test results.
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.
Release testing: Release testing is the process of testing a particular release of a system that is
intended for use outside of the development team.
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.
• Alpha testing
o Users of the software work with the development team to test the software at the
developer’s site.
• Beta testing
o 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
o Customers test a system to decide whether or not it is ready to be accepted from
the system developers and deployed in the customer environment. Primarily for
custom systems.
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)
• 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).
They found a bug (actually a moth) inside a computer in 1947 that made the program not
behaving as expected. This was the “first” real bug.
• Alpha Release(s)
• Beta Release(s)
• RC - Release Candidate(s)
• RTM – Release To Manufacturing
Figure 13-7: Software versioning
Software testing should be performed during the whole Software Development Life Cycle (SDLC)
as shown in Figure 13-8.
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".
Figure 13-10: When are you Finished with Testing?
• Black-box
• White-box Testing
You need no knowledge of how the system is created. Black-box testing can be done by a person
who only know what the software is supposed to do. You may compare to driving a Car – you
don’t need to know how it is built in order to test it.
In Figure 13-11: Whitebox TestingFigure 13-12 we see how White-box Testing is working.
Figure 13-11: Whitebox TestingFigure 13-12: White-box Testing
• Unit Testing
• Regression Testing
• Integration Testing
• System Testing
• Acceptance Testing
Figure 13-13: Software 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.
Unit Tests are written by the developers as part of the programming. They are automatically
executed by the system, e.g., Visual Studio and Team Foundation Server have built-in functionality
for Unit Testing.
Sometimes the Unit Tests are written before you start programming, so-called Test Driven
Development (TDD).
Since Unit testing are part of the development process, so-called Unit Tests Framework are usually
integrated with the IDE.
• Visual Studio Unit Test Framework. Unit Tests are built into Visual Studio (no additional
installation needed)
• JUnit (Java)
• 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)
• etc.
Visual Studio have built-in features for Unit Testing. In the Solution Explorer you just add a “Test
Project” as part of your code (see Figure 13-14).
Figure 13-14: Unit Test Project in Visual Studio
In Figure 13-15 wee se an example of how how you create Unit Tests in Visual Studio and C#.
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-15: 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:
• Create rules that make sure you need to run Unit Tests (and they need to pass) before you
are allowed to Check-in your Code in the Source Code Control System
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.
Since system tests make sure the requirements are fulfilled, they must systematically validate each
requirement in the SRS (Software Requirements Specification).
Figure 13-16: 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! Others terms and definitions are used as well in different literature.
Figure 13-17: The Software Testing Process
Documents involved:
In addition to write 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.
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 a 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.
We will focus on Team Foundation Server (TFS) in this document. The bug tracking features in TFS
will be discussed in Chapter 24 - Team Foundation Server (TFS).
In TFS we can add requirements, user stories, tasks, new features, bugs, etc. as so-called “Work
Items” (Figure 13-18).
Figure 13-18: Team Foundation Server (TFS) – Work Items
• 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.
• etc.
This setup consists of the 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.
Figure 13-19: Development, Test and Production Environment
13.6.1 Virtualization
In order to create test environments easily, virtualization is the answer. There exists lots of
different virtualization solutions on the market today.
VMware Workstation Player (Figure 13-20: VMware PlayerFigure 13-21) is probably the simplest
and easiest solution. You may download it for free at no costs.
With VMware Workstation Player or other virtualization solutions 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 in in different operating systems, etc.
Figure 13-20: VMware PlayerFigure 13-21: VMware Workstation Player
Figure 13-22: Window Server 2012 running as a virtual machine
13.7.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 (actually a moth) inside a computer in 1947 that made the program not
behaving as expected. This was the “first” real bug.
13.7.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 (break-points, etc.). The
Compiler will also find syntax errors, etc.
For more “advanced” bugs other methods are required (Unit Testing, Integration Testing,
Regression Testing, Acceptance Testing, etc.). The main focus here will be on these methods, while
Debugging is something you learned in Programming courses.
Example:
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.
Example: Microsoft uses Windows PCs and Visual Studio to create their software.
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 the sense in the world for those who practice Agile.
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 over and over again, 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 & requirements
For more information about these 7 principles of testing, see the following:
http://www.guru99.com/software-testing-seven-principles.html
and
http://www.testingexcellence.com/seven-principles-of-software-testing
Figure 13-23: Test Categories, Test Levels and Test methods
13.10 Exercises
6. What is “Dog-fooding”?
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 deployment stage. 80% of the cost of
(commissioned) software comes at and after deployment.
Software deployment is all of the activities that make a software system available for use.
Examples:
• Documentation
• 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, 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)
140
141 14 Deployment and Installation
Figure 14-1: Software Releases before Deployment
• Start planning and development of Windows 8, 2008/2009 (the planning started before
Windows 7 was released)
14.3 Deployment
What is Deployment?
Software deployment is all of the activities that make a software system available for use.
Examples:
• Documentation
• Installation
• etc.
Deployment strategies may vary depending of what kind of software we create, etc.
• Business Processes: Most large software systems require the customer to change the way
they work.
• Expertise: Does the customer have the IT expertise to install the software?
• 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
During the software lifecycle we have 3 different environments for the software we are creating:
• Development Environment
• Test Environment
• Production Environment
Figure 14-2: Development-, Test- and Production Environment
Test/Production Environment is an Infrastructure with Servers, Virtual Servers, Database Servers,
Web Servers, etc.
• etc.
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.
This setup consists of the 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.
15 Project Documentation
During the software development a lots of documentation (Figure 15-1) is created in the different
phases of the development.
Figure 15-1: Example of Documentation during the SDLC
Some documents are for internal use inside the software company or inside the development
team, while others documents are important for the stakeholders and customers that are going to
use the software (Figure 15-2: Software DocumentatioFigure 15-3).
146
147 15 Project Documentation
Figure 15-2: Software DocumentatioFigure 15-3: Software Documentation
o Documentation stating what parts of an application will be tested, and the schedule
of when the testing is to be performed
o Introduction, Test Plan, Test Design, Test Cases, Test procedures, Test Log, …,
Summary
Figure 15-4: 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 sub categories:
• System Documentation
• User 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)
Satisfying these requirements requires different types of documents from informal working
documents through professionally produced User Manuals
• 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 from 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.
• E-mail messages, wikis, etc. These record the details of everyday communications
between managers and development engineers.
• Evolve in step with the product that it describes. Product documentation includes
– User documentation, which tells users how to use the software product,
1. System documentation includes all of 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.
In Figure 15-5 we see an overview of different product documentation and readers of such
documents.
Figure 15-5: Product Documentation Types & Readers [1]
For large systems that are developed to a customer’s specification, the system documentation
should include:
• 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 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.
• 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.
• 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 taken into account in its design
– 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.
• User Manual
• Installation Guide
• Wiki
• etc.
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 particular 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
• A cover page
• A preface, containing details of related documents and information on how to navigate the
user guide
• A contents page
• A guide on how to use at least the main functions of the system (Text + Screen Shots)
• A troubleshooting section detailing possible errors or problems that may occur, along with
how to fix them
If we have a generic product, it is especially important that the customers are able to 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:
• Executable files
• Check the system for missing dependencies or drivers etc. (e.g., Your software may
need .NET X.x, etc.)
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, software is changed. Who changes it?
• Development team 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.
Examples:
• Repair
o Fixing defects/bugs
• Enhancement
o New Requirements
16.2 Categories
155
156 16 Software Maintenance
• Corrective maintenance
• Adaptive maintenance
• Perfective maintenance
• Preventive maintenance
Figure 16-1: Software Maintenance Categories
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 it will occurs changes in the external environment
(OS, hardware, etc.) your software depends on.
Perfective New features based on new user requests. The software must continuously
adapt new needs or your software will become useless.
While [1] only divide into 3 different categories, see Figure 16-2.
Figure 16-2: Maintenance Categories [1]
158
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. In
order 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 runs inside a web browser, such as e.g., Internet Explorer, Chrome,
Safari, Opera or Firefox. In the simplest for we can use HTML. For more dynamic web pages
we can use ASP.NET, PHP, JavaScript, AJAX, etc.
Desktop
• Windows
• Mac OS
• Linux
Web
• ASP.NET
• PHP
• IIS
• Apache
• HTML
• JavaScript
• AJAX
Mobile Devices
159
160 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
Figure 17-2: Desktop and Mobile platforms Vendors
17.3 Desktop
On the desktop we have 3 main platforms, namely Windows, Linux and Mac OS X.
Figure 17-3: Desktop Platforms: Windows, Linux and Mac OS X
We have lots of development tools for these platforms, see Figure 17-4: Development Tools
availible for different Desktop PlatformFigure 17-5. These will be discussed more in detailed later.
Figure 17-4: Development Tools availible for different Desktop PlatformFigure 17-5:
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.
Figure 17-6: Windows Release History
• Windows 3
• Windows 95
• Windows NT
• Windows XP
• Windows 7
Figure 17-7: Windows 1.0
With Windows Microsoft changes the user experience dramatically, see Figure 17-8.
Figure 17-8: Windows 8
17.3.2 Mac OS X
Mac OS X (Figure 17-9) is developed by Apple Inc. Mac OS X 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 Mac OS X software can be deployed to Mac App Store for easy installation.
A popular development platform on Mac OS X is the Xcode IDE and the Objective C programming
language.
Figure 17-9: Mac OS X
The different releases of Mac OS X is named after big cats like Puma, Jaguar, Tiger Leopard, Lion,
see Figure 17-10.
Figure 17-10: Mac OS X Release History
The Mac OS X 10.9 was called “OS X Mavericks”, so from this version they have stopped using
names from big cats (all the names was taken?).
The latest version is called “OS X El Capitan”, so they have switched from big cats to famous places
in California, USA (Figure 17-11).
Figure 17-11: OS X Yosemite
17.3.3 Linux
Linux is 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-12 wee see that both Linux and Mac OS X have their origins from the UNIX
platform.
Figure 17-12: UNIX History
• Fedora
• Red Hat Linux
• SUSE
• Mandriva
• Ubuntu
• etc.
The penguin symbol (Figure 17-13: LinuxFigure 17-14) is typical for Linux.
Figure 17-13: LinuxFigure 17-14: The Linux Mascot
17.4 Web
Web have become more and more important as a platform for developing software.
• HTML
• JavaScript
• ASP.NET
• PHP
• Internet Information Services (IIS)
• 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-15 we see the typical web architecture, including web browsers, HTML, CSS,
JavaScript and a web server for hosting the web pages.
Figure 17-15: Web Architecture
In Figure 17-16 we se 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-16: 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
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.
Figure 17-17: Web Server
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. ASP.NET is built on the Common Language
Runtime (CLR), allowing programmers to write ASP.NET code using any supported .NET language,
such as C# and VB.NET.
ASP.NET web pages or webpage, known officially as Web Forms], are the main building block for
application development. Web forms are contained in files with an “.aspx” extension.
Figure 17-18: ASP.NET
For more information about ASP.NET, please see the Tutorial “ASP.NET and Web Programming”
[17].
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.
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()
{
document.getElementById("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 a 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>
<?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.
We have several different platforms, but these are the 3 major platforms.
Figure 17-19: Mobile Platforms
In general we have 2 different kind of apps for mobile devices (Figure 17-20), i.e., we can
distinguish between “native apps” and “web apps”. Web apps are created using HTML 5
technology and runs 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.
Figure 17-20: Native vs. Web Apps
Web apps are not real applications; they are really 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 really 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 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,
contacts list, etc.
• Native apps can use the device’s notification system and can work offline.
17.5.1 iOS
iOS (see Figure 17-21) 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 as the iPod touch (2007) and iPad (2010). With iOS 7 and later the OS have gone trough a
large makeover, compared to previous versions.
Figure 17-21: iOS (left: iOS 6, right: iOS 7)
iOS is derived from OS X, which is the operation system used on Apple Mac computers.
Apps can be downloaded from the App Store. In order 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 in order to create apps
for the iOS platform.
17.5.2 Android
Android (see Figure 17-22) is a Linux-based operating system designed for mobile devices such as
smartphones and tablets. Android is developed by Google.
Figure 17-22: Android
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 the 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-23 Android Versions
Notice that all Android versions are named after a dessert, a cake or other sorts of candy. They are
also in alphabetical orders:
• 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
More about Android for Developers here:
http://developer.android.com/index.html
Here you can get detailed information about Android and download resources, development
tools, etc., including Android Studio, which is thee 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 others
IDEs as well. Especially, many use the Eclipse software. In that case you need to download and
install the Android SDK Tools.
Figure 17-24 shows data about the relative number of devices running a given version of the
Android platform.
Figure 17-24: Android versions (2015.11.09)
Here you can find more information about the different versions, etc.:
http://developer.android.com/about/dashboards/index.html
Android has become a widely used platform for many different kinds of devices, including
smartphones, tablets, TV’s (Android TV), watches (Android Wear), and even cars (Android Auto).
• Windows 8 Pro – This version works on both ordinary PCs and tablets. The user interface is
divided into 2 parts; ordinary user interface like Windows 7 and so-called Modern UI
(previously called Metro). Modern GUI (see Figure 17-25) consists of so-called live tiles
• Windows RT – This version works only on tablets. This version uses the ARM architecture.
Windows RT consists of only the Modern UI.
Figure 17-25: Windows 8 Modern UI
Modern UI Apps may be downloaded from Windows Store which is integrated into Windows 8.
In order to create Modern UI Apps, you need to use a Windows 8 computer with the Visual Studio
2012 IDE installed.
In Figure 17-26 we see an overview of the Windows release history, from Windows 1.0 released in
1985 to Windows 8/Windows RT released in 2012.
Figure 17-26: Windows Release History
Figure 17-27: Windows Phone
Examples:
2. iCloud
3. Windows Azure
6. etc.
Figure 17-28: Cloud Computing (Wikipedia)
In this chapter we will discuss some of the most used (probably) programming languages today.
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.
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.
182
183 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++.
Figure 18-1: Programming LanguagescodeFigure 18-2: Programming Languages
Here is a list of some of the most popular programming languages in use today:
Note! The list is in
random order and based on my personal opinion. The list is not necessarily based on data like
"Number of installations", "Number of programmers using it", or "Total number of lines of code",
etc.
• C, C++
• C#
• Java
• Visual Basic
• Perl
• Python
• PHP
• JavaScript
• SQL
• MATLAB
• LabVIEW
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.
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.
Visual Basic, C, C++ and C# are typically compiled languages, while Python, PHP, MATLAB are
typically interpreted languages.
Figure 18-3 shows the Top 20 list from RedMonk (this is just on of many similar lists).
Figure 18-3: Popular Programming Languages – Top 20
Below we will give a very short introduction to some of the most popular programming languages.
18.2.1 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.
18.2.2 C++
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.3 C#
C# is pronounced “see sharp”. C# is an object-oriented programming language and part of the
.NET family from Microsoft. The most recent version is C# 4.5.1 and it is part of Visual Studio
2013.
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 similar to 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”).
.NET is a software framework that runs primarily on Microsoft Windows.
The .NET Framework 1.0
and C# 1.0 was 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.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace WindowsFormsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
}
}
18.2.4 Java
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”.
A common IDE for programming with Java is the Eclipse IDE.
Java and Eclipse are used to create
Android Apps.
18.2.5 Objective-C
Objective-C is a general-purpose, high-level, object-oriented programming language that is based
on the C programming language.
It is the main programming language used by Apple for the OS X and iOS and their respective APIs,
Cocoa and Cocoa Touch.
Originally developed in the early 1980s, it was selected as the main language used by NeXT for its
NeXTSTEP operating system, from which OS X and iOS are derived.
Visual Basic was derived from BASIC and enables the rapid application development (RAD) of
graphical user interface (GUI) applications, access to databases using Data Access Objects, Remote
Data Objects, or ActiveX Data Objects, and creation of ActiveX controls and objects.
Scripting languages such as VBA (Visual Basic for Applications) and VBScript are syntactically
similar to Visual Basic, but perform differently.
The final release was version 6 in 1998 (VB6). The successor is Visual Basic .NET (now known
simply as Visual Basic).
The .NET Framework 1.0 and Visual Basic .NET 1.0 (VB.NET or just Visual
Basic) was released in 2002 as part of Visual Studio .NET 2002.
18.2.7 Perl
Perl is a high-level, general-purpose, interpreted, dynamic programming language. Perl was
originally developed by Larry Wall in 1987 as a general-purpose Unix scripting language to make
report processing easier. Since then, it has undergone many changes and revisions and become
widely popular amongst programmers.
18.2.8 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 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:
18.2.9 PHP
PHP is a general-purpose scripting language originally designed for web development to produce
dynamic web pages (server-side scripting). For this purpose, PHP code is embedded into the HTML
source document and interpreted by a web server which generates the web page document.
PHP can be deployed on most web servers and as a standalone interpreter, on almost every
operating system and platform free of charge.
PHP was originally created by Rasmus Lerdorf in 1995.
PHP is installed on more than 20 million
websites and 1 million web servers including Facebook.
PHP originally stood for “Personal Home
Page”, while it is now said to stand for “PHP: Hypertext Preprocessor”. PHP is a free open source
software.
Some of the contents of this web site is created in PHP.
18.2.10 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 in order
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.
JavaScript is officially managed by Mozilla Foundation.
18.2.11 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 he most widely used database language today. All popular Database Systems
supports 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 Support all kind of CRUD (Create, Read, Update, Delete) operations on database systems.
For more information about SQL, please see [19] and Chapter 25.
18.2.12 MATLAB
MATLAB (matrix laboratory) is a numerical computing environment and fourth-generation
programming language. Developed by MathWorks, MATLAB allows matrix manipulations, plotting
of functions and data, implementation of algorithms.
MATLAB is intended primarily for numerical computing. MATLAB is widely used in academic and
research institutions, but also in the industry.
Figure 18-4: MATLAB
MATLAB Training:
http://home.hit.no/~hansha/?training=matlab
18.2.13 LabVIEW
LabVIEW is a graphical programming language.
LabVIEW (short for Laboratory Virtual
Instrumentation Engineering Workbench) is a platform and development environment for a visual
programming language from National Instruments.
LabVIEW was originally released for the Apple Macintosh in 1986 and it is commonly used for data
acquisition, instrument control, and industrial automation on a variety of platforms including
Microsoft Windows, various versions of UNIX, Linux, and Mac OS X.
In LabVIEW you can create and run executable files. In order to do so you need to have the
LabVIEW Run-time Engine installed on the target computer.
LabVIEW can be extended with
additional modules and Toolkits. LabVIEW MathScript is an add-on which is a miniature version of
MATLAB.
Figure 18-5: LabVIEW Program
LabVIEW Training:
http://home.hit.no/~hansha/?training=labview
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:
Examples:
class Car
{
void ShowCarColor()
{
…
}
}
→ In Pascal casing the first letter in the identifier and the first letter of each subsequent
concatenated word are capitalized.
Examples:
System.Drawing
System.Collections.Generics
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”:
txtName
txtPassword
lblName
btnCancel
Where “txt” means it is a Text Control, “lbl” a Label Control, “btn” a Button Control, etc.
Acronyms:
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.
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.
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.
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,
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.
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.
MyMethod()
{
try
{
... //Do Something that can cause an Exception
}
catch
{
... //Handle Exceptions
}
finally
{
... //Clean Up
}
Example:
AOChannel myAOChannel;
try
{
myAOChannel = analogOutTask.AOChannels.CreateVoltageChannel(
aoChannel,
"myAOChannel",
0,
5,
AOVoltageUnits.Volts
);
writer.WriteSingleSample(true, analogDataOut);
}
catch (Exception e)
{
string errorMessage;
errorMessage = e.Message.ToString();
finally
{
analogOutTask.Stop();
}
• .NET Framework
• WPF (Windows Presentation Foundation)
• Silverlight (obsolete, but still in use many places)
• etc.
18.5.2 WPF
Developed by Microsoft, the Windows Presentation Foundation (or WPF) is a computer-software
graphical subsystem for rendering user interfaces in Windows-based applications. WPF is part of
the .NET Framework
The graphical user interface in WPF is designed using XAML (Extensible Application Markup
Language). Following the success of markup languages for web development, WPF introduces a
new language known as eXtensible Application Markup Language (XAML), which is based on XML.
XAML is designed as a more efficient method of developing application user interfaces
Figure 18-6: The WPF Project Template in Visual Studio
In Figure 18-7 we see an example of a WPF application in Visual Studio. In addition to the graphical
designer we are able to create and modify the GUI using XAML.
Figure 18-7: Creating WPF Apps in Visual Studio
18.5.3 Silverlight
Microsoft Silverlight is an application framework for writing and running browser plug-ins or other
rich internet applications, with features and purposes similar to those of Adobe Flash. The run-
time environment for Silverlight is available as a plug-in for most web browsers. Silverlight is also
one of the two application development platforms for Windows Phone 7/8.
Silverlight is based on WPF, so in Silverlight applications, user interfaces are declared in Extensible
Application Markup Language (XAML) and programmed using a subset of the .NET Framework.
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.
199
200 19 Software Architecture
Figure 19-2. Software Interaction with the Environment
Based on the fundamental interaction between the software and the environments we have
different kinds of software architecture.
• Client – Server
• n-tier architecture, 3-tier architecture
• Model-View-Controller (MVC)
• Web Services
• Interfaces
• APIs
Figure 19-3: Network/Software Architecure ExamplesFigure 19-4: Network/Software
Architecture Examples
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 expose to others
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 create code in such manners it can’t be used by others, the software project is
doomed to fail.
Pros:
Cons:
• Requires abstraction.
• Requires modularization.
When an API is used in a project, it
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
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.
Figure 19-5: 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-6: Limited acces to the database in a networkFigure 19-7).
Figure 19-6: Limited acces to the database in a networkFigure 19-7: Limited Access to the
Database in a Network
The solution: Web Services. Web Services uses 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 communications
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#/ASP.NET, PHP,
LabVIEW, Objective-C, Java, etc.)
Web Services uses standard Web technology (Web protocols) such as HTTP, REST, SOAP, XML,
WSDL, JSON, etc.
Figure 19-8: Web Services
A Web Service is typically deployed on a web server, similiar as ordinary web pages, see Figure
19-9.
Figure 19-9: Web Service Infrastructure
“Complex”
Figure 19-10: Different kind of Web Services
This document only describes the basic principles of Web Services. For practical code examples,
see the Tutorial “Introduction to Web Services” [23].
Figure 19-11: SOAP Web Services Architecture
XML:
XML stands for eXtensible Markup Language. XML is designed to transport and store data.
<?xml version="1.0"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
Figure 19-12: REST Web Services Architecture
3 ways to do it:
Figure 19-13: Creating Web Services using Visual Studio and ASP.NET
Below we see an example of a Web Service created with Visual Studio and ASP.NET:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Services;
namespace CalculatorWS
{
/// <summary>
/// Summary description for CalculatorWS
/// </summary>
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(false)]
// [System.Web.Script.Services.ScriptService]
public class CalculatorWS : System.Web.Services.WebService
{
[WebMethod]
public string HelloWorld()
{
return "Hello World";
}
[WebMethod]
[WebMethod]
public double Substract(double a, double b)
{
return a - b;
}
[WebMethod]
public double Multiply(double a, double b)
{
return a * b;
}
[WebMethod]
public double Divide(double a, double b)
{
return a / b;
}
}
}
A Web Service can be accessed through a web browser (see Figure 19-14) or other clients.
Figure 19-14: Web Service Example
A Web Service is typically hosted on a web server, e.g., IIS (Internet Information Services).
Figure 19-15: Web Service hosted in IIS
In order to use a Web Service we need to add a Service Reference to the project where we want to
consume or use the Web Service (see Figure 19-16).
Figure 19-16: Add Web Service Reference in Visual Studio
MessageBox.Show(myWS.HelloWorld());
In this simple example we just called the “HelloWorld” Web Service Method.
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.
• Presentation Layer
• Business/Application Layer
These layers may be on the same computer, but normally they are distributed on different
computers.
Figure 19-17: Software Architecture
Presentation Tier:
This is the topmost level of the 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 access directly such as a web page, or an operating
systems GUI
Application tier:
(Other terms 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-18 shows a sketch of the typical logical layers or tiers in a 3-tier/layer architecture.
Figure 19-18: 3-tier Architecture
Figure 19-19 gives an overview of the 3-tier architecture and gives a short description of the
different layers.
• A Web Server
• An Application Server
• A Database
Web Services could be used for communication between the different layers.
Figure 19-19: 3-tier Overview
Figure 19-20: Example of 3-layer Architecture Software
20 Integrated Development
Environment (IDE)
What is an IDE? What is the difference between an IDE and a Programming Language?
Popular IDEs:
• Visual Studio
• Xcode
• Eclipse
• Android Studio
Figure 20-1: Visual Studio
217
218 20 Integrated Development Environment (IDE)
It can be used to develop console and graphical user interface applications along with Windows
Forms applications, web sites, web applications, and web services in both native code together
with managed code for all platforms supported by Microsoft Windows, Windows Phone, Windows
CE, .NET Framework, .NET Compact Framework and Microsoft Silverlight.
For more information about Visual Studio and C#, see [18].
20.2 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).
It is the main programming language used by Apple for the OS X and iOS and their respective APIs,
Cocoa and Cocoa Touch. Actually Apple released a new programming language, called Swift. Swift
has now replaced Objective-C as the official language for iOS and Mac programming.
Originally developed in the early 1980s, it was selected as the main language used by NeXT for its
NeXTSTEP operating system, from which OS X and iOS are derived.
Figure 20-2: Xcode
20.3 Eclipse
Eclipse (see Figure 20-3) is a multi-language Integrated Development Environment (IDE). It is
written mostly in Java. It can be used to develop applications in Java, C, C++, JavaScript, Perl, PHP,
Python, Ruby, etc.
Figure 20-3: Eclipse
Eclipse is the main IDE used for Android programming. Then you will need the Android SDK plug-
in.
Figure 20-4: Android Studio
21 UML Software
There exists hundreds of different software for creating UML diagrams, here we mention just a
few:
• Visio
• Enterprise Architect
• Visual Studio (Enterprise)
• StarUML
• Rational Rose
• etc.
21.1 Visio
In Figure 21-1 we see the available UML diagram in Visio.
Figure 21-1: UML Diagrams in Visio
221
222 21 UML Software
Figure 21-2: UML Diagrams in Visual Studio Ultimate
In this chapter we will give a short overview of some of the most popular source code control
(SCC) systems on the market today.
Here are a list with some of the most popular SCC systems on the market today:
The main focus will be on Team Foundation Server from Microsoft because this software is tightly
connected to Visual Studio. In addition, it has lots of other features in addition to SCC.
• Checkout, Checkin/Commit
• Branching, Merging
• File Locking (avoid concurrent access)
• Label/Tag
• Change/Change List
• Conflict
• Revision, Iteration
• Centralized/client–server architecture
• Distibuted Version Control System (DVCS)
223
224 22 Source Code Control (SCC)
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
in order to “check out” a complete copy of the project, work on this copy and then later “check in”
their changes.
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.
ALM is short for Application Lifecycle Management. An ALM tool typically facilitate and integrate
things like:
• Requirements Management
• Architecture
• Coding
• Testing
• Bug Tracking
• Release Management
• etc.
Team Foundation Server is a separate server product designed specifically for software
engineering teams with developers, testers, architects, project managers, etc.
TFS is a Source Code Control (SCC), Bug Tracking, Project Management, and Team Collaboration
platform. TFS is tightly integrated with Visual Studio as Microsoft is the vendor of both Visual
Studio and TFS. For more information, see [24].
22.3 SVN
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)).
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 others systems as
well:
• Mercurial
• Bazaar
• LibreSource
• Monotone
• BitKeeper
• Visual Studio Team Services (formerly known as Visual Studio Online/Team Foundation
Services)
• GitHub
• Bitbucket
Visual Studio Team Services (VSTS) is an online SCC hosting service based on the Team Foundation
Server (TFS) platform.
You can either use the built-in SCC repository (called TFVC) or a Git repository.
You can use this solution for free for up to 5 users, then you need to pay a monthly fee for
additional users.
22.7.2 GitHub
GitHub uses (as the name says) a Git repository.
22.7.3 Bitbucket
With Bitbucket you can either use a Mercurial or a Git repository. It is free to use for 5 users.
They found a bug (actually a moth) inside a computer in 1947 that made the program not
behaving 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.
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:
We will focus on Team Foundation Server in this document. The bug tracking features in TFS will
be discussed in chapter 24 - Team Foundation Server (TFS).
228
Team Foundation Server is a separate server product designed specifically for software
engineering teams with developers, testers, architects, project managers, etc.
TFS (see Figure 24-1) is a Source Code Control (SCC), Bug Tracking, Project Management, and Team
Collaboration platform. TFS is tightly integrated with Visual Studio as Microsoft is the vendor of
both Visual Studio and TFS. For more information, see [24].
Figure 24-1: Team Foundation Server (TFS)
229
230 24 Team Foundation Server (TFS)
The following diagram (Figure 24-2) demonstrates that team members on different platforms can
collaborate by using Team Foundation Server.
Figure 24-2: TFS Everywhere
TFS has plenty of competitors. The main benefit with TFS is that all the systems mentioned above
is integrated in one package, normally you would need a lots of different software for this.
TFS is something you install on a server, but to get access to the functionality there exists different
kinds of client tools (see also Figure 24-3):
Figure 24-3: Team Foundation Server - Client Tools
1. TFVC: Team Foundation Version Control (TFVC) uses a single, centralized server repository
to track and version files. Local changes are always checked in to the central server where
other developers can get the latest changes.
2. Git: 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.
We will focus on TFVC, since this is the default choice within TFS. Before you start adding code or
other documents to your repository, it is a good idea to create a proper folder structure. Open
Visual Studio and connect to your TFS, then open the Team Explorer. From the Team Explorer,
select the Source Control Explorer (see Figure 24-4).
Figure 24-4: Start by creating a proper folder structure within your new TFS project
Figure 24-5: TFS Areas
Figure 24-6 shows an example of different Iterations in TFS. We can create Iterations for the
different releases/milestones, such as Alpha, Beta1, 2, 3, RC, RTM.
Figure 24-6: TFS Iterations
Figure 24-7: Work Items in TFS
• Task
• 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-8 we sww how we can enter new Work Items using the Work Item Editor.
Figure 24-8: 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-9) in order to tailoring your own queries.
Figure 24-9: Query Editor
24.4 Taskboard
In Agile development and Scrum the Taskboard feature (Figure 24-10) is very useful.
Figure 24-10: Taskboard
Figure 24-11: Visual Studio Team Services
• Goto http://visualstudio.com
• 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 Team Foundation Service from Visual Studio (similar as connection to a
Team Foundation Server)
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
Figure 24-12: Visual Studio Online – Getting Started
When creating a New Team Project we can select between different templates, see Figure 24-13,
such as Agile Development and Scrum Development.
Figure 24-13: New Team Project - Templates
When we have created a new Project (or clicked on an existing Project) the following web page
appears (Figure 24-14):
Figure 24-14: Visual Studio Team Services – Project Home Page
Below we give an overview of the different client tools available for Team Foundation Server:
Team Explorer is integrated with Visual Studio. In Figure 24-15 we see Visual Studio with Team
Explorer. In addition to Team Explorer we have the Source Control Explorer, which is handy when
we want to make a good structure, create folders, etc. We can check-in and check-out files using
the Source Control Explorer.
Figure 24-15: Visual Studio with Team Explorer
The process of check-in and check-out files can also be done from the Solution Explorer in Visual
Studio (see Figure 24-16).
Figure 24-16: Visual Studio and Solution Explorer
Figure 24-17: MS Excel Add-in for TFS
Figure 24-18: Windows Explorer Integration in TFS
Figure 24-19: TFS MSSCCI used together with LabVIEW
In LabVIEW we select Tools è Options in order to configure the TFS MSSCCI Provider for use
within the LabVIEW environment, then select the “Source Control” tab (see Figure 24-20). If you
have installed the TFS MSSCCI Provider properly you should be able to find it in the list of available
providers.
Figure 24-20: Configuration of TFS MSSCCI Provider in LabVIEW
We have the Product Backlog and the Sprint Backlog features (see Figure 24-21).
Figure 24-21: Product Backlog and Sprint Backlog in TFS
Figure 24-22: Using a Taskboard in TFS
Figure 24-23: Create the Product Backlog in TFS
You may also group the items in the Product Backlog into “Features”.
Figure 24-24: Create the Sprint Backlog in TFS
In order to make that happen, you need to configure the different sprints as “Iterations” in TFS
(Figure 24-25). You also need to right-click and select “Set as Teams Backlog iteration”.
Figure 24-25: Configure Iterations and Sprints in TFS
Finally, you break the Sprint Backlog Items into Tasks. In the Sprint Backlog click the sign in
order to add Tasks to the specific Backlog Item (see Figure 24-26).
Figure 24-26: Break Sprint Backlog Items down into Tasks
Then give the Task a name, and estimate the work it will take (Remaining Work).
The final results may look something like this (Figure 24-27):
Figure 24-27: The Sprint Backlog divided into a hierarchical structure with Features, Backlog
Items and Tasks
24.7.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 TFS.
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.
Figure 24-28: Updating the Sprint Taskboard in TFS
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-29.
Figure 24-29: Using the Taskboard to update the Sprint Tasks before/under the Daily Scrum
Meeting
Figure 24-30: Software Testing in TFS/Visual Studio Team Services
Figure 24-31: Test Planning in TFS
25 Databases
Almost any kind of software program uses a database for back-end storage, e.g., Facebook, etc.
The main focus in this chapter will be Microsoft SQL Server. For more information about database
systems, please see [25].
Figure 25-1: SQL Server
250
251 25 Databases
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
252 25 Databases
We can use a lot of different tools to create such ER diagram. In this document I will only focus on
the following:
• MS Visio
• ERwin
25.2.1 MS Visio
In Figure 25-4 we see a typical ER diagram created in Visio.
Figure 25-4: ER Diagram Example
25.2.2 ERwin
ERwin is a very good tool for creating ER diagrams, but it is expensive. But there exists a free
edition called “CA ERwin Data Modeler Community Edition” – this is a free edition that contains a
subset of the standard product.
In Figure 25-5 we see the same database model in ERwin as the example shown in Figure 25-4.
253 25 Databases
Figure 25-5: Database Modelling with ERwin
SQL is a A Database Computer Language designed for Managing Data in Relational Database
Management Systems (RDBMS). In SQL we have 4 different types of queries:
• INSERT
• SELECT
• UPDATE
• DELETE
These are refered to as CRUD – Create (Insert), Read (Select), Update and Delete.
• 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, ...)
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 Team Foundation Server have built-in
functionality for Unit Testing).
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
4. etc.
Note! Some of the more advanced test features in Visual Studio is only availible in the Ultimate or
Premium editions.
255
256 26 Unit Testing
Figure 26-1: Unit Test Project used in Visual Studio
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace BankTest
{
[TestClass]
public class BankAccountTests
{
[TestMethod]
public void TestMethod1()
{
…
}
…
}
}
[TestMethod]
public void Debit_WithValidAmount_UpdatesBalance()
{
// arrange
double beginningBalance = 11.99;
double debitAmount = 4.55;
double expected = 7.44;
BankAccount account = new BankAccount("Mr. Bryan Walton",
beginningBalance);
// act
account.Debit(debitAmount);
// assert
double actual = account.Balance;
Assert.AreEqual(expected, actual, 0.001, "Account not debited
correctly");
}
We get an overview of all the Tests in the Test Explorer (Figure 26-2):
Figure 26-2: Test Explorer inside Visual Studio
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 Team Foundation Server together with Unit Testing in Visual Studio you can alos choose
to fource Unit Testing before you are allowed to check-in the code.
Example:
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).
Figure 26-3: Code Coverage in Visual Studio
26.4 Exercises
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
27 Deployment in Visual
Studio
Is it a Generic Software Product or a Tailor-made Software Solution?
– Generic Software:
– Many Customers
– Tailor-made:
– The Developer Company typically installs the software (at least server-side
components)
Different Deployment/Installation preparations required depending on what type of Apps you are
Developing.
Desktop Apps
– You are use the Setup in order to install the software on all the clients
– Mac: You can deploy to Mac App Store, Windows 8: You can deploy to Windows
Store
Web Apps
260
261 27 Deployment in Visual Studio
• Easy, simple to deploy new versions, bugfixes, etc. (Customer dont need to do
anything)
• But make sure you 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)
• InstallShield Professional/Premium
– The WiX toolset builds Windows installation packages from XML source code.
– Used by e.g., Microsoft to create Setup packages for Office, SQL Server, Visual
Studio, etc. Apple, etc. also use it.
• Inno Setup
• etc.
• ClickOnce Deployment. Publishing Desktop Apps to a Web Server. Users can then install
them with a single click.
• In the New Project dialog box, expand the Other Project Types node, and then choose the
Setup and Deployment node.
• In the template list, choose Enable InstallShield Limited Edition, and then choose the OK
button.
• In the browser window that opens, read the instructions, and then choose the Go to the
download web site link.
In Figure 27-1 we see InstallShield Limited Edition and how it integrates into Visual Studio.
Figure 27-1: InstallShield Limited Edition
Figure 27-2: WiX in Visual Studio
Part 4 : Additional
Resources
In this part additional resources, references and appendices are available.
265
28 Tutorials
If you want to go more in details on some of the topics in this document, please see the following
Tutorials:
http://home.hit.no/~hansha/?page=tutorial
http://home.hit.no/~hansha/?tutorial=software_development
Here you will also find lots of hands-on exercises and training resources, e.g.:
http://home.hit.no/~hansha
266
29 Glossary
Below we will give a short overview of some important topics in software development.
Term Description
Agile Manifesto The philosophy behind Agile methods is reflected in the Agile Manifesto.
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 of 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 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.
267
268 29 Glossary
Dog-fooding Computer software company uses 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
interact with.
HMI Human Machine Interface. Another term for Graphical User Interface.
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.
SCC Source Code Control or Version Control. A version control system keeps
track of all work and all changes in a set of files. Allows several
developers (potentially widely separated in space and time) to collaborate
and share code.
TFS Team Foundation Server. TFS is a Source Code Control (SCC), Bug Tracking,
Project Management, and Team Collaboration platform from Microsoft
References
[1] I. Sommerville, Software Engineering, 9 ed.: Pearson, 2010.
[11] K. Schwaber and J. Sutherland. (2011, The Scrum Guide. Available: scrum.org
[12] E. J. Braude and M. E.Bernstein, Software Engineering: Modern Approaches, 2 ed.: Wiley, 2011.
[16] F. Tsui, O. Karam, and B. Bernal, Essentials of Software Engineering, 3 ed.: Jones & Barlett Learning,
2014.
270
271 References
E-mail: [email protected]
Blog: http://home.hit.no/~hansha