ERP Report

ANALYSIS AND DESIGN OF AN AUTOMATED INFORMATION SYSTEM TO MANAGE
SALES PROCESS OF HONEYCOM SERVICES LIMITED

by

Masudul Mannan
ID#0020081

An Internship Report Presented in Partial Fulfillment
of the Requirements for the Degree
Bachelor of Business Administration

INDEPENDENT UNIVERSITY, BANGLADESH
April 2006
ANALYSIS AND DESIGN OF AN AUTOMATED INFORMATION SYSTEM TO MANAGE
SALES PROCESS OF HONEYCOM SERVICES LIMITED

by

Masudul Mannan
ID#0020081

has been approved
April, 2006

___________________________
Mr. Akhtaruzzaman Sarkar
Lecturer
School of Business
Independent University, Bangladesh

April 30, 2006

Mr. Akhtaruzzaman Sarkar
Lecturer
School of Business
Independent University, Bangladesh

Subject: Submission of a report on Analysis and Design of an Automated Information System to
Manage Sales Process of Honeycom Services Ltd.

Dear Sir,
With humble submission I would like to draw your kind attention to the fact that I have great
pleasure as I have been successful in submitting the report Analysis and Design of an Automated
Information System to Manage Sales Process of Honeycom Services Limited, which was
assigned to me as a partial requirement of my internship. I have tried my best to make this report
an exclusive one within the given time period. I deem to be highly rewarded if this report serves
its objectives in all aspects.

I state that this report has not been submitted or used for any other degree or course. I shall be
pleased to answer any query you think necessary as now and when needed with best regards.

Sincerely,

Masudul Mannan
ID#0020081

ACKNOWLEDGEMENT

It is my pleasure to take this opportunity to acknowledge the guidance, help and patience of
many people to whom I render my gratitude, without those I would have never been able to
accomplish my internship and also this project to this stage.

First of all I like to pay my gratitude to my academic supervisor Mr. Akhtaruzzaman Sarkar
(Lecturer, Independent University, Bangladesh) for giving me the opportunity to do the project.
His insightful discussions, constant suggestions and guidance enabled me to resolve a number of
issues related to my project and helped me to work without staggering. Without his help this
report could not have been a comprehensive one.

I also like pay my appreciation to Tawhid Sarwar Hossain Managing Director of Honeycom
Services Limited for giving me the opportunity to implement my knowledge and studies and to
offer me the opportunity to use the resources of his organization for the evolvement of my studies
through database development.

I like to express my sincere thanks to my organizational supervisor Mr. M. A. Shakoor
(Manager, HR and Finance, Honeycom Services Ltd.) for his careful suggestion and direction for
successful accomplishment of my project. In the entire course of this project, from the beginning
to the end, he helped me consistently and constructively.

Executive Summary

This research paper is based on the Analysis and Design of an Automated Information System
to Manage Sales Process of Honeycom Services Ltd. This report will attempt to let the user
identify the necessity of an automated information system of Honeycom Services Ltd. There are
number of problems have been identified with the existing system and they are greatly looking
for a new system which will solve the entire existing problem. This report is being generated to
develop an automated information system for sales process instead of an existing manual system.
To develop this system the waterfall model which is a popular version of the SDLC model for
software engineering has been used. The current manual system has number of problem like;
complicated data sharing process, huge time is needed to acquire information and they are failing
to run their organization smoothly etc. The proposed system will overcome these problems. The
proposed system is designed using the modern technique of system development such as Data
Flow Diagram and Entity-Relationship model and also the physical design is carried out where a
Data Dictionary is used for documenting all the specific data terms. The object oriented database
design approach has also been carried out for this project. In objects oriented approach a range of
UML (Unified Modeling Language) diagrams have been used to get a very clear picture of their
sales process to design the automated information system as smooth as possible. The prototype
user interface has also been designed and some skin shot of the user interface has been shown in
chapter 7. This system is developed using MS SQL Server2000 at the back end and Visual Basic
6.0 at the front end.
The system has developed as friendly as possible so that to operate this software no extra
training is needed. The existing hardware and software will be sufficient to run this system. The
feasibility study has been carried out and it is found that the system is feasible.
Due to the time limitation the software hasnt been tested. It was not also possible for the
researcher to run much error checking. Sometimes it became really hard for the researcher to
develop the system as the client intended due to some ambiguous information. It is possible to
overcome these problems and the researcher hopes that in future these problems will be overcome
and the system will work smoothly and efficiently as it is required. Future improvement of the
information system will be based on the clients feedback and their future requirements.

TABLE OF CONTENTS

Topic Page No.

Chapter-1 Introduction

1.1 Introduction 1
1.2 Background of the project 1
1.3 Problem Justification 2
1.4 Purpose of the Project 2
1.5 Objective of the project 2
1.6 Limitations of the project 3
1.7 Significance of the project 3

Chapter-2 Organizational Overview

2.0 History of the Organization 4
2.1 Organization Background 4
2.2 Organization Chart 5

Chapter-3 Methodology

3.0 Methodology 6
3.1 Preliminary Investigation 7
3.1.1 Fact Finding Techniques 7
3.1.1.1 Interviews 8
3.1.1.2 Questioner Survey 8
3.1.1.3 Record Review 8
3.1.1.4 Observation 8
3.2 System Analysis 9
3.2.1 Problem Analysis 9
3.2.2 Requirement Analysis 9
3.2.3 Decision Analysis & Feasibility Study 9
3.3 System Design 10
3.3.1 Logical Design 10
3.3.2 Physical Design 10
3.3.3 Object Oriented Design 10
3.4 System Implementation 11
3.4.1 Programming/Coding 11
3.4.2 Testing & Conversion 11

Chapter-4 System Analysis

4.0 System Analysis 12
4.1 Components of the Information System 12
4.1.1 People 12
4.1.2 Procedures 12
4.1.3 Data 13
4.1.4 Software 13
4.1.5 Hardware and Network 14
4.2 Phases of System Analysis 14
4.3 Problem Analysis 14
4.3.1 Description of the Existing Business System 15
4.3.2 Identified Problems 19
4.4 Requirement Analysis 19
4.4.1 Functional Requirements 19
4.4.1.1 Input 19
4.4.1.2 Processing 20
4.4.1.3 Output 20
4.4.1.4 Storage 20
4.4.1.5 Control 20
4.4.2 Non Functional Requirements 21
4.5 Decision Analysis and Feasibility Study 22
4.5.1 Feasibility Study 22
4.5.1.1 Feasibility Study of Solution A 23
4.5.1.2 Feasibility Study of Solution B 23
4.5.1.3 Feasibility Study of Solution C 23
4.5.1.4 Feasibility Matrix 24
4.5.2 Proposed Solution 24

Chapter-5 Systems design

5.0 Systems design 27
5.1 Logical design 27
5.1.1 Process Modeling: Data Flow Diagram (DFD) 27
5.1.1.1 DFD Symbols 28
5.1.1.2 Context Level DFD of Sales Management System 31
5.1.1.3 System Level DFD Sales Management System 33
5.1.1.4 Order verification process 35
5.1.1.5 Inventory checking process 36
5.1.1.6 Purchasing Process 37
5.1.1.7 Receiving Process 38
5.1.1.8 Shipping Process 39
5.1.1.9 Installation Process 40
5.1.1.10 Payment Process 41
5.1.2 Logical Data Modeling: E-R Diagram 42
5.1.2.1 Basic Constructs of E-R Modeling 42
5.1.2.2 ERD Notation 44
5.3 Physical design 48
5.3.1 Data Dictionary 48

Chapter-6 Object Oriented Approach

6.1 Object Oriented Approach 55
6.2 Mechanism of Object-oriented Approach 55
6.3 Unified Modeling Language 56
6.3.1 Use Case Diagram 57
6.3.1.1 Use Case Notation 57
6.3.1.2 Use Case Narration 59
6.3.2 Activity Diagram 66
6.3.2.1 Elements of an Activity diagram 66
6.3.2.2 Activity Diagrams of Sales Management System 67

Chapter-7 User Interface

7.0 User Interface 70
7.1 Input Modules 71
7.2 Output Reports 76

Chapter-8 Future Development & Conclusion

8.1 Future Development 78
8.2 Conclusion 78

REFERENCES
APPENDIX

LIST OF TABLES
Topic Page No.

Table 4.1 Feasibility Matrix of Candidate Solutions 24

LIST OF FIGURES
Figure-2.1 Honeycom Services Management Hierarchy 5
Figure-3.1 Waterfall (Traditional) System Development Methodology 6
Figure-4.1 Rich Picture of Current Sales Management System 17
Figure-4.2 Work Flow Diagram of Current Sales Management System 18
Figure-4.3 Work Flow Diagram of the Proposed Solution 26
Figure-5.1 Gane and Sarson DFD Symbols 28
Figure-5.2 Context Level DFD 31
Figure-5.3 System Level DFD (0 Level Diagram) 33
Figure-5.4 Order verification process (Level 1 Diagram) 35
Figure-5.5 Inventory checking process (Level 1 Diagram) 36
Figure-5.6 Purchasing Process (Level 1 Diagram) 37
Figure-5.7 Receiving Process (Level 1 Diagram) 38
Figure 5.8 Shipping Process (Level 1 Diagram) 39
Figure-5.9 Installation Process (Level 1 Diagram) 40
Figure-5.10 Payment Process (Level 1 Diagram) 41
Figure-5.11 ER Diagram of Sales Management System 46
Figure-5.12 Relational Tables of Sales Management System 47
Figure-6.1 Use Case graphical notations 57
Figure-6.2 Use Case Analysis 58
Figure-6.3 Activity Diagram of Selling Product 67
Figure-6.4 Activity Diagram of Product Installation & Support 69
Figure-7.1 Customer Information module 71
Figure-7.2 Manufacture Unit Information module 71
Figure-7.3 LC Details information module 72
Figure-7.4 Bank Information module 72
Figure-7.5 Machine information module 73
Figure-7.6 Engineering Team information module 73
Figure-7.7 Payment information module 74
Figure-7.8 Order details information module 74
Figure-7.9 Shipping information module 75
Figure-7.1 Support information module 75
Figure-7.11 Customer Order Report 76
Figure-7.12 Purchase report 77
Figure-7.13 Payment Report 77
Analysis and Design of an Automated Information System to Manage Sales Process of Honeycom Services

Chapter 1: Introduction
1.1 Introduction
In present day, largely through advances in computer and communication technology we are
living at a time that most people call as the Information age. It is because most working people
today have information-intensive jobs. For example, jobs such as of teacher, accountant, lawyer
and manager are predominantly based on the handling of information.
But even until the eighties, managers did not need to know much about how information was
collected, processed and distributed in their organizations, and technology involved was minimal.
Information was not considered an important asset of the firm. The management process was
considered a face-to-face personal art and not a global coordination process. Today Information
processing has become a matter of strategic importance for any organizations. Information has
become an essential resource as capital or manpower. Expectation of today's customers can only
be met by high technological computerized systems.
Information system has defined by many people in many ways. Some says information
system is A collection of interrelated components that collect, process, store and output
information needed to complete business tasks some says it is The combination of people,
procedures, equipment, and data that process data and information other says it is nothing but
Computer-based tool that helps people transform data into information. Actually they are all
right in their own perspective. An Information System can be defined as a set of interrelated
components working together to collect, process and store, and distributing information to
support decision making, coordination and control in an organization. In addition it may also
help managers to analyze problems, visualize complex subjects and create new products.
A sound information system can help its users to achieve their goals much efficiently and
quickly. But a bad developed information system will cause more trouble for its users rather than
help them. The success of any information system relies on how smoothly the business process
has been analyzed and user requirements have been consider.

1.2 Background of the project
This project has been prepared for fulfilling the requirement of the internship program, which
is titled as Analysis and Design of an Automated Information System to Manage Sales Process
of Honeycom Services Ltd.. This task has been assigned to me by the organizational supervisor


2
Mr. M. A. Shakoor (Manager, HR and Finance, Honeycom Services Ltd.) and has been approved
by the academic supervisor Mr. Akhtaruzzaman Sarkar (Lecturer, Independent University,
Bangladesh).

