Apply principles of creating computer software

by developing a complete programme to meet

given business specifications

Unit Std # 115392

NQF Level 5
Notional hours 12
Credit(s) 120
Field Field 03 - Physical, Mathematical, Computer and Life Sciences
Sub-Field Information Technology and Computer Sciences
Qualification National Certificate: Information Technology (Systems Development) LEVEL
5- SAQA- 48872- 131 CREDITS

Learner’s Guide

The Learner guide

At the end of this unit standard you will be able to Apply principles of creating
computer software by developing a complete programme to meet given business

1
specifications

Purpose:
People credited with this unit standard are able to:

 To provide a expert knowledge of the areas covered

For those working in, or entering the workplace in the area of Systems Development
To demonstrate an understanding of how to create (in the computer language of choice) a
complete computer program that will solve a given business problem, showing all the steps
involved in creating computer software

Specific outcome:
 Interpret a given specification to plan a computer program solution
 Design a computer program to meet a business requirement
 Create a computer program that implements the design
 Test a computer program against the business requirements
 Implement the program to meet business requirements
 Document the program according to industry standards

Learning assumed to be in place:

Apply the principles of Computer Programming
 Design, develop and test computer program segments to given specifications
Competent in demonstrating an understanding of the use of different number bases
and measurement units and an awareness of error in the context of relevant
calculations (SAQA ID = 9010).

Equipment needed:
Learning material, Learner workbook, Pen, Ruler.
PLEASE NOTE: THE USE OF PENCILS OR TIPPEX IS NOT ALLOWED.
IF YOU USE A PENCIL THE VALIDITY OF YOUR WORK COULD BE
QUESTIONABLE, AND THIS COULD LEAD TO FRAUD.

Resources (selective resources might be used, depending on the facilitator and venue

2
circumstances), one or all of the following can be used:
 Your facilitator/mentor
 Learning material
 Learner workbook
 Visual aids
 White board
 Flip chart
 Equipment
 Training venue

Venue, Date and Time:

Consult your facilitator should there be any changes to the venue, date and/or time.
Refer to your timetable.

Assessments:
The only way to establish whether you are competent and have accomplished the
specific outcomes is through continuous assessments
The given exercises can contain one or more of the following:
 Information for you to read
 Exercises that require you to have a problem-solving approach to communication
 Questions for you to answer
 Case studies with questions that follow

How to do the exercise:

 The facilitator will tell you which exercise you need to complete each day.

3
  You need to hand in your answers to the facilitator who will mark it for correctness.
 If you do not know the answer, you will have to go back to that particular section in
you learner guide and go over it again.
 Ask the facilitator for help, if you do not understand any of the questions asked.
 Always remember to give reasons for your answers

SPECIFIC OUTCOME 1:

Interpret a given specification to plan a computer program solution.

ASSESEMENT CRITERIA
 The plan proposes a description of the problem to be solved by the development of the
computer program that is understandable by an end-user and meets the given specification.
 The plan integrate the research of problems in term of data and functions
 The plan includes an evaluation of the viability of developing a computer program to solve the
problem identified and compares the costs of developing the program with the benefits to be
obtained from the program.
 The plan concludes by choosing the best solution and documenting the program features that
will contain the capabilities and constraints to meet the defined problem.

4
1.1 Interpret a given specification to plan a computer program solution.

1.1 1 Writing Software Requirements Specifications (SRS)

For technical writers who haven’t had the experience of designing software requirements
specifications (SRSs, also known as software functional specifications or system specifications)
templates or even writing SRSs, they might assume that being given the opportunity to do so is either
a reward or punishment for something they did (or failed to do) on a previous project. Actually, SRSs
are ideal projects for technical writers to be involved with because they lay out the foundation for the
development of a new product and for the types of user documentation and media that will be required
later in the project development life cycle. It also doesn’t hurt that you’d be playing a visible role in
contributing to the success of the project.

1.1 2 What are Software Requirements Specifications?

An SRS is basically an organization’s understanding (in writing) of a customer or potential client’s

system requirements and dependencies at a particular point in time (usually) prior to any actual
design or development work. It’s a two-way insurance policy that assures that both the client and the
organization understand the other’s requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions and capabilities a
software system (i.e., a software application, an eCommerce Web site, and so on) must provide, as
well as states any required constraints by which the system must abide. The SRS also functions as
a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to
as the “parent” document because all subsequent project management documents, such as design
specifications, statements of work, software architecture specifications, testing and validation plans,
and documentation plans, are related to it.

It’s important to note that an SRS contains functional and non-functional requirements only; it doesn’t
offer design suggestions, possible solutions to technology or business issues, or any other information
other than what the development team understands the customer’s system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

 It provides feedback to the customer. An SRS is the customer’s assurance that the development
organization understands the issues or problems to be solved and the software behavior necessary
to address those problems. Therefore, the SRS should be written in natural language , in an
unambiguous manner that may also include charts, tables, data flow diagrams, decision tables,
and so on.

5
 It decomposes the problem into component parts. The simple act of writing down software
requirements in a well-designed format organizes information, places borders around the problem,
solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.

 It serves as an input to the design specification. As mentioned previously, the SRS serves as
the parent document to subsequent documents, such as the software design specification and
statement of work. Therefore, the SRS must contain sufficient detail in the functional
system requirements so that a design solution can be devised. It serves as a product validation
check. The SRS also

 It serves as the parent document for testing and validation strategies that will be applied to the
requirements for verification.

Software requirements specifications are typically developed during the first stages of “Requirements
Development,” which is the initial product development phase in which information is gathered about
what requirements are needed–and not. This information-gathering stage can include onsite visits,
questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs
analysis of the customer or client’s current business environment. The actual specification, then, is
written after the requirements have been gathered and analyzed.

