Software Engineering Study

Notes
1.1. Notes
Information technology concepts

Information technology (IT) combines hardware, software and

telecommunication systems to form systems that are able to process
relevant information. This information is used to support business
operations, improve productivity and help managers make decisions.

Systems analysis and design forms an essential part of IT. Systems

analysis and design is a process of analysing an organisation’s business
strategy and designing an information system that will use hardware,
software, data, processes and people effectively in order to meet the
requirements of the business objectives. A systems analyst is someone
who is involved in the planning, analysis and implementation of an
information system.

In order for the information system to be effective, it must conform to the

customer’s and to the organisation’s expectations.

A business model is a graphical representation of an organisation’s

business functions. The business functions are made up of business
processes that perform specific tasks, for example, sales, marketing and
accounting.

A business process describes specific events, tasks, and desired

outcomes and results.

Systems analysts are able to represent an organisation’s operations and

information requirements by using a process called business process
modelling.

Information system components

A system consists of a set of components that interact with each other to

achieve a desired goal. All the components in the system work together to
perform a task or function.

Every system exists within a certain environment and a system

boundary separates the system from its environment. The system
boundary determines where one system ends and another begins. It also
determines the connections between the system and the environment.
An information system is a system that allows businesses to manage
their data and information.

A mission-critical system is a system without which the system cannot

function. Systems that control air traffic at airports could be considered
mission-critical systems.

Data relates to facts that describe objects within the information system.
Within an organisation, data would be the facts describing the
organisation’s staff, the business objectives, sales figures and anything
that relates to the organisation and how it functions.

Information is data that has been processed to produce meaningful

output. Information may also be used to detect trends or patterns that
could benefit the organisation.

The key components of an information system are:

 Hardware
 Software
 Data
 Processes
 People

Figure 1 shows the components of an information system:

Figure 1 – Key components of an information system

Hardware
Hardware is the physical layer of the information system, and includes
devices such as computers, servers, keyboards, networks,
communications equipment, scanners and printers.

Software

Software refers to the programs or applications that users or hardware

use to run the computer or carry out a specific task. There are two types
of software:

 System software includes the operating system, the device

drivers that interact with the hardware, and various utilities.
 Application software consists of programs designed to process
available data, support users and carry out the functions of the
business. Application software can include spreadsheets, database
management systems and payroll systems.

Data

Data refers to the raw material (facts) that an information system will
process and use to produce useful information.

Processes

Processes are the functions that are performed by the information system
users or by the information system itself. Typical processes of an
information system can include verification, updating and printing.

People

People who interact with the system are classified as users or end
users, and can include internal or external users. For example, in an
online retail organisation, internal users typically include managers,
sales staff, IT technicians, etc. External users can be customers who log
on to the retail website and place orders.

The system’s input and processing operations must meet the users’
requirements in order for it to be successful.

Information system

An information system processes data to produce useful information. For

instance, in Figure 2, a pet store organisation might have a database that
stores data in a requirements table about the food supply that a pet
needs. Data about the food supply, such as brand name, description and
the amount of stock available, is stored in the supply table. The
organisation’s information system is able to retrieve data from both tables
and determine whether more stock is required, and whether the stock
available satisfies the amount required by the pet.
Figure 2 – Data in tables used by the information system

IT company types

We can classify most IT companies as one of the following general types:

 Internet-dependent (dot-com): conduct their business online using a

commercial website, e.g. [Link].
 Product-oriented: focus on product manufacture and sales, e.g. a
soft drink or furniture manufacturer.
 Service-oriented: offer a service to the public and may sell products
supplied by other companies, e.g. airlines, telephone companies and
certain retail stores.
 Brick-and-mortar: conduct their business from a physical location.

Internet-based commerce, or e-commerce

Internet-based commerce is a business sector that has been growing

rapidly in recent years. It is more commonly known as e-
commerce (electronic commerce) or I-commerce (Internet commerce)
and includes both B2C (business-to-consumer) and B2B (business-to-
business).

Many organisations, both large and small, are employing e-commerce in

their business strategies to reach the wider consumer market. In doing so,
e-commerce is changing the way consumers purchase goods.

This means that businesses need new business models. For example,
consumers would traditionally visit a retail store to make a purchase. In
order for the customer to make that same purchase over the Internet, a
different business model is required to deal with different marketing and
advertising strategies and profitability issues.

For an organisation to conduct business over the Internet successfully, it

needs to develop an interface that is secure, powerful and reliable.

B2B transactions already account for the largest transaction volumes and
are predicted to increase rapidly in the future as technology improves.
When B2B first started, Electronic Data Interchange (EDI) was used by
companies to share information (from one computer to another), using
traditional telecommunication networks. More recently, the use
of Extensible Markup Language (XML) has proved to be a popular
data exchange format which allows web-based communication between
different hardware and software environments, using a standard web
protocol.

Information system types

An organisation may contain many information systems. Many large

organisations need different types of information systems. We can classify
information systems as one of the following:

 Enterprise computing systems

 Transaction processing systems
 Business support systems
 Knowledge management systems
 User productivity systems

Next, we briefly discuss each type of information system.

Enterprise computing systems

Enterprise computing systems:

 Support organisation-wide data management requirements.

 Improve efficiency.
 Reduce costs.
 Improve security.
 Make use of Enterprise Resource Planning (ERP) applications to
supply cost-effective support for management and users throughout
the company.

Examples of enterprise computing systems include credit card payment

and airline reservation systems.

Transaction processing systems

Transaction processing systems:

 Process data applicable to day-to-day business operations.

 Are normally mission-critical systems.
 Involve large amounts of data for processing.

Examples of transaction processing systems include customer invoicing,

accounts receivable and warranty claims processing.
Business support systems

Business support systems:

 Provide work-related information that supports company staff in

their daily tasks.
 Help staff to improve decision-making by using decision support.
 Often work in conjunction with a transaction processing system, by
recording statistical information on sales volumes, customer
purchasing trends, stock levels, etc.
 Use new technologies for data acquisition, such as radio frequency
identification (RFID) tags to track product items.

Knowledge management systems

Knowledge management systems:

 Are also known as expert systems.

 Make use of a database of information called a knowledge base.
 Allow users to search the knowledge base by entering key words or
phrases.
 Use a technique called fuzzy logic, which allows inferences to be
made on the information being searched, using patterns or
relationships.

User productivity systems

User productivity systems:

 Improve the productivity of employees at all levels.

 Enable the easy sharing of information within or between
companies.

Examples of user productivity systems include email, voice mail, fax,

video conferencing, word processing, desktop publishing, company
intranets and high-speed Internet access. More often than not, most
organisations need information systems that combine all of the features of
the systems mentioned above.

Organisational structure

In a typical organisation (see Figure 3) the operational employees report

to lower and middle management, and they, in turn, report to top
management. In a corporate organisation, the top management have to
report to a board of directors elected by the shareholders.

It is important for the systems analyst to understand the organisational

structure fully in order to determine who is responsible for business
processes and decisions, and what information is required.
 Figure 3 – Organisational structure

Top management

Top management devise long-term strategic plans that define the

organisation’s overall mission and goals. Strategic plans determine the
organisation’s future growth, any issues regarding its survival, and future
long-term IT plans.

Middle management and knowledge workers

Middle managers develop tactical plans, which are short-term plans to

meet business goals that usually range from one month to one year.
Middle managers require more detailed information than top
management, but less detailed information than lower management.

Knowledge workers are professionals, essential to carrying out tasks that

support the day-to-day functioning of the company.

Supervisors

Supervisors implement day-to-day operational plans, and oversee

operational employees.

Operational employees

Operational employees use transactional processing systems to perform

their tasks.
Tools and techniques used by the systems analyst

The systems analyst must be able to gather information from users,

managers, IT staff and other employees in order to develop a systems
design that satisfies everyone’s requirements. Analysts use their
knowledge of the various tools and techniques to present their design
ideas.

Some of these tools and techniques are described here after.

Modelling

Modelling techniques use graphical representations to describe concepts

or processes. The following types of models exist:

 Business or Requirements model: describes business functions.

 Data model: describes the design and structure of data.
 Object model: illustrates real world objects that affect the system.
 Network model: shows the design and protocols of
telecommunication links.
 Process model: describes the systems logic and processes.

Computer-aided systems engineering

Computer-aided systems engineering (CASE) is a technique that

makes use of CASE tools, which are powerful software programs that
automate many routines.

Overview of systems development methodology

When developing an information system, the analyst needs to choose a

methodology. The more traditional approach is structured
analysis, whereas object-oriented analysis is the relatively newer
method. Both methods are popular and each strategy has its own
variations. Organisations may choose to use these methodologies, they
may develop their own strategy or they may implement strategies offered
to them by vendors or consultants. IT experts agree that no methodology
or strategy is the only option. Systems analysts should take the different
strategies and their strengths and weaknesses into consideration.

Structured analysis

Structured analysis uses a developmental approach called the systems

development life cycle (SDLC).

In the 1960s, most systems were based on individual data files being
processed on a mainframe computer. It was during this time
that structured analysis evolved and became popular. Structured
analysis became a process-centred technique, because it demonstrated
processes that could convert data into useful information. Structured
analysis views processes and data as separate components.

Object-oriented analysis

Whereas structured analysis views data and processes separately, object-

oriented analysis (OO) uses objects that are a combination of data and
the processes that manipulate this data. Using OO methods, analysts can
model concepts such as business processes and operations. When
analysts model the business processes and operations, they produce
objects that are real world representations of things, people and events.

Many analysts believe that the OO approach is more flexible, efficient and
realistic than structured analysis in today’s business environment. OO also
allows for a far easier conversion to programming languages such as Java,
C++, C# and Visual Basic.

The systems development life cycle

As mentioned before, structured analysis and object-oriented analysis use

a technique called the systems development life cycle (SDLC), which
implements a sequence of phases. These phases plan and manage the
development of the system. They include activities that are usually
performed by developers, irrespective of the type of methodology that is
being used. The five phases of the SDLC are:

1. Systems planning
2. Systems analysis
3. Systems design
4. Systems implementation
5. Systems operation and support

Systems planning

In order for any project to begin, the IT department must first receive a
formal request, called a systems request. This request can be either to
develop a new system or change an existing one. If the request is
approved, then the planning of the project can begin.

During the systems planning phase:

 The objective is to establish the scope and description of the

business problem.
 This is accomplished by doing a preliminary investigation, also
called a feasibility study, and the result or deliverable of this
investigation is a preliminary investigation report.
  The preliminary investigation report contains business
considerations, costs, benefits and recommendations based on
operational, economic and technical feasibility.
 Based on the findings of the preliminary investigation, a decision will
be made on whether or not to proceed with development.

In some cases, reviewing the business process is more appropriate than

an IT solution. If a decision is made to continue with development, the
phase that follows is systems analysis.

Systems analysis

In the analysis phase, the systems analyst needs to understand the

business requirements and processes fully in order to build a logical
model of the new system. During the analysis phase:

 The first stage is requirements modelling, which defines the

business processes. Systems analysts should work closely with
users to determine these processes.
 Analysts must determine what the users want and expect from the
new system.
 Analysts carry out data modelling, process modelling and object
modelling.
 The deliverable for this phase is the system requirements
document, which contains some of the same elements as the
preliminary investigation report, but includes more detail.

Systems design

The objective of the design phase is to design a blueprint of the new

system that satisfies the requirements specified in the analysis phase,
irrespective of the development option that is chosen. During systems
design:

 Analysts identify all the input, output, interfaces, and internal and
external controls, as well as automated and manual tasks.
 User and management participation and contribution is very
important so that the design correctly represents the requirements
specified in the analysis phase.
 The deliverable of this phase is the systems design
specification, which contains the final systems design.

Systems implementation

During systems implementation, the information system is:

 Coded
 Tested
 Documented
  Installed
 Supported on the system

The deliverable of this phase is a fully functional and documented

information system, which is ready for use.

Systems operation and support

During systems operation and support:

 IT staff maintain the system.

 Maintenance fixes errors and adapts the system if there are any
minor changes to be made.
 New benefits and features that will enhance the system are added.

A system that is well designed will be reliable, maintainable and

scalable. Scalable means that the system can be adapted and expanded
to deal with any new requirements.

Systems development life cycle models

Traditionally, the SDLC is viewed as a waterfall model (see Figure 4). The
end of each phase produces a result, which is known as an end product or
deliverable. This is the input for the next phase. It is known as the
waterfall model because once a phase is completed, the development
team will not return to that phase, much like water that only runs in one
direction down a waterfall.

Figure 4 – Waterfall model

However, when developing an information system, it is generally

unrealistic to expect that all the requirements for each phase will be
correctly completed on the first attempt. For this reason, there are usually
many revisions to the requirements, which means revisiting the earlier
phases. For example, certain requirements may not be discovered during
the analysis phase, but rather during the design phase. In this case,
analysts need to revisit the analysis and, possibly, the planning phases.

In a real world scenario, the phases in the SDLC are revisited a number of
times. As a result, there is an alternative to the SDLC waterfall model
known as the iterative model. The iterative model (see Figure 5) shows
the iterative or repeating nature of the phases. To find accurate
requirements for each phase means that users, managers and system
developers must be involved.

Figure 5 – Iterative model

Systems development guidelines

When developing an information system, there are a few basic guidelines

to bear in mind:

 Follow an overall development plan.

 Involve the user in the development process as much as possible.
 Identify the major milestones.
 Establish checkpoints between milestones.
 Be flexible within the framework of the development plan.
 The cost and benefit information must always be accurate and
reliable.

Information technology department

The purpose of an IT department is to develop and maintain an

organisation’s information system. Different organisations structure their
IT departments in different ways, with varying levels of responsibility. For
example, in a small business, the IT department could be managed by a
single person, while in a large organisation many people are required to
run the department.

The IT department provides technical support. This includes six main

functions, namely application development, systems support, user
support, database administration, network administration and web
support.

Figure 6 shows a graphical representation of an IT department and its

functions.

Figure 6 – Six main technical support functions

2.1. Notes
About the unit

In this unit, we cover the first phase of the systems development life
cycle, systems planning. Here we emphasise the importance of
understanding business operations and requirements, how IT projects
support an organisation’s overall strategic plan, and how information
systems projects are started and reviewed. Figure 7 shows where the
planning phase fits into the SDLC.
Figure 7 – The planning phase

Strategic planning

Strategic planning focuses on the long-term goals of the organisation

(which can span years or even decades), the strategies on how to go
about achieving the goals, and establishing what resources the
organisation needs to achieve the goals.

During strategic planning, top management asks a series of questions

concerning the following:

 What are the strengths of the organisation and the strengths of

the IT systems?
 Where do the weaknesses in the organisation and IT infrastructure
lie?
 Are there major opportunities, and how can the organisation take
advantage of them?
 What threats does the organisation face, and how can they
overcome them?
 This is known as a SWOT (strengths, weaknesses, opportunities and
threats) analysis.

After drawing up the mission statement, the organisation needs to

establish goals that will fulfil the mission. Goals are long-term tasks that
the organisation needs to complete. These goals can span years or even
decades. In order to achieve these goals, they are broken down further
into a list of objectives. Objectives have a shorter time frame than goals,
and are usually measured monthly, quarterly or half-yearly. The
organisation achieves its objectives during day-to-day operations.

Factors that affect a systems project

Internal and external factors always affect any business decision. The
following two sections discuss these factors.

Internal factors that affect a project

The following are internal factors that can affect a project:

 User requests: User requests for IT support increase as more users

depend on information systems more extensively to help them carry
out their responsibilities.
 Top management: Most major information systems projects are
undertaken primarily due to directives from top management.
 IT department: IT staff may make recommendations for changes on
the systems they are working on due to their knowledge of IT
operations or due to new technological trends.
 Existing systems: Older systems, called legacy systems, eventually
need to be replaced by new technology when they can no longer
support the company’s needs.

External factors that affect a project

The following are external factors that can affect a project:

 Technology: Advances in technology affect companies and society

and influence business operations.
 Customers: Customer service is very important to any organisation.
Systems that interact with customers have the highest priority in
most firms.
 Economic: The performance of the economy strongly affects the
way an organisation manages its information. Research and
planning are very important when trying to forecast the business
cycle so that organisations can plan and prepare for the future.
 Government: National and local government regulations will affect
the manner in which a corporation designs its information systems.
 Competitors: The type of information system that a competitor is
using may have an effect on an organisation’s decision to enhance
or upgrade their own information system.

Reasons for starting an information systems project

The first step in pursuing a new information systems project is to draw up

a systems request. A systems request could propose new features or
corrections for an existing system, or even an entirely new information
system. All systems requests must be justified and reasonable.

The main reasons for proposing a systems request are (see Figure 8):

 Improved service
 Better performance
 More information
 Stronger controls
 Reduced costs

Figure 8 – Common reasons for systems request

Systems request forms

Systems request forms are special forms that an organisation draws up

to determine the nature and urgency of the request. The systems request
form needs to be easy to understand, must have clear instructions on how
to complete it and must state whether further documents are required.

The systems analysts and IT managers will evaluate the completed

systems request form and determine the necessary resources (e.g. staff
and time) that are required to conduct a preliminary investigation. After
the evaluation of the request, a committee or designated manager will
decide whether or not to go ahead with the preliminary investigation.

Overview of feasibility

Before any project is undertaken, it must undergo a series of tests to

determine whether it will be beneficial and worthwhile to the organisation.
This is called a feasibility study. The feasibility study is an extremely
important part of any systems project because it establishes if the project
will be worth the effort. Feasibility is measured in terms of three criteria,
namely operational feasibility, technical feasibility and economic
feasibility.

Whenever the IT department receives a systems request, they do an

initial examination to see if the system needs further study. There are
certain factors that play a part in this decision-making process.

A systems analyst needs to ask three important questions regarding each

request:

 Is the proposal operationally feasible?

 Is the proposal technically feasible?
 Is the proposal economically feasible?

The feasibility study provides management with vital decision-making

information. If the request is worthwhile and needs to be implemented, an
investigation will begin that will overlap with the next phase in the SDLC,
the analysis phase.

Figure 9 illustrates the three types of feasibility:

Figure 9 – Types of feasibility

Technical feasibility

There are certain questions that the IT department needs to consider

when determining the technical feasibility of an organisation:

 Does the organisation have the technology available to complete

the project?
 Are there people with the technical skills available to work on and
complete the project in the specified time?
 Will any new hardware integrate and interface with the current
system?
  Will the system be able to handle future increased transaction
volumes?

If even one of the factors cannot be met, the project is not technically
feasible.

Operational feasibility

Operational feasibility determines whether the organisation will use the

system effectively after the request has been fulfilled. It is possible that
users of the new system may show resistance, or may struggle to use the
system effectively. In this case, the project is not operationally feasible.

Users should be involved in the project from the start to avoid any
resistance that may occur later on in the development process. This also
ensures that their needs are being met and that they become familiar
with the system early on, making it easier for them to learn to use the
system.

Economic feasibility

In order for a request to be economically feasible, the expected benefits of

the system must be greater than the predicted costs. The costs of the
system can be once off or ongoing. One of the main issues that the
organisation must consider is the total cost of ownership (TCO). TCO is
the overall cost of running the system, which includes:

 Ongoing support
 Maintenance
 The cost of obtaining the necessary requirements

When determining whether a system will be economically feasible, the IT

department must first determine the tangible and intangible benefits of
the system.

Tangible benefits are measured in currency, e.g. rands. Tangible

benefits occur when the organisation’s expenditure decreases or the
revenue increases, or a combination of the two. Examples of tangible
benefits are:

 Improving system performance to speed up transaction processing.

 Automating tasks to improve efficiency and reduce the number of
staff required.

Intangible benefits are difficult to measure accurately in monetary

