Friday, December 6, 2019

Inventory Management Developed for Australian Labs

Question: Discuss about the Inventory Management for Developed for Australian Labs . Answer: Introduction 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 to Systems Development 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 users 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. 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. Sources of Software 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: 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) Systems Requirements 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. Non-functional Requirements 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 24x7 basis and the downtime in case of an attack or a disaster should be minimal. Project Cost Benefit Analysis 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. Project Schedule 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 System Information Requirement Investigation Techniques 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 External Stakeholders: Project Sponsor Jim Larsen and his team Customers Suppliers Vendors Technicians Information Investigation Techniques 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/AnalysisDesign/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].

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.