Inventory Control Management Systems

PROJECT MEMBERS
Name Aniruddha Das Arijit Chatterjee Asif Ahmed Debanjali Das Paromita Biswas Shreyasi Paul College Name Academy of Technology Academy of Technology Academy of Technology Academy of Technology Academy of Technology Academy of Technology

Page 1

CONTENTS

Serial No. Name

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Acknowledgement Project Analysis Tools And Platform Used Technology Used Software Engineering Paradigm Preliminary Investigation Feasibility Study System Requirement Specification The Project Entity Relationship Diagram Context Diagram Table Structure Project Testing Conclusion Advantages and Disadvantages Of The Project Future Enhancements Bibliography

Page No.
3 4 5 6 7 7 8 10 13 24 25 26 27 29 30 31 32

Page 2

Acknowledgement
At such an early stage of our career in INFORMATION TECHNOLOGY and its applications we deem ourselves fortunate in having an opportunity to work in such project. A large number of individuals had contributed directly in this project. We would like to thank the countless number of people who have helped get this work out of door. While developing this project we had to consult many people from different grounds of activity, which includes Software Professionals, Database Administrator, Networking professional and many more.

First and foremost, we thank our project guide Sudipta Chatterjee of Moniba Compu Academy Pvt. Ltd. (IBM ACE), whose earnest suggestion, inspiration and involvement paved the way for the successful completion of the project. We would like to offer our special gratitude to them for sharing the ups and downs during the development and bearing inconvenience. We also express our sincere gratitude to all the faculty members of Moniba Compu Academy Pvt. Ltd. (IBM ACE) for their suggestions & enormous encouragement.

Page 3

Project Analysis
A project work is a mandatory requirement for the Business Management Program. This type of study aims at exposing the young prospective executive to the actual business world. This project gives me knowledge about the Inventory Control Management & Material Planning involve raising funds for the firm. It is concerned with formulation and designing of Inventory Control structure. The most crucial decision of any company is involved in the formulation of its appropriate Inventory structure. The best design or structure of the Inventory system of a company helps the management to achieve its ultimate objectives of minimizing overall cost of capital, maximizing profitability and also maximizing the value of the firm Organization. It is very effective way to judge a companys cash flow prospects, as cash is like blood life for any company. The report initially begins with the company profile, followed by the detailed analysis of company, like businesses of the company, products offered by the company, financials of the company, etc. The report involves a lot of research to understand what exactly Inventory control system of the company should be. Thats why companies require appropriate inventory structure. The purpose is to develop an action plan that creates such an inventory structure that will upgrades and standardize the quality of business analysis.

Page 4

Tools and Platform used:

Tools Platform Database : : :

Oracle 10G Express Edition

Hardware Requirement:1. 2. 3. 4. 5. 6. Intel Pentium 1.5 Ghz. 1 GB main memory. 3 GB of free hard disk space. 14 or bigger monitor. Mouse. Standard Keyboard.

Software Requirement:Operating System Database

: Any O.S. Supporting Oracle

: Oracle

Page 5

Technology Used:
PL/SQL (Procedural Language/Structured Query Language) is Oracle Corporation's procedural extension language for SQL and the Oracle relational database. PL/SQL's general syntax resembles that of Ada or Pascal. PL/SQL is one of three key programming languages embedded in the Oracle Database, along with SQL itself and Java. PL/SQL is available in Oracle Database (since version 7), Times Ten in-memory database (since version 11.2.1), and IBM DB2 (since version 9.7). PL/SQL supports variables, conditions, loops and exceptions. Arrays are also supported, though in a somewhat unusual way, involving the use of PL/SQL collections. PL/SQL collections is a slightly advanced topic. Implementations from version 8 of Oracle Database onwards have included features associated with object-orientation. PL/SQL program units (essentially code containers) can be compiled into the Oracle database. Programmers can thus embed PL/SQL units of functionality into the database directly. They also can write scripts containing PL/SQL program units that can be read into the database using the Oracle SQL*Plus tool. Once the program units have been stored into the database, they become available for execution at a later time. While programmers can readily embed Data Manipulation Language (DML) statements directly into their PL/SQL code using straightforward SQL statements, Data Definition Language (DDL) requires more complex "Dynamic SQL" statements to be written in the PL/SQL code. However, DML statements underpin the majority of PL/SQL code in typical software applications. In the case of PL/SQL dynamic SQL, early versions of the Oracle Database required the use of a complicated Oracle DBMS_SQL package library. More recent versions have however introduced a simpler "Native Dynamic SQL", along with an associated EXECUTE IMMEDIATE syntax. Oracle Corporation customarily extends package functionality with each successive release of the Oracle Database.

