Red is stuff that I do not understand/Have no idea wtf is going on

Module 1: Development and Impact of Software

Solutions
Social and Ethical Issues
The impact of software
● When software is inappropriately developed or used, the impacts have the potential to be
significant.
● The main issues present within certain software are the following:
○ Inappropriate data structures
■ A data structure is a data organisation, management and storage format that is
usually chosen for efficient access to data.
■ When designing software, developers sometimes must consider efficiency and cost
simultaneously, meaning the inappropriate data structure can be sometimes in the
need of less cost/more efficiency.
■ Example: The Year 2000 (Y2K) Problem
● During the 1960s and 70s, storage was very expensive, meaning software
developers used 2 digits to represent the year within dates (i.e. 1986 was
displayed as 86).
● However, it was realised that the year 2000 would be represented as 00 and
so forth, with software developers concerned that it would be interpreted as
1900 instead of 2000.
● This lead to individuals believing that major systems and networks would
crash, though nothing ended up actually occurring.
● This shows how inappropriate data structures (although accidental) may
have a negative impact on software.
○ Computer malware such as viruses
■ Computer malware is a shortened form of “malicious software”, referring to software
programs designed to damage or do other unwanted actions on a computer system.
■ Common examples of malware include viruses, worms, Trojan horses, and
ransomware.
● For example, ransomware is able to delete or encrypt files on a hard drive,
and demand a ransom sum in order to restore the files.
■ Software developers have the responsibility to ensure their products do not contain
viruses.
○ Reliance on software
■ While software has begun to be present in all forms of our lives (sports, cooking,
leisure etc.), this overreliance on software may cause issues if software were to
disappear/malfunction.
■ For example, if an office worker had all logs of their sales digitally, and their hard
drive corrupted, all of their progress and work would be completely lost;
demonstrating the impacts of overreliance in software.
 ■ Furthermore, overreliance leads to an increased sharing of personal
information/data (such as using a virtual assistant for all your daily tasks), raising
further concerns regarding user’s safety.
○ Social networking
■ Related to the reliance of software, social networking has proven to be a very
important tool in communication and connecting with one another in the modern
day and age.
■ However, concerns have been raised regarding the privacy of data on social
networking, considering how many of these sites require data such as the user's
name, email and domestic address, which is very personal
○ Cyber safety
■ When it comes to the safety of software users, developers must take into account
that their handling of their data (which should be safely), as well as the limitations of
the product itself (can users send credit card info in a chat box?), can play a big role
in the cyber safety of their users.
○ Huge amounts of information (which may be unsupported, unverifiable, misleading, or
incorrect) available through the internet
■ The internet can be used as a source of virtually unlimited information, allowing
individuals to learn, grow and share from this information much more easily.
■ However, the validity of this information is not absolute on many websites, and so
this may impact the quality of a user’s experience on the internet, especially if they
are misled or misinformed online.
Rights and Responsibilities of software developers
● Developers have a lot of responsibilities in creating their product, being that of:
○ Producing quality software
■ Producing software that is of a high quality, producing no errors or issues
that may prove detrimental to a user’s system.
○ Recognition and acknowledgement of Intellectual Property
■ Your own and other’s
■ Recognising intellectual property that may not be their own, but is used in
their software, and crediting the makers of this property.
○ Responding to user-identified problems
■ If a user has submitted a problem, developers have the responsibility to
ensure this problem is solved, to fulfil their responsibility of producing
quality software.
○ Not creating or transmitting malware
■ Related to quality software, developers must ensure that no malicious
software is present in their own, as this would be very harmful to unknowing
users. (Not that knowing users would want malware)
○ Addressing ergonomic issues in software
■ Related to inclusivity and quality, software must take into consideration
ergonomics (such as the average human reading speed, finger span (for
shortcuts)) so the product is able to be easily and efficiently used.
 ○ Ensuring software inclusivity
■ Acknowledging cultural backgrounds
■ Acknowledging economic backgrounds
■ Acknowledging gender
■ Acknowledging disabilities
○ Ensuring individuals’ privacy is protected
■ When using or taking users' data, developers must ensure that this data is
private and can be solely used by the user themselves, unless the user has
given permission for this to be the case.
● Their rights are very similar, having the right to:
○ Own their product legally
○ Distribute their own product freely (given it follows the code of conduct)
Software Piracy and Copyright
● Intellectual Property (IP)
○ Intellectual property is the property withheld by a certain individual, created with
their own intellect (thus having that name).
○ Just like books, TV shows and music, software is also part of intellectual property,
with developers having the right to have ownership over their software.
● Plagiarism
○ Plagiarism refers to the practice of taking someone else’s work or ideas, and passing
them off as one’s own.
○ Software is also able to be plagiarised, being an issue as it is a developer’s
intellectual property, with copying and profiting of it prohibited morally and under
law.
● Copyright Laws
○ Copyright laws are laws that prevent plagiarism on a very large scale, protecting
creators (including software developers)
● Licences / Licensing Issues / Licensing Conditions
○ For their software,
developers are able to
place licences on them,
which dictate what is
able to be done with
their software legally.
○ Some developers allow
their product to be
completely taken apart
and remade while
distributed, while others
do not allow anything to
be done to their product,
with the purchaser
having one copy only.
 ○ The table to the right displays all the types of licences available for software, with
most of the software we purchase being commercial.
● Ownership vs. Licensing
○ Software obtained from outside sources is not generally owned by the user.
○ The developer, who is the author of the product, retains ownership.
○ Generally, for commercial contexts, the purchaser of this book is only licensed to use
the software, but cannot copy it or distribute copies.
○ With some software, the purchaser is able to do this (such as public domain
software), but licensing agreements must be read before installing new software.
● Modern technology to combat software piracy/copyright infringement
○ Non copiable datasheet
○ Disc copy protection
○ Hardware serial numbers - if software and hardware do not match, program will not
run
○ Site licence installation counter on a network
○ Registration code for software
○ Encryption keys to scramble/unscramble data/software
○ Back to base authentication
Use of Networks
● Developers have recognised the increasing popularity of networked computers.
● Programs are now available for network use.
● They could be either:
○ Centralised software, in which software is available as a single copy on a central
server
○ Distributed software, which is available on individual machines.
● Regardless, each machine on the network or using the software requires a separate licence.
● Pros/cons for software developers:
○ Access to resources - graphical assets, source code, third party libraries
○ Ease of communication - networks allow developers to communicate with each
other
○ Productivity - collaboration can effectively increase productivity due to both the
ease of communication and access to resources
● Pros/cons for users
○ Response times - important for users and will usually give up if too slow. Factors
such as server load are out of the hands of the developers and are an effect of
networking.
○ Privacy and security issues - Sensitive data is often transferred across networks.
Precautions are often made to ensure that the data remains private.
The Software Market
● The aim of a developer is to maintain their space in the software market.
● To market a software product, the following needs to be considered:
● Product
○ The expectation of customers should be met by the product
 ○ It is unethical to produce a product that does not meet the user’s expectations.
○ Also includes custom software, where software is designed specifically for a
business
● Place
○ An audience must be specified before deciding on a place to sell the product
○ There are many methods of distributing software; shop fronts, online, bookstores.
○ Depending on where the software is sold, it can change the perception of customer’s
expectations
● Price
○ A developer has a responsibility to to arrange a reasonable price for a product
○ Methods for pricing a product are either a cost-plus basis, or consumer based
pricing
● Promotion
○ The different ways developers use to persuade people to buy products
○ Developers have an ethical responsibility in what they say about their product to
their consumers
Legal Implications
● National Legal Action Cases:
○ RACV vs Unisys
■ Claims management system → electronic storage and retrieval system
■ Failed expectations of software. RACV sought damages citing false
representation and misleading conduct. Awarded damages of $5 million
dollars to RACV.
○ Microsoft vs Apple
■ Microsoft released Windows after Apple released Macintosh, with Apple
suing Microsoft for copyright infringement.
■ A settlement was reached, allowing both companies to distribute their OS.

Software Approaches
● Factors of defining approaches
○ Scale of the product
○ Complexity of the product
○ Skills of the personnel developing the product
○ Detail of the requirements
○ Time for project
○ Budget
● Different types:
○ Structured
■ Time-consuming, ordered and controlled
■ Highest level of personnel skill required
■ Product of the highest size and quality
■ Top-down approach (waterfall method)
■ Thoroughly planned, documented and monitored
 ■ Used for large products in large companies
■ Costs are high and errors can be hard to find and correct
■ Requirements are understood before design and coding occurs
■ Requires high project management
○ Agile
■ Emerged due to the demand for products to be specifically tailored for
individuals
■ Places emphasis on system being developed
■ In depth documentation is not needed
■ Focus on team-work, cooperating, communication skills and efficient work
methods
■ Development team must be able to adapt to the situation
■ Small teams preferred; members are multiskilled
■ Characterised by the speed of getting the product to the user, interaction
between the team and users, responds well to changing circumstances
■ Product in development being continually updated.
○ Prototyping
■ Lies between structured and agile approach
■ Predates the agile approach
■ Repeatedly iterates through development stages to refine user requirements
■ Each prototype includes more functionality
■ Intense user interaction
■ Prototypes are just interactive models of the user interface
■ Favoured over structured approach is the ability to adapt to changing
requirements is required
■ There are five types of prototyping approaches:
● Concept prototyping
● Rapid throwaway prototyping
● Evolutionary prototyping
● Incremental prototyping
● Extreme prototyping
■ Acknowledges that the communication with users is very important and
helps in the defining and understanding of any future products to be
developed.
○ RAD
■ Main purpose of reducing time and money
■ Result of low quality, less usability and less features
■ RAD has only become possible due to 4th generation programming
languages, which enable visual production of interfaces with little coding
taking place in the background
■ Ability to include re-usable code which has been developed
■ Integrate with other software solutions
■ Development team to work very close to each other
 ■ Continuous feedback with users
