Automated Inventory Management System For Australian Labs

Approach to Systems Development

Discuss about the Inventory Management for Developed for Australian Labs .

The report is developed for Australian Labs to develop and implement an automated inventory management system at their end. A paper based inventory management and tracking system is currently used in the Australian labs which causes a number of faults and mismanagement and leads to unhappy customers. The project will develop an advanced inventory management system linked with the latest database to manage all the tests that are received by the labs along with the provision of providing accurate status updates and turnaround estimates. The report suggests the two approaches for system development along with the functional and non-functional requirements associated with the project. Project schedule, stakeholder analysis and the information investigation techniques have also been covered in the report.

Approach 1

The first approach that can be used to develop the inventory management system for Australian labs is the predictive waterfall model for software development.

This approach will apply to this project as the requirements for the development process are well clear and there are lesser chances of major changes and inflation associated with the same. The waterfall model for software development proceeds in a step by step manner and will include the following phases:

• Requirements Analysis and Definition

The requirements that will be provided by Jim Larsen will be analysed in order to decide the project strategy and understand the project objectives. The requirements will also be classified in functional and non-functional categories. Resource allocation, cost/benefit analysis and project schedule will also be completed in this phase (Lott, 1997)

• System and Software Design

On the basis of the requirement specifications, design specifications will be created in the form of a number of design diagrams and blueprints.

• System Development and Unit Testing

The coding phase will begin in this phase along with the setting up of the database for the system. A unit testing of the entire code will be done to rectify the basic issues detected.

• System Testing and Implementation

The entire software build provided by the development team will be tested as per the test approach and the defects will be reports. There will also be change requests and performance management done under the implementation of the system.

• Operations and Maintenance

This is the last phase in this approach which will deal with the release activities and the post-production tasks such as handling of issues at the user’s end.

Approach 2

The second approach that has been suggested for the development of inventory management system for Australian labs is the Agile Software Development methodology. This is the adaptive approach towards software development that works on the ad-hoc basis.

Sources of Software

The requirements are more of static in this project and are less likely to change. However, there can be a few last minute changes and this methodology will allow incorporating the same without any re-work. Also, the customer will be involved in every single phase of the project and would be able to provide the valuable comments and feedback at every step (Habib, 2013).

The development process will proceed in the form of iterations which are termed as sprints as per the agile methodology. Every sprint will work on a sub-set of the entire list of the requirements and will have a daily scrum meeting of a short duration to understand the progress and required effort. One sprint will last for three to five weeks and the customer will be involved during the entire set of activities. The customer feedback along with the product and sprint backlog will be utilized in the next sprint. The end product will then be produced as the final outcome.

There are a number of sources of software which are as listed below along with the advantages of each.

• Information Technology Service Firms               

This is the source in which an IT firm outsources its software to other organizations. These can be customized as per the required application and are preferred as they come with vendor support, documentation and customization.

• Packaged Software Products               

These are also termed as off-the-shelf software as the organizations offer these packages for commercial utilization. These are generally cheaper and are available immediately (Hoffer, George, & Valacich, 2016).

• Enterprise Solutions Software

These are also a widely used software source as it provides complete integration with the current business processes of an organization.

• Cloud Computing

This is the newer form of the software source as it comes free from the requirement of a computing infrastructure for using the same. The software is provided over the internet and the customers can easily use the same from over there.

• Open Source Software

These are the software that are available for free and come with the basic to advanced features for the users.

• In-House Development

Organizations also tend to go for in-house development of the required software if they have the required skill set present. This form of software is always designed such that the required specifications are fulfilled.

There are a number of off-the-shelf software packages that are available. The choice of the same shall depend upon the need and requirement of a particular project along with the project budget and the skill set that is available with the organization. In case of the Australian labs project, the following off-the-shelf software can be utilized to remain low on cost and high on availability and requirements:

Systems Requirements

Microsoft Project for designing and managing the project schedule

Adobe Dreamweaver for coding

