Social and Ethical Issues

Syllabus dot points:

● explains the relationship between emerging technologies and software
development
● identifies and evaluates legal, social, and ethical issues in a number of
contexts

The Impact of Software

● Controls essential services (water, gas, electricity)
● Communications is run on software (including traditional phone lines)
● Financial transactions
● Physical products need software for design and manufacturing
● Electronically run products have embedded software

The Year 2000 (Y2K) Problem

In the 1960s and 1970s storage was expensive so software was required to use the
absolute minimum amount of storage space. To cater to this need, software developers
often used only 2 digits to represent the year within dates. It was never envisaged that
these products would still be in use when the Year 2000 came along. As a
consequence of this short-sightedness, it was anticipated that many computer-based
systems would fail as the year changed from 1999 to 2000. That is, the software
would potentially think that the year was 1900 and not 2000. Similar problems were
expected with regard to other years, such as 1960 being interpreted as 2060 and hence
causing a variety of incorrect calculations and computer crashes.

Computer Malware (including viruses)

Define: any software which performs an unwanted or uninvited task.
Examples: viruses, worms, Trojan horses, and spyware.
New malicious software appears somewhere in the world on a daily basis. Anti-virus,
anti-malware and anti-spyware utilities are installed to detect and destroy malware and
to advise users of potentially unsafe practices or websites.

Viruses:
● Distinguished by the ability to replicate themself
● commonly attached or embedded within apparently legitimate software/files
 ● The virus will execute along with the attached software; duplicate and perform its
malicious processing
● It will then continue to spread through email/other electronic mail

Worms:
● Type of virus
● Slow down a system
● Many worms exploit a security flaw in the operating system and then install
themselves on the hard drive (often as hidden files).
● As it replicates, the worm will start to (and eventually will) take over the entire
hard-drive
● Some other worms will continue to execute copies of themselves; this could lead
to the RAM being taken over as well
○ This will either slow down programs or take over the RAM enough that
they can’t be run at all

Trojan Horse:
● Malicious software that appears to be legitimate
● Can delete or corrupt files
● Often a trojan horse is used to install malware that will give an outside user
access to/the ability to take over the computer
● Botnets (aka zombie armies): a bunch (sometimes thousands/hundreds of
thousands) that have been taken over by the same malware and are being
controlled by the same thing
○ denial of service (DoS) attacks occur when all computers in a botnet are
instructed to access a single website. The web server is unable to process
all the requests and hence the website crashes or is unable to process
legitimate requests. Such attacks can come from competitors who wish to
cripple the competition.
○ Botnets are routinely used to send spam messages.
○ The botnet provides a level of cover for the criminal operator as it appears
the spam messages are from a legitimate source.

Spyware:
● Aim to obtain your information without your knowledge. Examples:
○ web browsing habits
○ your email contacts
○ keystrokes as you enter passwords and credit card details
● Used for fraud and identity theft
○ Identity theft is particularly harmful
 ○ They can steal your money
○ But also ruin your reputation and make it very difficult to obtain credit

Reliance on Software
We are often unaware of the impact of computers and software on our everyday lives.
-household appliances (ovens, tvs, videos, stereos)
-motorized transport (car, train, plane)
-utilities (gas, water, electricity)
-government authorities (social security, tax office)
Summary: we use software so much that we completely rely on it

Social Networking
Social network: a group of people who associate with each other
Recently, this idea has expanded into the online world with the popularisation of social
media.

Clearly, social networking sites have many varied and worthwhile advantages,
however, there are also disadvantages. Private and personal information is all too
easily shared and this can (and has) led to a variety of problems including identity
theft, stalking, and online bullying. The ability of a single message to be delivered to
thousands of unknown others has the potential for unintended consequences, such as
thousands of people arriving at a party. Comments made on an online site can remain
accessible indefinitely. Views you may hold now and comments made as a teenager
may be embarrassing and inappropriate when viewed by some future employer or by
your future children and friends.

Cyber Safety
Risks:
● Location Based services
● Unwanted contact
● Cyber Bullying
● Catfishing
● Digital Footprint
● Online Purchases (scams, ongoing payments)
● Identity theft

Evaluating information available through the internet

On the internet biased, unsupported, unverifiable, misleading, and often
incorrect information is common. Although the internet encourages freedom of speech
for all, it has the unfortunate consequence that determining the correctness of such
information is difficult and often impossible. This is a particular issue when performing
research as verifying the accuracy of information is a necessity.

Guidelines to look for:

● The author - should be easily identified, look for qualifications; a reputable
organisation, address or phone number can increase confidence in the legitimacy
● Is the info up to date?
● Who is the intended audience (this is starting to sound like history) - is it a factual
or opinion piece? Be aware of political, religious or cultural bias.
● What is the purpose of the information - an advertisement/promotions are usually
not trustworthy

Rights + Responsibilities of Software Developers

Intellectual property
- Authors have the right to control how the work is sold and distributed
Quality
- It is a responsibility for developers to meet the quality assurance requirements
- Different customers will have different expectations but all of them have the right
to have these expectations met
Things that affect quality
● Hardware
○ Software developers have the right to expect hardware developers to
provide reliable components
○ Developers have a responsibility to test their products with types of
hardware
○ It is the responsibility of the software developers to build modules which
will react appropriately to inevitable hardware problems
● OS
○ Designers have a responsibility to consider how their software will interact
with a variety of OS
○ Applications should not change OS settings
● Other installed software
○ Developers have the right to expect that other software will not affect
theirs
 ○ They also have the responsibility the ensure the same of their own
software
● Run time errors
○ Error checking must be built into the code
○ Stop fatal errors at all costs as it can result in lost user data
● Responses to problems
○ Responsibility to ensure that problems are resolves in a timely, accurate
and efficient manner
○ The worse the problem, the more quickly it should be solved

● Code of conduct

Code of Conduct
: a set of standards by which Software Developers agree to abide.

A Code of Conduct is a set of standards by which Software Developers agree to abide.

Many professional software developers are members of professional associations that
expect adherence to a written Code of Conduct. It is the responsibility of the
individual developer to uphold the Code of Conduct. Doing so enhances the
reputation of themselves as well as the profession as a whole. In the long term,
accepted Codes of Conduct increase standards across the entire industry. Most
professional associations have rules, which allow for members to be expelled if they
fail to uphold the association’s Code of Conduct. Clients of members of the
association can complain to the association if they feel one of its members is not
transacting business in accordance with the Code of Conduct. Members of the
association should encourage adherence to the Code of Conduct by other members of
the association.
 Summary: uphold the code of conduct, it will help your reputation and also
your ability to not get fired.

Malware
● Software designers have a responsibility to make sure that there is no malware
attached to their software. This includes following these steps:
○ All incoming emails scanned for viruses and other malware.
○ Removable media scanned for malware before use.
○ Update anti-virus software regularly.
○ Scan all software before distribution to purchasers.
○ Use firewalls and other security mechanisms to minimize the risk of
security breaches.
● Similarly, users have to right to expect a malware free product
Ergonomics
User Needs
: not what the software needs to do, but how the user would prefer to do it.
The program must make sense to the users and integrate with their way of doing things.
It is often useful to record other software applications that are routinely used so that
consistency of design across applications can be assessed.

User Interface Design

Functionality is of little value if the users cannot understand how to access the
functions. The most important aspect of interface design is consistency of design. A
mental model of the software application’s operation is built up in the user’s mind;
consistency reinforces this model.
Important points:
● Setting standards and sticking to them. Design should be based on industry or
well-known standards before adding extra elements to the design. Most
operating system developers have sets of design standards; these standards will
often define much of the design.
● Explain the rules. There should be a simple set of rules that apply to the entire
application; and this way you will only need to explain things once.
● Use interface elements correctly. Know when to use a checkbox vs textbox etc…
● Use colour appropriately and sparingly. Don’t override a user’s system settings,
they chose them and your application should not override their choices. This
ensures consistency between applications. Ensure you maintain sufficient
contrast between text and backgrounds.
● Use appropriate fonts. Users do not want their eyes to be assaulted every time
they open the application. Fancy fonts also decrease readability.
● Alignment of elements; makes everything looker neater and easier to
understand.

Usability testing: Should be done continuously throughout the development process to

ensure that the products meet the needs of the users There are a variety of options for
usability testing:
● prototypes of each screen can be distributed to specific users for comment
● representative users can be included on the development team (which is integral
to the agile approach)
● task analysis can be undertaken with random groups of users
Whichever techniques are chosen the testing should be repeated once the identified
usability issues have been corrected. That is, the best usability testing is iterative. It
progressively refines the user experience until an optimal solution is reached (or time
and budget are exhausted).
Inclusivity

Cultural Background
: the set of ways of living built up over a period of time and passed from generation to
generation.
It is not possible to be an expert on all cultures; however, we can easily include users
from a variety of cultures as part of the testing processes occurring during development.
Things to consider/examples:
● In most western countries people will have a first name and a surname; however
in some eastern countries it is more common to have a formal and informal name
● Dates structure (day/month/year vs month/day/year)
● Currency form
● Differing grammar
● Other languages/translations
○ Most worldwide programs will have one single file with all of the text on it
that will be put into the program at execution
○ Because of this translations will only need to change one file, rather than
re-writing the entire application
● times/timezone
● Religious beliefs
○ Many religions pray at a certain time of the day. Perhaps software can be
written so that processor-intensive batch operations can be performed at
this time.
○ Many attempts at humour could be seen as distasteful/disrespectful in
other religions
○ Many images that are considered appropriate in the west are not in
eastern countries
○ Things specific to one culture: ex. Aboriginal people don’t look at images
of people who have died