■ Only meets most important requirements
■ RAD lacks formal stages to reduce time and cost
■ Removes need for data structures, algorithms
■ Uses existing routines and API of applications
■ RAD is suited when
● Distribution is narrow
● Application runs on small LAN
● Does not need to interface with other systems
■ Advantages of RAD
● Reduced coding of modules where library code is used
● Less errors
● Library code can ensure consistent look and feel
● Shorter development cycle
○ End User
■ Never used in software companies, not made for the purpose of making
money
■ Used to address a specific problem that end users need a solution for
■ Very small budget
■ Does not require knowledge of the workings of a computer, as it uses
Customised off the shift (COTS) software, Wizards or other automated code
generated devices
■ Resulting programs will not be overly complex and may not meet
specifications that the user may have initially wanted
■ Advantages of the End User approach
● The solution can be revised and modified at will, without
consultation with other users.
● No money required
● Less development time required
● A freedom to change requirements at any stage
○ Combinations of Software Development Approaches
■ Does not have to be of one type, or another
■ Combinations of approaches are perfectly viable, as different components of
a program may be developed using different approaches
■ The combination can be used to make the most efficient, low costing, high
quality solution.
■ One example is the use of an Agile approach with Prototyping, with meetings
between the client and developers being used to discuss current prototypes.
● CASE Tools
○ Version Control
■ Helps archive and maintain current/past versions of a program
■ Logs the current version, and changes made to each version
○ Test Data Generation
 ■ Test correct operation of modules
■ Test and evaluate performance
■ Check error messages
■ Outputs can be compared
○ Production of Code/Documentation
■ Avoid delays in production
■ Data flow diagrams
■ Structure diagrams
■ Flow charts
● Methods of Updating systems
○ Direct
■ Involves the old system being completely dropped and the new system being
installed at the same time
■ Need to make sure the new system is completely functional and operational
■ This conversion method is only used when it is not feasible to operate two
separate systems at the same time
■ Any data conversion and import must be done before installation occurs
■ New data lost if new system fails
■ Implementation occurs over shorter period but may be more time
consuming
○ Parallel
■ Involve the operating of both systems being run for a period of time
■ Allows problems with the new system to be found without loss of data
■ Once new system is up and running, the old system can stop being used
■ Old systems must be used until conversion
○ Phased
■ Gradual introduction of the new and discarding of the old
■ Done by introducing new parts while removing old parts
■ Often used when product is still under development
■ Done over a period of time
○ Pilot
■ The new system is installed for a small number of users
■ These users learn, use, and evaluate the system
■ Once it is seen as satisfactory, it is installed and used by all
■ Allows users to become experts and teachers of the new system
■ Pilot conversion also allows for the testing of the product in an operational
setting
● Trends
○ From 1995 to 2000, there was a large increase in job opportunities in software
development, though this pace has gotten slower
○ Employment based on experience
○ Meet demand for jobs
○ Outsourcing
 ■ Outsource work to specialists if they do not have expertise of resources
■ Reduces and controls costs
■ Higher quality results from specialists
■ Access to newer tech
■ Faster development times
■ Specialists are able to respond to change easily
○ Changing nature of work
■ Work has shifted from in person - in firms - to remotely working, which can
be done even internationally
○ Changing nature of applications
■ Originally, applications were solely used for computing in the primitive
stages of software development.
■ Now, there exist a wide range of applications for many day-to-day purposes
■ Examples:
● Mobile applications
● Big data processing - data analysts
● Cloud technology - iCloud, DropBox,
● DevOPs software, development operation managers - serve customer
and clients better; cloud management
● User interface developers - consumer focused, intuitive, create
enterprise applications and apps make it user friendly
● Web based software - Google apps, Facebook, Youtube, Instagram
● Learning Objects
● Widgets
● Cloud computing, Microsoft Azure

Module 2: Software Development Cycle (SDC)

Defining and Understanding the Problem
Defining the problem
● Identifying the problem
○ Carried out by a system analyst
○ Includes the following aspects:
■ Functionality
■ Compatibility
■ Performance
○ Determining the objectives which will be met
○ Boundaries and scope of the problem is understood
● Understanding the problem will enable a better understanding of the inputs, processing and
outputs of the system to be developed
● Needs of the client
○ A solution usually meets the needs of the client, which can be found using:
■ Surveys - info for large groups; limited in detail
 ■ Interviews - freedom to discuss in detail; limited to smaller sets of people
and time-consuming
■ Time management studies and observations - involves observing people
processing tasks
■ Business analysis - examines business rules and tasks
● Objectives
○ Short terms and long-term aims and plans
○ Clarification of objectives leads to determining the requirements, boundaries and
rules for the development
○ Measurable outcomes are also expressed in objects (e.g. performance statistics)
● Issues
○ Social and ethical considerations
■ Changing nature of work for users
● New skills to be acquired
■ Effects on levels of employment
● Technology replacing work done by humans
● Created new information technology jobs
● Less costs for businesses
■ Effects on the public
● Large software systems can have substantial effect on the general
public e.g. ATM’s
● Older generations are unwilling to accept technological innovation
○ Consideration of existing software products
■ Refer below
○ Customisation of those existing software solutions
■ Cost-effective strategy for obtaining new functionality
■ Many software developers spend much of their time modifying their own
existing products to suit specific needs of individual clients
■ Open source software is often customised to add new features; in many cases
the modifications are built as add-ons which are then available to other
users of the base software product
■ The ability to customise software helps the original developer of the product
widen their market
■ It is common for tools to be included in many commercial products which
allow the user to create customised screens and other functionality using
wizards and multiple drag and drop design screens.
○ Cost effectiveness
■ One of the constraints of a new software system will be that it falls within a
certain budget. If it is not a requirement, then it will most likely be a
constraint
■ Compare the costs between developing a new product or modifying an
existing product
■ Development hardware costs
 ● Any new hardware that needs to be bought/leased to enable
development
■ Development software costs
● What software is required; programming languages, CASE tools,
database management systems, graphics tools
■ Development personnel costs
● Salaries of development team and other staff
■ Outsourcing costs
○ Licensing/Legal considerations
■ Issues relating to copyright
■ Software that is used to store and access sensitive information will need to
include safeguards against unauthorised access
● Requirements
○ Statements that are indicators of what needs to be met
○ The final evaluation of a project’s success of failure is based on how well the original
requirements have been achieved
○ Functionality Requirements
○ Compatibility Issues
○ Performance Issues
● Boundaries of the problem
○ Define the limits of the problem
○ Anything outside the system is said to be part of the environment
○ System connects with the environment through an interface

Design Specifications
● The need of the proposed system
○ A software’s requirements specification is a standard framework for a team to
develop a large, complex software system and includes a complete description of the
behaviour of a system to be developed.
○ Includes a set of use cases that describes all the interactions the users will have with
the software.
○ SRS also contains non-functional requirements, and the methods which will be used
to model the system will also be specified.
● Developer’s perspective
○ Data Types
■ The types of data that are to be used in the software should be specified
beforehand.
■ For example, an inventory management system would most likely use a large
amount of data in the form of strings and integers, and so these data types
should be considered in defining and understanding the problem.
○ Data Structures and Variables
■ Variables represent storage locations of data within the computer system
 ■ A programmer will look at the data items and determine how they are to be
stored and accessed
■ The data type and an appropriate identifier is then determined
■ Meaningful variable names are considered intrinsic documentation and help
programmers follow the logic of the program
■ Global or Local Variables
○ Algorithms
■ Pseudocode or flow charts
■ Problem is modularised (split into modules)
■ Top down decomposition (more about this later on)
■ Familiar modules, which can be drawn from a library of code (such as
random number generation)
■ This method ensures a minimum of testing is required
● User’s Perspective
○ Interface design
■ Standards for interface design will be specified to ensure continuity of
design across the project’s visuals.
■ The wording of messages, design of icons and the format of any data
presented to the user need to be determined and a set of specifications
created.
■ Ergonomic Issues should also be considered.
○ (Social and Ethical) S & E issues
■ When developing software, S & E issues must also be considered, such as the
use of such software in a work environment, whether it is child-friendly,
whether the nature of the software can be subverted for malicious purposes
etc.

Consultation with Client

● Client’s perspective
○ The client’s perspective is one that is external and only considers the product from a
usage side, and can thus prove to be very important in developing software.
○ The developer and user are equally important to the success of the software project
● Feedback
○ Feedback from test users, or the client if actively involved in the process is
imperative in understanding and designing the software.
○ For effective communication, developers need to establish both formal and informal
channels and communication
○ Formal channels
■ Memos and regular meetings to keep the users up to date with the
development process
○ Informal channels
■ Discussed at any time during development process, as matters will arise that
cannot be kept until the next formal meeting
 ○User should have the opportunity to provide feedback
○Development process will proceed well if members can achieve construction
criticism and if there is two-way communication
● Empowering the client during the process
○ Through early models, as well as communication and feedback to and from the
client, they will feel empowered in designing their own product, helping the
developers during this stage of the SDC.
○ Changing work practices are often cause for discomfort, resentment and fear (!?)
○ Empowering the user also means giving them the ability to make decisions that
affect their work

