"Automation of Weltron Kitchenware": Department of Information Technology

SE- UOG - Project Coordination Office Version: 1.
0
Final Project Deliverable Guide Date: September 25, 2017
Department of Information Technology
University of Gujrat
“Automation of Weltron Kitchenware”
Session : BSCS Spring 2014-2018
Project Supervisor: Sir Rameez Iqbal
Submitted By
Hamza Bin Javed 14064119-021
Sharjeel Tariq 14064119-009
Rana M.Hamza Arshad 14064119-047
Department of Computer Science

University of Gujrat
STATEMENT OF SUBMISSION
© Department of Computer Science
1
SE- UOG - Project Coordination Office Version: 1.0
This is certify that “Hamza Bin Javed” Roll no.(14064119-021), “Sharjeel Tariq” Roll no.
(14064119-009) and “Rana M.Hamza Arshad” Roll no. (14064119-047) has successfully
completed the final year project named as”Automation Of Weltron Kitchenware
Industry” at the Department of Computer Science, University of Gujrat, to fulfill the
requirement of the degree of Bachelors in Computer Science.
______________________ _____________________
Project Supervisor Project Coordination Office
Faculty of C&IT -UOG
______________________
Head of the Department

2
Acknowledgement
We truly acknowledge the cooperation and help make by Sir Touqeer ul Amin , Head of
department,CS&IT(Evening), University of Gujrat. He has been a constant source of
guidance throughout the course of this project. We would also like to thank Mr.Rameez
Iqbal 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.
1- Sir Nauman
2- Sir Rizwan
Date: June 25, 2018

3
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.
TABLE OF CONTENTS
4
1.1. INTRODUCTION.....................................................................................................7
1.2. PROJECT/PRODUCT FEASIBILITY REPORT.................................................................7
1.2.1. Technical Feasibility.........................................................................................7
1.2.2. Operational Feasibility.....................................................................................8
1.2.3. Economic Feasibility.........................................................................................8
1.2.4. Schedule Feasibility...........................................................................................8
1.2.5. Specification Feasibility....................................................................................8
1.2.6. Information Feasibility......................................................................................9
1.2.7. Motivational Feasibility....................................................................................9
1.2.8. Legal & Ethical Feasibility...............................................................................9
1.3. PROJECT/PRODUCT SCOPE........................................................................................9
1.4. PROJECT/PRODUCT COSTING....................................................................................9
1.4.1. Project Cost Estimation By Function Point Analysis......................................10
1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model). 11
1.4.3. Activity Based Costing.....................................................................................11
1.5. TASK DEPENDENCY TABLE.....................................................................................12
1.6. CPM - CRITICAL PATH METHOD............................................................................12
1.7. GANTT CHART.........................................................................................................14
1.8. INTRODUCTION TO TEAM MEMBER AND THEIR SKILL SET......................................14
1.9. TASK AND MEMBER ASSIGNMENT TABLE..............................................................15
1.10. TOOLS AND TECHNOLOGY WITH REASONING........................................................17
1.11. VISION DOCUMENT...............................................................................................17
1.12. RISK LIST..............................................................................................................17
1.13. PRODUCT FEATURES/ PRODUCT DECOMPOSITION................................................18
CHAPTER 2: SOFTWARE REQUIREMENT SPECIFICATION (FOR OBJECT
ORIENTED APPROACH).............................................................................................19
2.1 INTRODUCTION:........................................................................................................19
2.1.1 Systems Specifications......................................................................................19
2.2.5. Identifying External Entities:..........................................................................21
2.1.3. Context Level Data Flow Diagram:................................................................22
2.1.4. Capture "shall" Statements:............................................................................23
2.1.5. Allocate Requirements:....................................................................................24
2.1.6. Prioritize Requirements:.................................................................................25
2.1.7. Requirements Trace-ability Matrix:................................................................28
2.2.10. High Level Usecase Diagram:......................................................................30
2.2.11. Analysis Level Usecase Diagram:.................................................................39
2.2.12. Usecase Description......................................................................................49
CHAPTER 3: DESIGN DOCUMENT..........................................................................56
3.1. INTRODUCTION:.......................................................................................................56
3.2. DOMAIN MODEL......................................................................................................57
3.3. SEQUENCE DIAGRAM:.............................................................................................58
3.3.1: SEQUENCE ONLINE:....................................................................................58
3.5. COLLABORATION DIAGRAM....................................................................................59
3.6. OPERATION CONTRACTS.........................................................................................59

5
3.7. DESIGN CLASS DIAGRAM........................................................................................61