1.3 Problem Justification
Honeycom Services doesnt maintaining any automated information system for their current
sales process. Most of their works are paper based and because of that their daily task becoming
more complicated. The company is facing several problems because of their manual system.
These problems include difficulty in data sharing between different department, huge duplication
of data, time consuming process and data confliction. The manual system is also responsible for
lack of data security and there is also a possibility of getting inaccurate data.

1.4 Purpose of the Project
After surveying their daily work it has been identified that they are facing various difficulties
because of their existing business process. But if the company maintains a computerized central
database system they will be able to simplify their work. They will be needed to maintain a huge
DBMS to run their daily operation smoothly. But currently the authorities of the organization
want to construct a database to manage their sales process. The company can obtain various
benefits by using the automated information system. The user of the proposed system will get the
following benefits from the software:
Preparing the reports more efficiently, accurately and quickly.
Minimum input of data.
Checking and crosschecking of datas so that any kind of error corruption will be detected
more accurately and precisely.
Any kind of product information will be just one mouse click ahead.

1.5 Objective of the project
The main objective of this project is to build a database management system for Honeycom
Services Ltd. There are number of problems that have been identified with the existing system.
We have followed specific formalized steps to develop a solution for these problems.


3
As the existing system of Honeycom Services Ltd. is mostly a manual one, therefore simple
storing and retrieval of information has become a very time consuming and inefficient task. As a
result, the existing information system (IS) makes it impossible for the management to take
quick, efficient and effective decisions. Looking at the problems posed by the existing IS of
Honeycom Services Ltd. the objective can be summarized as developing an automated
information system for managing the sales process of Honeycom Services Ltd. that will
efficiently and effectively store all information related to the various aspects of service operation,
and will allow the management to accesses those information as necessary and informs that they
(information) are desired by the management, in order to made quick and effective decisions for
proper and optimal business operations.

1.6 Limitations of the project
This project was aimed to provide a complete automated database solution for Honeycom
Services Ltd.. While working on the project the problems came across when the length of time
has taken to conduct the project, because the given time length is not sufficient enough for
conducting a project like this. Since most design decisions were driven by a single developer
(including database design), many design choices were not the best choices available. Another
problem was communication between the developer and the client is not properly clear
sometimes. So, from time to time it has become very hard to develop the system as the client
desire.

1.7 Significance of the project
If the proposed DBMS could be implemented successfully the company will be able to obtain
various benefits by using it. They will be able to share data, reduce data redundancy; speed up
data process time, reduce data confliction, maintain higher security. They will also be able to use
accurate and up-to-date information which will help the management to take swift decisions
effectively and efficiently.

Chapter 2: Organizational Overview
4
2.0 History of the Organization
Honeycom is a registered limited company in Bangladesh specialized is sales, design, install,
commissions and maintenance of Building Management System, Fire Detection & Protection
System and Security Management System with trained and experienced people both at home and
abroad.
The company has started operation in the year 1993. The sales turnover of the company last
year was around two million US dollar. Honeycom believe to the leading technical supports and
marketing centers for all the system the company deal with. Honeycom is able to provide sales as
well as technical expertise unrivaled by any of its competitors through the strength of four full
time marketing specialists in its marketing and sales department and with twelve full time
technical specialists in its engineering department.
The greatest asset of the company is their human resource and technological advancement.
The company continuously invests in training the human resource asset, such as equipping the
technical design team with the skill to use the latest technology in computer aided design (CAD)
and train the software engineers to write their own program for building management system and
fire detection system by using the prescribed software for the designated system.

2.1 Organization Background
Name of the Company: Honeycom Services Limited.
Year of Establishment: The Company started its operation in 1993 in the form of
Honeycom Pte. Ltd. This was later re-established as Honeycom Services Limited in the
year 2000.
Corporate Mission: To delight customer through energy efficiency, a better
environment, great productivity, increased safety and enhanced comfort.
Head Office: 332, Elephant Road (Ground Floor), Dhaka-1205, Bangladesh.
Nature of the Organization: Service oriented organization.
Financial Profile: Authorized Capital US$ 6,50,000
Paid Up Capital US$ 40,000
Number of Office: 2 (Gulshan-1, Elephant Road)

Chapter 2: Organizational Overview
5
Products: Building Management and Security Management services.
Human Resource (Employee): 35
Service Coverage: Primarily serves corporate customers within Dhaka.
Future Growth: The Company has a future plan to contribute its 70% of the human
resources to engineering and market the latest technologies from Honeywell in
Bangladesh

2.2 Organization Chart

Figure-2.1: Honeycom Services Management Hierarchy

Chapter 3: Methodology
6
3.0 Methodology
System development requires careful research, planning and coordination. These factors are
essential in determining the success of any software development project. System Development
Methodology is a collection of procedures, techniques, tools and documentation aids, which help
the system developers in their efforts to implement a new system. The classic system
development life cycle (SDLC) is one of the most popular system development methodologies.
SDLC refers to a methodology for developing systems. It provides a consistent framework of
tasks and deliverables needed to develop systems. The SDLC methodology tracks a project from
an idea developed by the user, through a feasibility study, systems analysis and design,
programming, pilot testing, implementation, and post-implementation analysis. Documentation
developed during the project development is used in the future when the system is reassessed for
its continuation, modification, or deletion. Now a days system developers are using many
versions of SDLC.
The waterfall (traditional) model is a popular version of the SDLC model for software
engineering. Often considered the classic approach to the systems development life cycle, the
waterfall model describes a development method that is rigid and linear. Waterfall development
has distinct goals for each phase of development where each phase is completed for the next one
is started and there is no turning back.

Figure-3.1: Waterfall (Traditional) System Development Methodology

7
The perceived advantages of the waterfall process are that it allows for departmentalization
and managerial control. A schedule is typically set with deadlines for each stage of development
and a product can proceed through the development process. In theory, this process leads to the
project being delivered on time because each phase has been planned in detail. Waterfall system
development methodology is consisting of the following phases.
Preliminary Investigation
System Analysis
System Design
System Implementation
Coding
Testing
Conversion
Maintenance

3.1 Preliminary Investigation
There are basically two purposes of this phase, to answer the question Is this project worth
looking at? and establishing the project charter. The researcher has defined the perceived
problems, opportunities and directives that triggered the projects and assess the risk of pursuing
the project. And also he figure out the scope of the project, preliminary requirements and
constraints, project participants, budget and schedule to establish the project charter. To find
these aspects the researcher has used the fact finding techniques.

3.1.1 Fact Finding Techniques
Fact-finding techniques are used to collect data about requirements. Requirement
determination involves studying the current business system to find out how it works and where
improvements should be made. The very first step is to understand the system as the systems
designers are not part of the user departments and thus do not have the same base of facts and
details as users in those areas. The researcher has used the following fact-finding techniques.
Interview
Record Review

8
Questionnaire
Observation

3.1.1.1 Interviews
Interview is a formal meeting where the analysis can obtain information about the operation
of the present system and the requirement for the new system. This is the most common method
used to verify the proposed system design and gather fact about the procedure. For interview the
researcher asked selected question to different employee of Honeycom Services. The candidates
to be interviewed were, Managing Director, Managers and senior officers. We had to carefully
ask the question so that they must relevant to the interviewee and appropriate to his level and
status.

3.1.1.2 Questioner Survey
A questioner survey had been performed in each department of Honeycom Services to collect
information about various aspects of the existing system from most of the employee. For the
survey purpose both structured and unstructured questions has been used.

3.1.1.3 Record Review
Record review is to review the documents that represent formal information flow in the
organization. Record includes written policy manuals, regulations and standard operating
procedures. The organization has four different departments Marketing Department, Logistic
Support, Service Support and Engineering Department. All these section maintain their various
transactions. The researcher has reviewed those transactions and also has reviewed some report,
which they produced by Ms Access & Ms. Excel.

3.1.1.4 Observation
Through observation analysts can obtain firsthand information about how activities are
carried out. The researcher observed the normal flow of work and typical bottlenecks. He also
observed Informal systems for storing and producing information and also the interoffice
communication and handling of spontaneous queries.


9
3.2 System Analysis
System Analysis is studying business systems to learn current methods and assess
effectiveness. In this phase the existing system was studied and the requirements for the new
system was determined. This phase itself consists of component phases:
Problem Analysis
Requirement Analysis
Decision Analysis
Feasibility Study

3.2.1 Problem Analysis
In the problem analysis phase existing sales process system of Honeycom Services was
studied. The flaws and shortcomings of the current system were identified.

3.2.2 Requirement Analysis
Defining and prioritizing new system requirements were done in this phase. This phase was
considered as the most important phase because errors or omissions in requirement analysis phase
result in user dissatisfaction with the final system and costly modifications. The researcher has
identified who needs what information, where, when, how etc.

3.2.3 Decision Analysis & Feasibility Study
In this phase candidate solutions will be identified. Feasibility of these solutions will be
analyzed and a new system will be recommended. Though feasibility study is a separate phase of
system analysis but because of which solution needed to be implemented to determine that, the
researcher has to carry out the feasibility phase along with the decision analysis phase.
Technical, Economical and Operational feasibility were carried out to ensure that the new project
is viable and will be accepted in the organization based on their resources and constraints.


10
3.3 System Design
This is the phase of the system development where an appropriate solution is devised to fulfill
all the information requirements of the system identified from the previous System Analysis
phase. The design phase is concerned with technology-based views of the system's Data,
processes and Interfaces. Design specifications can take many forms including written
documentation, or working computer generated prototypes of the new system. The researcher has
used three types of design strategy for this system.

3.3.1 Logical Design
Logical design lays out the components of the system and their relationship to each other as
they would appear to users. In this project the researcher has used two types of logical design.
They are:
Process Modeling: Data Flow Diagram (DFD)
Data Modeling: Entity Relationship Diagram (ERD)

3.3.2 Physical Design
Physical design is the process of translating the logical abstract model into the specific
technical design for the new system. In this project the researcher will develop a Data Dictionary
for physical data modeling.

3.3.3 Object Oriented Design
The researcher has also used the object-oriented approaches besides process and data oriented
approach to develop this system. The principals of objects, encapsulation, inheritance, and
polymorphism are the foundation for object-oriented systems development. To understand and
express the essential and interesting features of an application in the complex real world, an
object-oriented model is built around objects. An object encapsulates both data and behavior,
implying that analysts can use the object-oriented approach for both data modeling and process
modeling.

11
The researcher has used the Unified Modeling Language (UML) as an object-oriented
approach. It is a language for specifying, visualizing, constructing, and documenting the artifacts
of software systems, as well as for business modeling (UML Document Set, 2001). UML
includes many modeling language. Among them two popular and commonly used diagrams are
shown in this project.
Use Case Diagram
Activity Diagram

3.4 System Implementation
System implementation is the fourth phase of the waterfall system development method. This
phase is consist of another three different phases. Coding, Testing and Conversion are the three
phase of implementation. The researcher has carried out the coding phase for this project but due
to time limitation it hasnt been possible for him to carry the other two phases.

3.4.1 Programming/Coding
In this phase standards User-Interface were designed and Coding were done. Various user-
friendly forms were designed. Incase of form designing similar and consistent color was
maintained. A user-friendly menu was developed for easy understanding. Wherever possible a
variety of options were put in place to reduce confusion or facilitate user input by using different
designing concepts like combo boxes, data control etc.

3.4.2 Testing & Conversion
In future this two phase will be carried out to ensure that the top quality and workability of
the software. Future studies should identify and analyze these factors of database development.

Chapter 4: System Analysis
12
4.0 System Analysis
Before starting the system analysis phase we have to know about what is an information
system and what are its component. In the introduction the researcher has already discussed
about what is an information system. In here the components of an information system will be
discussed briefly.

4.1 Components of the Information System
The five major components of information systems are people, procedures, data, hardware
and software. With the extensive use of network systems in todays business organizations, some
researchers consider network as a separate components of information systems.

4.1.1 People
People are required for the operation of all information systems. People are divided into two
classes.
Users are people who use an information system or the information it produces. They can be
accountants salespersons, engineers, clerks, customers or managers. They can be further divided
into following basic groups:
End-users: directly using the information system to perform their job activities.
Honeycom Services has two computer operators who works as end users for their existing
information system
User manager: supervising the end-users. For three different departments the organization
has different managers who are working as user manager.
IS specialists are people who develop and operate information systems. They include systems
analysts, programmers, computer operators, etc. There are no IS specialists currently working in
the organization.

