Complete Final Project Documentation Guidelines-1

Department of Information Technology
Superior University Gujranwala
“Automation of Weltron Kitchenware”
Session: BSIT Spring 2015-2019
Project Supervisor: Sir Muhammad Bilal
Submitted By
Rana Malahim BITM-F15-017
Information Technology
Superior University Gujranwala
STATEMENT OF SUBMISSION
© Department of Information Technology 1

This is certify that), “Malahim Naseer” Roll no. (BITM-F15-017) has
successfully completed the final year project named as”Automation Of
Weltron Kitchenware Industry” at the Department of Information
Technology, Superior University, to fulfill the requirement of the
degree of Information Technology.
______________________ _____________________
Project Supervisor Project Coordination Office
Faculty of IT
______________________
Head of the Department

Acknowledgement
We truly acknowledge the cooperation and help make by Sir Muhammad Bilal , Head of
department, CS&IT(Evening), Superior University Gujranwala. He has been a constant
source of guidance throughout the course of this project. We would also like to thank Mr.
Uzair Ahmad our supervisor for his help and guidance throughout this project. We are
also thankful to our friends and families whose silent support led us to complete our
project.

Abstract
Due to ever increasing demand of transporting huge amount of information generated

from various sources such as voice, data, video, etc., modern telecommunication
networks have been transformed into all digital and broadband. Depending on the
characteristics of information sources and the availability of facility, the mode of
transportation can be either constant bit rate (CBR) using circuit switched networks or
variable bit rate (VBR) using packet switched networks. For efficient utilization of the
network, all kinds of information can be transported using BISDN (Broadband Integrated
Services Digital Network) and ATM (Asynchronous Transfer Mode) technology. One
important research area in Network Technology is the design of high-speed digital
network with good performance. The issues need to be investigated include modeling of
Variable Bit Rate video traffic, efficient assignment of different traffic classes with
diverse quality of services, optimal bandwidth allocation, routing and call admission
control etc. This project not only relates to study of Digital Subscriber Line, which is a
Broadband technology to provide high-speed data, voice and video but also addresses the
above-mentioned issues. What are the provisions made in DSL implement QoS quality of
service.

Chapter 4: User Interface Design
4.1. Introduction
A user interface design consists of three main parts:

Page elements should be visualized on paper before building them in the computer. Just
as you draw a site map to plan the site, use cartoons and storyboards to begin blocking
out the site’s appearance and navigational scheme.
1. Site maps
2. Storyboards
3. Navigational maps
4. Traceability Matrix
4.2. Site Maps

4.3. Story boards
First step: User will Log in
Second step: Dashboard will appear after successful logging in

User can move to any module from dashboard like this is the employee registration
module.
4.4. Navigational maps:
4.5 Trace-ability Matrix
Following columns are involved in the trace-ability matrix.
Feature: Order Placement

Use Case ID: UC-1

UI ID: UI-1
Priority: 1
Use Case Cross Ref: UC-2
DB Table Id: tbl-customer, tbl-online customer, tbl online order,
Online order delivery.
Elaborated Use-case ID: Order Placement
Dependent Classes: No dependent class.
Feature: Registration Request

Use Case ID: UC-2
UI ID: UI-2
Priority: 1
Use Case Cross Ref:
DB Table Id: tbl-customer , tbl-online customer.
Elaborated Use-case ID: Registration Request.
Feature: Order Maintenance

Use Case ID: UC-13
UI ID: UI-3
Priority: 1
Use Case Cross Ref: UC-1, UC-2.
Elaborated Use-case ID: Order Maintenance.
Feature: Functionalities.
Use Case ID: UC-5,Uc-6
UI ID: UI-3
Priority: 1
Use Case Cross Ref: UC-1, UC-2.
Elaborated Use-case ID: Order Maintenance.

Chapter 5: Software Testing
5.1 Introduction:
This deliverable is based on the IEEE standard of software testing i.e. IEEE SOFTWARE
TEST DOCUMENTATION Std 829-1998. This standard describes a set of basic test
documents that are associated with the dynamic aspects of software testing (i.e., the
execution of procedures and code). The standard defines the purpose, outline, and content
of each basic document. While the documents described in the standard focus on dynamic
testing, several of them may be applicable to other testing activities (e.g., the test plan
and test incident report may be used for design and code reviews). This standard may be
applied to commercial, scientific, or military software that runs on any digital computer.
Applicability is not restricted by the size, complexity, or criticality of the software.
However, the standard does not specify any class of software to which it must be applied.