1.1.3 Why Should Technical Writers be Involved with Software Requirements Specifications?

Unfortunately, much of the time, systems architects and programmers write software requirements
specifications with little (if any) help from the technical communications organization. And when that
assistance is provided, it’s often limited to an edit of the final draft just prior to going out the door.
Having technical writers involved throughout the entire SRS development process can offer several
benefits:

 Technical writers are skilled information gatherers, ideal for eliciting and articulating customer
requirements. The presence of a technical writer on the requirements-gathering team helps
balance the type and amount of information extracted from customers, which can help improve
the software requirements specifications.

 Technical writers can better assess and plan documentation projects and better meet customer
document needs. Working on SRSs provides technical writers with an opportunity for learning
about customer needs firsthand–early in the product development process.

 Technical writers know how to determine the questions that are of concern to the user or customer
regarding ease of use and usability. Technical writers can then take that knowledge and apply it

6
 not only to the specification and documentation development, but also to user
interface development, to help ensure the UI (User Interface) models the customer requirements.

 Technical writers, involved early and often in the process, can become an information resource
throughout the process, rather than an information gatherer at the end of the process.

In short, a requirements-gathering team consisting solely of programmers, product marketers, systems

analysts/architects, and a project manager runs the risk of creating a specification that may be too
heavily loaded with technology-focused or marketing-focused issues. The presence of a technical
writer on the team helps place at the core of the project those user or customer requirements that
provide more of an overall balance to the design of the software requirements specifications, product,
and documentation.

1.1.4 What Kind of Information Should an SRS Include?

You probably will be a member of the SRS team (if not, ask to be), which means SRS development
will be a collaborative effort for a particular project. In these cases, your company will have
developed SRSs before, so you should have examples (and, likely, the company’s SRS template) to
use. But, let’s assume you’ll be starting from scratch. Several standards organizations (including the
IEEE) have identified nine topics that must be addressed when designing and writing an SRS:

1. Interfaces

2. Functional Capabilities

3. Performance Levels

4. Data Structures/Elements

5. Safety

6. Reliability

7. Security/Privacy

8. Quality

9. Constraints and Limitations

But, how do these general topics translate into an SRS document? What, specifically, does an SRS
document include? How is it structured? And how do you get started? An SRS document typically
includes four ingredients, as discussed in the following sections:

1. A template

7
2. A method for identifying requirements and linking sources

3. Business operation rules

4. A traceability matrix

Begin with an SRS Template

The first and biggest step to writing software requirements specifications is to select an existing
template that you can fine tune for your organizational needs (if you don’t have one already).
There’s not a “standard specifications template” for all projects in all industries because the individual
requirements that populate an SRS are unique not only from company to company, but also
from project to project within any one company. The key is to select an existing template or
specification to begin with, and then adapt it to meet your needs.

In recommending using existing templates, I’m not advocating simply copying a template from
available resources and using them as your own; instead, I’m suggesting that you use available
templates as guides for developing your own. It would be almost impossible to find a specification or
specification template that meets your particular project requirements exactly.

Table 1 shows what a basic SRS outline might look like. This example is an adaptation and extension
of the IEEE Standard 830-1998:

Table 1 A sample of a basic SRS outline

1. Introduction

8
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies
3. External Interface Requirements
3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces
4. System Features
4.1 System feature A
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B
5. Other Nonfunctional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation
6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list
Appendix B: To be determined

9
 SPECIFIC OUTCOME 2 :
Design a computer program to meet a business requirement.
ASSESEMENT CRITERIA
 The design incorporates development of appropriate design documentstion and is desk-
checked.
 The design of the program includes program structure components.
 The design of the program includes program logical flow components.
 The design of the program includes data structures and access method components.

2.1 A Design a computer program to meet a business requirement

2.1.1 Establish Business Rules for Contingencies and Responsibilities

10
“The best-laid plans of mice and men…” begins the famous saying. It has direct application to writing
software requirements specifications because even the most thought-out requirements are not immune
to changes in industry, market, or government regulations. A top-quality SRS should include plans for
planned and unplanned contingencies, as well as an explicit definition of the responsibilities of each
party, should a contingency be implemented. Some business rules are easier to work around than
others, when Plan B has to be invoked. For example, if a customer wants to change a requirement that
is tied to a government regulation, it may not be ethical and/or legal to be following “the spirit of
the law.” Many government regulations, as business rules, simply don’t allow any compromise or
“wiggle room.” A project manager may be responsible for ensuring that a government regulation
is followed as it relates to a project requirement; however, if a contingency is required, then the
responsibility for that requirement may shift from the project manager to a regulatory attorney. The
SRS should anticipate such actions to the furthest extent possible.

2.1 2 Establish a Requirements Traceability Matrix

The business rules for contingencies and responsibilities can be defined explicitly within a
Requirements Traceability Matrix (RTM), or contained in a separate document and referenced in the
matrix, as the example in Table 3 illustrates. Such a practice leaves no doubt as to responsibilities and
actions under certain conditions as they occur during the product-development phase.

The RTM functions as a sort of “chain of custody” document for requirements and can include
pointers to links from requirements to sources, as well as pointers to business rules. For example, any
given requirement must be traced back to a specified need, be it a use case, business
essential, industry-recognized standard, or government regulation. As mentioned previously, linking
requirements with sources minimizes or even eliminates the presence of spurious or frivolous
requirements that lack any justification. The RTM is another record of mutual understanding, but also
helps during the development phase.

As software design and development proceed, the design elements and the actual code must be tied
back to the requirement(s) that define them.

2.13 Software Design

Software design is both a process and a model. The design process is a sequence of steps that enable
the designer to describe all aspects of the software to be built. It is important to note, however, that the
design process is not simply a cookbook. Creative skill, past experience, a sense of what makes

