Table of Contents

1 Introduction......................................................................................................................................... 3

2 Background and Literature Survey............................................................................................3

3 Design...................................................................................................................................................... 3

3.1 Use Cases.....................................................................................................................................................3

3.1.1 Use Case 1............................................................................................................................3

3.1.2 Use Case 2............................................................................................................................3

3.1.3 Use Case 3............................................................................................................................3

3.2 Architecture...............................................................................................................................................3

3.3 Activity Diagrams....................................................................................................................................3

3.4 Data Flow Diagram.................................................................................................................................3

3.5 Entity Relation Diagram.......................................................................................................................3

3.6 Class Diagrams.........................................................................................................................................3

3.7 Sequence Diagrams................................................................................................................................3

4 Implementation.................................................................................................................................. 3

4.1 Pseudo code...............................................................................................................................................3

4.2 Screen Shots.............................................................................................................................................. 3

5 Testing.................................................................................................................................................... 3

6 Evaluation and Results....................................................................................................................3

7 Conclusion............................................................................................................................................. 3

8 Help (Delete this after using)........................................................................................................3

8.1 References..................................................................................................................................................3

8.2 Font Size......................................................................................................................................................3

8.3 TOC and Headings...................................................................................................................................3

8.4 Table of Figures........................................................................................................................................3

2

9 Bibliography......................................................................................................................................... 3

3

Figure 8.1: Some figure.............................................................................................................................3

4

1 IntroductionThis chapter puts the work into context. Having read it, the reader should be left in

no doubt as to:

the agreed project proposal

why the work is being done

what else has been done in the area and by whom

how the author proposes to tackle the problem

Gant Chart showing project schedule 

The project proposal is often expressed in terms of a main objective and possibly

one or more additional objectives. It is useful to define "milestones" or "sub-goals"

that mark the progress towards the objectives. Refer to the project plan, which

should be included as an appendix.

It is common to end this chapter with a brief overview of each of the subsequent

chapters of the report.

5

2 Background and Literature SurveyThis chapter should give essential background information with references to

published material in research papers, books, URLs, magazine articles and even

newspapers. Expand on any references to other work that have been mentioned in

Chapter 1. Refer to the notes on References (below) for the preferred way of

referencing publications. The reader, stimulated by the presentation of ideas in this

section, may be led to consult some or all of the referenced publications. This

section will be useful for any student in a subsequent year who wishes to take the

project further. This chapter could also be an appropriate place to justify the choice

of platform and software used in the project.

6

3 DesignThis chapter starts to describe the student's own work. It is where the main design

aspects of the project are described. The style of presentation may reflect the life

cycle of the project, for example commencing with the Requirements Analysis, but it

should not read like a diary. The design should be clearly and precisely described

with supporting diagrams. The presentation should be at a fairly high level without

excessive detail.

3.1 Use Cases

A use case in software engineering and systems engineering is a description of a

system’s behavior as it responds to a request that originates from outside of that

system. In other words, a use case describes "who" can do "what" with the system in

question. The use case technique is used to capture a system's behavioral

requirements by detailing scenario-driven threads through the functional

requirements.

3.1.1Use Case 1

3.1.2Use Case 2

3.1.3Use Case 3

…………………………………………..

7

3.2 Architecture

The software architecture of a program or computing system is the structure or

structures of the system, which comprise software components, the externally

visible properties of those components, and the relationships between them. The

term also refers to documentation of a system's software architecture. Documenting

software architecture facilitates communication between stakeholders, documents

early decisions about high-level design, and allows reuse of design components and

patterns between projects.

3.3 Activity Diagrams

Activity diagrams are graphical representations of workflows of stepwise activities

and actions with support for choice, iteration and concurrency. In the Unified

Modeling Language, activity diagrams can be used to describe the business and

operational step-by-step workflows of components in a system. An activity diagram

shows the overall flow of control.

3.4 Data Flow Diagram

A data-flow diagram (DFD) is a graphical representation of the "flow" of data

through an information system. DFDs can also be used for the visualization of data

processing (structured design).

On a DFD, data items flow from an external data source or an internal data store to

an internal data store or an external data sink, via an internal process.

A DFD provides no information about the timing or ordering of processes, or about

whether processes will operate in sequence or in parallel. It is therefore quite

different from a flowchart, which shows the flow of control through an algorithm,

allowing a reader to determine what operations will be performed, in what order,

and under what circumstances, but not what kinds of data will be input to and

8

output from the system, nor where the data will come from and go to, nor where the