The standard addresses the documentation of both initial development testing and the
testing of subsequent software releases. For a particular software release, it may be
applied to all phases of testing from module testing through user acceptance. However,
since all of the basic test documents may not be useful in each test phase, the particular
documents to be used in a phase are not specified. Each organization using the standard
will need to specify the classes of software to which it applies and the specific documents
required for a particular test phase.
The standard does not call for specific testing methodologies, approaches, techniques,
facilities, or tools, and does not specify the documentation of their use. Additional test
documentation may be required (e.g., code inspection checklists and reports). The
standard also does not imply or impose specific methodologies for documentation
control, configuration management, or quality assurance. Additional documentation (e.g.,
a quality assurance plan) may be needed depending on the particular methodologies used.
Following are standard artifacts, which must be included in this deliverable:

1. Test Plan
2. Test Design Specification
3. Test Case Specification
4. Test Procedure Specification
5. Test Item Transmittal Report
6. Test Log
7. Test Incident Report
8. Test Summary Report
5.2. Test plan
5.2.2. Outline
A test plan shall have the following structure:
a. Test plan identifier

b. Introduction
c. Test items
d. Features to be tested
e. Features not to be tested
f. Approach
g. Item pass/fail criteria
h. Suspension criteria and resumption requirements
i. Test deliverables
j. Testing tasks
k. Environmental needs
l. Responsibilities
m. Staffing and training needs

n. Schedule
o. Risks and contingencies
p. Approvals
The sections shall be ordered in the specified sequence. Additional sections may be
included immediately prior to Approvals. If some or all of the content of a section is in
another document, then a reference to that material may be listed in place of the
corresponding content. The referenced material must be attached to the test plan or
available to users of the plan.
Details on the content of each section are contained in the following sub-clauses.
5.2.2.1. Test plan identifier

The identifier has specific number that is “001”.
5.2.2.2. Introduction:
Testing phase start after completion of project . I am going to test this application as a
whole system and will check the communication between different pages and their back
end connectivity with database.
5.2.2.3. Test items

We will test all the forms present in application
 Log in page
 Sale Page
 Purchase page
 Employee registration page
 User management page
 Attendance page
 Customer record.
 Reports generation.
5.2.2.4. Features to be tested

Following features are going to be tested
 Log in system
 Sale system
 Purchase system
 Employee registration system
 User management system
 Attendance system
 Customer record entry

5.2.2.5. Features not to be tested
5.2.2.6. Approach
The approaches which we used to test application are Black Box and White Box.
5.2.2.7. Item pass/fail criteria

Passing criteria:
If all the forms of application are responsive , are communicating perfectly , record is
being saved in database as it was entered then system will be considered pass.
Failing criteria:
If application is slow , forms are not communicating , database is not saving record of
any one form then it will be considered that system has fail as it is not meeting the
requirements.
5.2.2.8. Suspension criteria and resumption requirements
Suspension Criteria: If forms are not communicating , database is not saving record
properly.
-Resumption Criteria: Testing will be done again to ensure that the bug has been fixed
and the selected tests like data entry, order placement give the expected results.
Only then will the testing be resumed.
5.2.2.10. Testing tasks

All the functionalities are performing in the way as they were described in use cases.
Our application is meeting the requirements of the user.
5.2.2.11. Environmental needs

As we have developed our system on visual studio so same tool will be used for testing
and following are the specs of the system on which testing has been performed
 Core i3
 2 GB RAM
5.2.2.12. Responsibilities
Hamza Bin Javed will focus on both black box and white box and will be responsible for
checking database connectivity with system, form validation , form communication, Rana
Hamza will check user interface deeply and Sharjeel Tariq will focus on white box testing
and will find bugs in the code will find exceptions .

5.2.2.13 Staffing and training needs
Hamza Bin Javed will be responsible for checking database connectivity with system,
form validation , form communication so he should have knowledge about simple
database queries and as he will check form validation so he should know how to validate
a form by giving random entries Rana Hamza will check user interface deeply so he
should have basic knowledge about Human computer interface and should be able to
make positive changes in the application and Sharjeel Tariq will focus will find bugs in
the code will find exceptions so he should have basic knowledge about how to code in c#
and ASP.net.
5.2.2.14. Schedule
Testing user interface 2 days.
Form validation and form communication 2 days.
Database connectivity with system 1 week.
Finding bugs in the code 2 week.
Handling exceptions 2 week
5.2.2.15. Risks and contingencies