Page 6

Preliminary Investigation:
A request to take assistance from information systems can be made for many reasons, but in each case someone in the organization initiates the request. When the request is made, the first systems activity the preliminary investigation begins. This activity has three parts: Request Clarification Feasibility Study Request Approval

Request Clarification: Many requests from employees and users in the organizations are not
clearly defined. So it becomes necessary that project request must be examined and clarified properly before considering systems investigation.

Feasibility Study: An important outcome of the preliminary investigation is the determination

that system requested is feasible. There are three aspects in the feasibility study portion of the preliminary investigation: Technical Feasibility Economic Feasibility Operational Feasibility

Request Approval: The projects that are feasible and desirable should be put into a schedule. In
some cases, development can start immediately although usually systems staff members are busy on other projects. When such situation arises, management decides which projects are most urgent and schedules them accordingly. After a project request is approved, its cost, priority completion time and personnel requirements are estimated.

Page 7

Feasibility Study:
Feasibility is the determination of whether or not a project is worth doing. The process followed in making this determination is called a feasibility study. This type of study determines if a project can and should be taken. Once it has been determined that a project is feasible, the analyst can go ahead and prepare the project specification which finalizes project requirements. Feasibility studies are undertaken within tight time constraints and normally culminate in a written and oral feasibility report. The contents and recommendations of such a study will be used as a sound basis for deciding whether to proceed, postpone or cancel the project. Thus since the feasibility should may lead to the commitment of large resources, it becomes necessary that it should be conducted competently and that no fundamental errors of judgment are made. In the conduct of feasibility study the analyst will usually consider seven distinct but interrelated types of feasibility. They are:

TECHNICAL

FEASIBILITY:

This is concerned with specifying equipment and software that will successfully satisfy the user requirement. The technical needs of the system may vary considerably but might include: The facility to produce outputs in a given time. Response time under certain conditions. Ability to process a certain volume of transaction at a particular speed. Facility to communicate data to distant location. In examining technical feasibility, configuration of the system is given more importance than the actual make of hardware. The configuration should give the complete picture about the systems requirement. Out of all feasibilities technical feasibility is most difficult to determine.

OPERATIONAL FEASIBILITY:
It is mainly related to human organizational and political aspects. The points to be considered are: What changes will be brought with the system? What organizational structures are disturbed? What new skills will be required? Do the existing staff members have these skills? If not, can they be trained in due course of time? Generally project will not be rejected simply because of operational infeasibility but such considerations are likely to critically affect the nature and scope of the eventual recommendations. This feasibility study is carried out by a small group of people who are familiar with information system techniques, who understand the parts of the business that are relevant to the project and are skilled in system analysis and design process.

ECONOMIC FEASIBILITY:
Economic analysis is the most frequently used technique for evaluating the effectiveness of a proposed system. More commonly known as cost/ benefit analysis; the procedure is to determine the benefits and savings that are expected from a proposed system and compare them with costs. If benefits outweigh costs, a decision is taken to design and implement the system. Otherwise, further Page 8

justification or alternative in the proposed system will have to be made if it is to have a chance of being approved.

TIME FEASIBILITY:
Time feasibility is a determination of whether a proposed project can be implemented fully within a stipulated time frame. If project takes too much time it is likely to be rejected.

MANAGEMENT FEASIBILITY:
It is a determination of whether a proposed project will be acceptable to management. If management does not accept a project or gives a negligible support to it, the analyst will tend to view the project as a non-feasible one.

Page 9

System Requirement Specification:

1. SYSTEM REQUIREMENTS:The problem which software engineers are called upon to solve is often immensely complex. Understanding the nature of the problem can be very difficult. If the system is new, there is no existing system to help understand the nature of the problem. Consequently, it is difficult to establish exactly what the system should do. The process of establishing the services the system should provide and the constraints under which it must operate is called requirements engineering. The term engineering is used rather loosely in this respect. It means that a systematic process is used to derive a definition of the software system which is to be developed. Requirements analysis is done in order to understand the problem the software system is to solve. The problem could be automating an existing manual process, developing a new automated system, or a combination of two. My project emphasis on requirements analysis is on identifying what is needed from the system, not how the system achieves its goal. This task is complicated by the fact there are often at least two parties involved in software development-a client and a developer. The developer has to develop the system to satisfy the clients needs. The developer usually does not understand clients problem domain, and the client often does not understand the issues involved in software systems. This causes a communication gap, which has to be adequately bridged during requirement analysis. Some of the problems that arise during the requirements engineering process are a result of failing to make a clear separation between these different levels of description. We make this separation by using the term requirement definition to mean the high level abstract description of requirements and requirements specification to mean the detailed description of what the system should do. As well as these two levels detail, a further even more detailed description may be produced to bridge the requirements engineering and design activities. Requirement specification, requirement defication and software specification may be defined as follows: 1. A requirements defication is a statement, in a natural language plus diagrams, of what services the system is expected to provide and constraints under which it must operate-it is generated using customer-supplied information. 2. A requirements specification is a structured document which sets out the system services in detail this document. Which is sometimes called a functional specification, should be precise. It may serve as a contract between the system buyer and software developer. Page 10