Quality Assurance
● Explicit defined criteria
○ By ensuring that the client/developers have agreed on an explicit criteria for the
software, the problem can be thoroughly defined from the beginning, allowing for
lesser mistakes
○ Furthermore, all the development that is undergone in the SDC can be checked
against the criteria, to ensure that the project is not deviating from its original goal.
● Management process put in place
○ A management process, incorporating a team of a system of individuals that manage
the development process, ensure that the project is upheld in terms of timescale, as
well as understanding the problem, leading to a higher quality product.
○ For example, a manager is able to delegate certain tasks/modules to more junior
workers in this management process, while ensuring that they are completing these
tasks with respect to the criteria.
● Ongoing checking that it’s being met.
○ Similar to the management process that is put into place, ongoing checking of the
software by both the client and senior developers (in reference to previously defined
requests/the explicit defined criteria) ensure that the project constantly refers back
to (and fulfils) the explicitly defined criteria that was first implemented, to assure
the project is at its best quality.

System Documentation
● Different types of documentation are produced throughout the software development cycle
● Many large companies
utilise diagrams that
form part of the UML
(unified modelling
language) which
incorporated a variety
of different modelling
tools that are now
available as part of
 many CASE tools and IDE’s (integrated development environments)
● A model of a system is a representation of that system designed to show the structure and
functionality of a system. Many system modelling tools are in the form of diagrams
● The model gives directions and specifications for the developers
● Different types of modelling are applicable to different aspects of the system
● IPO Charts
○ Explain how inputs
are transformed into
outputs by processing
○ Expand on the
processes found in the
data flow diagram and
structure diagram
○ IPO diagram can
either be
diagrammatical, or in
a table form (mainly
in a table form)
● Context Diagrams
○ Used to present an
overview of the
whole system
○ Shown as a single
process, along with
inputs and outputs
○ Visualises data
entering and
information exiting
the system without
detailing the
processing required
in any detail.
○ Does not show data stores nor internal processes
○ Also known as level 0 data flow diagrams
○ Symbols:
■ Rectangle - person or organisation, source or sink that provides or receives
data
■ Arrow - flow of data
■ Circle - process (in this case, the entire system)
● Data Flow Diagrams
○ Represent a
system as
several
 processes that, together, form a single system
○ It is a deeper look into the context diagram, showing further detail
○ DFDs identify the source of data, flow between processes, and it’s destination along
with data generated by the system
○ Symbols:
■ Squares - representing external entities, sources or destinations of data
■ Circles - processes, which take data as an input, process it, and output it
■ Arrows - represent the data flow, electronic data or physical items
■ Open-ended rectangles - represent data stores such as databases.
● Storyboards
○ Shows the various interfaces in a
system as well as the links
between them,
○ The representation of each
interface should be detailed
enough for the reader to identify
the purpose, contents and design
elements.
○ Areas used for input, output and
navigation should be clearly
identified and labelled
○ Any links shown between
interfaces should originate from
the navigational element that triggers the link.
● Structure Charts
 ○ Describes the top-down design and sequencing of a process
○ Represents a system by showing the separate modules or subroutines that
compromise the system and their relationship to each other
○ The chart is read from top to bottom, with component modules or subroutines on
successively lower levels, indicating these modules or subroutines are called by the
module or subroutine above.
○ Modules are read left to right to show the order of execution
○ These modules set the structure for the development of the IPO diagrams and the
development of the algorithm and subsequent coding of each module
○ Structure charts are useful for maintenance
○ Symbols:
■ Open arrow - data movement between modules or subroutines, usually
passes as parameters
■ Closed arrow - indicates a flag or control variable
■ Small diamond at intersection - a decision
■ Undo arrow - repetition
■ Line - call the module
● System Flowcharts
○ Used to represent the logic and movement of data between the system components,
including hardware, software and manual components
○ System flowcharts are a diagrammatic way of representing the system to show the
flow of data, the separate modules comprising the system and the media used
○ Many symbols for system flowcharts have become outdated because of changes in
technology
 ○ Symbols:

● Data Dictionaries
○ Comprehensive
description of
each data item
in a system
○ Commonly
includes:
 ■ Variable name
■ Size in bytes
■ Number of characters as displayed on screen
■ Data type
■ Format including decimal points if applicable
■ Description
■ Example of data
● Extended Backus-Naur Form (EBNF)
○ Metalanguage - A way to describe language in a simplified form
○ EBNF is a metalanguage used to define the syntax of any programming language.
The following symbols are used:
Symbol Definition

= ‘is defined as’

| Indicates a choice between alternatives

Terminal symbol There is no need for further definition of this item. It may be
a symbol or a reserved word (such as PRINT, IF…)

<> Used to specify a term that will be subsequently defined

[] Indicates an optional part of a definition

{} Indicate a possible repetition (0 or more times)

() Used to group elements together

Examples Letter = A | B | C

Digit = 0 | 1 | 2 | 3 | 4 | 5

Identifier = <Letter>{<Letter><Digit>}

Assignment Statement: LET <Identifier> = <Identifier>

Interpretation of Letter is a non-terminal symbol defined as A or B or C

the above
examples Digit is a non-terminal symbol defined as 0 or 1 or 2 or 3 or 4
or 5

An identifier is defined to be a Letter followed by one or more

Letter or Digits.

Using these definitions, a valid Identifier could therefore be

any of the following:
● B24A
● C
● ABC1
 A valid assignment statement could be LET C = B24A, as they
are both identifiers
● Railroad diagrams
○ An alternative,
graphical method
used to define the
syntax of a
programming
language
○ Rectangles are used
to enclose
non-terminal
symbols, that is,
symbols that will
be further defined
○ Circles or rounded
rectangles are used
to enclose terminal symbols
○ There is no need for further definition of such items
○ They may be a symbol or a reserved word
○ These elements are linked by paths to show all valid combinations
○ By starting at the left-hand side of the diagram and tracing any path in a forward
direction to reach the right-hand side of the diagram, a syntactically correct
construct is defined
○ ‘Railroad” in this context means a branch in the diagram is valid if it is treated as a
set of tracks in a railroad layout, where a
branch can only be followed in a forward
direction.
● Algorithms used in document
○ The logic in modules and subroutines
are represented before being coded,
using pseudocode and flow charting
○ Flowchart is a graphical representation
○ Flowcharts should not be used for large
projects
● Sideline on Pseudocode (Important!)
○ Pseudocode uses English-like statements
with defined rules of structure and
keywords.
○ There are specific guidelines for
pseudocode, being (for the NSW HSC
syllabus):
 ■ for each procedure or subroutine:
● BEGIN name
● END name
■ for binary selection:
● IF condition THEN
○ statements
● ELSE
○ statements
● ENDIF
■ for multi-way selection
● CASEWHERE expression evaluates to
○ A: process A
○ B: process B
● ....................
● OTHERWISE: process …
● ENDCASE
■ for pre-test repetition
● WHILE condition
○ statements
● ENDWHILE
■ for post-test repetition
● REPEAT
○ statements
● UNTIL condition
■ for FOR / NEXT loops
● FOR variable = start TO finish STEP increment
○ statements
● NEXT variable
○ In pseudocode:
■ Keywords are written in capitals
■ Structural elements come in pairs, e.g. for every BEGIN there is an END, for
every IF there is an ENDIF
■ Indenting is used to identify control structures in the algorithm
■ The names of subprograms are underlined. This means that when refining
the solution to a problem, a subroutine can be referred to in an algorithm by
underlining its name, and a separate subprogram developed to show the
logic of that routine. This feature enables the use of the top-down
development concept, where details for a particular process need only be
considered within the relevant subroutine
● Test Data and expected outputs
○ Many operational factors may be outside the control of the programmer, or unable to
be foreseen (e.g. inputs, variation in hardware, different OS and changing
technologies)
 ○ Programmer can only test the program within the bounds that are set during the
analysis stage of development
○ With an increasing size of an application, it makes it harder to create test data to run
throughout the whole application
○ Modularisation of programs means that data can be created to test each module,
however, it is also likely that an unforeseen output from one module will cause
problems in other modules in the program (i.e. the flow of unexpected data)

Planning and designing software solutions

● Standard logic used in software solutions, namely:
○ finding maximum and
minimum values in arrays
■ The value in the
first element is
stored in a
temporary variable
called Max/Min
■ As the array is
traversed, each
element is
considered to
determine if its
value is
larger/smaller than
that stored value
■ If so, the value in
Max/Min is
replaced by this
larger/smaller
value, and the index
of this element is
stored in a
temporary variable
called
Max/MinIndex
■ When all elements
have been
considered, Max
will contain the
largest value and MaxIndex will contain the index of the largest element and
vice versa for minimum
○ processing strings (extracting, inserting, deleting)
■ String - string of characters one after another forming a sequence
 ■ String Concepts