4.1.2 Procedures
Simply stated procedures are sets of instructions that tell people in the organization how to
perform their jobs. As an organization evolves, it develops standard operating procedures (SOP)
13
to guide its operations. These procedures may be formal or informal. Undocumented procedures
belong lo the informal category. Procedures are instruction for people. The procedure
components of an information system are of three types:
Control procedures: backing up data or verifying input. In this system after any new
record has been entered, the system has to keep a copy of the records in paper in addition
to the computer file with the help of a file system.
Application procedures: how to run the business application. Computerized application
procedures include running the application in MS-Excel sheet. Besides the manual sorting
of customers files in ordered way and get into the information is also an application
procedure in this system.
System procedures: describe how to operate hardware. The organization runs their
applications in the Windows XP professional operating system in several computers.

4.1.3 Data
The raw data is collected from the customer order, machinery information, and manufacturer,
opening LC form, customers personal information and bank branch list, which are checked by
the office Clerk. It is kept on a file base system.

4.1.4 Software
Software resources include all sets of information processing instructions for the computer.
There are two types of software are used to maintain the information of sales process of
Honeycom Services.
System Software (O/S): Eight computers are running on Windows XP platform. The
networking is also done by this operating system.
Application Softwares (MS Office, Microsoft SQL Server 2000 etc.): The main purpose
of this software packages is to calculate, record keeping, word processing and to maintain
the database.
14
4.1.5 Hardware and Network
Hardware resources include all physical devices and materials used in information processing.
It includes computers, calculators, printing devices, input devices, storage media, etc, that is all
tangible objects. The company is currently using twenty workstations and each of them is either
IBM or HP Pentium-III computers with at least 256MB RAM and 40GB hard disk. These
computers are connected through a local network. The company is currently using a simple Peer
to Peer Network system. This kind of networks offers the ability to share workstation devices
such as printers, and access disk drives on other workstations. This network has been established
between fourteen of the computes and several printers by using Ethernet LAN cards and a layer
three HUB.

4.2 Phases of System Analysis
The analysis stage begins with the business models developed during the initial strategy stage.
The preliminary analysis findings are verified and expanded into sufficient detail to describe
exactly "what" will and will not be built into the system. It is the process of gathering and
interpreting facts, diagnosing problems, defining the problem and recognizing causes using the
information to recommend improvements to the system. The information obtained during the
analysis stage is documented in the requirement specification. The requirement specification
establishes the foundation for all-subsequent design and development work. This phase itself
consists of four different phases. The phases are:
Problem Analysis
Requirement Analysis
Decision Analysis
Feasibility Study

For analyzing Honeycom Services current sales process and to recommend improvement for
the system the researcher has carried out all these four phases.
4.3 Problem Analysis
In problem analysis the current system is analyze and the problems that are hampering the
process are identified.
15
4.3.1 Description of the Existing Business System
The company (Honeycom) sells their products (machineries) in two methods. One approach
is costumers come to the company and order for products or sometimes the company itself goes
outside to sell their products. When customers come to purchase their products the company
provides product description catalogues to customers from where they choose their preferred
machineries. After selecting suitable products, the company and the customer come to an
agreement and after that the customer confirms their order for purchasing machineries. After
receiving the order confirmation from customer the company checks their stock. If the product is
available they (company) checks customer account and sees whether the account is valid or not
and after checking it they accept the order. On the other hand if the product is not available in
their stock, then the company prepares a purchase request and opens LC in a bank. Afterwards
they send this purchase request along with the LC to the manufacturing companies (Honeywell)
which are located in different countries.
After receiving the purchase request and LC confirmation from the dealer company
(Honeycom) the manufacturing company start building the machine as customer require. After
the production phase the machines or equipments are delivered to Dealer Company by various
shipping process. After getting the product from manufacture unit the company (Honeycom)
verifies that whether the manufacture unit sends the right product and also checks the condition of
the products. Then they officially receive the product and update their inventory position. After
that they start the shipping procedure. Before shipping the product the company makes sure
which shipping method will be appropriate for the selected product. After that they prepare an
invoice of the shipment. Then they dispatch the product to customer along with the shipment
invoice. After the products are received by the customer, the engineering teams of dealer
company start setting the machine as the customer required or sometimes the company itself
suggests the setting procedure. During this time the company may have to provide some extra-
services, like various equipments for setting the machine. Sometimes the company provides
these equipments for free and sometimes they charge customer for those. After the setting period
company offer customer technical supports that they provide for free which includes train
customer how to use the product, handle the use of machine for customer for few months. After
installation and support when the customer is satisfied the payments of the machine take place by
agreement. Sometimes the customer pay in full or sometimes they pay in installment. In case of
16
full payment the company provides the customer a payment receipt. On the other hand in case of
installment the company verifies customer account. They prepare a billing statement with terms
and condition and send it to customer. The payment transactions are done through banks.
After finishing all kind of transactions and product setup procedures the company offer
customer service support by their engineering teams. These supports include warranty and
maintenance of the machine, which can be varied for different type products.

17

Figure-4.1: Rich Picture of Current Sales Management System of Honeycom Services
18

Figure-4.2: Work Flow Diagram of Current Sales Management System of Honeycom Services (As-Is Diagram)
19
4.3.2 Identified Problems
A number of problems have been identified in the current business process and manual
information. These problems are:
Because of manual system various data sharing is very complicated.
Because of the existing manual system there is a huge duplication of data.
Simple retrieval of important information takes a long time, as a result the business
process become very time-consuming.
Since the datas are handle by people the security of those data very less, like an employee
can manipulate those as he/she want.
Sometimes inaccurate datas are providing in manual system.

4.4 Requirement Analysis
It is the stage for defining and prioritizing business requirements. This is perhaps the most
important phase. Errors or omissions in requirement analysis result in user dissatisfaction with
the final system and costly modifications. Establish what the new system must do. This phase
involves identifying who needs what information, where, when and how, broadly speaking this
stage identifies the data, process and interface requirements for the users of the new system. Both
functional and non functional requirements have been identified in this phase.

4.4.1 Functional Requirements
A system function is an activity or process step, which is expressed as an action verb followed
by the object of the action. Functional requirements describe the behaviors (functions or
services) of the system that support user goals, tasks or activities. An information system
performs five basic functions.

4.4.1.1 Input
Involves inserting and updating, which are to be entered and processed in the module. The
types of input that are implemented in this module are:
Information about manufacture unit
20
Information about LC
Information about customer
Information about how an order is placed
Information about certain machinery etc.

4.4.1.2 Processing
Processing functions describe the way that data are manipulated to perform business function.
This involves the processing of inputs that are later used to generate reports as output. The basic
processing involves:
Processing of order information
Processing machinery information
Processing purchase request etc.

4.4.1.3 Output
In Honeycom Services the outputs from the processing are the report such as the order
information, money receipt, machinery information, purchase information etc. These reports are
printed daily and weekly basis depending on their needs.

4.4.1.4 Storage
Storage Functions describe the activities required to maintain system data. Captured data
must be stored in storage medium in an organized way for subsequent retrieval of the data. Datas
are retrieved from database using SQL queries. Currently the company is storing their data into
different separate databases which they are maintaining manually. But in the proposed automated
system data will be store in a single central data store.

4.4.1.5 Control
Control functions describe the manual and automated activities performed to verify the
validity and accuracy of inputs and outputs, to ensure the integrity of stored data and provide data
security with controlled access to data and processing information. Insertions of data are
controlled by various warning message. For example; checking the insertion of Manufacture unit
Id, Customer ID, and Machine ID etc, the main field that must be entered are controlled by
21
following coding convention. [A-Z][A-Z][1-9][0-9][0-9][0-9][0-9]. Proper data must be entered if
the data is to be inserted successfully.
4.4.2 Non Functional Requirements
A system has properties that emerge from the combination of its parts. These emergent
properties will surely be a matter of accident, not design, if the non-functional requirements, or
system qualities, are not specified in advance. Non-functional requirements include constraints
and qualities. Which means what the information system can do better and in what step its work
will be hampered. Non Functional Requirements of proposed sales process of Honeycon
Services is identified as:
Accuracy: the system has accuracy. It means that the system has a provision of right or
agreed results or effects.
Compliance: The system is altered to application related standards.
Fault Tolerance: The system has the ability to tolerate a given level of performance even
if there are faults.
Analyzability: Identification of deficiencies, failure causes, parts to be modified, etc will
be easy to analyze.
Maturity: The software has a moderate frequency of failure by faults.
Understandability: Users can easily understand the structure of the system. Thus, they
can control and of operate the system by giving less effort.
Changeability: The system requires less effort for modification and fault removal
activities.
Stability: Risk of unexpected effects of modification is low.
Testability: Less effort is needed for validating the modified software.
Install ability: Less effort is needed to install the software in a given environment.
Adaptability: The system has a moderate chance for adaptation to different
environments.
Recoverability: Capability of reestablish level of performance after faults is high.
Time behavior: Response and processing times and throughput rates are relatively low.
Stability: Risk of unexpected effect of modifications is low.

22
4.5 Decision Analysis and Feasibility Study
The purpose of this phase is to identify candidate solutions, analyze their feasibility and
recommend a new system. Though feasibility study is a separate phase of system analysis but
because of which solution needed to be implemented to determine that the researcher has to carry
out the feasibility phase along with the decision analysis phase.
To solve the problems which Honecom Services is facing for their current business process
the researcher has proposed three different solutions. These solutions are:
Solution A: The Company can buy a new software system from any software developer
for its sales management system.
Solution B: An automated information system could be developed for managing the sales
process of Honeycom Services. This will convert the existing manual into a computerized
database system.
Solution C: The Company can hire more people and buy more computers for their
existing manual system.

4.5.1 Feasibility Study
In addition to suggesting a solution, systems analysis involves a feasibility study to determine
whether that solution is feasible, or achievable, given the organization's resources and constraints.
Three major areas of feasibility must be addressed:
1. Technical Feasibility: whether the proposed solution can be implemented with the
available hardware, software and technical resources. Does the company staff have the
technical expertise to use the solution?
2. Economic Feasibility: whether the benefits of the proposed solution outweigh the costs
(is it cost-effective?).
3. Operational Feasibility: whether the proposed solution is desirable within the existing
managerial and organizational framework. How the proposed solutions change the work
environment? How do the users feel about such a solution?

To determine which solution has a better chance of solving the problem feasibility study has
carried out for all three of the proposed solutions and for better understanding a feasibility matrix
has been provided at the end of feasibility study.
23

4.5.1.1 Feasibility Study of Solution A
Economic Feasibility: This solution is economically feasible. It is not only affordable
but it will reduce cost for the company in the long run.
Technical Feasibility: This solution is not technically feasible because the hardware,
software and technical resources available at Honeycom Services may not be compatible
with the software.
Operational Feasibility: Senior management will not support this solution because these
softwares are default made. There is an immense possibility that this software will not
fulfill all the requirement of the company.

4.5.1.2 Feasibility Study of Solution B
Economic Feasibility: Honeycom has the capability to develop a new system which will
bring revenue for the company in the long run. Another economic benefit is to run the
new system they will not need any additional resources. They will be able to manage the
new system with their existence resources that they have i.e. with their current hardware,
software. So the new system will be cost effective.
Technical Feasibility: Since the system will be designed as the company required, they
will know how to operate and maintain the system. The researcher has analyzed that
whether the proposed solution could be implemented with the hardware, software and
technical resources available at Honeycon Services Limited. For the project, Honeycom
have to have Windows XP professional operating system and a network setup which they
already have.
Operational Feasibility: Senior management will support this solution as the system will
be designed according to the companys requirement. It will help the company to sort out
all of their problems.

4.5.1.3 Feasibility Study of Solution C
Economic Feasibility: Although this solution is affordable it will not be able to generate
much revenue for the company. So, it is not cost-effective.
24
Technical Feasibility: operating this solution will require neither any sophisticated
technology nor any high skilled professional. Thus it is technically feasible.
Operational Feasibility: The management will not support such a solution as it will
require the company to hire more employees. Moreover this process will be time
consuming and thus it will not serve the purpose of the company.

4.5.1.4 Feasibility Matrix
Feasibility study of all the proposed solutions are summarized into a table called feasibility
matrix. This matrix will give a clear picture of the feasibility study of the candidate solutions and
also help the researcher and the top management of Honeycom Services to decide which solution
to implement.