3. A software specification is an abstract description of the software which is a basis for design and implementation. This specification may add further detail to the requirement specification.

2. REQUIREMENT VALIDATION:Requirement validation is concerned with showing that the requirements are actually define the system that the clients want. If this validation is adequate, errors in the requirements will be propagated to the system design and implementation. Expensive system modifications may be required at a larger stage to correct problem with requirements. The cost of errors in requirements is particularly high if these errors are not discovered until the system is not implemented. The cost of making a system change resulting from a requirement problem is much greater than repairing design or coding errors. A requirements change implies that the design and implementation must also be changed. The system testing and validation process must be repeated. The cost of changing a system after delivery because of a requirement change can therefore be up to 100 times more than the cost of repairing a programming error. There are several aspects of the requirements which must be checked: I. Validity A user may think that a system is needed to perform certain functions. However, further thought and analysis may identify additional or different functions that are required. Systems have diverse users with different needs and any set of requirements is inevitably a compromise across the user community. II. Consistency any one requirement should not conflict with any other. III. Completeness should include all functions and constraints intended by the system user. IV. Realism There is no point in specifying requirements that are unrealizable. It may be acceptable to anticipate some hardware developments in software technology are much less predicted.

3. REQUIREMENT EVOLUTION:Developing software requirement forces attention on software capabilities, business objectives and other business systems. As the requirements definition is developed, a better understanding of users needs is achieved. This feeds information back to the user, which causes the requirements. To be changed. Furthermore, the time required analyzing requirements and to develop a large system may take several years. The inevitability of change should be recognized and

Page 11

anticipated when producing a requirements document. It is unwise to prematurely freeze requirements. Although this is attractive as far as system development is concerned, it leads to systems that are unlikely to meet the real business needs of systems procurer. This activity is at the heart of system analysis the analyst must study the present system and document feature for further analysis by using various fact by gathering techniques. The analyst must evaluate the flow and structure of information, refine all software functions in detail, and establish system: Therefore characteristic and uncovered details design consideration. Each of these tasks servers to described the problem so that an overall approach or solution may be synthesized. The analyst must determine the problems with the current system and determined what information will be produced by new system and what data will be provided to the system. After doing this analyst must synthesize one or more possible solution.

Page 12

The Project:
Customer:

Page 13

Page 14

Product:

Page 15

Page 16

Page 17

Transaction:

Page 18

Page 19

Page 20

Page 21

Vendor:

Page 22

Page 23

Context Diagram

Customer

Inventory Management System

Vendor

Page 24

Entity Relationship Diagram

Entity-Relationship Model :
The E-R (entity-relationship) data model views the real world as a set of basic objects (entities) and relationships among these objects. It is intended primarily for the DB design process by allowing the specification of an enterprise scheme. This represents the overall logical structure of the database Products
HAS

Transaction

IS A

Sales

Makes

Customer

IS A

Table Structures:

Page 25

Table Structure
1. PRODUCT:

2. CUSTOMER:

3.VENDOR:

4.TRANSACTION:

Page 26

Project Testing:
Introduction: Software testing is the process of testing the functionality and correctness of software by running it. Software testing is usually performed for one of two reasons: I. Defect detection. II. Reliability estimation. The problem of applying software testing to defect detection is that software can only suggest the presence of flaws, not their absence (unless the testing is exhaustive). The problem of applying software testing to reliability estimation is that the input distribution used for selecting test cases may be flawed. In both of these cases, the mechanism used to determine whether program output is correct (known as an oracle) is often impossible to develop. Obviously the benefit of the entire software testing process is highly dependent on many different pieces. If any of these parts is faulty, the entire process is compromised. General Techniques of Testing : There are two main methodologies of testing: white-box and black-box testing. White-box testing examines the internal structure of a program and attempts to test each logical case. White-box testing can be thought of as "transparent" box testing: the tester can see and test a specific section of code. For instance, in white-box testing, an IF-THEN-ELSE statement would be tested with both a TRUE condition and a FALSE condition. Unfortunately, there are a few problems with white-box testing: The tester often does not have access to the source code. White-box testing can be exponentially large (for n IF-THEN-ELSE statements, there are 2n different combinations of values). These problems with white-box testing lead to the more practical black-box testing methodology. Black-box testing (also known as data-driven or input/output-driven testing) in which the tester views the program as a black box, and as such, the inner workings of the program are unknown. The main tool used in black-box testing is the specification of the program: that is, the tester attempts to determine what input causes the output of the program to be different from what the specifications would require. Besides these two types of testing there is another type of testing strategy known as Gray-box testing. In using this strategy Black box testing can be combine with knowledge of database Page 27