Economic Background
Unlike most products/industries, software costs are mostly influenced by design and
development, rather than the cost of materials. Products should be priced appropriately
to ensure that it is available to the widest possible economic classes while still paying
the authors a fair amount.
Things that can affect costs include:
● Quality
 ● Nature of the market: It is not economically feasible to develop a product where
the need it is intended to meet is of less value than the product’s cost.
● Management of the software design and development process: Choosing a
suitable development approach (e.g. agile, structured) By creating structures that
help developers work more effectively, managers will reduce costs and increase
the quality of the software produced.
● Capitalism: companies are ultimately in it to make money, and this often involves
a decrease in quality as well. Some government regulations can help stop this,
but it does still occur

Gender (ugh)
The development team should be an even mix of both sexes. As men have mostly
dominated the software development field, it is easy for the applications to be suited
towards men, this needs to be counteracted in order to achieve a more inclusive
product.

Disability
Visual Disabilities
● The ability to make fonts larger should be included: this is usually included in the
operating system
● Colour should not be used to distinguish between two things (I'm looking at you,
mac safari closing buttons) in case of colour blindness
● The software should be able to accurately collaborate with external text-speech
and braille utilities
● Graphics can be a problem for these readers; it is recommended that labels be
used to identify all functional graphics.

Hearing disabilities
● Should not rely on sound as the sole mode of conveying information
● Utilities are available that will give some visual clue if a sound has been
produced.
● Developers should be aware that with many HOH people, English is not their first
language, sign language is. There are a variety of software utilities available to
convert speech into text or into sign language.

Physical disabilities
● Many software utilities that interface with specialized input devices for the
disabled utilise the standard keyboard interface; in effect, they send the same
 data as a standard keyboard. It is therefore vital that the user interface is able to
be controlled using just the keyboard.
● Accessibility features available: altering the time-delay before keys repeat when
held down, changing the keyboard layout, allowing keyboard combinations to be
pressed one key at a time (e.g. pressing Ctrl and then pressing S without the
need to hold down Ctrl), simulating the mouse using arrow/cursor keys, changing
the mouse pointer speed and adjusting the double-click speed.
● Specific applications are available to perform input and output functions from and
to specialised hardware devices. Many of the input devices are simple switches
of varying size and sensitivity to suit the needs of the individual user.

Privacy issues
Privacy is about protecting an individual’s personal information. Personal information is
any information that allows others to identify you. Privacy is a fundamental principle of
our society, we have the right to know who holds our personal information. Privacy is a
feeling of seclusion, where we can be safe from observation and intrusion. For this to
occur we need to feel confident that our personal information will not be collected,
disclosed or otherwise used without our knowledge or permission.
Personal information is required, quite legitimately by many organisations when carrying
out their various functions. This creates a problem, how do we ensure this information is
used only for its intended task and how do we know what these intended tasks are?
Laws are needed that require organisations to provide individuals with answers to these
questions. In this way individuals can protect their privacy. In Australia, privacy is legally
protected under the Privacy Act 1988 and its subsequent amendments. This act
contains ten National Privacy Principles, that set standards that organisations are
required to meet when dealing with personal information.
Consequences of the Privacy Act 1988 mean that information system that contain
personal information must legally be able to:
• explain why personal information is being collected and how it will be used
• provide individuals with access to their records
• correct inaccurate information
• divulge details of other organizations that may be provided with information from
the system
• describe to individuals the purpose of holding the information
• describe the information held and how it is managed

Software Piracy and Copyright

● The illegal copying and use of software

Plagiarism
Appropriation or imitation of anothers ideas + manner of expressing them and claiming it
as your own

Copyright laws
The current law is the copyright act 1968 and all of its amendments

Classification of software in terms of copyright

● Commercial
○ Must purchase a license to use software
○ (most purchased software is commercial)
● Open source
○ Developed collaboratively and is available for all to modify and redistribute
○ The only restrictions are the the author is recognised and that the modified
products must be released using the same unrestricted open source
license
● Shareware
○ You require a license
○ Basically has a test run, but once thats over you must pay
○ Modifications are not permitted
○ Distributing copies is permitted
● Public domain
 ○ Happens when the copyright holder explicitly relinquishes all rights to the
software
○ Software that is public domain muat be clearly marked
○ Just because something doesnt have a copyright symbol, does not mean
that it is public domain
○ Has no limitations

Software License agreements (terminology)

Licence: formal permission or authority to use a product
Agreement: a mutual arrangement or contract between parties; acceptance can be
made in many different ways. For example, by clicking ‘OK’ or ‘i agree’ to terms and
conditions
Term: the period of time the agreement is in force
Warranty: assurance/guarantee of some sort. Usually pertaining to the quality
Limited use: restrictions on the use of the product (e.g. copying)
Liability: an obligation or debt as a consequence of some event
Program: computer software
Reverse engineer: the process if decompiling the product
Backup copy: copy of the software made for archival purposes

Current + emerging technologies used to combat software piracy

● Noncopyable data sheet
○ Started in the 80s
○ User needed to enter codes from the data sheet to continue
● Disk copy protection
○ Many techniques
○ E.g. putting data on usually unreadable parts of the disk
● Hardware serial number
○ Some hardware components include an embedded serial number that
can’t be altered. Software was designed to examine the number and stop
if it doesn’t match
● Site license counter on a network
○ In large organisations software is often from a network server. The org
purchases a site license which allows the either a certain amount of
installations or sets a limit on simultaneous use
○ The network server contains a utility that stops the org from exceeding
their limit
● Registration code
○ Used to activate software products during the installation process
○ They can either be unique or have a certain amount of uses
 ○ The developers will sometimes have identifiable info of the buyer (e.g. ip
address) which can be used to further verify and stop people from
guessing random codes
● Encryption key
○ Encryption scrambles the data or program so that it is unreadable without
decrypting
○ There are two types of key systems: single or two key
■ Single key encryption: used the same key for encryption and
decryption, difficult to implement over networks as the key must be
sent to the user securely
■ Two key encryption:has a public key (to encrypt) and a private key
(to decrypt), anyone can access the public key as it is useless
without the other, can be used to securely send a single key
● Back-to-base authentication
○ The application contacts the software publishers server to verify the
user/computer has a valid license
○ Requires internet connection

Use of Networks
BY DEVELOPERS
● Used to communicate with other team members
● Access code libraries

BY USERS (ON NETWORK BASED SOFTWARE)

● Too many requests could make things go slower
● You should carefully consider when to send client requests to increase efficiency
(e.g. instead of sending ten requests for one piece of information, send one
request for ten pieces of information)
● Large files requests like images/videos should be limited

The software market

Marketing is often described as the 4 Ps of marketing (product, place, price, promotion).
The relative proportion of resources devoted to each of these id called the marketing
mix.
● Product - what do you sell?
○ You arent selling a product as much as an expectation
○ Exaggerating the product is unethical and will lead to dissatisfaction
 ● Place - where do you sell it?
○ Shop fronts, software retailers, e.g. computer/book stores
○ Industry-specific distributors, e.g. businesses specialising in the sale of
software to a particular industry
○ Direct sales, e.g. over the counter, direct order, direct mail
● Price - what do you sell it for?
○ Cost-plus basis: take cost of producing and add profit margin
○ Consumer-based: involves looking at what the customer wants + how
much they are willing to pay for it
● Promotion - how do you spread the word?
○ Advertisements + word of mouth
○ Should help customers make informed decisions
○ Social + ethical responsibilities about what you say and how you say it

Effect of dominant developers of software

If one player's product is dominating any market it becomes the default purchase

Application of software development

approaches
Software development approaches
Approaches in commercial systems
All use the same steps:
1. Define + understanding the problem
2. Planning + design
3. Implementation
4. Testing + Evaluation
5. Maintenance
It is the timing + frequency of these steps that changes based on the approach.

Approach is chosen based on a bunch of things:

● Size of product
● Nature of product
● Skills of dev team
● Detail of requirements
 ● Finances available

CASE tools in large system development

Computer aided software engineering (CASE) tools
● Used to assist and coordinate the activities involves in the process of software
development
● Any software tool used to help developers can be considered a CASE tool. E.g.
simple drawing tools for diagrams, text processes for documentation.

Many integrated case tools provide all or some of the following functions:
● System modelling
● Data dictionary creation
● Production of documentation
● Automatic test data generation
● Software versioning
● Production of source code

Examples: oracle designer (system designer)

Methods of installation (of new software products)

DIRECT CUT-OVER
being completely installed at the same
time. The old system is no longer
available. As a consequence, you must
be absolutely sure that the new system
is totally functional and operational. This
method involves the old system being
completely dropped and the new system
is completely installed at the same time.
This conversion method is used when it
is not feasible to continue operating two
systems together. Any data to be used in
the new system must be converted and
imported from the old system. Users must be fully trained in the operation of the new
system before the conversion takes place.
PARALLEL
The parallel method of installation (or
conversion) involves operating both
systems together for a period. This
allows any major problems with the
new system to be encountered and
corrected without the loss of data.
Parallel conversion also means users
of the system have time to familiarise
themselves fully with the operation of
the new system. In essence, the old
system remains operational as a
backup for the
new system. Once the new system is found to be meeting requirements then
the operation of the old system can cease. The parallel method involves double the
workload for users as all functions must be performed on both the old and the new
Systems. This method of installation is especially useful when the product is of a crucial
nature. That is, dire consequences would result if the new system were to fail. By
continuing the operation of the old system, the crucial nature of the data is protected.