3.8. STATE CHART DIAGRAM...........................................................................................62
3.9. DATA MODEL..........................................................................................................64
CHAPTER 4: USER INTERFACE DESIGN...............................................................65
4.1. INTRODUCTION........................................................................................................65
4.2. SITE MAPS...............................................................................................................66
4.3. STORY BOARDS........................................................................................................66
4.4. NAVIGATIONAL MAPS:.............................................................................................68
4.5 TRACE-ABILITY MATRIX..........................................................................................68
CHAPTER 5: SOFTWARE TESTING.........................................................................70
5.1 INTRODUCTION:........................................................................................................70
5.2. TEST PLAN...............................................................................................................71
5.2.2. Outline.............................................................................................................71
5.3. TEST DESIGN SPECIFICATION...................................................................................74
5.3.2. Outline.............................................................................................................74
5.4. TEST CASE SPECIFICATION......................................................................................77
5.4.2. Outline............................................................................................................78
5.5. TEST PROCEDURE SPECIFICATION............................................................................79
5.6. TEST ITEM TRANSMITTAL REPORT...........................................................................91
5.7. TEST LOG.................................................................................................................92
5.9. TEST SUMMARY REPORT..........................................................................................95
5.9.2.1. Test summary report identifier.....................................................................95
APPENDIXES:................................................................................................................97
APPENDIX 1: FINAL DOCUMENTATION FORMAT GUIDELINES...................98
APPENDIXES:..............................................................................................................102
Appendix 1: Final Documentation Format Guidelines..............................................103
First Deliverable
6
Chapter 1: Project Feasibility Report
1.1. Introduction
The project aims to achieve an ecommerce website and desktop application built
client-specific for the company named ‘Weltron Kitchenware Industry.’. The
website and desktop application will showcase company products, their features and
technical specifications as well as available stock amount at the website. Customers
who will register via an email will have access to order and purchase data such as,
shopping cart and previous order history and any promotions available.
Subscriptions at the website will provide crucial data for the company to keep an
eye on trends in purchase behavior of the clients as well as ability to get user
feedback and conduct surveys for past products or advertise for upcoming products.
It will immensely increase customer influx for the company as well as streamline
their services as per customer’s demands.
a. Project Feasibility:
b. Project Scope
c. Project Costing
d. Task Dependency Table
e. Critical Path Method Analysis (CPM Analysis)
f. Gantt Chart
g. Introduction to team members
h. Tasks and member assignment table
i. Tools and Technologies
j. Vision Document
k. Risk List
l. Product Features
1.2. Project/Product Feasibility Report
1.2.1. Technical Feasibility
Q-1 Is the proposed system practical?

Ans. The proposed system is definitely practical as we have all the resources available.
Also building up this module requires the minimum amount of hardware & software is
easily available. So, the proposed system is extremely efficient and practical.

7
Q-2 Do we currently possess the necessary technology?

Ans. Looking into the system requirement, we can see that we possess all the hardware
and software requirements. Also the technology used is easily available and deployed all
around the world.
1.2.2. Operational Feasibility

The operational feasibility includes the technical expertise of the staff to operate the
project. Our project is worthy and problem solving for the client. We are going to give the
very reliable and feasible solution for the problems of our client. This project will be very
helpful for both the customers and company . Therefore we’ll utilize the technical
expertise of each staff members to outcome the efficient results.
1.2.3. Economic Feasibility

Economic feasibility have two types:
Cost Estimates:
In Cost Estimates Total Cost of a Project can be calculated
Acquisition Cost= 30k
Maintenance and Operation Cost= 5k Per Year of Website Services and Desktop
Application and 5k for every year testing and updating.
Benefit Estimates:
Benefit estimates enclose tangible benefits and intangible benefits.
Tangible Benefits:
First year we provide our services for free and make our system easier to use then our
services are paid.
Intangible Benefits:
We try to provide best services to the users of our system and provide correct and useful
information and help.
1.2.4. Schedule Feasibility.

Scheduling and planning of resource and staff is very important to complete project on
time. In this regard we divide the project into tasks with proper dependencies and
durations. We’ll also make critical path method for scheduling the feasible solution to our
project. This will help us to complete our project within the deadlines.
1.2.5. Specification Feasibility

Requirement specification and analysis is the main aspect of our project. We must have
proper requirements specification to make our project meaningful and useful according to
user requirements. This will greatly enhance the user experience and make our project
successful.

8
1.2.6. Information Feasibility

The feasibility of information must be assessed regarding its completion, reliability, and
meaningfulness. Our project will be information feasible because the information used
for recommendation of Automation will be based on the user requirements. It will give
the maximum resemblance to the user expectations.
1.2.7. Motivational Feasibility

There is no such an efficient smart system available for my client. This could be the first
step towards solving the one of the major issue in the business life cycle. By developing
this, we’ll be able to provide such smart service through which the client will maintain
his all data and all this will help him in future. This system will help our client to remove
duplicities.
1.2.8. Legal & Ethical Feasibility

Below mentioned are some of the legal and ethical feasibility details of our project:.
Microsoft Visual Studio is free available to all the University students legally.
We use Visual Studio for Desktop Application Development.
We use Visual Studio for web development.
Our project is legally and ethically feasible for development.
1.3. Project/Product Scope

Recently, people have gained massive information via Internet and dealt with them. Then
the information filtering becomes useful tool as well as information retrieval. There are
some kinds of information filtering techniques: contents-based filtering, collaborative
filtering and so on. The main function of our recommender system predicts user’s
preference from the rating information, filters some items, and suggests candidate items
for user. In general, recommender system has been used for support of selecting items.
Especially in e-commerce, the system is now attractive to enhance customer satisfaction.
1.4. Project/Product Costing

The project costing is done by the following three phases:
 Project cost estimation by function point analysis
 Project cost estimation by using constructive cost model
 Activity based costing