● In traditional systems string were not identified directly in a
programming language
● A programmer had to work with the individual characters that make
up a message or word
● A string was represented as an array of character
● Commonly given a default value of 25fi characters
● Common operations include
○ Determining the length of the string
○ Joining strings together - concatenation
○ Extracting characters from the string
○ Inserting characters into the string
○ Deleting characters
■ Extracting
■ Inserting
■ Deleting
■ The three things above all are just long bits of pseudocode
○ generating a set of unique random numbers
■ Most high-level languages have a function to generate a random integer or
floating-point number
■ Generally, a range in the random function is specified
■ Random number generators have applications in gambling, statistical
sampling, computer simulation, cryptography
■ The generation of pseudo random numbers is an important and common
task in computer programming
■ Different applications require different amounts of unpredictability
■ Most computer generated random numbers use Pseudo random number
generators (PRNGs) which are algorithms that can automatically create long
runs of numbers with random properties but eventually the sequence
repeats
■ The series of values generated by such algorithms is generally determined by
a fixed number called a seed
■ One of the most common PRNG is the linear congruential generator which
uses the recurrence:
● processing of sequential files, including:
○ The data stored in a sequential file is stored in a continuous string
○ The data is accessed from beginning to end
○ Text files are sequential files
○ Sentinel files are used to indicate the end of file
○ Once sequential files are read and the sentinel is reached, files are closed
○ sentinel value
■ In a sequential or recursive file/algorithm, a sentinel value is usually one
which is used to terminate its process.
 ■ E.g. WHILE TRUE has FALSE as a sentinel value, as it would end the while
loop.
○ priming read
■ The statement which reads the first input data record prior to starting a
structured loop
■ The main purpose of a priming read is to allow the processing block that
follows it to be structured
○ open for input, output or append
■ Sequential files can be opened in one of three modes:
● Input - used to read the data within a file
● Output - used to write data to a new file
● Append - used to write data at the end of existing file
● processing of relative files, including:
○ open for relative access
■ Relative refers to the position of a record in the file, as each record is the
same length
■ Allows the relative position of a record to be known
○ defining a key field for a relative file
■ The position of each record in the file is used as a key to allows direct access
of a record (instead of sequential)
○ retrieving, writing and updating a record in a relative file
■ Relative files need to be open for relative access to be updated and must be
closed before the program ends
■ All records are accessed using a key which specifies the relative position of
that record within the file
■ The key fields used must contain positive integer value only
● linear search
○ Examining one
item at a time in
an array
beginning at the
first item and
moving to the end
of the array
○ Does not require
numbers to be
sorted
○ Processing taken
for the search is
directly related
(proportional) to
the size of the
array searched
 ○ Linear search involves:
■ The function accepting a search value
■ Traverses the array using iteration
■ Checks each value compared with the search value
■ Returns ‘number found’ and the index of the cell whose value equals the
search value
■ Otherwise, returns ‘number not found’
● binary search
○ Only used if the values
in the array are
already sorted in
order
○ The binary search
starts by checking the
middle value of an array
to see if it matches the
search value
○ If not, the binary search
then determines if the
search value is in the
first half of of the array
or the second half (after
the middle value)
○ This process is repeated
with the remaining list
of items
○ Eventually the required
item will be found or
the list of possible items will be empty
● bubble sort
○ Popular amongst
novice programmers
○ Main logical structure
is based on traversing
an array and switching
adjacent pairs of
values that are not in
the correct order
○ After one traverses,
the largest value will
have ‘bubbled’ to the
end of the array. This
is repeatedly until all
 values are in the correct cells
● insertion sort
○ Used when a
large part of
the data is
already sorted
○ During each
pass, the last
element from
the unsorted
part is
inserted into
the
appropriate
place in the
sorted part of
the array
○ A linear
search is conducted to find the correct place to insert
○ As each sorted element is checked, it is moved to the left/right to make room for the
new elements
○ At each pass the sorted section of the array increases by 1
○ Process continues until the unsorted section = 0
● selection sort
○ During each pass a
linear search is
performed
○ A marker is placed at
the first cell in the array
and then search
through the array from
that position onwards
looking for the smallest
value
○ When the smallest
value is found, it is
swapped with the
marker’s cell value.
This naturally places
the smallest value at
the front of the array
○ The next step is to increment the marker to the next cell and repeat the process
○ When the marker reaches the last cell, the array is sorted
Custom designed logic used in software solutions
● requirements to generate these include:
○ identification of inputs, processes and outputs
■ When designing software solutions, the inputs, outputs and processing of
both are at the forefront of this design.
■ Developers must consider the environment in which the software solution
will be implemented in, as this will determine the input that a software
solution receives.
■ In regard to the output, the developer must consider identify what the client
requirements are, as these dictate what the software should output for the
user.
■ The processes usually follow after the identification of both the
input/outputs of the software, as the developer must now consider how the
inputs must be processed to have proper output.
○ representation as an algorithm
■ An algorithm is defined as a process or a set of rules to be followed in
calculations or other problem-solving operations, especially by a computer.
■ Before designing the software solution, developers must first represent the
processing of the input into an output as an algorithm, usually done in a form
of representation outside the language the program is to be coded in.
■ For example, the inputs, processing and output can be represented in the
form of a flowchart or pseudocode.
■ This algorithm can then be converted into a 4th generation language, such
that it is able to be interpreted/compiled.
○ identification and definition of required data structures
■ Algorithms make sure of certain data structures, and in such, these must be
considered alongside of the representation of the logic of the program as an
algorithm.
■ For example, a customer’s information could be stored as an array of
records, while the time and location they visited could be represented as a
two-dimensional array.
○ testing of the logic in the algorithm
■ The testing of the logic used in designing the algorithm can be done through
conventional methods of testing code/algorithms, using methods such as
desk checking, single line stepping, and the testing of boundaries with test
data.
● use of data structures, including multidimensional
arrays, arrays of records, files (sequential and relative)
(see Course Specifications document)
○ Single Dimensional Arrays
■ A simple array is a grouped list of
similar variables, all of which are used
 for the same purpose and are of the same data type.
■ Individual elements are accessed using an index, which is a simple integer
variable.
■ Before using an array in a program, some languages first require that it must
be dimensioned (that is, defined) in order to allocate sufficient memory for
the specified number of elements.
■ A statement such as the following is a typical example of the above:
○ Multidimensional arrays
■ Arrays can be of
many
dimensions.
■ A useful way to
diagrammatically
represent a
multidimensional
array is to think
of each element
being further
subdivided with
each successive
dimension.
■ Individual elements are accessed using one index for each dimension, each of
which is a simple integer variable.
■ Consider a 3-dimensional array Sales(Town, Month, Product) which stores
information about sales of four different products in each month for a
number
of towns.
○ Records
■ A record
is a group
of
variables,
which
may each
be of
different
data
types.
■ Individual
elements
are
accessed
using
 their field names within the record.
○ Array of records
■ An array of records is in an array, each element of which consists of a single
record.
■ Every record in the array must have the same structure, that is, the same
component fields in the same order.
● customised off the shelf packages
○ Off the shelf packages refer to software that is commercially available for purchase
and modification; often containing modules and programs that can be used
normally.
○ However, off the shelf packages can also be edited by users to be used for specific
functions (e.g. Microsoft Office being edited in Visual Basic 6.0 to add more specific
word document features) is what as known as a customised off the shelf package.
○ identifying an appropriate package
■ An appropriate off the shelf package can be used as a baseline to design
custom logic. For a running example, let's use a mp3 metadata editing
program, which you want to also make a mp4 metadata editing software.
○ identifying the changes that need to be made
■ The off the shield package will not have all the logic which developers
require to have in the final product, and thus, they must consider the original
function of the software with their logic, and identify which specific parts of
the package must be altered, whether it be specific code or entire libraries.
■ The changes that are needed to be made are clearly in the types of files
which the program opens, and the libraries which they use to edit specific
metadata.
○ identifying how the changes are to be made
■ Through either direct editing, or the implementation of external modules,
developers must identify how the package should be customised to
accommodate for their custom logic.

Standard modules (library routines) used in software solutions

● reasons for the development and use of standard modules
● requirements for generating a module or subroutine for reuse, including:
○ identification of appropriate modules or
○ subroutine
○ appropriate testing using drivers
● thorough documentation of the routine:
○ author
○ date
○ purpose
● order and nature of parameters to be passed
● issues associated with reusable modules or subroutines, including:
○ identifying appropriate modules or subroutines
 ○ considering local and global variables
○ appropriately using parameters (arguments)

Documentation of the overall software solution

● tools for representing a complex software solution, including:
○ Algorithms
■ An algorithm is a process or set of rules to be followed in calculations or
other problem-solving operations, especially by a computer
● refined system modelling tools, including:
○ IPO diagrams
○ context diagrams
○ data flow diagrams (DFDs)
○ Storyboards
○ structure charts
○ system flowcharts
○ data dictionaries

Interface design in software solutions

● the design of individual screens in consultation with the client, including:
○ consideration of the intended audience
■ Each screen in a program will have a target audience. If the screen is to be
effective, the needs of that audience must be met:
● Organisation of screen elements
● The way they are presented
● The way the user interacts with the interface and the way help is
provided
■ Communication with the user is key to finding out the specification for
interface design depending on the target audience
○ identification of screen size
■ Screen size will be affected by the intended hardware the software will be
installed on
■ Will also impact screen resolution, the graphics hardware and drivers
needed for so
○ identification of data fields and screen elements required and their appropriate
onscreen placement
■ Screens are designed to present data, input data or output data
■ It is important for the developer to have a clear understanding of how data
items need to be presented to the user
■ The context in which data is displayed is closely related to the processes
being carried out
● Menus are used to initiate execution of modules within a program
● Command buttons are used to select a different path for execution,
often used for confirmations
 ● Tool bars; used to quickly access commonly used items
