0% found this document useful (0 votes)

877 views

Module 3 - Computer Programming Development - Problem Solving

This document is a learner guide for a module on computer programming development and problem solving. It provides information on four unit standards, including the specific outcomes and assessment criteria for applying principles of designing computer system inputs and outputs. The guide outlines the purpose of the module, learning assumed, equipment needed, resources, venue details, and assessments. It also provides an explanation of input design principles and specific outcome 1 for assessing explanations of various input and output types, structures, user involvement, and graphical vs text-based functions.

Uploaded by

Bukho Tsengiwe

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

877 views

Module 3 - Computer Programming Development - Problem Solving

Uploaded by

Bukho Tsengiwe

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

You are on page 1/ 77

LEARNER GUIDE

Module 3
Computer programming Development &
Problem Solving

Unit Standard 115365

Unit Standard 115362
Unit Standard 115388
Unit Standard 115359

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p1 of 77
Learner Information:
Details Please Complete this Section
Name & Surname:
Organization:
Unit/Dept:
Facilitator Name:
Date Started:
Date of Completion:

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p2 of 77
Apply the principles of designing computer
system inputs and outputs(US115365)
Unit Std # 115359
NQF Level 4
Notional hours 20
Credit(s) 2
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

Table of contents

Specific Outcome 1 : Explain the principles of computer input and output design.
 The explanation identifies the various types of inputs and outputs.
 The explanation distinguishes between appearance and the underlying structure and
processes.
 The explanation identifies the purpose of user involvement in creating the designs.
 The explanation compares online computer functions with manual forms and offline data
entry.
 The explanation includes a discussion of input and output that compares graphical input and
output functions with text based input and output functions.
Specific Outcome 2 : Design computer input and output functions
 The design meets the specification for the function.
 The design can be implemented in the specified computer environment.
 The design conforms to an industry recommended format for the function.
Specific Outcome 3 : Create computer input and output functions
 The creation ensures that the function format corresponds to the design.
 The creation ensures that the function behaviour corresponds to the design.

NOTIONAL HOURS BREAKDOWN

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p3 of 77
The candidate undertaking this unit standard is best advised to at least spend one hundred hours of
study time on this learning programme. Below is a table which demonstrates how these one
hundred hours could be spread:

TIMEFRAME

Total Notional Hours Contact Time Non contact-

Self-Study/Assessment
Credits (2) x 10 = 20 6HRS 14HRS
1. Learning Programme REFER TO COVER PAGE
Name:
2. SAQA Qualification/Unit REFER TO COVER PAGE
Standard Title:
3. Qualification/ 4 SAQA ID 5 NQF 4 6 Credits 2
Unit Standard . Number . Level .
7. PURPOSE for offering REFER TO NEXT PAGE
this programme to your
learners:

8. TARGET AUDIENCE for REFER TO NEXT PAGE

this specific
programme:

9. Entry/Admission REFER TO NEXT PAGE

Requirements:

10 Timeframe for Training: Theory content –Role play, Simulation, Group work, Pair work =
. (Total 6hrs.
Hours/Days/Weeks) Non contact session- self-study, assignment, practise guided by
coach or mentor, formative assessment and summative
assessment =14 hrs.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p4 of 77
The Learner guide

At the end of this unit standard you will be able to Apply the principles of designing
computer system inputs and outputs

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

 Explain the principles of computer input and output design

 Design computer input and output functions
 Create computer input and output functions

Specific outcome:
 Explain the principles of computer input and output design
 Design computer input and output functions
 Create computer input and output functions