MySQL database for keeping the customer and vendor information stored and also to manage the same

Word processors and spreadsheets for reporting and other documentation (Zentz, 2013)

Functional Requirements

• Login Functionality

The users will be allowed to login to the application and the three types of users will be setup as administrator, customer and technician.

• Inventory Tracking

The option would allow the user to enter their order id and the tracking details will be displayed in terms of a report that will contain the customer information, date of request, current status and the delivery date.

• Extraction of Reports

The customers will also be allowed to print or save their test reports and the collection details will also be displayed.

• Cancellation Requests

The customers will also be provided to cancel the requests after 12 to 24 hours of the placement of the same.

• Request tracking for technicians

The option will be allowed only for the technicians to view the requests that are pending to be completed along with the ones that have already been completed. It will allow them to devise the strategy accordingly.

• Automatic Alerts

The system will generate alerts to the users on the completion of their requests.

• Admin role

The admin will be able to set up user privileges along with setting up of the priorities on the requests that are received.

The following set of non-functional requirements will be fulfilled by the inventory management and tracking system.

Usability: The system must be usable for the customers as well as form the technicians. It should have smooth navigations and must be designed to fulfil all the requirement specifications for Australian labs.

Reliability: The information that is presented on the system must be reliable and accurate in nature. It must be updated regularly to show the latest piece of information from the database.

Performance: The system should score well on the performance in terms of the response time and the user experience.

Scalability: The system should be scalable in nature that is it should always have the scope to upgrade and add new functionalities without compromising on the existing ones (PUROHIT, 2016).

Availability: The system must be available on a 24×7 basis and the downtime in case of an attack or a disaster should be minimal.

Cost benefit analysis is defined as a process where decisions are made on the basis of cost invested and benefits obtained from an information system in order to find whether the investment would be of any use. In this project, the process has been carried out to find the economic feasibility of the project. For this, Net Present Value and Return rate are calculated. In addition to this, payback period is also being calculated.

As shown in the calculations above, NPV is positive and net return of investment is 7% and break even occurs between 3 and 4 years i.e. 3.99 years i.e. payback period turns out to be 4 years. Hence, from this analysis, the proposed system is feasible and can be started. This result comes with 6% discount factor.

		Fiscal Year
Program Element	Element Manager	2016	2017	2018	2019	2020
Element 1	Total cost	$80,000
Element 2	Maintenance		$25,000	$25,000	$25,000	$25,000
Program Total Costs By Year	$80,000	$25,000	$25,000	$25,000	$25,000
Program Grand Total Cost	$180,000

	Fiscal Year
Benefit Sources	2016	2017	2018	2019	2020	2021
Cost Reduction		$40,000	$40,000	$40,000	$40,000	$40,000
Total Benefits Per Year	$0	$40,000	$40,000	$40,000	$40,000	$40,000
Confidence Factor	100%	100%	100%	100%	100%	100%
Benefits Claimed for Analysis	$0	$40,000	$40,000	$40,000	$40,000	$40,000
Program Grand Total Benefit	$200,000

	Fiscal Year
	2016	2017	2018	2019	2020	2021
Undiscounted Flows
Costs	-$80,000	-$25,000	-$25,000	-$25,000	-$25,000	$0
Benefits	$0	$40,000	$40,000	$40,000	$40,000	$40,000
Net Cash Flow	-$80,000	$15,000	$15,000	$15,000	$15,000	$40,000
Discount Factors
Discount Rate	6.0%
Base Year	2016
Year Index	0	1	2	3	4	5
Discount Factor	1.0000	0.9434	0.8900	0.8396	0.7921	0.7473
Discounted Flows
Costs	-$80,000	-$23,585	-$22,250	-$20,990	-$19,802	$0
Benefits	$0	$37,736	$35,600	$33,585	$31,684	$29,890
Net	-$80,000	$14,151	$13,350	$12,594	$11,881	$29,890
Cumulative	-$80,000	-$65,849	-$52,499	-$39,905	-$28,023	$1,867
Net Present Value	$1,867
Internal Rate of Return	7%