● Text boxes; receive input in the form of strings
● List boxes; force the user to select from the given options
● Combination boxes; combine functions of text box and list box
● Check boxes; obtain boolean input from the user
● Options or radio buttons; select from one of the displayed options
● Scroll bars; navigation
● Grid; likened to an array of records
● Labels; provide guidance and information to the user
● Picture/image box; display graphics
○ online help
■ Help system should be designed to encourage users to seek assistance
immediately a problem is encountered
■ Context sensitive help
● If user asks for help, new window displayed containing information
about user’s last action
● Small windows can open to display simple tips relating to current
screen elements if the user holds the mouse over an element for
more than a few seconds
■ Procedural help
● Concise and accurate instructions on how to complete a specific task
● ‘How’ rather than ‘why’
■ Conceptual help
● Aims to explain ‘what’ and ‘why’ rather than ‘how’
● Tours, tutorials and wizards
○ consistency in approach
■ Must be consistency between screens within an application
■ Allows the user to anticipate actions and placement
■ Design rule should be created before the development process is undertaken
● Especially important when a team of programmers is employed
■ Transfer across to new product
■ Aspects of consistency
● Names of commands
● Use of icons
● Placement of screen elements
● Feedback
● Forgiveness
○ recognition of relevant social and ethical issues
■ The interface must be socially and ethically acceptable, featuring symbols
and icons that are in any way not offensive and acceptable.
■ Furthermore, privacy must be considered in
● current common practice in interface design
 ○ Common practice in interface design can be seen in many websites, and often
follows:
■ Having buttons in the corner of the screen
■ Having header text in the middle
■ Having buttons underlined
■ Spacing text out considerably
■ Etc.

Factors to be considered when selecting the programming language to be used

● sequential or event driven software
○ Sequential
■ Screens follow one after the other and minimum user input is required
■ Data items are accessed from outside the program
○ Event-driven
■ Data items are accessed from within the program and the user controls the
order of processing, creates an interactive and dynamic pattern to follow
● driven by the programmer or user
○ User
■ Program logic
■ Requires user’s actions to trigger an event
■ Features menu, buttons, icons etc.
■ Order of module execution is defined by the user
■ Polling: process of continuously checking the status of events
■ Event parsing: executes events that the user has instigated
○ Programmer
■ Sequential approach
■ Follows set of steps to solve a given problem
■ Utilises standard control structures such as Begin…End, Do…Until
■ Order of module execution is defined by the programmer
■ Used in data handling programs such as databases and word processers
● features required, and features available in the language
○ commands within the language to interface with the required hardware
○ ability to run under different operating systems

Factors to be considered when selecting the technology to be used

● performance requirements
○ Minimum hardware configuration
■ Processor type and speed
■ Primary storage (RAM) available
■ Specific input and output devices
■ Secondary storage size and type
■ A minimum operating system
 ○ Requirements either come from the purpose of the software, or the system itself,
needing to convert the source code into executable code
● Benchmarking
○ Involves creating a set of tasks that can be used to measure the speed with which a
computer system will perform a task
○ Allows for a comparison between different combinations of hardware and software
○ Purely object process and so subjective measurements of aspects such as
user-friendliness and ergonomic factors are not included in the process
○ Interpreting these results are just as important as obtaining them.

Implementation of software solution

Implementation of the design using an appropriate language
● the different programming languages and the appropriateness of their use in solving
different types of problems
● construction of syntactically correct code that implements the logic described in the
algorithm

Language syntax required for software solutions

● use of EBNF and railroad diagrams to describe the syntax of statements in the selected
language

The need for translational to machine code from source code

● translation methods in software solutions including:
○ High level languages cannot be directly understood by a processor. Instructions must
be converted into binary.
○ Instead, source code, which is code that programs are inherently coded in (i.e. C++,
Java etc.), are translated into machine executable code
○ The source code is said to be machine independent; can be on several different
processors.
○ Executable code is very processor specific, each different family of processors will ha
○ Compilation
■ Takes source code and produces a complete translated file
■ Compiling is machine CPU specific
■ This file can be used on other machines with the same CPU without a need
for translator
■ Unwanted code, such as comments/remarks, are removed therefore creating
code that is more efficient
■ Allows for use of a share resource and libraries
■ Each time a change is made, the whole program must be recompiled
■ Slower testing and error detection phase
■ All coding errors are reported at the end
 ○ Interpretation
■ Translation but slower, less efficient object code as each line is translated
when loaded into memory
■ Line by line translation and execution
■ Much slower overall executions
■ Errors reported line by line; instant error feedback
■ Early error detection of runtime errors
■ When error is detected, execution is halted
■ Users must have the interpreter on their computer
● advantages and disadvantages of each method
Compilation Interpretation

Advantages Runs faster and more efficient Cross platform

Source code is private Easier debugging

Disadvantage Executables created with Slows down execution significantly

compilers and machine because of each statement needing
specific; not cross platform to be translated before it is
If it is to operate on a different executed
processor/operating system, Public source
source code must be Users of interpreted programs
recompiled, longer to develop must have a copy of the interpreter
in

● steps in the translation process

● lexical analysis, including token generation

○ Source code is broken up into lines of code
○ All formatting is removed, and comments are removed
○ Each group of characters on the line checked against a syntax library held in
memory
○ Individual language elements such as constructs, called lexemes, are identified and
labelled with a token
 ○ The process checks reserved words, identifiers, constants and operators are correct
○ Identifier token are stored in a symbol table or token dictionary
○ The translator uses attributes in the symbol table to allocate memory to variables
● syntactical analysis including parsing
○ Parsing implements the syntax rules of the programming language
○ If a group of tokens does not conform to the syntax rules, the analyser cannot place
them in the parse tree → an error is reported
■ The analyser reports the error to the programmer
○ The tokens pass from the scanner to the syntactic analyser
○ The syntactic analyser arranges tokens so the computer (CPU) understands the logic
of the program being translated
○ Arrangement can be written as a parse tree
○ Type checking (part of parsing)
■ Parsed tokens are sent to the type checker
■ Type checker has two purposes
● Detection of data types within the tokens and passing data type
detection to the translator
● Detecting incompatible operation between data types and creation of
error messages
● code generation
○ If the process of lexical analysis and syntactical analysis have been completed
without error, then the machine code can be generated.
○ Involves converting each token or series of tokens into their respective machine
code instructions
○ No errors should be found during code generation
○ The parse tree created during syntactical analysis will contain the tokens in their
correct order for code generation, and these tokens will be converted into their
respective machine code.

The role of machine code in the execution of a program

● CPU Operation
○ Fetches the instructions from primary storage
○ Decodes the instructions
○ Executes the instructions that are expressed and stores the result
○ Control unit coordinates the actions of the processor
○ Arithmetic and logic units are responsible for all the arithmetical and logical
operations carried out by the processor
○ Registers (memories) are provided to store results, locations and flags
○ The above components are joined by the internal data bus system
○ The processor is connected to main memory via an external data bus system
○ The CPU contains a microcode instruction set which are permanently set in the CPU
sometimes referred to as firmware
● machine code
 ○ Low-level programming language, consisting of machine language instructions
○ Machine code is strictly numerical language which is designed to run as fast as
possible
○ Consists of binary or hexadecimal instruction, allowing computers to respond
● instruction format
○ Machine instructions need to convey several pieces of information
○ An instruction is the command given to the central processing unit by a computer
program
○ Instructions are made up of an operation code and a memory address
○ The first few bits are used to tell the CPU the type of instruction to be carried out
○ An operation code is a machine language for a single operation
○ The control unit interprets this code to determine the appropriate action

○ First four values represent command ‘copy’

○ Next four represent the command “into the accumulator the value that follows’
○ Instruction byte 2 and 3 represent the memory location that supplies the data
○ This type of instruction is called direct addressing of a memory location
○ Processor instructions are grouped into sets
● use of registers and accumulators
○ A register is a temporary storage location within the central processing unit
○ Working registers are referred to as accumulators. Data leaving the main CPU goes
through the register buffer
○ Accumulators hold the data items currently being processed
○ An accumulator is a register which stores the result of the latest computation
carried out by the CPU or the last data that is about to be computed
○ Data is stored in the registers and results are passed from registers back to main
memory
○ Special purpose registers are used to store bits known as flags
○ After being in the accumulator, the data must be moved to a different memory
location
 ● the fetch–execute cycle
○ Fetch instruction from primary memory and place in instruction register
○ Set program counter to the next instructions address
○ Decode the instruction
○ Load operands from memory into a register
○ Execute the instruction and store result in an accumulator (generally the ALU will
execute the task)
○ Reset
● use of a program counter and instruction register
○ The program counter is a register that is part of the computer’s CPU
○ The program counter stores the address of the next instruction to be executed
○ Instructions are generally stored sequentially unless the instruction is to change the
program counter
○ The instruction register is where the instruction is either being decoded or executed
is stored
● execution of called routines
○ A register called the ‘stack pointer’ is used to keep track of the location of the
beginning of a part of main memory known as the stack
○ The stack is then used by the CPU to hold the address of the next instruction when a
subprogram is run or called
○ The CPU can then return to the correct position in the main program when the
subprogram is finished
○ The stack is a set of locations in main memory used by the CPU
○ The stack is a LIFO list
○ The last location in the stack to have a value placed in it is called the top of the stack
● linking, including use of DLLs
○ Linking allows for machine code programs to be combined with other machine code
programs
○ Because larger programs are modular in nature, the linker is used to join these
modules
○ Since programs must be in the RAM to be executed, linkers save resources because
only the needed modules are loaded
○ DLLs are a library of machine code programs which can be accessed by others to
perform specific tasks
○ DLL files allow programs common access to resources and provide efficient use of
the memory
○ When a program requires a sub procedure, its address is stored in a linker
○ The linker calls the sub routine into the main program
○ The sub routine gains control
○ When finished, control is passed back to the main program
○ Provides method of updating software without rewriting main program

