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