Software Engineering: A Methodical Approach (2014)

PART G. Appendices

Appendix 8. Project Proposal for a Generic Inventory Management System

This appendix provides excerpts from a sample project proposal (also called initial system requirement) for a generic Inventory Management System that may be suitable for a small or medium sized organization.

The document includes the following:

· Problem Definition

· Proposed Solution

· Scope of the System

· System Objectives

· Expected Benefits

· Overview of Storage Requirements

· Anticipated Outputs

· Feasibility Analysis Report

· Initial Project Schedule

A8.1 Problem Definition

When operating a business, an inventory management system is one of the fundamental needs. Inventory management is critical to any business. The absence of such a system could result in several problems, some of which are stated below:

1. If a business does not know what items are in stock it might lose significant sale opportunities. On the other hand if the inventory system shows items in stock that are actually not in stock then that is an embarrassing situation where a customer has to wait while the missing (non-existent) item is being located. This lack of professionalism could most certainly drive customers away.

2. In addition to this, there is also the problem of knowing exactly how much inventory should be kept on hand. Keeping too much inventory on hand is costly, resulting in storage costs, insurance costs, and salaries of individuals to manage/locate inventory. On the other hand, not having sufficient stock on hand is also costly, in that the business could lose significant opportunities for additional sale.

3. Knowing exactly how much stock is on hand is crucial to knowing exactly when items need to be reordered.

4. Inability to properly manage the inventory could severely affect the productivity and profitability of the company.

A8.2 Proposed Solution

This project seeks to address this problem by developing generic Inventory Management System (IMS) that is tailored to the specific needs of any company.

This software system must be portable and platform independent (if possible). In light of this, the recommended software development tools include Delphi or Java NetBeans on the front-end, and MySQL as the back-end DBMS.

A8.3 Scope of the System

The main components of the system will be as follows:

· A relational database in MySQL or another portable DBMS stores the essential data for subsequent analysis

· An Acquisitions Subsystem (AS) facilitates tracking of purchases, utilization and sale of inventory items

· A Financial Management Subsystem (FMS) provides the financial implications of various transactions

· Point of Sale Subsystem (POSS) manages interfacing between the point of sale equipment (barcode scanners, and invoice printers, etc.) and the internal database

A8.4 System Objectives

The Inventory Management System (IMS) will fulfill the following objectives:

· Accurate tracking of inventory

· Features to facilitate entry and update of inventory items and modify products and quantities

· Tracking of customers and suppliers contact information

· Tracking of outgoing purchase orders to suppliers

· Tracking of incoming purchase orders from customers

· Features to facilitate management of purchases and sale of goods

· Features to facilitate and handle return of goods purchased and sold

· Features to query various aspects of the company’s inventory (e.g. lookup quantities for specific items) and the financial implications of this

· Facility to generate an inventory sheet

· Alerts for the reorder of inventory items

· Basic financial management capabilities which will give an overview of the financial status of the company (basic account receivable and accounts payable)

A8.5 Expected Benefits

The IMS will bring a number of benefits to the organization:

· The system will help to keep accurate records of inventory. This will be an invaluable aid to sales as well as purchasing.

· The maintenance of accurate records should reduce the likelihood of inventory loss or misappropriation.

· The system will reduce the amount of human effort needed, and hence the overhead cost of the business.

· The system will contribute to improving the public image of the business — customers will appreciate being able to know instantly exactly what is available without having to waste time.

· The system should facilitate better management decisions, as well as improved productivity.

· The system will facilitate better management of the company’s resources. For instance, instead of having money tied up in unnecessary inventory, the company can have a just-in-time (JIT) delivery system, and thereby free up funds that would otherwise be used in inventory storage, to be available for other aspects of the business.

A8.6 Overview of Storage Requirements

It is anticipated that the system will contain the following main information entities:

· Inventory Master

· Item Categories

· Suppliers

· States or Provinces

· Customers

· Purchase Orders

· Purchase Invoices

· Purchase Returns

· Sale Orders

· Sale Invoices

· Sale Returns

· Chart of Accounts

· Accounting Balances

· Purchase Invoice Payment Plans

· Payments Made

· Financial Institutions of Interest

· Sale Invoice Payment Plans

· Payments Received

· Financial Transactions

· Investments

A8.7 Anticipated Outputs

It will be possible to run queries and obtain reports on all information stored. As such, operations will be provided to extract and display information from the above mentioned information entities. Some of the more prominent outputs are as follows:

· Inventory Master Listings

· Sales Orders

· Sales Invoices

· Payments Received Log

· Accounts Receivable

· Returns History

· Purchase Orders