9
1.4.1. Project Cost Estimation By Function Point Analysis
Total function point calculated are 118.58

10
1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model)
Our Project is between Organic and embedded types so we use Semi-detached type to
measure cost.
Basic COCOMO
Type Effort Schedule
Semi-Detached PM= 3.0 (6)1.12=20.16 TD= 2.5(20.16)0.35=17.64
PM= person-month (effort) KLOC= lines of code, in thousands

TD= number of months estimated for software development (duration)
People Required = 20.16/ 17.64=2
1.4.3. Activity Based Costing
Activity Resources Cost Rate Duration

A.Website Visual Studio 5k 4 Weeks
Development
.
B. Visual Studio 5k 2 Week
Application
Development
C. Login and Visual Studio 5k 4 Weeks
Registration
Process
D.Database sql Free 4 Weeks
Connectivity
E. Testing Visual Studio 5k 2 Weeks
F.Complete Visual Studio 5k 8 Weeks
Working
Application
G.Whole Visual Studio 5k 2 Week
System
Testing

11
1.5. Task Dependency Table

TASK DEPENDENCY Duration (Weeks)
A. Website None 4 Weeks
Development
B.Applicatio None 2 Week
n
Development
C. Login and A,B 4 Weeks
Registration
Process
D.Database A, B,C 4 Weeks
Connectivity
E. Testing A,B,C,D 2 Weeks
F.Complete A,B,C,D 8 Weeks
Working
Application
G.Whole A,B,C,D,F 2 Week
System
Testing
1.6. CPM - Critical Path Method
Activity Immediate Predecessor Duration (Weeks)

A None 4
B None 2
C A, B 4
D B, C 4
E B, C, D 2
F A, B, C, D, E 8
G F 2

12
D
A
G
Start C End
F
B
Network Diagram for the above-mentioned activities
Activity Duration ES EF LS LF TS
A 4 0 4 0 4 0
B 2 0 2 2 4 2
C 4 4 8 4 8 0
D 4 8 12 8 12 0
E 2 12 14 12 14 0
F 8 14 22 14 22 0
G 2 22 24 22 24 0
The parameters and slacks are calculated as follows:
The critical path is:

A, C, D, E, F, G

13
1.7. Gantt chart
1.8. Introduction to Team member and their skill set
Members Name Skill Set Tasks

Sharjeel Tariq Desktop Developing desktop Application and
application development of Web site, website design.
development, web
development
Hamza Bin Website Designing, Website Design, Structure, and Layout ,Login and
Javed Implementation, Registration Process Module, Testing Web modules,
Planning, analysis and design of system , Complete
Documentation, documentation.
Desktop
application
Rana M. Hamza Testing, Project Project Testing, Coding Implementation,
Arshad Designing, Database Implementation Module
Database
Implementation

14
1.9. Task and Member Assignment Table
Task Duration (days) Dependencies Members

T1 28 M2,M3
T2 14 T1 M2
T3 28 T1, T2 M1
T4 28 T1, T2, T3 M1
T5 14 T1, T2, T3, T4 M3,M1
T6 56 T1, T2 ,T3, T4 M1,M2,M3
T7 14 T1, T2 ,T3, T4, T6 M1,M2
Task durations and dependencies
1.1.18 1.2.18 1.3.18 1.4.18 1.5.18 1.6.18 31.7.18
M2,M3
M2, T1,T2
M1,T1,T2,T3
M1,T1,T2,T3,T4
M2,M1,T1,T2,T3,T4
M1,M2,M3,T1,T2,T3,T4,T5,T6
M1,M2,T7
M3
Activity Bar Chart

15
Allocation of People to Activities:
Task Member
T1 Hamza bin Javed, Rana M. Hamza Arshad
T2 Hamza bin Javed
T3 Sharjeel Tariq ,Hamza Bin Javed
T4 Sharjeel Tariq ,Hamza Bin Javed
T6 Hamza bin Javed, Rana M. Hamza Arshad , Sharjeel
Tariq
Staff Allocation:
1.1.18 1.2.18 1.3.18 1.4.18 1.5.18 1.6.18 31.7.18
T1
T5
Hamza Bin Javed
T6
T8
T3 T4
Sharjeel Tariq
T6
T7
T3
TTT
T5
Rana M. Hamza Arshad T6 T7

16
1.10. Tools and Technology with reasoning

 HTML5 & CSS3
For web structure and design
 C#
For Development of Application.
 ASP.NET
For Development of Website.
 SQL
For database.
 Visual Studio
For coding
 MS Visio
For UML diagrams
1.11. Vision Document

The vision behind this project is to introduce smart system that is very helpful in
providing Facilities to the Client and their customers. To replace the local commissioned
service agents with reliable and smart recommendation system. We are going to
introduce the desktop application and smart website which will greatly enhance the user
experience and provide best user satisfaction according to their desire needs. This will
also improve the user experience by providing instant solutions.
1.12. Risk List

 User satisfaction

17
1.13. Product Features/ Product Decomposition
 User can maintain attendance of their employees.

 They can main their inventory.
 Customers can buy items online.
 The system also provides shopping cart and secure payment.
 The system also provides reports of the profit/loss.
 System GUI is easy to use.
 The system in robust and secure in nature.