data will be stored (all of which are shown on a DFD).

3.5 Entity Relation Diagram

An entity-relationship (ER) diagram is a specialized graphic that illustrates the

interrelationships between entities in a database. ER diagrams often use symbols to

represent three different types of information. Boxes are commonly used to

represent entities. Diamonds are normally used to represent relationships and ovals

are used to represent attributes.

9

4 ImplementationThe implementation details should be confined to the important, difficult or

interesting aspects. Large chunks of code should be avoided, and diagrams and

tables should be used to present details clearly.

4.1 Class Diagrams

In software engineering, a class diagram in the Unified Modeling Language (UML) is

a type of static structure diagram that describes the structure of a system by

showing the system's classes, their attributes, and the relationships between the

classes.

4.2 Sequence Diagrams

A sequence diagram in Unified Modeling Language (UML) is a kind of interaction

diagram that shows how processes operate with one another and in what order. It is

a construct of a Message Sequence Chart.

Sequence diagrams are sometimes called Event-trace diagrams, event scenarios,

and timing diagrams.

4.3 Pseudo code

Pseudo code is a compact and informal high-level description of a computer 

programming algorithm that uses the structural conventions of a programming 

language, but is intended for human reading rather than machine reading. Pseudo

code typically omits details that are not essential for human understanding of the

algorithm, such as variable  declarations, system-specific code and subroutines. The

programming language is augmented with natural   language descriptions of the

details, where convenient, or with compact mathematical notation. The purpose of

10

using pseudo code is that it is easier for humans to understand than conventional

programming language code, and that it is a compact and environment-independent

description of the key principles of an algorithm. It is commonly used in textbooks

and scientific publications that are documenting various algorithms, and also in

planning of computer program development, for sketching out the structure of the

program before the actual coding takes place.

No standard for pseudo code syntax exists, as a program in pseudo code is not an

executable program. Pseudo code resembles, but should not be confused

with, skeleton   programs  including dummy   code, which can be compiled without

errors. Flowcharts can be thought of as a graphical alternative to pseudo code.

4.4 Screen Shots

11

5 TestingThis chapter should give details of how the system designed and implemented by

the student was tested. The data and results obtained from this testing should be

presented and consideration be given as to whether or not these results confirm

that everything works correctly.

12

6 Evaluation and ResultsThe analysis of test results is very important and some assessment of their

significance and quality must be given. Likely sources of error and inaccuracy

should be mentioned. Use graphs, bar charts and histograms where appropriate,

remembering to label all axes and give scales. The analysis is often done badly, thus

sacrificing marks.

Results which illustrate how the system designed by the students’ works in practice,

and how it is intended to be used, may be presented in this chapter. Screen shots

may be useful to illustrate how the software interacts with the user.

13

7 ConclusionThis can be a short chapter summarizing what has been achieved and what has been

learned from the achievement. It is different from the abstract. The main results of

the work should be highlighted with a critical appraisal of them indicating to what

extent the objectives agreed at the beginning of the project and outlined in Chapter

1 have been met. Discuss whether the project plan and milestones had to be

modified in the course of the project and if so why. Exaggerated claims are

counterproductive here. The author may consider how the achievements change the

state of the art in this subject. Recommendations for further activity are often

included in this chapter.

14

8 Help (Delete this after using)

8.1 References

There are a number of schemes for presenting references to the reader. Most

publications are very strict about their presentation and, unfortunately, there is no

unanimity of format across the range of relevant publications. The recommended

method, used in IEE and IEEE journals, is to identify each reference with a number

located at the appropriate point of the text in brackets, e.g. (42). This is the

recommended format for project reports in Computer Science. The list of references

included in your report must give all the relevant information to enable the reader

to find it.

This is an example of a reference (1)

8.2 Font Size

Use a font size of 12. The only allowable exceptions to this font are captions (not

smaller than 9 point) and headings (not larger than 20 points). Use of italics is

restricted to foreign words, books or periodical titles, taxonomic names, letters used

as statistical symbols or algebraic variables, test scores and scales.

15

8.3 TOC and Headings

If you want an entry into the Table of Contents then you must use one of the three

levels of Heading 1 – Heading 3 from the styles tab in Microsoft Word.

8.4 Table of Figures

Use caption option for the image to set the caption

Format: “Figure 1.1: Label”

Example

Figure 8.1: Some figure

16

9 Bibliography1. Tim Berners-Lee. Weaving the Web. New York : HarperSanFrancisco, 1999. 0-06-

251586.