· Purchase Invoices

· Payments Made Log

· Accounts Payable

· Account Balances — Accounts Payable and Accounts Receivable

· Financial Transactions Log

· Investments Log

A8.8 Feasibility Analysis Report

Possible alternate solutions examined are

· Alternative A: Manual system where inventory is kept track of by hand

· Alternative B: Buy an off-the-shelf solution and customize it

· Alternative C: Contract a software engineering firm to develop the system

· Alternative D: Develop system as a student project (for the purpose of illustration and academic research, this alternative will be taken)

A8.8.1 Feasibility of Alternative A

The technical feasibility of this alternative may be summarized as follows:

· No expensive computer equipment would be required; only folders, files, and basic office equipment would be needed.

· No computer software would be needed.

· Not much knowledge and expertise is required since this kind of job would be basically filing forms and keeping track of inventory.

· No other technology would be required.

The economic feasibility of this alternative may be summarized as follows:

· The cost of this option is minimal (the wages of the employees who count stock and fill out the inventory forms).

· The cost of the office supplies needed for this system would be minimal.

The operational feasibility of this alternative may be summarized as follows:

· This method of having to manually count stock would be time consuming and painstakingly difficult and it offers no guarantee of success.

· There would be no development time since this is a manual system.

· Implementation time would also be low — because this manual system is easy to learn not much training is required to be able to do the job.

The risks associated with this approach are extremely high. All the problems stated above would remain. This could potentially run the business into bankruptcy.

A8.8.2 Feasibility of Alternative B

The technical feasibility of this alternative may be summarized as follows:

· The business no doubt already has the computer hardware that would be required to run the software.

· Customizing the software package could be tedious if the acquired software system is poorly designed.

· Maintaining the software could be problematic, especially if the system is poorly designed, and the documentation is scanty and/or inadequate.

· There is no guarantee that the purchased software system will be comprehensive enough.

In terms of economic feasibility, the initial investment may be affordable. However, estimating maintenance cost could be tricky.

The operational feasibility of this alternative may be summarized as follows:

· There would be no development time since the software is already made.

· The implementation time would be related to how well-designed the software system is. If it’s well designed, installation time and time to learn the software should be minimal.

· User training would be required.

The risks associated with this approach are high, since there is no guarantee that software acquired will live up to expectations.

A8.8.3 Feasibility of Alternative C

The technical feasibility of this alternative may be summarized as follows:

· Acquiring the required software development environment would be the responsibility of the contracted company.

· Knowledge and expertise might be required in learning the new software and how to use and apply it, but a well-developed software system that is custom-made for the business should be easy to learn.

· The developers themselves would have to spend some time learning about the operation and needs of the business in order to be able to develop a suitable software system.

The operational feasibility of this alternative may be summarized as follows:

· The initial investment would be very high because paying a software engineering company for development time can be very costly.

· Development time could be as much as 6 months to a year, but for an experienced software engineering firm, it shouldn’t take more than a few months.

· The economic life of such custom-made software should be relatively long if the software is well made and well designed and if the needs of the business don’t change drastically, in which case the system would either be not needed or wouldn’t be adequate enough for the new needs.

The operational feasibility of this alternative may be summarized as follows:

· User training would be required.

· Implementation time should be short, provided that the system is adequately designed.

The risks associated with this approach could be high or low, depending on how the project is managed. There is no guarantee that software engineering firm will deliver a good job; however, precautions can be taken to ensure software quality.

A8.8.4 Feasibility of Alternative D

The technical feasibility of this alternative may be summarized as follows:

· Acquisition of the required software development environment would be required.

· Required knowledge and expertise are readily available.

The operational feasibility of this alternative may be summarized as follows:

· Technology required is relatively inexpensive.

· The development time would be high, but the benefits gained from the experience would be huge.

The operational feasibility of this alternative may be summarized as follows:

· The implementation time would be long, mainly because the software would have to be developed by student effort.

· Minimal user training would be required.

The risks associated with this approach could be high or low, depending on how the project is administered. The student has total control over who works on the project, so depending on the quality of the project team risks may or may not be reduced.

A8.8.5 Evaluation of Alternatives

The following table provides a comparison of the project alternatives, based on a number of feasibility factors. For each factor, a rank in the range {0 .. 20} is given for each alternative.

Figure A8-1. Feasibility Evaluation Grid Showing Comparison of System Alternatives

A8.9 Initial Project Schedule

Figure A8-2 shows an initial project schedule. This will be further refined as more details become available. The estimated duration (assuming three full-time software engineers) is 41 weeks.

Figure A8-2. Initial Project Schedule