18
Chapter 2: Software Requirement Specification (For Object Oriented

Approach)
2.1 Introduction:
2.1.1 Systems Specifications
Introduction
The project aims to achieve an ecommerce website and desktop application built client-
specific for the company named ‘Weltron Kitchenware Industry.’. The website and
desktop application will showcase company products, their features and technical
specifications as well as available stock amount at the website. Customers who will
register via an email will have access to order and purchase data such as, shopping cart
and previous order history and any promotions available. Subscriptions at the website
will provide crucial data for the company to keep an eye on trends in purchase behavior
of the clients as well as ability to get user feedback and conduct surveys for past products
or advertise for upcoming products. It will immensely increase customer influx for the
company as well as streamline their services as per customer’s demands.
Existing System
Weltron industry deals in following two main business areas:
 Gas appliances manufacturing

 Gas appliances ordering and supply
Following departments/offices facilitates above mentioned business services:

Gas appliances Manufacturing Department
Deals in manufacturing of gas appliances.
Weltron supplier office:
It deals in supply of gas appliances to different selling outlets or to other individuals. It
also processes orders from the dealers. Following are some business processes, which are
handled in this department.
1. Sales
2. Purchase
3. Order
4. Human Resource Management
5. Financial Management
6. Data Analytics
7. Reports Generation

19
Organizational Chart
Organizational chart will be very much supportive to get a better overview of the
organization’s business areas and their decomposition into different departments
.
Scope of the System
The system of Weltron industry is divided
Phase I
Phase I includes following business areas:
 Customer Account Maintenance
 Order Processing
 Product Inventory
Phase II
Phase II involves complete automation of the Supplier Department. Phase II includes
following business areas:
 Accounts and Administration
 Financial management

20
 Sales and Marketing

 HRM
Phase III
Phase III covers a complete solution for Weltron industry. Phase III includes remaining
business areas which are not developed in previous phases.
Summary of Requirements: (Initial Requirements)

The purposed system must fulfill following requirements as follow:
Order Management:
1. Only registered customer could place order for goods. So a customer must be able
to register himself to the system by requesting for registration. There should only
normal registration process. All the requests are to be viewed by the customer
account administrator (CA). CA could accept, reject and temporarily waive the
requests on the basis of credentials provided.
2. Registered customers could order for goods. Customer places an order by

providing his ID and other order related details A complete order must contain
personal details of the customer, shipping information, product list along with
product quantity and payment details. Customer could make payment through
cash. Accordingly invoice should be generated, and user should be given the
option to finally place the order and in the end confirmation receipt must be given
to the customer. Invoice contains the list of complete product along with their
pricing details. It also contains discounts, sales tax and total pricing details
3. Shipping Department ships the corresponding orders.
Product Inventory:
1 Deals with addition, searching, updating of products and their stocks. Whenever a
product stock arrives, the Inventory Administrator updates the stocks of the products.
He could add new product in the inventory. He could also view, search and modify the
product details. The Admin could view the whole product list and their product
summaries.
2.2.5. Identifying External Entities:

The Identification of External Interfaces is done in two phases.
Over Specify Entities from Requirements:

On the basis of the requirements, following are the entities .
 Customer  Invoice
 Order  Product
 Order Product  Payment
 Shipment

21
 Request
Perform Refinement:
Following are the entities according to our business logics.
 Customer
 Inventory
 Shipment
 Account
2.1.3. Context Level Data Flow Diagram:
Data flow diagram 1

22
2.1.4. Capture "shall" Statements:

Para Initial Requirements
#
1.0 A customer “shall” place order for goods
1.0 A customer “shall” register himself to the system
1.0 CA “shall” accept, reject and temporarily waive the requests on the basis of credentials
provided.
1.0 A customer “shall” login to the system and can change his password
1.0 System “shall” update the customers Request
1.0 System “shall” process different types of updating e.g. , or updating of personal
information and shipment details.
1.0 System “shall” search any customer details
2.0 Registered customers will order for goods.
2.0 Customer “shall” make payment through cash
2.0 System “shall” generate invoice, confirmation receipt and finally will place order
2.0 User “shall” be able to view his order
2.0 Customer “shall” place the request for the cancellation of the order. But all these updating
and cancellation requests are to be viewed by the Order Administrator in order to accept,
reject, or waive them.
3.0 Corresponding administrator "shall" view his Action List containing different actions, and
correspondingly process these pending actions
3.0 System”shall” be able to maintain record of purchase and sale.
3.0 System “shall” be able to maintain record of all the labour i.e designation of all the labour.
3.0 System “shall” be able to generate salaries of all the registered labours with their
increments and decrements.
3.0 System”shall” be able to tell profit of all the products separately by using data analytics
techniques.
3.0 System”shall” be able to generate reports.
3.0 System”shall” be able to conduct labour attendance.

23
3.0 System”shall” be able to make new accounts for the users of desktop application.
2.1.5. Allocate Requirements:

1.0 A customer “will” place order for goods UC_Place_Order
1.0 A customer “shall” register himself to theUC_Registration_Request