11
“good” software, and an overall commitment to quality are critical success factors for a competent
design. The design model is the equivalent of an architect’s plans for a house. It begins by
representing the totality of the thing to be built (e.g., a three-dimensional rendering of the house) and
slowly refines the thing to provide guidance for constructing each detail (e.g., the plumbing layout).
Similarly, the design model that is created for software provides a variety of different views of the
computer software. Basic design principles enable the software engineer to navigate the design
process. Davis [DAV95] suggests a set of principles for software design, which have been adapted
and extended in the following list:

The design process should not suffer from “tunnel vision.” A good designer should consider
alternative approaches, judging each based on the requirements of the problem, the resources
available to do the job.

The design should be traceable to the analysis model. Because a single element of the design model
often traces to multiple requirements, it is necessary to have a means for tracking how requirements
have been satisfied by the design model.

The design should not reinvent the wheel. Systems are constructed using a set of design patterns,
many of which have likely been encountered before. These patterns should always be chosen as an
alternative to reinvention. Time is short and resources are limited! Design time should be invested in
representing truly new ideas and integrating those patterns that already exist.

The design should “minimize the intellectual distance” between the software and the problem as it
exists in the real world. That is, the structure of the software design should (whenever possible) mimic
the structure of the problem domain.

The design should exhibit uniformity and integration. A design is uniform if it appears that one
person developed the entire thing. Rules of style and format should be defined for a design team
before design work begins. A design is integrated if care is taken in defining interfaces between
design components.

The design should be structured to accommodate change. The design concepts discussed in the
next section enable a design to achieve this principle.

The design should be structured to degrade gently, even when aberrant data, events, or operating
conditions are encountered. Well- designed software should never “bomb.” It should be designed to
accommodate unusual circumstances, and if it must terminate processing, do so in a graceful manner.

12
Design is not coding, coding is not design. Even when detailed procedural designs are created for
program components, the level of abstraction of the design model is higher than source code. The
only design decisions made at the coding level address the small implementation details that enable
the procedural design to be coded.

The design should be assessed for quality as it is being created, not after the fact. A variety of
design concepts and design measures are available to assist the designer in assessing quality.

The design should be reviewed to minimize conceptual (semantic) errors. There is sometimes a
tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A design
team should ensure that major conceptual elements of the design (omissions, ambiguity,
inconsistency) have been addressed before worrying about the syntax of the design model.

2.1.4 Design Concepts

The design concepts provide the software designer with a foundation from which more sophisticated
methods can be applied. A set of fundamental design concepts has evolved. They are:

Abstraction - Abstraction is the process or result of generalization by reducing the information

content of a concept or an observable phenomenon, typically in order to retain only information which
is relevant for a particular purpose.

Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a

macroscopic statement of function in a step-wise fashion until programming language statements are
reached. In each step, one or several instructions of a given program are decomposed into more
detailed instructions. Abstraction and Refinement are complementary concepts.

Modularity - Software architecture is divided into components called modules.

Software Architecture - It refers to the overall structure of the software and the ways in which that
structure provides conceptual integrity for a system. A good software architecture will yield a good
return on investment with respect to the desired outcome of the project, e.g. in terms of performance,
quality, schedule and cost.

Control Hierarchy - A program structure that represents the organization of a program component
and implies a hierarchy of control.

Structural Partitioning - The program structure can be divided both horizontally and vertically.
Horizontal partitions define separate branches of modular hierarchy for each major program function.

13
Vertical partitioning suggests that control and work should be distributed top down in the program
structure.

Data Structure - It is a representation of the logical relationship among individual elements of data.

Software Procedure - It focuses on the processing of each modules individually

Information Hiding - Modules should be specified and designed so that information contained within
a module is inaccessible to other modules that have no need for such information

2.1.5 Design considerations

There are many aspects to consider in the design of a piece of software. The importance of each
should reflect the goals the software is trying to achieve. Some of these aspects are:

Compatibility - The software is able to operate with other products that are designed for
interoperability with another product. For example, a piece of software may be backward-compatible
with an older version of itself.

Extensibility - New capabilities can be added to the software without major changes to the underlying
architecture.

Fault-tolerance - The software is resistant to and able to recover from component failure.

Maintainability - A measure of how easily bug fixes or functional modifications can be

accomplished. High maintainability can be the product of modularity and extensibility.

Modularity - the resulting software comprises well defined, independent components. That leads to
better maintainability. The components could be then implemented and tested in isolation before
being integrated to form a desired software system. This allows division of work in a software
development project.

Reliability - The software is able to perform a required function under stated conditions for a
specified period of time.

Reusability - the software is able to add further features and modification with slight or no
modification.

Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input.
For example, it can be designed with a resilience to low memory conditions.

Security - The software is able to withstand hostile acts and influences.

14
Usability - The software user interface must be usable for its target user/audience. Default values for
the parameters must be chosen so that they are a good choice for the majority of the users.

Performance - The software performs its tasks within a user-acceptable time. The software does not
consume too much memory.

Portability - The usability of the same software in different environments.

Scalability - The software adapts well to increasing data or number of users.

SPECIFIC OUTCOME 3:
Create a computer program that implements the design.
ASSESEMENT CRITERIA
 The creation includes coding from design documents, to meet the design specifications
 Names created in the program describe the purpose of the items named
 The creation includes conformance with the design documentation, and differences are
documented with reasons for deviations

3.1 Create a computer program that implements the design

15
What is involved in writing a computer program?

What kinds of decisions must be made?

Who is involved?

The process of creating a computer program is not as straight-forward as you might think. It involves
a lot of thinking, experimenting, testing, and rewriting to achieve a high-quality product. Let's break
down the process to give you an idea of what goes on.

3.1.1 What Task?

The first decision to make when creating a computer program is:

What is this program supposed to do?

The more detailed this description is, the easier it will be to get good results.

3.1.2 What Language?

The choice of what computer language to use has important consequences for how easy the program
will be to write and maintain. The graphic shows some of the most commonly used languages and
what tasks they are usually used for.

The languages are grouped by how complex they are for the writer. The simplest with the least power
are at the bottom. Simple languages for simple tasks. (But how simple is any of this, really??)

3.1.3 Things to consider in choosing a language

16
Works with what you've got -

 Existing standards in your company

 Existing hardware

 Existing software with which to interact

 Programmers' current knowledge

Will work in the future -

 With variety of hardware

 Changes easy to make in programs

 Errors easy to find in programs

3.1.4 Who's Involved?

What people are involved in the creation of a new computer program?

The End User sets the tasks to be done. What does the customer want
to do??

A Systems Analyst designs the overall requirements and sets the

strategy for the program.

A Programmer writes the actual code to perform the tasks.

There may be a huge team of dozens of people involved. Or perhaps one programmer decides that he
can write a program that is the answer to what users complain about. It may be done in a highly
structured series of conferences and consumer surveys. Or perhaps someone is listening to what
people say as they go about trying to work. Somehow the needs of the end users must be understood
as well as the limitations of the code and the hardware. Costs come into play, too. (Sad but true.)

All of these people must communicate back and forth throughout the process. No program of any size
will be without unexpected problems. So it's test and fix and test again until the program actually does
what it was intended to do.

17
3.1.5 Program Development

A program goes through the following steps over and over during its development, never just once.

1. Set & Review goals: What is it supposed to do?

2. Design: Create the strategy to achieve goal.

3. Coding: Write the program.

4. Testing: Try it out with real people.

5. Documentation: What you did and why. How to use it.

One of the techniques used during the design phase is to flowchart the program, as on the right.
Different shapes represent different kinds of steps, like input and output, decisions, calculations. Such
charts help keep the logic clear, especially in complex programs.

Each time through the development loop, the program must be debugged. This means testing the
program under all conditions in order to find the problems so they can be handled. There
will alwaysbe problems. Sometimes it's just a typo, and sometimes it's a flaw in the logic, and
sometimes it's an incompatibility with the hardware or other software. Handling such situations can be
the most time-consuming part of the whole process!

Proper documentation can make or break a program. This includes explanations to the end user of
how to use the program and also internal notes to programmers about what the code is doing and why.
It is amazing how quickly the original coder can forget why he wrote the code that way!

Programs often need to be maintained, that is, changes must be made. For example, the sales tax rate
might change or zip codes may get more digits. With proper internal documentation, a different
programmer can make these adjustments without damaging the program.

18
 SPECIFIC OUTCOME 4:
Test a computer program against the business requirements.
ASSESEMENT CRITERIA
 The testing includes assessment of the need to develop a testing program to assist with stress
testing
 The testing includes the planning, developing and implementing a test strategy that is

19
 appropriate for the type of program being tested.
 The testing includes the recording of test results that allow for the identification and validation
of test outcomes.

4.1 Testing a computer program against given specifications according to test plans.
 Programme Testing refers to a set of activities conducted with the intent of finding
errors in software.

 Test plan refers to specification is called a test plan. The developers are well aware what
test plans will be executed and this information is made available to management and the
developers. The idea is to make them more cautious when developing their code or
making additional changes. Some companies have a higher-level document called a test
strategy.

4.1.1 Approaches to programme testing

(a) Static vs. dynamic testing

There are many approaches available in software testing. Reviews, walkthroughs, or inspections are
referred to as static testing, whereas actually executing programmed code with a given set of test
cases is referred to as dynamic testing. Static testing is often implicit, as proofreading, plus when
programming tools/text editors check source code structure or compilers (pre-compilers) check syntax
and data flow as static program analysis. Dynamic testing takes place when the program itself is run.
Dynamic testing may begin before the program is 100% complete in order to test particular sections
of code and are applied to discrete functions or modules. Typical techniques for this are either
using stubs/drivers or execution from a debugger environment.

Static testing involves verification, whereas dynamic testing involves validation. Together they help
improve software quality. Among the techniques for static analysis, mutation testing can be used to
ensure the test-cases will detect errors which are introduced by mutating the source code.

(b) The box approach

Software testing methods are traditionally divided into white- and black-box testing. These two
approaches are used to describe the point of view that a test engineer takes when designing test cases.

i. White-Box testing

20
 White-box testing (also known as clear box testing, glass box testing, transparent box
testing and structural testing) tests internal structures or workings of a program, as opposed
to the functionality exposed to the end-user. In white-box testing an internal perspective of the
system, as well as programming skills, are used to design test cases. The tester chooses inputs
to exercise paths through the code and determine the appropriate outputs. This is analogous to
testing nodes in a circuit, e.g. in-circuit testing (ICT).

While white-box testing can be applied at the unit, integration and system levels of the
software testing process, it is usually done at the unit level. It can test paths within a unit,
paths between units during integration, and between subsystems during a system–level test.
Though this method of test design can uncover many errors or problems, it might not detect
unimplemented parts of the specification or missing requirements.

Visual testing

The aim of visual testing is to provide developers with the ability to examine what was
happening at the point of software failure by presenting the data in such a way that the
developer can easily find the information he or she requires, and the information is
expressed clearly.

At the core of visual testing is the idea that showing someone a problem (or a test
failure), rather than just describing it, greatly increases clarity and understanding.
Visual testing therefore requires the recording of the entire test process – capturing
everything that occurs on the test system in video format. Output videos are
supplemented by real-time tester input via picture-in-a-picture webcam and audio
commentary from microphones.

Visual testing provides a number of advantages. The quality of communication is

