Project Documentation For Web
Project Documentation For Web
MASTER OF SCIENCE
IN
CHEMISTRY
January 2017
DECLARATION
I hereby declare that the contents of the thesis, “Title” is product of my own research and no part
has been copied from any published source (except the references, standard mathematical and
genetic models/ equations/ formula/ protocols etc.). I further declare that this work has not been
submitted for award of any diploma/ degree. The university may take action if the information
provided is found inaccurate at any stage (in case of default the scholar will be proceeded against
as per HEC plagiarism policy).
Name of Student
Registration No
(Sample Certificate Page)
This is one of the most important chapters of the report. It should begin with a clear
statement of what the project is about so that the nature and scope of the project can be
understood by any reader. It should summaries everything you set out to achieve, provide
a clear summary of the project’s background, relevance and main contributions. The
introduction should set the context for the project and should provide the reader with a
summary of the key things to look out for in the remainder of the report. When detailing
the contributions it is helpful to provide pointers to the section(s) of the report that provide
the relevant technical details. The introduction itself should be largely non-technical. It is
useful to state the main objectives of the project as part of the introduction. Should have
the following headings:
• Project Background/Overview
• Problem Description
• Project Objectives
• Project Scope
Chapter 2
Literature Review
Literature review is a systematic method of identifying, evaluating and interpreting the
work (similar to yours) produced by others. This chapter should set the project into context
and give the proposed layout for achieving the project goals. It is an important chapter
especially if the project involves significant amount of ground work. Review prior work
critically, identify gaps in knowledge/areas of application and build an argument for your
own work. When referring to other pieces of work, cite the sources where they are referred
to or used, rather than just listing them at the end
Chapter 3
Requirement Specifications
In this chapter, first describe the existing system, its limitations or drawbacks and then
explain how the new or proposed system will overcome these problems. This should then
be followed by complete requirements specification for the proposed system. Describe
the behavior of the system to be developed and include a set of use cases that describe
interactions the users will have with the system. In addition also describe non-functional
requirements. Non-functional requirements impose constraints on the design or
implementation (such as performance engineering requirements, quality standards, or
design constraints). Should have the following headings:
• Existing System
• Proposed System
• Requirement Specifications
• Use Cases
Chapter 4
Design
System design is the process of defining the elements of a system such as the architecture,
modules and components, the different interfaces of those components and the data that goes
through that system. It is meant to satisfy specific needs and requirements of a business or
organization through the engineering of a coherent and well-running system.
Systems design implies a systematic approach to the design of a system. It may take a bottom-
up or top-down approach, but either way the process is systematic wherein it takes into account
all related variables of the system that needs to be created—from the architecture, to the
required hardware and software, right down to the data and how it travels and transforms
throughout its travel through the system. Systems design then overlaps with systems analysis,
systems engineering and systems architecture.
https://www.techopedia.com/definition/29998/system-design
Systems design is the process of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements. This chapter should
have the following sections:
4.1 System Architecture
Web applications give to content from a server to client machines over the internet and the users view the web
applications between a web browser. This project uses client/server architecture. It is hosted on the web server and
responds from other clients, as shown in Figure.
This section describes the system in narrative form using non-technical terms. It should
provide a high-level system architecture diagram showing a subsystem breakout of the
system, if applicable. The high-level system architecture or subsystem diagrams should,
if applicable, show interfaces to external systems. Supply a high-level context diagram
for the system and subsystems, if applicable.
4.2 Design Constraints
This section describes any constraints in the system design (reference any trade-off
analyses conducted such, as resource use versus productivity, or conflicts with other
systems) and includes any assumptions made during the developing the system design.
4.3 Design Methodology
Summarize the approach that will be used to create and evolve the designs for this
system. Cover any processes, conventions, policies, techniques or other issues which
will guide design work. This is for deciding whether you will use structured, object-oriented
or other specific methodologies. Most people will use some object-oriented technique with
UML.
4.4 High Level Design
This section describes in further detail elements discussed in the Architecture. High-level
designs are most effective if they attempt to model groups of system elements from a
number of different views. Typical viewpoints are:
1. Conceptual or Logical: This view shows the logical functional elements of the system.
Each component represents a similar grouping of functionality. For UML, this would be a
component diagram or a package diagram.
2. Process: this view is the runtime view of the system. The components are threads or
processes or distributed applications. In UML, this would be a process interaction
diagram.
3. Physical: this view is for distributed systems. The components are physical processors
that have parts of the system running on them. For UML, this would be a deployment
diagram.
4. Module: this view is for project management and code organization. The components
are typically files or directories. This picture shows how the directory structure of the build
and development environment will be designed.
5. Security: The Online Real Estate System uses JavaScript forms authentication to allow users to
access secure web sites such as editing property information. this view typically focuses on the
components that cooperate to provide security features of the system. It is often a subset
of the Conceptual view.
4.5 Low Level Design
This section provides low-level design descriptions that directly support construction of
modules. Normally this section would be split into separate documents for different areas
of the design. For each component we now need to break it down into its fundamental
units or modules. For an OO implementation in Java, our components would become
packages.
Then the low level design will take each package and break it down into its classes. For
smaller systems, you may have a single UML class diagram that each module description
refers to.
4.6 Database Design
The section should reveal the final design of all database management system (DBMS)
files and the non-DBMS files associated with the system under development. Provide a
comprehensive data dictionary showing data element name, type, length, source,
validation rules, maintenance (create, read, update, delete capability), data stores,
outputs, aliases, and description.
4.7 GUI Design
This section provides the detailed design of the system and subsystem inputs and outputs
relative to the user. Depending on the particular nature of the project, it may be
appropriate to repeat these sections at both the subsystem and design module levels.
4.8 External Interfaces
External systems are any systems that are not within the scope of the system under
development. In this section, describe the electronic interface(s) between this system and
each of the other systems and/or subsystem(s), emphasizing the point of view of the
system being developed.
Chapter 5
System Implementation
Implementation is the process of moving an idea from concept to reality. The System
implementation is a realization of a technical specification or algorithm as a program,
software component, or other computer system through programming and deployment.
5.1 System Architecture
Describe the architecture e.g. in terms of: System internal components, Functionality of
the components, Communication between the components Tools and Technology Used
Development Environment/Languages Used Processing Logic/Algorithms Application
Access Security Describe new application access related security measures, e.g. in terms
of: Security Zones/Firewalls, Encryption, Authentication, e.g. Account & Password
structures and rules, Authorization, e.g. operator rights and roles, authority handling,
Auditing / Access Logging, Safe Data Storage Database Security
Describe new DB related security measures, e.g. in terms of: Remote Access,
Authentication (Account & Password: structure, rules), Authorization (rights/roles,
handling), Anonymous and Group Users, Auditing/Logging (events, data, log handling).
Chapter 6
System Testing and Evaluation
The project’s conclusions should list the things which have been learnt as a result of the
work you have done. For example, "The use of overloading in C++ provides a very elegant
mechanism for transparent parallelisation of sequential programs". Avoid tedious
personal reflections like "I learned a lot about C++ programming..." It is common to finish
the report by listing ways in which the project can be taken further. This might, for
example, be a plan for doing the project better if you had a chance to do it again, turning
the project deliverables into a more polished end product.
References
It is important that the students should go to the primary sources of information and an effort
always be made to obtain the information from original articles published in a journal or a reprint
obtained from the author. The tendency to cite the literature from abstracting journals is neither
enough nor in scientific spirit. In only unavoidable circumstances, the secondary source of
information may be utilized or when the original article is in a language other than English.
Secondary reference(s) should be written in parenthesis after quoting primary reference without
the main heading. Following points should be kept in mind while enlisting references.
i. References should be arranged alphabetically according to author and then according to
the year.
ii. A complete reference includes author(s), year of publication, complete title of the paper,
and reference to journal
iii. The number of the issue of the volume of a journal may not be given, unless paging of each
number starts from 1 or issue number may be given in all the references consistently.
iv. In case of book, the name of the author(s), year of publication, title, edition and complete
address of the publisher must be given and should not be underlined.
v. Names of journals and number of their volumes should not be underlined.
vi. The words ‘Idem’ and ‘Ibid’ may be avoided in citing references.
vii. The word ‘References’ may be used in preference to ‘Literature Cited’.
viii. The title must appear exactly as it does on the first page of article or the title page of the
book.
ix. For titles of scientific papers, only the first letter of the first word is capitalized. (exceptions
are proper names, scientific names or certain other words which are capitalized always).
x. The family name of the first or sole author precedes the initials or given names. The names
of co-author(s) follow in normal order and are separated by comma.
xi. When the reference is the proceedings of a symposium etc. and the author to be cited is the
editor, it may be indicated as such in parenthesis.
xii. References except of publication by Government department or other organization for
which no author is known, may be listed as Anonymous.
xiii. In case of publications of organizations, learned societies or Government department, the
name of the organization, Government department, Ministry or Division be given in place
of author, if no author is indicated in the publication.
xiv. Work of authors, whether individual or joint should be discussed under different topics or
headings in the review, i.e. integration and analytical treatment.
xv. There are many systems of writing References in vogue in various sciences and journals.
With this end in view, a model list is given below to be followed for uniformity in the thesis
preparation.
2. Nazli, Z. H., M. Arshad and A. Khalid. 2003. 2 – Keto – 4 – methyl thiobutyric acid dependent
biosynthesis of ethylene in soil. Biol. Fertil Soils, 37(): 130–135.
3. Arshad, M. and Z. A. Zahir. 2004. Kinetics of effects of trace elements and electron complexes
on 2 – Keto – 4 – methyl thiobutyric acid – dependent biosynthesis of ethylene in soil . Letters
in Applied Microbiology. 39(): 306 – 309.
Appendices are generally included to help clarification and make readers Understand statements
in the main body of theses or dissertations. In addition, sometimes appendices are useful to support
the interpretation of results. This becomes a record of data for different computations later by the
author or the readers