Sometimes “parallel” means using the direct cut-over method on some sites while
others are still on the old system. This is pretty much unique to large systems.

PHASED
involves a gradual introduction of the
new system whilst the old system is
progressively discarded. This can be
achieved by introducing new parts of
the new product one at a time while the
older parts being replaced are removed.
Often phased conversion is used
because the product, as a whole, is still
under development. Completed
modules are released to customers as
they become available. Phased
conversion can also mean, for large
businesses, that the conversion process is more manageable. Parts of the
total system are introduced systematically across the business, each part replacing a
component of the old system. Over time the complete system will be converted.
PILOT
The new system is installed
for a small number of users.
These users learn, use and
evaluate the new system.
Once the new system is
deemed to be performing
satisfactorily then the system
is installed and used by all.
This method is particularly
useful for new products, as it
ensures functionality is at a
level that can perform in a
real operational setting. The
pilot method also allows a
base of users to learn the new system. These users can then assist with the training of
others once the system has been fully installed. The pilot conversion method can be
viewed as the final testing of the product. Both the developer and the customer are able
to evaluate the product in an operational environment prior to its full installation.

Trends in software development

Employment trends
● Outsourcing
○ Contracting other businesses who specialize in software development
weather than attempting it in-house
○ Often cheaper and produces higher quality products
● Contract programmers
○ Positions of short term employment
■ Software developers are often only brought on for one hob
○ Programmer changes employers frequently

Development trends
● Environment in which programmers work
○ More collaborative
○ Sometimes long distance (over the internet)
Defining and understanding the problem
Defining and understanding the problem
Defining and understanding the problem is the first stage of the software development
cycle. In many ways, this initial stage is the most important. Formally identifying the
precise problem to be solved and determining if an existing solution is viable or a new
solution is needed are vital steps that are often overlooked and perceived as trivial by
some large software developers. Studies have shown that some 30% of software
projects are abandoned well into the development cycle. The majority of these
cancelled projects are well over budget and clearly were not feasible from the outset.
Software developers must take steps to carefully define and understand the problem
before moving onto the planning and design phase.

Defining the Problem

Some questions that need to be asked to help define and identify the problem are:
• What are the client’s needs which will be met by this product?
• Compatibility issues with other existing software and hardware?
• Possible performance issues, particularly for internet and graphics (or video)
intensive systems?
• What are the boundaries of the new system?

Client needs
Often needs are expressed in non-specific, even emotive terms. For example, we need
to improve customer relations, or we want to improve our turnaround times. Analysing
needs is an important aspect of beginning to define the problem and for large systems a
professional systems analyst is used. A number of tools and techniques are available
for accomplishing the analysis.

• Surveys - Completed by all key personnel. For example, managers, IT personnel,

users and clients. Survey’s are an excellent tool for gathering information from
large numbers of people, however they often limit the detail and explanations
participants are able to provide.
• Interviews - Personal interviews will allow participants to more freely express
their needs. Detailed responses and explanations are possible, however
performing interviews is labour intensive and hence expensive.
• Time management studies - How much time is really spent on each specific
function. Actually watching and recording the time, nature and order of tasks as
they are performed will often highlight priority areas.
• Business analysis - Examining different aspects of a business’ activities in search
of areas where improvement can be made. Often such analysis will include a cost
benefit analysis to ensure a profitable return on the software investment is likely.
Many developers have great ideas for new products. This is all well and good, but is
there a need for this product? Developing a new product of any type without
establishing a need for the product is like putting the proverbial cart before the horse.
Many great inventions have remained as ideas because no market or need exists for
the product. Conversely, many fine products appear which fail economically because
they don’t meet the needs of the market place.

Functionality requirements
Functionality requirements describe what the system will do. They are what you are
aiming to achieve. Requirements are statements that if achieved, will allow needs to
be met. The requirements of a system give direction to the project. Throughout the
design and development of a system the functionality requirements should continually
be examined to ensure their fulfilment. The final evaluation of a project’s success or
failure is based on how well the original requirements have been achieved. To be able
to evaluate the degree of success or failure of requirements requires that the
requirements be stated in such a way that they can be readily verified. In terms of
software development, this often means they must be quite scientific or mathematical
statements. For example, a requirement may be: ‘The system will be able to redraw the
screen at least 12 times per second’ or ‘95% of orders will be filled within 24 hours’.
Each of these requirements can be precisely tested.

Compatibility Issues
Software of various types runs on a variety of operating systems, browsers, hardware
configurations and even a range of different devices, such as smart phones and tablet
computers. Users are able to configure their device in a variety of manners, for
example screen resolution, colour depth and font sizes.
Some examples of common compatibility issues include:
• Problems with different versions of the intended operating system, particularly as
users upgrade their operating system.
• COTS products which experience issues when the underlying application is
updated.
• Not all graphics cards are supported by many graphics code libraries.
• Screens which do not resize to support different screen resolutions.
• Labels for screen elements which overlap or are no longer aligned correctly when
fonts are enlarged.
• Loss of server connection causes fatal errors over wireless networks.
• Browsers which do not correctly implement HTML standards set by the W3C
(World Wide Web Consortium).

Performance issues
Often the specifications of the computers used by developers far exceed those likely
to be present in a typical user’s computer. In addition multi-user applications and
applications that access large files and databases will perform very differently under
real world conditions. Testing environments and actual tests should simulate real
world conditions.
Some common examples of performance issues include:
• The computer appears to be not responding after some function has been initiated.
In fact it is busy processing a time consuming task.
• Users experience poor response times. This is often seen with networked
applications where during data entry users spend most of their time waiting for the
application.

Boundaries of the Problem

Boundaries define the limits of the problem or system to be developed. Anything outside
the system is said to be a part of the environment. The system interacts with its
environment via an interface. Input and output to and from the system takes place via
an interface. The keyboard provides an interface that allows humans to input data into a
computer system. An internet service provider (ISP) provides an interface between
computers and the internet. It is vital to determine the boundaries of a problem to be
solved. Determining the boundaries is, in effect, determining what is and what is not a
part of the system. Items that are not part of the system, that is items that are in the
environment, need to be considered if they have an influence on the system. For items
in the environment to influence the system there must be an interface with the system.
Items in the environment can affect the system, however, the system cannot alter its
environment.

Issues relevant to a proposed solution

Although a new solution may well meet the current identified needs there are other
areas that should be considered prior to investing time and money in the development
of a new software product. Will a new solution provide enough advantages to the
organisation to be worth the time, effort and money involved in its development and
implementation?

Points to consider from the client’s perspective include:

• Will the existing system be able to perform the required tasks in the foreseeable
future? If so, then maybe the new system should be cancelled until a later date.
• Will the proposed new system meet future needs? If not, then maybe the
requirements need to be changed to reflect longer term needs.
• Have existing similar solutions been examined? Perhaps a suitable solution already
exists or an existing software package can be customised.
• How crucial is the new system to the total organisation? Perhaps resources would
be better utilised in other areas.
Some points to be considered by the software developer include:
• What expertise is required to complete this project? Do we already have this
expertise and if not then can we get it?
• What resources are required to develop this project? Do we have these resources
and if not can we get them?
• Will we be able to support this product in the future?
• Can we retrain/redistribute existing staff and resources to this project? How would
this affect other projects?

Social and ethical considerations

● Changing nature of work for users
○ The introduction of most new software products has an effect on the
nature of work for users of the system. We must consider the effect the
new system will have on users. Input from potential users is critical at this
stage.
○ If the product is to be implemented across large numbers of sites, perhaps
industry associations and/or unions need to be involved in the consultation
process. Employees may need to be retrained to acquire skills for their
new or changed position.
● Effects on level of employment
○ One of the main reasons for creating a new software system is to reduce a
business’ costs (wages if technology is replacing people)
○ Developers and their clients must take this into account, both in terms of
cost savings but also in terms of the effect on employees made redundant.
● Effect on public
○ Large software systems can have a substantial effect on the general
public. Example: The introduction of ATMs involved retraining the entire
population.
○ These effects can be either positive or negative, it is important to consider
them

Legal issues including licensing considerations

All parties must consider issues related to copyright, both in terms of protecting the
rights of the developer and the legal rights of the customers who will purchase and use
the product. Software that is used to store and access private and personal information
will need to include safeguards against unauthorised access.

Customisation of existing software products

Customisation of an existing software product is often a cost effective strategy for
obtaining new functionality. The ability to customise software helps the original
developer of the product widen their market. It is now common for tools to be included in
many commercial products which allow the end user to create customised screens and
other functionality through the use of wizards and various drag and drop design
screens.

Cost effectiveness
Things to consider when calculating cost: hardware, personnel, software required to
make it, outsourcing
Things to consider when making a budget: available capital, predicted sales for finished
product, cost savings as a result of the product’s implementation, predicted future
upgrade and maintenance costs for the product, ongoing customer support costs, other
costs (example, special hardware required to operate the system, training
costs for new future users)

Design Specifications
Developers’ perspective Users’ perspective

Consideration of: Consideration of:

● Data types ● Interface design
● Data structures ● Appropriate messages
● Algorithms ● Appropriate icons
● Variables ● Relevant data formats for display
● Software design approach ● Ergonomic issues
● Quality assurance ● Relevance to the user’s
● Modelling the system environment and computer
● Documentation configuration
These specifications will create a ● Social and ethical issues
standard framework under which the
team of developers must work.
Once these specifications have been
developed a system model can be
created to give an overview of the entire
 system. These system models will lead to
the allocation of specific tasks for
completion by team members, whilst at
the same time an overall direction of the
project can be visualised.

SYSTEM DOCUMENTATION
There are various modelling techniques available that can be used to describe the data
moving through systems. Each technique aims to describe the system in a logical and
understandable manner.

Flowcharts
Used to model the entire system, flowcharts have different universal symbols that
represent different elements of code (see picture). They describe the interactions that
occur between input,
processing, output and
storage, as well as the
nature of each of these
components. Generally,
flowcharts show only a
higher level of the hierarchy
and are therefore not overly
detailed. Some of the
symbols, such as the punch
card symbol, are out of date
due to how long this type of
chart has been used. Each
of the symbols are connected by an arrow to show the order of the system. A good
online tool to create flowcharts is lucidchart.

Hierarchy Chart
Top-down design is the most common
method of breaking down a problem.
The problem is progressively refined
until each module can be solved using a subroutine of code. In many cases, the design
will be strictly hierarchical; with each higher-level subroutine accessing or calling one or
more lower-level subroutines. The process of developing this hierarchy of subroutines is
known as stepwise refinement.

Structure Chart
Another version of the hierarchy chart but with more symbols,
this chart not only shows the hierarchical order of the modules
but also what should be passed between each one. Control
parameters are anything that have an effect on the order in
which tasks are executed. Repetition arrows are added around
the call lines. Reading from left to right on a particular level
describes the order of execution of tasks. The call lines do not
have arrows on them.

Context diagram
Context diagrams will generally only have one circle as they only show a very high-level
process (system rather than a module).
They are used to show all the external
inputs and the outputs of a system. Each
data item is represented as an arrow or
data flow and is labeled with the name of
the data item. External entities from
which data is obtained (source) or sent
(sink) are represented as boxes.
SHOULD ONLY HAVE ONE PROCESS

Data Flow Diagrams (DFD)

Data flow diagrams describe the path data takes through a
system. No attempt is made to indicate the timing of events.
The ‘data flow’ arrows should be labelled with the type of
data, this should be unique within the DFD. The origin of
data input into the system is known as a source, a
destination for data output from the system is known as a
sink. Both sources and sinks are external entities (AKA
terminators). Datastores are mainly databases or online
storage, however, they can refer to physical stores such as a
filing cabinet (also yes, the side of the rectangle is meant to
be missing). HAS MULTIPLE PROCESSES
IPO Diagram/Chart
IPO (Input-Process-Output) diagrams are useful tools that
describe the steps taken to turn inputs into outputs. There
are many different formats however the textbook used the
table method. Tabular IPO diagrams are commonly used
as documentation for programmers. The programmer
uses this information to develop detailed algorithms

Data dictionary
A place to document variable names or identifiers. Data
dictionary functions are available with most software
development CASE tools.
A data dictionary should include:
● Identifier name or data item
● Data type (int, string etc)
● Format; display format, where applicable. EXAMPLE: if the data is a string the
format may be: two letters followed by three numbers OR the format for the date
would be xx/xx/xxxx where x are numbers
● Number of bytes required for storage
● Size for display
● Description or purpose of variable
● Example; particularly with items that
have a specified format (example:
date, time)
● Validation: refers to the range of
allowable values. EXAMPLE: age
must be positive and less than say
130
● Scope of the variable
Every data dictionary does not need ALL of these categories

Screen Designs and Concept Prototypes

Considerations in regard to placement of items, consistency of design, order, grouping
and nature of screen elements, use of colour, graphics and fonts, and language used all
contribute to the effectiveness of a screen’s design. Concept prototypes are used to
implement screen designs so potential clients can evaluate them. Companies that
produce operating systems publish standards for screen design to ensure consistency
of design between applications. Many integrated CASE tools include areas where
preferences in regard to screen design are stored. When source code is generated, the
screens will adhere to the preferences entered into the CASE tool.
Storyboards
Storyboards for software products usually include a series of screen designs together
with a diagram illustrating the possible navigation paths between screens. This diagram
will show each screen as a rectangle with arrows leading to and from other screens. If
the screens are small and simple and the screen designs fit on a single page then the
links can be included without the need for a separate diagram. It is important to develop
a logical navigation system between screens so users do not become lost in a maze of
screens. Navigation buttons are normally included on every screen in a consistent
position to assist users. For movie production, the sequence in which screens are
encountered is always linear, as the movie needs to be watched from start to finish to
make sense. This is not the case with most software. The interactive nature of software
means that storyboards must carefully document the possible flow of data between
screens.

Quality Assurance
a set of processes that occur throughout the development and manufacturing of any
type of product. These QA processes ensure standards and requirements are met and
continue to be met such that the final products are of a high quality.

Software Quality: The extent to which desirable features are incorporated in to

software so it can reliably and efficiently continue to meet the needs of users.

Software Quality Assurance:

● Efficiency
○ should perform its functions by making the best use of the computer’s
resources.
○ assurance that good programming techniques are used such as the use of
algorithms that optimise processing time, well-structured code and
thorough testing.
○ The selection of an appropriate language for the problem and the use of
the operating system and CPU features such as multitasking, distributed
and parallel processing.
● Integrity
○ The correctness of data within the system
○ Integrity is improved when data validation is thorough and the ability to
access the system illegally or inappropriately is tightly controlled. Data
 integrity will often reduce over time as time dependant data becomes out
of date. Systems to check such data should be included, for instance
checks that phone numbers, addresses and email addresses are current.
● Reliability
○ The ability of the system to continue to perform its functions over time.
Other reliability factors that should be considered include the time taken to
recover from a failure and the ability of the system to be updated to reflect
changes in requirements or changes in the environment in which the
software operates.
● Usability
○ The ability of software to be learnt and used by users
● Accuracy
○ The software performs its functions correctly and according to its
specifications
● Maintainability
○ Maintainability is a measure of the ease with which these changes can be
made
● Testability
○ The ability to test all aspects of the software is critical to each of the other
quality assurance factors. Testing occurs at various times and levels as
software development progresses. Individual subroutines and the modules
should be thoroughly tested, the system should be tested to ensure it
performs according to requirements and finally the client performs
acceptance testing to ensure requirements have been met with a live
system.
● Re-usability
○ The ability to reuse code in other related systems

Planning And Designing Software

Solutions
Planning and Designing Software Solutions
What is an algorithm?
: a method of solution for a problem. They describe the steps needed to turn inputs into
the desired output. Algorithms are not written in a specific language and are often
created so that they can translated easily into multiple languages. Each algorithm has a
distinct start and end, and is split into the three control structures (sequence, decision
and repitition). Some common ways of representing algorithms are with pseudocode or
flowcharts.

Top-down design
The process of breaking a problem down into its modules/components. These
components are then continuously broken down until they are a small programmable
module; this is known as stepwise refinement. An algorithm is written for each
component in top down design.

STANDARD ALGORITHMS
:pre-made algorithms for common problems, often left in libraries, used to save time.
Some of the basic ones are: linear search, finding max and min values, binary search,
insertion sort, selections sort, bubble sort, processing strings (exctracting, inserting and
deleting), generating a set of unique random numbers, processing of sequential and
relative files.

Linear Search
Examining items one at a time, from the start of a list til the end of a list. Linear search
does not require data to be in a particular order. If, for instance, you needed to find how
many times an item appears in a list, it will always have the same processing time, as it
needs to go through the same amount of items, no matter how many instances there
are.

Finding max and min values

Finding maximum and minimum values in an unsorted list of items is essentially
performed using a linear search where a record is maintained of the largest or smallest
value as the list is traversed. For sorted lists, finding maximum and minimum values
is trivial: they will be either the last or the first values in the list.

Binary search
Involves splitting the list in two parts and disregarding the irrelevant part. It has a
gradually more specific instruction and will eventually bring the result down to one. The
list of data items must be sorted. The middle item in the list is compared to the required
item. If the required item lies in the first half of the list then the second half is discarded.
If the required item lies in the second half of the list then the first half is discarded. 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.
Insertion sort
Used to arrange items in order; particularly useful when a small number of items need
to be added to an existing list. Involve looking through a sorted list one by one for the
correct position for a new item and inserting the item into that position.

Selection sort
Selection sorts essentially are a repetition of a linear search to find the smallest (or
largest) item in a list. Each time the search is complete, the item found is moved to the
end of the sorted list. This type of sort is rather more intuitive for humans as it is a
strategy often employed when sorting things by hand.

Bubble sort
Bubble sorts, just like the insertion and selection sorts, are used to arrange data into
either numerical or alphabetical order. Data items tend to bubble, or float to the end of
the list when a bubble sort is undertaken. The list is sorted by considering the order of
individual item pairs and swapping them if they are out of order. This results in items
moving one position at a time towards their final position.

Processing strings
Some useful routines for processing strings include ones for extracting,
deleting or inserting strings out of or into other strings. Most programming languages
include functions for performing these activities. In this section, we examine the
algorithms behind these standard string manipulation functions.