Two main risks are scripting test and environment designing. We solve the scripting test
problem by testing is doing along with the code implementation otherwise difficult to
identify the error and we solve the environment designing problem by designing
according to our knowledge of HCI.
5.2.2.16 Approvals
5.3. Test design specification
5.3.2. Outline
A test plan shall have the following structure:
a. Test plan identifier;

b. Introduction;
c. Test items;
d. Features to be tested;
e. Features not to be tested;

f. Approach;
g. Item pass/fail criteria;
h. Suspension criteria and resumption requirements;
i. Test deliverables;
j. Testing tasks;
k. Environmental needs;
l. Responsibilities;
m. Staffing and training needs;
n. Schedule;
o. Risks and contingencies;
p. Approvals.
included immediately prior to Approvals. If some or all of the content of a section is in
another document, then a reference to that material may be listed in place of the
corresponding content. The referenced material must be attached to the test plan or
available to users of the plan.
5.3.2.1 Test plan identifier

The identifier has specific number that is “001”.
5.3.2.2. Introduction
Testing phase start after completion of project . I am going to test this application as a
whole system and will check the communication between different pages and their back
end connectivity with database.

 Log in page
 Sale Page
 Purchase page
 Employee registration page
 User management page
 Attendance page
 Customer record.
5.3.2.3. Test items
We will test either the system is meeting its requirements or not . The software is
designed according to its requirements or not. The software is user friendly. The software
is easy to understand.
5.3.2.4. Features to be tested

Following features are going to be tested
 Log in system

 Sale system
 Purchase system
 Employee registration system
 User management system
 Attendance system
 Customer record entry
5.3.2.6. Approach
The approaches which we used to test the application are Black Box and White Box.
“Black Box ”focus on the user interface and form validation . For example, we will test
forms by giving random values(wrong entries and right entries) in textbox . “Clear Box”
is focus on, checking working of code for example for checking working of system .
5.3.2.7. Item pass/fail criteria

Passing criteria:
If all the forms of application are responsive , are communicating perfectly , record is
being saved in database as it was entered then system will be considered pass.
Failing criteria:
If application is slow , forms are not communicating , database is not saving record of
any one form then it will be considered that system has fail as it is not meeting the
requirements.
5.3.2.8. Suspension criteria and resumption requirements
Suspension Criteria: If forms are not communicating , database is not saving record
properly.
-Resumption Criteria: Testing will be done again to ensure that the bug has been fixed
and the selected tests like data entry, order placement give the expected results.
Only then will the testing be resumed.
5.3.2.10. Testing tasks

All the functionalities are performing in the way as they were described in use cases.
Our application is meeting the requirements of the user.

As we have developed our system on visual studio so same tool will be used for testing
and following are the specs of the system on which testing has been performed
 Core i3

 2 GB RAM
5.3.2.12. Responsibilities
Hamza Bin Javed will focus on both black box and white box and will be responsible for
checking database connectivity with system, form validation , form communication, Rana
Hamza will check user interface deeply and Sharjeel Tariq will focus on white box testing
and will find bugs in the code will find exceptions .
5.3.2.13 Staffing and training needs

Hamza Bin Javed will be responsible for checking database connectivity with system,
form validation , form communication so he should have knowledge about simple
database queries and as he will check form validation so he should know how to validate
a form by giving random entries Rana Hamza will check user interface deeply so he
should have basic knowledge about Human computer interface and should be able to
make positive changes in the application and Sharjeel Tariq will focus will find bugs in
the code will find exceptions so he should have basic knowledge about how to code in c#
and ASP.net.
5.3.2.14. Schedule
Testing user interface 2 days.
Form validation and form communication 2 days.
Database connectivity with system 1 week.
Finding bugs in the code 2 week.
Handling exceptions 2 week
Reports generation 2 hour
5.3.2.15. Risks and contingencies

Two main risks are scripting test and environment designing. We solve the scripting test
problem by testing is doing along with the code implementation otherwise difficult to
identify the error and we solve the environment designing problem by designing
according to our knowledge of HCI.
5.3.2.16 Approvals
Specify the names and titles of all persons who must approve this plan. Provide space for
the signatures and dates.
5.4. Test Case Specification
5.4.2. Outline
A test case specification shall have the following structure:

a. Test case specification identifier
b. Test items
c. Input specifications
d. Output specifications
e. Environmental needs
f. Special procedural requirements
g. Inter case dependencies
included at the end. If some or all of the content of a section is in another document, then
a reference to that material may be listed in place of the corresponding content. The
referenced material must be attached to the test case specification or available to users of
the case specification. Since a test case may be referenced by several test design
specifications used by different groups over a long time period, enough specific
information must be included in the test case specification to permit reuse.
5.4.2.1. Test case specification identifier

001.
5.4.2.2 Test items

In this test case we are going to test user interface.
5.4.2.3. Input specifications

No inputs are to be given all forms are to be visited one by one
5.4.2.4. Output specifications

All forms will appear one by one .
5.4.2.5.1. Hardware
 4GB RAM
 CORE I5.
5.4.2.5.2. Software
VISUAL STUDIO
5.4.2.5.3. Other
None

5.4.2.6. Special procedural requirements
None
5.4.2.7. Inter case dependencies
None
5.5. Test procedure specification
5.5.2.1. Test procedure specification identifier

001A
5.5.2.2. Purpose
This procedure execute test case 001.
5.5.2.3. Special requirements

The computer should have a visual studio for conducting this test case and the tester
should have deep knowledge of HCI.
5.5.2.4. Procedure steps
The tester will visit all the forms one by one and will check either the interface is
developed according to requirements.
5.5.2.4.1. Log
Describe any special methods or formats for logging the results of test execution, the
incidents observed, and any other events pertinent to the test (see Clauses 9 and 10).
5.5.2.4.2. Set up
All form should be designed and should be in running form in visual studio.
5.5.2.4.3. Start
All forms should be in running form in visual studio.
5.5.2.4.4. Proceed
Visit all the forms one by one.
5.5.2.4.5. Measure
The forms will be test according to basic rules of HCI.
5.5.2.4.6. Shut down

If you want to finish testing then simply exit the visual studio after testing all the forms.
5.5.2.4.7. Restart
Testing will restart when you will visit one after other form.

5.5.2.4.8. Stop
We can stop the system orderly by clicking pause button in visual studio.
5.5.2.4.9. Wrap up
We can restore the environment by opening the form again.
5.5.2.4..10. Contingencies
As the project is very much important if any anomalous activity take place we have to
pause the visual studio .

002.
5.4.2.2 Test items

In this test case we are going to test form communication.

The input required to move from one form to other form .

All the form will appear orderly.
5.4.2.5.1. Hardware
 4GB RAM
 CORE I5.
5.4.2.5.2. Software
VISUAL STUDIO
5.4.2.5.3. Other
None
None
001


002A
5.5.2.2. Purpose

should know how to move from one form to other and he should have some basic
knowledge that how forms are connected in application and what kind of data is to be
entered.
 The tester will enter data in all the text fields.
 Then tester will click on the button by which other form will appear.
 Then tester will check either the form appeared is correct or not.
5.5.2.4.1. Log
All forms should be connected with each other like the way they should be according to
the requirements.
5.5.2.4.2. Set up
The tester will visit all the forms one by one and will check either the interface is
developed according to requirements
5.5.2.4.3. Start
Tester will start entering in the text fields
5.5.2.4.4. Proceed
Tester will click the button after entering the required data.
5.5.2.4.5. Measure
Tester will check the communication between the forms i.e either the order of the forms
is correct.

5.5.2.4.7. Restart
Testing will restart when tester will find order of form incorrect.
5.5.2.4.8. Stop

5.5.2.4.9. Wrap up

003.
5.4.2.2 Test items

In this test case we are going to test either forms are validated correctly or not.

We will enter wrong values in the field.

System should generate an error message.
5.4.2.5.1. Hardware
 4GB RAM
 CORE I5.
5.4.2.5.2. Software
VISUAL STUDIO
5.4.2.5.3. Other
None
None
001

003A

5.5.2.2. Purpose

knowledge that how forms are connected in application and what kind of data is to be
entered.
 The tester will enter wrong values deliberately in text fields
 Then tester will click on the button .
 Then tester will check either the system is generating an error message or not.
5.5.2.4.1. Log
Form validation should be done
5.5.2.4.2. Set up
The tester will visit all the forms one by one and will check enter the wrong values.
5.5.2.4.3. Start
Tester will start entering data in the text fields
5.5.2.4.4. Proceed
5.5.2.4.5. Measure
Tester will check either the system is giving error message or not.