increased dramatically because testers can show the problem (and the events leading up
to it) to the developer as opposed to just describing it and the need to replicate test
failures will cease to exist in many cases. The developer will have all the evidence he
or she requires of a test failure and can instead focus on the cause of the fault and how
it should be fixed.

ii. Grey-box testing

Grey-box testing involves having knowledge of internal data structures and algorithms for
purposes of designing tests, while executing those tests at the user, or black-box level. The
tester is not required to have full access to the software's source code. Manipulating input data
and formatting output do not qualify as grey-box, because the input and output are clearly

21
outside of the "black box" that we are calling the system under test. This distinction is
particularly important when conducting integration testing between two modules of code
written by two different developers, where only the interfaces are exposed for test.

However, tests that require modifying a back-end data repository such as a database or a log
file does qualify as grey-box, as the user would not normally be able to change the data
repository in normal production operations Grey-box testing may also include reverse
engineering to determine, for instance, boundary values or error messages.

By knowing the underlying concepts of how the software works, the tester makes better-
informed testing choices while testing the software from outside. Typically, a grey-box tester
will be permitted to set up an isolated testing environment with activities such as seeding
a database. The tester can observe the state of the product being tested after performing
certain actions such as executing SQL statements against the database and then executing
queries to ensure that the expected changes have been reflected. Grey-box testing implements
intelligent test scenarios, based on limited information. This will particularly apply to data
type handling, exception handling, and so on.

Unit testing

Unit testing, also known as component testing, refers to tests that verify the
functionality of a specific section of code, usually at the function level. In an object-
oriented environment, this is usually at the class level, and the minimal unit tests
include the constructors and destructors.

These types of tests are usually written by developers as they work on code (white-box
style), to ensure that the specific function is working as expected. One function might
have multiple tests, to catch corner cases or other branches in the code. Unit testing
alone cannot verify the functionality of a piece of software, but rather is used to ensure
that the building blocks of the software work independently from each other.

Unit testing is a software development process that involves synchronized application

of a broad spectrum of defect prevention and detection strategies in order to reduce
software development risks, time, and costs. It is performed by the software developer
or engineer during the construction phase of the software development lifecycle. Rather
than replace traditional QA focuses, it augments it. Unit testing aims to eliminate
construction errors before code is promoted to QA; this strategy is intended to increase
the quality of the resulting software as well as the efficiency of the overall development
and QA process.

22
 Integration testing

Integration testing is any type of software testing that seeks to verify the interfaces
between components against a software design. Software components may be
integrated in an iterative way or all together ("big bang"). Normally the former is
considered a better practice since it allows interface issues to be located more quickly
and fixed.

Integration testing works to expose defects in the interfaces and interaction between
integrated components (modules). Progressively larger groups of tested software
components corresponding to elements of the architectural design are integrated and
tested until the software works as a system.

iii. Component interface testing

The practice of component interface testing can be used to check the handling of data passed
between various units, or subsystem components, beyond full integration testing between
those units. The data being passed can be considered as "message packets" and the range or
data types can be checked, for data generated from one unit, and tested for validity before
being passed into another unit.

One option for interface testing is to keep a separate log file of data items being passed, often
with a timestamp logged to allow analysis of thousands of cases of data passed between units
for days or weeks. Tests can include checking the handling of some extreme data values while
other interface variables are passed as normal values. Unusual data values in an interface can
help explain unexpected performance in the next unit. Component interface testing is a
variation of black-box testing with the focus on the data values beyond just the related
actions of a subsystem component.

iv. System testing

System testing, or end-to-end testing, tests a completely integrated system to verify that it
meets its requirements. For example, a system test might involve testing a logon interface,
then creating and editing an entry, plus sending or printing results, followed by summary
processing or deletion (or archiving) of entries, then logoff.

In addition, the software testing should ensure that the program, as well as working as
expected, does not also destroy or partially corrupt its operating environment or cause other

23
 processes within that environment to become inoperative (this includes not corrupting shared
memory, not consuming or locking up excessive resources and leaving any parallel processes
unharmed by its presence).

v. Installation testing

An installation test assures that the system is installed correctly and working at actual
customer's hardware.

vi. Compatibility testing

A common cause of software failure (real or perceived) is a lack of its compatibility with
other application software, operating systems (or operating system versions, old or new), or
target environments that differ greatly from the original (such as
a terminal or GUI application intended to be run on the desktop now being required to
become a web application, which must render in a web browser). For example, in the case of
a lack of backward compatibility, this can occur because the programmers develop and test
software only on the latest version of the target environment, which not all users may be
running. This results in the unintended consequence that the latest work may not function on
earlier versions of the target environment, or on older hardware that earlier versions of the
target environment was capable of using. Sometimes such issues can be fixed by proactive
abstracting operating system functionality into a separate program module or library.

vii. Smoke and sanity testing

Sanity testing determines whether it is reasonable to proceed with further testing.

Smoke testing consists of minimal attempts to operate the software, designed to determine
whether there are any basic problems that will prevent it from working at all. Such tests can
be used as build verification test.

viii. Regression testing

Regression testing focuses on finding defects after a major code change has occurred.
Specifically, it seeks to uncover software regressions, as degraded or lost features, including
old bugs that have come back. Such regressions occur whenever software functionality that
was previously working, correctly, stops working as intended. Typically, regressions occur as
an unintended consequence of program changes, when the newly developed part of the
software collides with the previously existing code. Common methods of regression testing

24
 include re-running previous sets of test-cases and checking whether previously fixed faults
have re-emerged.

The depth of testing depends on the phase in the release process and the risk of the added
features. They can either be complete, for changes added late in the release or deemed to be
risky, or be very shallow, consisting of positive tests on each feature, if the changes are early
in the release or deemed to be of low risk. Regression testing is typically the largest test effort
in commercial software development due to checking numerous details in prior software
features, and even new software can be developed while using some old test-cases to test parts
of the new design to ensure prior functionality is still supported.