system
1.0 CA “shall”accept, reject and temporarily waiveUC_Process_Customer_Request
the requests on the basis of credentials
provided.
1.0 A customer “shall” login to the system and can UC_Login
change his password
1.0 System “shall” update the customers Request UC_Update_Request
1.0 System “shall” process different types ofUC_Change_Status
updating e.g. updating of his personal/shipping
details.
1.0 A customer “shall” view his details forUC_View_Customer_Details
verification purposes
1.0 System “shall” search any customer details UC_Search_Customer
2.0 Customer “will” make payment; through cash. UC_Pay_For_Order
2.0 System “will” generate invoice, confirmationUC_Invoice_Generation,

receipt and finally will place order
2.0 User “shall” view the status of their orders by UC_Serach_Orders
providing the Order Number
2.0 Customers “shall”place the request for theUC_Update_Request
updating of their orders if the orders are not
shipped.
3.0 System”shall” be able to maintain record ofUC_Enter_purchase

purchase and sale. UC_Enter_Sale
3.0 System “shall” be able to maintain record ofUC_Enter_Labour_Record
all the labour i.e designation of all the
labour.

24
3.0 System “shall” be able to generate salaries UC_Generate_Salaries

of all the registered labours with their
increments and decrements.
3.0 System”shall” be able to tell profit of all the UC_Generate_product1_profit
products separately by using data analytics
techniques.
3.0 System”shall” be able to generate reports. UC_generAte_reports
3.0 System “shall” be able to conduct worker UC_Attendance_System
attendance.
3.0 System “shall” be able to make new accountUC_New_Account
for the users of desktop application.
2.1.6. Prioritize Requirements:
Para Rank Initial Use Use Case Name

Requirements Case ID
1.0 Highest A customer “will”UC_1 UC_PlaceOrder
place order for
goods
1.0 Highest A customer “shall”UC_2 UC_Registration_Request
register himself to
the system
2.0 Highest Customer “will”UC_3 UC_Pay_For_Order
make payment
through cash
2.0 Highest System “will”UC_4 UC_Invoice_Generation,
generate invoice,
confirmation
receipt and finally
will place order
3.0 Highest System”shall” beUC_5 UC_Enter_purchase
able to maintainUC_6 UC_Enter_Sale
record of purchase
and sale.
3.0 Highest System “shall” beUC_7
able to maintain UC_Enter_Labour_Record
record of all the
labour i.e
25
designation of all
the labour,deptof
labour.
3.0 Highest System “shall” beUC_8 UC_Generate_Salaries

able to generate
salaries of all the
registered labours
with their
increments and
decrements.
3.0 Highest System”shall” beUC_9 UC_Generate_product1_profit
able to tell profit of
all the products
separately by using
data analytics
techniques.
3.0 Highest System”shall” be
able to generateUC_10 UC_generAte_reports
reports.
3.0 Highest System “shall” be
able to conductUC_11 UC_Attendance_System
attendance of
labour
1.0 Medium CA “shall”accept,UC_12 UC_CA_control

reject and
temporarily waive
the requests on the
basis of credentials
provided.
1.0 Medium System “shall”UC_13 UC_Update_Request
update the
customers Request
1.0 Medium System “shall” beUC_14 UC_Change_Personal_Details
able to update
customer personal
and shipment
information.
1.0 Medium System “shall”UC_15 UC_Search_Customer
search any
customer details

26
2.0 Medium User “shall” viewUC_16 UC_Serach_Orders

the status of their
orders by providing
the Order Number
1.0 Lowest A customer “shall”UC_17 UC_Login,
login to the system
and can change his
password
3.0 Lowest System “shall” beUC_18 UC_NEW_Account
able to make new
account for users of
desktop application
2.1.7. Requirements Trace-ability Matrix:
Sr Para # System SpecificationBuild Use Case Name Category

# Text
1 1.0 A customer “will”B1 UC_Place_Order Business
place order for goods
2 1.0 A customer “shall”B1 UC_Registration_Request Business
register himself to the
system
3 1.0 CA “shall”accept,B1 Business
reject and temporarily _Accept_Customer_Request
waive the requests on _Reject_Customer_Request
the basis of _View_Customer_Request
credentials provided.
4 1.0 A customer “shall”B1 UC_Login, Business
login to the system
and can change his
password
5 1.0 System “shall” updateB1 UC_Update_Request Business
the customers Request
6 1.0 System “shall”B1 Business
process different types
of updating e.g. UC_Change_Personal_Details
updating of his
personal/shipping
details.
8 1.0 System “shall” searchB1 UC_SearchCustomer Business
any customer details
9 2.0 Registered customersB1 UC_Place_Order_ Business
will place order.
27
10 2.0 Customer “will” makeB1 UC_Pay_For_Order Business

payment; through
cash
11 2.0 System “will”B1 UC_Invoice_Generation Business
generate invoice,
confirmation receipt
and finally will place
order
12 2.0 User “shall” view the UC_Serach_Orders Business
status of their ordersB1
by providing the
Order Number
14 3.0 System”shall” be able UC_Enter_purchase Business
to maintain record of UC_Enter_Sale
purchase and sale.
15 3.0 System “shall” be able UC_Enter_Labour_Record Business

to maintain record of
all the labour i.e
designation of all the
labour.
16 3.0 System “shall” be able UC_Generate_Salaries Business