5.5.2.4.7. Restart
Testing will restart when tester will find that system is not giving error message.
5.5.2.4.8. Stop
5.5.2.4.9. Wrap up

004.
5.4.2.2 Test items

In this test case we are going to test either system is connected to database properly.

We will enter values in the text fields respectively.

Entered values should be saved in database and should be visible in data grid view
present on the form.
5.4.2.5.1. Hardware
 4GB RAM
 CORE I5.
5.4.2.5.2. Software
VISUAL STUDIO
SQL Management studio
5.4.2.5.3. Other
None
None
001, 003.

004A
5.5.2.2. Purpose


knowledge that how forms are connected in application , what kind of data is to be
entered and he should also have basic knowledge about database systems
 The tester will values in text fields respectively
 Then tester will check either the entered value is saved in the database or not.
5.5.2.4.1. Log
System should be connected with database.
5.5.2.4.2. Set up
The tester will visit all the forms enter value in all the test field of the respective form and
then will check saved values in database.
5.5.2.4.3. Start
5.5.2.4.4. Proceed
Tester will start debugging code.
5.5.2.4.5. Measure
Tester will check either the code has bugs or not if there are bugs in code then tester is
suppose to fix it.

5.5.2.4.7. Restart
Testing will restart when tester will find that values are not being save in database
correctly.
5.5.2.4.8. Stop
5.5.2.4.9. Wrap up

005.

5.4.2.2 Test items
In this case our tester will find bugs in the code .

This is clear box testing so in this case we will not give any input we will just debug the
code.

Code should be free of bugs.
5.4.2.5.1. Hardware
 4GB RAM
 CORE I5.
5.4.2.5.2. Software
VISUAL STUDIO
5.4.2.5.3. Other
None
None
None.

005A
5.5.2.2. Purpose

The computer should have visual studio and the tester should have proper knowledge of
c# and along this he should also be able to know how to debug the code.
 Tester will check all the modules one by one and debug the code.
5.5.2.4.1. Log

System should be in running condition.
5.5.2.4.2. Set up
then will check saved values in database.
5.5.2.4.3. Start
5.5.2.4.4. Proceed
5.5.2.4.5. Measure
Tester will check either the entered value and the saved values are same or not.

5.5.2.4.7. Restart
correctly.
5.5.2.4.8. Stop
5.5.2.4.9. Wrap up

006.
5.4.2.2 Test items

In this test case our tester will check that exceptions handling has been done properly or
not.

We will enter values in the text fields respectively.
We will perform different type of functionalities in all modules

System should catch exception.

5.4.2.5.1. Hardware
 4GB RAM
 CORE I5.
5.4.2.5.2. Software
VISUAL STUDIO
5.4.2.5.3. Other
None
None
001,002,003,004.

006A
5.5.2.2. Purpose

should have knowledge of c# and visual studio .net platform. The application should be
in running form.
 The tester will values in text fields respectively
 Then tester will check either the system is catching exceptions and handling it or not.
5.5.2.4.1. Log
System should be as a whole in running condition and performing all functionalites.
5.5.2.4.2. Set up
then will check that either the system is catching exceptions or not.

5.5.2.4.3. Start
5.5.2.4.4. Proceed
5.5.2.4.5. Measure
Tester will check either the system is handling exceptions properly.

5.5.2.4.7. Restart
correctly.
5.5.2.4.8. Stop
5.5.2.4.9. Wrap up

007.
5.4.2.2 Test items

In this test case we are going to test either system is generating reports properly.

Tester will ask system for generating reports.

System will generate reports.
5.4.2.5.1. Hardware
 4GB RAM
 CORE I5.

5.4.2.5.2. Software
VISUAL STUDIO
5.4.2.5.3. Other
None
None
001, 003,004,005,006,002.

007A
5.5.2.2. Purpose

The computer should have visual studio as it is the basic tool we are using for testing and
our tester should have basic knowledge about how to deal with a running application in
visual studio and he should also have knowledge about all the functionalities of the
corresponding application
 The tester will call the event of reports generation by clicking the respective button.
 Tester will then check the views of the reports.
5.5.2.4.1. Log
System should be connected with database.
System should be in complete running conditions.
5.5.2.4.2. Set up
The tester will call the event of reports generation.
5.5.2.4.3. Start
Tester will simply generate reports by clicking on the button which is associated with the
functionality of reports generation.
5.5.2.4.4. Proceed
Tester will click the button .