Table 4.1
Feasibility Matrix of Candidate Solutions

Solution Name Economical
Feasibility
Technically
Feasibility
Operational
Feasibility

Buy a default software
for the sales process

X

X

Develop an automated
Information System

Acquire more resources
for the existing manual
system.

X

X

4.5.2 Proposed Solution
In the workflow of existing business process of Honeycom it has been shown that the
company is keeping separate databases for different activities. The company is keeping different
databases for client, product, manufacture unit, installation, support and payment. All these
databases are maintained by different department of the company. For example, the marketing
department of the company is managing client database while product and manufacture unit
databases are handled by the inventory control. As the company is keeping separate databases for
25
different activities the company is facing many problems; like, data redundancy, data sharing
problem, lack of security of important data etc.
As the company is trying to solve all these problems it has been suggested that they can
develop an automated information system (central database) to manage their sales process instead
of maintaining different databases for their activities. This central database will be connected
with all the databases that are maintained by the different department of the company. By
maintaining this central database it will be possible for the company to minimize the above
mentioned problems. By maintaining a central database different department of the company will
be able to share information and also they dont have to store same information again and again.
In a central database it is possible to customized data access level which means no person can
access any important data without proper authorization. As a result the security level of
confidential data will be high. The company will also be able to handle various data very simply
because of using one central database rather than maintaining different databases.
26

Figure-4.3: Work Flow Diagram of the Proposed Solution (To-Be Diagram)

Chapter 5: System Design
27
5.0 Systems design
While systems analysis describes what a system should do to meet information requirements,
systems design shows how, the system will fulfill this objective. The design of an information
system is the overall plan or model for that system. Systems design has three objectives:
Systems designer is responsible for considering alternative technology configurations for
carrying out and developing the system.
Designers are responsible for the management and control of the technical realization of
systems.
The system designer details the system specification that will deliver the functions
identified during analysis.
The design phase is concerned with technology-based views of the system's Data, processes
and Interfaces. Design specifications can take many forms including written documentation, or
working computer generated prototypes of the new system. There are two types of design 1)
Logical design; 2) Physical design. In this chapter both logical and physical design of Honeycom
Services proposed Sales Management System has been carried out.

5.1 Logical design
Logical design lays out the components of the system and their relationship to each other as
they would appear to users. In this project two types of logical design have been used. They are:
Process Modeling: Data Flow Diagram (DFD)
Data Modeling: Entity Relationship Diagram (ERD)

5.1.1 Process Modeling: Data Flow Diagram (DFD)
The DFD is an excellent communication tool for analysts to model processes and functional
requirements. One of the primary tools of the structured analysis efforts of the 1970's it was
developed and enhanced by the likes of Yourdon, McMenamin, Palmer, Gane and Sarson. It is
still considered one of the best modeling techniques for eliciting and representing the processing
requirements of a system.

28
Used effectively, it is a useful and easy to understand modeling tool. It has broad application
and usability across most software development projects. It is easily integrated with data
modeling, workflow modeling tools, and textual specs. Together with these, it provides analysts
and developers with solid models and specs.

5.1.1.1 DFD Symbols
The diagrams use four symbols to represent any system at any level of detail. The four
symbols that must be represented are:
Processes - transforms of incoming data flow(s) to outgoing data flow(s)
External Entities - sources or destinations outside the specified system boundary
Data Flows - movement of data in the system
Data Stores - data repositories for data that is not moving
The following figure presents the symbols of a DFD that are developed by Gane and Sarson
(1979)

Figure-5.1: Gane and Sarson DFD Symbols

External Entity(s) (Sink, Source, Terminator)
Also known as External sources/recipients are things (e.g. customer, machines, company
etc.) which contribute data or information to the system or which receive data/information from
it. The name given to an external entity represents a type not a specific instance of the type.
It is common practice to have duplicates of external entities in order to avoid crossing lines, or

29
just to make a diagram more readable. The symbol used for this is rectangular box which may be
shaded.

Process (Activity, Function)
Depending on the level of the diagram it may represent the whole system as in a Context
diagram or a business area, process (activity), function, etc. in lower levels. Each box has a
unique number as identifier (top middle). The symbol used for represent process are circle
(Yourdon notation), or a rounded rectangle (Gane & Sarson notation).

Data Flows
It shows the directional movement of data to and from external entities, the process and data
stores. In the physical model, when it flows into a data store, it means write, update, delete, etc.
and when it flows out of data stores mean read, query, display, select types of transaction. The
symbol used for this is solid line with arrow. The arrows must either start and/or end at a process
box. It is impossible for data to flow from data store to data store except via a process, and
external entities are not allowed to access data stores directly. Each data flow is identified with a
descriptive name that represents the information (data packet) on the data flow.

Data Store
A data store is a repository of information. In the physical model, this represents a file, table,
etc. In the logical model, a data store is an object or entity. The symbol used for this is two
parallel lines (Yourdon notation), or an open ended rectangle (G&S notation). As like external
entities, it is common practice to have duplicates of data stores to make a diagram less cluttered.

Layers (Levels) of Data Flow Diagram
Data flow diagrams are usually drawn in several nested layers. A single process node on a
high level diagram can be expanded to show a more detailed data flow diagram. The data flow
diagram is analogous to a road map. It is a network model of all possibilities with different detail
shown on different hierarchical levels. The different levels are Context Diagrams, System Level
(Level 0) and Sub-Systems (Level 1)

30
The context diagram is the highest level in a data flow diagram and contains only one process,
representing the entire system. All external entities are shown on the context diagram as well as
major data flow to and from them. The diagram is fairly simple to create.
More detail than the context diagram permits is achievable by "exploding the diagrams."
Inputs and outputs specified in the first diagram remain constant in all subsequent diagrams.
Diagram 0 is the explosion of the context diagram and may include up to nine processes. Each
process is numbered with an integer. The major data stores of the system and all external entities
are included on Diagram 0.
Each process on Diagram 0 may in turn be exploded to create a more detailed child diagram.
The process on Diagram 0 that is exploded is called the parent process, and the diagram that
results is called the child diagram. The child diagram is given the same number as its parent
process in Diagram 0. For example, process 3 would explode to Diagram 3. The processes on
the child diagram are numbered using the parent process number, a decimal point, and a unique
number for each child process. On Diagram 3, the processes would be numbered 3.1, 3.2, 3.3,
and so on. This convention allows the analyst to trace a series of processes through many levels
of explosion.


31
5.1.1.2 Context Level DFD of Sales Management System

Figure-5.2: Context Level DFD

32
Context level DFD generally shows the total background of a process. Every entity that is
involved with the system is shown here and it has the main data store in which every data which
are generated by the process are stored. So we can say that context level DFD is the basic
structure of the information flow in a system.
In this context level DFD there are six entities. They are company (Honeycom), Customer,
Finance, Manufacture Unit, Bank and Engineering Team. The process in which these entities are
involved is addressed as Sales Management System. The data store is called the Sales Database.
This process initiated when customer place an order to purchase machineries. This order is
verified and confirmed by the company. Then the company checks its inventory and sees
whether the product is available. If the product is available then the finance department of the
company verifies customer credit status and supply the product to customer. If the product is
unavailable in their stock they place a purchase order to manufacturing units. For this purchase
order they open L/C in bank and send the L/C confirmation along with the purchase request to
manufacturing units. After getting the L/C confirmation and the purchase request from the
company (Honeycom) the manufacture units construct the machines and send it back to the
company. After getting the products the company supplies the products to customers. Then the
engineering team starts installing the machines and also provides various supports to customers.
After the installation phase the payment phase take place. The finance department of the
company receives payment from customer.


33
5.1.1.3 System Level DFD Sales Management System

Figure-5.3: System Level DFD (0 Level Diagram)

34
This is the second level of DFD. This level is also known as 0 level DFD. This level
consists of six entities, seven processes and six databases. These are:
External Entities
Customer
Company
Bank
Manufacturing Unit
Engineering Team
Finance
Process
Order verification process
Inventory checking process
Purchasing process
Receiving process
Shipment process
Installation process
Payment process
Databases
Order database
Inventory database
Purchase database
Shipment database
Support database
Accounts database

This process initiated when customer place an order to purchase machineries. This order is
verified and received by the company and stored in the order database. Then the company checks
its inventory and sees whether the product is available. If the product is available then the
finance department of the company verifies customer credit status and supply the product to
customer. If the product is unavailable in their stock they place a purchase order to
manufacturing units and store it in purchase database. For this purchase order they open L/C in
bank and send the L/C confirmation along with the purchase request to manufacturing units.
After getting the L/C confirmation and the purchase request from the company (Honeycom) the
manufacture units construct the machines and send it back to the company. After getting the
products the company updates their inventory position and store the information in inventory
database. Then they supply the products to customers. Then the engineering team starts
installing the machines and also provides various supports to customers. All the information
related to installation and supports are stored in support database. After the installation phase the
payment phase take place. The finance department of the company receives payment from
customer and store the information in their database.


35
5.1.1.4 Order verification process

Figure-5.4: Order verification process (Level 1 Diagram)

This is a third level of DFD. This level of DFD is also known as subsystem. This is the order
subsystem and consists of two external entities, four processes and five databases.
At first all the information about customer order has been collected including price of the
product. After completing order agreement customer places the order and the company receives
an order confirmation. After that the company checks their stock. If the product is available they
checks customer account and sees whether the account is valid or not and after checking it they
accept the order and store it in new order database. If the product is not available and if the
manufacturing units will not be able to produce it then the order is rejected and they (company)
send a rejection notification to customer. They also send a rejection notification if customer
account is invalid.

36
5.1.1.5 Inventory checking process

Figure-5.5: Inventory checking process (Level 1 Diagram)

This is also a third level of DFD. This is the Inventory subsystem and consists of one
external entity, three processes and four databases. Inventory subsystem initiated when the
company confirms that a new order has been placed by customer. Hare at first the company
checks what kind of machine customer place order for. Then they check their stock level for
those or that products. If the product is available they supply it to customer and if the product is
unavailable they generate a purchase request.

37
5.1.1.6 Purchasing Process

Figure-5.6: Purchasing Process (Level 1 Diagram)

This is a third level DFD of this system. This is the purchase subsystem and consists of three
external entities, two processes and two databases. In this process first the company select
appropriate manufacturing unit based on the purchase request because different manufacture units
produce different type of products. They acquire all this information from their manufacture unit
database. After selecting manufacture unit they prepare a purchase order and open a L/C in the
bank. Then the purchase order is sent to the appropriate manufacture unit along with L/C
confirmation.

38
5.1.1.7 Receiving Process

Figure-5.7: Receiving Process (Level 1 Diagram)

This is a third level DFD of this system. This is the receiving subsystem and consists of two
external entities, three processes and two databases. After getting the product from manufacture
unit the company (Honeycom) verifies that whether the manufacture unit sends the right product
and also checks the condition of the products. Then they officially receive the product and update
their inventory position and store the related information in inventory database.

39
5.1.1.8 Shipping Process

Figure 5.8: Shipping Process (Level 1 Diagram)

This is a third level DFD of this system. This is the shipping subsystem and consists of one
external entity, three processes and three databases. Before shipping the product the company
makes sure which shipping method will be appropriate for the selected product. After that they
prepare an invoice of the shipment. Then they dispatch the product to customer along with the
shipment invoice and store related information into shipment database.

40
5.1.1.9 Installation Process

Figure-5.9: Installation Process (Level 1 Diagram)

This is a third level DFD of this system. This is the Installation subsystem and consists of
two external entities, three processes and two databases. After shipping the products to customer
the engineering teams of dealer company start setting the machine as the customer required or
sometimes the company itself suggests the setting procedure. During this time the company may
have to provide some extra-services, like various equipments for setting the machine. Sometimes
the company provides these equipments for free and sometimes they charge customer for those.
After the setting period company offer customer technical supports that they provide for free
which includes train customer how to use the product, handle the use of machine for customer for
few months.

41
5.1.1.10 Payment Process

Figure-5.10: Payment Process (Level 1 Diagram)

This is a third level DFD of this system. This is the payment subsystem and consists of one
external entity, three processes and two databases. After installation and support when the
customer is satisfied the payments of the machine take place by agreement. Sometimes the
customer pay in full or sometimes they pay in installment. In case of full payment the company
provides the customer a payment receipt and store the information in accounts database. On the
other hand in case of installment the company verifies customer account. They prepare a billing
statement with terms and condition and send it to customer. Sometimes the company also sends
remainder to customer if they are failed to pay their installment in due time.