Concatenation
: Joining two (or more) strings together
Most programming languages use either an ampersand (&) or an addition sign (+) as
the symbol for concatenation. In this text we will use the addition sign to indicate
concatenation. For example, “The” + “Cat” would result in the string “TheCat”. If the
string variable Word contains “Dogs” and the variable Phrase contains the string “chase
balls”, then Word + “ ” + Phrase results in the concatenated string “Dogs chase balls”.

Extracting
Essentially making a copy of a certain section of a string. The original string stays intact;
extracting a letter from a string will not remove it from its word in the original. Three
pieces of information are required to achieve the extraction: the original or initial string;
the starting point for the extraction; and either the length of the extraction string or the
finish point of the extraction string.
Deleting
Essentially cutting a portion from the string. The original string is reduced in length by
the number of characters that have been removed. (no copy is made). Deleting requires
the same parameters as extracting; the original or initial string; the starting point for the
deletion; and either the length of the string to be deleted or the finish point of the string
to be deleted.

Inserting
Inserting a string of characters into another string of characters involves splitting the
initial string into two parts and then concatenating the first part of the string with the
insertion string and the final part of the initial string. Parameters required to complete
this process are the start position for the insertion, the insertion string, and the main or
initial string.

Random Numbers
Generating random numbers
Most high level languages include the ability to generate random numbers. Many
include a class called Random which is able to generate random integers and also
random floating point numbers. The syntax of these functions or methods will vary
depending on the language. In most cases the numbers generated are pseudo-random
numbers, which are generated using an initial seed into a mathematical formula.
Although these pseudo-random numbers are suitable for most purposes they should
not be used for cryptographic or gambling applications where true randomness is
required. For such applications random numbers created by sampling some real world
analog value are commonly used.

Generating a set of random numbers

There are many different ways to go about this task. Using too many loops (especially
nested loops) can decrease efficiency drastically. You should consider having an array
of all the possible values to draw from, rather than using a loop and predetermined
function.

Data Structures and Files

Multidimensional Arrays
Multi-dimensional arrays are of one data type (same as single-dimensional arrays).
Rather than one dimension or index, multi-dimensional arrays can have a number of
indexes. Often the dimensions or indexes for an array are called subscripts, because of
their similarity to subscripts commonly used in mathematics. The dimensions of an array
are usually given a name that describes their purpose.

An array of Records
A record is a data structure that contains a number of fields; each field can have a
different data type. For example, a record could store Name, Address and Date of Birth
details. Once a record is declared, it becomes a data type in the same way as any other
predefined, simple data type. This data type can then be put into an array; same as an
integer or string.