5.5.2.4.5. Measure
Tester will check either the view of reports is correct or not.

5.5.2.4.7. Restart
correctly.
5.5.2.4.8. Stop
5.5.2.4.9. Wrap up
Database connectivity test 1

Form communication test
5.7.2.3.3. Environmental information

HARDWARE USED
LAPTOP CORE I5
4 GB RAM
HP PROBOOK
performance was satisfactory.
5.9.2.1. Test summary report identifier

020
5.9.2.3. Variances
None.
5.9.2.4. Comprehensiveness assessment

The features associated with web application are not sufficiently tested as they were not
connected with the system but some of the modules of web application have been tested
by using the approach of unit testing but those were minor so are not mentioned in this
document.
5.9.2.5. Summary of results

All the items tested were satisfactory and as a whole system is performing all the
functionalities according to the user requirement.

5.9.2.6. Evaluation
All the items and features have pass the criteria . So there is no risk associated with the
system.
5.9.2.7. Summary of activities

Summarize the major testing activities and events. Summarize resource consumption
data, e.g., total staffing level, total machine time, and total elapsed time used for each of
the major testing activities.
Total persons involved in testing phase=3

Total Machine=1
Total elapsed time = 27 days
5.9.2.8. Approvals
Appendixes:
Appendix 1: Final Documentation Format Guidelines

Typographical Format and Binding
Page Format:
Page size: A4
Top margin: 1.00 inch
Bottom margin: 1.00 inch
Left margin: 1.25 inch
Right margin: 1.00 inch
Page numbering: Bottom right - part of the footnote

Title page not numbered
All other pages before the page of chapter one numbered in lower roman
numerals (i, ii, iii, …)
All other pages starting from first page of chapter one to last page of the report
numbered in integers (1, 2, 3, …)
Footer: Each page shall have a footnote “Division of Science &

Technology, University of Education, Lahore”
Left aligned
In case of long titles shorter versions should be used.

There shall be a line over the footnote.
Header: Each page shall have a header “Project Name”

Left aligned
There shall be a line under the footnote.
Chapter Startup: Each chapter shall be numbered as Chapter 1, Chapter 2,

etc. The name of the chapter shall be written immediately
below. Both shall be centered horizontally as well as
vertically.
The actual chapter content shall start from the next page.7
Text: Only one side of the paper shall be used.

The other side shall be blank.
When a report is opened the right side would contain text, figures, or tables and
the left side would be blank.
Tables and Figures: Tables and figures shall be placed on one side only
Separate pages shall be used for figures and tables.
One page may contain more than one figure or table but text will not be combined
or interlaced with figure or table.
Each table / figure shall be numbered.
For example "Table 1.2: Population distribution in Asia" or "Figure 3.2: Temperature
distribution"
The table number or figure number shall be placed as normal text centered at the bottom
of the table or figure or sideways with table / figure title
coming on the opening side of the paper and note on the
binding side.
Paragraph:
Single-spaced.
Line entered paragraph.
DONOT put indents at the beginning of the paragraph.
Left aligned or justified.
Text Format
Normal and plane text:

Font Type: Times New Roman
Font Size: 12
Headings:
Chapter Heading: Times New Roman Bold Size 16 Title Case normal
Heading 1: Times New Roman Bold Size 14 Title Case normal

Heading 3: Times New Roman Bold Size 12 Title Case italic
Sections and Subsections
In case of sections and subsections follow this format:
1 Section
1.1 Sub Section
1.1.1 Nested Sub Section
a
b
i
ii
The subsequent reference to a any section shall be made using the section and its number.
For example section 2.1.3 means chapter 2 section 1 subsection 3.
Mathematical Equations
The following numbering scheme should be used to number the equations:

f(x) = x+3 (XX:YY)
Where XX is the chapter number and YY is the sequence number of that equation
in that chapter.
If an equation is previously quoted in an earlier chapter, say as equation 4:5 and
need to be re-quoted in chapter 5, its number will remain as equation 4:5.
References
References are to be placed in square brackets and interlaced in the text. For
example "A comprehensive detail of how to prevent accidents and losses caused
by technology can be found in the literature [1]. A project report / thesis cannot be
accepted without proper references. The references shall be quoted in the
following format:
The articles from journals, books, and magazines are written as:
[1] Abe, M., S. Nakamura, K. Shikano, and H. Kuwabara. Voice conversion
through vector quantization. Journal of the Acoustical Society of Japan,
April 1990, E-11 pp 71-76.
[2] Hermansky, H. Perceptual linear predictive (PLP) analysis for speech.
Journal of the Acoustical Society of America, January 1990, pp 1738-
1752.
The books are written as:
[1] Nancy G. Leveson, Safeware System Safety and Computers, A
guide to preventing accidents and losses caused by technology,
Addison-Wesley Publishing Company, Inc. America, 1995.