terms. Intangible benefits become more apparent as the system is used.
Examples of intangible benefits are:

Improved customer satisfaction and service

  Improved organisational image
 Employee satisfaction

How to evaluate project requests

The review committee receives many requests for projects. However, not
all are accepted. They give priority to projects that:

 Carry the least cost

 Offer the most benefits
 Have a short time frame for development.

Other factors that affect the prospects of a project include:

 Improved customer service

 Reduced costs
 Improved organisational image
 Increased income
 Available resources
 Tangible factors
 Intangible factors

Often the intangible factors play a more important role in the decision to
accept or reject a systems request. If the request is proven to be feasible
after the different tests have been completed, the project can be
undertaken.

Preliminary investigation

The systems analyst needs to compile a recommendation on whether it is

feasible to carry out a specific systems request.

The analyst gathers facts about the current system and the requirements
for the new system by interviewing management and users of the system.

The systems analyst has to explain what the project entails, the
responsibilities of each individual, and invite comments and questions on
the procedure.

All information gained during this investigation is included in a report that

will be reviewed by management.

Steps involved in a preliminary investigation

The systems analyst usually follows a sequence of steps when conducting

a preliminary investigation. However, these steps can change, depending
on the type of request, the size of the project and the urgency of the
request. Figure 10 illustrates these steps.
Figure 10 – Steps in a preliminary investigation

Step 1: Understand the problem or opportunity

Systems analysts normally formulate a business profile for new projects or

projects that involve major changes to the current system. It is important
to understand how a new or modified system will affect users, company
operations and other systems connected to the system to be updated.

Step 2: Define the project scope and constraints

The systems analyst needs to determine the project scope (the

boundaries of the project). The boundaries need to be as specific as
possible so that there is a clear understanding of what the project includes
and what it does not include.

Another important reason to define the scope is to avoid project

creep. Project creep is a process in which the scope of the project
gradually expands without any authorisation, because the boundaries
were not clearly defined.

When defining the project scope the systems analyst must define the
systems constraints. A constraint is a situation that must be satisfied or
a result that the system must achieve. Hardware, software, cost, time,
national law and organisational policy are all factors that could define the
project scope. For example, a solution for an accounting system or an
online web security system must follow certain tax and privacy laws.

The following types of constraints exist:

  Present or future constraints
 Internal or external constraints
 Desirable or mandatory constraints

The systems analyst must identify all applicable constraints as early as

possible in order to avoid problems later on in the project’s lifecycle.

Step 3: Engage in fact finding

Fact finding makes use of many techniques. Fact finding can take as little
as a few hours, or be as long as several weeks, depending on the type of
information needed to investigate the request. Minor changes may only
require the analyst to call a user, or even evaluate a user, whereas a
major addition to a system would require many interviews with users, and
to a lesser extent, the managers who are involved in the system. This may
take many weeks.

The following is a list of the main fact-finding techniques:

 Analysis of company organisational chartsOrganisational

charts show the relationships between departments in the company,
the individuals who work in a department and their job titles. This
helps the analyst to determine which employees to interview.
 InterviewingInterviewing is the primary method of gathering
information during the fact-finding stage of the investigation. The
systems analyst needs to interview managers and supervisors, as
well as users and operational staff. The analyst should prepare a
standard set of questions beforehand to present to the interviewees.
 Reviewing systems documentationThe analyst must ensure that
the systems documentation is accurate and up to date.
 Observing the current system in operationThe analyst may
choose to observe staff working on the system, or follow the paths
taken by documents or reports through the system.
 Conducting surveysIn some cases, the systems analyst will
conduct a survey to obtain general information from all employees,
rather than conduct interviews, which are more time consuming.

Step 4: Determine project benefits

During this step, the systems analyst has gathered sufficient information
about the economic, technical and operational feasibility of the project to
make a determination about the project’s benefits.

Step 5: Estimate the time and cost for development

Once the systems analyst has worked out the project benefits, he or she
can make estimates for the time and cost for the systems analysis phase
of the SDLC.

The analyst carries out the following tasks:

 Information gathering and analysis.

 Conducting interviews and surveys.
 Determining the cost and time involved in analysing the information
and preparing a report.
 Determining the overall cost estimate for the project.
 Determining the overall time estimate for the project.

Step 6: Present results and recommendations to management

After the analyst has completed all the steps, he or she should be in a
position to make a decision based on the information.

It may be that further development is unnecessary, or that a different plan

of action may be needed instead of development. Where minor changes
are needed, full development need not continue. In other cases, it may be
necessary for development to continue to the next phase.

The deliverable of the preliminary investigation is the preliminary

investigation report (PIR), which the analyst hands to management.
This includes the evaluation of the systems request, cost benefit analysis
and the systems analyst’s recommendation.

3.1. Notes
About this Unit

The systems analysis phase is the second phase in the SDLC. In this
phase, the analyst develops a logical, business-oriented model of the
proposed system. Figure 11 shows where the systems analysis phase falls
within the SDLC.
Figure 11 – The analysis phase

Overview of the systems analysis phase

Once a system request is granted, the next phase in the systems

development life cycle is systems analysis. The objective in this phase
is to have a full understanding of the proposed project. The systems
analyst needs to understand the project to ensure that it supports the
business objectives and that a solid foundation is in place for the next
phase, namely systems design.

Four main activities take place during the systems analysis phase:

 Requirements modelling
 Data and process modelling
 Object modelling
 Deciding on a design strategy

Each of these activities will be discussed in this unit.

Requirements modelling

Requirements modelling is the process of gathering facts about a

systems project and creating models and documentation that will be used
to design and develop the system.

Systems development methods

Previously, IT departments used to develop systems independently and
only consulted with the users when their input, consent or approval was
absolutely necessary. Today, teams, including users, managers and IT
staff actively contribute towards the development of the system. Joint
applications development (JAD), rapid applications development
(RAD) and Microsoft Solutions Framework (MSF) are some systems
development methods that require people to work in teams.

JAD focuses on the group participating in fact-finding activities and

requirements modelling. JAD is not linked to any specific development
methodology, so systems analysts often use it when group interaction or
input is required.

RAD and MSF are methodologies that provide an overall framework for the
system and are more intensive than JAD.

Modelling tools and requirements

In order to help users, managers and systems analysts better understand

the current or new system, they use models to conceptualise the system
graphically without using technical language. These models represent
various stages in the development process. Unified modelling
language (UML) and functional decomposition diagrams (FDD) are
both modelling methods that analysts use during requirements modelling.
UML shows the interaction between the user and the system. FDDs
illustrate how to define business functions and processes.

Fact finding and modelling are closely related. Once analysts have
gathered the facts, they create models to help to clarify any issues, which
may in turn lead to more fact finding and modelling. UML is discussed in
detail later in this module.

System requirements

A system requirement is a feature or element that must be included in

the system. This requirement or characteristic is mandatory, because it
satisfies business and user requirements. This is done in order to analyse
the problem for which the system is to solve. The system requirements
describe what users need from the information system. Analysts use the
system requirements to check whether the completed system is
acceptable and meets the requirements.

System requirements can fall into the following five categories:

 Inputs
 Outputs
 Processes
 Performance
 Controls
Inputs are any information or data that needs to be entered into the
system. Examples of inputs are employee details, barcoded product
information and customer invoice details.

Outputs are what the system generates as a result of a process, for

example, daily, monthly or quarterly reports.

Processes are common tasks that the system must complete. Examples
of processes are:

 A library management system may not lend additional items to a member

who has overdue items.
 A finance system must be able to interface with the payroll system.
 A retail system must be able to calculate the tax percentage of all
purchases.

Performance requirements demand that the system operates and

functions in a manner that is fast, efficient and satisfactory to the users.
An example of performance may be that the system must be operational
seven days a week, 365 days a year, or that the system must support
multiple user access.

Controls are rules or conditions that the system must fulfil in order for
the system to continue with a task. Controls ensure that the system
remains error-free and that only authorised users have access to the
information. Examples of controls are logon, authorisation and error-
handling controls.

Scalability and total cost of ownership (TCO)

Scalability describes a system’s ability to adapt as business

requirements change over time. The system should be able to upgrade its
capabilities as hardware and software are upgraded.

The total number of transactions has a great impact on operational costs.

If the total number of transactions increases beyond the system’s
capabilities, the system will cost more to maintain.

Systems analysts must also determine the indirect or hidden costs (e.g.
the amount of electricity needed for the system or air-conditioning for
server rooms). These costs add to the total cost of ownership (TCO).
TCO has to be determined so that management is aware of the hidden
costs involved.

Information gathering

The concepts of system requirements, scalability and TCO are important

to bear in mind when gathering information or fact finding.
Conducting interviews, reviewing documentation, observing the system
and users, preparing surveys, sampling and researching are some of the
techniques that analysts use to gather facts.
The systems analyst has to develop a strategy to uncover the facts. The
analysts conduct fact-finding techniques, document the results and use
the results to prepare a system requirements document. They then
present this document to management for review.

Guiding questions: Who, what, when, where, how and why?

Analysts ask six typical questions, namely who? what? when? where?
how? and why? These questions are an important guide in fact finding.

For example:

 Who is responsible for carrying out certain functions? Why are they in
charge? Who else can perform that function?
 What security mechanisms are in place? What processes are performed?
Why are they performed?
 Where is data stored? Where are day-to-day operations performed? Why
are they performed there? Where else could they be performed?
 When are tasks carried out? Why are they carried out at that time? Would
it be more efficient to do it at another time and why?
 How is the task performed? Why is it performed in that fashion? Could it
be better, more efficient and more cost effective if performed in a different
fashion?

Interviews

Interviews are an important part of fact finding. An interview is a planned

meeting in which someone will gain information from another person by
asking questions or having discussions. When planning an interview, there
are seven steps to follow:

1. Identify who needs to be interviewed: In order for the analyst to

get an overall understanding of the current methods or systems that are
in place, they interview key users who interact with the system. During
analysis, it is important to talk to people from all organisational levels.

2. Establish the interview objectives: A good interview needs to be

structured properly and include a list of objectives and subject areas that
need to be discussed.

3. Construct interview questions: There are three types of questions

that an interviewer can ask, namely closed-ended questions, open-ended
questions and range-of-response questions.

Closed-ended questions expect concise responses. In other words, the

answers are restricted. This type of questioning is useful when verifying
facts or when specific information is required, for example:
  Do all employees currently have computers?
 How many hours of training do new staff members receive?
 Are the products barcoded before being sent out?

Open-ended questions allow people to respond in an unstructured

manner. These questions help to gain a deeper understanding of business
processes, for example:

 What do the operational employees rely on to perform their tasks?

 How do they perform their tasks?
 Why do they do it in that way?

Range-of-response questions are similar to closed-ended questions in that

the interviewee evaluates or rates something given a limited range of
options, for example:

 On a scale of 1 to 10, with 1 being inefficient and 10 being very efficient,

how efficient would you say the library system is?
 What is the level of importance of stationery requisitioning? Low, medium
or high?

4. Prepare for the interview: An interview is an important meeting and

careful planning needs to go into its preparation. The interviewee must be
informed of the date and time of the meeting in advance. Managers need
to be kept informed of their staff members’ interview times and dates.
Employees should also be provided with any questions that require
detailed information so that they can prepare for the interview.

5. Carry out the interview: After establishing the interview objectives,

determining whom to interview, and developing questions, the analyst
needs to develop a plan or agenda for the interview. The analyst should
introduce him- or herself, describe the proposed project, and explain what
he or she wishes to accomplish in the interview.

The analyst should ask the questions in the order that they were
prepared. The interviewee should have enough time to think about the
question before being asked to reply.

6. Document the interview: Taking down notes during an interview is

advisable, although this should not distract the interviewee.

7. Evaluate the interview: Interviews are evaluated to assess their

success and to determine if all necessary information was obtained.

The analyst can then decide if he or she needs any further information,
which may be obtained from other interviews, or through a different fact-
finding technique.

Reviewing documentation
Every system should have systems documentation. Reviewing the
systems documentation will assist the analyst in his or her understanding
of how the system is supposed to work. However, the documentation
might be outdated or the system procedures may have been modified, so
it is advisable to get copies of current forms and documents.

Observing the system and users

Being able to see the system in operation gives the analyst a better
understanding of the system processes. Observation also allows the
analyst to compare what is said about procedures during interviews to
what happens in practice.

Preparing surveys

A survey or questionnaire is a document that contains a set of

standardised questions. The analyst can send this document out to many
people in an organisation. The information gained from questionnaires
greatly helps the analyst in the fact-finding process, as questionnaires
contain various question/response formats.

The following are survey techniques:

 Sampling: Sampling is a process whereby examples of actual documents

are collected to aid in the study of a system. Samples could be reports,
error logs, records, requests and various other types of forms.
 Researching: Researching and reviewing documents, journals, books and
the Internet to get background and technical information, as well as news
about trends and developments in industry can provide accurate
information.
 Site visits: The purpose of a site visit is to observe the system in
operation at different locations.

Documentation

During systems development, it is essential to keep an accurate record of

all interviews and fact-finding results. When gathering information, the
analyst may forget complex details or overlook the importance of
something. Therefore, it is important to write everything down. There are
four basic principles that an analyst should follow when documenting
findings:

 Document information as soon as it is obtained.

 Use simple recording methods.
 Record findings so that other people can easily understand them.
 Organise documentation so that it is easy to find related documents.

There are various software programs and devices that make it easier to
document information. Some of these are:

 CASE tools
  Word processing software
 Spreadsheets
 Database applications
 Modelling software (e.g. Microsoft Visio)
 Personal Information Managers (e.g. Microsoft Outlook)
 Wireless communication devices (e.g. PDAs).

Data and process modelling

Analysts use the structured analysis approach when modelling data and
processes. Structured analysis views the system in terms of data,
inputs, outputs and the processes that act on the data. During the
systems analysis phase of the systems development life cycle, analysts
develop data and process models to show graphically how data is
transformed into useful information by the system.

The deliverable of structured analysis is a logical model of what the

system does and not how it does it. A logical model is also called
a business model, because it has to meet user requirements and
support business functions.

There are three main tools used for data and process modelling:

 Data flow diagrams

 The data dictionary
 Process descriptions

Data flow diagrams

A data flow diagram (DFD) is a graphical representation of the

movement of data to and from a system, and the processes that are
acting on the data. A DFD does not show the program logic or the actual
processing that is involved. It is merely a logical model that illustrates
what the system does (not how it does it).

Data flow symbols

There are four basic symbols that are used in DFDs. These symbols
represent data flow, external entities, processes and data stores.

There are many different styles of DFD symbols, such as the Gane and
Sarson symbol set, as well as the DeMarco and Yourdon symbol set. No
matter which version of DFDs is used, they all serve the same purpose.
This learning manual uses the Gane and Sarson symbol set.

Figure 12 shows the four basic symbols in the Gane and Sarson set, what
they mean, and an example of how each is used.
Figure 12 – Data flow diagram symbols from the Gane and Sarson symbol
set

The four symbols in the Gane and Sarson set are:

 Process symbol: A process is the action that is performed on the data

given as input to produce information as output. A process symbol is a
rounded rectangle.

 Data flow symbol: A data flow is a path showing that information moves
from one part of the information system to another. The data flow symbol
is a single line with an arrowhead.

 Data store symbol: A data store, or data repository, represents the

storage of data. A data store symbol is a rectangle closed on the left-hand
side, and open on the right-hand side.

 External entity symbol: External entities are a good indication of where

the system boundaries end, and how the system and the outside world
interact. They show the source of the data and the destination of the
processed information. An external entity is a rectangle.

A set of DFDs are top-down, graphical models of the system. Analysts

start creating a set of DFDs by first drawing a context diagram. From the
context diagram, they create a diagram 0, and then draw any subsequent
child diagrams.

Context diagrams
The first thing that an analyst does when developing a set of DFDs is to
draw a context diagram. A context diagram shows the information system
at a top level (showing very little detail), indicating where the systems
boundaries lie and the scope of the system.

Figure 13 shows an example of a context diagram for a DVD rental

system. The system keeps track of the DVDs that have been rented by
customers, the shifts that employees work, and the interaction with the
supplier.

Figure 13 – Context diagram for a DVD rental system

Diagram 0

A context diagram shows a general view of an information system and

hides the inner details of the system. In order to show the inner details of
a system, the analyst creates a DFD called diagram 0 (the digit zero, not
the letter O). A diagram 0 shows the context diagram in further detail by
including major processes, data stores and data flows. Any entities and
data flows that are shown in a context diagram are repeated in diagram 0.

Figure 14 shows an example of diagram 0 and its associated context

diagram for the DVD rental system.
Figure 14 – Context diagram and diagram 0 for a DVD rental system

Data dictionary

A data dictionary, or data repository, is a centrally located storage facility

that stores data about the organisation and information system. This
includes information about all data flows, data stores, processes, entities
and data elements. In a data dictionary, a data element (field or data
item) is the smallest meaningful piece of data. A data dictionary is able to
describe the data elements and group them into meaningful
combinations.

Examples of data elements include employee ID, commission, hours

worked and employee name. Combined data elements form records or
data structures. A record or data structure consists of a combination of
related data elements.

Records are included in data flows and kept in data stores. For example,
the data elements in the book record of a library could include ISBN, title,
author, genre, price and number of available copies.

Figure 15 shows the items that the analyst defines during structured
analysis and the creation of the data dictionary. These items have
significant relationships with each other. Data flows connect processes,
data stores and external entities. In Figure 15, you can see that data flows
and data stores are based on data structures, which, in turn, are made up
of data elements.

Figure 15 – Contents of a data dictionary

The data dictionary must document these relationships accurately so that

they are consistent with the DFDs.

The data dictionary must document all data elements, data flows, data
stores, data processes and external entities. We discuss documenting
data elements and data records below.

Documenting data elements

The analyst must document every element on the DFD in the data
dictionary. The aim of documenting data elements in a data dictionary is
to create clear and detailed information about the data and processes that
are involved in the system.

The data dictionary must document the following attributes for a data
element:

 The name or label of the element: should be standard, unique and

meaningful to users.
 Alternate names or aliases: synonyms for the standard name.
 Description: description or comments about the element.
 Element type: defines the type of values the element may hold, such as
alphabetic, numeric or character values.
 Element length: the maximum number of characters or digits an
element can contain.
 Input and output format: the format in which the element must be
entered by a user or displayed on the screen.
 Default value: the value to use for the element if one is not supplied by
the user.
 Acceptable values: the set or range of allowed values for the element.
 Source: defines where the element originates from.
 Security: identifies departments or users responsible for update
privileges on the element.
 Responsible users: users that are allowed to modify the element’s
value.
 Comments: additional notes regarding the element can be added here.

Documenting records

The data dictionary must document the following attributes for a record:

 The record or name

 An alternate name for the record
 A definition or description of the record
 The record content or description, including a list of all attributes for the
record.

Reports from the data dictionary

The data dictionary acts as the documentation warehouse for the

information system and must be centrally available. Besides documenting
the above-mentioned components, the data dictionary must also describe
the relationships between the data elements. Some of the reports that the
data dictionary can generate include:
  An alphabetised list of all the elements
 A particular data element and a list of all data flows and data stores that
use it
 A detailed report of any of the components stored in the data dictionary

Process description tools

Process description tools give an accurate picture of the processing

details for business logic that a DFD does not show. Examples of typical
process description tools are flowcharts, decision tables, structured
English and pseudocode. Modular design is the process of breaking
down a function into smaller units.

Modular design

Flowcharts most commonly use modular design to show logic. There are
three basic logical structures, also known as control structures. Modular
design makes use of a combination of control structures, which are the
building blocks of the process. The three control structures are sequence,
selection and iteration. These control structures are comprehensively
covered in the Processing and Logic Concepts and Program Design
modules.

Structured English