to generate salaries of
all the registered
labours with their
increments and
decrements.
17 3.0 System”shall” be able UC_Generate_product1_profit Business
to tell profit of all the
products separately by
using data analytics
techniques.
18 3.0 System”shall” be able UC_generAte_reports Business

to generate reports.
19 3.0 System “shall” be able UC_Attendance_System Business

to conduct worker
attendance.

28
20 3.0 System”shall” be able UC_New_Account Business

to make new accounts
for the user of desktop
application
2.2.10. High Level Usecase Diagram:
Order Placement
Online Customer registration

29
Delivery of goods
-Invoice generation

30
Purchase history

31
Sale history
Employee registrarion

32
Profit geneartion
Reports generartion
Attendance

33
Online order maintaince
Order editing

34
Edit details
Search customer

35
Check order status
Password updation

36
User management module
2.2.11. Analysis Level Usecase Diagram:
Order Placement

37
Online Customer registration
Order deleivery

38
Invoice generation
Purchase history

39
Sale history
Employee maintainance

40
Salary generation
Profit generation

41
Reports generation
Attendance

42
Order maintaince

43
Customer details editing
Customer order editing
Customer maintainance

44
Check Order Status
Password Updation

45
User management
2.2.12. Usecase Description
UC_1:
Brief description: In this use case primary actor “customer” will place an order
and secondary actor “system” will save that order.
Pre-condition: Customer should have an active account. Customer will log in.
Main flow: Customer will view products from online catalogue. Customer will
select the item he want to purchase. Customer will place the order. System will
show the message “Order have been placed successfully”.
Alternate flows: The system will not place order due to any problem.
Post condition: Order have been placed successfully.

46
UC _2:
BRIEF DESCRIPTION: In this use case primary actor “customer” will register
himself on the website by signing up and secondary actor “system” will save his
account.
Pre-condition: User will open website on browser
Main flow: Customer will enter the required information for registration. System
will register user .
Alternate flow: System will cancel user’s registration request due to any flaw in
information or due to any other reason.
Post-condition: User have been registered successfully.
UC _3:
BRIEF DESCRIPTION: In this use case Primary actor “Shipment official” will
deliver the order and secondary actor “Customer” will pay the bill of respective
delivery and then foreman will save the record.
Pre-condition: User must have place an order. System must have confirm the
respective order. The company has deliver the order.
Main flow: The shipment official will deliver the order to the customer . The
customer will pay for his order to the shipment official . The shipment official
will give that payment to the respective foreman. The foreman will clear the debts
record of the respective customer.
Alternate flow: Order will not be delivered and the customer will not pay for his
order.
Post-condition: Foreman will receive the payment and will clear the debts from
the system.

47
UC_4:
BRIEF DESCRIPTION: In this use case primary actor foreman will generate an
invoice with help of secondary actor “system”.
Pre-condition: Customer will place an order. Foreman should be logged in.
Main flow: Foreman will enter the items. System will calculate the bill and will
generate an invoice.
Alternate flow: No alternate flows.
Post-condition: Invoice generated
UC_5:
BRIEF DESCRIPTION: In this use case the primary actor “foreman” will enter
record of purchase and secondary actor “system” will save it.
Primary Actor: Foreman.
Secondary Actor: System.
Pre-condition: Company has purchase some stock. Foreman should be logged in.
Main flow: Foreman will enter the items. System will update the record.
Post-condition: System will update the record.
UC_6:
BRIEF DESCRIPTION: In this use case the primary actor “foreman” will enter
sale record and secondary actor “system” will save it.
Pre-condition: Foreman will log in. Foreman will initiate a sale
Main flow: Foreman will enter the items. System will update the record.
UC_7:
BRIEF DESCRIPTION: In this use case primary actor “foreman” will enter
labor record and secondary actor “system” will save it.
Pre-condition: Foreman will log in. Foreman will open labor record
Main flow: Foreman will enter the new entries, enter the new designation in
short will update the record.

48

UC_8:
BRIEF DESCRIPTION: In this use case the primary actor ”foreman” will
generate salaries of the labor and secondary actor “system” will save the record.
Pre-condition: Foreman should be logged in.
Main flow: Foreman will open the salaries record. Foreman will enter the labor
ID. After this foreman will generate salary of all the labor by adding increments
and subtracting decrements. In the end foreman will update the record after giving
salaries to the labor.
UC_9:
BRIEF DESCRIPTION: In this use case primary actor “foreman” will place
request for generating profit of a product and secondary actor “system” will
generate profit of the product and will show it to the foreman.
Pre-condition: Foreman should be logged in
Main flow: Foreman will enter the product ID. System will generate profit or loss
and will display it to the foreman.
Post-condition: System will generate the net profit or net loss.
UC_10:
BRIEF DESCRIPTION: In this use case system will generate report and will
show it to the foreman.
Main flow: Foreman will click on reports section. System will generate reports.
Post-condition: System will generate reports.

