SAQA - 14909 - Summative Memorandum
SAQA - 14909 - Summative Memorandum
1|Page
FULL NAME &
SURNAME
ID NUMBER:
NAME OF ASSESSOR
DATE OF ASSESSMENT
VENUE
SKILLS
2|Page
ASSESSMENT PACK
Surname:
Date:
Company: Site:
ID
Surname:
Date:
Assessor no:
Provider no: Site:
ID
3|Page
Name:
Surname:
Date:
Moderator no:
Provider no: Site:
ID
Results:
4|Page
1. INSTRUCTIONS TO ASSESSOR
5|Page
Introduction:
This assessment guide has been designed as a generic assessment guide and is
intended for use by the accredited NATIONAL CERTIFICATE: COMMUNITY
DEVELOPMENT Training Providers.
2. Assessment Process
General
Use the assessment guide and your latest company policies and standard
operating procedures to assess the evidence received from the learner.
Use the section: Addition Comments/Questions to note down any further
comments or questions on the evidence assessed.
Use the model answers as a guideline to assess the learner’s answers to the
assessment questionnaire.
The learner can complete the assessment questionnaire orally. In this case,
agree a date, time and venue.
Provide the learner with a feedback within 10 working days of receiving the
evidence.
6|Page
Step 1 - Planning for the Assessment
Review this assessment guide to:
Ensure that you understand all the requirements of the assessment in
terms of evidence required to prove competence.
Identify and prepare the learner for the assessment by:
o Completing the Assessment Plan with the learner to discuss and
agree the details regarding the assessment.
o Completing the Assessment Preparation Checklist and getting the
learner to sign.
Ensure that you have familiarized yourself with the following:
o The various patrolling functions and standard operating procedures
within the company.
7|Page
Allow the learner time to provide you with feedback relevant to the
process.
Record the learner’s feedback in the guide and ensure that it is given to
the person responsible for the quality assurance of assessment tools.
Ensure that the learner co-signs the assessment guide to indicate
agreement with the feedback.
♦ Assessment Plan
♦ Assessment Preparation Checklist
♦ Assessment Policy (including Appeals)
♦ Evidence Matrix
♦ Assessment Instruments
Step 2: Conducting the Assessment
♦ Assessor Guide
♦ Learner’s workbook
♦ Summative assessment pack
Step 3: After the Assessment
♦ Assessment Comments
♦ Feedback Report
4. Specific Instructions
Please note that Part 3 Assessment Instruments are not included in this guide
and are to be included by the assessor on an individual basis.
The actual summative assessments need to be completed and signed off by both
learner and assessor. The assessor will take control of the completed assessment
instruments and will file them under the tab for Assessment Evidence.
8|Page
The normal appeal procedure prescribed by SETA and described by the
provider’s Quality Management System will be followed.
9|Page
10 | P a g e
ASSESSMENT PLAN
ASSESSMENT DETAILS
TIME OF ASSESSMENT
Start: End:
VENUE Contact
person
LANGUAGE MEDIUM
METHOD OF
METHOD OF ASSESSMENT (please tick off the one to be used)
11 | P a g e
PRE-ASSESSMENT MEETING CHECKLIST
12 | P a g e
A copy of the unit standard(s) involved has been given to me prior to this
meeting. I know I will be assessed against the criteria, which have been set to
the applicable unit standards. The criteria have been discussed with me, and the
procedures and purpose of the assessment has been clearly explained to me.
I am well aware of the venue, date and time that I will be assessed. I consider
the period of time given to me to prepare myself for the assessment to be fair.
I understand clearly that I have the right to appeal against any decision made by
the assessor during the assessment of the evidence provided by me, and that I
have free access to the appeals procedures attached to this assessment pack. I
understand that I have the right to be accompanied by another person during all
procedures, and that I have free access to the Training Division of SBV’S Health
and Safety Procedures- filed at the offices.
13 | P a g e
14 | P a g e
Assessment Instruments
TAKE NOTE
The assessment instruments included in this assessment pack are all
summative assessment instruments and are to be read in conjunction
with the formative assessment instruments contained in the learner
workbook. Both formative (workbook) and summative assessments are
to be retained as part of the learner’s portfolio of evidence.
A number of the assessment instruments contained in this assessment
are workplace knowledge based questions. This means that you will
arrange with the learner, a time that is suitable, during which the
learner will complete each questions.
Activity Mark
Describe and explain the basic principles of an
1 7
object.
Objects
Objects are the physical and conceptual things we find in the universe around
us. Hardware, software, documents, human beings, and even concepts are all
examples of objects. For purposes of modeling his or her company, a chief
executive officer could view employees, buildings, divisions, documents, and
benefits packages as objects. An automotive engineer would see tires, doors,
engines, top speed, and the current fuel level as objects. Atoms, molecules,
volumes, and temperatures would all be objects a chemist might consider in
creating an object-oriented simulation of a chemical reaction. Finally, a software
engineer would consider stacks, queues, windows, and check boxes as objects.
Objects are thought of as having state. The state of an object is the condition of
the object, or a set of circumstances describing the object. It is not uncommon to
hear people talk about the "state information" associated with a particular
object. For example, the state of a bank account object would include the current
balance, the state of a clock object would be the current time, the state of an
electric light bulb would be "on" or "off." For complex objects like a human being
or an automobile, a complete description of the state might be very complex.
Fortunately, when we use objects to model real world or imagined situations, we
15 | P a g e
typically restrict the possible states of the objects to only those that are relevant
to our models. We also think of the state of an object as something that is
internal to an object. For example, if we place a message in a mailbox, the
(internal) state of the mailbox object is changed, whereas the (internal) state of
the message object remains unchanged. Sometimes people think of objects as
being strictly static. That is, the state of an object will not change unless
something outside of the object requests the object to change its state. Indeed,
many objects are passive (static). A list of names does not spontaneously add
new names to itself, nor would we expect it to spontaneously delete names from
itself. However, it is possible for some objects to change their own state. If an
object is capable of spontaneously changing its own state, we refer to it as an
"object with life." (Objects with life are sometimes also called "active objects"
or "actors.") Clocks and timers are common examples of objects with life. If we
were modeling a business process, we would recognize that salespeople and
customers were also objects with life.
Activity Mark
A class is the set of all items created using a specific pattern. Said another way,
the class is the set of all instances of that pattern.
16 | P a g e
Activity Mark
Inheritance can be defined as the process whereby one object acquires (gets,
receives) characteristics from one or more other objects. Some object-oriented
systems permit only single inheritance, a situation in which a specialization
may only acquire characteristics from a single generalization. Many object-
oriented systems, however, allow for multiple inheritances, a situation in
which a specialization may acquire characteristics from two or more
corresponding generalizations.
Our previous discussion of the bank
account, checking account, and savings
account was an example of single
inheritance. A telescope and a television
set are both specializations of "device that
enables one to see things far away." A
television set is also a kind of "electronic
device." You might say that a television
set acquires characteristics from two
different generalizations, "device that
enables one to see things far away" and
"electronic device." Therefore, a television
set is a product of multiple inheritance.
Inheritance
One important characteristic of object-oriented languages is
inheritance. Inheritance refers to the capability of defining a new class of objects
that inherits from a parent class. New data elements and methods can be added
to the new class, but the data elements and methods of the parent class are
available for objects in the new class without rewriting their declarations.
For example, Java uses the following syntax for inheritance:
public class B extends A {
declarations for new members
}
17 | P a g e
Objects in class B will have all members that are defined for objects in class A. In
addition, they have the new members defined in the declaration of class B.
The extends keyword signals that class B inherits from class A. We also say that
B is a subclass of A and that A is the parent class of B.
In some languages, Java for example, the programmer has some control over
which members are inherited. In Java, a member is defined with a keyword
indicating its level of accessibility. The keyword private indicates that the
member is not inherited by subclasses. This capability is not often used.
Activity Mark
Inheritance can be defined as the process whereby one object acquires (gets,
receives) characteristics from one or more other objects. Some object-oriented
systems permit only single inheritance, a situation in which a specialization
may only acquire characteristics from a single generalization. Many object-
oriented systems, however, allow for multiple inheritances, a situation in
which a specialization may acquire characteristics from two or more
corresponding generalizations.
Our previous discussion of the bank
account, checking account, and savings
account was an example of single
inheritance. A telescope and a television
set are both specializations of "device that
enables one to see things far away." A
television set is also a kind of "electronic
device." You might say that a television
set acquires characteristics from two
different generalizations, "device that
enables one to see things far away" and
"electronic device." Therefore, a television
set is a product of multiple inheritance.
Inheritance
18 | P a g e
One important characteristic of object-oriented languages is
inheritance. Inheritance refers to the capability of defining a new class of objects
that inherits from a parent class. New data elements and methods can be added
to the new class, but the data elements and methods of the parent class are
available for objects in the new class without rewriting their declarations.
For example, Java uses the following syntax for inheritance:
public class B extends A {
declarations for new members
}
Objects in class B will have all members that are defined for objects in class A. In
addition, they have the new members defined in the declaration of class B.
The extends keyword signals that class B inherits from class A. We also say that
B is a subclass of A and that A is the parent class of B.
In some languages, Java for example, the programmer has some control over
which members are inherited. In Java, a member is defined with a keyword
indicating its level of accessibility. The keyword private indicates that the
member is not inherited by subclasses. This capability is not often used.
Activity Mark
A Real-World Example
Okay, that's enough theory. We're going to put both types of programming to the
test with a real-world example. Let's say that you are working for a vehicle parts
manufacturer that needs to update it's online inventory system. Your boss tells
you to program two similar but separate forms for a website, one form that
processes information about cars and one that does the same for trucks.
For cars, we will need to record the following information:
Color
Engine Size
Transmission Type
Number of doors
For trucks, the information will be similar, but slightly different. We need:
Color
Engine Size
19 | P a g e
Transmission Type
Cab Size
Towing Capacity
In procedural programming, you would write the code first to process the car
form and then the code for the truck form. With object-oriented programming,
you would write a base class called vehicle that would record the common
characteristics what we need from both trucks and cars. In this case, the vehicle
class will record:
Color
Engine Size
Transmission Type
We'll make each one of those characteristics into a separate method. The color
method, for example, could take the color of the vehicle as a parameter and do
something with it, like storing it in a database. Next, we will create two more
classes: truck and car, both of which will inherit all of the methods of the vehicle
class and extend it with methods that are unique to them. The car class will have
a method called number Of Doors and the truck class will have the methods cab
Size and towing Capacity. Okay, so let's assume that we have a working example
for both procedural and OO programming. Now, let's run through a few scenarios
that we could come across in a normal working environment. You know the type
of scenario because it always begins with the thought: I really wish my boss
didn't send this in an email request at 4pm on a Friday afternoon.
Scenario 1
Suppose that we suddenly need to add a bus form, that records the following
information:
Color
Engine Size
Transmission Type
Number of passengers
Procedural: We need to recreate the entire form, repeating the code for Color,
Engine Size, and Transmission Type.
OOP: We simply extend the vehicle class with a bus class and add the method,
number Of Passengers.
Scenario 2
Instead of storing color in a database like we previously did, for some strange
reason our client wants the color emailed to him.
20 | P a g e
Procedural: We change three different forms: cars, trucks, and buses to email the
color to the client rather than storing it in the database.
OOP: We change the color method in the vehicle class and because the car,
truck, and bus classes all extend (or inherit from, to put it another way) the
vehicle class, they are automatically updated.
Scenario 3
We want to move from a generic car to specific makes, for example: Nissan and
Mazda.
Procedural: We create a new form for each make, repeating all of the code for
generic car information and adding the code specific to each make.
OOP: We extend the car class with a nissan class and a mazda class and add
methods for each set of unique information for that car make.
Scenario 4
We found a bug in the transmission type area of our form and need to fix it.
Procedural: We open and update each form.
OOP: We fix the transmissionType method in the vehicle class and the change
perpetuates in every class that inherits from it.
ASSESSOR REPORT
ASSIGNMENT
CANDIDATE NAME:
DATE OF FEEDBACK:
STRENGTHS:
WEAKNESSES:
21 | P a g e
LEARNER COMMENTS:
DEVELOPMENT PLAN:
CANDIDATE DECLARATION:
____________________ ____________________
22 | P a g e