University of ZimbabweComputer Science Department CT 260/ CT 360 Project Guidelines Prepared by Zanamwe N CHAPTER ONE 1. Introduction 1.1 Background Here you develop the theoretical and conceptual framework upon which the project is based. It is appropriate to describe relevant data representations and algorithms. The developer must initiate reader into the project. The developer must begin with a general overview and then narrow down to specific focus. The background paves way for the statement of problem. 1.2 Statement of Problem or Nature of the Research Problem The first stage of a project is to realize a problem and the problem has to be chronic. A problem statement is a clear concise statement that spells out the problem to be solved and it also Prepared by Zanamwe N @ 2013 1 articulates the value added if problem is solved. The statement must be brief and nontechnical. 1.3 Previous and Current Work, Methods and Procedures This is an historical or conceptual survey of relevant work done in the area by previous investigators. Each contribution must be accompanied by appropriate references to be listed in the reference section. The developer must identify existing systems that were developed to address the current problem and how they are inadequate or what are their weaknesses. 1.4 Project Description/ Novel Characteristics of the Research This section presents a brief overview of new, extended or different functions, structure or operation of the system. The developer must clearly show the novelty or newness of system to be developed. 1.5 Research Purpose/ Research Objectives/ Aims Developers are urged to focus on the statement to generate research objectives. Objectives are evidence of focus/direction 1.6 Justification of Project/ Rationale/ Significance of project Theoretical, practical, or educational impacts on hardware, software, or users Rationale addresses among other issues the following: ∙ Why the research is necessary ∙ Why it is important i.e. its benefits to the users and the community at large ∙ Expressing value of project output to target users 1.7 Organisation of the project/ Summary / Presentation of Research This section gives an overview of the whole project that is what is going to be covered in each of the foregoing chapters. CHAPTER TWO 2. System Specification 2.1. Introduction Give a brief introduction about what this chapter covers. 2.2. System Functional Specification or Problem Definition This is a detailed specification of functions performed by the proposed system, from an external or user perspective, not from an internal or programmer viewpoint. Thus, the system is regarded as a black box with various inputs and outputs related by the functions performed by the system. The description should be sufficient for another programmer to implement the system. Prepared by Zanamwe N @ 2013 2 2.1.1 Functional Requirements List and briefly describe each of the functions which the system will be designed to perform for its user: What the system will do. The requirements must be complete and should not be ambiguous. 2.1.2 NonFunctional Requirements List and describe each of the internal (self) and external (environment) limitations and/or restrictions on the range of system functions: What will the system not do. DO NOT INSULT/OFFEND THE READER BY INCLUDING ITEMS THAT WOULD NOT BE A SURPRISE. 2.1.3 System Evolution The developer must outline assumptions on which the system is based, anticipated changes due to hardware and software evolution and changes in user requirements. 2.1.4 System Scope This stage involves establishing the system boundary. A system boundary depicts the parts of the original requirements that are to be computerised. The developer must realise that that the boundary may or not may enclose all requirements. When setting up a system boundary the developer must consider among other things, the available resources, user requirements and other limitations in implementing the system. Further this section must give a description of system components and the system environment 2.1.5 Prototyping Developers may use this technique if they want to validate the requirements. Prototyping involves developing a quick and dirty but still convincing model of the final system. The developer must articulate the goals of prototyping, functions prototyped and results of the prototyping process. 2.1.6 User Interface Design Give a detailed description of the system user interface including diagrams of all the ``work'' windows (or screens or panes), a table of operations for each work window, and precise descriptions of each operation that the user would regard as unfamiliar. A work window is one that contains data the user is editing, browsing or viewing. This section is required for all programs that engage the user interactively. 2.1.7 Other User Inputs Give a precise description of the other inputs to the system including source (human or storage) syntax (format) and semantics (meaning). Give examples. This section is required for all programs that obtain input from their environment non interactively. 2.1.8 Other User Outputs Give a precise description of the other outputs of the system including syntax and semantics. Prepared by Zanamwe N @ 2013 3 Correlate the outputs with the inputs and the functions performed. Give examples. This section is required for all programs that obtain input from their environment non interactively. 2.1.9 System Data Files Give a precise description of the data files created or maintained by the system. Thus, for example, you would include files in a database and you would exclude executable files and text files. 2.1.10 User Interface Specification ● Interface Metaphor Model ● User Screens/Dialog ● Report Formats/Sample Data ● Online Help Material ● Error Conditions and System Messages ● Control Functions 2.3. Feasibility Study A feasibility study decides whether or not the proposed system is worthwhile. The goal of feasibility study is to identify the existing system and note any problems associated with it, establish if any practical solutions exist and determine whether it is worthwhile to implement the system. A feasibility study checks the following: ∙ If the system contributes to organisational objectives ∙ If the system can be engineered using current technology and within budget ∙ If the system can be integrated with other systems that are used. The developer must therefore conduct the following feasibility studies 2.3.1 Economic feasibility Involves establishing whether it is possible to implement the system using the existing monetary resources (hardware and human resources). Economic feasibility study also involves carrying out a cost benefit analysis for each of the alternative solution. 2.3.2 Technical Feasibility To a larger extent this involves assessing the knowledge and skills that the system developer has and establishing whether it is possible to develop the system using the existing level of skills and knowledge. 2.3.3. Operational Feasibility An operational feasibility study tries to figure out whether upon completion the system is going to be usable in the intended environment. 2.4.System Performance Requirements Prepared by Zanamwe N @ 2013 4 2.4.1 Efficiency (speed, size, peripheral device usage) 2.4.2 Reliability ∙ Description of Reliability Measures (accuracy, precision, consistency, reproducibility, etc.) ∙ Error/Failure Detection and Recovery (failure modes, failure consequences, error logging and reporting, manual and automatic recovery procedures) ∙ Allowable/Acceptable Error/Failure Rate 2.4.3 Security ∙ Hardware Security ∙ Software Security ∙ Data Security ∙ Execution Security (user validation) 2.4.4 Maintainability 2.4.5. Modifiability 2.4.6. Portability 2.5 Conclusion Give a chapter conclusion CHAPTER THREE 3. Project planning and Literature Review 3.1. Introduction Give a chapter introduction 3.2. Project planning and scheduling The project developer must clearly articulate the deliverables and milestones. Students can also using project planning tools such as bar charts, project network charts, Gantt charts etc. Project planning software may also be used. 3.3. Literature Review This is a historical or conceptual survey of relevant work done in the area by previous system developers. Each contribution must be accompanied by appropriate references to be listed in the reference section. The developer must identify existing systems that were developed to address the current problem and how they are inadequate or what are their weaknesses. Further the developer must identify process models that that will be used and a justification must be given as to why certain process models have been chosen. The user might choose process models such waterfall, spiral, incremental etc. Be sure to choose a process model that suits your project. Prepared by Zanamwe N @ 2013 5 3.4. Conclusion Give a chapter conclusion CHAPTER FOUR 4. System Analysis and Design This is a top level preliminary or provisional indication of the proposed system architecture and flow. You should correlate system functions with system structure and interface specifications. Further the developer should analyse both the existing and new system with the aim of obtaining a fuller understanding of the system. The developer can use questionnaires or interviews or both when investigating about the system. The developer must not use technical tools in the analysis. At this stage, the developer can make use of the following tools: dataflow diagrams, decision tables and trees, ERDs, sequence diagrams, use case diagrams, class diagrams, data dictionary, petri nets, state transition diagrams. 4.1.Introduction Chapter introduction 4.2.System Architecture 4.2.1. Data Flow Diagrams (level 1 and 2 DFDs) This is a hierarchical (or levelled) set of diagrams showing the flow of data elements into and out of the functional units of the program, data stores and environmental sources and sinks. Labelled arrows denote data flows. This diagram is complementary to the structure chart described next. 4.2.2. Entity Relationship Diagram This is a conceptual model of a system showing the entities and their attributes as well as the relationships between or among entities. 4.2.3. System Structure Chart(s) This is a (set of) chart(s) showing the functional units of the system hierarchically organized to show which units call, use or contain other units. Each interface between two units (a call) is annotated with small arrows and data item labels to show the data exchanged between the units. 4.2.4. System Data Dictionary This is a comprehensive dictionary of all the data items that appear in the system data flow diagrams and the structure charts. At a minimum it contains, for each data item, its identifier, any abbreviation used instead of the identifier, the name of the type of the data, and a definition of the data item in the form of either a symbolic expression or a precise description. The most Prepared by Zanamwe N @ 2013 6 appropriate way is to come up with data dictionary for each and every technique that the developer would have used. The data dictionary should be part of every project. 4.2.5. Equipment Configuration Describe the equipment you will use to support the operation and development of your system. 4.3. System Data Structure Specifications 4.3.1. Other User Input Specification 4.3.1.1.Identification of Input Data 4.3.1.2.Source of Input Data (NOT input device) 4.3.1.3.Input Medium and/or Device 4.3.1.4.Data Format/Syntax 4.3.1.5.Legal Value Specification 4.3.2. Other User Output Specification 4.3.2.1. Identification of Output Data 4.3.2.2. Destination of Output Data (NOT output device) 4.3.2.3 Output Medium and/or Device 4.3.2.4 Output Format/Syntax 4.3.2.5 Output Interpretation (meaning of output) 4.3.3. System Database/File Structure Specification 4.3.3.1Identification of Database/Files 4.3.3.2 (Sub) systems accessing the Data Base (creating, updating, using; frequency) 4.3.3.3 Logical File Structure (record formats, file organization, access methods, rationale, examples) 4.3.3.4 Physical File Structure (storage device, blocking, organization, access, etc.) 4.3.3.5 Data Base Management Subsystems Used (internal or external) 4.3.3.6 Data Base Creation and Update Procedure (if NOT by system) 4.3.4 System Internal Data Structure Specification 4.3.4.1.Identification of Data Structures 4.3.4.2.Modules Accessing Structures (creating, updating, using) 4.3.4.3.Logical Structure of Data (format, organization, access, rationale, examples) 4.4. Module Design specifications 4.4.1. Module Functional specification 4.4.1.1 Functions Performed 4.4.1.2 Module Interface Specifications (input/output arguments/global variables/files) 4.4.1.3 Module Limitations and Restrictions 4.4..2 Module operational Specification 4.4.2.1 Locally Declared Data Specifications (variable dictionary) 4.4.2.2 Algorithm Specification (flowchart, pseudo code, decision table, etc) 4.4.2.3 Description of Module Operation Prepared by Zanamwe N @ 2013 7 4.5. Conclusion Chapter conclusion CHAPTER FIVE 5 Implementation and Testing 5.1. Introduction Chapter introduction 5.1. Choosing the language List the programming languages or scripting languages you have used for the implementation of your project and give reasons for choosing each language. 5.2. Choice of environment Indicate where applicable the databases that were used and justify why you chose for instance Oracle instead of MySQL or vice versa. Indicate the operating system used and web servers and other web authoring tools used and do not forget to justify why you chose those tools. 5.3.Language specific algorithm 5.4.Efficiency 5.5.Correctness 5.6.Documentation of code 5.7.Variables 5.8.System verification/ testing 5.8.1. Items/Functions to be Tested 5.8.2. Description of Test Cases 5.8.3. Justification of Test Cases 5.8.4. Test Run Procedures and Results 5.8.5. Discussion of Test Results 5.8.6. Evaluation of User System 5.8.6.1.Protocol Study 5.8.6.2.User Survey 5.8.6.3.Real Time Monitoring 5.8.6.4.Interviews 5.9.Conclusion Chapter conclusion Prepared by Zanamwe N @ 2013 8 CHAPTER SIX 6. Conclusions 6.1.Summary 6.2.Problems Encountered and Solved 6.3.Suggestions for Better Approaches to Problem/Project 6.4.Suggestions for Future Extensions to Project REFERENCES APPENDICES Any other attachments Program Listing User manual CDs or DVDs containing the System and Documentation where necessary, provide passwords and usernames for logging into the system. Style and Policy Manual for Software Projects Dear Student The aim of doing a project is to solve a real world problem using computer science skills at your disposal. A software project is the outcome of a substantial effort. Its content and style will reflect Prepared by Zanamwe N @ 2013 9 on you, your supervisors and on the Computer Science Department. By adhering to the standards set forth in the following pages you will be presenting your work in a professional manner, to the credit of all who have contributed to it. Statement on plagiarism The Computer Science Department takes plagiarism very seriously and will never ever tolerate it. To the uninitiated, Plagiarism refers to the use of other people’s intellectual property (words, ideas, diagrams, code etc) without appropriately acknowledging the sources of these materials. This constitutes plagiarism whether it is intentional or unintentional and whether it is the work of another or of you. Students are therefore strongly warned against downloading software projects from the internet or getting them from other universities across the world and posing as if they are the original developers of those projects. Supervisors must make an effort to ensure that students submit plagiarism free projects by using the antiplagiarism software. It is also the responsibility of the student to make sure that their work is free from any form of plagiarism. Requirements for Projects Please note the following: 1) The report should be printed on one side of the page, 2) Number each sheet consecutively at the bottom of the page. 3) Headings: Chapter titles start on a new page. Chapter numerals should be Arabic, not Roman numerals. Type the chapter number and title in upper and lower case, flush left, at the top of the report page; leave an extra space and then begin the text. Since you will have several levels of subheadings, distinguish one level from another in a consistent way, such as (1, 1.1, 1.2, 2, 2.1, 2.1.1, 2.1.2, 2.2). Avoid having more than three levels of subheadings. 1. Text formatting ∙ The font size must be 12. Subscripts or superscripts must not be smaller than 9 point. Students must note that projects using oversized or small font sizes will not be accepted. These requirements apply only to body text implying that students can use font sizes greater than 12 for chapter headings. The same typeface and size must be used throughout the text. Students are recommended to use a standard, clearly legible font for example Times New Roman or Arial. Exotic fonts will not be accepted. Bold, italics, and underlines are acceptable, but only if they remain in the same character size as the rest of the text. If you have any questions regarding a particular font, please bring an original example to the coordinators. ∙ The text of the project must be presented with full justification on the prescribed margins. ∙ Line spacing must be 1.5 ● Change language to Zimbabwean English ● Do not use abbreviated words such as; can’t, don’t, &, ie, etc Prepared by Zanamwe N @ 2013 10 ● No one or two sentence paragraphs ● Students must place caption below Figures and above Tables, their numbering must show chapter for example a table in chapter 2 can be given a caption ‘Table 2.1’ ∙ Margins: margin refers to the blank space surrounding printed text. The mechanics of binding require that projects have at least a 1.5inch margin on the binding side of the page and a 1inch margin on the remaining three sides. No margin may be greater than 1.5 inches. Please note that the page number is included in the text area and must not violate the margins. The margin above the page number must be at least 1 inch. Insufficient margins seriously affect the readability and appearance of the project. Students must note that projects that do not meet these requirements will not be accepted. Margin requirements apply to all materials to be bound within the project, including appendices. ∙ Be consistent in style, that is, do not use more than one font type in the same document or embolden other headings while others are not. ∙ Do not use bullets when numbering sections and subsections and when numbering subsections, your numbering must reveal the chapter for example, 4.3.2 means the second subsection in the third section of chapter 4 ∙ Do not to start a sentence with a number ∙ The final copies must be neatly executed and correct in spelling, punctuation, and format. ∙ The print must be of the same intensity throughout. Corrections on the submitted copies (i.e., whiteout, correction tape, interlineations, etc.) will not be accepted. 2. Pagination Students must note that two separate numbering systems are used in formatting projects: 2.1 Preliminary Pages The Title Page is page one but is not numbered so the page two is numbered ii. Small roman numerals ( ii, iii, iv, etc.) are used for all other preliminary pages, including subsequent pages of the Abstract, Table of Contents, List of Figures, List of Tables, Acknowledgments, Dedication, etc. The numbers must appear in the upper righthand corner of the page at least 1 inch from the edge of the paper to allow for the standard margin. A Preface is optional but if it is included, it must be listed in the Table of Contents. 2.2 Text The text is numbered with Arabic numerals, without embellishment or punctuation (i.e., initials, hyphens, running heads or footers, lines across the page, etc.,). Page numbers must be centred at the top of the page or placed in the upper righthand corner so that they are at least 1 inch from the top and right edges of the paper. Only whole numerals are acceptable and must be in the same typeface and location throughout. Pages numbered 56a, 56b, etc., will not be accepted. Every page must have a page number. However, the number will not appear on the following pages: a. The first page of text. (The second page is page 2.) b. The first page of each Chapter, the first page of the Bibliography or References Cited, c. The first page of each Appendix. Prepared by Zanamwe N @ 2013 11 d. Minor sections within chapters are not considered title pages and must carry a page number. 3. Illustrations Illustrations refer to informational material that illustrates and enhances the text. Figures and tables are all examples of illustrations and are either inserted throughout the text, appearing as soon as possible after the references to them have been made, or grouped at the end of each chapter. Whichever method you choose, you must use it consistently for all the figures, tables, or other illustrations included. Students are discouraged from including illustrations which are not referred to, implying that you must refer to each and every illustration All illustrations must conform to the margin requirements. Please consult a project coordinator for help with an oversize illustration. If an illustration continues for more than one page, subsequent pages are numbered consecutively with the rest of the text. The illustration number followed by the word continued appears placed appropriately. (EXAMPLE: Fig 4.3 (continued)). All illustrations, including those appearing in appendices, must be numbered, titled, and listed in the appropriate preliminary pages. They may be numbered consecutively throughout the text or within each chapter or appendix. If you choose to number them within each chapter or section, they must be identified with the chapter or section number. For example: Figure 2.2_(Title), Table III.3_(Title). Illustrations in previously published material which you are presenting as appendices may retain the original identification and should not be listed in the preliminary pages. 4. Captions and Legends A caption consists of the illustration number (e.g., Table 2:) and its title. Captions may be single spaced and must all be in the same typeface. If illustrations are reduced, the caption and page number must remain the same size as the text. If illustrations appear horizontally (i.e., landscape format) in the text, the top must be on the left margin, and the caption, must also appear horizontally. The page number remains vertical (i.e., portrait format), consistent with the rest of the text. Tables Tables contain information placed in a columnar arrangement and are the only illustrations numbered and captioned above. Figures Figures may include DFDs, ERDS, photographs (original or photocopied), charts, diagrams, graphs, and drawings. They must all be listed in the preliminary pages in a List of Figures. Figure titles in the List of Figures may be abbreviated, if necessary. Figure numbers and captions appear below the figure. 5. List of references A List of References is a comprehensive list of all sources used by the project developer and is required at the end of each project, appearing immediately after the text. The Department of Prepared by Zanamwe N @ 2013 12 Computer Science will accept any recognized format but it must be used consistently throughout. Full citation must appear in alphabetical order at the end of text. Note that all sources must appear in the text and in references. No source must be included in the reference list that has not been directly referred to in the body of the project. The next sections present the Harvard referencing format. Students should not confuse referencing and a reference list which are two different but related concepts. Referencing refers to citing sources inside the body of the project and the standard is to just include the surname of the author and the date of publication as follows: ∙ If author’s surname forms part of sentence, the year follows in parentheses as given below: As illustrated by Sipser (1996), theory of computation deals with complexity theory and computability theory. ∙ If author’s name is not part of sentence, both the author and year are shown in parentheses: Theory of computation deals with complexity theory and computability theory (Sipser, 1996) ∙ When referring to a particular page, this is given in parentheses after the year: “Theory of computation deals with complexity theory and computability theory (Sipser, 1996:56) ∙ Direct quoting a full paragraph: here you have to indent paragraph and use difference format, there is no need for quotation marks. The author, year and page must be provided ∙ If author has more than one publications in different years, use chronological order in reference list but if publications are in the same year, use letters a, b after the year to distinguish; (Cohen, 2006a), (Cohen, 2006b) ∙ When no author is given, appropriate body or institution should be used: (University of Zimbabwe, 2006) or (World Bank, 2007) ∙ When the reference is not the original source: Date (2005) cited in Navathe and Elmasri (2006), ∙ Citing more than one author: If there are two authors, both should be given: Navathe and Elmasri (2003) aver that… If there are more than two authors, all should appear the first time, thereafter, author et al. (year). Note that the order of authors must be strictly adhered to ∙ Referencing abbreviations (in the body of the project) o Author not given (Anon) o Date not given (n.d.) o No place, sine loco (s.l.) o No publisher, sine nomine (s.n.) Reference list: a reference list on the other hand is an elaborate list of sources that you referred to and it must include the titles of books or articles and publishers 1. Author(s) or editors of articles 2. Date of publication (in brackets) 3. Title of article (in single quotes) Prepared by Zanamwe N @ 2013 13 4. Title of journal (underlined) o Volume, part number (where available) o Page numbers of articles 5. Title of book (underlined) o Place of publication o Publisher(s) 6. Book with one or two authors: o Navathe, Elmasri (2001). Database Systems. London: MacMillan 7. Author, I. (year) ‘Title’. [Website] (date when the web was viewed or downloaded) 8. Surname of journalist, Initial. (year) ‘title of article’. Name of Newspaper. Date, page 9. Author, Initial. (Year) ‘Title of paper’. Paper presented at name of conference, place of conference, month of conference 6. Appendices Appendices may consist of material that is related to, but not appropriate for, inclusion in the main body of the project. This includes user manuals, code listing, CDs or DVDs etc. They appear after the List of References and must be titled. They are listed, along with their titles, in the Table of Contents, not on a separate list of appendices. Pagination is continuous with the project, and the first page of each appendix is treated like the first page of a chapter in the text (i.e., counted, but not numbered). Appendix material need not be retyped unless it does not meet the above requirements for margins and readability. Material may be reduced as long as it remains legible. However, appendix titles and page numbers must remain fullsize; it is recommended that they be added to the page after reduction. Any illustrations appearing in the appendices which are not from previously published material must be captioned and placed in the appropriate list. 7. Arrangement of pages All projects submitted to the Computer Science Department must include the following in the order listed: 1. Title page The Title Page must include the correct project title, the correct degree title, the correct year, and the student’s first and last names conforming exactly to University records. The title page must also include the name of the supervisor and the year the project was done. Further, the title page must include the name of the university and department. See sample below. All text appearing on the Title Page must be centred on the margins. 2. Dedication (optional) 3. Declaration (Mandatory see sample below) Prepared by Zanamwe N @ 2013 14 4. Abstract An abstract is a single paragraph in which you summarize the essence of your project: why the software was developed, what problem was solved, how the problem was approached, what major results were found, what major conclusion were drawn. It would be unusual for an abstract to be longer than two pages. 5. Table of Contents. Each project must have only one Table of Contents listing all of the chapters or main sections and their appropriate page numbers. The listing of subsections within chapters is optional. Only major sections, whether called chapters or not, will start on a new page; sections within chapters must be contiguous with the previous text. The numbering and wording of titles and headings in the Table of Contents must be consistent with the text. All preliminary pages must be included in the Table of Contents except the Title Page and Declaration Page. Each appendix must be identified separately, including a title, and must be listed in the Table of Contents, NOT on a separate List of Appendices. Appendices are paginated consecutively with the text. Pocket materials must also be included in the inside back cover and must be listed after the appendices. Students must include a CD or DVD with the executable system. 6. List of Figures If your project includes any figures you must identify them in a List of Figures, in the preliminary pages. 7. List of Tables If your project includes any tables you must identify them in a List of Tables in the preliminary pages. Each List of Figures, List of Tables, or List of Illustrations included in the preliminary pages must appear on a separate page and must be numbered in small Roman numerals centred at the bottom of the page, at least one inch from the edge of the paper, in the order in which they are to be bound. All illustrations must be numbered and titled. Captions must appear on the appropriate list in the preliminary pages. These may be abbreviated titles if the full title is too long for inclusion. 8. Glossary (optional) 9. List of Abbreviations (optional) 10. Preface (optional) 11. Acknowledgments. Acknowledgments recognize the people to whom you are indebted for guidance and assistance and those to whom you are grateful for any special or nonroutine aid. Acknowledgments should be expressed simply and tactfully. They should be oneandonehalf or doublespaced and conform to margin requirements. Acknowledgments are numbered consecutively with the other preliminary pages with small Roman numerals centred at the bottom of the page. Please note: Acknowledgments and/or Dedication are not listed in the Table of Contents. 12. Dedication (optional). 13. Main body of the project. Prepared by Zanamwe N @ 2013 15 14. Bibliography or List of References. 15. Appendices (list your code here and the user manual). 16. Pocket Materials (CDs containing the software, remember to provide logon details and instructions on how the system operates) Declaration Sample I, Ngonidzashe Zanamwe, do hereby declare that this project is the result of own investigation and research, except to the extent indicated in the Acknowledgements and References and by acknowledged sources in the body of the report, and that it has not been submitted in part or full for any other degree to any other University or College. Signature............................................................................Date......................................... Title Page Sample: Development of a Membership Management Information System for use by Church Organizations By Ngonidzashe Zanamwe A project submitted in partial fulfillment of the requirements for the degree of Bachelor of Business Studies and Computing Science 2002 Prepared by Zanamwe N @ 2013 16 Computer Science Department University of Zimbabwe Supervisor: Dr. Hapanyengwi Prepared by Zanamwe N @ 2013 17