49
UC_11:
BRIEF DESCRIPTION: In this use case foreman will conduct attendance of the
labor and system will save it.
Pre-condition: Foreman should be logged in.
Main flow: Foreman will open the attendance and will mark attendance of their
respective area labor and will save the attendance and the record of over hours
working .
Post-condition: System will generate reports.
UC_12:
BRIEF DESCRIPTION: In this use case CA will confirm order on the basis of
credential history and system will save it.
Pre-condition: Administrator should be logged in
Main flow: Administrator will check the new online orders. Administrator will
then check the credential history of the customers. According to the history of the
customers administrator will either accept or reject the order. Administrator may
delay the order due to non-availability of the product.
Post-condition: Administrator will either accept, reject or delay the order.
UC_13:
BRIEF DESCRIPTION: In this use case customer will update his order request
and system will save it.
Pre-condition: Customer should be logged in.
Main flow: Customer will be able to update request up to a limited time.
Customer will check wether he have time to update the record if yes he can
update the record by clicking on the update button. System will save the update
request.
Post-condition: System will update request.

50
UC_14:
BRIEF DESCRIPTION: In this use case customer will update his personal data
and system will save it.
Main flow: Customer will click on updating the details . Customer will be able to
change limited things like address where order is to be delivered or the customer
will be able to change his contact number . After changing system will save the
record.
Post-condition: System will update customer details.
UC_15:
BRIEF DESCRIPTION: In this use case foreman will search for the registered
customers.
Main flow: Foreman will click on Customer section. Foreman will be able to
search any customer by entering his id.
Post-condition: System will search the customer.
UC_16:
BRIEF DESCRIPTION: In this use case customer will search for the orders.
Primary Actor: Foreman.
Secondary Actor: System.
Main flow: Foreman will enter the invoice number. System will show the order.
Post-condition: System will search the order.

51
UC_17:
BRIEF DESCRIPTION: In this use case customer will change his password and
system will save it.
Main flow: Customer will click on update password and will enter the existing
password and new password. System will save the new password.
Post-condition: System will update the password.
UC_18:
BRIEF DESCRIPTION: In this use case CA will generate an account for the
new user of the desktop application.
Main flow: Administrator will click on new account generation and will give the
required information the system will generate the new account for the new
foreman.
Post-condition: Account will be generated successfully.

52
Chapter 3: Design Document
3.1. Introduction:
Third deliverable is all about the software design. In the previous deliverable, analysis of
the system is completed. So we understand the current situation of the problem domain.
Now we are ready to strive for a solution for the problem domain by using object-
oriented approach. Following artifacts must be included in the 3rd deliverable.
1. Domain Model
2. System Sequence Diagram
3. Sequence Diagram
4. Collaboration Diagram
5. Operation Contracts
6. Design Class Diagram
7. State Transition Diagram
8. Data Model
Now we discuss these artifacts one by one as follows:

53
3.2. Domain Model
Domain Model

54
3.3. Sequence Diagram:
Sequence Desktop:
Sequence desktop
3.3.1: SEQUENCE ONLINE:
Sequence Online

55
3.5. Collaboration Diagram
Collaboration Diagram
3.6. Operation Contracts
Operation Contract Syntax
Name: : Place Order
Responsibilities: Order request
Cross References: UC_1

Exceptions: none
Preconditions: Customer should have an active account. Customer will log in.
Postconditions: Order have been placed successfully.
Name: Registration request.
Responsibilities: Sign up for website

56

Exceptions: none
Preconditions: User will open website on browser
Postconditions: User have been registered successfully.
Name: Payment
Responsibilities: Product delivery, Payment , Clearance from the system

Exceptions: none
Preconditions: User must have place an order. System must have confirm the respective
order. The company has deliver the order.
Postconditions: Foreman should be logged in. Foreman will receive the payment and will
clear the debts from the system.
Name: Enter record
Responsibilities: enter sale, enter purchase , enter labor record, enter financial record
Cross References: UC_5,UC_6,UC_7,UC_8,UC_9,UC_10,UC_11
Exceptions: none
Preconditions: Foreman should be logged in
Postconditions: Foreman have successfully entered sale, purchase ,labor record or any
type of financial data.

57
3.7. Design Class Diagram
CLASS DIAGRAM

58
3.8. State chart diagram

WEBSITE:
STATE CHART 2

59
DESKTOP:
state chart 1

60
3.9. Data Model

The data model is a subset of the implementation model, which describes the logical and
physical representation of persistent data in the system.
Data Model
Chapter 4: User Interface Design

61
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

62
4.2. Site Maps
4.3. Story boards
First step: User will Log in

63
Second step: Dashboard will appear after successful logging in
User can move to any module from dashboard like this is the employee registration
module.

64
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

65
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.

66
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.
67
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

68
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

69
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 .

70
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;
71
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

72
 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

73
 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:
74
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
75
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.

76
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

77

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

78
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

79

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

80

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

81

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

82

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

83

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.

84
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

85

 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.

86

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.

87
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
5.6. Test item transmittal report

88
Transmittal report ITEM Test Time Location Tester Status

Identifier Case Or
identifie Media
r
001B User Interface 001 2 Days Laptop Rana M. Hamza
Core i5 Arshad
4GB RAM
002B Form 002 2 Days Laptop Hamza Bin Javed
communication Core i5
4GB RAM
003B Form Validation 003 2 Days Laptop Hamza Bin Javed
Core i5
4GB RAM
004B Database 004 1week Laptop Hamza Bin Javed
connectivity Core i5
4GB RAM
005B Debugging of 005 2 Laptop Sharjeel Tariq
code weeks Core i5
4GB RAM
006B Exception 006 2 Laptop Sharjeel Tariq
Handling weeks Core i5
4GB RAM
007B Reports 007 2 hoursLaptop Rana M.Hamza
generation Core i5 Arshad
4GB RAM
5.6.2.5. Approvals
5.7. Test log
Test Log Description Test procedureResults Author