ix. Acceptance testing

Acceptance testing can mean one of two things:

1. A smoke test is used as an acceptance test prior to introducing a new build to the
main testing process, i.e. before integration or regression.

2. Acceptance testing performed by the customer, often in their lab environment on

their own hardware, is known as user acceptance testing (UAT). Acceptance testing
may be performed as part of the hand-off process between any two phases of
development.

x. Alpha testing

Alpha testing is simulated or actual operational testing by potential users/customers or an

independent test team at the developers' site. Alpha testing is often employed for off-the-shelf
software as a form of internal acceptance testing, before the software goes to beta testing.

xi. Beta testing

Beta testing comes after alpha testing and can be considered a form of external user
acceptance testing. Versions of the software, known as beta versions, are released to a limited
audience outside of the programming team. The software is released to groups of people so
that further testing can ensure the product has few faults or bugs. Sometimes, beta versions
are made available to the open public to increase the feedback field to a maximal number of
future users.

xii. Functional vs non-functional testing

Functional testing refers to activities that verify a specific action or function of the code.
These are usually found in the code requirements documentation, although some development

25
 methodologies work from use cases or user stories. Functional tests tend to answer the
question of "can the user do this" or "does this particular feature work."

Non-functional testing refers to aspects of the software that may not be related to a specific
function or user action, such as scalability or other performance, behaviour under
certain constraints, or security. Testing will determine the breaking point, the point at which
extremes of scalability or performance leads to unstable execution. Non-functional
requirements tend to be those that reflect the quality of the product, particularly in the context
of the suitability perspective of its users.

xiii. Destructive testing

Destructive testing attempts to cause the software or a sub-system to fail. It verifies that the
software functions properly even when it receives invalid or unexpected inputs, thereby
establishing the robustness of input validation and error-management routines. Software fault
injection, in the form of fuzzing, is an example of failure testing. Various commercial non-
functional testing tools are linked from the software fault injection page; there are also
numerous open-source and free software tools available that perform destructive testing.

xiv. Software performance testing

Performance testing is generally executed to determine how a system or sub-system performs

in terms of responsiveness and stability under a particular workload. It can also serve to
investigate, measure, validate or verify other quality attributes of the system, such as
scalability, reliability and resource usage.

Load testing is primarily concerned with testing that the system can continue to operate under
a specific load, whether that be large quantities of data or a large number of users. This is
generally referred to as software scalability. The related load testing activity of when
performed as a non-functional activity is often referred to as endurance testing. Volume is a
way to test software functions even when certain components (for example a file or database)
increase radically in size. Stress testing is a way to test reliability under unexpected or rare
workloads. Stability testing (often referred to as load or endurance testing) checks to see if the
software can continuously function well in or above an acceptable period.

There is little agreement on what the specific goals of performance testing are. The terms load
testing, performance testing, scalability testing, and volume testing, are often used
interchangeably.

26
 Real-time software systems have strict timing constraints. To test if timing constraints are
met, real-time testing is used.

xv. Usability testing

Usability testing is to check if the user interface is easy to use and understand. It is concerned
mainly with the use of the application.

xvi. Security testing

Security testing is essential for software that processes confidential data to prevent system
intrusion by hackers.

xvii. Internationalization and localization

The general ability of software to be internationalized and localized can be automatically

tested without actual translation, by using pseudo localization. It will verify that the
application still works, even after it has been translated into a new language or adapted for a
new culture (such as different currencies or time zones).

Actual translation to human languages must be tested, too. Possible localization failures
include:

 Software is often localized by translating a list of strings out of context, and the
translator may choose the wrong translation for an ambiguous source string.

 Technical terminology may become inconsistent if the project is translated by several

people without proper coordination or if the translator is imprudent.

 Literal word-for-word translations may sound inappropriate, artificial or too technical

in the target language.

 Untranslated messages in the original language may be left hard coded in the source
code.

 Some messages may be created automatically at run time and the resulting string may
be ungrammatical, functionally incorrect, misleading or confusing.

 Software may use a keyboard shortcut which has no function on the source
language's keyboard layout, but is used for typing characters in the layout of the target
language.

 Software may lack support for the character encoding of the target language.

27
 SPECIFIC OUTCOME 5:
Implement the program to meet business requirements.
ASSESEMENT CRITERIA
 The implementation involves checking the program for compliance with user expectations and
any other applicable factors
 The implementation involves training of users to enable them to use the software to their
requirements
 The implementation involves planning of installation of the program that minimises disruption
to the user

5.1 Implement the program to meet business requirements

Business requirements are what must be delivered to provide value. Products, systems, software, and
processes are the ways how to deliver, satisfy, or meet the business requirements whats.
Consequently, the topic of business requirements often arises in the context of developing or
procuring software or other system; but business requirements exist much more broadly. That is,
'business' can be at work or personal, for profit or non-profit.

Business requirements in the context of software engineering or the software development life
cycle, is about eliciting and documenting business requirements of business users such as customers,
employees, and vendors early in the development cycle of a system to guide the design of the future
system. Business requirements are often captured by business, who analyze business activities and
processes, and often study As-is process to define a target To-be process.

Business requirements often include

 Business context, scope, and background, including reasons for change

 Key business stakeholders that have requirements

 Success factors for a future/target state

 Constraints imposed by the business or other systems

 Business process models and analysis, often using flowchart notations to depict either 'as-is' and
'to-be' business processes

 Logical data model and data dictionary references

28
 Glossaries of business terms and local jargon

 Data flow diagrams to illustrate how data flows through the information systems (different from
flowcharts depicting algorithmic flow of business activities)