Table 1: Cost Benefit analysis

However, with 10%, the NPV is negative, hence it is not economical feasible to develop the proposed system.

Work Breakdown Strutcure

DESCRIPTION	START DATE	END DATE	DURATION (days)
1.      Inventory Management and Tracking System	8/25/16	11/11/16	76
1.1     Initiation	8/25/16	9/7/16	12
1.1.1 Evaluation & Recommendations	8/29/16	8/31/16	2
1.1.2 Develop Project Charter	8/31/16	9/2/16	2
1.1.3 Deliverable: Submit Project Charter	9/2/16	9/3/16	1
1.1.4 Project Sponsor Reviews Project Charter	9/3/16	9/5/16	2
1.1.5 Project Charter Signed/Approved	9/5/16	9/7/16	2
1.2     Planning	9/7/16	9/19/16	12
1.2.1 Create Preliminary Scope Statement	9/7/16	9/12/16	5
1.2.2 Determine Project Team	9/12/16	9/13/16	1
1.2.3 Project Team Kickoff Meeting	9/13/16	9/13/16	0
1.2.4 Develop Project Plan	9/13/16	9/16/16	3
1.2.5 Submit Project Plan	9/16/16	9/16/16	0
1.2.6 Milestone: Project Plan Approval	9/16/16	9/19/16	3
1.3     Analysis and Design	9/19/16	10/7/16	18
1.3.1 Project Kickoff Meeting	9/19/16	9/19/16	0
1.3.2 Verify & Validate User Requirements	9/19/16	9/23/16	4
1.3.3 Design System	9/23/16	10/3/16	10
1.3.4 Procure Hardware/Software	10/3/16	10/5/16	2
1.3.5 Install Development System	10/5/16	10/7/16	2
1.4     Implementation	10/7/16	10/17/16	10
1.4.1 Project Management	10/7/16	10/17/16	10
1.4.2 Project Status Meetings	10/7/16	10/17/16	10
1.4.3 Risk Management	10/7/16	10/17/16	10
1.4.4 Update Project Management Plan	10/7/16	10/17/16	10
1.5 Testing	10/17/16	11/1/16	14
1.5.1 Test Scope	10/17/16	11/1/16	14
1.5.2 Test Plan Preparation	10/17/16	11/1/16	14
1.5.3 Test Case Creation	10/17/16	11/1/16	14
1.5.4 Test Execution	10/17/16	11/1/16	14
1.5.5 Defect Reporting	10/17/16	11/1/16	14
1.6     Closeout	11/1/16	11/11/16	10
1.6.1 Audit Procurement	11/1/16	11/11/16	10
1.6.2 Document Lessons Learned	11/1/16	11/11/16	10
1.6.3 Update Files/Records	11/1/16	11/11/16	10
1.6.4 Gain Formal Acceptance	11/1/16	11/11/16	10
1.6.5 Archive Files/Documents	11/1/16	11/11/16	10

The project schedule has been designed as per the activities that are covered in the Work Breakdown Structure of the project as shown above. Each of the activity has been allotted a time frame as per the list of the sub-activities that are present under the same along with the effort that is required to complete all of the tasks.

Initiation and Planning activities have been allotted 12 days each as the base of the project will be formed in these two phases only. It is essential for the resources to have the time at their hands to cover and complete each of the activity with perfection to avoid risks and delays at the later stage. Analysis and design has captured the major schedule that is 18 days as this is the phase in which the actual design and development will take place. Implementation, testing and closeout have covered a share of 10 days each as there are a number of components that are involved under each of these. The entire schedule has been created such that the resources get the required amount of time and are able to meet the deadlines as well.

The schedule has been designed as per the systems goals, requirements and scope. The basic aim of the system is to provide an automated Inventory Management and Tracking System to the users for smooth and quick working. The schedule covers all the required phases that will aid in achieving the same. Also, the time that has been assigned is in accordance with the same as described above.