Validation, such as SQL for database query and adding/loading data sets to confirm functions, as well as query the database to confirm expected result. Advantage of Black-box testing: Black-box is better in that it discovers: Missing functions Functions which do not correspond to the spec Weakness in the spec Interface errors between modules Performance weakness Initialization errors Termination errors Advantage of White-box testing: White-box is better than black-box in that: It goes into a level far beyond just looking at the output of a program, and is therefore clearly better than black-box testing on individual small modules It discovers extra non-specified functions that black-box would not know to look for such extras can only be discovered by inspecting the code.

Page 28

Conclusion :
Testing is an essential stage of Software Development Life Cycle. If they are done properly by following an organizations standards the end result will be more robust programs going into System integration. Proper Coding and Unit Testing are basic steps to ensure that the system being built will work once it is put together. Regulations expect that the accurate coding and testing will be performed and documented The Quality Assurance Professional must help educate programming staff if they do not already know what standards should be followed and internal reviews are required. During the SDLC, there are many types of reviews including requirements review, design review, code review (walkthroughs) and test readiness review. The Quality Assurance Professional can be a part of each of these review process. And most importantly we all know that it isnt documented, it never happened. Software Developers must be persuaded to save the results of their hard work for future use.

Page 29

Advantages and Disadvantages of The Project:

Speed and Efficiency
A computerized inventory management system makes everything from inputting information to taking inventory easier. Doing a hand count of inventory can take days, but with a computerized inventory management system, the same process can be done in a matter of hours.

Document Generation
Once the computerized inventory management system is in place, managers and workers can use it to automatically generate all kinds of documents, from purchase orders and checks to invoices and account statements. Managers can also use the system to automatically order products when they run low.

Timely Data
With a manual system, the data is only as accurate and up to date as the last hand count. With a computerized inventory management system, the management team can pull a report and instantly see how many units are on the floor, how many have sold and which products are selling the fastest.

Reliance on Technology
With a computerized inventory management system, the company is at the mercy of its technology. Outside factors like a power failure or the loss of Internet or network connectivity can render the system temporarily useless.

Accuracy Issues
A computerized system alone does not ensure accuracy, and the inventory data is only as good as the data entry that created it. Companies that plan to use a computerized inventory management system need to have a system in place to validate their data and check the numbers reported by the system. A select hand count or targeted audit may be necessary to ensure the integrity of the system.

Risk of Fraud
Any computerized system carries the risk of intrusion, and with a computerized inventory management system comes the risk of fraud as well. A dishonest vendor could hack the system to receive payment for products never delivered, or a dishonest employee could redirect checks to themselves.

Page 30

Future Enhancements:
The scope of the project includes that what all future enhancements can be

done in this system to make it more feasible to use Databases for different product range and storage can be provided. Multilingual support can be provided so that it can be understandable by the person of any language. This whole project is a backhand version. A graphic user interface can be created to make the project more user friendly. Manage and backup versions of documents can be created online.

Page 31

Bibliography:

http://www.scribd.com http://en.wikipedia.org/wiki/Inventory_control_system http://en.wikipedia.org/wiki/PL/SQL http://smallbusiness.chron.com/advantages-disadvantagesmanual-inventory-control-system-22693.html

Certificate Of Originality

Page 32

This is to certify that the project report entitled Inventory Control Management Systems submitted to Moniba Compu Academy Pvt. Ltd. (IBM ACE) in fulfillment of the Vocational Training Program on Inventory Control Systems, is an original work carried out by the students named below.:

Name Aniruddha Das Arijit Chatterjee Asif Ahmed Debanjali Das Paromita Biswas Shreyasi Paul
under the guidance of Sudipta Chatterjee.

College Name. Academy of Technology Academy of Technology Academy of Technology Academy of Technology Academy of Technology Academy of Technology

The matter embodied in this project is a genuine work done by the student and has not been submitted whether to this University or to any other University/Institute for the fulfillment of the requirement of any course of study.

Signature of the guide

Page 33