The Fetch, Decode and Execute Cycle

 The Fetch-Execute Cycle: What's Your Computer Actually Doing?
● A basic computer can simply comprise of:
○ CPU - Central Processing Unit
■ Clock - ticks periodically, performing a function every clock tick.
■ Registers - Small sets of data holding locations for the CPU, which are
extremely fast. There are three main registers for the Fetch-Execute cycle.
● Program Counter - A register which stores what program step the
CPU is up to.
● Instruction Register - A register which stores the instruction the CPU
is to execute.
● Accumulator - A register which stores any data that the CPU is
performing operations, or has performed operations on.
○ RAM - Random Access Memory
■ RAM is used to store the instructions, and their order, for the CPU to execute.
● When the CPU performs operations (a computer is a glorified calculator), it undergoes what
as known as the Fetch, Decode and Execute Cycle, also known as the Fetch-Execute Cycle.
● The cycle goes as so, with each step taking one clock tick.
○ Fetch - The CPU retrieves the next instruction (as dictated by the Program Counter),
retrieving it from the correct RAM address. This instruction is stored in the
Instruction Register.
○ Decode - The CPU decodes the contents of the Instruction Register (e.g. ADD 1 to 6)
○ Execute - The CPU executes the instruction it has decoded, storing the result in the
Accumulator.
■ Important to note that the Accumulator is not where the end result is
permanently stored; an instruction to store the accumulator’s content into
RAM usually follows a calculation instruction.
● This cycle repeats indefinitely, unless one of the instructions given terminates the set of
instructions that the CPU has been following, in which case, the CPU moves onto/receives a
new set of instructions.

Techniques used in developing well-written code

● the use of good programming practice, including:
○ a clear and uncluttered mainline
■ Software projects should be developed using a clear modular approach
■ In general, the mainline should be clear and uncluttered, so it is easy to
follow and identify subroutine calls
■ This means that the subroutines are coded and tested independently, which
is better for maintenance reasons
○ one logical task per subroutine
■ The name should be able to describe the algorithm succinctly
■ When the algorithm becomes too long it becomes more difficult to
understand and therefore to maintain
○ use of stubs
 ■ A stub is an incomplete function that has the same name as interface as the
final form but simpler
■ Stubs usually only contain an output statement to indicate the function was
called
■ It is used in testing the implementation of a program
○ use of drivers
■ A driver can be considered the “inverse” of a stub, in the sense that stubs act
as a false function/module to be called for testing, while drivers act as a false
calling of a function or module, to test these functions/modules
○ appropriate use of control structures and data structures
■ Control structures should only use recognised statements such as pre or
post-test loops
■ The condition for the loop should determine the only exit from the loop
■ There shouldn’t be jump that cause control to exit a loop or selection
unexpectedly
■ Types and unusual cases should be considered when making repetition or
selection structures
■ Data structure such as arrays, records, array of records and others should be
○ writing for subsequent maintenance
■ Coding should be done in such a way that future maintenance programmers
can easily update the code
■ Good ways to make the code accessible for maintenance includes:
● Clear documentation within the code
● Appropriate identifiers names
● Identing within control structures
○ version control
■ Version control allows complete applications to be continuously developed
with regular version being released to users
■ Version control allows reversion to a previous version any time in the future
■ Version control systems are routinely used by teams of programmers
because it routinely does all the above functions
○ regular backup
■ During coding all programmers should regularly save their work to prevent
loss, and allow for different versions of the program or module
■ Regular backup should be done to various devices instead of single one to
prevent absolute loss
○ recognition of relevant social and ethical issues
■ Social and ethical issues should be considered when developing:
● Intellectual property
● Thorough testing
● Documentation for future developers and maintainers
● the process of detecting and correcting errors, including:
○ types of error
 ■ syntax errors
● Mistakes in the source code, such as spelling and punctuation errors,
incorrect labels/functions etc.
● Syntax errors are involved in the translation process
● Syntax errors prevent the translating high-level code to object code
● Syntax errors are detected as a result of lexical analysis and
syntactical analysis in the translation process
● Once a syntax error has been detected, it is usually a simple task to
correct.
● Example in Python:
○ priint(“Hello World!”)
○ has print misspelled, leading to a syntax error
■ logic errors
● A bug in a program that causes it to operate incorrectly, but not
terminate abnormally/crash
● However, it does give way to unanticipated and erroneous behaviour
in the program
● Syntactically, the code is correct, but it does not complete the correct
task at hand
● They are the most difficult error to correct, as the program runs as
normal
● It is impossible for the development environment to detect logic
errors, with the users having to notice these
● Example in Python:
○ while true:
■ print(“Kumalala Kumalala Kumala Savesta”)
○ This code would infinitely run, and not have any condition
upon to stop, which would be erroneous for many (if not all)
applications.
○ This leads to a logic error, as there is nothing syntactically
wrong.
○ runtime errors, including:
■ arithmetic overflow
● Involves the incorrect use of data types and data structures
● Usually when the result cannot be stored properly
● E,g, a large enough result may not be able to be stored properly,
resulting in this overflow error.
● division by zero
○ As with mathematics, a division by 0 would lead to an infinite
result (which is represented by a limit), but this cannot be
comprehended by a computer, and would theoretically take
an infinite amount of storage.
 ● As a result, this division by 0 results in an error, which is a form of an
arithmetic error
■ comparison errors
● Comparisons are attempted on different data types, or a choice of
multiple comparisons is not correct e.g., using AND as a comparison
when OR should have been used instead
■ Control logic errors
● Looping or branching does not perform correctly usually due to the
wrong choice of comparison, boundary values, or incorrect
initialisation or termination when using loops
■ Data structure errors
● Using data structures that internal to the module e.g. flags, counters,
accumulators (variables used inside the module to total amounts)
■ Input/output errors
● Occur when reading/writing files
● Testing this part of a module ensures that data items received from a
file are those that are expected
■ Interface error detection
● Parameters passed from one module to another are the focus of
interface error detection
● Parameters tested include data items passed between modules, and
data items ued for control such as flags
■ accessing inappropriate memory locations
● This error occurs when inappropriate memory locations are
accessed.
● methods of error detection and correction
○ use of flags
■ Flags are a marker placed in the code to signal a change in status
■ Code that will change the value of a flag is added to an appropriate location
■ An example for Python is the placement of a boolean for a post-test loop,
which acts as a flag
● Originally acting as true, when the loop triggers a condition for the
flag to be false, the change in status would end the loop, causing the
program to move on to the next module/end.
○ methodical approach to the isolation of logic errors
■ When a logic error is encountered, the best course of action is to split code
into various sections and test each separately.
■ This can be done using the comment tool, which stops certain lines of code
from running.
■ By commenting out blocks of code, they can systematically find the precise
location of an error.
 ■ However, commenting out sections of code can prove to be dangerous, as this
can cause more logic errors or even syntax errors, so programmers must be
cautious
○ use of debugging output statements
■ Debugging output statements are temporary lines of code added to display
the value of a variable
■ It may also be used to state that a part of code has been reached
■ Python example:
● dogcount = int(input(“How many dogs do you have? “))
● print(str(dogcount))
● total = dogcount + catcount
○ peer checking
■ Involves the checking of code alongside another person (usually a
programmer)
■ They are able to see the code outside the scope you have seen it in usually,
and so can point out errors you have misse
○ desk checking
■ Test data is used to compare the actual result with the expected results
■ Use a structured walk through to step through the code and find where
errors occur
■ Desk checking should be performed on sub and whole programs
■ Example below:

○ structured walkthrough
■ Similar to the desk checking process above, a structured walkthrough is
usually more formal than peer checks, with an evaluation of code by walking
through each line
■ No attempt is made to correct problems, only feedback is given
■ Made to evaluate design at different levels
○ comparison of actual with expected output
 ■ The output of initial tests should be compared with expected output that has
been determined in the planning and design stage
■ If the actual and expected output vary, then a logic error has more than likely
occurred
■ All paths in logic should be tested
■ Often in large programs, subroutines or individual modules are tested by
individuals for logic errors
■ Testing software may assist in the testing of logic, particularly in large
software development projects
○ the use of software debugging tools, including:
■ use of breakpoints
● A simple technique which may temporarily or permanently stop
executions
● Used to check variable contents before and after processes occur
● Breakpoints are placed in areas where errors may exist, to locate the
source of error
● Many development environments (IDE’s) allow lines of code to be
marked with a breakpoint
○ For example, Visual Studio Code allows breakpoints to be
placed and the code ran up until/from the breakpoint, to
check for errors.
■ resetting variable contents
● The data stored in a variable can be changed while the program is
running
● The program is usually halted using a breakpoint
● Can be used to check which values are giving errors by changing the
values when execution has stopped
■ program traces
● Allows the programmer to view progress of the program execution in
detail
● The order of line executions is tracked, analysing the flow of the
statements
● Particularly useful for following the progress of the program through
nested loops or complicated section
● A log of transitions from section to section is often created, and this
trace log can be used to identify sources of errors
■ single line stepping
● A variable trace enables the programmer to observe the variable
changing throughout the program
● Single line stepping is the process of halting the executions after each
line or statement
● A keystroke is usually required to step through lines (such as Enter,
or K)
 ● Usually used to concentrate on a sub routine instead of the whole