Figure 1: Gantt chart

Stakeholders

There are a number of stakeholders that will be involved with the system which are as listed below:

Internal Stakeholders:

• Project Manager
• System Developer
• System Designer
• Database Administrator
• Test Engineer
• Implementation Head

• Project Sponsor – Jim Larsen and his team
• Customers
• Suppliers
• Vendors
• Technicians

Technique 1

A questionnaire must be prepared by the analysts for all the parties that are involved. It shall cover the basic criteria of the information collection by including the questions that answer the objective of the system being developed, the business need of the system, the target audience and likewise. These set of questions can also be divided in a number of different categories to record the answers better.

Technique 2

The second technique that can be adopted is a one-on-one interview session with the parties. The interviews would allow the personal standpoint of the entity which may be absent in the group discussions. It will also allow the analysts to understand the variety of viewpoints and come up with an effective analysis (processworksgroup.com, 2016).

Technique 3

The third technique that can be used for information investigation and gathering is through workshops and sessions. These can be informal in nature so that the parties that are involved ease out and are able to provide effective information without any hesitation. It will allow the analysts to understand the behaviour and requirements of the participants in an excellent manner.

All the three techniques that have been described are different from each other. Questionnaires and interviews are the most applicable when the anonymity of the resources has to be maintained. The third technique of workshops is applicable when it is necessary to understand the standpoint of an individual along with the group as a whole.

These three techniques are extremely useful not only to extract the information from the parties that are involved but to also make the resources feel involved in a particular activity by assuring them that their viewpoints are being considered. These are also important for the analysts to understand the difference of opinion of an individual in a group atmosphere and in the standalone environment as well.

Reflections and Conclusions

The project development cost was restricted to $80,000,00 and the recurring cost was $25,000,00. The same had to be maintained to avoid any budget overruns. Also, the project schedule did not have any scope for delays and re-work.

The project was designed for allowing the customers and technicians to have a better experience in terms of inventory related activities. It was developed to provide an automated solution to the associated parties and the requirement set also reflects the same. Non-functional requirements were also included in the project to make sure that the user experience with the system that is developed is of utmost quality and results in supreme level of customer satisfaction.

References

Ambler, S. (2016). The Agile System Development Life Cycle (SDLC). [online] Ambysoft.com. Available at: https://www.ambysoft.com/essays/agileLifecycle.html [Accessed 23 Aug. 2016].

Habib, M. (2013). Agile software development methodologies and how to apply them – CodeProject. [online] Codeproject.com. Available at: https://www.codeproject.com/Articles/604417/Agile-software-development-methodologies-and-how-t [Accessed 23 Aug. 2016].

Hoffer, J., George, J. and Valacich, J. (2016). System Analysis & Design. [online] Available at: https://www.cs.kau.se/~gustas/student/Analysis&Design/Introduction(2).pdf [Accessed 23 Aug. 2016].

PUROHIT, S. (2016). SYSTEM REQUIREMENTS SPECIFICATIONS FOR THE PROJECT INVENTORY CONTROL SYSTEM FOR CALCULATION AND ORDERING OF AVAILABLE AND PROCESSED RESOURCES. [online] Available at: https://www.cs.uic.edu/~spurohit/documents/Requirements%20Document.pdf [Accessed 23 Aug. 2016].

Lott, C. (1997). Breathing new life into the waterfall model. IEEE Software, [online] 14(5), pp.103-105. Available at: https://dx.doi.org/10.1109/52.605938 [Accessed 23 Aug. 2016].

Zentz, M. (2016). Custom vs. Off-the-Shelf Software | Digital Marketing Insights | The Marketpath Web Digest. [online] Marketpath.com. Available at: https://www.marketpath.com/digital-marketing-insights/custom-applications-vs-off-the-shelf-software [Accessed 23 Aug. 2016].