42
5.1.2 Logical Data Modeling: E-R Diagram
The entity-relationship model or entity-relationship diagram (ERD) is a data model or
diagram for high-level descriptions of conceptual data models, and it provides a graphical
notation for representing such data models in the form of entity-relationship diagrams. Such
models are typically used in the first stage of information-system design; they are used, for
example, to describe information needs and/or the type of information that is to be stored in the
database during the requirements analysis.
The Entity-Relationship (ER) model was originally proposed by Peter in 1976 [Chen76] as a
way to unify the network and relational database views. Simply stated the ER model is a
conceptual data model that views the real world as entities and relationships. A basic component
of the model is the Entity-Relationship diagram which is used to visually represent data objects.
Since Chen wrote his paper the model has been extended and today it is commonly used for
database design for the database designer.

5.1.2.1 Basic Constructs of E-R Modeling
The ER model views the real world as a construct of entities and association (relationship)
between entities.

Entities
Entities are the principal data object about which information is to be collected. Entities are
usually recognizable concepts, either concrete or abstract, such as person, places, things, or
events which have relevance to the database. Some examples of entities are CUSTOMER,
PRODUCT, COMPANY etc. An entity is analogous to a table in the relational model. An entity
occurrence (also called an instance) is an individual occurrence of an entity. An occurrence is
analogous to a row in the relational table. There are also some special entity types. Associative
entities (also known as intersection entities) are entities used to associate two or more entities in
order to reconcile a many-to-many relationship.

Relationships
A Relationship represents an association between two or more entities. It illustrates how two
entities share information in the database structure. Some examples of relationship are:

43
CUSTOMER place order for PRODUCT, COMPANY supply PRODUCT etc. Relationships are
classified in terms of degree, connectivity, cardinality, and existence. These concepts are
discussed below.

Classifying Relationships
Relationships are classified by their degree, connectivity, cardinality and existence. Not all
modeling methodologies use all these classifications.

Degree of a Relationship
The degree of a relationship is the number of entities associated with the relationship. The
unary relationship is the general form for degree n. A unary relationship occurs when an entity is
related to itself. An example might be "some employees are married to other employees". Special
cases are the binary, and ternary, where the degree is 2, and 3, respectively. Binary relationships,
the association between two entities are the most common type in the real world. A ternary
relationship involves three entities and is used when a binary relationship is inadequate. Many
modeling approaches recognize only binary relationships. Ternary or unary relationships are
decomposed into two or more binary relationships.

Connectivity and Cardinality
The connectivity of a relationship describes the mapping of associated entity instances in the
relationship. The values of connectivity are "one" or "many". The cardinality of a relationship is
the actual number of related occurrences for each of the two entities. The basic types of
connectivity for relations are: one-to-one, one-to-many, and many-to-many.
A one-to-one (1:1) relationship is when at most one instance of an entity A is associated with
one instance of entity B. For example, one LC is issue against one PRODUCT and one
PRODUCT has one LC.
A one-to-many (1: N) relationships is when for one instance of entity A, there are zero, one or
many instances of entity B, but for one instance of entity B, there is only one instance of entity A.
An example of a 1: N relationship is, one ENGINEERING TEAM gives support to many
CUSTOMERS but each CUSTOMER is receiving support from one ENGINEERING TEAM.
A many-to-many (M:N) relationship, sometimes called non-specific, is when for one instance
of entity A, there are zero, one, or many instances of entity B and for one instance of entity B

44
there are zero, one, or many instances of entity A. An example is, many PRODUCTS are
building by a single MANUFACTURE UNIT conversely many MANUFACTURE UNITS can
build same type of PRODUCTS. Many-to-many relationships cannot be directly translated to
relational tables but instead must be transformed into two or more one-to-many relationships
using associative entities.

Existence
Existence denotes whether the existence of an entity instance is dependent upon the existence
of another, related, entity instance. The existence of an entity in a relationship is defined as either
mandatory or optional. If an instance of an entity must always occur for an entity to be included
in a relationship, then it is mandatory. An example of mandatory existence is the statement
"every CUSTOMER must receive training from ENGINEERING TEAM". If the instance of the
entity is not required, it is optional. An example of optional existence is the statement, "every
ENGINEERING TEAM may not give training to all customers".

Attributes
Attributes are the properties or characteristics of an entity. Attributes describe the entity of
which they are associated. A particular instance of an attribute is a value. For example, "Said
Ibne Rahman" is one value of the attribute Name. The domain of an attribute is the collection of
all possible values an attribute can have. The domain of Name is a character string. Attributes
can be classified as identifiers or descriptors. Identifiers, more commonly called keys, uniquely
identify an instance of an entity. A descriptor describes a non-unique characteristic of an entity
instance.

5.1.2.2 ERD Notation
There is no standard for representing data objects in ER diagrams. Each modeling
methodology uses its own notation. The original notation used by Chen is widely used in
academics texts and journals but rarely seen in either CASE tools or publications by non-
academics. Today, there are a number of notations used; among the more common are Bachman,
crow's foot, and IDEFIX. All notational styles represent entities as rectangular boxes and
relationships as lines connecting boxes. Each style uses a special set of symbols to represent the
cardinality of a connection. The symbols used for the basic ER constructs are:

45
Entities are represented by labeled rectangles. The label is the name of the entity. Entity
names should be singular nouns.
Relationships are represented by a solid line connecting two entities. The name of the
relationship is written in a diamond shaped rectangle. Relationship names should be
verbs.
Attributes, when included, are listed inside a circle. Attributes which are identifiers
(primary key) are underlined. Attribute names should be singular nouns.
Cardinality of many is represented by a line ending in a crow's foot. If the crow's foot is
omitted, the cardinality is one.
Existence is represented by placing a circle or a perpendicular bar on the line. Mandatory
existence is shown by the bar (looks like a 1) next to the entity for an instance is required.
Optional existence is shown by placing a circle next to the entity that is optional.


46
Entity Relationship Diagram (ERD)

Figure-5.11: Entity Relationship Diagram of Sales Management System of Honeycom Service

47
Relational Tables

Figure-5.12: Relational Tables of Sales Management System of Honeycom Services (with Primary & Foreign Key)

48
5.3 Physical design
Physical design is the process of translating the logical abstract model into the specific
technical design for the new system. In this project Data Dictionary has been used for physical
data modeling.

5.3.1 Data Dictionary
The data dictionary is a specialized application of the kinds of dictionaries used as references
in everyday life. The data dictionary is a reference work of data about data (that is, metadata),
one that is compiled by systems analysts to guide them through analysis and design. As a
document, the data dictionary collects and coordinates specific data terms, and it confirms what
each term means to different people in the organization.
Systems analysts must be aware of and catalog different terms that refer to the same data
item. This awareness helps them avoid duplication of effort, allows better communication
between organizational departments sharing a database, and makes maintenance more
straightforward. The data dictionary can also serve as a consistent standard for data elements.
Understanding the process of compiling a data dictionary can aid the systems analyst in
conceptualizing the system and how it works. In addition to providing documentation and
eliminating redundancy, the data dictionary may be used to:
1. Validate the data flow diagram for completeness and accuracy.
2. Provide a starting point for developing screens and reports.
3. Determine the contents of data stored in files.
4. Develop the logic for data flow diagram processes.

This Data Dictionary describes each attribute of a table with their Field Name, Data Type,
Size and description of the data that are being stored. In this proposed system eleven entity tables
have been used.


49
Entity Name: MANUFACTURE UNIT
Table Name: tblmanufactureunit
This table is containing information about manufacture unit.

Name Data
Type
Size Key/Null/
Not Null
Remark
cmanufactureunitid varchar 12 PK/Not
Null
Primary key of this relation ID of the
manufacture unit. Example: SI036458
cbranchname varchar 10 Not Null The branch name of the manufacture unit.
Example: Singapore Branch.
cstreet varchar 10 Null The street name or number, where the
manufacture unit is located. Example: Orchard
Road
ccity varchar 10 Null The city name, where the manufacture unit is
located. Example: Singapore city
czipcode varchar 10 Null The zip code of the country or city where the
manufacture unit is located. Example: 0864
ccountry varchar 12 Null The country name, where the manufacture unit
is located. Example: Singapore

Entity Name: BANK
Table Name: tblbank
This table is containing information about bank.

Name Data
Type
Size Key/Null/
Not Null
Remark
cbankid varchar 10 PK/Not
Null
Primary key of this relation. ID of the bank.
Example: HS107
cbankname varchar 10 Not Null This attribute is the bank name. Example: HSBC
Bank
cbranchname varchar 10 Not Null The branch name of the bank. Example:
Dhanmondi Branch
cstreet varchar 10 Null The street name or number, where the bank is
located. Example: Street No. 7
ccity varchar 10 Null The city name, where the bank is located.
Example: Dhaka
czipcode varchar 10 Null The zip code of the country or city where the
bank is located. Example: 1208


50
Entity Name: L/C
Table Name: tbllc
This table is containing information about L/C.

Name Data
Type
Size Key/Null/
Not Null
Remark
clcnumber varchar 10 PK/Not
Null
Primary key of this relation. The L/C
number. Example: LCXR9086
dissuedate datetime dd/mm/yy Not Null The date of issuing the L/C. Example:
03/11/2004
mlcamount money Null Total amount for how much the L/C is
issued. Example:'12,00000
cmanufactureunitid varchar 12 FK/Not
Null
Foreign key come from manufacture unit.
ID of the manufacture unit. Example:
SI036458
cbankname varchar 10 FK/Not
Null
Foreign key come from bank. Name of
the bank. Example: HSBC Bank

Entity Name: CUSTOMER
Table Name: tblcustomer
This table is containing information about customer.

Name Data
Type
Size Key/Null/
Not Null
Remark
ccustomerid varchar 10 PK/Not
Null
Primary key of this relation. ID of the customer.
Example: AMH02345
cfirstname varchar 10 Null First name of the customer. Example: Ahmed
cmiddlename varchar 10 Null Middle name of the customer. Example: Mustafa
clastname varchar 10 Null Last name of the customer. Example: Hossain
ccustomerpriority varchar 10 Null Customer priority number. Who has the first
priority gets the most service.
Example: AMH02
ccity varchar 10 Null The city name, where the customer is located.
Example: Dhaka
cstreet varchar 10 Null The street name or number, where the customer is
located. Example: Ullon Road
czipcode varchar 10 Null The zip code of the country or city of the customer.
Example: 1218


51
Entity Name: ORDER
Table Name: tblorder
This table is containing information about how an order is placed.

Name Data
Type
Size Key/Null/
Not Null
Remark
cordernumber varchar 10 PK/Not
Null
Primary key of this relation. This contains
the order number. Example: CTS28031
dcustomerorderdate datetime dd/mm/yy Not Null The date when the customer place an
order. Example: 04/10/2004
dcompanyorderdate datetime dd/mm/yy Not Null The date when the company place an
order to the manufacturing unit. Example:
15/10/2004
cbackorder varchar 10 Null The order numbers which, order the
customer has cancel. Example:
CTS28031
ccustomerid varchar 10 FK/Not
Null
Foreign key come from customer. ID of
the customer. Example: AMH02345
cmanufactureunitid varchar 12 FK/Not
Null
Foreign key come from manufacture unit.
ID of the manufacture unit. Example:
SI036458

Entity Name: MACHINERY
Table Name: tblmachinery
This table is containing information about certain machinery.

Name Data
Type
Size Key/Null/
Not Null
Remark
cmachineid varchar 10 PK/Not
Null
Primary key of this relation. This contains
the machine id. Example: CTS28031
cmachinename varchar 15 Not Null The name of the machine. Example: MRI
cmachinerange varchar 10 Null Whether the machine is of high range or
low range.
mmachineprice money Null Customer price of a certain machine.
Example: 5000000 Tk
mmachinecost money Null Machine price for the dealer company.
Example: 4500000 Tk
ddeliverydate datetime dd/mm/yy Null The date of delivering the machine to
customer. Example: 05/12/2004
cordernumber varchar 10 FK/Not
Null
Foreign key coming from the table order.
The order number. Example: CTS28031