program
● Some IDE’s also allow for the stepping back of programs, which allow
programmers to double-check whether certain lines are the ones
causing logic errors
■ Watch expressions
● Expressions whose values are written to a separate watch window
● These watch expressions can be variables present in the code
themselves, as well as calculations separate to the program lines of
code
● This can provide automated desk checking, as watch windows are
automatically updated
● An example of a watch window can be seen below:

■ It is important to note that a combination of these methods can be used,

even simultaneously
● For example, a watch window can be used with stepping through
lines, to digitally desk check the program

Documentation of a software solution

● forms of documentation, including:
○ log book
■ A log kept by all members of the development team, of all the steps taken in
the development process
■ Annotated and dated regularly to avoid the loss of important steps and tests
■ If an error occurs, its date of occurrence can be cross-referenced with the
logbook, to check the changes made to the project before then
○ user documentation, including:
■ user manual
 ● Paper or online external documentation that is user-friendly, so an
everyday user can understand the information presented, and is
provided to the user for instructions on how to use the software
effectively
● The manual needs to be designed with accordance to the level of
expertise the target user had/has, and needs to cater for the
experienced and inexperienced
● Should state:
○ How to get started
○ How users may use common functions
○ How to fix mistakes
○ How to recover work that may have been lost
○ Troubleshooting guide
● Example of a User Manual (Online)
■ reference manual
● Similar to a user manual, but is much less detailed and usually just
for a “quick reference” for any minor issues users may be having
■ installation guide
● A program installation guide is also included within user
documentation, and should include:
○ Details on how to install the program and descriptions of the
mediums supplied
○ Minimum hardware specifications
○ Details of any known conflicts with any other software
● It is very useful to use screenshots in the user manual, as the users
can effectively compare what stage they are up to, confirming that
they are on the right track
■ Tutorial
● Guide the user through the steps of working with features of a
program
● Tutorials usually train the user how to use the program
■ online help
● Online help systems provide updated solutions to various problems,
providing the user with information from the internet - FAQ’s are
also provided to aid the user
● Having the help documentation online enables easy addition and
updating of the help information
● Internet connections are usually required
○ technical documentation, including:
■ systems documentation
● Systems documentation should provide a description of the
operation of the program including the use of subprograms and any
special features of the code
 ● Should include documentation on how to configure the hardware
and software required
■ Algorithms
● Primarily used during program design to provide a clear description
of the steps carried out to solve any problems
● Consists of the standard algorithms present throughout the program,
so whoever is maintaining the program is able to easily understand it
■ source code
● Programming code that makes up a program
● Documentation within the source code are in the form of comments
and intrinsic information, which describes lines of code and their
purpose
■ use of application software including CASE tools to assist in the
documentation process
● CASE tools may be used during the development
● CASE tools use templates for documentation
● CASE tools provide a standardised approach to documentation
● Automates process of documentation
Testing and evaluating of software solutions
Testing the software solution
● Stages of testing
○ Alpha testing
■ Testing of the final solution by personnel within the software development
company prior to the product’s released
○ Beta testing
■ Testing of the final solution by a limited numbers of users outside the
software development company using real world data and conditions
○ Aspects to testing a software solution
■ Validation
● Process of comparing the solution with the design specifications
■ Verification
● Process of ensuring that the software performs its function correctly
● comparison of the solution with the design specifications
○ Design specifications should be written in a form that provides a set of measurable
performance criteria.
○ The following guidelines can be used to review the design specifications:
■ Ensure specifications are written in terms of measurable outcomes
■ Clarify any vague terms (sometimes, usually etc.)
■ Clarify any ambiguous statements
■ Incomplete lists of items should be avoided
■ Calculations should be accompanied by examples
■ Pictures and diagrams should be used to clarify the program’s structure
 ○ If the above is followed in the specifications document, an objective evaluation of the
project can be made.
○ The process of validation involves the use of the software in a real situation with real
data, so its performance can be compared under conditions that are close as possible
to the final environment
● generating relevant test data for complex solutions
○ Outside the programmer(s)’s systems, test data should be generated so that external
operation factors outside the control of the programmer are tested against the
program, such as:
■ User and environment inputs
■ Variations in hardware such as CPU, memory, graphics processors, and
peripherals
■ Different OS
■ Changing technologies such as cloud storage and wireless systems
● black box testing
○ Also known as functional testing
○ The inputs and expected outputs are known; the processes occurring are unknown.
○ Does not attempt to identify the source of the problem, but rather to identify that a
problem exists
○ Concentrates on their input and their expected output
○ Helps find the gaps in functionality, usability and other features
○ Boundary analysis
■ Involves the selecting of test data elements that represent either side of a
boundary where the effects of processing are different
■ For example, an online store might charge a customer full-price shipping for
orders less than $20, half-price shipping for orders over $20 but less than
$100, and free shipping for all orders over $100.
● The boundaries for this program are for order amounts of $20 and
$100
● Therefore, test data for this program would include values of less
than $20, between $20, and more than $100.
● The output from all of these inputs would be compared with the
expected outputs that are manually calculated.
○ Equivalence partitioning:
■ Breaking up the input data into groups that have the same properties
● white box testing
○ Also known as structural or open box testing
○ Software testing technique whereby explicit knowledge of the internal workings of
the products being tested are used
○ Helps verify the inner workings of an application
● statement coverage testing
○ The execution of every statement in the module
● decision-condition coverage testing
 ○ Involves testing the execution of each decision in a control structure with a true and
false for each one (Boolean variables, loop conditions, if statements etc.)
● exhaustive condition coverage
○ Tests all the possible combinations of true and false for each condition
○ Bring out any unexpected errors that may occur with unusual data combinations
○ Very thorough

● levels of testing
○ Module
■ Tests each module and subroutine functions correctly
■ Each module should be treated like a stand-alone program that doesn’t
require any other parts of the program to function
■ The module is tested with a set of appropriate test data in order to reveal
any faults in processing
○ Program
■ Test that the overall program (including incorporated modules and
subroutines) functions correctly
■ The process of combining the modules in the program is called integration
■ Testing that occurs as part of this process is called integration testing
○ System
■ test that the overall system (including all programs in the suite) functions
correctly, including the interfaces between programs
■ Focuses on four different types of testing:
● Performance testing
○ Used to measure the quality of the software’s performance by
increasing the load on the software until it fails
● Recovery testing
○ Used to check the system’s ability to recover from a fault, and
involves a series of tests that force the system to fail
○ Then measures the system’s ability to recover on its own, or
the time that it takes for humans to recover it
● Security testing
○ Involves trying to breach the security of the system
● Stress testing
○ Involves creating situations that may cause the system to fail,
such as rapid reading/writing to the disk and maximum
usage of memory
○ This would physically “stress” the system
○ These tests will help the developer determine whether the
system will cope or fail in different situations
○ Acceptance testing
 ■ Carried out by users of custom-built software to determine whether the
requirements have been met, and whether the software can successfully
operate within the system
■ Real data is used during the stage of testing, to ensure the program
completes the processes and procedures it was designed for
■ At this stage, the developer can also see how the user interacts with the
software and detect any problems that might have been missed in early
testing
■ Acceptance testing is also an opportunity to train users in how to operate the
system
● Approaches to the assembly of code
○ Top down approach:
■ A program driver module is tested first with stubs, representing lower
modules
■ When the driver module works properly, modules are then gradually added
one-by-one
■ When an added module has been tested and corrections made and further
tested, then the next module is added so on until the program is complete
■ The advantage of using this method is that errors that are detected will be
from the most recently added module so they will be easier to find and
correct
■ This approach can also be used to build large modules from a number of
smaller sub-modules
○ Bottom up approach:
■ The lower-level modules are tested first, then added together one-by-one
while testing, modifying and then further testing the larger module until it
functions properly without errors
■ The module is built up from smaller modules to a complete functioning
program
■ The driver module is the last one to be added, with a in-place driver being
used beforehand
● the use of live test data to ensure that the testing environment accurately reflects the
expected environment in which the new system will operate
○ large file sizes
■ The use of large files will highlight problems associated with data access
■ Often systems that perform at acceptable speeds with small data files
become unacceptably slow when large files are accessed
■ Particularly the case when data is accessed using networks
○ mix of transaction types
■ Testing needs to include random mixes of translation types
■ If data is altered by another transaction, then problems can occur
■ Software must include mechanisms to deal with such eventualities
○ response times
 ■ The response time of an application is the time the system takes to respond
to data input
■ Live data will subject the system to real processing requests and therefore
will provide a simulation of a real response time
■ Any processes that are likely to take more than one second should provide
feedback to the user e.g. progress bar
○ volume of data (load testing)
■ Large amounts of data should be entered into the new system to test the
application under extreme load conditions
■ Multi-user products should be tested with a large number of users entering
and processing data simultaneously
■ CASE tools are available that enable the automatic completion of data entry
forms to simulate thousands of users entering data to load test during alpha
testing
○ effect of the new system on the existing systems in the environment into which it
will be installed
■ It is also important to test how well the new system will interact with the
existing system in the environment into which it will be installed, and to
observe any undesirable effects.
○ Interfaces between modules and programs
■ Provides a communication link between system components
■ Interface is usually provided with parameters that are used to pass data to
and from modules
■ Require testing to make sure the connections between modules work
efficiently
○ Comparison with program test data
■ Comparison can highlight any errors or problems
■ The output from live data testing is compared with the output of developer
testing to determine effectiveness
○ Benchmarking
■ Process of evaluating a product using a series of tests; these tests provide
numerical results that are compared with recognised standards
■ Benchmark: A point of reference from which quality or excellence is
measured
■ These results allow users of software products to make informed purchasing
decisions
■ Benchmarking aims to reduce the number of variables and to report results
objectively
■ Compare results to competitors to maintain and improve market penetration
Reporting on the testing process
● Test description including the test requirements
○ States scope of testing
○ States purpose and nature of system
 ○ Procedure necessary to prepare hardware and software for testing
