NC: Information Technology

- System Development -
48872 - NQF Level 5

Module 5
Formative Assessments
Unit Standard – 115358
Unit Standard – 115392
Unit Standard – 115384
QUESTION 1

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p1 of 18
 Apply information gathering techniques for computer system
development (115358) 
SPECIFIC OUTCOME 1:

Design and conduct an interview for gathering information for computer

system development.
ASSESEMENT CRITERIA
 The interviewee reports that he or she has understood the interview objectives.
 The interviewee reports that he or she has understood the interview questions.
 The interview provides answers that meet interview objectives.
 The presentation of the interview is appropriate to the interviewee.

Activity Practical SO AC

1.1 Why should you conduct interviews? (2)

1 1.2 Explain when interviews are not the best option (2) 1 1-4

1.3 Design an interviewee report (10)

The best way to communicate your ideas accurately and thoroughly with the person from whom
you obtain information is to use an interview. You have power over the order of questions and can
ensure that all the questions are answered.
You will also benefit from the interview's spontaneity. Interviewees are not always glamorous to
go away and reflect or to some extent even edit their replies. You can find that the respondents
blurring items they never agree to in a questionnaire on paper.
Interviews are sometimes are not even appropriate or efficient because large phone interviews
can be time consuming and expensive.
Interviews are the best option or suitable if the respondents are not willing to cooperate.

Self-check

OUTCOME Yes No I Need help

 The interviewee reports that he or she has understood the X
interview objectives.
 The interviewee reports that he or she has understood the X
interview questions.

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p2 of 18
 SPECIFIC OUTCOME 2 :
Design and perform an analysis of the results from a questionnaire for
gathering information.
ASSESEMENT CRITERIA
 The respondents report that they understand the questionnaire objectives.
 The respondents report that they understand the questions.
 The questionnaire responses provide answers that meet questionnaire objectives.
 The presentation of the questionnaire is appropriate to the target population.
 A summary of questionnaire responses, and a comparison with expected responses, allows
summary statements to be made about the population sample.

Activity Practical SO AC

1.1 What are the Advantages and Disadvantages of a questionnaire

(6)
2 1.2 List Two types of questionnaires (2) 2 1-5
1.3 Design a questionnaires with questionnaire responses
that provide answers that meet questionnaire objectives
(10)
Advantages
 Economy - Expense and time involved in training interviewers and sending them to
interview are reduced by using questionnaires.
 Uniformity of questions - Each respondent receives the same set of questions phrased in
exactly the same way. Questionnaires may, therefore, yield data more comparable than
information obtained through an interview.
 Standardization - If the questions are highly structured and the conditions under which
they are answered are controlled, then the questionnaire could become standardized.
Disadvantages
 Respondent’s motivation is difficult to assess, affecting the validity of response.
 Unless a random sampling of returns is obtained, those returned completed may
represent biased samples.
1. Closed or restricted form - calls for a "yes" or "no" answer, short response, or item
checking; is fairly easy to interpret, tabulate, and summarize.
2. Open or unrestricted form - calls for free response from the respondent; allows for
greater depth of response; is difficult to interpret, tabulate, and summarize.
This questionnaire is designed for students, investigating about their nutrition as students or
learners.

Questionnaire
Code-_______________
Card no-_______________
Region-_______________
Municipality-_____________
District area-______________
Survey area-_______________

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p3 of 18
 Parent’s detail
1. (Please answer the following questions)
Surname
Name
Date of birth
Gender
Population Group

2. What is your relationship to the learner?

Mother

father

Gardian parent

3. What is your level of education?

Primary School

Secondary School

Tertiary Education

Student’s personal details

4. (Please answer the following questions)

Surname
Name
Date-of-birth
Gender
Population group
What grade are you in?
Name of school?

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p4 of 18
 Student’s nutrition details
5. How often do you eat fruit per day?
• Less than 1 a day
• 1 per day
• 2 per day
• 3 per day
• More than 3 per day