[2] Richard R. Brooks, S. S. Iyengar, Multi-Sensor Fusion
Fundamentals and Applications with Software, The Prentice-Hall
Inc. London, 1998.
Binding
All reports shall be bounded with an appropriate print on the backbone.

Two copies should be submitted.
Color of the binding:

 BSc project / thesis reports: black
 MSc project / thesis reports: blue
Contents of the CD Attached

All reports / theses must accompany a CD whose contents will have the following:
Top-level directories:
Doc All documents related to the project
Instructions how to access the CD to the point to running the project
All reports already submitted
The final project report in thesis form
Installation instructions
Trouble shooting instructions in case of problems
User manual
Research material including URLs
Papers consulted / referred to
Slides of the presentations
Source All source files that will be needed to compile the project.
Further subdirectories can be used.
This must include sample data files as well.
Project The running project including sample data files as well as sample
output.
This should be in a form that if copied to a machine runs without
errors.
This may an exe file of an entire project, an installer depending on
the project or simply a running project.
You can have sub directories with appropriate names.
Length
The length of your dissertation depends on the type of project you have selected. An
excellent dissertation will often be brief but effective (its author will have said a lot in a
small amount of space). Voluminous data can be submitted electronically on CD.

Appendixes:
Appendix 1: Final Documentation Format

Guidelines
Typographical Format and Binding
Page Format:
Page size: A4
Top margin: 1.00 inch

Bottom margin: 1.00 inch
Left margin: 1.25 inch
Right margin: 1.00 inch
Page numbering: Bottom right - part of the footnote

Title page not numbered
All other pages before the page of chapter one numbered in
lower roman numerals (i, ii, iii, …)
All other pages starting from first page of chapter one to
last page of the report numbered in integers (1, 2, 3, …)
Footer: Each page shall have a footnote “Division of Science &

Technology, University of Education, Lahore”
Left aligned
There shall be a line over the footnote.
Header: Each page shall have a header “Project Name”

Left aligned
There shall be a line under the footnote.
Chapter Startup: Each chapter shall be numbered as Chapter 1, Chapter 2,

etc. The name of the chapter shall be written immediately
below. Both shall be centered horizontally as well as
vertically.
The actual chapter content shall start from the next page.7
Text: Only one side of the paper shall be used.

The other side shall be blank.
When a report is opened the right side would contain text,
figures, or tables and the left side would be blank.
Tables and Figures: Tables and figures shall be placed on one side only
Separate pages shall be used for figures and tables.
One page may contain more than one figure or table but
text will not be combined or interlaced with figure or table.
Each table / figure shall be numbered.
For example "Table 1.2: Population distribution in Asia" or
"Figure 3.2: Temperature distribution"
The table number or figure number shall be placed as
normal text centered at the bottom of the table or figure or
sideways with table / figure title coming on the opening
side of the paper and note on the binding side.

Paragraph:
Single-spaced.
Line entered paragraph.
DONOT put indents at the beginning of the paragraph.
Left aligned or justified.
Text Format
Normal and plane text:

Font Type: Times New Roman
Font Size: 12
Headings:
Chapter Heading: Times New Roman Bold Size 16 Title Case normal
Heading 3: Times New Roman Bold Size 12 Title Case italic
Sections and Subsections
In case of sections and subsections follow this format:
1 Section
1.1 Sub Section
1.1.1 Nested Sub Section
a
b
i
ii
The subsequent reference to a any section shall be made using the section and its
number. For example section 2.1.3 means chapter 2 section 1 subsection 3.
Mathematical Equations
The following numbering scheme should be used to number the equations:

f(x) = x+3 (XX:YY)
Where XX is the chapter number and YY is the sequence number of that equation
in that chapter.
If an equation is previously quoted in an earlier chapter, say as equation 4:5 and
need to be re-quoted in chapter 5, its number will remain as equation 4:5.
References
References are to be placed in square brackets and interlaced in the text. For
example "A comprehensive detail of how to prevent accidents and losses caused