Structured English is a subset of Standard English (see Figure 16).

Analysts use it to describe processing logic accurately in an
understandable and organised way.

Figure 16 – Example of structured English

Structured English resembles pseudocode (which is covered in the

Program Design module). The difference between structured English and
pseudocode is that structured English focuses on describing the business
logic, whereas pseudocode is used as generic notation for the actual code
and is language independent.
Decision tables

A decision table illustrates all valid logical combinations for a set of

conditions, together with the results of those combinations. Analysts often
use decision tables to describe a logical process. Decision tables are
covered in the Processing and Logic Concepts module.

Logical and physical models

Analysts can use structured analysis tools to develop logical and physical
models for the information system. The physical model shows how the
system implements the requirements, and follows from the logical
model. The physical model is usually developed during the design phase,
and includes operational tasks and techniques.

The sequence of models

In the systems analysis phase, the analyst must fully understand the
system and the operations of the system before constructing a logical
model. Analysts sometimes create a physical and logical model of the
current system, and then create a logical model of the new system. This
process is time consuming, but it allows the analyst to gain a better
understanding of the system.

Object modelling

The next part of the systems analysis phase is object-oriented analysis,

which analysts use to view and construct a model of the system
requirements.

Object-oriented concepts

When using object-oriented analysis, the information system is defined in

terms of objects that are relevant and significant to the information
system. Objects represent real world things, such as people, places,
transactions or events. For example, if a person books a ticket to see a
movie, the person, the ticket and the movie are all individual and separate
objects.

With object-oriented analysis, the analyst looks at the information