6. How often do you drink milk a day?

• Never
• 1 glass of milk a day
• 2 glasses of milk a day
• 3 glasses of milk a day
• More than 3 glasses of milk a day

7. How often do you eat cereal before you go to school?

• I do not eat cereal
• Sometimes
• Always (everyday

8. Do you carry lunch box to school?

If no why? ……………………………………………………………………….

9. Does your school provide feeding scheme?

If yes, please answer the following questions

10. How many times do you get food?

• Once a day
• Twice a day
• Other

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p5 of 18
 SPECIFIC OUTCOME 3:
Gather data from documents for computer system development.
ASSESEMENT CRITERIA
 Research notes identify data that meet the specified information requirements using an
industry recommended format.
 Research notes identify the characteristics of the data and the relationships between data
items.
 Research notes identifying data items facilitate access to those data items.

Activity Question SO AC

1.1 What is the importance of documents analyst (2)

3 1.2 What is Coding data (2) 3 1-3
1.3 What is the importance of Organizing data (2)
• The importance of documents analyst is that it can find information, such as problem with
existing systems, opportunities to meet new needs if only certain information or information
processing were available, organizational direction that can influence information system
requirements, and the reason why current systems are designed as they are.
• The importance of documents analysts is that when analysing those official documentations,
analysts should pay attention to the difference between the systems described on the official
documentations and the practical systems in real world.
It refers to translating data, particularly qualitative data that isn’t expressed in numbers, into a
form that allows it to be processed by a specific software program or subjected to statistical
analysis.
• How you do this will depend on your research design and your evaluation questions.
• You might group observations by the dependent variable indicator of success they relate to,
by individuals or groups of participants, by time, by activity.
• Organizing data in ways that make them easier to work with.

Self-check

OUTCOME Yes No I Need help

 Research notes identify data that meet the specified
information requirements using an industry X
recommended format.
 Research notes identify the characteristics of the data
and the relationships between data items. X
 Research notes identifying data items facilitate access to X
those data items.

SPECIFIC OUTCOME 4:

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p6 of 18
 Observe a person's behaviour for gathering information for computer
system development
ASSESEMENT CRITERIA
 A record of the behaviour identifies events that meet the specified information requirements,
and outlines those events.
 A report about the observation compares the outcome of the observation with the
observation objectives.

Activity Question SO AC

1.1 Define ABC data collection (2)

4 1.2 Give an example of ABC data collection (10) 4 1-2
1.3 Comment on the use of ABC data collection tool (2)
1. Is an assessment tool used to gather information that should evolve into a positive
behavior support plan
ABC refers to:
 Antecedent- the events, action, or circumstances that occur before a behavior.
 Behavior- The behavior.
 Consequences- The action or response that follows the behavior.
Antecedent Behaviour Consequence

Joe screams, "NO!" and

Parent asks Joe to stop Parent tells Joe to leave the
refuses to leave the
playing on the computer. computer again.
computer.

Parent starts counting to 10

Parent tells Joe to leave the
Joe again refuses to leave. as a warning to get off the
computer.
computer.

Parent starts counting to 10 Parent finishes counting to

Joe does not move from the
as a warning to get off the 10 and again warns him to
computer station.
computer. get off the computer.

Parent finishes counting to Parent threatens that Joe

Joe stays at the computer
10 and again warns him to lose computer privileges in
and refuses to leave.
get off the computer. the future.

Parent threatens that the The parent count to 10

Joe ignores and continues
Joe will lose computer again and again threatens
working on the computer.
privileges in the future. future computer use.

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p7 of 18
 The parent counts to 10
Joe ignores and continues The parent becomes angry
again and again threatens
computer use. and leaves the room.
future computer use

1. ABC data collection can be used for all individuals with behavior issues at home and in school, not
just individuals on the autism spectrum.

2. Once accurate and sufficient data is collected; placements, planning, modifications, instruction,
and feedback are easier, more valid, and effective.

QUESTION 2

Test a computer program against a given specification (115384)

SPECIFIC OUTCOME 1:

Test a computer program against given specifications according to test

plans.
ASSESEMENT CRITERIA
 The testing executes operational steps identified in the test plan.
 The testing uses input data as specified in the test plan.
 The testing outlines deviations from the test plan, with explanations.
 The testing follows the standards and procedures specified in the test plan for testing and re-
testing.

Activity Practical SO AC

1.1 In groups discusses how to Test a computer program against

1 given specifications according to test plans. (10) 1 1-4

 Black box testing - functional, data driven, I/O testing.

 White box testing - logic-driven, structural, glass box testing.
 Screen layout, Forms design, Data controls, Input validation, Ranges.
 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

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p8 of 18
 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.

SPECIFIC OUTCOME 2 :
Record the results from testing a computer program.
ASSESEMENT CRITERIA
 The records are provided for all tests executed.
 The records identify variations from expected test results and gives reason where available.
 The recorded results are reproduced if the tests are repeated under the same conditions.
 The recorded results are recorded in a way that allows the results to be reviewed..

Activity Practical SO AC

2
1.4 In pairs outline how to Record the results from testing a 2 1-4
computer program (10)
Test log, Test incident report, Error flags, Schedule of tests.
 Recording test execution results is very important part of testing, whenever test execution
cycle is complete, tester should make a complete test results report which includes the
Test Pass/Fail status of the test cycle.

 If manual testing is done then the test pass/fail result should be captured in an excel
sheet and if automation testing is done using automation tool then the HTML or XML
reports should be provided to stakeholders as test deliverable.

Testing results include the following:

 Test plan status
 Test documentation status
 Test execution status(defect status)

 Test Plan: It is enough to communicate with the rest of the project teams, when a test
plan is created or when a major change is made to it.

 Test documentation– Let all the teams know when the designing of the tests, data
gathering and other activities have begun and also when they are finished. This report
will not only let them know about the progress of the task but also signal the teams that
need to review and provide signoff on the artefacts, that they are up next.

Test execution– Execution is the phase of a project when the testing team is the primary focus –
positively and negatively – we are both the heroes and the villains.
A typical day during a test cycle is not done, unless the daily status report is sent out. In some

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p9 of 18
 teams, they could agree on a weekly report, but having it sent daily is the norm.
SPECIFIC OUTCOME 3:
Review the testing process for a computer program against
organisation policy and procedures.
ASSESEMENT CRITERIA
 The review allows improvements to be made to the application testing process.
 The review follows organisation policy and procedures.

Activity Question SO AC

3 1.4 In groups describe Different types of reviews (10) 3 1-2

 Pair programming is a type of code review where two persons develop code together at
the same workstation.
 Technical review is a form of peer review in which a team of qualified personnel examines
the suitability of the software product for its intended use and identifies discrepancies
from specifications and standards.
 Inspection is a very formal type of peer review where the reviewers are following a well-
defined process to find defects.
 Walk-through is a form of peer review where the author leads members of the
development team and other interested parties through a software product and the
participants ask questions and make comments about defects.
 Code review is systematic examination often as peer review of computer source code.

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p10 of 18
Question 3

Principles of creating computer software by developing a

complete programme to meet given business specifications
(115392)
Activity Practical SO AC

1.1 In pairs Explain Why Should Technical Writers be Involved

with Software Requirements Specifications?. (10)
1 1 1-3
1.2 What Kind of Information Should an SRS Include?

 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 first and–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 not only to the specification and documentation development.
 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, involved early and often in the process, can become an information
resource throughout the process, rather than an information gathered at the end of the
process. 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.
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:
 Safety
 Reliability
 Security/Privacy
 Quality
 Constraints and Limitations
 Interfaces
 Functional Capabilities
 Performance Levels

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p11 of 18
  Data Structures
 Elements

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p12 of 18
 Activity Practical SO AC

1.5 In pairs demonstrate understanding of how to establish

Business Rules for Contingencies and Responsibilities and
2 2 1-4
Establish a Requirements Traceability Matrix (10)

1.6 In small groups discuss about Design considerations

• 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.
• 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.
There are many aspects to consider in the design of a piece of software. The importance of each
should reflect the goals that 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.
• 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.

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p13 of 18
 Activity Question SO AC

3
1.5 In small groups discuss how Create a computer program that 3 1-2
implements the design. (5)
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:
• 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.
• 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.

• 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.
• Scalability - The software adapts well to increasing data or number of users.

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p14 of 18
 Activity Question SO AC

1.1 In small groups demonstrate understanding of how to Test a

4 4 1-2
computer program. (10)
A computer program can be tested in the following ways either Statically or Dynamically
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.
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.

Activity Question SO AC

1.1 In pairs describe how to implement the program to meet

5 5 1-2
business requirements. (5)
• 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

Activity Question SO AC

1.1 Write short notes on how to Document the program according

6 6 1-2
to industry standards.. (5)
Computer program documentation is transcribed script that escorts computer program or
software. It also 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:
• Requirements - Statements that identify attributes capabilities, characteristics, or qualities of
a system. This is the foundation for what shall be or has been implemented.
• Architecture/Design - Overview of software. Includes relations to an environment and
construction principles to be used in design of software components.

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p15 of 18
 • Technical - Documentation of code, algorithms, interfaces, and APIs.
• End user - Manuals for the end-user, system administrators and support staff.
• Marketing - How to market the product and analysis of the market demand.

SELF-ASSESSMENT

The learner must make use of the following self-evaluation checklist to rate himself against the
learning outcomes of this particular training module in establishing the level of mastery of the
information.

1. Not able to comply

2. Reasonable compliance (Not acceptable for final evaluation)

3. Able to comply fully

LEARNING OUTCOMES 1 2 3
1 Apply information gathering techniques for computer X
system development

2 Apply principles of creating computer software by

developing a complete programme to meet given X
business specifications

3 Test a computer program against a given specification X

____________________________________________ ________________________________

Learner Signature Date

____________________________________________ ________________________________

Facilitators’ Signature Date

Revision: 1.0 Date: 16 June 2018

Module 5 – Formative Assessment p16 of 18
ASSESSMENT FEEDBACK REPORT

FACILITATOR FEEDBACK & REMARKS

The Learner Is found Competent in the Unit Standards for this module.

ASSESSMENT JUDGEMENT

Learner’s Total Mark: Requirements met  Requirements not met

Action/s required: None

By when: N/A

LEARNER FEEDBACK & COMMENTS

I, …………………………………., declare that I am satisfied that the feedback given to me by the

Facilitator was relevant, sufficient and done in a constructive manner. I accept the assessment
judgment and have no further questions relating to this particular assessment event.

DECLARATION BY THE FACILITATOR

I Robert Brady, (Facilitator), hereby certify that I have examined the learner workbook and I am
satisfied with the evidence provided by the learner.

DECLARATION BY LEARNER

I, …………………………………………………………………….declare that I am satisfied that the feedback given to me

©ProjectcodeX 2018 Revision: 1.0 Date: 28 April 2018

Module 5 – Formative Assessment p17 of 18
 by the Facilitator was relevant, sufficient and done in a constructive manner. I accept the assessment
judgment and have no further questions relating to this particular assessment event.

………………………….

Learner Date Facilitator Date

DECLARATION BY THE ASSESSOR

I Robert Brady, (Assessor), hereby certify that I have examined the learner workbook and I am satisfied
with the Facilitator Judgment of this assessment.

Assessor Date Moderator Date

©ProjectcodeX 2018 Revision: 1.0 Date: 28 April 2018

Module 5 – Formative Assessment p18 of 18