SPECIFIC OUTCOME 6:
Document the program according to industry standards.
ASSESEMENT CRITERIA
 The documentation includes annotation of the program with a description of program purpose

29
 and design specifics.
 The documentation includes the layout of the program code including indentation and other
acceptable industry standards
 The documentation includes full internal and external documentation, with a level of detail that
enables other programmers to analyse the program
 The documentation reflects the tested and implemented program, including changes made
during testing of the program

6.1 Plan and design documentation for a computer program to agreed standards.
Computer program documentation is written text that accompanies computer program or software. It
either explains how it operates or how to use it, or may mean different things to people in different
roles.

Role of documentation in software development

Documentation is an important part of software engineering. Types of documentation include:
1. Requirements - Statements that identify attributes capabilities, characteristics, or qualities of
a system. This is the foundation for what shall be or has been implemented.
2. Architecture/Design - Overview of software. Includes relations to an environment and
construction principles to be used in design of software components.
3. Technical - Documentation of code, algorithms, interfaces, and APIs.
4. End user - Manuals for the end-user, system administrators and support staff.
5. Marketing - How to market the product and analysis of the market demand.

Process and Product Documentation

For large software projects, it is usually the case that documentation starts being generated well before
the development process begins. A proposal to develop the system may be produced in response to a
request for tenders by an external client or in response to other business strategy documents. For some
types of system, a comprehensive requirements document may be produced which defines the features
required and expected behavior of the system. During the development process itself, all sorts of
different documents may be produced – project plans, design specifications, test plans etc.

It is not possible to define a specific document set that is required – this depends on the contract with
the client for the system, the type of system being developed and its expected lifetime, the culture and

30
size of the company developing the system and the development schedule that it expected. However,
we can generally say that the documentation produced falls into two classes:

1. Process documentation. These documents record the process of development and maintenance.
Plans, schedules, process quality documents and organizational and project standards are process
documentation.

2. Product documentation. This documentation describes the product that is being developed.
System documentation describes the product from the point of view of the engineers developing and
maintaining the system; user documentation provides a product description that is oriented towards
system users.

Process documentation is produced so that the development of the system can be managed. Product
documentation is used after the system is operational but is also essential for management of the
system development. The creation of a document, such as a system specification, may represent an
important milestone in the software development process.

Process documentation

Effective management requires the process being managed to be visible. Because software is
intangible and the software process involves apparently similar cognitive tasks rather than obviously
different physical tasks, the only way this visibility can be achieved is through the use of process
documentation.

Process documentation falls into a number of categories:

1. Plans, estimates and schedules. These are documents produced by managers which are used to
predict and to control the software process.

2. Reports. These are documents which report how resources were used during the process of
development.

3. Standards. These are documents which set out how the process is to be implemented. These may
be developed from organizational, national or international standards.

4. Working papers. These are often the principal technical communication documents in a
project. They record the ideas and thoughts of the engineers working on the project, are interim

31
versions of product documentation, describe implementation strategies and set out problems which
have been identified. They often, implicitly, record the rationale for design decisions.

5. Memos and electronic mail messages. These record the details of everyday communications
between managers and development engineers.

The major characteristic of process documentation is that most of it becomes out-dated. Plans may be
drawn up on a weekly, fortnightly or monthly basis. Progress will normally be reported weekly.
Memos record thoughts, ideas and intentions which change.

Although of interest to software historians, much of this process information is of little real use after it
has gone out of date and there is not normally a need to preserve it after the system has been
delivered. However, there are some process documents that can be useful as the software evolves in
response to new requirements.

For example, test schedules are of value during software evolution as they act as a basis for re-
planning the validation of system changes. Working papers which explain the reasons behind design
decisions (design rationale) are also potentially valuable as they discuss design options and choices
made. Access to this information helps avoid making changes which conflict with these original
decisions. Ideally, of course, the design rationale should be extracted from the working papers and
separately maintained. Unfortunately this hardly ever happens.

Product documentation
Product documentation is concerned with describing the delivered software product. Unlike most
process documentation, it has a relatively long life. It must evolve in step with the product which it
describes. Product documentation includes user documentation which tells users how to use the
software product and system documentation which is principally intended for maintenance engineers.

User Documentation
Users of a system are not all the same. The producer of documentation must structure it to cater for
different user tasks and different levels of expertise and experience. It is particularly important to
distinguish between end-users and system administrators:

1. End-users use the software to assist with some task. This may be flying an aircraft, managing
insurance policies, writing a book, etc. They

32
want to know how the software can help them. They are not interested in computer or administration
details.

2. System administrators are responsible for managing the software used by end-users. This may
involve acting as an operator if the system is a large mainframe system, as a network manager is the
system involves a network of workstations or as a technical guru who fixes end-users software
problems and who liaises between users and the software supplier.

To cater for these different classes of user and different levels of user expertise, there are at least 5
documents (or perhaps chapters in a single document) which should be delivered with the software
system (Figure1).

The functional description of the system outlines the system requirements and briefly describes the
services provided. This document should provide an overview of the system. Users should be able to
read this document with an introductory manual and decide if the system is what they need.

The system installation document is intended for system administrators. It should provide details of
how to install the system in a particular environment. It should contain a description of the files
making up the system and the minimal hardware configuration required. The permanent files which
must be established, how to start the system and the configuration dependent files which must be
changed to tailor the system to a particular host system should also be described. The use of
automated installers for PC software has meant that some suppliers see this document as unnecessary.
In fact, it is still required to help system managers discover and fix problems with the installation.

33
The introductory manual should present an informal introduction to the system, describing its
‘normal’ usage. It should describe how to get started and how end-users might make use of the
common system facilities. It should be liberally illustrated with examples. Inevitably beginners,
whatever their background and experience, will make mistakes. Easily discovered information on
how to recover from these mistakes and restart useful work should be an integral part of this
document.