Files
A file, in terms of software development, means a collection of data that is stored in a
logical manner. Normally, files are stored on secondary storage devices, usually a
hard disk that is separate from the application program itself.
Sequential Files
Sequential files store data in a continuous stream. This data must be accessed from
beginning to end (e.g. if you want to look at file #3, you must first flick through files #1
and #2)
Sentinel value: A dummy value used to indicate the end of data within a file.
used to indicate logical breaks in the data and also to indicate the end of the file.
For example, tab characters may be used between fields and carriage return characters
between records. Often a particular string, such as “ZZZ”, may be used as a sentinel to
indicate the end of a sequential file. When a sentinel value is used to signal the end of a
file care is required to ensure the sentinel value is not processed as if it were data.
When reading sequential files it is common to use an initial or priming read before the
main processing loop to detect files that only contain the sentinel.

Sequential files can be opened in one of three modes – input, output and append. Input
is used to read the data within the file, output is used to write data to a new file and
append is used to write data commencing at the end of an existing file. Notice it is
generally not possible to commence writing from the middle of an existing sequential
file. This is because the length of data items within the file is unknown and hence
there is no way to ensure required data is not overwritten.

Relative (or random access) files

Random access refers to the ability to access the files in any order (unlike sequential).
Relative refers to the fact that there is a known structure to these files which allows
the start of individual records to be determined. As each record within the file is
exactly the same length then the relative position of each record within the file can be
used to access individual records.
Relative files are used to store records. Each record is the same data type and must be
of precisely the same length. Complete records are read and written to relative files.
The programming language is able to able to determine the precise byte where a
record begins because all records are the identical length. Individual fields within
records can be identified precisely because the exact length and structure of each
record is known. Fields containing strings that are of differing lengths are usually
padded out using the blank character.

Interface design in software solutions

The design of the screens for a software project will be influenced by the nature of the
problem. Interactive software products will require more user-friendly screens than
those requiring minimal user interaction. For example, most data oriented projects
will include data entry screens that will be used for many hours by individual users.
The layout and selection of screen elements will have a large effect on the
productivity of data entry personnel.

Software projects where the final product operates in the background may only require
a simple configuration screen. For example: printer drivers, encryption products, virus
scanners and many system utilities. These product’s screens will only occasionally be
used and hence they are of lower importance to the overall product.

If an event-driven approach has been selected for implementation then the screen
designs are more likely to be crucial to the operation of the final product. An event-
driven program will normally require user input to determine the order of processing.

In a sequential program the order of processing has been determined by the developer,
hence less selection possibilities are available to the user and screens will be more
specific to the processing currently occurring. It is important that the user feels in
control of the software rather than feeling controlled by the software.

Identification of data required

Before the task of designing a user interface can commence the data to be included on
each screen needs to be determined. The system models, algorithms and data
dictionaries will provide this information. Once the required data is ascertained the
next task is to decide on the most effective screen element to use to display each data
item.
Screen elements:
● Menus
● Buttons
● Tool bars
● Text boxes
● List boxes
● Drop down lists
● Check boxes
● Option or radio buttons (like checkboxes but you can only choose one option)
● Scroll bars
● grids/tables
● Labels
● pictures/images
Current popular approaches
The textbook doesn't have much actual information on this but it should be taken into
account

Design of help screens

Help screens are used to assist the user with the operation of the final software
product. Ideally, your user interface should be designed in such a way that users can
quickly and intuitively learn to use the product. Inevitably however, users will need
some assistance in this task.

There are a number of different methods of providing help to users using screens:
● Context sensitive help
○ If the user asks for help, then a new window can be displayed (it should
not take up the entire screen, and the original program should stay open)
○ Small windows can pop up with simple tips when the users mouse is
hovered over an element. As the user has not asked for this help, the
window should go away as soon as the user pays attention to something
else.
● Procedural help
○ Procedural help should provide concise and accurate instructions on how
to complete a specific task.
● Conceptual help
○ Conceptual help aims to explain information about ‘what’ and ‘why’ rather
than ‘how’. The concepts behind a task should be explained.
● Tours, tutorials and wizards
○ Tours are used to give new users of the product an overview of the
product’s purpose and basic features
○ Tutorials aim to provide instruction to users on how to complete specific
tasks
○ Wizards are used to automate complex tasks.
■ The user completes a series of dialogues that gather together the
required inputs needed to complete the task.
■ The wizard then completes the task for the user

Audience identification
The user interface needs to be designed with the desired audience in mind. Systems
intended for large audiences with unknown levels of expertise may include user
interfaces that can be personalised.

Consistency in approach
Consistent user interfaces allow users to transfer skills that they have previously learnt
(and increases learnability). If the user feels that the software is familiar and predictable,
they will be able to focus on tasks easier.

Some aspects of interface design where consistency is required include:

● Names of commands (cut, copy, paste)
● Use of standard icons (floppy disk)
● Placement of screen elements (save command in the file menu)
● Feedback; users will expect a response after they have initiated an action
● Forgiveness; Warnings about potential dangerous operations and methods of
recovery need to be consistent. Users like to explore an interface to learn by trial
and error. The interface should allow for this by permitting users to cancel
operations before damage results.

Customisation Of Existing Software Solutions

Many custom off-the-shelf (COTS) packages allow customisation using a
programming language included as part of the COTS package. These languages
allow developers to include features not included in the original package.

Selection of language to be used

● Is the programming logic driven by the user or by the programmer?
○ this question will determine whether the language selected should use an
event-driven approach or a sequential approach.
○ Many problems involve a combination of approaches.
● Does the language provide for all the required features of the solution?
○ Careful consideration of features required to implement a solution, and an
intelligent selection of an appropriate language, will result in reduced
development times and more efficient final products
● What hardware and operating system ramifications are there?
○ Most COTS packages are designed to operate under a specific operating
system.
○ If a language is used that does not support the system settings provided in
modern operating systems, then drivers for different peripheral devices
may need to be written
 ● Is a graphical user interface (GUI) required?
○ If you have one when you don’t need it, it can decrease efficiency
● What is the experience of the developers?
○ Before deciding on a language for implementation, the experience and
expertise available within the software development team need to be
examined.

Factors To Be Considered When Selecting The

Technology To Be Used
● Performance requirements
○ Not only how fast the hardware is, but also how well they hold up under
pressure, how easily they break, if they can handle power surges, etc…
● Benchmarking
○ The process of evaluating something by comparison to a standard;
enables competing products to be fairly compared.

The Interrelationship Between Software

And Hardware
The binary number system
LOGIC GATES

Type of gate Describe images

AND Both inputs must be turned on in

order for the output to be turned on.
The equivalent of a series circuit.
AND gates use a rectangle with a
rounded right-hand side. For most
purposes, two inputs are sufficient,
however, it is possible to design
AND circuits using any number of
inputs; 2, 3 or 4 inputs are common.

OR Only one of the inputs must be on

in order for the output to be on. The
equivalent of a parallel circuit.
NOT The not gate is used to reverse the
input; if the input is off then the
output is on and vice versa. It is
only possible to have one input into
a NOT gate.

The symbol for a NOT gate is a

small hollow circle. The triangle
preceding the circle is really a
buffer. Buffers are used to
synchronise timing, often your
circuit will need to wait for the next
input. Buffers can be used to
accomplish this task. NOT gates
require buffers to ensure correct
timing.

NAND Logically the same as an AND gate

(NOT AND) followed by a NOT gate. The output
from a two-input NAND gate is the
opposite of that from an AND gate.
In logic terms, the output from a
NAND gate is true if all inputs are
not true.
 NOR OR gate followed by a NOT
(NOT OR) gate.

XOR Exactly one input must be on in

(exclusive order for the output to be on
OR)

Boolean Algebra
In Boolean algebra notation, variables can hold values of 0 (false) or 1 (true). There are
three operations NOT, OR and AND. NOT A is denoted as Ā, A OR B is denoted A+B
and A AND B is denoted A⋅B or just AB. A further notation has been added for XOR, A
XOR B is denoted A⊕ B .
Conversion Between Truth Tables, Boolean
Expression And Circuit Diagrams
sop/pos

Specialty Circuits

Binary The sum part of the truth table is

Half-Adders identical to a XOR table, the carry
part of the truth table is identical to an
AND truth table.

A half-adder only works when adding

two bits together. It can’t add more
than two bits because there is no
functionality where the carry column
actually carries.

Binary The combinations of two half-adders

Adders to add a carry-on function and create
a full adder. Binary adders can be
turned into chains to add multiple
(>2) bit numbers
Flip-Flops FF are bistable circuits used to store
binary digits. (Bistable: A stable
device is able to hold or maintain a
particular state. A bistable device can
maintain two possible states.)
Flip-flops are the basis of most
temporary memory within computers;
this includes registers within the CPU
and some types of RAM chips.

There are many different types of flip

flops. (different inputs, some have a
clear function)

A Flip flop has three different

components (next rows of table)
Latch (SR) circuit that is able to store a binary
digit.
For a particular state, to be
maintained within a circuit requires
feedback. Feedback is provided by
connecting the outputs of two logic
gates to each other inputs.

A simple latch could be created with

two NOT gates, but that circuit
provides unpredictable results when
the input is changed. As a result, two
NAND or NOR gates are generally
used. The traditional inputs to these
gates are R, S (reset, set) and as a
result, the gates are called RS-NOR
and RS-NAND.

Clocking When a number of latches are

connected together, it is vital that we
can force all latches to change (or not
change) at the same time. By
connecting a clock to our circuit, we
can achieve this aim. Essentially, a
clock is an extra input that changes
state from 0 to 1 then back to 0 when
we wish to make changes to the
attached latches.

Two problems remain, what happens

if the S or R inputs are both 1 when
the clock (CLK) is 1. Also it is
possible for S and R to change
multiple times whilst CLK is 1.
 Latch Removes the possibility of the illegal
(D/Data) input of 11. This also means that the
input at D and the output at Q are not
inverted.

Edge Combines two latches that are on at

Trigger opposite times. The input will be
entered into the master latch, and
only after the input/clock has been
turned off will the state be allowed to
move through the slave latch and
consequently to the output (Q).

Shift register
A row of flip flops used to store data. In most the flipflops are connected to each other
and to the same clock. This means that each time the clock is activated all of the states
get transferred to the flipflop on their right and the lost-most one gets a new input, the
right-most value gets lost. Shifting a binary digit to the right by one will divide its value
by two, making them useful for calculations. There are also bi-directional flip flops -
meaning that you can shift the data left or right, adding a multiplication (by 2) function.
Programming Of Hardware Devices
Input and output data streams from and to sensor and other devices
Computer systems require input from outside sources. This input may be acquired
from traditional input devices (keyboard, mouse) or from external sensors that can react
to changes in the environment such as light or temperature. Similarly, output from the
computer system requires conversion into forms that are understandable by the output
device.

Data Packets
Data to and from devices is sent in packets. Each packet has three distinctive parts:
Header: information preceding the data. For communication with hardware devices
within the computer system or connected directly to one of its ports, the header is often
just a single start bit. This bit signals to the receiving device that a new data packet is
commencing.

Data Characters: The actual data being sent. This is the stream of data that is used by
the receiving device. Often control characters are included within this data stream. For
example, a modem requires control sequences to activate its internal functions, such as
instructions to go off-hook or dial a number.

Trailer: information following the data. Trailer information includes error checking bits
and stop bits. There are various error checking techniques that can be used, often a
simple parity bit is used. A stop bit is often used to indicate the end of the data packet.

Processing of the data stream

Once a data stream has been received it will require processing by the computer. The
software must be able to understand the precise format of the data stream. Control
characters will need to be isolated and acted upon and strings of data will need to be
interpreted into forms that can be used by the system. The processing required is
dependant on the particular hardware device.

Control systems
made up of sensors that obtain data from the environment and actuators that are able to
perform output functions under the direction of a controller (computer).
Open Loop: do not react to changes in the environment
Closed Loop: react to changes in the environment
Implementation of Software Solutions
Railroad Diagrams (syntax structure diagrams)
Graphical diagrams used to represent code from
any language. It does not show any instance of the
code running, but all the possibilities of what the
code could do. Railroad diagrams have three main
elements (fig 5.2 - image): pre-defined/non-terminal
elements, fixed/terminal elements, and the
pathways that connect them.
Non-terminal: represents a method/subroutine, the
code that it represents is drawn separately from the
rest of the diagram. Defined by a box shape.
Terminal: To be taken literally. Whatever is inside it
is to be taken as a character or string. Defined by a
circle OR rounded rectangle shape.
Pathways: pathways connect all of the other elements. They run from left to right
always. The pathways are used to define selection structures by diverting off the main
path to another element, before joining back to the main path. A pathway can only have
one start and one end, no matter how many ways you can get through the middle (how
many options you have)

EBNF (Extended Backus-Naur Form)

The text version of the railroad diagrams. Uses different types of brackets to mean
different things.
< > = pre-defined/non-terminal element
( ) = used to group things together
[ ] = optional element
{ } = element can be repeated 0 or more times
If an element NEEDS to be run at least once, write it like this: THING{THING}
| = or/selection
::= = used to represent the statement “is defined as”
Translation Methods In Software Solutions

Pros Cons

Compiling “The source ● Program runs faster ● The initial compiling

code is translated into ● Level of protection is slow
executable code. The from people stealing ● Must have a
executable code can later and adapting code different executable
be executed without any as it is saved as an file for each type of
need for the translator.” executable CPU
(machine code)

Interpreting “Each line of ● As the source code ● Program runs slowly

source code is converted is interpreted by ● Easy for people to
to machine code and each different CPU steal and adapt
immediately executed. If you only have to ● must have a copy of
errors exist in the source have one file the interpreter
code, they will stop the (“Source code is installed on their
execution once said to be machine machines for
encountered by the independent.”) execution to take
interpreter.“ place.

Lexical analysis
Making sure that everything is a valid part of a
programming language. In terms of source code
translation, lexical analysis is a process that ensures
all reserved words, identifiers, constants and
operators are legitimate members of the high-level
language’s lexicon. At this stage the translator
doesnt care if the elements are in the right order, just
that they are valid elements.

How is this achieved? A table of symbols or tokens

is used. This table will initially contain all the
reserved words and operators that are included
elements of the language. As the lexical analysis
continues, identifiers and constants will be added to
the symbol or token table. This table essentially
becomes a dictionary or lexicon for the lexical analysis process. Each character in the
source code is read sequentially. Once a string of characters, called a lexeme, matches
an element in the symbol table, it is replaced by the appropriate token. This process
continues until the entire source code has been tokenised. (Comments and white space
are ignored during lexical analysis).

Synatical analysis
is the process of checking the syntax of sentences and phrases is correct in terms of
the grammatical rules of the language. (example: checking that you have a semi-colon
at the end of each line).

Parsing is the process of checking the syntax of a sentence. A parse tree is used to
diagrammatically describe the component parts of a syntactically correct sentence.

Code Generation
This stage involves converting each token or series of tokens into their respective
machine code instructions. Because we know that the tokens are correct and are in the
correct order, no errors will be found during code generation.

The Role Of Machine Code In The Execution Of A

Program
An interrupt is a communication channel into and out of the CPU.

How is machine code executed by the CPU?

As previously described, the CPU contains permanent instructions that describe how
each machine language instruction is to be executed. These instructions are known as
microcode or firmware. Each machine language instruction activates a microcode
procedure requiring the execution of one or more microcode instructions. Each
microcode instruction is executed using the fetch-execute cycle and the integrated
circuits within the CPU.
Techniques Used In Developing Well-Written Code

Error detections/correction techniques

● Desk checking
Desk checking is the process of working through an algorithm or piece of source code
by hand. A table with a column for each variable is used. As the algorithm or code is
worked through by hand, changes to variables are made by writing the new value
under the appropriate identifier.
● Flags
used to indicate that a certain condition has been met. Usually a bool variable. flags are
used to check if certain sections of code have been executed or certain conditions have
been met.
● Stubs
a small subroutine used in place of a yet to be coded subroutine.Stubs are used to set
the value of any variables affecting their calling routines and then end. Sometimes a
stub may include an output statement to inform the programmer that the call to the stub
has been successful.
● Peer checking
● Drivers
A subroutine written to test the operation of one or more other subroutines. Commonly,
drivers set the value of any required variables, call the subroutine to be tested and
output the results of the subroutine call.
● Debugging output statements
By placing output statements within called subroutines, the programmer can
determine which subroutines have been called. This assists in the detection of the
source of an error. Often output statements will be used to display the contents of
variables at crucial stages during execution. This allows the programmer to monitor
changes in the contents of variables whilst the code executes.
● Structured walkthrough
The developers walk the group step-by-step through each aspect of
the program. As the walk through continues, comments are written down for future
consideration. No attempt is made to correct or justify aspects of the product; the aim
being to receive feedback on the product as it stands.
● Use of expected output
When initial test data items are created the expected output from these inputs should
be calculated by hand. Once the subroutine has been coded, the test data is entered
and the output from the subroutine is compared to the expected outputs.

Software debugging tools

 ● Breakpoints
temporarily halt the execution of the code. Break statement in the code or the little red
dot on the side
● Resetting variable contents
The ability to alter a variable’s contents can also allow the programmer to determine
which values are causing errors without the need for the variable to actually attain that
value as a consequence of execution.
● Program trace
refers to tracking some aspect of the software. A program trace enables the order of
execution of statements to be tracked or the changing contents of variables to be
tracked. Both these types of trace involve analysing and following the flow of execution.
Some programming environments can display each line of code as it is executed at
slow speed. Others allow you to analyse the call stack when a breakpoint is
encountered. The call stack is a list of subroutine names from the current call back to
the main program. Many COTS products, particularly data oriented products, are able to
produce a trace file. Many development environments provide a window containing all
the variables local to the current subroutine together with their current value and data
type.
● Single line stepping (step into)
the process of halting execution after each statement is executed.
● Watch expressions
A watch expression is an expression whose value is updated in the watch window as
execution continues.

The Use Of Good Programming Practices

Use of a clear modular structure

● In general, the mainline (main program) should be clear and uncluttered so it is
easy to follow and identify calls to subroutines. Each subroutine in a
well-structured program can be coded independently. The subroutine can be
tested and any errors encountered corrected. The subroutine is only included in
the project once it has been rigorously tested on its own. Once included in the
project the subroutine is tested in conjunction with routines above and below it in
the top-down design.
One logical task per subroutine
● Code for each subroutine should fit on a page
● The task should be described in the title
Quality of solution
 ● A quality solution is a solution that is superior in performance, design and
maintainability to other solutions.
Appropriate use of data structures and control structures
● Care is required when designing and coding repetition structures. Programmers
should consider unusual cases such as reading an empty file, processing (or not
processing) sentinel values and reacting to unexpected inputs so that infinite
loops or other errors do not occur.
Writing for subsequent maintenance
● Coding should be done in such a way that future maintenance programmers can
easily update the code as new requirements come to light. All the points
mentioned above will help to simplify the tasks of maintenance programmers.
Version control and regular back ups
● Regularly save your work
● Prevents the loss of source code but also allows for different version of the
program (or more commonly, subroutine) to be saved at once
● Version control systems (VCS) are routinely used by teams of programmers. A
VCS performs all of the above plus it allows multiple developers to work on the
same project. Commonly a central repository contains all the files and individual
developers must check out the file they wish to modify. The system maintains a
record of every change made by every developer so that it is possible to track all
changes and also to revert to previous versions of any file as they appeared at
any point in time.
Recognition of relevant social and ethical issues
● When using code written by others it is important to respect their intellectual
property rights including but not limited to their legal rights.
● Thorough testing to ensure software performs correctly and as expected.
● Documentation for future maintainers of the software. Many successful
applications remain in use for decades. It is important that the source code can
continue to be understood.

ERRORS OCCURING IN SOFTWARE SOLUTIONS

Syntax error - any errors that prevent the

translator converting the high-level
code into object code.
- Any error resulting from incorrect
use of the high-level language is
called a syntax error.
 result from both the lexical analysis stage
and the syntactical analysis stage of
translation.

Logic error - Logic errors are the result of

syntactically correct code that does
not complete the required task.
- i.e. the logic in your code is wrong

Runtime error - errors detected by the computer

whilst a program is executing.
can be linked to either hardware or
software problems. EXAMPLES: BIOS,
OS, hardware drivers, application
software (arithmatic overflow and divide
by zero, accessing inappropriate memory
locations, recursive calls) can all cause
runtime errors

Documentation Of A Software Solution

User Documentation

Documentation targeted at users needs to be directed at their level of knowledge and

expertise.

Installation Guide
should provide the user with sufficient information to successfully install the software
product on their machine(s). Hardware and software requirements will be included
together with step-by-step instructions to guide the user through the set-up process.
Often notes are included to help resolve common installation problems.
Should include:
● Hardware requirements
● steps that need to be undertaken to install the product
● Address common installation issues
● Contact information for any additional problems

User Manual
provide concise and accurate information in regard to the operation and purpose of
software. The information needs to be presented using a format that is appealing,
accessible and consistent. Often much of the information traditionally contained in a
user manual will be included in help files that are accessible directly from within the
application. Each topic should have a conceptual and procedural explanation.
Conceptual explanations explain what the function is and why the user may need to use
that function. Procedural explanations describe how a process is performed using the
software.

Reference Manual
a reference manual should succinctly describe each command within the application.
Reference manuals are not designed to be read from start to finish, rather they will be
read in random order as needs arise. Each command within the application
should be listed in alphabetical order. This assists the user in locating required
information without the need to refer to the contents or index pages. Normally each
command is listed together with a brief description and a succinct example to illustrate
its usage.

Tutorials
Tutorials provide instruction in the use of software products using example scenarios.
The user is lead step-by-step through the processes included in the product. The user
performs the tasks under the direction of the tutorial. Tutorials are designed so users
can experience real world use of the application before using their own data.

Online Help
Each of the above types of user documentation can be in either printed or electronic
online form. It is now common for most user documentation to be provided online
rather than as printed manuals. Online documentation can be provided as Adobe PDF
files which are often similar in structure to more traditional printed manuals; however
dedicated hypertext documents are now more common. Hypertext help documents
allow users to efficiently search for specific items or in many cases they allow context
sensitive help to be provided from within the application. When the user selects help
within the application they are directed to the most relevant help topic automatically.
Online help can be truly online, meaning it is stored on a remote web server and hence
requires an internet connection or it can be stored on locally on the user’s machine.
Currently many software applications only provide truly online internet based help.
This has the advantage that the software company can update the help files as required
and all users will immediately have access to the new content. In addition, interactive
help such as user support forums and the ability to ask questions or suggest new
functionality are valuable additions to an applications support options.
Technical Documentation
Technical documentation is designed for an audience who are proficient and
knowledgeable in regard to the subject matter. In terms of software products,
technical documentation primarily describes the structure and engineering behind a
product.

Logbooks
records the systematic series of actions that have occurred during the development of a
project.The purpose of maintaining log books is twofold. Firstly, the information can be
used to determine the relative cost of each stage of development. More importantly, log
books are used as reflective devices. By examining the log books mistakes, delays or
inefficiencies during development can be analysed. Future projects can then be more
effectively managed to ensure such issues do not continue to arise.

Source code documentation

● Comments
● Intrinsic documentation
○ Meaningful identifiers
○ Use of indentation

Other
charts/diagrams, etc.
These should all be updating and evolving as the project progresses
Hardware Environment To Enable Implementation Of
The Software Solution
Minimum Hardware Configuration
The checklist, shown in Fig 5.44, lists hardware
items that need to be considered by the
software developer for all solutions. The
minimum configuration should allow the
software to operate successfully with
acceptable performance and response times.

Possible Additional Hardware

Additional hardware items are those items
supported by the software product but not
essential for its operation. Extra RAM may allow
the product to operate with larger files. Sound
cards may allow for optional audio feedback for the sight impaired. The addition of a
network or internet connection may allow for foreign exchange rates to be updated
electronically in financial packages.

Appropriate drivers or extensions

Custom built hardware may require a purpose built driver to be created. This driver
would need to be installed as part of the installation of the software solution. In this
case, the driver is an extension to the software package.

Emerging technologies
● Quantum computers
● Human-computer interaction
● Internet access initiatives

Testing and Evaluation

Personnel within the software development process perform alpha testing with real
data. Beta testing occurs when the product is distributed for use to a limited number of
outside users. These users are engaged to report any faults or recommendations back
to the software development company.
Comparison Of The Solution With The Design
Specifications
How Do We Test The Design Specifications?

Black Box Testing (AKA functional testing)

● The inputs and expected outputs are known the processes occurring are
Unknown.
AKA they input the data into a function and test the practical outputs
against the expected outputs
● Doesnt really do anything to fix the problem, it more geared towards finding if
there is a problem (on the system level)

White Box Testing (AKA structural, or open box testing)

● You would move on to white box testing after bbt has identified an issue
● Involves examining the code for errors

Levels of Testing

System-Level Testing
● Aims to ensure that the five aspects of a system (software, hardware, personel,
data, procedures) all work together correctly
● To achieve this aim requires the use of real test environments utilising live test
data
○ CREATING SUITABLE TEST ENVIRONMENTS
○ Hardware:
■ The software product should be installed and tested on different
combinations ofhardware ranging from those specified as the
minimum requirements
○ Software
■ Other software installed on the system will have an effect on the
operation of new software products. This is particularly the case
when COTS products have been used. Different versions of the
base product can cause incompatibilities with the new product.
Similar problems can occur with different versions of the intended
operating system. It is important to test the new product with
various combinations of software installed.
■ Often data is passed between applications and across networks.
The only way to confidently test the interfaces between these
applications is using live test data. Internet and web based
 applications require special attention as they often need to operate
across a broad range of operating systems, variable network
speeds and many different web browsers.
○ Data
■ The data input into the system is the most likely source of errors.
■ The product needs to be tested with a large combination and
quantity of live test data to ensure its reliability under live
conditions.
○ Personnel and Procedures
■ Beta testing must be utilised to ensure that the program
(particularly the gui) is usable
■ Beta testing can be used to analyse the ability of personnel to
efficiently implement any new procedures and to modify old
procedures.

Use of Live Test Data For System Testing

When a system is finally installed and implemented within the total system it is said to
be ‘live’. Once a product goes live it needs to undergo a series of tests to ensure its
robustness under real conditions. This testing occurs using live test data.

Live test data is produced to simulate extreme conditions that could conceivably
occur. The use of live test data aims to ensure the software product will achieve its
requirements under these extreme conditions. Different sets of live test data are used
to test particular scenarios.

For most products live test data should be created to test each of the following
conditions:

Large File Sizes

● Large files highlight problem with data access and processing
● During alpha and beta testing large files should be used to test performance
(particularly speed) under stressed conditions
● Speed is particularly a problem when the data is being accessed via a network
● Large data files highlight aspects of the code that are inefficient or require
extensive processing. Many large systems will postpone intensive processing
activities until times when system resources are available. For example, updating
of bank account transactions takes place during the night when processing
resources are available.
Mix of Transaction Types
● Module and program testing usually involve testing specific transactions or
processes one at a time. During system testing we need to test that transactions
occurring in random order do not create problems.
● The results of one process will often affect other processes. If a transaction is
currently being completed on specific data and that data is altered by another
transaction then problems can occur. When a number of applications are used to
access the same database then conflicts are inevitable. Software must include
mechanisms to deal with such eventualities.

Response Times
● Any processes that are likely to take more than one second should give feedback
to the user (such as a progress bar)
● Data entry forms that need to validate data before continuing should be able to
do so in less than one second; 0.1 second is preferable.
● Studies show that users can only tolerate delays of up to a second and their
concentration will deteriorate is the delays are frequent
● Response times should ideally be 0.1 seconds to stimulate an instant response
● Response times should be tested on minimum hardware using typical data of
different types. Any applications that affect and/or interface with the new product
should be operating under normal or heavy loads when the testing takes place.

Volume 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 large numbers of users entering and
processing data simultaneously.
● Large systems that require extensive data input require special consideration.

Interfaces Between Modules and Programs

● In many large systems the interface between programs will include a
communication link, this being an integral part of the interface. Tests should
examine the accuracy of data being passed as well as response times and the
ability of the interface to cope with large files, different transaction types and
large volumes of data.

Comparison Of Actual With Expected Results

● During previous stages of the software development cycle, test data together
with expected outputs were created. This test data should be entered into the
finished product to ensure the actual outputs match the expected outputs.
 Because the correctoutputs are already known, this testing process ensures the
final product is able to perform its processing correctly. (black box testing)

Benchmarking
The process of benchmarking aims to compare the performance of a product with
recognised standards through a series of tests.

These results allow users of software products to make informed purchasing decisions.
They also provide software developers with objective data, which can be used to
compare their products with those of their competitors.

Successfully completing benchmark tests requires copies of competitors’ products.

Both products are subjected to a series of tests using identical hardware configurations
and test data sets. The results are used to evaluate the performance of the product
compared to its competitors.

Benchmarking should be done by an outside reputable source to remove bias/ensure

fairness:
Companies specialising in benchmarking are emerging. These companies
provide benchmarking software that can be utilised to test specific aspects of computer
systems. Industry associations, as a result of their unbiased nature, often create and
distribute benchmarking products. Most of these products test the performance of
specific hardware functions when subjected to particular software commands: for
example, graphics rendering, file input and output, or floating-point calculations.
Results from these benchmarking tests can be used to optimise software products for
particular system configurations.

Quality Assurance
The quality of a software product is measured against how well the product meets or
exceeds users’ expectations.

• Correctness: Does it do what it is supposed to do?

• Reliability: Does it do it all of the time?
• Efficiency: Does it do it the best way possible?
• Integrity: Is it secure?
• Useability: Is it designed for the end user?
• Maintainability: Can it be understood?
• Flexibility: Can it be modified?
• Testability: Can it be tested?
• Portability: Will it work with other hardware?
• Re-useability: Can parts of it be used in another project?
• Interoperability: Will it work with other software?

National and international standards exist for quality assurance. The International
Standards Organisation (ISO) develops standards for quality assurance. Companies
and products can adopt these standards. Organisations throughout the world provide
certification services to businesses wishing to participate. In Australia, Quality
Assurance Services (QAS) is one of the largest suppliers of such services. QAS
provides initial certification services, product testing, and certification, together with
auditing and education services. Products and companies are able to use standards
logos on their advertising and product packaging.

Maintaining Software Solutions

Maintenance is an ongoing process of correction and refinement. Many software
products have a life span of some ten to fifteen years. These products will require
maintenance for them to continue to meet the expectations of their users. Maintenance
includes the correction of errors (bugs) in the source code together with upgrades to
enhance the functionality of the product to meet new or changing requirements.

Patch: Used to correct a problem in a software solution. A patch is an actual piece of

executable code that is inserted into (patched into) an existing executable program.

Modification Of Code To Meet Changed

Requirements
Changes made to subsequent releases of applications are often the result of user
requests.
Identification Of The Reasons For Change In Source Code
Reasons for change common to all applications include: bug fixes, new hardware and
new software purchases. Major upgrades of operating systems will have a flow-on effect
to other applications. Upgrading of applications to take advantage of features available
in new operating systems is required.

A software company whose products have a large customer base may receive many
thousands of requests for modification of their products. The company must then
prioritise these requests. Often registered users are surveyed to obtain their views on
possible modifications. Support departments provide a valuable source of data: the
number of support issues about specific functions highlights useability problems.

As customised software is an expensive purchase, maintaining the product is normally

preferable to changing products, or developing a new product from the ground up.

Software based on COTS products is particularly susceptible to upgrades in the

base COTS product. Macro and script commands may change, resulting in
unexpected results. Often applications will need to be recompiled using the new
version of the COTS product. The Internet has automated the upgrading of many
commonly used applications.

Location of Section to be Altered

Models of the system are used to assist in this process. Structure charts and data flow
diagrams will assist in the location of the module or modules requiring modification.

Determining changes to be made

Depending on the nature of the modifications, changes may need to be made to the
data structure, files, user interface or source code.

The consequences of changes made to one module must be considered. If a record

data structure is altered then what effect will this have on other modules that access
this data? We don’t want to solve one problem only to cause a number of new ones.
Analysis of the original documentation should alert programmers to the possible
consequences of changes.

Testing and implementing the changes

Testing of modifications should be performed using the same techniques employed
for the development of new products. Often CASE tool scripts and test data used
during the original testing can be reused. The tests should not be restricted to the
modified code segments, but applied to all aspects of the application that are in any
way affected by the change.

Documenting Changes
Original documentation created during the development of the product must be modified
to reflect any changes. This includes technical and user documentation.

Configuration Management: Systematic control of changes to a software product, the

purpose being to maintain software integrity, traceability and accountability during the
life of the product. There are CASE tools to automate the control and documentation of
changes.

Source Code Documentation

Careful documentation of any changes made to the original code must be maintained.
Details of who made the change, and when, should be included within the code. Any
original comments that are no longer relevant should be removed or modified.

Updating associated hard copy documentation and online help

As hard copy documentation is becoming less and less relevant it is not as important to
know how to update it (im assuming they just issue a new instruction manual?). Online
help is much easier to modify. All official forums and documents should be taken inton
account when modifying a product. The help needs to stay up to date to ensure the
continued usability of the product.

Use Of Case Tools To Monitor Changes And Versions

Some of the problems commonly addressed by these tools are:

Change management
● Change management supports the life cycle of each change, beginning with the
initial change request to the inclusion of the modification into the final product.
Each step of the software development process for each modification is
monitored. For example, a history is maintained of each modification made, when
it was made, and by whom.

Parallel development
● Maintenance of products by large teams of developers requires significant
coordination. Parallel development CASE tools enable multiple users to work on
 the same project without fear of duplication or destroying another team member’s
work.
● Individual files are checked out as required by individual team members. This
effectively locks the file, preventing others from making modifications. When the
modification is complete, the file is checked in. The checking-in process releases
the file and retains a record of the changes made. Distributed parallel
development tools create scripts of changes made to each file; these scripts are
distributed electronically to other team members. This ensures developers work
with the most up-to-date code available.

Version Control
● Version control CASE tools manage multiple versions of software components or
modules. The system tracks which version of each component or module should
be used when the application is finally reassembled. A record is maintained of
prior versions of components, allowing the reconstruction of previous versions of
the application.
● (like github does)

Developing a Solution Package