52
Entity Name: BUILT
Table Name: tblbuilt
This table is containing information about which manufacture unit is building which machine and
the building period.

Name Data
Type
Size Key/Null/
Not Null
Remark
cmanufactureunitid varchar 12 PK/Not
Null
First part of the composite primary key of this
relation table. This contains the ID of the
manufacture unit. Example: SI036458
cmachineid varchar 10 PK/Not
Null
Second part of the composite primary key of
this relation table. Containing machine id.
Example: CTS28031
dbuildingperiod varchar 10 Null Time period of building a machine by the
manufacturer. Example: 6 months

Entity Name: ENGINEERING TEAM
Table Name: tblengineeringteam
This table is containing information about engineering team and the members of the team.

Name Data
Type
Size Key/Null/
Not Null
Remark
cengineeringteamid varchar 10 PK/Not
Null
Primary key of this relation table. This attribute
is containing the id of the engineering team.
Example: ET02
cmemberid varchar 10 Not Null Members id of the engineering team.
Example: ET0204
cfirstname varchar 10 Null First name of a member. Example: Ahmed
cmiddlename varchar 10 Null Middle name of a member. Example: Niaz
clastname varchar 10 Null Last name of a member. Example: Morshed
cstreet varchar 10 Null Consisting of street name or number, where a
member is located. Example: Ullon Road
ccity varchar 10 Null The city name, where a member is located.
Example: Dhaka
czipcode varchar 10 Null This attribute is the zip code of the place where
a member is located. Example: 1217


53
Entity Name: SUPPORT
Table Name: tblsupport
This table is containing information about which engineering team is giving support to which
customer and also the type of the support.

Name Data
Type
Size Key/Null/
Not Null
Remark
csupportid varchar 10 PK/Not
Null
This is the primary key of this relation. This
contains the support id. Example: ST092
Null
Foreign key from the table customer. ID of
cengineeringteamid varchar 10 FK/Not
Null
This is foreign key from the table
engineering team. ID of the engineering
team. Example: ET02
dtrainingperiod varchar 10 Null This attribute is the time period of training
the customer. Example: 4 months
dhandleuseofmachine varchar 10 Null This attribute is the time period of handling
use of a machine for the customer by the
company. Example: 2 months

Entity Name: SHIPMENT
Table Name: tblshipment
This table is containing information about shipping machinery to customer

Field Name Data
Type
Size Key/Null/
Not Null
Remark
cshippingid varchar 8 PK/Not
Null
Primary key of this relation. Contains the
shipping ID. Example: MRI0081
cinvoiceno varchar 8 Null Invoice of the machine. Example: INV0081
dshippingdate datetime dd/mm/yy Not Null Date of shipping the machine to customer.
Example: 04/05/2004
mshippingcost money Null How much it is cost when the product was
shipped to customer. Example: 1000 TK
Null
Foreign key from the table customer. ID of
cmachineid varchar 10 FK/Not
Null
Foreign key from the table machine. ID of the
machines. Example: CTS101245


54
Entity Name: PAYMENT
Table Name: tblpayment
This table is containing information about customer payment after a successful installation of
machine.

Field Name Data
Type
Size Key/Null/
Not Null
Remark
cpaymentid varchar 10 PK/Not
Null
Primary key of this relation. It is the
payment number. Example: MRI0098
dpaymentdate datetime dd/mm/yy Not Null The date when the customers pay for the
machine purchased. Example:
04/10/2004
cpaymenttype varchar 10 Null This attribute store the payment type,
either it is full or installment. Example:
Full
mpaymentamount money Not Null This attribute store the payment amount
paid by the customer. Example: 12,00000
Tk
Null
Foreign key from the table customer. ID
of the customer. Example: AMH02345
cbankname varchar 10 FK/Not
Null
Foreign key from the table bank. This is
the bank name. Example: HSBC Bank


Chapter 6: Object Oriented Approach
55
6.1 Object Oriented Approach
There have been basically 3 approaches in information system development area: process-
oriented, data-oriented and object-oriented approaches. As information technology (both
hardware and software) has been advancing, people have moved from the earliest process-
oriented approach to data-oriented approach and now begun to adopt the latest object-oriented
analysis methodology.
Unlike its two predecessors that focus either on process or data, the object-oriented approach
combines data and processes (called methods) into single entities called objects. Objects usually
correspond to the real things an information system deals with, such as customers, suppliers,
contracts, and purchase agreements. Object-oriented model is able to thoroughly represent
complex relationships and to represent data and data processing with a consistent notation, which
allows an easier blending of analysis and design in an evolutionary process. The goal of object-
oriented approach is to make system elements more reusable, thus improving system quality and
the productivity of systems analysis and design (Hoffer et al. 2002).

6.2 Mechanism of Object-oriented Approach
The principals of objects, encapsulation, inheritance, and polymorphism are the foundation
for object-oriented systems development. To understand and express the essential and interesting
features of an application in the complex real world, an object-oriented model is built around
objects. An object encapsulates both data and behavior, implying that analysts can use the object-
oriented approach for both data modeling and process modeling.
Specific objects in a system can inherit characteristics from the global instance of an object.
For example, many types of objects may have a name and a creation date. Specific objects can
inherit these global characteristics from parent objects that include only global characteristics.
Objects can inherit characteristics from more than one parent object. Inheritance attempts to
avoid the redundant definition of similar characteristics that can be embodied at higher levels in
the system (Cackowski 2000).

56
By a concept called polymorphism, functionality that is conceptually similar among differing
objects is extracted to a global level. This process limits the production of parallel functionality
and streamlines the information interface.

6.3 Unified Modeling Language
The Unified Modeling Language (UML) is an object-oriented language for specifying,
visualizing, constructing, and documenting the artifacts of software systems, as well as for
business modeling (UML Document Set, 2001). The UML was developed by Rational Software
and its partners. It is the successor to the modeling languages found in the Booch (Booch 1994),
OOSE/Jacobson, OMT and other methods.
By offering a common blueprinting language, UML relieves developers of the proprietary ties
that are so common in this industry. Major vendors including IBM, Microsoft, and Oracle are
brought together under the UML umbrella. And because UML uses simple, intuitive notation,
nonprogrammers can also understand UML models. In fact, many of the language's supporters
claim that UML's simplicity is its chief benefit. If developers, customers, and implementers can
all understand a UML diagram, they are more likely to agree on the intended functionality,
thereby improving their chances of creating an application that truly solves a business problem
(Apicella 2000).
The UML, a visual modeling language, is not intended to be a visual programming language.
The UML notation is useful for graphically depicting object-oriented analysis and design models.
It not only allows us to specify the requirements of a system and capture the design decisions, but
it also promotes communication among key persons involved in the development effort (Hoffer et
al. 2002). The emphasis in modeling should be on analysis and design, focusing on front-end
conceptual issues, rather than back-end implementation issues, which unnecessarily restrict
design choices (Rumbaugh et al. 1991).
UML includes many modeling language. Among them two popular and commonly used
diagrams are shown in this project. These are
Use Case Diagram
Activity Diagram


57
6.3.1 Use Case Diagram
A use case is a collection of possible sequences of interactions between the system under
discussion and its Users (or Actors), relating to a particular goal. The collection of Use Cases
should define all system behavior relevant to the actors to assure them that their goals will be
carried out properly. Any system behavior that is irrelevant to the actors should not be included
in the use cases. Use cases are used in almost every project. They are helpful in exposing
requirements and planning the project. During the initial stage of a project most use cases should
be defined, but as the project continues more might become visible.

6.3.1.1 Use Case Notation
The basic component of Use Case diagrams are the Actor, The Use Case and The
Association.

Figure-6.1: Use Case graphical notations

Actor: An Actor models a type of role played by an entity that interacts with the subject (e.g., by
exchanging signals and data), but which is external to the subject (i.e., in the sense that an
instance of an actor is not a part of the instance of its corresponding subject). Actors may
represent roles played by human users, external hardware, or other subjects. (OMG Unified
Modeling Language Specification - UML 2.0 Superstructure Specification, p. 643)

Use Case: Use Cases are what happens when actors interact with the system. An actor uses the
system to achieve a desired goal. By recording all the ways our system is used ("cases of use" or
Use Cases) we accumulate all the goals or requirements of our system.

Association: Associations are used to link Actor with Use Cases, and indicate that an actor
participates in the Use Case in some form.

58
Use Cases of Sales Management System of Honeycom Services

Figure-6.2: Use Case Analysis

59
6.3.1.2 Use Case Narration
In this project fourteen Use Cases have been identified. Narration of these Use Cases has
given in the following.

USECASE NAME Choosing Machinery from Catalogue
ACTOR(S) Customer
DESCRIPTION This is the process that describes customers activity of selecting
which machinery to purchase from Honeycom services. After
choosing the machinery, customers inform the company about their
selection.
TYPICAL COURSE
OF EVENTS
Actor Actions

Step1: Customer selects
machineries from the catalogues.
Step4: This use case is
concluded when customer
confirms the company about
selected machineries.
System Response

Step2: Preliminary information
about client such as clients name,
address etc are recorded.
Step3: A Product detail according
to the customers choice is
recorded.
ALTERNATIVE
COURSES
None
PRECONDITION Machineries must be selected only from those which are available in
catalogues.
POSTCONDITION Client has to confirm the company about their selected machineries.


60
USECASE NAME Agreement for Purchasing
ACTOR(S) Customer, Company
DESCRIPTION This use case describes the process that the company and customer
follow to come to an agreement for the business transaction.
TYPICAL COURSE
OF EVENTS
Actor Actions

Step1: This use case is initiated
when customer confirms the
company about selected
machineries.
Step4: Company authorizes the
agreement.
Step5: This use case concluded
when the agreement is signed by
both of the company and the
customer.
System Response

Step2: Detailed information about
the client such as client name,
address, phone numbers are stored
for future purpose.
Step3: Detailed information about
selected equipment such as product
id, model, make of the product, per
unit price etc are recorded.
ALTERNATIVE
COURSES
None
PRECONDITION Customer have to choose product from Honeycom Services Ltd.
POSTCONDITION Agreement must be signed by both of the parties.

USECASE NAME Placing Order
ACTOR(S) Customer
DESCRIPTION This use case describes the order procedure of the customer.
TYPICAL COURSE
OF EVENTS
Actor Actions

Step1: Customer confirms
the company about the
transaction and place order
for purchasing the
equipment.
Step5: Customer reviews the
order to verify and confirm
the company about their
order.
concluded when the order is
placed into the system.
System Response

Step2: Each customer is provided a
unique ID and individual order
information are recorded for different
orders.
Step3: An unique ID is assigned for
each order and all order information
such as order date, order type etc are
recorded.
Step4: Data on manufacturing unit is
recorded to keep information about the
manufacturing company of the
equipment.
ALTERNATIVE
COURSES
None
PRECONDITION Client must choose product to place an order.
POSTCONDITION Order must be validated by client.

61

USECASE NAME Checking Stock
ACTOR(S) Company
DESCRIPTION This use case describes the process of checking if selected equipment is
available in the inventory or not.
TYPICAL COURSE
OF EVENTS
Actor Actions

initiated when the company
stored order information in the
system.
Step6: This use case
concluded when the low
ranged product is checked if it
is available in the stock or not.
System Response

Step2: Determine if the selected
equipment is of low range.
Step3: If the equipment is of low
range, the system checks if it is
available in the inventory.
Step4: If the equipment is not
available in the inventory, the system
will place new order to the
manufacturing unit.
ALTERNATIVE
COURSES
None
PRECONDITION Customer orders have to be confirmed before checking stock.
POSTCONDITION Product may be available in the stock or not.

USECASE NAME Purchase Preparation
ACTOR(S) Company
DESCRIPTION This use case describe the process of placing order by Ardent Pvt. Ltd to
manufacture units for acquiring machine, through opening LC to a bank.
TYPICAL COURSE
OF EVENTS
Actor Actions

place order to manufacturing
unit
concluded when the
manufacturing unit receives
the order.
System Response

Step2: Machine description such as
machine range, name has been stored
in the system.
Step3: For each machine being
ordered the machine id has been
validate.
Step4: L/C is opened in the bank.
Step5: Manufacturing unit name and
location is also stored.
ALTERNATIVE
COURSES
Step2: If the machine id is not valid, request for a valid machine id.
PRECONDITION Order to manufacturing unit can only be placed by the dealer company.
POSTCONDITION Order information must have to enlist in the system