Identifier identifier
001C The item tested is User001A Satisfactory Rana M.hamza

interface. The system on which
testing has been done is core I5
laptop with 4GB RAM

89
002C The item tested is002A Satisfactory Hamza Bin Javed

communication between forms .
The system on which testing
has been done is core i5 laptop
with 4GB RAM.
003C The item tested is form003A Satisfactory Hamza Bin Javed

validation and he system on
which this test has been
conducted is core i5 laptop with
4GB RAM
004C The item tested is database004A Satisfactory Hamza Bin Javed
connectivity and the system on
which this test has been
performed is a core i5 laptop
with 4GB RAM.
005C The item tested is bugs in the 005A Satisfactory Sharjeel Tariq
code and the system on which
this test has been performed is a
core i5 laptop with 4 GB RAM
006C The item tested is 006A Satisfactory Sharjeel Tariq
exception handling and the
system used is core i5 with 4 gb
ram
007C The module tested is of reports Satisfactory Rana M. Hamza
generation and the system used 007A
is core i5 with 4 gb ram

90
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.

91
5.9. Test summary report
5.9.2.1. Test summary report identifier

010
5.9.2.2. Summary
Test Log Description Test procedureResults

Identifier identifier
001C The item tested is User interface. The 001A Satisfactory

system on which testing has been done is
core I5 laptop with 4GB RAM
002C The item tested is communication002A Satisfactory

between forms . The system on which
testing has been done is core i5 laptop
with 4GB RAM.
003C The item tested is form validation and he003A Satisfactory

system on which this test has been
conducted is core i5 laptop with 4GB
RAM
004C The item tested is database connectivity 004A Satisfactory

and the system on which this test has
been performed is a core i5 laptop with
4GB RAM.
005C The item tested is bugs in the code and 005A Satisfactory
the system on which this test has been
performed is a core i5 laptop with 4 GB
RAM
006C The item tested is exception 006A Satisfactory
handling and the system used is core i5
with 4 gb ram
007C The module tested is of reports generation Satisfactory
and the system used is core i5 with 4 gb 007A
ram

92
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

93
Appendixes:

94
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.

95
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.

96
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

97
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.

98
Appendixes:

99
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.
100
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

101
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

102
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.

103

104

"Automation of Weltron Kitchenware": Department of Information Technology

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

"Automation of Weltron Kitchenware": Department of Information Technology

Enviado por

Direitos autorais:

Formatos disponíveis

SE- UOG - Project Coordination Office Version: 1.

Department of Information Technology

“Automation of Weltron Kitchenware”

Session : BSCS Spring 2014-2018

Project Supervisor: Sir Rameez Iqbal

Hamza Bin Javed 14064119-021

Sharjeel Tariq 14064119-009

Rana M.Hamza Arshad 14064119-047

Department of Computer Science

© Department of Computer Science

Date: June 25, 2018

© Department of Computer Science

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

© Department of Computer Science

3.7. DESIGN CLASS DIAGRAM........................................................................................61

Chapter 1: Project Feasibility Report

1.2. Project/Product Feasibility Report

1.2.1. Technical Feasibility

Q-1 Is the proposed system practical?

© Department of Computer Science

Q-2 Do we currently possess the necessary technology?

1.2.2. Operational Feasibility

1.2.3. Economic Feasibility

1.2.4. Schedule Feasibility.

1.2.5. Specification Feasibility

© Department of Computer Science

1.2.6. Information Feasibility

1.2.7. Motivational Feasibility

1.2.8. Legal & Ethical Feasibility

1.3. Project/Product Scope

1.4. Project/Product Costing

© Department of Computer Science

1.4.1. Project Cost Estimation By Function Point Analysis

Total function point calculated are 118.58

© Department of Computer Science

1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model)

PM= person-month (effort) KLOC= lines of code, in thousands

People Required = 20.16/ 17.64=2

1.4.3. Activity Based Costing

Activity Resources Cost Rate Duration

© Department of Computer Science

1.5. Task Dependency Table

1.6. CPM - Critical Path Method

Activity Immediate Predecessor Duration (Weeks)

© Department of Computer Science

Network Diagram for the above-mentioned activities

The parameters and slacks are calculated as follows:

The critical path is:

© Department of Computer Science

1.7. Gantt chart

1.8. Introduction to Team member and their skill set

Members Name Skill Set Tasks

© Department of Computer Science

1.9. Task and Member Assignment Table

Task Duration (days) Dependencies Members

Task durations and dependencies

1.1.18 1.2.18 1.3.18 1.4.18 1.5.18 1.6.18 31.7.18

Activity Bar Chart

© Department of Computer Science

Allocation of People to Activities:

1.1.18 1.2.18 1.3.18 1.4.18 1.5.18 1.6.18 31.7.18

© Department of Computer Science

1.10. Tools and Technology with reasoning