Learning assumed to be in place:

 Demonstrate an understanding of fundamental mathematics (at least NQF level 3)

 Demonstrate PC competency skills (All End User Computing unit standards)

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.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p5 of 77
Resources (selective resources might be used, depending on the facilitator and venue
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.
 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

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p6 of 77
SPECIFIC OUTCOME 1:

Explain the principles of computer input and output design.

ASSESEMENT CRITERIA
 The explanation identifies the various types of inputs and outputs.
 The explanation distinguishes between appearance and the underlying structure and
processes.
 The explanation identifies the purpose of user involvement in creating the designs.
 The explanation compares online computer functions with manual forms and offline data
entry.
 The explanation includes a discussion of input and output that compares graphical input and
output functions with text based input and output functions.

1.1 Input design

Input design facilitates the entry of data into the computer system. Input design involves the
selection of the best strategy for getting data into the computer system at the right time and as
accurately as possible. This is because the most difficult aspect of input design in accuracy .The use
of well-defined documents can encourage users to record data accurately without omission.

For example, if a customer's telephone number is a needed input data, the sales order form should
have a specific line that is clearly labelled "customer telephone number". Having several lines
labelled "customer information" would be less effective. This is because sometimes only the name
and address would be filled in leaving out the telephone number.

Input design must capture all the data that the system needs, without introducing any errors. Input
errors can be greatly reduced when inputting directly by using appropriate forms for data capture
and well-designed computer screen layout.

1.1.1 During design of input, the analyst should decide on the following details:

 What data to input

 What medium to use

 How data should be arranged

 How data should be coded i.e. data representation conventions

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p7 of 77
 The dialogue to guide users in providing input i.e. informative messages that should be provided
when the user is entering data. Like saying, "It is required. Don't leave it blank."

 Data items and transactions needing validation to detect errors

 Methods for performing input validation and steps to follow when errors occur

The design decisions for handling input specify how data are accepted for computer processing. The
design of inputs also includes specifying the means by which end-users and system operators direct
the system in performing actions.

Output refers to the results and information that are generated by the system. In many cases,
output is the main reason for developing the system and the basis on which the usefulness of the
system is evaluated. Most end-users will not actually operate the information system or enter data
through workstations, but they will use the output from the system.

1.1.2 While designing the output of system, the following factors should be considered:

 Determine what information to present

 Decide on the mode of output, i.e. whether to display, print, or "speak" the information and
select the output medium

 Arrange the presentation of information in an acceptable format

 Decide how to distribute the output to intended recipients

These activities require specific decisions, such as whether to use pre-printed forms when preparing
reports and documents, how many lines to plan on a printed page, or whether to use graphics and
colour. The output design is specified on layout forms, sheets that describe the location
characteristics (such as length and type), and format of the column heading, etc.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p8 of 77
Typical Physical DFD with Input and Output Functions

Outputs are data going out from the system to the users. The users may be an external entity, or
maybe internal (boundary between computer-system and manual system). You have to be careful
when determining the output data flow. Notice that dataflow – inquiry form – is a form that induces
the input from the user (Customer) that means although the dataflow goes out of the system
boundary, that form is an input form and not an output.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p9 of 77
SPECIFIC OUTCOME 2 :
Design computer input and output functions.
ASSESEMENT CRITERIA
 The design meets the specification for the function.
 The design can be implemented in the specified computer environment.
 The design conforms to an industry recommended format for the function.

2.1 Design computer input and output functions

2.1.1 Designing computer input functions

Below is a sample input form

2.1.2 Input methods

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p10 of 77
 Batch input is the oldest and most traditional input method. Source documents or forms are
collected and then periodically forwarded to data entry operators, who key the data using a
data entry device that translates the data into a machine-readable format. The most
common medium for batch input data are Key-to-disk (KTD) and key-to-tape (KTT)
workstations that transcribe data to magnetic disks and magnetic tape, respectively.

 On-line input is the capture of data at its point of origin in the business and the direct
inputting of that data to the computer, preferably as soon as possible after the data
originates. The system user directly enters the data when or soon after that data originates.
No data entry clerks are needed! There is no need to record data onto a medium (paper and
such) that is later input to the computer; this input is direct! If data is entered incorrectly,
the computer's edit program detects the error and immediately requests that the operator
make a correction.

2.1.3 Trends in Automatic Data Collection Technology

Biometric ADC technology is based on unique human characteristics or traits. For example, it is
known that every individual can be identified by their own unique fingerprint, voice pattern, or
pattern of certain veins (retina or wrist).
This technology is particularly popular for systems that require security access.

Electromagnetic identification technology is becoming very popular in applications that involve

tracking physical objects are out of sight and on the move. For example, electromagnetic ADC is
being used for public transportation tracking and control, tracking manufactured products, and
tracking animals to name a few.
There are over one billion magnetic stripe cards in use today! They have found their way into a
number of business applications such as, credit card transactions, building security access control,
and employee attendance tracking.

Point-of-sale terminals in retail and grocery stores frequently include bar-code and optical-character
readers. Bar codes eliminate the need for keying data, either by data entry clerks or end-users.

Smart card applications are particularly promising in the area of health records where a person’s
blood type, vaccinations, and other past medical history can be made readily available. Other uses

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p11 of 77
may include such applications as passport, financial information for point-of-sale transactions, pay-
television, etc.

2.1.4 System User Issues for Input Design

Because inputs originate with system users, human factors play a significant role in input design.
Inputs should be as simple as possible and designed to reduce the possibility of incorrect data being
entered.

The volume of data to be input should be minimized. The more data that is input, the greater the
potential number of input errors and the longer it takes to input that data. Thus, numerous
considerations should be given to the data that is captured for input.

Do not enter constant data. For instance, when deciding what elements to include in a SALES ORDER
input, we need PART NUMBERs for all parts ordered. However, do we need to input PART
DESCRIPTIONs for those parts? PART DESCRIPTION is probably stored in a database table. If we input
PART NUMBER, we can look up PART DESCRIPTION. Permanent (or semi-permanent) data should be
stored in the database. Of course, inputs for maintaining those database tables must be designed.

If you input QUANTITY ORDERED and UNIT PRICE, you don't need to input EXTENDED PRICE, which is
equal to QUANTITY ORDERED times PRICE. Another example is incorporating FEDERAL TAX
WITHHOLDING data in tables (arrays) instead of keying in that data every time.

2.2 Designing computer output functions

Output-design Objectives are to:
• Serve the intended purpose
• Deliver the right quantity of output
• Deliver it to the right place
• Provide output on time
• Choose the right method

2.2.1 Types of Outputs

• Internal outputs stay inside the system to support the system's users and managers

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p12 of 77
• External outputs leave the system to trigger actions on the part of their recipients or
confirm actions to their recipients
– Turnaround outputs are those which are typically implemented as a report
eventually re-enters the system as an input

2.2.2 Output Media

• Paper
• Screen
• Microfilm/Microfiche
• Video/Audio
• CDROM, DVD
• Other electronic media

2.2.3 System User Issues for Output Design

• Be aware of output bias.
• Computer outputs should be simple to read and interpret.
• The timing of computer outputs is important.
• The distribution of computer outputs must be sufficient to assist all relevant system users.
• The computer outputs must be acceptable to the system users who will receive them ->
Need for training.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p13 of 77
The figure above is a prototype of a typical report that may result from the previous customization
screen. Examine the content and appearance of the tabular report. We draw your attention to the
following:
• Icons are included for activating commands for allowing the user to “zoom” the
report to 100%, fit the report to window size, and to adjust the page width. These
features take into consideration the user and often times difficult task of viewing a
report on a display screen.
• Buttons are included for activating commands were included to permit the user to
easily move from one report page to another (Notice that the window’s scroll bar is
active allowing the user to scroll through the report.)
• A Printer Icon is provided as a visual clue to suggest that the user can request a
hardcopy of the report.
• The user is given the opportunity to save the report as a file or to load a different
report.
• Another example of output design is the form below.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p14 of 77
Revision: 1.0 Date: 16 June 2018
M3 Computer Programming Development & Problem Solving - Learner Guide p15 of 77
User issues are so important here (and also in the Input design and User interface design):
• Users will use the system mostly; and therefore, they determine the success or
failure of the system.
• Users don’t see the databases or how the program is working; yet output, input,
interfaces (navigation) affects their use of the system and those are the ones the
users see.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p16 of 77
SPECIFIC OUTCOME 3:
Create computer input and output functions.
ASSESEMENT CRITERIA
 The creation ensures that the function format corresponds to the design.
 The creation ensures that the function behaviour corresponds to the design.

3.1 How to Create Computer Inputs and output functions.

• Step 1: Review Input and output Requirements
• Step 2: Select the GUI Controls
• Step 3: Prototype the Input Screen
• Step 4: If Necessary, Design or Prototype the Source Document

Developing graphical user interfaces for new applications involves two stages for input design. In the
first stage, the designer focuses their efforts on correctly identifying the confirming content of the
input. And, consistent with the repository-based programming emphasis discussed earlier, to
identify properties or characteristics for that input data.

The second stage deals with the overall appearance or look and feel of the input. This stage is
typically deferred until the designer has given consideration to the overall appearance and working
of the entire application’s interface.

Given an input to be designed, we should review the required attributes. The basic content of these
inputs should have been recorded in the project repository during systems analysis. If the content
has not been recorded, we can define input requirements by studying the output and database
requirements or designs. An output attribute that can't be retrieved from database tables or
calculated from attributes that are retrieved from tables must be input! Additionally, inputs must be
designed to maintain the database tables in the system.

Now that we have an idea of the content for our input, we can address the proper screen-based
control to use for each attribute to appear on our screen. Using the repository-driven programming
approach, we would first check to see if such decisions and other attribute characteristics have
already been made and recorded as repository entries. If so, we would simply reuse those repository
entries that correspond to the attributes we will using on our input screen(s). In those cases where
there is no repository entry, we will have to simply create them.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p17 of 77
Prototype for NEW VIDEO TITLE, DISCONTINUED VIDEO TITLE, and VIDEO TITLE UPDATE inputs

The logo appearing in the upper right portion of the screen was included to adhere to a company
standard - that all screens must display the company logo. The buttons also appearing in the upper
center and right portion of the screen were added because of the decision to combine the three
inputs into a single screen. They were needed to allow the user the option of select the desired type
of input and record action. Draw your attention to the following:
The PRODUCT NUMBER, MONTHLY UNIT SALES, YEAR UNIT SALES, and TOTAL UNIT
SALES are screened in a special color as a visual clue to the user that these fields are
locked and they cannot enter data into them. These fields are automatically
generated by the system. Other fields appearing on the screen have white
background as a visual clue that they are editable.

Notice that edit masks were specified for these input fields. The UNIVERSAL
PRODUCT CODE field contains dashes in specified locations. The user does not
actually enter these dashes. Rather, the user simply types in the numbers and

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p18 of 77
afterwards the entire content is redisplayed according to the specified edit mask.
The same is true for the MANUFACTURERS SUGGESTED RETAIL PRICE, CLUB
DEFAULT UNIT PRICE, AND CURRENT SPECIAL UNIT PRICE fields. For example, in
either of these three fields the user could type the number “9”, press enter, and the
content would be redisplayed (according to the edit mask) with a dollar sign and
decimal point.

Each field on a screen has been given a label that is meaningful to the users.
Feedback from the indicated that “CC” was a commonly recognized abbreviation for
“closed caption”. Also, the users indicated that a label was not necessary for
CATALOG DESCRIPTION.

Notice that related radio buttons have been arranged in a group box that contains a
descriptive label. Group boxes are frequently used to visually associate a variety of
controls that are related. For example, notice the group box labeled “Common
Information”. The fields located inside this group box were grouped together
because the user associates these attributes any type of SoundStage product. Also,
realize that each label that correspond to a radio button option is not what is
actually input and stored in the database. Rather, what you see is the meaning of
the value. The actual value that is stored is a code. For example, the code value “E”
would actually be stored instead of “English” if the user selects the radio button
labeled “English” for the attribute LANGUAGE.
Notice that the multiple-line text box has a vertical scroll bar feature. This is a visual
clue that there is additional text not appearing inside the CATALOG DESCRIPTION
field.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p19 of 77
Now, here are two alternatives of input form design. Which one do you like? And Why?
3.2 User Interface Design
User interface design is the specification of a conversation between the system user and the
computer. The user interface should provide a friendly means by which the user can interact with
the application to process inputs and obtain outputs. Recall that in previous lectures, you learned
how to design and prototype inputs and outputs. User interface design and prototyping addresses
the overall presentation of the application and may require revisions to those preliminary input and
output prototypes. Today, there are two commonly encountered interfaces: terminals (or
microcomputers behaving as terminals) used in conjunction with mainframes and the more common
display monitors connected to microcomputers. There are also several strategy styles for designing
the user interface for systems. This conversation generally results in either input or output --
possibly both.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p20 of 77
My notes

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
_________________________________________________________________________________

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p21 of 77
Manage software development source files using
appropriate tools (US115362)

Learner’s Guide
Table of contents

Unit Std # 115362

NQF Level 5
Notional hours 50
Credit(s) 5
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

Specific Outcome 1: Locate software development source files.

 The location ensures that the correct source file is identified.
 The location ensures that the correct versions of additional files associated with the software
development source files are identified.
Specific Outcome 2 : Retrieve software development source files for update purposes.
 Retrieval and updating of the source file is in accordance with organisation procedures.
 Retrieval protects source files from loss while updates are in progress.
 Retrieval prevents source files from being updated simultaneously by two or more people.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p22 of 77
NOTIONAL HOURS BREAKDOWN

The candidate undertaking this unit standard is best advised to at least spend one hundred hours of
study time on this learning programme. Below is a table which demonstrates how these one
hundred hours could be spread:

TIMEFRAME

Total Notional Hours Contact Time Non contact-

Self-Study/Assessment
Credits (5) x 10 = 50 15HRS 35HRS
1. Learning Programme REFER TO COVER PAGE
Name:
2. SAQA Qualification/Unit REFER TO COVER PAGE
Standard Title:
3. Qualification/ 4 SAQA ID 5 NQF 5 6 Credits 5
Unit Standard . Number . Level .
7. PURPOSE for offering REFER TO NEXT PAGE
this programme to your
learners:

8. TARGET AUDIENCE for REFER TO NEXT PAGE

this specific
programme:

9. Entry/Admission REFER TO NEXT PAGE

Requirements:

10 Timeframe for Training: Theory content –Role play, Simulation, Group work, Pair work =
. (Total 15 hrs.
Hours/Days/Weeks) Non contact session- self-study, assignment, practise guided by
coach or mentor, formative assessment and summative
assessment =35 hrs.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p23 of 77
The Learner guide

At the end of this unit standard you will be able to Manage software development source
files using appropriate tools

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

 Manage software development source files using appropriate tools

Specific outcome:
 Locate software development source files
 Retrieve software development source files for update purposes

Learning assumed to be in place:


 Demonstrate an understanding of fundamental mathematics (at least NQF level 3).
 Demonstrate PC competency skills (End-User Computing unit Standards, at least up
to NQF level 3.)

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p24 of 77
Resources (selective resources might be used, depending on the facilitator and venue
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.

How to do the exercise:

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p25 of 77
SPECIFIC OUTCOME 1:

Locate software development source files.

ASSESEMENT CRITERIA
 The location ensures that the correct source file is identified.
 The location ensures that the correct versions of additional files associated with the software
development source files are identified.

1.1 Locate software development source files.

If you’re looking for a more generic solution to identifying unrecognized file types, here are 5 tools to
help you find them or files which have been given the wrong extension. All programs were tested on
Windows 7 32-bit and 64-bit.

1. Locate Opener
Locate Opener installs itself into your right click context menu, and when you run the program
executable it simply has an install or remove button to add it into the menu. From there, you right
click on an unrecognized or incorrectly labelled file and select Locate Opener from your context
menu. Depending on whether the file has no extension at all or one it cannot identify, you will either
be asked to look for the extension online at file-extension.net or to scan the file with TrID.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p26 of 77
To get the latest file definitions, just download and extract the TrIDDefs.TRD package to Locate
Opener’s TrID folder. If the program has found any matches through TrID it will pop up a box with
the most likely in terms of percentages, and offer to give the file an extension that best fits. The
program also has a command line and several advanced options can be configured through the ini
file.

2. Smart File Advisor

This is another program that places itself into your right click context menu, although it does use a
more traditional installer unlike Locate Opener’s semi portable tool. Simply right click on the file and
select Smart File Advisor from the menu. A box will appear which asks what you want to do next;
search its parent website Filefacts.net for the appropriate program or let Windows manage the file
by selecting a program via Open with.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p27 of 77
The search Filefacts option on its own is not that helpful unless you’re looking for an unknown
extension. The most useful function is the tick box in the window that says “send first 20 bytes of the
file to help detect file type”. Just about all files can be identified by analyzing the first few bytes of
their content so sending these 20 bytes should identify a file with no extension. If you click the link it
will show the 20 bytes to be sent in ASCII and HEX format. Click OK to send and a webpage from
Filefacts will open to tell you what a missing extension should be or what a wrong extension should
be renamed to.

3. Identify!
Identify! is a very old utility that dates back to 1999, but still actually works fine, even on Windows 7
x64, and it’s also only a tiny 200K portable executable. There may be newer file formats around since
then but the way they’re identified is still exactly the same. The list of around 150 supported types is
rather small compared to the 5,000+ in the TrID database, but it covers the most common types.
Also Identify! has an added feature built in which is you can easily add your own file formats to its
current list or edit what’s already there. Go to Edit -> Library to access the editor.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p28 of 77
Run the program to open the window and select File -> “Open and Identify” to locate the file you
want to check on. What it’s been identified as will show in the window along with the suggested file
extension in brackets. The only thing that doesn’t seem to work in the program is the shell extension
option to put an entry in the context menu, but it handles the identification of unknown files
without issue. Being small and portable makes it useful for a USB toolkit.

4. ExifTool
The ExifTool program works in a slightly different way to the other programs here because it’s a
command line tool that you can also use from the desktop. Simply extract the executable from the
zip file and to identify a file, drag and drop it onto the ExifTool icon. Any extensions the file has will
be ignored and its content will be scanned so it doesn’t matter if the file has no extension or simply a
wrong extension.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p29 of 77
As more knowledgeable users might recognize from its name, Exiftool is designed primarily for
viewing and editing the meta information held in most digital images, especially cameras. But it is
also capable of recognizing hundreds of different file types from their content. After dropping a file
onto the icon a DOS window will open with information about the file and could also include extra
information such as image tag details, archive information or executable file descriptions etc. Double
click on ExifTool for help, supported types and extra commands that can be used.

5. Analyze It!
Apart from the ability to determine a file type from its content, AnalyzeIt! also has a couple of other
functions which could be useful to some. One is getting detailed information about a file extension
such as Mime type and classification, the company that created it, its ID and also the characters in
Hex and ASCII that identifies it. There’s an even more advanced window of detail in the PE Info tab
which can give raw information about executable files. The Content Into tab is the most useful one
for identifying unknown files.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p30 of 77
The program needs installing and can also place an Analyze It! entry in your right click context menu.
The Content info tab displays the file’s attributes, whether it’s a binary or text file, and also the first
16 bytes of its content in Hex and ASCII formats. Experienced users might be able to tell what the file
is just from that information alone. Click on the “Analyze file header and content button” and the
program will identify the most probable type of file, it will then offer to rename it to the correct
extension for you.

My notes

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p31 of 77
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
______________________________________________________________________________

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p32 of 77
SPECIFIC OUTCOME 2 :
Retrieve software development source files for update purposes.
ASSESEMENT CRITERIA
 Retrieval and updating of the source file is in accordance with organisation procedures.
 Retrieval protects source files from loss while updates are in progress.
 Retrieval prevents source files from being updated simultaneously by two or more people.

2.1 Retrieve software development source files for update purposes.

2.1.1 Developing Backup, Restore and Storage Procedures

Backup specifics and procedures vary according to the needs of a company. Periodically reviewing
your backup-and-restore process is a key part of ensuring data security.

2.1.2 Considerations for Developing Procedures

This section offers a series of checklists — suggestions and questions — to serve as flexible
guidelines when you develop a comprehensive backup-and-restore process for your company.

Delegation of Tasks

It is critical that reliable personnel perform your backup and restore operations. Consider the
following questions when deciding how to delegate these tasks:

 Who makes the policy that determines what files and computers are backed up, and how is
the policy made known?

 Who is responsible for performing backups?

 If backups occur automatically, who handles interruptions such as error messages?

 Who does the backup when the assigned backup operator is unavailable?

 To whom is the success or failure of a backup reported? Who notifies the users if a backup
fails?

Time-Sensitive Backup Questions

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p33 of 77
In addition to determining when and how often backups take place, it is important to know how long
it takes to retrieve backup media and perform a restore. To determine this, ask the following
questions:

 Do all backups, both full and partial, occur outside of regular business hours?

 Should backups occur immediately after or before regular business hours?

 How often do you perform full and incremental backups?

 How long does it take to retrieve backups or copies from a local or remote storage area? Can
the remote copies be obtained at any time or only during business hours?

 How long does it take to perform a full restore if the computer fails?

In the Event of a Backup Problem

Make sure to take certain issues into consideration before a backup problem occurs:

 Determine who is notified if a problem or backup failure occurs, and what process they
follow.

 If backup fails because of hardware problems, is standby hardware on-site or available on

loan from your vendor? Determine how long it takes to replace failed hardware.

 Determine the availability of hardware and software technical support.

 Does your technical support staff have configuration information about computers running
Windows 2000? If not, you need to determine how to make the information available in the
event of a problem.

 How does support from hardware or software vendors affect how long fixes take?

 If trained personnel monitor overnight backups, are they also scheduled to work the next
day? Who covers their other duties while they troubleshoot backup problems or restore
data?

Security Considerations

The security of your backup operations, as well as the security of the storage location, is of
paramount importance. Take the following questions into consideration when planning for the
security of company data:

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p34 of 77
 Where are the backup tapes stored?

 What has been done to make the backup location secure in the event of fire, flood, theft, or
another disaster?

 How is the backup location monitored?

 Are the tapes that are stored on-site always accessible to the people who need them?

 If there are copies of backup media, where are they stored?

 Is the backup location bonded?

Policy Considerations

Developing a backup-and-restore process and deciding what to back up requires that you either set
or comply with company policy. Keep the following issues in mind when determining your backup
plans:

 What is the policy for backup, and how is your plan in compliance?

 Are all modified files to be backed up, or does company policy specify only critical files or the
files of certain users, groups, departments, or divisions?

 Are any disks or volumes on the computer not to be backed up?

 Are users responsible for backing up their own client systems?

 Is there a charge-back system for the amount of storage used?

 How is the backup process validated?

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p35 of 77
Technical Considerations

You also need to determine how your backups are performed. For instance, determine the following:

 Does the system have to meet certain conditions before the backup starts?

 How is the backup started — from the command line, from an icon, or by batch?

 Are logs created and are they correct?

 If the path is long, the file name odd, the file size very large, or the number of files large,
does the backup still work? Can you restore files that have these characteristics?

 Is the backup done to a local tape drive, remotely over the LAN, or remotely over the wide
area network (WAN)

 Does the tape verify that the backed-up data is correct?

 How are the connections between a data source and the storage device verified before the
backup begins?

 Are computers equipped for power outages if operators are not present when backups take
place?

 Do backups occur on schedule?

 What is the process in place for dealing with unforeseen occurrences during a backup or
restore?

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p36 of 77
2.1.3 Testing Backup-and-Restore Procedures

Complete verification of the entire backup-and-restore process is critical. Develop backup-and-

restore strategies with appropriate resources and personnel, and then test them. Testing backup
strategies also demonstrates how much time is required to restore data. A good plan ensures fast
recovery of lost data.

Try performing a trial restoration periodically to verify that your files are properly backed up. A trial
restoration can uncover hardware problems that do not show up with software verifications.

After a backup strategy has been designed, test it thoroughly with as many simulated failures as
possible. For example, if you use disk mirroring, simulate a disk failure by removing or powering
down one of the mirrors and ensure that remaining mirror continues to operate without
interruption. Again, while RAID is effective, it does not eliminate the need for backups. A data
recovery plan based on disk mirroring alone offers no protection if a computer is stolen.

The following questions can help you assess your verification strategy.

 Has every option that you expect to use been tested?

 Do automated backup instructions work?

 Does the backup-and-restore process work properly?

 After you make changes to the operating system (such as installing a service pack), or the
backup program, does the backup-and-restore process work properly?

 After you make hardware changes (such as installing a new controller or tape drive, or
changing the BIOS on the motherboard) does the backup-and-restore process work
properly?

 When you change the hardware or software involved in a backup, how do you verify that
you can use the old tapes?

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p37 of 77
Documenting Backup-and-Restore Procedures

Keeping accurate backup records is essential to finding missing information quickly, particularly if
you have accumulated a large number of high-volume media. Thorough records include media
labels, catalogs, and online log files and log books.

Media labels Labels should contain a date, the type of backup (normal, incremental, or
differential), and a list of contents. If you are restoring from differential or incremental
backups, you need to locate the last normal backup and either the last differential backup
or all incremental backups created since the last normal backup. Alternately, you can label
media sequentially and keep a log book of media content.

Catalogs Most backup software includes a mechanism for cataloging backup files. Backup
stores backup catalogs on the backup media and temporarily loads them into memory.
Catalogs are created for each backup set, or collection of backed up files from one drive.

Log files Log files include the names of all backed up and restored files and directories. A
log file is useful when restoring data because you can print or read it from any text editor.
Keeping printed logs in a notebook makes it easier to locate specific files. For example, if
the tape containing the catalog of the backup set is corrupt, you can use the printed logs to
locate a file.

Conducting Verify Operations

A verify operation compares the files on disk to the files on backup media. It occurs after all files are
backed up or restored, and it takes about as long as the backup procedure. It is recommended that
you perform a verify operation after every backup, especially if you back up to a set of media for
long-term storage. A verify operation is also recommended after file recovery.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p38 of 77
My notes

Produce documentation for a computer program to agreed

standards (US115388)

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p39 of 77
Learner’s Guide
Table of contents

Unit Std # 115388

NQF Level 5
Notional hours 30
Credit(s) 3
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

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p40 of 77
Specific Outcome 1 : Plan and design documentation for a computer program to agreed
standards.
 The documentation design covers the format of the documents in line with industry
conventions.
 The documentation plan covers full program documentation components.
Specific Outcome 2: Create documentation for a computer program to agreed standards.
 The documentation is created according to the design created in specific outcome 'Plan and
design documentation for a computer program to agreed standards'.
 The documentation components created are created according to the plan specified in specific
outcome 'Plan and design documentation for a computer program to agreed standards'.
 The documentation created is structured sensibly, defining how program specifications have
been met.
Specific Outcome 3: Review documentation for a computer program for completeness.
 The review identifies if documentation was created according to the design created in specific
outcome 'Plan and design documentation for a computer program to agreed standards'.
 The review identifies if documentation was created consistent with the computer program
being documented.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p41 of 77
NOTIONAL HOURS BREAKDOWN

TIMEFRAME

Total Notional Hours Contact Time Non contact-

Self-Study/Assessment
Credits (5) x 10 = 50 9HRS 21HRS
1. Learning Programme REFER TO COVER PAGE
Name:
2. SAQA Qualification/Unit REFER TO COVER PAGE
Standard Title:
3. Qualification/ 4 SAQA ID 5 NQF 5 6 Credits 3
Unit Standard . Number . Level .
4. PURPOSE for offering REFER TO NEXT PAGE
this programme to your
learners:

5. TARGET AUDIENCE for REFER TO NEXT PAGE

this specific
programme:

6. Entry/Admission REFER TO NEXT PAGE

Requirements:

7. Timeframe for Training: Theory content –Role play, Simulation, Group work, Pair work = 9
(Total hrs.
Hours/Days/Weeks) Non contact session- self-study, assignment, practise guided by
coach or mentor, formative assessment and summative
assessment =21 hrs.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p42 of 77
The Learner guide

At the end of this unit standard you will be able to Produce documentation for a computer
program to agreed standards

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

 Produce documentation for a computer program to agreed standards

Specific outcome:
 Plan documentation for a computer program to agreed standards
 Create documentation for a computer program to agreed standards
 Review documentation for a computer program for completeness

Learning assumed to be in place:

 Demonstrate PC competency skills (End User Computing unit standards, at least up

to NQF level 3)
 Apply the Principles of Computer Programming

Resources (selective resources might be used, depending on the facilitator and venue
circumstances), one or all of the following can be used:

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p43 of 77
 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.

How to do the exercise:

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p44 of 77
SPECIFIC OUTCOME 1:

Plan and design documentation for a computer program to agreed

standards.
ASSESEMENT CRITERIA
 The documentation design covers the format of the documents in line with industry
conventions.
 The documentation plan covers full program documentation components.

1.0 Introduction
All large software development projects, irrespective of application, generate a large amount of
associated documentation. For moderately sized systems, the documentation will probably fill
several filing cabinets; for large systems, it may fill several rooms. A high proportion of software
process costs is incurred in producing this documentation. Furthermore, documentation errors and
omissions can lead to errors by end-users and consequent system failures with their associated costs
and disruption. Therefore, managers and software engineers should pay as much attention to
documentation and its associated costs as to the development of the software itself.

The documents associated with a software project and the system being developed have a number
of associated requirements:

1. They should act as a communication medium between members of the development team.
2. They should be a system information repository to be used by maintenance engineers.
3. They should provide information for management to help them plan, budget and schedule the
software development process.
4. Some of the documents should tell users how to use and administer the system.

Satisfying these requirements requires different types of document from informal working
documents through to professionally produced user manuals. Software engineers are usually
responsible for producing most of this documentation although professional technical writers may
assist with the final polishing of externally released information.

My goals here are to describe the documentation which may be produced during the software
process, to give some hints on ways of writing effective documents and to describe processes

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p45 of 77
involved in producing these documents. My focus in this paper is on documentation that is intended
to be printed and so is delivered on paper or in a format such as PDF which may be viewed on a
screen or locally printed. Many systems now also have associated hypertext help systems. Producing
these systems requires a different set of skills from producing paper documentation.

1.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 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:

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p46 of 77
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.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p47 of 77
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
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 outdated. 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.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p48 of 77
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
want to know how the software can help them. They are not interested in computer or
administration details.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p49 of 77
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.

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

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p50 of 77
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.

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

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p51 of 77
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
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

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p52 of 77
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.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p53 of 77
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.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p54 of 77
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.

Examples of product standards which should be developed are:

1. Document identification standards - As large projects typically produce thousands of

documents, each document must be uniquely identified. For formal documents, this identifier may

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p55 of 77
be the formal identifier defined by the configuration manager. For informal documents, the style of
the document identifier should be defined by the project manager.
2. Document structure standards- As discussed in the previous section, there is an appropriate
structure for each class of document produced during a software project. Structure standards should
define this organization. They should also specify the conventions used for page numbering, page
header and footer information, and section and sub- section numbering.
3. Document presentation standards -Document presentation standards define a ‘house style’ for
documents and they contribute significantly to document consistency. They include the definition of
fonts and styles used in the document, the use of logos and company names, the use of color to
highlight document structure, etc.
4. Document update standards- As a document is changed to reflect changes in the system, a
consistent way of indicating these changes should be used. These might include the use of different
colors of cover to indicate a new document version and the use of change bars to indicate modified
or deleted paragraphs.

Document standards should apply to all project documents and to the initial drafts of user
documentation. In many cases, however, user documentation has to be presented in a form
appropriate to the user rather than the project and it should be recast into that form during the
production process.

Interchange standards
Document interchange standards are important as more and more documents are produced in
electronic format as well as or instead of on paper. For documentation that is delivered with a
software system, the Adobe Portable Document Format (PDF) is now very commonly used. However,
when documents are exchanged by the development team and drafts are circulated within an
organization these are often in the format of whatever word processor is used (often Microsoft
Word).

Assuming that the use of a standard word processor and graphical editing system is mandated in the
process standards, interchange standards define the conventions for using these tools. The use of
interchange standards, allows documents to be transferred electronically and re-created in their
original form.

Interchange standards are more than simply an agreement to use a common version of a system for
document production. Examples of interchange standards include the use of an agreed standard

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p56 of 77
macro set if a text formatting system is used for document production or the use of a standard style
sheet for a word processor. Interchange standards may also limit the fonts and text styles used
because of differing printer and display capabilities.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p57 of 77
My notes

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p58 of 77
SPECIFIC OUTCOME 2 :
Create documentation for a computer program to agreed
standards.
ASSESEMENT CRITERIA
 The documentation is created according to the design created in specific outcome 'Plan and
design documentation for a computer program to agreed standards'.
 The documentation components created are created according to the plan specified in specific
outcome 'Plan and design documentation for a computer program to agreed standards'.
 The documentation created is structured sensibly, defining how program specifications have
been met.

2.1 Create documentation for a computer program to agreed standards.

Composing computer program/software documentation

Like other forms of technical documentation, good software documentation benefits from an
organized process of development. In the case of software documentation, the process as it
commonly occurs in industry consists of five steps:

1. User analysis, the basic research phase of the process.

2. Planning or the actual documentation phase.
3. Draft review, a self-explanatory phase where feedback is sought on the draft composed in
the previous step.
4. Usability testing, whereby the usability of the document is tested empirically.
5. Editing, the final step in which the information collected in steps three and four is used to
produce the final draft.

Accurately documenting a new or revised computer application is critically important so that all
stakeholders agree on the application to be developed. The system design documentation process
provides a common framework for computer programmers to develop the system.

2.2 Instructions on how to create documentation for a computer program to agreed standards

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p59 of 77
 Write a brief description of your new program --- include its purpose, what platforms the
program will run on and any memory requirements. List several bullet points stating major
features of the program.
 Sketch out how you want the user documentation to look. Include any possible headers and
footers to place within the documentation, page numbers and how the cover should look.
This outline will also help you with putting the guidebook together.
 Write your first section -- how to install the program. State each step clearly from inserting
the compact disk into the computer to what to do once the software is installed. Provide
screen shots of the installation process. Don't leave out any steps and list any possible errors
that might occur. Include a chart of troubleshooting tips.
 State clearly the steps for getting the program to run. Include which icon to click and what
the main screen will look like. Provide a screen shot of the opening screen.
 Write your third section -- how to operate with the program. Describe any menu functions,
how to access help if available, how to save files, how to print, how to exit the program and
any other basic functions. Include screen shots throughout this section also. Use simple
English and don't expect the end user to assume anything. If the program interfaces with
another program or package, explain this connection.
 Compose a simple table of contents and an index using keywords from your documentation.
Write this section once you have the above core sections done. The index provides the user
with a quick way to retrieve information without having to search the entire guidebook.
 Create a glossary of terms for any technical words or jargon that need to be defined for the
user. Next, design the cover to go on the front of the guidebook.
 Edit your documentation -- check your spelling, grammar and overall flow of information.
Make any revisions and pass the documentation on to someone else to double check your
work. Print and bind the final version.

My notes

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p60 of 77
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
________

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p61 of 77
SPECIFIC OUTCOME 3:
Review documentation for a computer program for completeness.
ASSESEMENT CRITERIA
 The review identifies if documentation was created according to the design created in specific
outcome 'Plan and design documentation for a computer program to agreed standards'.
 The review identifies if documentation was created consistent with the computer program
being documented.

3.1 Review documentation for a computer program for completeness.

After completing, your computer program documentation should include all of the documents
describing the computer program 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 computer program that are developed to a customer’s specification, the computer
program documentation should include:

1. The requirements document and an associated rationale.

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.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p62 of 77
My notes

__________________________________________________________________________________
__________________________________________________________________________________

__________________________________________________________________________________
__

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p63 of 77
Unit Std # 115359
NQF Level 4
Notional hours 20
Credit(s) 2
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
Demonstrate an understanding of the handling of error in a
computer programming environment(US115359)

Learner’s Guide

Table of contents

Specific Outcome 1 : Explain different errors found in the computer programming environment.
 The explanation covers the difference between an error and a mistake.
 The explanation covers the errors found in data entry via computer input devices.
 The explanation identifies sources of induced errors in calculations.
Specific Outcome 2 : Demonstrate how calculation errors are induced in the computer.
 The demonstration explains overflow errors found in computers.
 The demonstration explains underflow errors found in computers.
 The demonstration explains conversion errors found in computers.
 The demonstration explains errors found in computers because of advancement in processor
word-sizes.

Specific Outcome 3 : Demonstrate how mistakes and computer errors can be minimised
 The demonstration explains how mistakes can be minimised.
 The demonstration explains how errors can be minimised.

NOTIONAL HOURS BREAKDOWN

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p64 of 77
The candidate undertaking this unit standard is best advised to at least spend one hundred hours of
study time on this learning programme. Below is a table which demonstrates how these one
hundred hours could be spread:

TIMEFRAME

Total Notional Hours Contact Time Non contact-

8. TARGET AUDIENCE for REFER TO NEXT PAGE

this specific
programme:

9. Entry/Admission REFER TO NEXT PAGE

Requirements:

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p65 of 77
The Learner guide

At the end of this unit standard you will be able to Demonstrate an understanding of the
handling of error in a computer programming environment

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

This unit standard is designed to provide credits towards the mathematical literacy
requirements of the NQF at level 4.

Specific outcome:
 Explain different errors found in the computer programming environment , and
differentiate it from mistakes.
 Demonstrate how calculation errors are induced in the computer.
 Demonstrate how computer errors can be minimised.

Learning assumed to be in place:


 Competent in Mathematical Literacy and Communications at NQF level 3.
 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).

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p66 of 77
Resources (selective resources might be used, depending on the facilitator and venue
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.

How to do the exercise:

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p67 of 77
SPECIFIC OUTCOME 1:

Explain different errors found in the computer programming environment.

ASSESEMENT CRITERIA
 The explanation covers the difference between an error and a mistake.
 The explanation covers the errors found in data entry via computer input devices.
 The explanation identifies sources of induced errors in calculations.

1.1 Explain different errors found in the computer programming environment and differentiate
them from mistakes.

1.1.1 Types of Program Errors

There are three basic types of program errors.

(a) Syntax Errors

The first type of error is a syntax error. You already know that syntax errors are caused when you
don’t obey the syntax rules of C#. A common syntax rule you might take in the beginning is
forgetting to terminate each program statement with a semicolon. Intellisense does an excellent job
of catching syntax errors. While you may hate the squiggly line that Intellisense displays, it ’ s a lot
easier for Intellisense to detect and isolate syntax errors than it is for you to do it yourself.

(b) Logic Errors

Logic errors are those errors that remain after all the semantic and syntax errors have been
removed. Usually, logic errors manifest themselves when the result the program produces doesn’t
match the result your test data suggest it should produce. Most of the time, logic errors are found in
the process. Logic errors occur when you implement the algorithm for solving the problem
incorrectly.
The key to fixing logic errors is to be able to reproduce the error consistently. A repeatable logic
error is much easier to track down and fix than an error that appears to be occurring randomly. You
will learn the detail of using some of the tools Visual Studio provides to help you detect and isolate

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p68 of 77
program bugs.)

(c) Semantic Errors

A semantic error occurs when you obey the syntax rules of the language but are using the statement
out of context. For example, a sentence in English is expected to have a noun and a verb. Consider
the sentence “The dog meowed. ” This sentence does obey the rules of having a noun and a verb,
but the context of the sentence is out of whack. Dogs don’t meow, therefore the context of the
statement is incorrect. The error message I showed you earlier:
The name ‘i’ does not exist in the current context refers to a type of semantic error. There may well
be a variable named i defined somewhere in the program, but it is not currently in scope. That is,
you are trying to use i when it is out of scope. Intellisense does a good job of detecting semantic
errors.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p69 of 77
My notes

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p70 of 77
SPECIFIC OUTCOME 2 :
Demonstrate how calculation errors are induced in the computer.
ASSESEMENT CRITERIA
 The demonstration explains overflow errors found in computers.
 The demonstration explains underflow errors found in computers.
 The demonstration explains conversion errors found in computers.
 The demonstration explains errors found in computers because of advancement in processor
word-sizes.

2.1 Demonstrate how calculation errors are induced in the computer.

Computers do lots of calculations - millions or more per second. Unfortunately, they sometimes
make mistakes. We call these ERRORS. They are not actually caused by computer "mistakes",
because the computer is following programming that a human-being wrote. And computers do
follow that programming exactly. So if there is a mistake, it came from human beings. Computers are
perfectly RELIABLE (maybe 99.999%).

2.1.1 The following are how computers make errors

(a) Overflow errors found in computers

An error that occurs when the computer attempts to handle a number that is too large for it. Every
computer has a well-defined range of values that it can represent. If during execution of a program it
arrives at a number outside this range, it will experience an overflow error. Overflow errors are
sometimes referred to as overflow conditions.

(b) Underflow errors found in computers.

A data-processing error arising when the absolute value of a computed quantity is smaller than the
limits of precision of the computing device, retaining at least one significant digit.

(c) Conversion errors found in computers

Inexactitude can also be a result of data conversion. This means that the result of the conversion can
be conceptually different from the source files. An example would be the extant in word processors,

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p71 of 77
WYSIWG paradigm and desktop publishing applications compared to the structural descriptive
paradigm found in XML and SGML. It is important to know the workings of both source and target
format when converting data. If the format specifications are unknown, reverse engineering can be
applied to carry out any conversion as this can attain close approximation of the original
specification although there is no assurance that there can be no error or inconsistency. In any case,
there applications that can detect errors so appropriate actions can be done.

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p72 of 77
My notes

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p73 of 77
SPECIFIC OUTCOME 3:
Demonstrate how mistakes and computer errors can be
minimised.
ASSESEMENT CRITERIA
 The demonstration explains how mistakes can be minimised.
 The demonstration explains how errors can be minimised.

3.1 Demonstrate how mistakes and computer errors can be minimised.

Computers can have issues and errors. These many times happen because there are security flaws in
the system, malicious software, and some poor computer habits that the user is causing. Learn what
you can do to help prevent computer errors on your machine as much as possible.

 One of the most common mistakes is filling up the hard drive. A Windows machine
needs at least a few gigabytes of space to correctly save settings when shutting
down the machine. The extra space will also help your computer run faster since
when you are using it, you need some space for your temporary files. There are
variety of issues that you can avoid by deleting a few files or moving them to an
external hard drive and leaving a few gigabytes of space. An external hard drive is a
worthwhile purchase, not only will you help keep your computer's hard drive clutter
free, but you will have a back up of all your important files.

 Another step that needs to be taken is to always shut down the computer properly.
Many times people might just hold down the power button to make the machine
turn off. This is not good for the computer on the hardware side or even the
software side. It's important to properly go through the shut down procedures to
prevent possible complications.

 One thing that should always be done regardless of what type of machine you are
using is to update the operating system. There are many security patches that are

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p74 of 77
there for your protection. Whenever there is an operating system update, be sure to
get it as soon as possible.

 The same goes for your applications that you are running on your machine especially
those that are connected to the internet. The browser is attacked all the time
regardless of which one you choose to use. You need to update the browser
whenever there is patch available because it will help keep your machine more
secure.

 Following these steps will help prevent a variety of computer errors that you might
have otherwise had to face. It is not fun to have any type of computer failure and
many times failure happens because of something that could not be prevented.
However, for peace of mind it is important to do what you can to keep your
computer healthy and help to avoid any issues. You will be glad you did!

 Irrespective of the operating system you use, make sure that you run a check disk
program regularly to ensure that there are no errors on your hard disk. This way it
will help you to keep a note of errors that make your hard drive slow and repair it
periodically. As a result, your hard disk will operate at an optimum level

 Remove Temporary File

 When you browse the internet or work on any document, the system stores some of
the information in temporary folder, which reduces the speed of your system to a
great extent. Delete the temporary files through internet options, delete cookies
once a week.

 Organize the Present Data

 As you work, run updates of software and documents, the data will be saved in
those spaces of hard drive that are far away from original part of files. Fragmenting
the disc once a week brings all the files together, which will help in opening the files
faster and increase the speed of the system

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p75 of 77
 Virus Protection

 Antivirus, Malware, Spywares and adware reduce the performance of your system
and capture your private information. Use comprehensive antivirus, run regular
deep system scan to keep your system virus free. Keep the virus definition of your
antivirus updated regularly.

 Remove Web History

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p76 of 77
My notes

Revision: 1.0 Date: 16 June 2018

M3 Computer Programming Development & Problem Solving - Learner Guide p77 of 77

Syllabus CSEN1111-OOP With Java
No ratings yet
Syllabus CSEN1111-OOP With Java
7 pages
Lesson Plan 6
No ratings yet
Lesson Plan 6
16 pages
Chapter 6 - Transition To System Design
0% (1)
Chapter 6 - Transition To System Design
54 pages
Module 2 SD (Formative Assessment)
No ratings yet
Module 2 SD (Formative Assessment)
17 pages
Information Management
No ratings yet
Information Management
2 pages
Integrative Programming and Technologies (Itec4121)
No ratings yet
Integrative Programming and Technologies (Itec4121)
17 pages
Cse329 Management-Information-systems Syllabus
No ratings yet
Cse329 Management-Information-systems Syllabus
2 pages
IT 12 Data Communication With Networking OBE Syllabus 1hour
No ratings yet
IT 12 Data Communication With Networking OBE Syllabus 1hour
8 pages
La Salette of Roxas College, Inc.: Information Technology Department
No ratings yet
La Salette of Roxas College, Inc.: Information Technology Department
7 pages
Course Plan HCI
No ratings yet
Course Plan HCI
9 pages
Introduction To Computing: What Is A Computer?
No ratings yet
Introduction To Computing: What Is A Computer?
11 pages
HTML Proj
No ratings yet
HTML Proj
14 pages
Basic Components of Computer System
No ratings yet
Basic Components of Computer System
4 pages
TSA2151 Lec01
No ratings yet
TSA2151 Lec01
32 pages
Platform Technologie S: Lesson 1-Elec4
No ratings yet
Platform Technologie S: Lesson 1-Elec4
27 pages
It 301 - Adet Lesson 1
No ratings yet
It 301 - Adet Lesson 1
7 pages
SYLLABUS
No ratings yet
SYLLABUS
3 pages
The Computer Level Hierarchy
No ratings yet
The Computer Level Hierarchy
6 pages
Software Engineering Lab - CSE342P Experiment List
No ratings yet
Software Engineering Lab - CSE342P Experiment List
2 pages
CIS - Fundamentals of Enterprise Data Management
No ratings yet
CIS - Fundamentals of Enterprise Data Management
6 pages
Keyboard Processing With Control Flow: Julius Bancud
No ratings yet
Keyboard Processing With Control Flow: Julius Bancud
30 pages
ITEC54 - System Integration and Architecture - Introduction
No ratings yet
ITEC54 - System Integration and Architecture - Introduction
6 pages
Module 4 - Chapter 5 - Platform Technologies
No ratings yet
Module 4 - Chapter 5 - Platform Technologies
20 pages
Integrative Programming Technology - Integrative Coding
No ratings yet
Integrative Programming Technology - Integrative Coding
45 pages
01 Information Processing Cycle 1201113124804673 3
No ratings yet
01 Information Processing Cycle 1201113124804673 3
16 pages
Integrative Programming Lecture PDF
No ratings yet
Integrative Programming Lecture PDF
13 pages
Syllabus On Human Computer Interaction
No ratings yet
Syllabus On Human Computer Interaction
19 pages
El 1 - Platform Technologies
No ratings yet
El 1 - Platform Technologies
8 pages
Dbms Lesson Plan
No ratings yet
Dbms Lesson Plan
11 pages
What Is Web Services and Middleware
No ratings yet
What Is Web Services and Middleware
8 pages
Software Engineering 2
No ratings yet
Software Engineering 2
111 pages
Introduction To Data Warehousing
No ratings yet
Introduction To Data Warehousing
43 pages
Introduction To HCI
100% (1)
Introduction To HCI
11 pages
Identifying Needs and Establishing Requirements: HCI - Umber Shamim
100% (1)
Identifying Needs and Establishing Requirements: HCI - Umber Shamim
54 pages
C++ Quiz 1
No ratings yet
C++ Quiz 1
15 pages
Intruders
No ratings yet
Intruders
27 pages
IS2184 Information Systems Management
No ratings yet
IS2184 Information Systems Management
2 pages
It0423 Ipt Manual 2012-13
100% (1)
It0423 Ipt Manual 2012-13
78 pages
IT101 IT Fundamentals
No ratings yet
IT101 IT Fundamentals
2 pages
Master of Science in Information Technology
100% (1)
Master of Science in Information Technology
2 pages
LESSON 1 Information Management
No ratings yet
LESSON 1 Information Management
5 pages
Computer Multitasking
No ratings yet
Computer Multitasking
5 pages
Operating Systems Overview
No ratings yet
Operating Systems Overview
20 pages
Living in It Era
No ratings yet
Living in It Era
2 pages
Lab Exercise Set 6
No ratings yet
Lab Exercise Set 6
9 pages
Lesson 1 Introduction To Information Security
No ratings yet
Lesson 1 Introduction To Information Security
42 pages
Internet Programming Notes
100% (1)
Internet Programming Notes
3 pages
System Design: What Is Design? Example Designs in Real Life
No ratings yet
System Design: What Is Design? Example Designs in Real Life
11 pages
Course Outline (Data Communication and Networking 1)
No ratings yet
Course Outline (Data Communication and Networking 1)
3 pages
Mobile Application Development
50% (2)
Mobile Application Development
3 pages
CS368 Web Technologies
No ratings yet
CS368 Web Technologies
3 pages
Final Project
No ratings yet
Final Project
12 pages
Lab 01: Introduction To Assembly Language: Theory
No ratings yet
Lab 01: Introduction To Assembly Language: Theory
5 pages
Data Structures Syllabus
No ratings yet
Data Structures Syllabus
2 pages
1.living in A Network Centric World
No ratings yet
1.living in A Network Centric World
34 pages
Syllabi in Networks and Communications Nc101
No ratings yet
Syllabi in Networks and Communications Nc101
3 pages
Lecture Note Formal Methods in Software Engineering - Lecture 1 (Download Tai Tailieutuoi - Com)
No ratings yet
Lecture Note Formal Methods in Software Engineering - Lecture 1 (Download Tai Tailieutuoi - Com)
6 pages
Fundamentals of Information Technology
No ratings yet
Fundamentals of Information Technology
2 pages
It Security
No ratings yet
It Security
33 pages
Introduction to Linux: Installation and Programming
From Everand
Introduction to Linux: Installation and Programming
N. B. Venkateswarlu
No ratings yet
Learner Guide
No ratings yet
Learner Guide
57 pages
Module 4 SD (Formative Assessment)
No ratings yet
Module 4 SD (Formative Assessment)
16 pages
Module 5 SD - Gathering Techiques For Computer Systems Development
No ratings yet
Module 5 SD - Gathering Techiques For Computer Systems Development
105 pages
Module 1 SD Personal Development - Formative Assessment
No ratings yet
Module 1 SD Personal Development - Formative Assessment
44 pages
Module 5 SD (Formative Assessment)
No ratings yet
Module 5 SD (Formative Assessment)
18 pages
Module 1 - Personal Development PDF
No ratings yet
Module 1 - Personal Development PDF
196 pages
Module 3 SD (Formative Assessment)
No ratings yet
Module 3 SD (Formative Assessment)
19 pages
CISSP Exam Outline PDF
No ratings yet
CISSP Exam Outline PDF
15 pages
Accenture Service Delivery Platform FY09
100% (1)
Accenture Service Delivery Platform FY09
20 pages
Wheel Dozer
No ratings yet
Wheel Dozer
20 pages
Digital Swim Stopwatch Instructions PDF
No ratings yet
Digital Swim Stopwatch Instructions PDF
1 page
Io TSystem Architectureand Technologies
No ratings yet
Io TSystem Architectureand Technologies
6 pages
Manual DreamBox BusyBox
No ratings yet
Manual DreamBox BusyBox
77 pages
CBSE Class 11 Computer Science Sample Paper Set 1
No ratings yet
CBSE Class 11 Computer Science Sample Paper Set 1
4 pages
109141-Day_Planner_-_Online_RN
No ratings yet
109141-Day_Planner_-_Online_RN
5 pages
3rd Cbse Cs FE
No ratings yet
3rd Cbse Cs FE
2 pages
Vertical Seek Bar or Slider in Android, As Android Doesn't Provide Seek Bar Orientation Property
No ratings yet
Vertical Seek Bar or Slider in Android, As Android Doesn't Provide Seek Bar Orientation Property
10 pages
Groovy 9 - Capturing Rawrequest & Response: or or
No ratings yet
Groovy 9 - Capturing Rawrequest & Response: or or
4 pages
CxSASTReport 21 12 2022-11 51 28
No ratings yet
CxSASTReport 21 12 2022-11 51 28
153 pages
Atr42 - 72 MPC Specs
No ratings yet
Atr42 - 72 MPC Specs
233 pages
(Campus Bus Management System) : Presented By: Jawad Zahoor Ishaq Ali Presented To: Ms. Abida Sadaf
No ratings yet
(Campus Bus Management System) : Presented By: Jawad Zahoor Ishaq Ali Presented To: Ms. Abida Sadaf
32 pages
13-08-02 Motorola Mobility Motion To Dismiss Microsoft Complaint Against U.S. Customs
No ratings yet
13-08-02 Motorola Mobility Motion To Dismiss Microsoft Complaint Against U.S. Customs
33 pages
Lesson 4 - PHP Operators
No ratings yet
Lesson 4 - PHP Operators
12 pages
01-01 Local Maintenance Terminal
No ratings yet
01-01 Local Maintenance Terminal
12 pages
Kiln Roller Water Jacket-Model PDF
No ratings yet
Kiln Roller Water Jacket-Model PDF
1 page
Resilient Azure Architecture
No ratings yet
Resilient Azure Architecture
19 pages
DatabaseRevisionQuestions With Ans - Day2
No ratings yet
DatabaseRevisionQuestions With Ans - Day2
30 pages
Assignment 04
No ratings yet
Assignment 04
3 pages
TTS For Punjabi (Theisis) PDF
No ratings yet
TTS For Punjabi (Theisis) PDF
61 pages
Tax Postings With Accounting BAPI - ERP Financials - SCN Wiki
No ratings yet
Tax Postings With Accounting BAPI - ERP Financials - SCN Wiki
7 pages
2 Problem Sheet Two
No ratings yet
2 Problem Sheet Two
4 pages
Installation Screenrec: For Tenants
No ratings yet
Installation Screenrec: For Tenants
29 pages
Sticker Instructions PDF
No ratings yet
Sticker Instructions PDF
3 pages
Testing of RESTful Web APIs
No ratings yet
Testing of RESTful Web APIs
3 pages
Boss Scalper Code
No ratings yet
Boss Scalper Code
2 pages
Build Prop6 5
No ratings yet
Build Prop6 5
6 pages
Adobe Photoshop Level 1 - EnG
No ratings yet
Adobe Photoshop Level 1 - EnG
56 pages