62
USECASE NAME Opening LC
ACTOR(S) Bank
DESCRIPTION This use case describes the LC open process for placing order by the
company to manufacturing unit.
TYPICAL COURSE
OF EVENTS
Actor Actions

when the company opens LC
through a bank for placing order
to manufacturing unit.
when the LC has been confirmed
by the manufacturing unit.
System Response

Step2: Check company account
information.
Step3: Store bank information such
as bank id and address.
Step4: Validate the LC id with
respect to manufacturing unit id.
Step5: Store LC amount, issue date
and LC number.
ALTERNATIVE
COURSES
Step2: If no valid company account is found, then the company has to
open a valid account in the bank.
PRECONDITION Only the company can open LC for receiving machine from
manufacturing unit.
POSTCONDITION After the LC is opened in the bank the information has been stored in
the system.

USECASE NAME LC confirmation
ACTOR(S) Bank, Manufacture Unit
DESCRIPTION This use case describes the LC confirmation process by the bank and the
manufacturing unit.
TYPICAL COURSE
OF EVENTS
Actor Actions

Step1: This use case initiate
when bank send LC confirmation
to manufacturing unit.
when manufacturing unit
receives LC confirmation.
System Response

Step2: Validate the LC id against
manufacturing unit id.
Step3: Store LC information.
Step4: Check machine id for which
LC has been opened,
Step5: Obtain confirmation receipt.
ALTERNATIVE
COURSES
Step2: If the LC confirmation is not received by the manufacturing unit,
send a request to bank to send it to them.
PRECONDITION The LC can only be confirmed by any external financial organization
such as bank.
POSTCONDITION Receiving of LC confirmation by the manufacturing unit has been
recorded.


63
USECASE NAME Shipping machine to company
ACTOR(S) Manufacture Unit, Company
DESCRIPTION This use case describe the process of shipment of machine from
manufacturing unit to the company
TYPICAL COURSE
OF EVENTS
Actor Actions

when manufacturing unit send
machines to the company.
when the company receives
machine.
System Response

Step2: Check the machine id and
validate it against shipping id.
Step3: Store the shipping info such
as shipment date, time and receiving
date.
ALTERNATIVE
COURSES
Step2: If there is a delay in shipment, send a request to the
manufacturing unit to send machine again.
PRECONDITION Only the company can receive machine from manufacturing unit.
POSTCONDITION After receiving machines the information has been stored in the system
and a receipt is send to manufacturing unit.

USECASE NAME Shipping machineries to customer
ACTOR(S) Company, Customer
DESCRIPTION This use case describe the process that company supply the machinery to
customer

TYPICAL OURSE
OF EVENTS
Actor Actions

Step1: This use case initiated
that company supply the
machinery to customer.
concludes when company is
ready to supply machinery.

System Response

Step2: Company confirms the machine id
where the machine has already received or
not.
Step3: Company validate whether the
machine is ordered.
Step4: Company checks the payment
information of customer.
Step5: Company also verifies the delivery
date.

ALTERNATIVE
COURSES

Step2: If company cannot delivery the machine on due date customer
should extend delivery date.
Step3: If company did not delivery on extended date then the customer
can cancel the order.

PRECONDITION
Only when company gets the machinery from manufacture unit only then
company can supply machinery to customer.

POSTCONDITION
Company delivers machinery to customer on due date and company store
all information about machinery and customer in data warehouse.


64
USE CASE NAME Machinery setup
ACTOR(S) Engineering team
DESCRIPTION

The use case describes the process that the company provides the
engineering team and they are responsible for the machinery setup. The
company gives feedback to the engineering team.

TYPICAL COURSE
OF EVENTS
Actor Action

Step 1: This use case is
initiated when the engineering
teams setup the machine.
Step5: This use case concludes
when the machine setup is
complete.

System Response

Step2: Engineering team information
is validated against what is currently
on file.
Step3:Validate the Machine number
Step3:Engineering team generate the
information about the setup process
and return it to the company
Step4:Company check the status
ALTERNATE
COURSES

Step2: If the engineering team is not available or applicable to setup the
machine the company reschedules the plan.
Step3: If the machine id is not valid they send a notification to the
customer.
PRECONDITION Machinery setup only done by engineering team.
POSTCONDITION After complete the setup engineering team inform it to company and all
data about the setup store in the database.

USE CASE NAME

Warranty provided for machine
ACTOR(S) Company
DESCRIPTION The use case describes the process that the company provides
maintenance and hardware support. All are basis with some
conditions.

TYPICAL COURSE
OF EVENTS
Actor Action

when the company provides
warranty for machine.
when the company receives the
setup confirmation notice.
System Response

Step2: Store information.
Step3: Store Customer name and
address.
Step4: Specify Warranty period
and type
ALTERNATE
COURSES

Step2: If the confirmation is not given then the warranty will not
provided.
Step3: If customers dont follow the terms and conditions, in this case
warranty will be avoided.
PRECONDITION

Machine should be full set up successfully and the customer will give
confirmation about this.
POSTCONDITION The warranty should be providing with some terms and conditions.

65

USECASE NAME Payment for machine.
ACTOR(S) Customer, Company
DESCRIPTION This use case describes the process of payment for machine and
company receives the payment.

TYPICAL COURSE
OF EVENTS
Actor Actions

Step1: This use case initiated
when customer pays the payment
for machine and company receive
the payment.
when customer receives machine
and payment information is stored.
System Response

Step2: Company check about
customer information.
Step3: Company ensure machine
id and delivery date.
Step4: After delivery machine to
customer company store payment
information.
ALTERNATIVE
COURSES
Step2: If customer does not make payment the order will be cancel.
PRECONDITION Payment can only be made by customer.
POSTCONDITION Customer order has been recorded and payment information has been
routed to the warehouse.

USE CASE NAME After sales support
ACTOR(S) Engineering team, Customer
DESCRIPTION

The use case describes the process that the company will be
responsible for after sales support through some conditions.

TYPICAL COURSE OF
EVENTS
Actor Actions

provides after sales support
when the customer are friendly
with the machine to operate it
properly.

System Response

Step2: Time period of training
the customer.
Step3: Time period of handling
use of a machine for the
customer by the company.
ALTERNATE
COURSES
Step2: If the time period is not enough for the customer the
company extend the time period.
PRECONDITION Trainer should be more applicable.
POSTCONDITION Customer gathers all the information about the machine.


66
6.3.2 Activity Diagram
The easiest way to visualize an Activity diagram is to think of a flowchart of a code. The
flowchart is used to depict the business logic flow and the events that cause decisions and actions
in the code to take place. Activity diagrams represent the business and operational workflows of
a system. An Activity diagram is a dynamic diagram that shows the activity and the event that
causes the object to be in the particular state.
The Activity Diagram can help to describe the flow of control of the target system, such as
the exploring complex business rules and operations, describing the use case also the business
process.

6.3.2.1 Elements of an Activity diagram
An Activity diagram consists of the following behavioral elements:

Initial Activity: This shows the starting point or first activity of the
flow. Denoted by a solid circle. This is similar to the notation used
for Initial State.

Activity: Represented by a rectangle with rounded (almost oval)
edges.
Decisions: Similar to flowcharts, a logic where a decision is to be
made is depicted by a diamond, with the options written on either side
of the arrows emerging from the diamond, within box brackets.

Concurrent Activities: Some activities occur simultaneously or in
parallel. Such activities are called concurrent activities. For
example, listening to the lecturer and looking at the blackboard is a
parallel activity. This is represented by a horizontal split (thick dark
line) and the two concurrent activities next to each other, and the
horizontal line again to show the end of the parallel activity.

Final Activity: The end of the Activity diagram is shown by a bull's
eye symbol, also called as a final activity.


67
6.3.2.2 Activity Diagrams of Sales Management System of Honeycom Services
Three activity diagrams have been shown in this project to identify various events that took
place during the sales process of Honeycom Services. The activity diagrams and their
descriptions are given below:

Figure-6.3: Activity Diagram of Selling Product

68
The above activity diagram shows us the activities that have been perform while the company
is selling machine to customer. This diagram initiate when customer chooses any product for
purchase. If customer doesnt find what they want then the activity is ended and if the customer
choose any suitable product for purchase then the next activity occurs, which is agreement for
purchasing. If the company and the customer are unable to come to an agreement then again the
activities are ended while if the agreement are initiate between the two parties then the next
activity begins. The next activity occurs when customer place an order to purchase. After
confirming the order the company checks their stock. Two activities occur in this time, one is if
the product is available in the stock the company immediately supply it to customer and the
activities end there. But if the product is not available in the stock then the company prepares a
purchase request and sends it to manufacture units. After getting the purchase request
manufacture units built the products and send it to the company. Then the company supplies it to
customer and all the activities are ended here.


69

Figure-6.4: Activity Diagram of Product Installation & Support

After supplying the product to customer the activities of installation and support initiated.
But if there is problem with shipment then the activities stopped. After shipping phase the
engineering teams of Dealer Company start setting the machine. During this time the company
may have to provide some extra-services. After the setting period company offer customer
technical or service supports that they provide for free which includes train customer how to use
the product, handle the use of machine for customer for few months. After installation and
support when the customer is satisfied the payments of the machine take place. After finishing all
kind of transactions and product setup procedures the company offer customer service support by
their engineering teams and the activities of this phase ended.

Chapter 7: User Interface
70
7.0 User Interface
An interface is the tangent plane between the user and the computer (the user interface) or
the link between components (both software and hardware) in computer systems. Data are
exchanged in two directions via the interface. A proper standardization of the user interface leads
to the simplification of human/computer interaction and contributes a great deal to the
transparency for the user.
Physical design follows logical design. The logical design is implemented to the physical
design. Physical design provide user interface for the end user. User interface can be classified
into user menu, user forms, and user reports and under these three categories there may have data
entry form, multiple windows, reports etc to facilitate the end user. The user interface of Sales
Management System of Honeycom Services is divided into 10 modules. These are:
1. Customer Information module
2. Manufacture Unit Information module
3. LC Details information module
4. Bank Information module
5. Machine information module
6. Engineering Team information module
7. Payment information module
8. Order details information module
9. Shipping information module
10. Support information module

The user interface of Sales Management System of Honeycom Services produces 6 types of
output reports. These reports are:
1. Customer Order output report
2. Payment output report
3. Purchase output report
4. Shipping output report
5. LC details output report
6. Support details output report

71
7.1 Input Modules
Module Name: Customer Information module
Purpose: This form is used for storing customer information. Like Customer id, name, address
etc.

Figure-7.1: Customer Information module

Module Name: Manufacture Unit Information module
Purpose: This form is used for store various information of the manufacturing units.

Figure-7.2: Manufacture Unit Information module

72
Module Name: LC Details information module
Purpose: This form is used for storing various LC transactions. Like LC number, bank name etc.

Figure-7.3: LC Details information module

Module Name: Bank Information module
Purpose: This form is used for storing Bank information. Like bank name, address, phone etc.

Figure-7.4: Bank Information module

73
Module Name: Machine information module
Purpose: This form is used for storing machinery information. Like; machine id, name, price etc.

Figure-7.5: Machine information module

Module Name: Engineering Team information module
Purpose: This form is used for store various information about the engineering team.

Figure-7.6: Engineering Team information module

74
Module Name: Payment information module
Purpose: This form is used for store various information of the customer payment.

Figure-7.7: Payment information module

Module Name: Order details information module
Purpose: This form is used for storing order information. Like order number, time etc.

Figure-7.8: Order details information module

75
Module Name: Shipping information module
Purpose: This form is used for store various information about shipment of products.

Figure-7.9: Shipping information module

Module Name: Support information module
Purpose: This form is used for store various support information given by the engineering teams.

Figure-7.10: Support information module

76
7.2 Output Reports
Report Name: Customer Order
Purpose: This report shows detailed information about customers order.

Figure-7.11: Customer Order Report

77
Report Name: Purchase Report
Purpose: This report shows information about machine purchasing.

Figure-7.12: Purchase report

Report Name: Payment Report
Purpose: This report shows detail information of customer payment.

Figure-7.13: Payment Report