system from an object’s viewpoint, in other words, how objects interact
with the system and how they function. The deliverable or end result of
object-oriented analysis is an object model. This object model represents
and describes the entire information system using objects and object-
oriented concepts. Programmers can transform these objects into
modules of programming code during the implementation phase of the
SDLC. The modules can be tested, reused and optimised, which means
that the modular approach would save time and reduce costs.
A major advantage of using object-oriented design is that it allows
analysts to use modular objects, which helps to reduce the number of
errors. Programmers are also able to convert the designs into code by
using an object-oriented language (e.g. Java, [Link], C#, or C++), and
include reusable modules that have already been tested and verified.

Modelling objects with UML

Whereas DFDs are used in structured analysis to describe data and

processes, the object-oriented approach uses UML (unified modelling
language) to describe the system.

UML presents and documents an information system graphically, and is

used to develop object models. UML uses a set of symbols and notation
that represent the components and relationships found within the system.
Analysts mostly use UML to develop object models and support the
analysis of an object-oriented system. UML diagrams help with analysis
because they are easy to create, read and use.

Object-oriented modelling and UML are covered in detail in Units 7 to 16

of this learning manual.

Deciding on a design strategy

The transition to systems design is the final part in the systems analysis
phase of the SDLC. It involves evaluating the software alternatives, and
preparing the system requirements document for presentation to
management.

Development environment options

The systems analyst must consider whether development will take place
in a traditional desktop environment or a web-based environment.
Although the trend is to move towards web-based systems, there are
certain conditions that the analyst must consider before deciding which
environment to use.

Web-based environment considerations

A system developed in a web-based environment:

 Is generally developed in an Internet framework, such as the .NET

framework.
 Can be run in many different hardware environments.
 Is more scalable than in a traditional environment.
 Can include additional software layers (middleware) to communicate with
legacy systems.
 Often requires less computing power to run than a traditional system.
 Involves more security issues as the application operates on the Internet.
Traditional desktop environment considerations

When developing a system for a traditional desktop environment, the

analysts must consider that:

 They need to take into account factors such as software and hardware
platforms and legacy system requirements.
 Development is normally in-house, delivered by an outside company.
Alternatively, they may purchase a software package.
 Hardware and network constraints can affect scalability.
 These systems often require more computing power to run.
 Security issues are less of a factor.

Software alternatives

The first part of the analysis phase concentrated on gathering information,

investigating the current system and creating a logical model of the
system from all the information. As the analysis phase concludes, another
aspect that the analyst must consider is the different software options and
strategies for the system (see Figure 17).

Figure 17 – Evaluating and choosing software alternatives

Organisations have three options:

 Developing an in-house system

 Buying a software package
 Customising a software package

Each of these options has its own advantages, disadvantages and cost
issues. The IT staff within the organisation would have to develop an in-
house system. However, the organisation can buy or lease a software
package from a software vendor (organisations that develop software).
These packages can be standard software or software that the vendor has
customised specifically for the organisation.
Application software types

Two types of application software are available:

 Horizontal application software: Horizontal application software is

software that many different organisations can use, e.g. an accounting
package, such as Pastel.
 Vertical application software: Only specific industries can use vertical
application software, e.g. software for banks, airlines, hospitals or car
dealerships.

Organisations often use both types of software. For example, an

organisation might use an accounting package in the finance department,
and vertical application software to handle the more complex business
needs.

Advantages of developing in-house software

The advantages of developing in-house software are:

 It can be adapted to the constraints of the existing system.

 It can be adjusted to the technology that is available in the organisation.
 It caters for specific requirements.
 There are minimal changes to the organisation’s operations.
 IT staff can maintain the system themselves.

Advantages of buying a software package

The following are the advantages of purchasing a software package:

 Reduced costs.
 Reduced implementation time.
 Upgrades and improvements are provided by the vendor.
 Recommendations on the software package can be obtained from other
companies.
 Reliability.
 Fewer technical staff are required.

Outsourcing

Outsourcing is becoming a widely used option. Outsourcing occurs when

the organisation gives a portion of an organisation’s IT workload to an
outside organisation to deal with, on either a temporary or a long-term
basis. Organisations offering this service are called service providers.

Application service providers (ASP)

Another option available to an organisation is to use an application

service provider (ASP). ASPs are organisations that specialise in IT
applications. They develop and maintain the software and organisations
then have access to the application for a certain fee.
The ASP is responsible for the running and maintenance of the application
while the organisation rents and uses it. This is known as application
hosting. The advantages of using an ASP are that the organisation needs
significantly fewer staff to maintain the system, and the organisation can
focus its resources on running the business.

The difference between an ASP and outsourcing is that an ASP rents the
application to the organisation, whereas with outsourcing, an organisation
outsources its IT tasks to an independent service provider. The
organisation does so because it cannot handle the load or because it does
not possess the experience it needs to complete the task.

User applications

User applications use business software that has been modified to

increase user productivity. It is not always necessary for an organisation
to develop or purchase an information system because it can sometimes
use a user application to meet its requirements. For example, it is possible
to set up word processors and spreadsheets according to specific user
requirements, and programmers can also create special interfaces to
assist the users in interacting with the system. User applications can be a
simple, cost-effective method to meet business requirements.

Deciding on the software options

Depending on the organisation’s decision regarding the software

packages, the design phase can either begin or be skipped altogether.

The organisation will begin the design phase if it decides to develop its
software in-house. If the organisation decides to buy or customise
software, then they need to carry out certain steps. For customised
software, a developer needs to design the modifications and add them to
the software. This means that they must complete all steps in the design
phase of the SDLC.

Deciding on a software package to purchase

An organisation should follow six steps when deciding on purchasing a

software package:

1. Evaluate the information system requirements:

 Determine the important features of the system that need to be included.

 Estimate the organisation’s future growth and processing volume needs.
 Identify the constraints regarding the hardware requirements.
 Prepare a request for proposal (RFP) or request for quotation (RFQ).

The organisation compiles a request for proposal (RFP) before

choosing a specific package. An RFP is a list of all the features that the
organisation requires from a system. It sends this list to various vendors.
The vendors will decide whether they are able to provide a package that
satisfies the requirements. If so, they will propose a product and draw up
a quote.

If the organisation knows which package it will be using, it issues

a request for quotation (RFQ) to obtain the price quotations for the
software. It can also use RFQs to determine the available purchasing and
leasing options, and if the vendor will provide maintenance or support.

2. Determine possible vendors:

The Internet has become a primary marketplace for IT products and

services, and is the simplest and fastest way to obtain information on
software purchasing.

A commercial software vendor may help with software run on personal

computers. On the other hand, software for mainframe computers might
not be available from a commercial vendor. Contacting IT consultants,
vendors and industry sources helps when determining suitable products.

3. Consider software alternatives:

Once an organisation has selected potential software packages, it can

compare them to determine the best option:

 Gather as much information about the packages as possible.

 Obtain information on packages previously used by another organisation.
 Allow users within the organisation to test the software before purchasing.
 Use benchmark tests to determine whether the software is able to perform
to a set standard.
 Check the software package against the original RFP.

4. Determine the total cost of ownership (TCO) for each option:

Calculate the total cost of ownership (TCO) for each software option you
are considering. It usually helps to include the results graphically, showing
the impact on cost if one or more variables should change.

Remember that when buying software, you do not actually own it. By
buying the software, you are in fact buying a software licence that
allows you to use the software. The licence specifies the terms under
which you are allowed to use the software.

If the software is leased, there is a lease agreement that describes the

time period, payment conditions and terms of the lease.

When buying or leasing software, you must consider maintenance. It is

best to have a maintenance agreement with the vendor, so that they
can deal with any questions or problems that arise.
5. Draw up a recommendation for each option:

The recommendation includes advantages and disadvantages of each

option, and the costs involved for each, as stipulated by the TCO in step 4.
Management would have to approve the recommendation before the final
step.

6. Install the package:

Once a software product has been approved, it must be installed on the

system. Depending on the size of the system, installation can take as little
as a day, or much longer in larger systems. If the package is customised,
the installation process becomes more difficult. If the installation is for a
large system, it is quite possible that the installation process will interrupt
business processes and, for this reason, installation should be planned
well in advance to avoid any disruptions.

Concluding the systems analysis phase

The system requirements document (SRD), also known as software

requirements specification (SRS), is a document that describes:

 The new system’s requirements.

 The various options that were evaluated and considered.
 A single, specific recommendation as to how the organisation should
proceed.
 What the system developers must deliver to users.

It is important that the SRD be documented in a manner that is easy to

understand, so that users will be able to give recommendations or
corrections based on their understanding of the document.

Presenting the recommendation to management is one of the most

important factors in the development process.

The main aim of the presentation is to ensure that management approves

of the project and will provide the support and the resources that are
required.

Five possible outcomes

Once the presentation is complete, management can decide on five

possible courses of action (see Figure 18):

 Develop in house.
 Modify the current system.
 Purchase or customise a software package.
 Do further systems analysis.
 Stop all development work.
 Figure 18 – Five alternatives that management can choose from

There are certain tasks that are associated with each strategy. If software
has to be developed in house, or if the package is being customised, then
a model of the proposed system must be built.

Moving from systems analysis to systems design

The design phase of the systems development life cycle must begin if the
decision is to develop the system in house. At the end of the analysis
phase, the systems analyst will have a logical design of how the system
should operate.

The logical design reflects the tasks that the system must perform,
without explaining how they will perform. For example, the logical design
for a pet store might include tasks such as displaying all available pets,
entering transaction details, setting up vet appointments, etc., but would
not specify how to accomplish the tasks.

The logical design occurs during the analysis phase of the SDLC.
The physical design describes the actual processes that are necessary
to implement the system, and focuses on how the system will carry out
the task. The physical design occurs during the design phase of the
SDLC.

NOTE

 Logical design: what tasks the system must perform.

 Physical design: how the system must perform the tasks.

The logical design forms the foundation for the physical design. This is
why it is important that the analysis be completed before moving on to
the design phase.

Prototyping
A prototype is an early working model of a proposed information system
that has been built rapidly in order to ascertain whether the user
requirements have been met.

It is very important to get input and approval from the users as the
system is developed. The users are able to assess if the system has all the
necessary inputs, outputs and processes. After examining the prototype,
they can either approve the model or request changes. This process
reduces development time.

Although analysts only use the prototype of a system to confirm that the
user requirements have been satisfied, it does sometimes develop into
the final information system.

Prototyping methods

A sequence of analysis, design, modelling and testing is repeated as the

prototype is developed (see Figure 19).

Figure 19 – Prototyping steps

There are two methods for developing prototypes:

 Design or throwaway prototyping: this prototype is approved by users

and represents the features and benchmarks of the new system. The
prototype is discarded after everyone is happy that the user requirements
are being met.
 System prototyping: this prototype is developed with the aim of
becoming the final system. The prototype contains all the features of the
new system and will be fully functional by the end of development.

Advantages of prototyping

The following are all potential advantages of prototyping:

  Users are involved in the development and can offer input and more detail
on the specifications for the system.
 Users can test the features of the proposed system and evaluate a
working model better than specifications in a document. This is also
referred to as Beta testing.
 Misunderstandings about the purpose of the system can be avoided.
 Prototyping can prevent the organisation from investing in a system that
does not satisfy the user requirements or meet the business needs.
 Training and testing can begin before the system is implemented.

Disadvantages of prototyping

There are some disadvantages to prototyping. These include:

 As the prototype is developed, it is isolated from the rest of the system, so

it cannot be tested properly for reliability or maintainability.
 Since the system is developed rapidly, there may be some quality issues
that are overlooked and only discovered once the system is implemented
and operational.
 Prototypes can sometimes become difficult to manage in complex
systems.

4.1. Notes
About this Unit

The systems design phase is the third phase in the SDLC. Figure 20 shows
where the systems analysis phase falls within the SDLC.
Figure 20 – The design phase

Learning objectives

At the end of this unit you will be able to:

 List the elements involved in systems design.

 State the guidelines for user interface design.
 List and describe the main goals of input design.
 List various types of output and describe output design issues.
 Describe data structures.
 Describe file processing systems and the various types of files.
 Discuss database systems.
 Explain the components of a database management system.
 Explain data warehousing and data mining.
 Differentiate between logical and physical records, and discuss data
storage formats.
 Discuss the items that should be included in the design checklist.
 Define the terms server and client.
 Describe the client-server architecture, including fat and thin clients, and
middleware.
 Discuss the impact of the Internet on application architecture.
 Describe online and batch processing.
 Identify the different network topologies, and the layout of the
hierarchical, bus, star and ring network models.
 Describe wireless networks.
 Describe the system management and support tools.
 State the contents of the systems design specification.
Systems design overview

During the systems design phase, a physical model of an information

system is constructed. Figure 21 shows the elements involved in the
systems design phase.

Figure 21 – Elements involved in systems design

Systems design objectives

The objective of the systems design phase is to design a system that is:

 Reliable: the system must be able to cater for errors, anticipate errors,
and either correct them or alert the user as they occur.
 Maintainable: the system must be able to be modified to adapt to
changing technology.
 Effective: the system must be able to meet the specified requirements
and constraints.

Considerations for systems design

When designing a system, the analyst must consider and cater for the
interactions and processes that take place between users and data.

Users

The first aspect that the analyst needs to consider is how the user will use
the system. Remember, the system is being designed for the user, and in
order for the system to be accepted, the users must approve it and it
must be user friendly. The users must be involved throughout the
development phase of the system. Each design decision must be made
with them in mind. Key points to bear in mind when designing a system
for users are:
  Input and output tasks should be simple for the user to carry out.
 Output should be in an understandable format.
 Input validation (checking that data is in the correct format) should be in
place.
 The system must be scalable (easy to update if changes are necessary in
the future).

Data

Key points to bear in mind when designing a system with data capture in
mind are:

 Data entry should take place as the data becomes available to avoid
delays and errors.
 Verify data as users enter the data.
 Make use of codes. Codes are letters or numbers that represent a data
item uniquely. You should use codes to reduce the storage requirements
and simplify the input, output and processing formats.
 If possible, use automated methods of data entry, such as scanners for
barcoded items.
 Only allow authorised users to enter data and log any additions or changes
to critical data.
 Keep a log of any data entries and modifications.

Processing

Modular design is based on combinations of logical structures, which are

the building blocks of the process. These structures or modules form part
of a larger process or program. In object-oriented design, the objects and
classes become the modules, whereas in traditional design, the process or
sub-process would become the module.

Modules are easier to maintain, understand and implement and they can
be reused. Each module can be independently developed, tested and
corrected by different programmers before being integrated into the final
system.

User interface, input and output design

There are four main aspects to the design phase of the systems
development life cycle. These are:

 Designing the user interface, input and output

 Security and control
 Data design
 Choosing an application architecture

Designing the user interface

A user interface (see Figure 22) consists of all commands and

communications that a system needs in order for the user to provide input
to the system and receive output from the system. In other words, the
user will use the interface to interact with the system. This interaction is
normally through screen displays on a computer monitor. The input and
output may come in the form of a display screen or reports (e.g. Microsoft
Word.)

Figure 22 – Example of a user interface

Guidelines for user-centred design

The analyst should follow these guidelines for a user-centred design:

 The interface designer must understand the business functions.

 The analyst should make use of graphical user interfaces (GUIs).
 The analyst must know the users’ level of experience, skill and knowledge.
 The analyst must think like a user.
 The analyst must use prototypes.
 The interface should contain all necessary commands and tasks that allow
the user to interact with the system effectively.
 The analyst should obtain feedback from users.
 The analyst should document the interface design.

Guidelines for user interface design

When designing the interface, the following guidelines are useful:

 Do not make the interface too cluttered or overwhelming.

 Ensure that the interface is easy to learn.
 Users must be able to use the interface efficiently.
 Help options must be simple, concise and easy to use.
 Include data validation to check that entered data is valid before saving.
 Give feedback to the user whenever the system performs a task.
 The layout and design of the interface should be appealing but not
distracting.
 Use terms that the user is familiar with.

Designing the input

When designing an interface, the analyst must consider the ways in which
the data will enter the system. Many input devices are available to enable
data entry. The most common input device is the keyboard. Other
examples of input devices include a mouse, a touch screen, digital
cameras, biometric devices (such as fingerprint and retina scanners) and
wireless input devices.

Input design has six main goals (see Figure 23):

 Validation checks: These reduce the number of errors that occur when
entering data into the system.
 Reduce volume of input: Only ask users to enter data that is absolutely
necessary in order for the system to process the task.
 Input and data entry method: You can choose between batch or online
input:
o Batch input: data entry is scheduled and the data is processed in
bulk. The data could accumulate and be processed at the end of the
day, week, or at a specified time.
o Online input: as soon as the data is entered, it is processed and
the result is returned to the user. This allows for immediate
responses and validation.
 Develop input controls: Ensure that the data within the system is
secure, accurate and complete.
 Create attractive data entry screens.
 Design source documents: Source documentation helps the designer
determine what data is necessary for the system.

Figure 23 – The main goals of input design

Designing the output

Before designing the output, you need to know who will be receiving it,
how it will be used, whether it needs to be secure, how often it will be
needed and why it is needed. Another consideration is whether it needs to
be displayed on screen, printed or both.
Examples of output include:

 Printed
 On-screen
 Email
 Internet-based
 Instant messaging
 Podcasts
 Audio and video

Reports

There are many different types of reports. Which one you choose for an
output will depend on the type of information the user requires. It is
important that reports are not confusing or hard to understand, and that
they match the user’s requirements.

Some examples of reports are:

 Detail reports: for each record, one or more lines will be output on a
detail report. For example, Figure 24 shows a report listing all products,
according to the productID that belong to the Beverages category.

Figure 24 – Example of a detail report

 Summary reports: employees at higher levels in the organisation usually

do not need as much detail in their reports as lower-level employees. A
summary report usually contains totals showing a summary of the details.
Figure 25 shows a summary of totals for all orders placed in July 2009.
Figure 25 – Example of a summary report

 Exception reports: records that meet specific criteria appear in an

exception report, e.g. a product list displaying only teas and coffees (see
Figure 26).

Figure 26 – Example of an exception report

Security and control

It is important that only authorised people view the report. Systems

analysts must maintain the integrity and security of the output, which is
why organisations have controls in place to ensure that the output is
secure, accurate, complete and up to date.

Systems analysts must develop systems that have good security

measures in place. It is always important to consider security issues when
designing the system.

Data design

A systems analyst must understand some basic data design concepts

before building an information system. All data must be stored in an
organised manner.

Data can be stored in files or tables, which can store information about
things, people, places or events. They can design the system as a file
processing system or a database management system (DBMS), depending
on the business requirements.

File processing systems use a method called file processing to process

one or more individual files.

A database contains tables, which are linked to each other to form an

overall data structure. A database system is more efficient and flexible
than a file processing system. A database management system
(DBMS) can add, access, update and manage the data in a database. The
DBMS has features and tools that allow users to manipulate the data.

File processing

File processing systems contain data files that are constructed to suit the
needs of the individual business system. Older systems made use of batch
inputs and mainframe hardware and, because of this, they used file
processing because it was able to process large amounts of data
frequently. File processing systems are less popular today, but can be
much less expensive than a DBMS, especially when it is a relatively simple
system.

Some of the disadvantages of file processing are:

 Data redundancy: Occurs when data common to two information

systems is stored in several places. It is expensive, because it costs more
to maintain updates on all the copies of the data. It also requires more
storage space.
 Data integrity: Updates to only one file may cause data inconsistencies if
they are not applied to all files containing that data.
 Rigid data structure: File processing systems have rigid data structures,
making them inefficient and slow when retrieving information from other
file-based systems.

The following is a list of file types that are used in a file processing
system:

 Master files: used to store relatively permanent data.

 Work files: created for a single task. Work files are temporary files.
 Transaction files: store data produced during day-to-day transactions.
Transaction files are input files that update a master file.
 Table files: contain reference data; relatively permanent and not updated
by the system.
 Security files: used for backup and recovery purposes. Outdated files
must be updated regularly by new security files.
 History files: created for archiving purposes.

Database systems

Database systems largely eliminate the problems of file-oriented systems.

When using a database system, several information systems can all use a
single database. This prevents data redundancy and provides data access
that is real time (response is almost immediate), flexible (access is not
limited to specific, predefined elements only) and interactive (easy to
retrieve data that is needed from a specified query).

Advantages of database management systems include:

 Scalability.
 Data sharing.
 Redundancy is reduced or controlled by the DBMS.
 The DBMS offers good security controls.
 Better support of enterprise-wide applications.
 Faster development time.
 Good support for client-server systems.

Disadvantages of database management systems include:

 A need for more expensive equipment and hardware to support multiple

users.
 A DBMS is more complex than a file processing system, which makes it
more difficult to use.
 An increase in the total cost of ownership because of the need for more
training.
 In a database environment, all the data is held in the database and a
failure could severely interrupt business operations.
 Backup, recovery and security measures are more complicated.

Parts of a DBMS

Users are able to interact with the database through an interface that the
DBMS provides. The DBMS includes:

 A database, consisting of:

o A physical data repository: the data dictionary is converted to a
data repository which has its own schemas.
o A schema: the definition of a database, which includes all the
records, fields, relationships and their descriptions.
 Data manipulation language (DML): enables data retrieval, storage,
deletion and update operations on the database.
 Database administrator (DBA): manages security, user permissions on
database objects, provides backup, recovery and user needs.
 Users: use query language, such as Query-By-Example
(QBE) or Structured Query Language (SQL), to access the data on
database objects, such as tables, by using queries, functions or stored
procedures.
 Other information systems: a single DBMS is able to support several
different systems that provide input to or require data from the DBMS.

Figure 27 illustrates the DBMS and the users, DBA and other systems.
Figure 27 – DBMS and the users, DBA and other systems

The data warehouse

The data warehouse is a central storage facility or mechanism for all the
data in the organisation. Management use the data in the data warehouse
for decision-making and it can also provide support for management
analysis.

The data warehouse stores transaction data centrally in a standard

format, which allows users to access, analyse and combine the data
efficiently.

Data mining

Data mining software searches the data warehouse for meaningful

patterns and data relationships. Data mining can reveal patterns that are
useful to the organisation’s decision-making. For example, observing how
a particular product sells at different times of the year could help
management determine when they need to concentrate their sales.

A soft drink organisation may observe a pattern when winter sales in the
Cape Town area are low, but are above average in Durban all year round,
or that Johannesburg always has the highest number of sales. Knowing
where and when to distribute their soft drinks will help the organisation
save costs.

Database design terms

You need to know the following database design terms:

  Entity: a person, place, event or thing, e.g. in a pet store, PET, VET,
CUSTOMER and APPOINTMENT are some of the possible entities.

 Field (or attribute): a fact or characteristic about an entity, e.g. Name

or PetID (see Figure 28).

Figure 28 – Illustration of entities, fields and common fields

 Record: an entity contains many records. Each record is a set of fields

that describe the entity. A single record will contain fields describing one
member of the entity. For example, a record will have fields about one pet
or one customer. Records are arranged in either files or tables, depending
on the data design used.
 File: a file in a file-oriented system is a collection of records that all relate
to the same entity. The data within the file can be arranged so that it
speeds up processing.
 Table: a table in a database environment stores data about an entity. A
table is a two-dimensional structure that has vertical columns to show the
fields of the entity and horizontal rows to show each individual record. A
database can consist of many different tables.

Database design is discussed in detail in the Relational Database

Management Design module.

Storing data

There are many differences between physical and logical records and the
analyst must consider this when constructing the physical design of the
record.
It is important to understand the format in which data is stored (see
Figure 29):

 The smallest unit of data that can be stored is called a bit, which is one
binary digit.
 Eight bits equals one byte, or character.
 A set of bytes is a field, data element, or data item.

Figure 29 – An illustration of a bit, a byte and a field

Every instance of a field has a value. Fields can be different sizes,

depending on the data that they store. For example, the field OrderID can
contain one order having the two-byte value of 135 as a number; another
could have the one-byte value of 56. It is important to allow the field size
to contain the largest expected value, but should not be so large that it
wastes space because it remains unused.

A logical record

A logical record holds information about a single entity (person, place,

event or thing). The fields within the record describe the entity. A record is
a term that is associated with a logical record (see Figure 30). For
example, the logical record for a Customer would include the name,
address, telephone number, etc. The programs are not concerned about
where the records are physically stored. Whenever the operating system
needs to read from or write to a record, it supplies a logical record to the
program and accepts a logical record back from the program.
Figure 30 – Example of a logical record

A physical record

A physical record can be one or more logical records. A physical record is

also known as a block. This is the smallest unit of data that the operating
system can access. The operating system reads or writes each physical
record one at a time. It does so by moving the record from the file or table
to the buffer, or from the buffer to the file or table. The buffer is a section
in the computer’s memory that the operating system can use to store
data temporarily. Since the physical record or block is made up of logical
records, it contains something called a blocking factor, which is the
number of logical records within the physical record (see Figure 31).

Figure 31 – Example of a file and its contents

Formats for storing data

There are four basic storage formats for data:

 EBCDIC: The Extended Binary Coded Decimal Interchange format is

used in mainframe computers and requires one byte of storage per
character.
 ASCII: American Standard Code for Information Interchange is used
in most mini computers and personal computers. It requires one byte of
storage per character.
 Unicode: Uses two bytes of storage per character and can therefore
represent more characters than ASCII, including characters found in
foreign languages.
 Binary: An efficient storage format for numeric data.
Application architecture

Application architecture, sometimes known as system architecture,

focuses on the conversion from the logical design of an information
system into a physical structure, which includes the hardware, software,
network support and processing methods.

NOTE

The term application architecture (not system architecture) will be

used for the purposes of this module.

Checklist for design

The analyst must consider the following issues before choosing an

application architecture:

 Enterprise resource planning (ERP): ERP establishes a strategy for IT

resources and defines a specific architecture, including the standards to be
used when designing the user interface, data, network and processing.
 Scalability: the system must be able to adapt to changing business
requirements without difficulty.
 Processing options: the physical design of a system would depend on
the volume of data processed, and whether batch or online processing is
used.
 Online processing: may have to operate 24 hours a day and 7 days a
week.
 Batch processing: can be done during off-peak hours to reduce costs.
 Security.
 Initial cost and total cost of ownership (TCO).
 Web integration: if the application will be integrated with web-based
components, or if it is to be part of the organisation’s e-commerce
strategy, it requires a different type of application architecture, called a
web-centric architecture.
 Interface with legacy systems: all the data formats of a legacy system
must be examined and analysed so that it can interact with the new
system.

Server

A server is a computer that is able to provide processing services, data

and support for other computers. Clients are the computers that request
services from the server. Two terms are used to indicate a multi-user
environment. These are:

 Mainframe architecture: the server does all the processing.

 Centralised system: a server provides support to clients at different
locations.

Figure 32 shows a centralised system.

Figure 32 – Centralised system

The server is a more powerful computer than the client machines.

Organisations use servers to allow users to enter and retrieve data from a
centralised point. All the data access, storage and application programs
are stored on the server. Servers have advantages and disadvantages:

 The advantage of server-based processing is that the design does not

require a specific hardware platform, and different types of clients and
terminals (the computer that the user uses) can interact with the
mainframe.
 A disadvantage is that the user interface is limited, as server-based
processing uses character-based terminals.

Clients

Clients are computers used by users to request services and information

from servers. The advantages of stand-alone computers are that they:

 Perform all the functions of a server.

 Increase productivity.
 Can be used to carry out tasks independently.

The disadvantages of stand-alone computers are that they:

 Are inefficient.
 Are expensive.
 Can be inconsistent.
 Might not be able to maintain data integrity.
 Do not promote strong data security.

Eventually stand-alone computers became popular and most

organisations began to link the PCs (which became known as clients)
together in networks. These networks allowed the clients to share data,
communicate and perform local processing, as well as share hardware
resources such as printers, etc. There are two types of networks, namely
local area networks and wide area networks.
Local area network (LAN) and wide area network (WAN)

A local area network (LAN) consists of stand-alone computers in a

small area (e.g. in a building) connected to each other by a LAN to allow
sharing of data and resources. The LAN may consist of many clients, as
well as hardware resources such as scanners, printers, etc.

A LAN can be connected to a centralised mainframe (see Figure 33).

Figure 33 – Example of a LAN

If the client wishes to use the data, it requests a copy of the data file from
the server. The server then sends the copy of the file to the client. The
client uses the data on the file and returns it to the server when finished.
The server stores the modified file.

A wide area network (WAN) covers larger distances than LANs. WANs
can communicate with clients that are in different cities or even
continents. WANs commonly connect separate LANs together. Figure 34
shows an example of a WAN.
Figure 34 – Example of a WAN

Organisations often have many LANs and WANs. The systems that
connect them are called distributed systems.

Client-server architecture

Client-server architecture is a term used to describe systems in which the

processing is distributed between the clients in the network and the
server. Typically, the client will deal with the user interface, data query,
data entry and screen presentation logic. The server stores the data,
provides data management functions and data access.

The server and the clients divide the application logic between them in
some manner. With the client-server architecture, when the client wants
data, it requests it from the server. The server then carries out the
request and returns the result to the client. The server does not send the
entire file over the network. It only sends the result of the request.

The processing of the request is transparent to the client. The server may
even have to get information or processing support from other servers to
fulfil a request, but the client has no idea this is happening.

Client types

Client-server designs are categorised as either fat clients or thin clients.

In fat client design, also known as thick client design, most of the
processing is located on the client. In this case, the client must access and
update the data on the server more regularly.

In thin client design, most of the processing is located on the server.

There is often a need for very different applications to connect and

communicate with each other. Middleware is software that is able to
connect different applications and allow them to interact and share data.
For example, an application can connect to a database via middleware
(see Figure 35).

Figure 35 – Example of how to use middleware

Application architecture and the Internet

The Internet can affect the application architecture. The Internet is

continuously redefining the way in which an organisation can conduct
online business. It is important that the systems analyst proposes e-
commerce strategies that will benefit the organisation and help to fulfil
the business requirements.

E-commerce strategies include:

 In-house development
 Packaged solutions
 E-commerce service providers
 Corporate portals
 Strategies and methods used by more experienced companies

Network models

A network is used to decrease costs and provide the user with more ways
to execute business functions by sharing the resources that are available.
For this reason, careful planning must go into the network design.

A network topology is the manner in which a network is configured or set

up. Even though the physical implementation for a LAN (which can be
quite small) is different from a WAN (which can be very large), the same
principles and concepts apply. The resources that are shared over a
network can be hardware, software or data. Peripheral devices, databases
and any other devices that need to be linked to the system can also form
part of the network.

There are four types of topologies for LANs and WANs:

 Hierarchical topology: in a hierarchical network topology, one computer

(usually a mainframe computer) controls the entire network. There are
also servers or satellite computers that control the processing and devices
at lower levels (see Figure 36).

Figure 36 – Hierarchical topology

 Ring topology: the computers in a ring network topology are arranged in

a circular fashion, with each one connected to the next. The data only
flows in one direction. A ring topology is useful when processing occurs at
local sites (see Figure 37).
Figure 37 – Ring topology

 Star topology: in a star network topology, there is a central computer,

server or mainframe that acts as a coordinator between nodes
(computers). It can, but does not necessarily have to, contain all the data
needed for processing. The computers in a star topology are all connected
to a central computer resembling a star shape.

The star network is efficient and the data that is processed on the network
is controlled. The problem with a star network is that the entire network
will crash if the central node fails. In larger star networks, there are often
backup systems in place if the central computer fails (see Figure 38).

Figure 38 – Star topology

 Bus topology: the mainframe computer, PCs, servers and any peripheral
devices are connected by a single path, which is used for communication
in either direction. In this type of network, a device can send a message to
 any other device connected to the network. With a bus network, any
number of devices can easily be added to or removed from the network. If
a single computer fails, it does not affect the entire network (see Figure
39).

Figure 39 – Bus topology

Wireless networks

Many companies are turning to wireless networks as an alternative to the

traditional cabled network. A wireless local area network (WLAN) is
relatively cheap to install and is suitable for users that are not always in
one location during their work duties.

The most popular wireless standards and protocols are the 802.11
standards, which were developed by the Institute of Electrical and
Electronics Engineers (IEEE). These standards are also known as Wi-Fi
(wireless fidelity) standards.

Although wireless networks have the advantage of less expensive

installation requirements and greater manoeuvrability, they do have
certain disadvantages:

 They are less secure than cabled networks.

 They are more likely to pick up interference from other electrical devices,
such as cordless telephones or microwave ovens on the 2.4GHz frequency
band.

Bluetooth is another wireless technology, used in short distance wireless

communication devices and requiring low power output.

Examples of devices that use Bluetooth are certain cell phones, digital
cameras, wireless keyboards, mice and printers.
Protocols

Every network must use a protocol. A protocol is a set of standards that

the network follows when transmitting data. One of the more popular
protocols is TCP/IP (Transmission Control Protocol/Internet
Protocol) which is the protocol that the Internet relies on. Another
protocol is NetBIOS, which is used mostly for LANs.

Obtaining licences

Analysts must consider the type of software licences that the

organisation is able to use when they design a network. They must also
determine if the software will be able to cope with the network traffic.
Software vendors offer various individual and site licences, and the
analyst must research the available options to determine whether there
are limitations on the number of users that can access system programs
simultaneously.

Managing and supporting the system

4.15.1 Managing performance

The systems administrator must monitor the performance of the system.

There are special tools that allow the users to get information about
system resources, activity levels, usage and capacity. It might also be
necessary to fine-tune the network or software settings in order to
optimise and increase performance.

4.15.2 System security

There must be a system in place that allows a systems administrator to:

 Assign and monitor user IDs, access levels and passwords.

 Protect the system against viruses and unauthorised access.
 Carry out security audits and trails.
 Have security policies in place throughout the organisation.

4.15.3 Backup and recovery

Every system should plan for data backup and recovery. This overall plan
is known as a disaster recovery plan. It includes:

 Backup: systematic copying of data, either on a continuous basis or at

certain scheduled times.
 Recovery: if the system is interrupted, recovery procedures restore the
data to a previously backed up version and restart the system.

The type of recovery planning that a system needs depends on the type of
system that it is:
  Batch processing: batch processing backups can occur at the end of any
processing transaction.
 Online processing: either the backups must happen continuously or when
the system is not in use.

It is important to realise that there may be certain government

regulations in place that require an organisation to keep files. This should
also be part of the backup plans of the company.

Completing the systems design phase

As the systems design nears completion, there are certain tasks that the
analyst needs to carry out. The analyst must:

 Create a systems design specification.

 Obtain user approval.
 Present system specifications.

Create a design specification

The analyst needs to record the system’s specification for future reference
in a document called the systems design specification. The systems
design specification is also known as a technical design
specification or detailed design specification. This document
contains details regarding the design of the system, as well as the cost,
the staff required, the training and schedules for systems implementation.

This document is written for the programmers and IT staff who need to
develop the systems programs.

Obtain user approval

The analyst needs to ensure that the design of the user interface meets
the user requirements and that they are satisfied with the screen and
report layouts.

The IT staff also need to examine the systems design specification and
give their input regarding the schedule and costs, and any hardware,
network and software requirements. Approval should be obtained
throughout the design phase.

Present system specifications

At the end of the systems design phase, the analyst must be able to
present the system objectives and specifications to the users and the
stakeholders. The purpose of these presentations is to put forward the
project specifications, clear up any misconceptions regarding the project,
and answer any queries about the project. The analyst must usually
complete a minimum of three presentations. These presentations include
presentations to:
  Systems analysts, programmers and staff that provide technical support
 Users and department managers
 Management

There are three options open to management at this stage (see Figure
40):

 Proceed with development.

 Conduct further studies for design.
 Terminate the project.

Figure 40 – Three courses of action management can take after systems

design presentation

Once the systems analyst has approval for the project, the process can
move on to the next step in the systems development life cycle, namely
the implementation phase.

5.1. Notes
About the unit

Systems implementation is divided into two parts, namely application

development and systems installation and evaluation. Figure 41 shows
where the systems implementation phase falls within the SDLC.
Figure 41 – The implementation phase

Application development

The following tasks occur during application development:

 Quality assurance
 Developing the application
 Testing
 Documentation

Quality assurance

Organisations have to reassess the quality of their product or service

continually, and then find ways in which they can improve on it. This often
includes improving their information system, and the IT department needs
permission from management for this. When developing the system, it is
far easier to cater for and detect problems early on in the design and
implementation phases than at a much later stage. Quality
assurance prevents or allows for the early detection of problems.

Developing the application

Whenever an application is developed and implemented the steps that

should be followed are similar for both structured design and object-
oriented design (see Figure 42). A new system needs to be planned, built
and tested.
Figure 42 – Steps to take when developing

When developing an application, you first need to plan the design. The
actual application must then be developed by going through the iterative
processes of designing, coding, testing and documenting. This continues
until the application satisfies the requirements. The application then
needs to be integrated into the system, tested and documented.

Structured application development

Modules are groups of related code that are small and easy to understand
and maintain. They are grouped together to perform a task that forms a
small part of the system. Complex programs can contain hundreds of
modules. One of the advantages of modular design (also known as a top-
down design) is that different modules can be given to different
programmers to code at the same time, so that development time for the
overall system is shortened.

A top-down design, which goes from a general to a more detailed

design, is a common approach to planning a system.

Structure charts show how the program modules relate to each other.
Table 2 illustrates the symbols for a structure chart and explains what
they represent.

Table 2 – Symbols used in a structure chart

 Name Description Symbol

Module Represented by a rectangle

Library Represented by a rectangle with

module lines at the sides. It is reusable
and can be used at more than
one point

Data Represented by an arrow that is

couple joined to an empty circle. It
shows that one module
continues to the next.

Control Represented by an arrow that is

couple joined to a filled circle. It shows
a message (or flag) which one
module sends to another.

Condition Represented by a line with a

diamond at one end. It shows
that the control module will
choose to use a subordinate
module based on a condition.

Loop Represented by a curved arrow.

It shows that modules can be
repeated.

In a structure chart, there is often a module called a control module that

decides when the lower level, or subordinate modules, will operate. Figure
43 shows an example of a structure chart.
Figure 43 – Layout of loop, control couple and data couple in a structure
chart

The control couple shows that the ‘Get item price’ module accepts a
barcode from the ‘Produce till slips’ module, and then returns a price. This
continues until there are no more items. The data couple shows that the
two modules pass data to each other.

Metrics

A software metric is a measure of a piece of software property or its

specification. In this module, we will only discuss cohesion, coupling,
coding and data binding software measurements. Cohesion is a measure
of the amount of processing that a module has to do, and the scope of the
module. If the module performs only a single task, it is more cohesive, and
this makes it easier to code and reuse. Therefore, the higher the degree of
cohesion in the module, the better the quality of the module is. For
example, the ‘Check Customer Number’ module is highly cohesive,
because the module is only required to check the customer number and
nothing else.

Coupling is the measure of the dependencies and the relationships

between the modules. Modules can be tightly coupled or loosely coupled:

 Tightly coupled modules: If the module is dependent on the processing

logic of another module, then the modules are tightly coupled. A tightly
 coupled module is harder to modify because other modules might depend
on its logic, and any changes made would affect the other modules.
Examples are Content coupling, Common coupling, External coupling and
Control coupling.
 Loosely coupled modules: These modules are more independent.
Loosely coupled modules are easier to work with, modify and maintain,
because the logic in the module does not necessarily affect other modules.
Examples are Data coupling and Stamp coupling.

Other tools that are used for developing applications are program
flowcharts, which represent module interaction and logic graphically,
and pseudocode, which represents the program logic in Structured
English.

Coding is the process of converting program logic into commands and

instructions that the computer can understand.

Depending on the systems design, the programmer can use an

appropriate programming language to change the logic of the system
into commands or code statements. Depending on the size of the system,
a single programmer can code a small program or a group of
programmers can code a relatively large system.

Data binding is a medium that captures the strength of coupling

between modules in a software system.

 potential data binding: (x, y, p)

o module x and p share variable y
 used data binding: (x, y, p)
o module x and p both assign/reference variable y
 actual data binding: (x, y, p)
o module x assigns to y, p reads from y

The higher the value, the stronger the bond between x and p.

Object-oriented (OO) application development

With object-oriented (OO) application development, the programmer can

easily translate the object model into an OO programming language. OO
development is more popular than structured application development
because the translation is quicker and easier. A structure chart helps keep
track of the relationships between modules when implementing a
structured design. However, with OO design, the relationships are already
in place because they were identified during the OO analysis and design
process. Therefore, the structure of the application is already developed in
the object model.
The analyst needs to analyse and review the classes, methods, attributes
and messages for the system before and during the conversion from an
OO design to an application. While the analyst is doing so, he or she can
make changes, updates and revisions to any of the diagrams. This helps
the programmer translate logic into program code, and establish which
events, messages or triggers make the modules execute.

OO application design is also modular. Groups of programmers can

complete the coding for different parts of the system. Once the coding is
complete, the programmers will integrate the modules and perform
vigorous testing. They will also document the system.

Testing

Program code always needs to be tested thoroughly to ensure that it

performs the required tasks. Testing consists of the following steps:

 The code is compiled using a CASE tool or a language compiler to check

for syntax errors (errors in the way in which the language is used), which
the programmer corrects.
 Desk checking is performed, which checks for logical errors in the code.
Logical errors produce incorrect results (the code does not do what it was
meant to).
 During a design walkthrough, programmers and users discuss the
features of the interface of the system.

The next phase in the testing process consists of:

 Unit testing
 Integration testing
 Systems testing

5.4.1 Unit testing

Unit testing tests a module or individual section of code for errors. All
errors that cause the program to end unexpectedly and any logical errors
that were missed during the code review are corrected during unit testing.

Unit testing involves a process called stub testing, in which

programmers simulate the result of a program integrating with another
program and then display a message regarding the outcome.

5.4.2 Integration testing

Programmers perform integration testing, or link testing, to ensure that

the individual programs are able to function together correctly.

5.4.3 System testing

System testing, or acceptance testing, covers the entire system and
involves programmers testing all processing situations that may occur.
The project development team runs tests to ensure that input, output and
processing deliver the desired results. In order for management and users
to approve the system, the acceptance tests must be successful.

The decision to stop testing is a judgment call, but projects have to keep
to schedule and there may not be enough time to retest. However, tests
are important and they are a cost-effective way of providing a high-quality
product.

Documentation

Every system needs to have documentation in place that explains how the
system works and helps people to use it. Complete and accurate systems
documentation assists with the operation and maintenance of the system.
If the system needs updating at a later stage, up-to-date documentation
can assist programmers with the maintenance of the system.

The types of documentation are:

 Program documentation.
 Systems documentation.
 Operations documentation.
 User documentation: the purpose of user documentation, i.e. a user
manual, is to help users to interact with the system.
 Systems testing results documentation: the results of the systems testing
are handed to management for approval.

Systems installation and evaluation

Systems installation and evaluation is the second part of the systems

implementation phase. It describes the actual installation of the
information system and its initial evaluation by the users.

5.6.1 Environments

Specific hardware and software combinations form

an environment or platform. The environment on which the final
system will run is called the operational environment or production
environment. Before the system becomes operational, developers will
test it on a test environment. Developers use the test environment to
build, develop, maintain and preserve the security and integrity of the
system.

The test environment is restricted to analysts, programmers and people

who were involved with the project and the development of the system.
The test environment contains copies of all the test data files, programs
and processes (see Figure 44).
The development team must thoroughly test all network connectivity,
configurations, telecommunications and settings that are a part of the
system before the system is made operational.

Figure 44 – Moving from a test environment to an operational

environment

5.6.2 Training

In order for the system to be successful, the users must be well trained in
order to make full and efficient use of all the functionality and features
that have been included in the system. The ease with which users interact
with a system determines its success.

Generally, three different groups of people require training:

 Users: need to know how to carry out day-to-day operations.

 Managers: need an overall picture of the system.
 IT staff: need to know the functions of the system, how it satisfies
requirements and what skills the users need to complete their tasks.

Users can receive three types of training:

 In-house: conducted internally by IT and development staff.

 Vendor: provided by the vendors that supplied the package.
 Outside: provided by an independent training firm hired to do the training.

5.6.3 Guidelines for developing in-house training sessions

Use the following guidelines when choosing in-house training:

 Train people needing training on the same topics together.

 Prepare effective training materials.
 Choose an appropriate location.
 Use interactive training methods.
  Use the experience of previous trainees.

5.6.4 Data conversion

When a new system is developed, all the data from the old system needs
to be transferred to the new system. This often means converting the old
data to fit in with the standards and conventions of the new system. It is
usually more efficient to automate the conversion process. However,
developers should completely test the conversion process in the test
environment before using it.

The main security concerns during data conversion are that data is input
into the new system correctly and that there is no unauthorised access
during the process.

Implementing the new system

When a new system is implemented, a system changeover will occur

when the old system is replaced by the new system. The change can be
quick or quite slow, depending on the method that is used.

There are four ways to implement a system changeover:

 Direct cutover
With the direct cutover method, the change from the old to the new
system occurs at the same time and the new system is fully operational
immediately (see Figure 45).

This is one of the cheaper methods to implement, but it is more risky than
other methods. If there are problems that testing did not find, then there
might be unacceptable downtime for a company’s operations. Direct
cutover may sometimes be the only choice if the operating system cannot
handle both systems, or if the two systems are completely different or
incompatible.
Figure 45 – Direct cutover

 Pilot operation
When the pilot method is used, the system is only implemented in a
certain part of the organisation. During the pilot operation, the old system
continues to operate throughout the organisation (see Figure 46). If the
pilot system is successful, then the team can implement it throughout the
organisation. This is also a less expensive method, because the
organisation only has to pay for the operation of the system at one site. By
having the system only operating at one site, the risk of the entire system
failing is reduced.

Figure 46 – Pilot operation

 Parallel operation
In the parallel method, the old and new systems operate at the same time
 until the users are satisfied that the new system operates correctly (see
Figure 47).
Both systems receive data input but only the new system produces data
output. The parallel system is a lower risk operation as the old system
serves as a backup to the new system should errors occur. However, the
expense is much higher because the organisation has to pay for the
operation of two systems at the same time.

Figure 47 – Parallel operation

 Phased changeover
A phased changeover allows the new system to be implemented in stages.
Once a module has been tested and is fully functional, it can be
implemented. Any one of the other three methods can be used to phase
the module into the system (see Figure 48).

Risk of failure is restricted to the module itself and can be corrected

without affecting the entire system. It is less expensive because only one
part of the system is implemented.

The phased changeover and the pilot system methods are similar but
differ because the phased changeover gives part of the system to all users
whereas the pilot system gives the entire system to a group of users.
Figure 48 – Phased changeover

Post-implementation evaluation

Once the implementation is complete, the users perform a post-

implementation evaluation. This evaluation determines the following:

 User satisfaction
 Completeness, accuracy and response times for the output
 The IT team’s performance
 How effective the training procedures were
 How reliable and maintainable the system is
 The security controls and measures that are in place
 The completeness of the documentation
 How accurate the cost and time estimates were

Final report to management

The deliverable at the end of this phase is a report to management. This

report should include:

 All final versions of the systems documentation

 Any changes or modifications to be implemented
 A review of the estimated cost
 The schedule to be compared to the actual budget
 The total time taken
 The post-implementation evaluation

This report is the final report in the development of the system. The next
phase will highlight the analyst’s responsibilities in providing maintenance
and support.
6.1. Notes
About this Unit

Unit 6 discusses the last phase in the systems development life cycle,
namely the systems operation and support phase. This phase begins and
continues for as long as the system is operating. It includes user support,
systems maintenance, improvement and performance measurement.
Figure 49 shows where the systems operation and support phase falls
within the SDLC.

Figure 49 – The systems operation and support phase

Maintenance and support of the system

Once the system becomes operational, there is no further major

development. However, maintenance and support for the system continue
for the rest of the system’s lifespan. The main tasks of the analyst are to
provide user support and maintenance to ensure that the system
continues to operate properly.

User support

User support, along with maintenance, is ongoing. Examples of user

support include training for users and a help desk to answer queries.
Training

Users need training on how to use the new system effectively and
efficiently. The department in which they will be working usually trains
new employees. If a new version of the system is released, then training
on that version might be released in a user training package. This type of
training is similar to the initial training that users received on how to use
the system.

Help desk

Many IT departments create help desks to help guide and support the
users, and make data more accessible as the system data structures
become more complex. A help desk, sometimes known as
an information centre, is usually the first place that users turn to when
they experience problems.

The help desk’s aim is to:

 Answer technical and operational questions.

 Provide assistance on how to use the system resources efficiently.
 Teach the users how to meet their own work needs, thereby making them
more productive.

Maintenance

Maintenance costs can vary depending on the support and maintenance

needs. Some of the maintenance activities that an analyst might have to
carry out include adapting the system programs, revising the
documentation and ensuring that the system operates as efficiently as
possible.

There are four maintenance methods:

 Adaptive: to add new features and enhancements to the system

 Corrective: to fix errors
 Preventative: to determine the steps needed to prevent errors in the
future
 Perfective: to increase and improve efficiency

Analysts can use these methods simultaneously. Maintenance costs are

often very high when the system is first implemented. The costs then
stabilise, rising and falling in response to the maintenance and support
that the system requires.

Systems operations

There is often a maintenance team to handle incoming requests, prioritise

these requests and release any changes to the system. The maintenance
team consists of one or more analysts and programmers, and their
responsibility is to manage the system’s operations properly.

The analysts often act as supervisors and must have:

 Strong IT backgrounds
 Strong analytical abilities
 Effective communication skills
 An understanding of business functions and operations

Maintenance requests

When the maintenance team receives a maintenance request, they need

to carry out the following tasks:

1. Systems administrators make the initial decision on whether to pursue the

request. The systems administrator deals with critical requests
immediately. Non-critical requests are passed to the systems review
committee.
2. The systems review committee studies the request and decides whether
to pursue it. They put valid requests in the maintenance schedule and the
systems administrator gives them a priority level. The committee then
informs the users.
3. The systems administrator assigns the tasks to individuals or a
maintenance team.

Changes to the system requirements often occur as the SDLC

progresses. Configuration management is the process that oversees
and controls these changes. Configuration management is in place to
manage system changes once the system is operational.

Releasing maintenance changes

If there are many versions of a system, it may become difficult to make

changes and updates. Organisations often work on a version control
methodology, whereby each version of the system has a different number.

Version control is an effective way of keeping track of the latest system

release. A new system version containing any changes is known as
a maintenance release.

System performance

The system’s performance affects the way in which users are able to carry
out their duties. Slow-running systems waste time and therefore increase
operational costs.

There are a few ways in which to measure system performance:

  Bandwidth: This is the amount of data that the system can handle in a
given time and is measured in bits per second (bps), kilobits per second
(kbs), megabits per second (Mbs) or gigabits per second (Gbs).
 Response time: This is the total time it takes for the system to deliver a
response after it receives a request for an activity.
 Throughput: This is the actual performance of the system under specified
conditions. Network traffic and the type of hardware can affect the
throughput.
 Turnaround time: This measures the time from when a request for
information is put through until the time that the processing of the
information is complete. It refers to centralised batch processing
operations.

The end of the system lifespan

All systems become obsolete at some point. This occurs when the
functions that the current system provides are no longer needed or if the
platform that it runs on becomes outdated.

The following are indications that a system is reaching the end of its
lifespan:

 An increase in maintenance requirements and adaptive measures starts

occurring.
 Operational costs increase and perfective maintenance measures are
unable to counteract them.
 Software packages are available that are able to do the same things, and
more, at a lower cost, faster and more effectively.
 Newer technology provides a way to perform the same functionality more
efficiently.
 The maintenance becomes more expensive and difficult to perform.
 The system needs a significant number of new features to support the
business functions of users.

When the system is at the end of its lifespan, the above reasons make a
systems request for a new system viable. The systems development life
cycle will then start over again.

Skip to main content

Print book

7.1. Notes
Site: Eduvos LMS

Course: Software Engineering

Book: 7.1. Notes

 Printed
Kriveshan Naidoo
by:

Thursday, 14 August 2025,

Date:
1:58 PM

Table of contents
 Learning objectives
 7.1 What is UML?
 7.1.1 UML modelling types
 7.2 The software problem
 7.3 A solution
 7.4 Key terms

Learning objectives

At the end of this unit you will be able to:

 Define UML and UML modelling types.

 Explain the software problem.
 Give a solution to the software problem.

What is UML?

UML (Unified Modelling Language) is a graphical modelling language

specification that has combined all the best engineering practices for
modelling software systems.

UML consists of graphical elements that represent objects and the

relationships between them, and enables developers and analysts to draw
diagrams of the system. They can combine these diagrams in a number of
different ways to form models that are largely independent, visually
meaningful and descriptive in their own right, but together form a model
of the entire system. This model reflects the real world more closely as
they can describe business data and processes more accurately in the
model than in a flowchart.

UML plays a vital role in defining different views of a system. These views
are listed in the table below:

View Description Diagram type

Design Consists of classes, interfaces Class diagram

and collaboration. and object
diagram.

Implementati Defines the components Component

on gathered together to make a diagram.
complete physical system.
Process Defines the flow of a system. Class diagram
and object
diagram.

Deployment Denotes the physical nodes of a Deployment

system that forms the hardware. diagram.

UML modelling types

Different diagrams are used for different UML modelling; therefore, it is

very important to distinguish between these UML models. There are three
types of UML modelling:

1. Structural modelling:

Structural models show the static features of a system. They consist of the
following:

 Class diagrams
 Object diagrams
 Deployment diagrams
 Package diagrams
 Composite structure diagrams
 Component diagrams

The class diagram is the most frequently used structural diagram.

2. Behavioural modelling:

Behavioural models show the dynamic nature of the system. Behavioural

models define the interactions among the structural diagrams in the
system. They consist of the following:

 Activity diagrams
 Interaction diagrams
 Use case diagrams

3. Architectural modelling:

Architectural models show the overall framework of the system containing

both structural and behavioural elements. They can also be thought of as
a blueprint for the entire system. Package diagram results from
architectural modelling.

The most common diagrams in UML are the class, object, state
machine, sequence, activity, communication,
component and deployment diagrams.

The software problem

In the early days, computer programming often produced results that did
not comply with all the original requirements. Systems analysis was often
informal, and frequent misunderstandings occurred between the user and
analyst.

The majority of the software written was either late, bug-ridden (i.e. full of
errors), unreliable or occasionally completely unusable. Together with the
fact that such software is usually very expensive to develop, there needed
to be some solution that could address these problems.

Many believed that part of the problem was the use of structured or
procedural programming languages (such as C and Pascal).

These languages rely on a program starting at one particular point,

proceeding through a set of structured steps broken into subprograms,
and finally reaching a goal. This form of programming becomes
increasingly complex as the scale of the project increases and leads to
programs that are difficult to maintain, almost impossible to extend and a
problem to manage.

A further problem was the process analysts followed when developing

these large programs (see Figure 50). Generally, they followed
a linear or waterfall methodology, in which the user (the person using
the computer system once it is operational) would pass on the system
requirements to a systems analyst who would design the system. The
result was that these requirements were often poorly defined. The project
would then be passed on to a senior programmer who would divide up the
tasks required to complete the system, and allow junior programmers to
code the various sections of the larger program. Once users had written
down the program specifications, they would not see the program again
until it was completed, and would not be involved in the design of the
system. Once a task had started down this path, there was no returning to
earlier steps in the process.

Although this is an over-simplification, the main disadvantage of this

methodology is that design problems are usually identified late in the
process when the user begins testing the program (only to discover it
does not behave as expected or required).
Figure 50 – From user to programmers

A solution

Object-oriented analysis, design and development of programs is one

potential solution to this software crisis, as it considers the overall design
or organisation of the program.

The goal of object-oriented design is to:

 Reflect real world situations more closely by focusing on the real world
objects that the system models.
 Build a strong link between data and the operations that manipulate them.
 Promote code reusability.
 Promote extensibility (part of the system can be changed without requiring
changes to the entire system).

The process when developing object-oriented systems should also include

the user in the design stage to ensure that the system does what the user
wants. This lessens the chance analysts will only find problems in the
software late in the development process.

Although a modelling language is a relatively minor part of building a

good object-oriented model, it is often where much of the energy is spent,
and much has been written on conventions for such a modelling language.
Today, UML is the accepted industry standard for software modelling.

8.1. Notes
The bigger picture

Object-oriented analysis and design is only one part of a bigger picture of

software development which begins with an idea (e.g. “maybe a computer
can solve this problem”) and ends with a completed, running software
package that does exactly what the user wants. The overall process would
probably follow an order of events similar to the systems development life
cycle (SDLC).

This module focuses on the steps that developers follow to model user
requirements of the system (analysis) and developing a model that will
meet these requirements (design).

There are different ways of approaching object-oriented analysis and

design. The method presented here follows a general structure, beginning
at the most simple level, moving towards more complex ideas that can be
transferred to the design stage, and then to the coding stage.

Remember that the ultimate goal is to produce a program that:

 Meets the requirements.

 Is reliable.
 Is maintainable.
 Is extensible (can be upgraded and enhanced without major changes).
 Is cost-effective (the long-term benefits of using the system outweigh the
original cost).

Analysis and design tasks

The modelling team needs to complete two tasks:

 Analysis
 Design

8.2.1 Analysis

The main task of analysis is to establish the user requirements of the

system. UML uses the following tools to model these user requirements:

 Use cases
 Scenarios
 Use case diagrams, which show how users interact with the system

8.2.2 Design

Once the analysts have established the user requirements, they address
the question of how to achieve these requirements. The analysts
reach a design of the model after examining how to achieve the
requirements.

UML makes use of the following tools to design the system:

 Classes and object diagrams.

 Sequence and communication diagrams, which show the interaction
between objects.
  State diagrams, which show the operations or behaviours of a single
object in the system.
 Activity diagrams, which model the operations (activities) of all objects in
the system for a specified process.
 Component diagrams, which model various software components (files,
modules, databases, etc.).
 Deployment diagrams, which show the required hardware components
and the hardware configuration of the system.

The main point of object analysis and design is to develop a model that
accurately reflects the business domain of the users. If the model does not
fit the real world situation, it is likely that the software will not do what is
required and that it will join the ranks of all the other useless software
that must be rewritten before it can be used.

Since UML is a standardised modelling language, most developers can

understand the UML models.

9.1. Notes
Use case analysis

For a program to function as it needs to, the modelling team have to

ensure that they understand exactly what is required. Generally, they use
the use case analysis technique to determine how people will use the
system and what they expect it to do. Involving the potential users of the
system at such an early stage increases the chances that the system will
indeed benefit these users once implemented. Use case analysis is also
known as requirements analysis.

Use cases

Use cases form part of the user requirements analysis in the SDLC.
Analysts use them to describe how a system will function from the point of
view of the users.

For the purpose of use case analysis, the system or program is seen as a
‘black box’. In other words, the analyst is not interested in how the system
achieves the result at this stage. All the use cases together make up all
possible ways of interacting with the system.

A use case is a function or task that a person, device or different system

performs as part of the user requirements. In a use case, the person,
device or system that performs the task is an actor. The use case must
contain a verb that describes the action by the actor.

A use case consists of a name that is a short statement or sentence.

Analysts can also use scenarios to describe use cases in more detail.
Scenarios explain the steps involved in the use case in more detail.
The description should be written in simple, clear language to ensure all
the team members understand exactly what they mean and what is
required. Some examples of use cases are:

 Register student.
 Calculate employee bonus.
 Print sales summary report.

Actors

An actor is the term used for anyone or anything that interacts with the
system. An actor could be a person, machine or another system that
communicates with the system. Note the following:

 Actors have goals, and the system should help the actor achieve these
goals.
 Actors refer to roles rather than actual people. The same person who
interacts with the system in two different ways is seen as two different
actors.
 Actors can be active, in which case they initiate sequences, or actors may
be passive, in which case the actors are on the receiving end of the result
of sequences. In other words, passive actors do not initiate sequences but
are affected by a sequence.
 Actors may be human or external systems. For example, a payroll system
may interact with a banking system.

Scenarios

A scenario is a particular instance of a use case that provides details on

how the use case actually happens from start to finish. Each use case may
have several scenarios that explain the ways that the use case can
happen. It is not possible to list all the scenarios as there would simply be
too many, and this would cause the analysis phase to take too long.
However, there are some scenarios that are important, which we will look
at now.

Essential and elaborate scenarios

We can write scenarios in two different ways:

 An essential scenario is one that deliberately excludes all references to

the exact nature of the user interface. For example, for a use case named
‘Check email’, an essential scenario would simply read ‘Client launches
mail program’, without specifying how it occurs. It has been suggested
that there should always be an essential scenario for each use case as it
shows more clearly what the user intended.

 An elaborate scenario is one that includes user interface details, and it is

possible that there will be more than one elaborate scenario for each
 essential scenario. For example, a user may use a mouse or a keyboard to
launch the mail program and these would be two separate scenarios. The
use case ‘Check email’ could include two elaborate scenarios: ‘Launch
mail program using mouse’ and ‘Launch mail program using keyboard’.

Primary and alternative scenarios

A primary scenario is a scenario that describes the use case when the use
case completes as expected without any errors. We also call this an 'all-
goes-well' scenario. Alternative scenarios are scenarios that should take
place when something goes wrong and the primary scenario cannot
complete successfully. It is necessary to capture most of the primary, all-
goes-well scenarios for each use case. Therefore, a primary scenario for
‘Draw cash’ would assume that a user has the correct access rights when
attempting an interaction (such as when a user enters a PIN number to
gain access to an ATM) and has enough money in the account to withdraw
the cash.

However, the analyst should also cover the alternatives or exceptions to

these primary scenarios (also known as secondary scenarios), such as
when a user enters an incorrect PIN number at an ATM, or there is not
enough cash in the account or in the machine.

For example, Figure 51 shows a possible use case titled ‘Draw cash’.

Figure 51 – A ‘Draw cash’ use case

Many people believe that at least 80% of the primary (all-goes-well)

scenarios should be included, as well as a few interesting and high-risk
alternative scenarios.

How to do a use case analysis

There are many ways of arriving at a use case analysis and the method
described below is just one of them. Remember that this is
an iterative process and that, as you identify and write use cases, it is
possible that the overall vision may change or evolve.

Finding the actors

A simple route to doing a use case analysis is to begin with the actors. Do
a brainstorming session with the design team aimed at identifying the
actors. To do this, begin with the vision statement and allow the team
members to simply name the people and systems that will interact with
the system.

Brainstorming is meant to generate ideas. At this point you should not be

deciding what role each actor will play, or even if they should have a role.
This session should find all possible actors, with no evaluation of the
actors at this point.

It is important to remember that in identifying actors, you are interested

in the roles people and other systems play, rather than the people
themselves. For example, one person could act as systems administrator
and accountant at the same time (dual roles are common in smaller
businesses). Clearly, this one person will interact with the system in two
different ways. Therefore, two actors represent one person but two
different roles. Remember that actors are external to the system. In other
words, they are not part of what the system does but rather interact with
it, initiating actions and getting responses.

Only once the actor brainstorming session is complete can the evaluation session
begin. Taking each actor in turn, you need to decide if each actor has a valid role
to play in communicating with the system. If an actor does have a valid role,
then you need to write use cases and scenarios for this actor (i.e. what this
person or system will do).

It is best to write use cases and scenarios in the active voice. For example, the
event:

‘The name is entered by the administrator’ (passive voice) should rather be

written as ‘The administrator enters the name’ (active voice).

You derive a use case name (‘Enter name’) from the statement and the actor
that will interact with the system is the administrator.

Another way of determining the actors and use cases is to first identify the
business or main events that are likely to occur in the system, and then
determine the use cases. Once you have identified the use cases, determine the
actors by asking the question ‘Who/what initiates the use case and who/what
benefits from the use case?’
Writing scenarios

Good scenarios should also follow an event/response model. This means

that when writing a scenario, include the actor that initiated the use case
and the actor that benefited from the use case, what the actor does and
how the system responds. The following example (Figure 52) expands on
the ‘Draw cash’ example.

Figure 52 – The ‘Draw cash’ use case

Questions to ask

Some of the questions below may help in finding the actors and the use
cases.

To find the actors:

 Who suggested this system?

 Where will this program be used in the business?
 Who will maintain and support the system?
 Who/what will supply the information that will be needed?
 Who/what will use the information being processed?
 Who/what will want to look information up on the system?
  Does one person play several roles?
 Do several people play the same role?
 Who/what initiated the use case?
 Who/what will benefit from the use case?

To find the use cases:

 What are the main business events in the system?

 What does a certain actor do?
 Will this actor put information into the system, do queries on the
information, or want reports or feedback from the system?
 Do any of the actors need to know about anything that happens in the
system?
 What will be needed to support and maintain the system?
 Are there any external changes that an actor would need to enter into the
system?
 Are all requirements covered by these use cases?

Use case diagrams

Play Video

Analysts can depict the use cases graphically in use case diagrams. These
diagrams show the relationships between the actors and the use cases
within a system.

Use the conventions shown in Table 3 when drawing use case diagrams.

Table 3 – Use case diagram symbols

Symbol Meaning

An actor is depicted using a stick man with

a role name.

Student

An ellipse shows a use case. The use case

name is written inside the ellipse.

Check course
____________________ An interaction is shown using a line. Arrowheads
are not required by UML but may be used to show
the direction the information is moving.
Billing system The system is shown using a rectangle which
indicates the system boundary and a system name.
Actors are placed outside the system boundary
(rectangle) and use cases inside the rectangle.
For the purposes of this module, we will only show the most general use
cases (known also as the system-level use cases) on the use case
diagram. That is, we will show the basic functionality of the system. We
will not show the details of gaining access to the system in this diagram,
although these can be shown on lower-order use case diagrams.

Figure 53 is an example of a use case diagram that illustrates a bookstore

system, which allows customers to order books and check their account
status. The bookshop assistant is also able to order books, open accounts
for customers and send the books to the customers when they arrive.

The accountant checks the customers’ accounts on a regular basis.

Figure 53 – A use case diagram for a bookstore

Advantages of use case analysis

A use case analysis has several advantages:

 It is a means of clearly defining the scope of the system, including what it

should be able to do and what is beyond the scope of the system.
 It identifies all actors who interact with the system.
 It clearly lays out the interactions between actors and the system.
 It ensures that the users are involved in the early stages of the analysis
and design of the system.

Use case example

The following example shows the events involved in a furniture removal
service that a company offers to clients to move goods from one location
to another.

The client meets with the removal company administrator and a contract
is drawn up for the delivery service. Once everyone has agreed on the
contract, they set a date for delivery of the goods.

On the day of delivery, the truck driver and delivery staff collect the goods
from the premises and deliver them to the new premises. On successful
delivery of the furniture, the truck driver hands a delivery slip to the client
who signs for the delivery. Once the goods have been delivered, the client
has seven days to make the final payment.

The analyst now follows these following steps:

 Find the actors.

 Write the use cases.
 Write the primary scenarios and any alternatives.
 Draw the use case diagram.

Find the actors

The actors involved in this event would be the company administrator,

client, and truck driver and delivery staff.

The main events that take place in this system are:

 The client and the company draw up a contract.

 The company prepares an invoice for the service.
 On the day of delivery, the truck driver and delivery staff fetch the goods
from the premises and deliver them to the new premises.
 The client signs for the successful delivery of goods.
 The client makes the final payment.

Write the use cases

The analyst can write the use cases from these events. Start the use case
with a verb and write a short phrase. The analyst identifies the following
use cases:

 Draw up contract.
 Prepare invoice.
 Deliver goods.
 Sign off for delivery.
 Make final payment.

Note: Even if two or more people/things can perform an event, the use
case is only mentioned once.

Primary scenarios and alternatives

The analyst lists the primary scenarios, followed by alternative scenarios
for each primary scenario. Alternative scenarios are the events that
should take place if the primary scenario does not complete successfully.

Next, we discuss each of the use cases in more detail.

[Link] Draw up contract

A company administrator draws up a contract stipulating the conditions of

the agreement between the company and the client. The client’s name,
address, phone and credit card details are stored on the system by the
administrator. The client signs the contract.

Alternatives:

 If the client does not have a credit card, he or she may pay via cash or
bank-guaranteed check.
 The company and client cannot come to an agreement on the contract.
The clerk cancels the contract and removes the client’s details from the
system.

[Link] Prepare invoice

The administrator prepares an invoice for the delivery service, which is

stored on the system. The invoice contains an invoice number, the client’s
details, date of delivery of the goods, removal address, delivery address
and the amount due. The client receives a printed copy of the invoice.

Alternatives:

 The client cancels the service. The clerk deletes the invoice from the
system.

[Link] Deliver goods

The truck driver drives to the removal address. The removal staff load the
truck with the stipulated items. The truck driver drives to the delivery
address and the removal staff transfer the items to the premises.

Alternatives:

 The truck is delayed in some way. The driver contacts the client
immediately and makes alternative arrangements.
 The delivery item or items are damaged in some way. The company
administrator and the client are contacted and arrangements are made to
replace or pay for the damaged goods.

[Link] Confirm delivery

The truck driver hands the delivery slip to the client to sign, which
stipulates that all goods were delivered successfully. The client signs the
slip and hands it back to the driver.

Alternatives:

 The client is not satisfied with the removal process. If the matter cannot
be rectified with the truck driver, the client must contact the administrator
to discuss the matter.

[Link] Make final payment

The client makes the final payment to the company by the stipulated
date.

Alternatives:

 The final payment is not made within the allowed time period as stipulated
in the contract. A notice for payment is sent to the client.

Use case diagram

The use case diagram shown in Figure 54 shows the interaction between
the actors and the system for the primary (all-goes-well) scenarios.
Alternative scenarios are not included on the use case diagram.

Figure 54 – Use case diagram for furniture removal example

Note: Try as far as possible to see that the interaction lines do not cross.
Note that more than one actor can carry out a use case. For each actor,
decide which use cases they would be involved in, using the interaction
lines to indicate this involvement.

Skip to main content

Print book

10.1. Notes
About the Unit

Object analysis focuses on understanding the problem and setting out the
requirements of the new system. Object design focuses on creating a
solution. This unit will look at transferring the user requirements to a
design that programmers can implement in code.

We will explain objects (and how they relate to entities called classes)
before taking the analysis phase further into object design. Remember
that object analysis and design are iterative processes, which means that
the requirements analysis might change as the analyst gains a better
understanding of the system requirements. These changes will also
impact on the design phase.

Objects and classes

Objects and classes are two key concepts in object design and object-
oriented programming, and we will examine both in this unit. Analysts
model software or programming objects after objects in the real world.
Possible examples of objects include a computer, a book, the desk or table
you are sitting at or the dog barking outside. All these things are real
world objects; they are entities, or things, that have sharp boundaries and
meaning. Object design provides a means of modelling real world objects.

A class is a template (or blueprint) of any entity or idea (concept) that we

need to model. The analyst designs a class for any entities or concepts
that a company wants to store information about. The class captures the
attributes and behaviours of that entity (more on attributes and behaviour
later). For example, a company wanting to store information on their
employees will design an employee class, containing the ID number,
name, address and contact number of the employee. These are attributes
of the class. The employee class represents the structure (a template) for
employees, but does not represent actual employees.

Objects are created from the class and represent real employees in the
company. For each employee in the company, there will be an object, but
there is only one employee class, regardless of the number of employees
in the company.

Classes are similar to a designer drawing a blueprint for a new car. Once
the blueprint is complete, the manufacturer can produce many cars
(objects) from it. The blueprint (class) itself is not the car, but it describes
the attributes of the car and what it can do (behaviours). A class diagram
reflects the classes and their relationship to one another.

An object is an instance of a class. In other words, an object (with its

unique attributes) is a specific case of the more general class. When you
start creating instances of the class, then you start creating unique
objects, each with its own data, functions and identity. So you could be an
instance of a Student class, water could be an instance of the Liquid class
and Ford could be an instance of the Car class.

An instance is the term we use to describe a particular object. For

example, Joe Soap is a particular student. He is an instance of the Student
class. Objects can be:

 Physical entities: these are tangible (they can be ‘touched’), for example,
a chair.
 Conceptual entities: these are intangible in that they exist, but as a
concept (they are intangible), for example, a part-time job or an
accounting process.
 Software entities: these objects are only relevant inside the memory of a
computer, for example, a linked list in the C++ programming language.

Each object has:

 An identity (it exists). An object always has a unique identity (in software,
it exists in memory at a certain address; in the real world, it has a physical
location, even if it has the same attributes as another object. For example,
there may be two students called John, but they are two different people,
each occupying their own space.
 A state, represented by the values of the attributes of the object at a
given time and in a given place, and can change with time and place. A
computer can be in the ‘state’ of ‘on’ or ‘off’. In a computer system, state
is represented by its data, for example, the value of the name attribute of
the student is ‘John’, and this is the current value of the variable name in
memory.
 Behaviour, which consists of a number of predefined operations that the
object can carry out. For example, openSunRoof() could be one of the
behaviours of the Car class.

Attributes and behaviour

All real world objects have attributes and behaviour, and so do their
software equivalents. In UML modelling, we refer to behaviour as an
operation. The attributes of a class store the data for the class.

In object design, object data and operations work together to make up a

software object that models its real world equivalent. The object
manipulates its data using operations that are also part of the object.

10.2.1 Attributes

Attributes describe an object. For example, a person has height, weight,

eye colour, and so on. These are a person’s attributes. A car’s attributes
could include colour, horsepower and number of doors. Each of these has
a specific value. The car’s colour may be white. This value could, of
course, change over time. Although currently white, after a car has been
re-sprayed it could be blue. This information is included in a software
object as object data, and the values are stored in program variables.
Attribute names are usually simple nouns or noun phrases, starting with a
small letter, e.g. name, studentName (not student_name). Variable names
should be descriptive, spelt out, if possible, and unique within a class (i.e.
you cannot have two variables with the same name in an object).
10.2.2 Behaviour

Behaviour refers to what an object can do and is usually something the

object does in response to a stimulus. For example, a car can brake and a
dog can bark. The set of behaviours an object has will determine how the
object performs. These behaviours are included in a software object as
operations (also known as functions or methods), and they operate on the
object data. The name of an operation should describe what the operation
does. You should write it as a verb or verb phrase, and with an initial small
letter followed by parentheses. For example, an operation to retrieve a
balance should be called getBalance(), and an operation to calculate a
balance should be called calculateBalance().

Consider the following example:

If an object were a PIHE student, data members could include a name,

student number and a set of marks. The system would need to activate an
operation when a student starts at PIHE, so that the system allocates a
name and number to the new student. The system would also need an
operation to enter marks. There could also be operations that calculate
the average mark, or print or display data. All the data and operations
together make up the student object.

Encapsulation

The data in a class should be hidden from other classes, and should only
be accessible in a controlled fashion. See Figure 55:
 Figure 55 – Encapsulation hides class data from other classes

We call this style of design encapsulation or data (information) hiding.

Encapsulation allows the interface to be visible to other objects
(operations or methods that are needed by outside objects are visible),
but all data and any methods that are internal to the object are hidden.

Compare this to driving a car. To stop the car, you need to press the brake
pedal (the interface function). You do not need to know exactly how it
stops the car or which data items are changed (the implementation). All
that you are concerned with is that the car stops. Similarly, a graphical
user interface (GUI) allows the user to perform many functions by clicking
on different icons. The user does not know, and does not need to know,
how the program performs these functions (for example, make print bold).
The implementation of the functions is hidden from the user. Data items
and operations that are hidden are private, whereas operations that are
visible (the interface functions) are public.
Encapsulation has two major benefits:

 Data hiding: As a user, you can use the member functions of a class to
manipulate the data members without having to know how the system
manipulates the data. Hiding data from users is the safest way of dealing
with data and protects the object from illegal users.
 Reusability: Programmers can write the code for a class without affecting
the code in other classes. Changes will affect only the class containing the
applicable code.

11.1. Notes
About this Unit

In this unit, we discuss how UML depicts classes. We then discuss

association, containment and inheritance. Finally, we discuss relationships
between objects (depicted by class diagrams). It is important to note that
often the relationships described below are relationships between objects
(instances of classes), and not relationships between the classes
themselves.

Class related concepts

We cover the following class concepts:

 How UML depicts classes

 Association
 Multiplicity
 Containment
 Inheritance

Classes in UML

UML depicts a class as a rectangle with the class name, attributes and
behaviour indicated in separate sections (see Figure 56).
Figure 56 – UML diagram for a class called Vehicle

Use the following naming conventions for class diagrams in exercises,

projects and examinations:

 A class name always starts with a capital letter.

 Attributes and operations always start with a lowercase letter.
 Operation (behaviour) names end with a set of parentheses, e.g.
getSalesReport().
 Class names, attributes and operations may not contain spaces.
 When a class, object, attribute, or operation name consists of more than
one word, each subsequent word must start with a capital letter, for
example, MyCar, dateOfPayment, makePayment().
 All names should be as descriptive as possible.

Association

Two or more classes that collaborate with each other in some way are
usually related through association.

For example, Figure 57 shows the relationship between Instructor and

Course as an association. Here, we can say that an instructor teaches the
course or that the course is taught by an instructor.

The UML diagram shows association using a solid line.

Figure 57 – Association

Multiplicity

Multiplicity, or cardinality, refers to the number of instances of one class

that are related to an instance of another class. Multiplicity indicates
details about the association between classes.

Multiplicity can show whether an association is mandatory or optional, as

well as the maximum and minimum number of instances that can occur in
the instance. In UML, we write the multiplicity symbols below the
association line. Table 4 lists the various multiplicity symbols.

Table 4 – Multiplicity symbols

many *
exactly 1

1
0 or 1

0 ...1
0 or more

0 ... *
1 or more

1 ... *
specific number

2 ... 4
For example, Figure 58 shows the association between a course and a
student. The academic institution will not run a course for less than 5
students and there is a maximum number of 20 per course. A student
may register for any number of courses.

Figure 58 – An example of multiplicity symbols

We can explain this in more detail using Figure 59. To indicate multiplicity
on a class diagram, we first create an association between the classes. To
determine values for multiplicity, consider one of the classes first.

For example, consider the Student class. Ask, ‘How many instances of the
associated (Course) class relate to one instance of this (Student) class?’
The answer is, ‘from zero to any number’, as one student may take none
to any number of courses. We indicate this value as 0...*, and write it next
to the associated class (Course).

Similarly, we can ask, ‘How many instances of Student relate to one

instance of Course?’ The answer is, ‘One course may be taken by a
minimum of 5 but a maximum of 20 students.’ We show this value next to
the Student class as 5..20.

If we combine the multiplicities between Student and Course, and

between Course and Student, we arrive at the class diagram in Figure 59:
Figure 59 – Multiplicity between two classes

NOTE

When indicating multiplicity in a class diagram, only show one association

line (as in Figure 58), and not two separate associations, as in Figure 59.

Containment

Containment refers to an object that is composed of many sub-objects.

The word ‘has’ often indicates containment. For example, a car has tyres,
doors, an engine, and so forth; a human body has arms, legs, a heart, and
so on. This is a specialised form of association in which the whole is
related to its parts.

We indicate containment by a diamond on the end of the association line

next to the object that represents the whole.

There are two types of containment:

 Aggregation
 Composition

Aggregation and Composition both refer to the member object. The

only difference is the survival or existence of the member object without
the containing class/object. Aggregation is also known as a ‘has a’
relationship because the child (member object) can survive or
meaningfully exist without the parent (containing class/object) after the
life cycle of the containing class.

Example 1 (has a): Room has a chair and the chair can exist without the
room. Furthermore, the chair can have a meaning without the room also.
Example 2 (has a): Car has a passenger and the passenger can exist
without the car. Furthermore, the passenger can have a meaning without
the car.

Composition is also known as a ‘is a part of’ because the child

(member object) cannot survive or meaningfully exist without the parent
(containing class/object) after the life cycle of the parent class.
Composition is also used instead of inheritance when different roles are to
be played by a single entity. This is where the ‘is a’ relation is
implemented.

Example 1 (is a part of): Computer Science Department is a part of the

college. The Computer Science Department cannot meaningfully exist
without the college after the life cycle of the college.

Example 2 (is a): A person is a manager. A person is a husband. Manager

and husband are the roles played by a single person. The husband role
without the person cannot exist and has no meaning, and the same
applies to the manager role.

NOTE

Figure 60 includes relationship naming for explaining the diagram.

Students must refrain from including relationship naming on any of the
diagrams.

Figure 60 – Aggregation and Composition association

From the figure above, Battery and Smart

Phone indicate Aggregation while the other relations
indicate Composition. The Smart Phone has a Battery. The Battery can
exist and have a meaning without the Smart Phone. The IMEI Number,
however, is a part of the Smart Phone and its existence completely
depends on the existence of the Smart Phone. The IMEI Number has no
meaning without the Smart Phone. The relationship between the IMEI
Number and the Smart Phone explains the ‘is a part of’ type of
composition.

Inheritance

Let us say that we want to model the attributes and behaviours of a

variety of insects. We could create a class to represent each insect and
include the characteristics (attributes and behaviours) within those
classes. However, there are characteristics that are common to all or
some of the insects (for example, bees and moths are both flying insects).

If we repeat common characteristics in different classes, this causes

redundancy in the software model. One problem with this approach occurs
when we need to change the model. If the same characteristic occurs in
different classes, we have to change all of those classes. However, if we
could group common attributes and behaviours into one class, we would
only need to make changes to that one class, thereby reducing or
eliminating redundancy.

Software modelling uses the concept of inheritance (also known as

generalisation) to achieve this. With inheritance, we can create a class or
classes that contain common characteristics and which other classes may
inherit. A base class or superclass is a class that other classes inherit
from. The inheriting class is the derived class or subclass. Single
inheritance occurs when a derived class inherits from only one base
class. Multiple inheritance occurs when a derived class may inherit
from more than one base class.

In UML, inheritance is modelled in a hierarchical (top-down) fashion, with

the base class at the top of the hierarchy and derived classes lower down
the hierarchy.

Derived classes are a ‘type of’ the base class. If we have an Insect class
at the top of the hierarchy, we could classify them into Flying and
Crawling insects, and say that flying and crawling insects are ‘types of’
insects. Expanding the hierarchy further, we could say that bees and
moths are types of flying insects and that beetles and worms are types of
crawling insects.

Figure 61 models the insect example, showing the inheritance

relationships:
Figure 61 – Insect example showing inheritance

We show inheritance by a hollow-headed arrow pointing to the more

abstract or base class. Encapsulation already has advantages for
programmers in that they can develop a class independently, and once
the class works effectively, other programmers can use it in their own
systems. Inheritance takes this a step further as other programmers can
take an existing class, inherit it and, without modifying it, add additional
features to extend the existing class to suit their own needs.

NOTE

Use inheritance conservatively when programming. The answer to the

question, ‘How does the structure and design of the superclass affect the
structure and design of the subclass?’ is a good indication of when to use
inheritance. For example, creating buttons on a GUI is a good example of
when to use inheritance. The construction of a general button with a label
on a GUI that does something when clicked can easily be modified to do
something else, or be named something different. Each modified button
will inherit the general characteristics of a general button with the added
enhancements.

Class diagrams

A class diagram expresses the relationships between classes using UML.

Be careful not to include too much detail when constructing class
diagrams. Until you actually start programming using object-oriented
methods, look at the class diagrams that you will draw from a conceptual
point of view. You need general classes to accomplish the set
requirements. Concentrate on the key areas for now.

Once you move into the wider world of class diagrams, you will find that
there are different varieties of notation that you can use, many of which
will add further detail to the class diagram. But for the moment, stick to
the classes and relationships (using multiplicity, where necessary).
Play Video

Class diagram example

The following example combines the concepts learnt in this unit into a
UML class diagram (see Figure 62).

In this example, the diagram models the relationships between classes for
the flight reservation system of an airline.
Figure 62 – Class diagram example

Note the following points from the class diagram:

 The Flight class contains the details for a specified flight.

 Attributes of the class are listed below the name of the class in the centre
of the class.
 The operations or behaviours of the class are listed in the lower section of
the class.
 Operations starting with a ‘set’ prefix modify or update the specified
attribute, whereas those with a ‘get’ prefix return or store the value of the
corresponding attribute. For example, setFlightDate() modifies an existing
date or sets a new date for a flight.
 There are two types of flights, namely domestic and international, and
these inherit attributes and functions from the Flight class.
 Both International and Domestic classes are a type of the Flight class.
  All attributes and operations in the Flight class are inherited by (belong to)
the International and Domestic classes.
 The International class stores the country of destination, stopover
destination and arrival date (the arrival date may be different from the
departure date).
 There may be discounts offered for domestic flights and certain special
offers not available on international flights.
 The Passenger class is linked to the Flight class through association. • The
Meal class shares an aggregate relationship with Flight.
 An instance of the Meal class cannot exist without belonging to an
associated flight but the Flight class can exist without an associated Meal
class.

In the projects, you are required to include the attribute data types. A
data type is a classification of the type of data that a variable can hold.
The table below lists the most common data types:

Data Description
type

boolean Expressions that result in a value of either true or false.

integer Stores a numeric value. E.g. “1, 2, 3, …”
string Stores content that is both letters and numbers. E.g. “1a2b3c”.
character Stores a single character. E.g. “A”.
float Stores a floating number. E.g. “1.23, 52.254, 19455.1”.

12.1. Notes
About the Unit
In this unit, we look at how UML represents objects. We then discuss how
objects interact with each other and how to represent these interactions in
UML.

12.1 Objects
UML represents objects by a rectangle divided into two parts. We write the
object name in the top section, followed by a colon, and then the name of
the class to which the object belongs. For example craigsCar:Car
represents an object of the Car class, called craigsCar. Notice that the
entire class name is underlined.

We can also name objects by using only the class name or object name:

 Class name only: used when we are not interested in any specific instance
of the class, for example, :Car (note the use of the colon). This is as an
 anonymous object. We normally use an anonymous object when we want
to show only one object of the class in a diagram. When we want to show
two or more objects, we use the full naming convention.
 Object name only: used when we have identified an object, but do not yet
know which class the object will belong to, for example, craigsCar. We
normally use this method in the earlier stages of analysis, before we have
identified all the classes.

The bottom section of the rectangle lists the attributes that the object
may have. The attribute list is optional, as they are always included in the
class diagram. The attribute list contains the name of the attribute
followed by a colon, and then the attribute type and value, for example,
colour: String = ‘red’ indicates that the colour attribute is of type String
and has a value of red.

Figure 63 shows the craigsCar object and shows it as a UML object,

including attributes.

Figure 63 – Object diagram including attribute list

Figure 64 shows the craigsCar object drawn without the attributes section.

Figure 64 – UML object without attributes list

The following naming conventions apply to UML objects:

 The name of the class to which an object belongs is underlined.

 The object name starts with a lowercase letter, terminated by a colon,
followed by the name of the class of which it is an object, but may consist
of the class name or object name only, as mentioned above.
 Attributes may be included in the attributes section of the object.
 If attributes are included, they must be named. The attribute type and
value are optional.
 All object, class and attribute names should be as descriptive as possible.
12.2 Object interaction
Each object interacts with other objects through messages sent from the
initiating object to a receiving object. The receiving object must respond
to the message by activating an operation (behaviour) corresponding with
the message. The operation or behaviour is one that is contained in the
class diagram of the class of which the object is a member. For example,
in a retail system, a Customer object can send a message called
createInvoice() to an Invoice object. The Invoice object should contain an
operation called createInvoice(), which executes all the required steps to
create the invoice.

Object interactions in UML are normally modelled to include the user that
is initiating the interaction between the objects. The users that are
involved are the actors in use cases and use case diagrams. The UML
models object interactions by using interaction diagrams. There are
four types of interaction diagrams:

 Sequence diagrams.
 Communication diagrams.
 Interaction overview diagrams.
 Timing diagrams.

We often refer to object interactions as use case realisations, because the

operations in class diagrams or the messages in interaction diagrams are
derived from (or realised by) the use case scenarios.

In this module, we will discuss the two most important UML interaction
diagrams, namely sequence diagrams and communication diagrams.

12.3 Sequence diagrams

Play Video

During the analysis phase of object-oriented software development, we

capture user actions in the use case diagrams and describe them using
scenarios. How the program achieves this interaction between objects is
determined during the design phase. The use case scenarios provide the
sequence of events that objects must follow when communicating with
one another, and we show this in the sequence diagram. The sequence
diagram therefore focuses on the time flow between events from top to
bottom. The emphasis in a sequence diagram is on interaction between
objects and not what goes on within the objects.

Table 5 shows the symbols we use in a sequence diagram.

Table 5 – Sequence diagram symbols

Symbol Meaning

A lifeline represents
how an object or
actor participates in
an interaction. It also
represents flow of
time as seen by the
object or actor. The
lifeline is represented
by the object and a
dashed tail
descending from the
object. Any point
lower on the tail
represents a later
time than a point
higher up.

The tall thin rectangle

represents the period of
time during which an
object executes
messages. We say that
the object has the focus
of control or activation.

A message (object
interaction) is indicated
by an arrow that starts at
the lifeline of the object
sending the message,
and points to the top of
the activation of the
object that will receive
the message. We write
the message to indicate
an operation (behaviour,
function, method). In
previous versions of
UML (before version
2.0), messages were
optionally numbered to
indicate the sequence of
events. The UML 2
specification does not
allow message
numbering for sequence
diagrams.
An
object create message is
indicated in the same
way as other messages
by an arrow pointing
towards the object to be
created. We write
a <<create>> message
above the message line.
This indicates that an
instance of that class
(object) needs to be
created at the present
time, with the object
appearing lower down in
the diagram than objects
that were present at the
start of the interaction.

In this module, we will

specify if an object
needs to be created at a
specific time. We will
then use
the <<create>> message
and the object will
appear lower down in
the diagram (at a later
time) than objects that
already exist.
An
object destroy message
is similar to an object
create message in that it
consists of an arrow
pointing towards the
object to be destroyed
and
a <<destroy>> message
above the arrow. A cross
at the end of the arrow
and underneath the
lifeline of the object
indicates the destruction
of the object at that time,
and terminates the
lifeline of the object.
This means that the
object has been deleted
 (removed from
memory).

In this module, we will

specify if an object
needs to be destroyed at
a specific time. We will
then write
the <<destroy>> messa
ge with the cross
indicating the deletion of
the object.
Each sequence diagram consists of objects, messages and time (shown
vertically). The objects that exist for the duration of the interaction are
arranged at the top of the diagram from left to right, and each has a
lifeline extending downwards from it that shows how long the object
exists. Most objects exist for the duration of the interaction, so their
lifelines will extend from the top to the bottom.

The focus of control, or activation, shows the length of time an object

performs a particular action on the lifeline. The longer the time spent on
the activity, the longer the focus of control. If a sequence diagram were to
show the logic behind an activity, it would show it within the focus of
control. The activity diagram shows the internal logic, which we will
discuss in Unit 14.

12.4 Sequence diagram example

Figure 65 represents the sequence of interactions for a user making a
cash withdrawal at an ATM machine. This corresponds with a ‘Withdraw
cash’ use case. The person using the ATM (user) initiates the transaction.
The following objects are used:

 ATMUI: the user interface of the ATM machine. This represents the front
of the machine, where the user can enter details and request transactions.
 Session: a session object is created when a user enters his or her ATM
card and is destroyed once all transactions have been completed and the
card is returned to the user. The Session object controls all transactions
that take place between the user and the ATM.
 Transaction: creates the transaction type (deposit, withdrawal, balance
enquiry, etc.)
 Account: the user’s account. The account is created once the user’s pin
number has been successfully entered and destroyed once the card has
been returned to the user.
Figure 65 – Sequence diagram for the ‘Withdraw cash’ use case

We can explain Figure 65 as follows:

 A Session object is created when the user inserts his or her card into the
ATM.
 As soon as the Session object is created, the ATM prompts the user to
insert his or her pin number.
 The system checks the pin number to ensure validity.
 Once the system has checked the pin number, the user requests a
withdrawal (transaction).
 The request is sent to the transaction object, which sets the type of
transaction to Withdrawal.
 The user enters the amount to withdraw. The Transaction object sets
(stores) this amount.
  The Transaction object sends a message to the Account object of the user
to check that the available balance is not less than the amount requested.
 The system debits the user account by the requested amount.
 The ATM User Interface object delivers the money to the user

12.5 Communication diagrams

The interaction between objects shown by a sequence diagram is also
shown by a communication diagram, but from a different perspective. A
sequence diagram shows a top-down (side) view, whereas a
communication diagram shows a view from the top (a bird’s eye view).
Communication diagrams show the configuration of an interaction and
how the lifelines connect. Communication diagrams use links instead of
lifelines.
Play Video

Communication diagrams link interacting objects by means of a line. The

diagram shows messages passed between the objects as a separate arrow
pointing towards the receiving object. We write the message above or
below the link.

We number each message to show the sequence in which the system

executes the messages. Remember that communication diagrams do not
indicate the flow of time as the sequence diagram does.

Communication diagrams contain less information and are not as user-

friendly as sequence diagrams.

NOTE: In previous versions of UML, communication diagrams were known as

collaboration diagrams.

Table 6 shows the symbols used in a communication diagram.

Table 6 – Communication diagram symbols

Symbol Meaning
An object is represented in the same way as in a
sequence diagram, but does not include the
lifeline.
A link is symbolised by a straight line
connecting two objects.
A message is indicated by an arrow, which
points to the object that will receive the
message. The message is written next to the
arrow and is labelled according to the sequence
 Symbol Meaning
in which it occurs. A colon separates the
number from the message. The message is
written to indicate an operation (behaviour,
function, method).
Drawing a communication diagram is easier if the components of the
diagram are drawn in the following order:

1. Place the objects in a logical order, such as at the corners of a triangle or

rectangle.
2. Connect the relevant objects with lines to show the links.
3. Add the messages that the objects send and receive above or below the
links.

12.6 Communication diagram example

The example in Figure 66 shows a communication diagram for the use
case scenario ‘Withdraw cash’. It corresponds with the sequence diagram
shown earlier.

Figure 66 – Communication diagram for the ‘Withdraw cash’ use case

Note the following points regarding Figure 66:

 The lines connecting the objects are called links, and are drawn separately
from the messages, the directions of which are indicated by arrows.
 Each message is numbered to indicate the sequence of messages of the
process.
 The <> and <> messages are numbered in a slightly different way to the
other messages.
 The numbering sequence 1.1: <> indicates that the object (the Session
object in this case) is created as part of the operation that is numbered 1,
and not as a separate operation. In other words, the Session object is
created within the insertCard() operation itself. In the same way, other
create and destroy messages are numbered with respect to
the preceding operation.
 In general, a create or destroy message numbered x.1 is created as part of
the operation numbered x.

Notice that table 5 and 6 for sequence and communication diagrams,

respectively, do not include a stick man as part of the symbols, but it is
used in the example diagrams. This is because a stick man is only
applicable when drawing the diagrams. Modelling the diagrams a class
object is used instead, unit 17 demonstrates this. The use of a stick man is
limited to the module exercises and the exams. The projects, however,
will make use of class objects
14.1. Notes
14.1 Activity diagrams
Play Video

In UML, an activity diagram shows the internal logic (or workflow) of the
system. An activity diagram models the functions or tasks that occur
during a system operation or process. These diagrams specifically model
the business activities of a system.

Unlike flowcharts, activity diagrams can also show parallel processing and
decisions that are not just based on a ‘yes’ or ‘no’ answer, but on multiple
results.

Drawing activity diagrams early in the modelling process can help you
understand the overall process of the system. An activity diagram may
also help identify the various components of the use case model, and to
model a particular use case scenario. You can use it to model the whole
system to show the flow of control from one activity to another. You can
also use activity diagrams to identify classes.

Table 8 shows the symbols used in an activity diagram:

Table 8 – Activity diagram symbols

Symbol Meaning
An activity. Before
another activity can
occur, processing
within the current
activity must complete.
Each activity has a
precise beginning and
end.
Initial node (start
point) of the activity
diagram.

Final node (end point)

of the activity diagram.
A transition from one
activity to another.

A decision node. The

guard conditions appear
in square brackets next
to the transition lines
that come from the
decision point, which is
a diamond shape. You
can draw as many
transition lines as you
need from the decision
point.

NOTE: You can also

represent a decision
node as transition lines
coming from an
activity, with no
triangular decision
point shown.
A thick bar, called
a synchronisation bar,
indicates transition
paths that split into two
or more paths that run
concurrently (at the
same time). Another
synchronisation bar
indicates where the
paths again join. We
call the first
synchronisation a fork
node and the last
synchronisation a join
node.

The entire process is

called concurrency (al
so known as parallel
processing in earlier
versions of UML).

In the example
diagram, the ‘Eat
breakfast’ and ‘Read
newspaper’ activities
can occur at the same
time, but the ‘Go to
work’ activity can only
start after these have
been completed.
 Activity partitions (als
o known as swimlanes
in earlier versions of
UML) are demarcated
areas that show which
actors are responsible
for the activities that
take place in each
‘lane’.

The name of the actor

is at the top of the
partition. Partitions are
the actors in a use case.

In the example to the

left, Shopper and Till
assistant are the
partitions.

14.2 Activity diagram examples

Proceed

14.2.1 A simple activity diagram

Every two weeks, a staff member checks and records the stock levels of
ingredients for a coffee shop. He or she then logs into a system and
completes an online order form and then mails it to the manager for
approval. Only then, the order form is mailed to the supplier. A simplified
activity diagram of this process could look like the following (see Figure
70):
Figure 70 – Simple activity diagram

14.2.2 Activity diagram showing partitions and decision

nodes

The following example expands on the coffee shop order process.

Every two weeks, a staff member checks the stock levels of ingredients
for a coffee shop and places an order for stock that has fallen below the
reorder point.

The staff member prints a list of ingredients from the system and then
enters the storeroom, where the ingredients are kept. The stock level for
each ingredient is recorded on the ingredients list. The staff member then
compares the stock level to the reorder point for each ingredient, marking
ingredients that fall below the reorder point. Once this is completed, the
staff member hands the ingredients list to a clerk who completes an
online order form.

Once the form is completed, the clerk emails it to the branch manager for
approval. The manager checks the form and if the order is approved,
returns it to the clerk who emails the order to the supplier. If the order is
not approved, the clerk is informed and the process ends.
Figure 71 shows the activity diagram including partitions and decision
nodes:

Figure 71 – Activity diagram for coffee shop

14.2.3 Example showing partitions and concurrency

For a particular online shopping site, shoppers must fill in their personal
and credit card details on a registration form before purchasing goods.
The system then processes the shopper’s details and verifies their credit
card details. Registration is not complete until the bank confirms the
credit card details are correct. If the system is unable to verify the credit
card details, it displays a message notifying the shopper that registration
did not take place and the order will not be processed. While the system is
processing the application, the shopper may view the goods on offer and
add items to the shopping cart. Once registration is complete and the
shopper has added all items to the cart, he or she can click on the
Checkout button and the system will process the order.

The activity diagram in Figure 72 describes this process:

 The online shopper fills in a registration form.

 The system displays the goods for sale, allowing the shopper to add goods
to the shopping cart and processes the shopper’s registration application
at the same time. This is indicated by the solid bar above the two
activities.
 The system gets the shopper’s details from the registration form and
sends the credit card details to the bank.
 The bank checks the credit card details and determines whether the credit
card details are valid (this decision is shown by the diamond symbol). If
they are invalid, the bank sends a message back to the system notifying it
of this.
 The system in turn notifies the shopper that his or her registration was not
accepted and that he or she may not shop.
 If the credit card details are correct, the bank notifies the system of this.
 The system completes the registration process by registering the shopper.
 Parallel processing ends with completion of registration (indicated by the
second solid bar).
 The shopper can now click the Checkout button.
 The shopping order is processed and the whole process ends.
Figure 72 – Activity diagram for an online shopping site

15.1. Notes
About The Unit
The diagrams discussed so far have been the most commonly used
diagrams in UML. A further two diagrams, the component and the
deployment diagrams, deal specifically with computer systems and
software development, especially in projects that are team based.

Table 9 shows the symbols used in component and deployment diagrams.

Table 9 – Component and deployment diagram symbols

Symbol Meaning
Component: the
component’s function is
written inside the
component.

Interface: shown as a
rectangle and can include
attributes and operations in
the same way as a class. The
word ‘interface’ must appear
above the name, enclosed in
guillemets (<< >>).

Interface realisation: can be

shown in two ways:

1. As a circle attached
to the component by
a solid line,
indicating that the
component
implements an
interface. The name
of the interface
appears above the
circle.

2. As a realisation arrow
pointing from the
component to the
interface. The arrow
line must be dashed.

Relationship between
components.
 A node: the type of node is
shown in guillemets within
the cube.

Devices may be shown as

nodes, but the word ‘device’
should then appear in
guillemets in the symbol, i.e.
<<device>>.
Association between nodes.

Represents the Internet.

15.1 Component diagrams

Play Video

The component diagram shows how software components are

organised and how they relate to each other within a program. This
diagram describes the physical things that make up the working part of a
software-intensive system, rather than the logical view. A component
provides various operations through an interface.

For example, there are ‘buttons’ on most GUIs. A button is normally

rectangular and has a name or icon printed on it describing its function. If
a user clicks the maximise button in a Microsoft Word document, the
document maximises to fill the window. How this happens is of no concern
to the user. The button acts as an interface between the user and the
component that maximises a window. Clicking on the button activates the
component attached to the button.

A software component could be an independent piece of source code, a

data file, an executable file, a library file, or a general index file. It should
ideally be reusable in different software systems with little or no change.
A UML component and interface are shown in Figure 73.

Figure 73 – A software component with its interface in UML

In the top part of Figure 73, the interface is drawn separate from the
component. The circle attached to the component indicates that the
component implements an interface. The name of the interface that it
implements is indicated above the circle, i.e. Menu.

The second example at the bottom of Figure 73 shows an alternative way

of drawing a component/interface relationship. The implementation is
indicated by a dashed, hollow arrow (called a realisation arrow) pointing
towards the interface.

15.2 Component diagram example

A company runs a simple computer system to manage employee
information. The employee records are stored in a database on a server. A
sort program sorts the employee records into ascending order according
to the employee number. A menu acts as an interface between the user
and the sort program. The Menu interface contains an operation called
Sort() which is implemented within the sort program. It is important to
remember that the interface does not contain any implementation itself.
The Employee database inherits the Sort() operation from the Sort
Program.

The component diagram in Figure 74 shows the different components (a

sort program and an employee database), namely the interface to access
the components, and the relationship between the components.

Figure 74 – Component diagram for employee record system

An association links the Employee database component to the Sort

Program component. The half circle icon shows that the Employee
database uses the Menu interface’s Sort() operation from the Sort
Program component. We call this ‘ball and socket’ notation.

15.3 Deployment diagrams

A deployment diagram shows the physical architecture of the system,
the computers and devices, and how they connect to one another. The
general term that describes a computing resource (that is, what is needed
to execute components) is a node and this is represented in a
deployment diagram as a cube. There are two types of nodes, namely
processors and devices. You can think of the processor nodes as the
‘brain’ of a system. They execute components (they are the ‘processors’
of the system), for example, any processing unit, such as a server or the
‘box’ that contains the CPU of a PC. Device nodes, on the other hand,
cannot execute components. They are interfaces and contain no
processing power.

Devices are just a means of getting information into and out of a

processing unit, for example, a keyboard or mouse. The components that
are dependent on the node may be drawn on the node or labelled on the
node (see Figure 75). We write the name of the node in lowercase letters
at the top of the node. We write the type of node just above the name and
enclose it by guillemets (i.e. <> or <>).

Figure 75 – Different ways of representing a node in UML

Generally speaking, the relationship between nodes is that of direct

association. That is, they are physically connected to one another by, for
example, Ethernet connections, ISDL lines or fibre optic cables. Nodes
may also form an indirect association with one another (they may be
indirectly connected), as in the case of a satellite link.

15.4 Differences between nodes and

components
Components and nodes are similar in their basic characteristics, but there
are important differences. Nodes differ from components in the following
ways:

 Processor nodes can execute components. Components are a part of the

execution of a system.
 Nodes show how the components are physically deployed (or set up).
Components represent the logical elements of the system.

15.5 Deployment diagram examples

Proceed

15.5.1 Deployment diagram example 1

To run the employee record system described earlier in this unit, we need
to determine the different nodes that we will need and then map the
relationship between them. There is now a printer in the system so that
we can print information from the server. Figure 76 shows the deployment
diagram for this example.

Figure 76 – Deployment diagram for the employee system

15.5.2 Deployment diagram example 2

The deployment diagram in Figure 77 shows the physical architecture of a

home computer system that has access to the Internet. Telkom provides
the phone connection and the link to the Internet is via satellite.

NOTE: The Internet node is a cloud symbol. The devices may be shown
graphically.
Figure 77– Deployment diagram for a home computer system
16.1. Notes
16.1 Source Code Versioning Platforms and
Control
A component of software management is version control, also known as
revision control or source control. This is the management of changes to
documents, computer programs, large websites, etc. These changes can
be easily identifiable by indication of a number or letter code, i.e. ‘revision
number’.

Example: The initial version of a document is labelled Version 1. After the

software manager has edited the document, he/she updates the version
number to the next logical code, in this case, Version 2.

The need for such a system has existed for as long as humanity has been
writing, but became more important and complicated when the computing
era began.

In software engineering, revision control is any kind of practice that tracks

the changes to source code, documentation or configuration files, allowing
users to view previous, current, deleted and edited versions.

There a many different programs and sites that can be used to help
manage these changes:

 Client-server Open Source Versions:

o Concurrent Versions System (CVS)
o Subversion (SVN)
o Vesta
 Distributed Open Source Versions:

o ArX
o Bazaar
o Git (GitHub)

NOTE: There are many more systems and versions, but for this module we will be
focusing on Git (GitHub).
Git was designed by Linus Torvalds based on the needs of the Linux
Kernel project. The platform was coded in a collection of Perl, C and
various other shell scripts. Git was created in 2005. It is one of the most
used Code Versioning Platforms to date as it allows all types of users, from
individuals trying to share their code examples with friends, to companies
looking for a safe storing and sharing environment. (For more information,
please visit: [Link]

Below are a few screenshots of the basic github screens:

 - Main Page -

- Your Repository (Containing all your projects) -

- Github how to Guide -
 - Starting a new project page -

16.2 Issue Management Platforms

Issue management platforms are also known as ‘Defect Tracking Systems’
or ‘Bug-Tracking systems’. These systems allow individuals or groups of
developers to keep track of outstanding bugs in software. Most bug
detection/tracking software charges users a huge licensing fee, despite
being labelled ‘free’. We will be using ‘Bugzilla’ as our example platform
for the rest of the unit.

- Bugzilla ([Link] -

What does Bugzilla do?

 Tracks bugs and code changes.

 Allows for communication between team mates.
 Allows for submission and review of software patches.
  Manages quality assurance.

Bugzilla can help users get an easier grip on the software development
process. Here are a few advantages of Bugzilla that make it one of the
best Issue Management Platforms available today:

 Being actively developed.

 Being constantly put to the test by the Mozilla Foundation.
 Supported by a dedicated team.
 Has countless features that most expensive solutions lack.
 Trusted by world leaders in technology.
 Can be installed on many operating systems, including Windows, Mac and
Linux.

Bugzilla provides a wide range of possible uses such as:

 Systems administration.
 Deployment management.
 Chip design and development problem tracking (both pre- and post-
fabrication).
 Software and hardware bug tracking.
 IT support queues.

NOTE: Bugzilla has reportedly reduced downtime, increased

productivity, raised customer satisfaction, improved
communication and reduced costs for many different companies.
16.3 Continuous Integration Platforms
Continuous Integration (CI) is a development practice that requires
developers to integrate code into a shared repository several times a day.
Each check-in is then verified by an automated build, allowing teams to
detect problems early. During the continuous integration process,
developers share and merge their changes (code and unit tests) into a
united version control repository upon the completion of every project
task.

Continuous integration carries a lot of advantages. Here are some of the

advantages that come with continuous integration:

 CI aids in avoiding merge conflicts, difficult-to-fix bugs, duplicated code

and discrepant coding strategies
 CI helps to minimize the time for code review and makes the project code
more homogenous
 CI fast tracks the development process and pushes releases closer
 CI ensures continuous feedback
 CI helps to decrease the project backlog

There are currently a wide variety of tools for continuous integration from
which you can choose. Depending on your business strategy, you may
want to get a free Open Source or a commercial CI solution. You should
also ensure that the tool you have chosen allows for simple project
management and transfer. Opting for a platform that can visualise the
content is also a smart idea.

Here are a few examples of Continuous Integration platforms:

 Jenkins.
 TeamCity.
 Travis CI.
 Go CD.
 Bamboo.
 GitLab CI.
 CircleCI.
 Codeship.

NOTE: The Jenkins platform will be used as an example for the rest of the unit
16.3.1 Jenkins CI solution

Jenkins is one of the most popular free open-source CI solutions that is

widely used in software engineering. It is a server-based CI application,
written in Java that requires a web server to operate on. Thousands of
users all over the world love working with Jenkins as it allows automating
builds and tests quickly.

There are six advantages to using the Jenkins platform:

 Continuous Integration
 Continuous Delivery
 Easy Installation
 Easy Configuration
 Plugins
 Extensibility
 Distributed Workspace

Installing Jenkins on Windows

Jenkins can be downloaded for free on the Jenkins website

here [Link]

Jenkins can be installed in a variety of platforms. In this module, we shall

be installing and using Jenkins on Windows 10.

Follow the following video for instructions on how to install Jenkins on

Windows 10
 Play Video

Video: Installing Jenkins on Windows 10

Once you have it installed. You also need to install Git for Windows. You
can download Git from here: [Link]

Download and install using default settings.

Creating a Jenkins Job

After installing Git and Jenkins, go to the Jenkins Dashboard using the
URL [Link] and login using the credentials you created
during the installation.

Now do the following:

 Click Manage Jenkins

 Under System Configuration click Global Tool Configuration
 Scroll down to Git section. Change the Path to Git executable to the path
you installed your Git installation.

In our case the path is C:\Program Files\Git\bin\[Link] as shown below

Figure 1 - setting the Git path

Click save once you are done. Click Back to dashboard.

Once there, click on "New Item" which is located on the top left corner.
 Figure 2- New item option

On the next screen, you need to enter the Item name. In our case, the
item name will have the name of our java file which
is JenkinsJobTutorial. This is as shown below:
 Figure 3- Item name and project type selection

On the type of project, choose the Freestyle project then click OK

On the next screen, you can now write the job details. On description,
write, "This job is for a simple java project to printout some text".

We need to specify the location of files which need to be built. In this

example, our repository is hosted on GitHub, so we will enter the url of
that repository here. The repository consist of a Java file which prints out
the sentence, "Hi. I'm studying Software Engineering at PIHE!. Enter the
following URL: [Link] under the
Source code management option as shown below:
 Figure 4 - Entering Git URL

Now scroll down to the Build section towards the end of the page and click
on Add build step → Execute Windows batch command. In the
command window, enter the following commands shown in Figure 5 and
then click on the Save button.
 Figure 5- Execute windows batch

These commands will compile and run our code.

Once saved, you will be be directed to the Project status screen. Here,
click on the Build Now option to see if you have successfully defined the
job.

Once the build is scheduled, it will run. Under the Build history section
shows that a build is in progress which should take a few seconds to
complete. Once the build is completed, a status of the build will show if
the build was successful or not. In our case, the following build has been
executed successfully. Click on the #1 in the Build history to bring up the
details of the build.

Figure 6- Build History

Once you are on the Build screen, click the Console Output option to
the left. The console output will show the details of the build as shown
below:
 Figure 7- Build Success

As you can see on the last line of the output, the build was a Success.
and the String "Hi I'm studying Software Engineering at PIHE!" is also
displayed.

It is worth noting that apart from the steps shown above there are just so
many ways to create a build job in Jenkins. The options available are
many, which what makes Jenkins such a fantastic continuous deployment
tool for software engineers.

16.4 Agile Methodology

Agile software development ([Link] describes a set
of values and principles for software development under which
requirements and solutions evolve through the collaborative effort of self-
organising, cross-functional teams. It advocates adaptive planning,
evolutionary development, early delivery and continuous improvement,
and it encourages rapid and flexible response to change. These principles
support the definition and continuing evolution of many software
development methods.

NOTE: This unit will just touch on the basics of Agile and provide a bit of
background knowledge.

Agile development is an umbrella term for several iterative and

incremental software development methodologies. The most popular agile
methodologies include Extreme Programming (XP), Scrum, Crystal,
Dynamic Systems Development Method (DSDM), Lean Development and
Feature-Driven Development (FDD).

The most common agile term used today by developers is ‘Scrum’. Scrum
is a lightweight agile project management framework with broad
applicability for managing and controlling iterative and incremental
projects of all types. Scrum has garnered increasing popularity in the agile
software development community due to its simplicity, proven
productivity and ability to act as a wrapper for various engineering
practices promoted by other agile methodologies.

An agile Scrum process benefits the organisation by helping it to:

 Increase the quality of the deliverables.

 Cope better with change (and expect the changes).
 Provide better estimates while spending less time creating them.
 Be more in control of the project schedule and state.

On top of benefiting the organisation, scrum also benefits a wider variety

of users:

1. Benefits to Customer - Customers find that the vendor is more responsive

to development requests.
2. Benefits to Vendors - Vendors reduce wastage by focusing development
effort on high-value features, and reducing time-to-market relative to
waterfall processes due to decreased overhead and increased efficiency.
Improved customer satisfaction translates into better customer retention
and more positive customer references.
3. Benefits to Development Teams - Team members enjoy development work
and like to see their work used and valued.
4. Benefits to Product Managers - Product Managers, who typically fill the
Product Owner role, are responsible for making customers happy by
ensuring that development work is aligned with customer needs.
5. Benefits to Project Managers - Project Managers (and others) who fill the
ScrumMaster role find that planning and tracking are easier and more
concrete, compared to waterfall processes.
6. 6Benefits to PMOs and C-Level Executives - Scrum provides high visibility
into the state of a development project, on a daily basis.
The most commonly used software development model used is the
Waterfall Model, as depicted in the following diagram. However, in most of
the cases, new functionalities are added and also earlier requirements
may change. The Waterfall model is not structured to accommodate such
continuous changes in requirements. Furthermore, the user will not have
clarity on the functionality of the product until the product becomes
available in its entirety. This allowed for improvement to the current
model and methodology, thus giving way to the Agile methodology.

- Waterfall model -

The Agile Manifesto was published by a team of software developers in

2001, highlighting the importance that needs to be attached to the
development team, accommodating changing requirements and customer
involvement.

The Agile Manifesto is as follows:

“We are uncovering better ways of developing software by doing it and
helping others do it. Through this work, we have come to value:

 Individuals and interactions over processes and tools.

 Working software over comprehensive documentation.
 Customer collaboration over contract negotiation.
 Responding to change over following a plan.
 The Agile Manifesto is based on the following principles:

Principle Description
Satisfaction and Customer satisfaction through early and continuous
Delivery working software.
Welcoming Change Welcome changing requirements, even at later stages
of development.
Deliver Frequently Deliver working software frequently (weekly rather
than monthly).
Communication is the Ensure close association of developers with business
Key people on daily basis.
Environment and Build projects around motivated individuals. Give
Trust them necessary support and trust them.
Face-to-Face Encourage face-to-face conversation to ensure
Communication efficient and effective communication.
Software as Measure Working software is the primary measure of
of Progress progress.
Sustainable Promote sustainable development with the ability to
Development maintain a constant pace throughout the development
process.
Attention to Detail Continuous attention to technical excellence and
good design.
The Power of Less Simplicity is essential.
Self-Organising Regular attention of the team on becoming effective
Teams in changing circumstances.