○ A description of each test including prerequisite conditions, test inputs, expected
test results, evaluation criteria, assumptions and constraints
○ Connection of relationship of the tests to the requirements
● Test data including test data and expected results
○ Scope of testing
○ Overview of system
○ Description of test environment
○ List of modules ot be tested, the tests to be performed and the scheduling of testing
○ Connection or relationship of the tests to the requiremtns
● Test report including results and recommendations
○ Scope of testing
○ Overview of testing outlining deficiencies and impacts on the other parts of the
system
○ Steps that may be taken to overcome deficiencies and impacts
○ Assesses the impact of testing environment
○ Test result details
● CASE tools
○ Test data generator
○ Word processor
○ File comparator
○ WinRunner
○ LoadRunner
○ DataTech
○ UsableNet
Communication of testing
● The nature of the project will determine the audience for the test results
● Large software development companies usually have separately development and testing
personnel, and testers must communicate their findings back to the development team
● Communication with the client
○ Language must be non-technical
○ Address any requirements and design specifications that have not been adequately
fulfilled
○ Rank problems in terms of severity
○ Upfront and honest about the capabilities of the product
○ To assist in the communication, it is common to give a demonstration of the system
to the users
● Communication with the developers
○ Testing departments need to communicate their results back to the development
team
○ Highlight problems in order of severity
○ Recommendations must be backed up with technical justifications
○ Actual test data will help developers correcting or modifying products
Evaluating the software solution
● verifying the requirements have been met appropriately
● quality assurance
○ Functional quality: How well it complies with or conforms to a given design, based
on requirements
○ Structural quality: How it meets non-functional requirements that support the
delivery of the functional requirements such as robustness or maintainability
○ Terms:
○ Clarity - precise and unambiguous instructions
○ Correctness - consistent output from the same input
○ Documentation - accurate without spelling, grammar and process errors
○ Economy - economical use of software and hardware resources
○ Efficiency - ease of completing tasks
○ Flexibility - ability to cope with situations encountered within the operation
of the program
○ Generality - software communicating with existing systems
○ Maintainability - correction of problems and errors
○ Modifiability - ability to change the software
○ Modularity - software parts are easily able to be replaced
○ Portability - ability to be executed within different software and hardware
environments
○ Reliability - a measure of failure rate
○ Resilience - ability to recover from abnormal situations and errors
○ Reusability - modules may be reused within other similar software projects
○ Understandability - how well the design of the software is understood
○ Usability - aspects important to the user, how easy the program is to learn
○ Validity - how the software meets the specifications of the user
Post implementation review
● facilitation of open discussion and evaluation with the client
○ Open discussion with client if the requirements have been met to a standard
○ For a large development, independent review may be performed to remove any
unintended bias
○ Acceptance testing may also occur once again, as a final test of the system
● client sign off process
○ The client will sign off on the project when acceptance testing has been carried out,
and the client is happy with the outcome

Maintaining software solutions

● Modifying code to meet changed requirements
○ It is common for changes after the development as user requirements evolve and
change
○ Modifying and maintenance of the problem may involve the structured program
development approach
○ Following this approach ensures effective changes are met
○ It is important for software developers to create and maintain the documentation as
well
○ Help desk support may also receive requests for changes or identity issues that need
to be fixed
○ Changes would need to be prioritised based on the severity of the issue
○ Developer websites often provide the option to report an issue and download a
patch for known issues
■ Patch: Used to correct a problem in a software solution. A patch is an actual
piece of executable code that is inserted into an existing executable program.
○ identifying reasons for change in source code
■ Maintenance may be carried out for the following reasons:
● Errors in code
● Changes in the operating environment
● Changes in requirements, such as increased functions required by
the client
■ Examples of reasons for modifying code:
● Poor logic in original code
● Changing users requirements
● Improvement for efficiency
● Improved security
● Upgrading the user interface
● Changes in data to be processed
● New hardware and/or software
● Changes in business requirements
● Changes in government requirements
■ Operating environment changes may include:
● Changes in the programs that interfere with the program
● Changes in the operating system
● Changes in hardware and associated utilities/software drivers (not
code drivers)
○ locating of sections to be altered
■ When an error in a program has been detected, the developer must be able
to find the location within the source code
■ Well-structured and well documented code will simplify the process of
isolating and correcting errors
■ When a modification is to be made, design documentation and source code
will be used to determine the exact location of the change required
■ Features that improve maintainability may include
● Well set out design documentation - such as IPO, data flow diagrams,
structure charts, algorithms, and source code
 ● Use of variables instead of literal constants
● Constants or global variables defined at the beginning of code
● Use of meaningful identifiers (internal documentation)
● Design comments/remark throughout code (internal
documentation)
● Code that incorporates a good error reporting system
● Use of correct control structures
● Modularisation of code
● One logical tasks per function/subroutine
○ determining changes to be made
■ There may be different reasons for changes to be made:
● Changes due to logic will require source code changes
● Changes to interface design may involve minor layout adjustments or
a completely new layout design
● Addition of new functions and requirements
○ implementing and testing solution
■ Once errors have been detected and located how will the change be
implemented
■ Methods for correcting code may include:
● Minor source code adjustments
● Software patch which may include several minor source code
adjustments
● New version implementation which may include the redesign of
several functions
● Software reengineering may be required if several modules need
improving
● A completely new system development
■ All changes should be thoroughly tested before being fully implemented
■ Even minor source code adjustments will need to be compiled
■ Regression testing is the process of retesting a program when changes have
been made
● Documenting changes
○ Should always be carried out when making changes to software
○ Responsibility of the software maintainer
○ Part of project management
○ Management of software resources is called configuration management
○ Documentation should be accurate and up to date, reflecting changes as they occur
○ including relevant comments in the source code to highlight the modification
■ Comments and remarks should be made in the source code to indicate that
there has been maintenance on the code, and what specifically has been
reworked/removed/fixed
■ Longer modification notes can be made within the headers of source code,
for added detail
○ updating associated hard copy documentation and online help
■ Hard copy documentation should also be updated, such as the system
developer’s notes, developers process diaries
■ Furthermore, manuals, references and online help must also be updated:
● Release notes
● Addendum to manuals
● Reprint of manuals or providing new manuals in PDF form
● Reinstallation of help files
○ using CASE tools to monitor changes and versions (see Course Specifications
document)
■ Word processors and PDF editors can help edit hard copy documentation
■ Online documentation for software projects (such as a logbook or a change
document) can also for the monitoring of changes and version
Module 3: Developing a Solution Package
Designing and developing a software solution to a complex problem
● defining and understanding the problem
○ identification of the problem
○ generation of ideas
○ communication with others involved in the proposed system
○ draft interface design
○ representing the system using diagrams
○ selection of appropriate data structures
○ applying project management techniques
○ consideration of all social and ethical issues
● planning and designing
○ algorithm design
○ refined systems modelling, such as:
■ IPO diagrams
■ context diagrams
■ data flow diagrams (DFDs)
■ Storyboards
■ structure charts
■ system flowcharts
■ data dictionaries
■ additional resources
● Gantt charts
● Logbooks
● Algorithms
● Prototypes
○ selecting software environment
○ identifying appropriate hardware
○ selecting appropriate data structures
○ defining files
■ Purpose
■ Contents
■ Organisation
○ defining records
○ defining required validation processes
○ identifying relevant standard or common modules or subroutines
○ using software to document design
○ identifying appropriate test data
○ enabling and incorporating feedback from users at regular intervals
○ considering all social and ethical issues
○ communicating with others involved in the proposed system
○ applying project management techniques
● Implementing
 ○ converting the solution into code
○ systematic removal of errors
○ refining the data dictionary
○ including standard or common modules or subroutines
○ using software to refine documentation
○ creating online help
○ reporting on the status of the system at regular intervals
○ applying project management techniques
● Testing and evaluating
○ completing thorough program and system testing
○ completing all user documentation for the project
● Maintaining
○ modifying the project to ensure:
■ an improved, more elegant solution
■ all needs have been met
■ the software solution operates under changed environments or
requirements
■ updating the software specifications and documentation to reflect the
changes

Module 4 Option 2: The interrelationship between

Hardware
Option Topic 2: The Interrelationship Between Software and Hardware Notes
Representation of data
● Characters
○ ASCII
○ Unicode
● Numbers
○ Binary
○ Hexadecimal
○ Decimal
● Two’s complement
○ Addition / Subtraction
● Floating Point
○ IEEE754 Representation
○ Large and small values
● Binary Arithmetic
○ Addition
○ Subtraction
○ Multiplication
○ Division
Electronic Circuits
● Logic Gates
○ AND
○ OR
○ NOT
○ NAND
○ NOR
○ XOR
● Truth Tables
● Boolean Algebra
○ Describing a circuit
○ Simplifying a circuit
● Circuit Design steps
○ Identifying an input and output
● Speciality circuits
○ Half Adder
○ Full Adder
○ Flip Flops
Programming of Devices
● Data Streams
○ Header
○ Data Block
○ Trailer
● Use of Control Characters
● Using hardware to display an expected data stream