Chapter 8: Future Development & Conclusion
78
8.1 Future Development
This project was aimed to provide a complete database solution to the Sales management
system of Honeycom Services Limited but due to time and other limitations the project has not
been developed as it was intended earlier. Future studies should identify and analyze other
factors of database development including the following issues. Because of the lack of time it
was not possible to test the system. As a result it was not possible to know if it will return the
data that it is suppose to. But in the future the software will be tasted and hopefully it will run
error freely. Since most design decisions were driven by a single developer (including database
design), many design choices were not the best choices available. This is due to the fact that the
developer may not have expert database design skills. So, in future running much error checking
process the system may work smoothly as it is required. Communication between the developer
and the client is not properly clear sometimes. So, from time to time it has become very hard to
develop the system as the client desire. But in future it will become more clearer and
understandable if much interview and fact finding techniques are performed with the customer.

8.2 Conclusion
The target of database based software is not just to enter the records, but also to analyze and
represent them to the management for making decisions and corrective plans. At the end of the
day, week or month the reports are produced to serve the management needs and provide them
with accurate picture of the transaction records in summarized form.
Analysis and Design of an Automated Information System to Manage the Sales Process of
Honeycom Services Limited is the project I was assigned to. I had to struggle and managed to
solve all the problems that I faced in my project work. I have to go through various online
documents and several books to solve the problems which arise in my work. The software has
been developed as user required it. I have developed this software using Visual Basic 6.0 in the
front-end of it and MS SQL Server2000 in the back-end.
The implementation of a new system is subject to organizational change. Whether the
organization accepts this change mostly depends on the successful implementation of the
developed system. This system is user-friendly than the previous manual system. I have tried my

Chapter 8: Future Development & Conclusion
79
best to make this project a complete & successful one, but due to time and other limitations I
could not make the system more resourceful. Since this project has introduced me with the arena
of real world for the first time, there may be some errors in developing the system.
As a graduate of management information system I am supposed to solve any kind of
problems in a real world system that will reflect my ability and knowledge in this field if I can do
it successfully. I am highly obliged that I had the opportunity to deal with such a project, which
has helped me to lift my confidence to a higher level, and also has given me the strength to face
the challenge that is ahead of me. Besides, these will help me a lot in future not only while
working in industries but also in higher studies.

Analysis and Design of an Automated Information System to Manage Sales Process of Honeycom
References
80
References

Activity Diagram in UML, Retrieve from http://www.developer.com/design/article.php/2247041

Activity Diagram, Visual Paradigm Gallery, Retrieve from
http://www.visual-paradigm.com/VPGallery/diagrams/Activity.html

A.J.Pae Galgotia Publication Pvt. Ltd, Relational Databases Concepts, Selection &
Implementation, First Edition (1993).

C.J. Date, An Introduction to Database Systems

Data Flow Diagram, The IT Analyst's Desktop, Retrieve from
http://www.infoarchgroup.com/qrdfd.htm

DR. Indrani Haque, MIS & System Analysis.

Fred R. Mcfadden, Jeffrey A. Hoffer, Mary B. Prescott. Modern Database Management.

How to draw data flow diagram, SmartDraw Software Design Center, Retrieve from
http://www.smartdraw.com/tutorials/software-dfd/dfd2.htm

Introduction to Data Modeling, The University of Texas at Austin, Retrieve from
http://www.utexas.edu/its/windows/database/datamodeling/dm/erintro.html

Ivan Bayross, SQL, PL/ SQL, The Programmer Language of Oracle, Second Edition (2001), BPB
Publication Pvt. Ltd

Jian Wang, Object-Oriented Analysis Methodology, School of Business Administration -
University of Missouri-St. Louis. Retrieve from
http://www.umsl.edu/~sauter/analysis/488_f01_papers/wang.htm

Kenneth A. Kozar (Spring 1997), Representing Systems with Data Flow Diagrams Retrieve
from http://spot.colorado.edu/~kozar/DFD.html

Kenneth A. Kozar (Spring 1997), The Technique of Data Flow Diagrams Retrieve from
http://spot.colorado.edu/~kozar/DFDtechnique.html

Analysis and Design of an Automated Information System to Manage Sales Process of Honeycom
References
81
Linda V. Knight, Theresa A. Steinbach, Vince Kellen, System Development Methodologies for
Web Enabled E-Business: A Customization Paradigm Retrieve from
http://www.kellen.net/SysDev.htm

Michael V. Mannino, Database: Design, Application Development and Administration.

Noel Jerke, The Complete Reference Visual Basic 6, Seventh Edition (1999, Tata McGraw-Hill
Publishing Company Limited.

Pere Botella, Xavier Franch et. el. Modeling Non-Functional Requirements University
Politecnica de Catalunya (UPC).

Ramez Elmasri, Shamkant B. Navathe, Fundamentals of Database System.

SQL Server 2000 Documentation.

System Development Life Cycle Methodology, Texas State University-San Macros, Retrieve
from http://www.txstate.edu/effective/upps/upps-04-02-03.html

UML Tutorial, Sparx System Retrieve from, http://www.sparxsystems.com.au/UML_Tutorial.htm

Understanding Entity Relationship Diagrams, Retrieve from
http://folkworm.ceri.memphis.edu/ew/SCHEMA_DOC/comparison/erd.htm

Use Case Fundamentals, Retrieve from http://members.aol.com/acockburn/papers/AltIntro.htm

Use Case Modeling: capturing user requirement, Retrieve from
http://www.zoo.co.uk/~z0001039/PracGuides/pg_use_cases.htm

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htm

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/history_of_uml.htm

http://seattlecentral.org/faculty/sconge/ITC255/Lectures/Chapter1Terms.html

http://www.mariosalexandrou.com/methodologies/waterfall.asp


Appendix
82
Appendix

Department Name: Respondent:

GENERAL QUESTIONS ON COMPUTERIZATION:

1. Are there any computers in the Organization?
Yes
No

2. How many and where?
________________________________________________________________________

3. Who maintains them?
________________________________________________________________________

4. These computers are using for what purpose?
________________________________________________________________________
________________________________________________________________________

5. Is there any existing computerized system in your Company?
Yes
No

If yes

a) Which systems are computerized?
i ) Order Mgt System
ii) Production Mgt System
iii) Commercial Mgt System
iv) Inventory Mgt System
v) L/C Mgt System
vi) HRM
vii) Fixed Asset Mgt System
viii) Other (Specify)_________________

b) How the system has been developed?
i) By hiring a Programmer
ii) By hiring a Software Firm
iii) By buying Local Software
iv) By buying foreign Software
v) Other (Specify).


Appendix
83
c) Why? (For the ans. of b.)
________________________________________________________________________

d) When the system has been developed?
________________________________________________________________________
e) How long it took to develop?
________________________________________________________________________

f) Is the system satisfactory?
a. Yes
b. No (if not what are the problems?)

If No

a) Why
i) Cost
ii)L.O.K
iii) Other(specify)__________

b) Are you thinking of future computerization?
a. Yes
b. No

If yes which parts

i) Order Mgt System
ii) Production Mgt System
iii) Commercial Mgt System
iv) Inventory Mgt System
ix) L/C Mgt System
x) HRM
xi) Fixed Asset Mgt System
xii) Other (Specify)_________________

c) From whom you would like to computerize the system?
i) Hire a Programmer
ii) Hire a Software Firm
vi) Buy Local Software
vii) Buy foreign Software
viii) Other (Specify)___________________

6. Do you have a web page of your company?
________________________________________________________________________

7. Are there any computer professional in your company. If yes how many and their expertise?
________________________________________________________________________


Appendix
84

QUESTIONS FOR ORDER MANAGEMENT:

1. Currently how do you manage Orders?
Paper based
Computerized

2. How do you get an order?
Local Buyer.
Foreign Buyer.
Other (Specify).

3. What information about a buyer do you need to know?
________________________________________________________________________
________________________________________________________________________

4. How do you store this information (about a buyer)?
________________________________________________________________________

5. What information do you need about an order?
________________________________________________________________________
________________________________________________________________________

6. How do you store this information?
________________________________________________________________________

7. Do you keep the payment information?
Yes
No

8. What types of reports are produced?
________________________________________________________________________
________________________________________________________________________

9. Who use which reports?
________________________________________________________________________

QUESTIONS FOR LETTER OF CREDIT:

1. When do you open an L/C?
________________________________________________________________________
________________________________________________________________________


Appendix
85
2. Who is responsible to maintain the L/C?
________________________________________________________________________

3. For whom do you open an L/C
a. Foreign buyer
b. Local Supplier
c. Foreign Supplier
d. Buying house
e. Other (Specify)

4. How many Back-to-Back L/C do you open against a Master L/C and why?
________________________________________________________________________
________________________________________________________________________

5. What reports are needed for this section?
________________________________________________________________________
________________________________________________________________________

6. Which reports are used by whom?
________________________________________________________________________
________________________________________________________________________

QUESTIONS FOR INVENTORY MANAGEMENT:

1. Do you have any existing Inventory Management System?
Yes
No

2. What type of materials you usually store?
________________________________________________________________________

3. What information you need about a materials to store?
________________________________________________________________________

4. If any materials needed for an order how you get this information?
________________________________________________________________________

5. Do you keep the information to which you provide these materials?
Yes
No

6. If there is any lacking of any particular materials in your store room what do you do?
________________________________________________________________________
________________________________________________________________________


Appendix
86
7. What information about a supplier you need?
________________________________________________________________________
________________________________________________________________________

8. How do you make a purchase order?
________________________________________________________________________
________________________________________________________________________

9. Do you keep the price and payment related information?
Yes.
No

10. How you keep track of the finished product?
________________________________________________________________________

11. What types of reports are produced in the system?
________________________________________________________________________

12. Who use which report?
________________________________________________________________________

13. Who is responsible for the Inventory Management System?
________________________________________________________________________

QUESTIONS HUMAN RESOURCE MANAGEMENT:

1. What is the current system for keeping personal information and pay roll?
________________________________________________________________________
________________________________________________________________________

2. How many types of employee do you have?
________________________________________________________________________
________________________________________________________________________

3. How many types of salary payment system do you have
a. Base salary paid
b. Consolidate salary paid
c. Other (specify)
________________________________________________________________________
________________________________________________________________________

4. What data do you keep about your employee?
________________________________________________________________________
________________________________________________________________________

Appendix
87

5. How do you collect information about employee?
a. CV
b. A General form
c. Other (specify)
________________________________________________________________________
________________________________________________________________________

6. How do you calculate salary?
________________________________________________________________________

7. On which date of month do you pay salary?
________________________________________________________________________
________________________________________________________________________

8. What is the procedure of paying salary?
a. Check
b. Cash in hand
c. Other (specify)_____________________

9. How do you keep attendance? And who is responsible for keeping employee attendance?
________________________________________________________________________
________________________________________________________________________

10. How do you keep information about overtime and leave?
________________________________________________________________________
________________________________________________________________________

11. What reports do you need and when?
________________________________________________________________________
________________________________________________________________________

12. Are there any systems of penalty? What are those?
________________________________________________________________________
________________________________________________________________________

13. Who maintains all these information?
________________________________________________________________________

14. Who use this information?
________________________________________________________________________

15. Which report goes to whom?
________________________________________________________________________

QUESTIONS FOR ENGINEERING DEPARTMENT:


Appendix
88
1. Is the engineering dept. divided into different team?
Yes
No

2. If yes, in how many team? A team is consisting of how many members?
________________________________________________________________________
________________________________________________________________________

3. What are the general procedures you follow while install/setup the equipments?
________________________________________________________________________
________________________________________________________________________

4. Are you providing any training to the customer to use the product? If yes, for how long
(generally)?
________________________________________________________________________
________________________________________________________________________

5. Are you providing any after sales support (Like, product warranty)?
Yes
No

6. If yes, what is the method of providing it?
________________________________________________________________________
________________________________________________________________________

7. What types of reports are produced in the system?
________________________________________________________________________
________________________________________________________________________

8. Who use which report?
________________________________________________________________________
________________________________________________________________________

9. Who is responsible for the management of engineering dept.?
________________________________________________________________________
________________________________________________________________________


Appendix
89

ERP Report

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ERP Report

Uploaded by

Copyright:

Available Formats

ANALYSIS AND DESIGN OF AN AUTOMATED INFORMATION SYSTEM TO MANAGE

SALES PROCESS OF HONEYCOM SERVICES LIMITED

You might also like