by technology can be found in the literature [1]. A project report / thesis cannot be
accepted without proper references. The references shall be quoted in the
following format:
The articles from journals, books, and magazines are written as:
[1] Abe, M., S. Nakamura, K. Shikano, and H. Kuwabara. Voice conversion
through vector quantization. Journal of the Acoustical Society of Japan,
April 1990, E-11 pp 71-76.
[2] Hermansky, H. Perceptual linear predictive (PLP) analysis for speech.
Journal of the Acoustical Society of America, January 1990, pp 1738-
1752.
The books are written as:
[1] Nancy G. Leveson, Safeware System Safety and Computers, A
guide to preventing accidents and losses caused by technology,
Addison-Wesley Publishing Company, Inc. America, 1995.
[2] Richard R. Brooks, S. S. Iyengar, Multi-Sensor Fusion
Fundamentals and Applications with Software, The Prentice-Hall
Inc. London, 1998.
Binding
All reports shall be bounded with an appropriate print on the backbone.

Two copies should be submitted.
Color of the binding:

 BSc project / thesis reports: black
 MSc project / thesis reports: blue
Contents of the CD Attached

All reports / theses must accompany a CD whose contents will have the following:
Top-level directories:
Doc All documents related to the project
Instructions how to access the CD to the point to running
the project
All reports already submitted
The final project report in thesis form
Installation instructions
Trouble shooting instructions in case of problems
User manual
Research material including URLs
Papers consulted / referred to
Slides of the presentations
Source All source files that will be needed to compile the project.
Further subdirectories can be used.
This must include sample data files as well.

Project The running project including sample data files as well as sample
output.
This should be in a form that if copied to a machine runs without
errors.
This may an exe file of an entire project, an installer depending on
the project or simply a running project.
You can have sub directories with appropriate names.
Length
The length of your dissertation depends on the type of project you have selected. An
excellent dissertation will often be brief but effective (its author will have said a lot in a
small amount of space). Voluminous data can be submitted electronically on CD.

Complete Final Project Documentation Guidelines-1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Complete Final Project Documentation Guidelines-1

Загружено:

Авторское право:

Доступные форматы

Department of Information Technology

Superior University Gujranwala

“Automation of Weltron Kitchenware”

Session: BSIT Spring 2015-2019

Project Supervisor: Sir Muhammad Bilal

Rana Malahim BITM-F15-017

© Department of Information Technology 1

© Department of Information Technology 2

© Department of Information Technology 3

Due to ever increasing demand of transporting huge amount of information generated

© Department of Information Technology 4

A user interface design consists of three main parts:

4.2. Site Maps

© Department of Information Technology 5

First step: User will Log in

Second step: Dashboard will appear after successful logging in

© Department of Information Technology 6

4.4. Navigational maps:

4.5 Trace-ability Matrix

Following columns are involved in the trace-ability matrix.

Feature: Order Placement

© Department of Information Technology 7

Feature: Registration Request

Feature: Order Maintenance

© Department of Information Technology 8

© Department of Information Technology 9

Following are standard artifacts, which must be included in this deliverable:

5.2. Test plan

a. Test plan identifier

© Department of Information Technology 10

5.2.2.1. Test plan identifier

5.2.2.3. Test items

5.2.2.4. Features to be tested

© Department of Information Technology 11

5.2.2.7. Item pass/fail criteria

5.2.2.10. Testing tasks

5.2.2.11. Environmental needs

© Department of Information Technology 12

5.2.2.15. Risks and contingencies

5.3. Test design specification

a. Test plan identifier;

© Department of Information Technology 13

5.3.2.1 Test plan identifier

We will test all the forms present in application

5.3.2.4. Features to be tested

© Department of Information Technology 14

5.3.2.7. Item pass/fail criteria

5.3.2.8. Suspension criteria and resumption requirements

5.3.2.10. Testing tasks

5.3.2.11. Environmental needs

© Department of Information Technology 15

5.3.2.13 Staffing and training needs

5.3.2.15. Risks and contingencies

5.4. Test Case Specification

© Department of Information Technology 16

5.4.2.1. Test case specification identifier

5.4.2.2 Test items

5.4.2.3. Input specifications

5.4.2.4. Output specifications

© Department of Information Technology 17

5.5. Test procedure specification

5.5.2.1. Test procedure specification identifier

5.5.2.3. Special requirements

5.5.2.4.6. Shut down