The system reference manual should describe the system facilities and their usage, should provide a
complete listing of error messages and should describe how to recover from detected errors. It should
be complete. Formal descriptive techniques may be used. The style of the reference manual should not
be unnecessarily pedantic and turgid, but completeness is more important than readability.

A more general system administrator’s guide should be provided for some types of system such as
command and control systems. This should describe the messages generated when the system
interacts with other systems and how to react to these messages. If system hardware is involved, it
might also explain the operator’s task in maintaining that hardware. For example, it might describe
how to clear faults in the system console, how to connect new peripherals, etc.

As well as manuals, other, easy-to-use documentation might be provided. A quick reference card
listing available system facilities and how to use them is particularly convenient for experienced
system users. On-line help systems, which contain brief information about the system, can save the
user spending time in consultation of manuals although should not be seen as a replacement for more
comprehensive documentation.

System Documentation
System documentation includes all of the documents describing the system itself from the
requirements specification to the final acceptance test plan. Documents describing the design,
implementation and testing of a system are essential if the program is to be understood and
maintained. Like user documentation, it is important that system documentation is structured, with
overviews leading the reader into more formal and detailed descriptions of each aspect of the system.

For large systems that are developed to a customer’s specification, the system documentation should
include:

1. The requirements document and an associated rationale.

34
2. A document describing the system architecture.

3. For each program in the system, a description of the architecture of that program.

4. For each component in the system, a description of its functionality and interfaces.

5. Program source code listings. These should be commented where the comments should explain
complex sections of code and provide a rationale for the coding method used. If meaningful names are
used and a good, structured programming style is used, much of the code should be self-documenting
without the need for additional comments. This information is now normally maintained
electronically rather than on paper with selected information printed on demand from readers.

6. Validation documents describing how each program is validated and how the validation
information relates to the requirements. A system maintenance guide which describes known
problems with the system, describes which parts of the system are hardware and software dependent
and which describes how evolution of the system has been taken into account in its design.

A common system maintenance problem is ensuring that all representations are kept in step when the
system is changed. To help with this, the relationships and dependencies between documents and
parts of documents should be recorded in a document management system as discussed in the final
part of this paper.

For smaller systems and systems that are developed as software products, system documentation is
usually less comprehensive. This is not necessarily a good thing but schedule pressures on developers
mean that documents are simply never written or, if written, are not kept up to date. These pressures
are sometimes inevitable but, in my view, at the very least you should always try to maintain a
specification of the system, an architectural design document and the program source code.

Unfortunately, documentation maintenance is often neglected. Documentation may become out of

step with its associated software, causing problems for both users and maintainers of the system. The
natural tendency is to meet a deadline by modifying code with the intention of modifying other
documents later.

Often, pressure of work means that this modification is continually set aside until finding what is to be
changed becomes very difficult indeed. The best solution to this problem is to support document
maintenance with software tools which record document relationships, remind software engineers

35
when changes to one document affect another and record possible inconsistencies in the
documentation. Such a system is described by Garg and Scacchi (1990).

Document Quality
Unfortunately, much computer system documentation is badly written, difficult to understand, out-of-
date or incomplete. Although the situation is improving, many organizations still do not pay enough
attention to producing system documents which are well-written pieces of technical prose.

Document quality is as important as program quality. Without information on how to use a system or
how to understand it, the utility of that system is degraded. Achieving document quality requires
management commitment to document design, standards, and quality assurance processes. Producing
good documents is neither easy nor cheap and many software engineers find it more difficult that
producing good quality programs.

Document structure

The document structure is the way in which the material in the document is organized into chapters
and, within these chapters, into sections and sub- sections. Document structure has a major impact on
readability and usability and it is important to design this carefully when creating documentation. As
with software systems, you should design document structures so that the different parts are as
independent as possible. This allows each part to be read as a single item and reduces problems of
cross-referencing when changes have to be made.

36
Structuring a document properly also allows readers to find information more easily. As well as
document components such as contents lists and indexes, well-structured documents can be skim read
so that readers can quickly locate sections or sub-sections that are of most interest to them.

Documentation Standards

Documentation standards act as a basis for document quality assurance. Documents produced
according to appropriate standards have a consistent appearance, structure and quality. Other
standards that may be used in the documentation process are:

1. Process standards- These standards define the process which should be followed for high-
quality document production.

2. Product standards - These are standards which govern the documents themselves.

37
3. Interchange standards- It is increasingly important to exchange copies of documents via
electronic mail and to store documents in databases. Interchange standards ensure that all electronic
copies of documents are compatible.

Standards are, by their nature, designed to cover all cases and, consequently, can sometimes seem
unnecessarily restrictive. It is therefore important that, for each project, the appropriate standards are
chosen and modified to suit that particular project. Small projects developing systems with a
relatively short expected lifetime need different standards from large software projects where the
software may have to be maintained for 10 or more years.

Process standards

Process standards define the approach to be taken in producing documents. This generally means
defining the software tools which should be used for document production and defining the quality
assurance procedures which ensure that high-quality documents are produced. Document process
quality assurance standards must be flexible and must be able to cope with all types of document. In
some cases, where documents are simply working papers or memos, no explicit quality checking is
required. However, where documents are formal documents, that is, when their evolution is to be
controlled by configuration management procedures, a formal quality process should be adopted.

Drafting, checking, revising and re-drafting is an iterative process which should be continued until a
document of acceptable quality is produced. The acceptable quality level will depend on the document
type and the potential readers of the document.

Product standards

Product standards apply to all documents produced in the course of the software development.
Documents should have a consistent appearance and, documents of the same class should have a
consistent structure. Document standards are project-specific but should be based on more general
organizational standards.

38
My notes

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

39
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
________

40