Stock Maintenanace System
Stock Maintenanace System
PROBLEM DEFINITION
A manufacturing company named The Unshakeable manufactures two wheelers by purchasing the raw materials from different subcontractors and assembling them into a finished product. The type and number of the raw materials purchased and finished products are being maintained manually involving a lot of paper work and human effort. As the manufacturing company is becoming popular and expanding, the effort needed is also large which will result in wastage of man hours. So the company wishes to automate the management of stock. The system must maintain details of both the raw materials and the finished products. In case of raw materials, the following details have to be maintained: Two wheelers Name Model Number Name of the raw material Number of pieces purchased Subcontractor details Date of Purchase Cost of each piece In case of the finished products, the details that are to be maintained are: Two wheelers Name Model Number Buyer Name Date of Sale Cost The system should allow the company manager to view all these details. Whenever the raw materials are assembled into a single product, then there must be a proper balance ensuring that each raw material is decreased by one in number and the number of finished products of that type is updated by increasing it by one in number. Also any imbalance implies wastage thus the waste products should also be kept track of to maintain the correct balance. The manager should then update the number of raw materials and finished products in their respective tables. If some raw material goes less in number below the minimum value set for that raw material, then an alarm will be raised notifying the manager about the current status. This checking and notification has to be done once in 6 months. This system will be very useful in assessing the status of the company whether there is any profit or is it going in loss. Also by knowing the demand for raw materials, those raw materials that have been used large in number can be purchased during the next purchase and those raw materials that have been in less demand can be purchased less in number during the next purchase. The system that meets the above specified needs must be delivered in three months from now. Also a yearly report must be generated that will display all the details of both the raw materials purchased and the finished products.
PROJECT PLAN
1.0 INTRODUCTION: The purpose of this software is to automate the maintenance of stock of various raw materials and the finished products.
1.1 PROJECT SCOPE:
This software enables easy management of the stock of a company thus reducing the effort needed to maintain such records manually. Inputs: The various inputs to the system include: i. Name of the raw material / finished product ii. Number of pieces iii. Model number iv. Subcontractor / buyer details v. Date of purchase / sale vi. Cost of each piece vii. Login name viii. Password These details are entered by the manager in the forms respective to the raw materials and finished products. Once the required details are furnished, the details are updated correspondingly. Whenever the raw materials are assembled into a complete product, the raw materials are decreased in number and an increment is made in the number of finished products to maintain the balance. Outputs: The outputs from the system include: i. A yearly report that displays the details about the raw materials and the finished products that helps in analyzing the progress of the company throughout the year. ii. Displaying the current status, that is, the details pertaining to either raw materials or finished products option selected in the browser by the manager.
1.2 MAJOR SOFTWARE FUNCTIONS:
The functional decomposition of the software results in modules such as: i. Displaying details like the number and type of the raw materials and the finished products along with the subcontractor and buyer details. ii. Getting the details of the raw materials and finished products from the manager and updating them when there is a change.
iii.
Displaying a yearly report to the manager regarding the purchase and sale of the products by the company throughout the year.
Only one user will be using the system. Thus concurrent connection will not be an issue for implementation. Every time the manager wishes to view or edit details, he/she must use the correct user name and password.
1.4 MANAGEMENT AND TECHNICAL CONSTRAINTS:
The software must be flexible enough to implement any changes. It should be manageable and portable. The software should be portable and not accessible to unauthorized people. It should not occupy more than 1 GB space. 2.0 PROJECT ESTIMATES: The effort, time and cost needed to build the software can be estimated by a number of techniques.
2.1 HISTORICAL DATA USED FOR ESTIMATES:
The estimates of other such currently used automated maintenance systems can be used to estimate effort, cost and time for the system under development.
2.2 ESIMATION TECHNIQUES APPLIED AND RESULTS: 2.2.1
Estimation Techniques: Technique 1: The COnstructive Cost Model (COCOMO) can be used in estimating the development effort and the time schedule for the software and this is based on the Lines Of Code (LOC). Effort = 2.4 * (KDLOC ^ 1.05) for organic systems where KDLOC = Thousands of Delivered Lines Of Code. Since the software is concerned with data processing, the system is said to be an organic system. Also the Development Time Schedule, M (expressed in months) is given by, M= 2.5 * (Effort ^ 0.38) Technique 2: The cost involved in developing the software is given as, Cost = ((Number of persons) * (Number of months) * (Pay for each person per month)) Estimate for Techniques: Technique 1: For the software under consideration, the Lines Of Code (LOC) for different modules are: User Interface Module 400
2.2.2
(Login, displaying raw material and finished product details, forms to get details, report) Database Handling Module (Checking login, storing raw material and product details) Updation Module Total LOC Effort = = = = = = = = 500
250
2.4 * (1.15)1.05 2.77 3 person months 2.5 * (2)0.38 3.25 3 months Effort/M 3/3 1
The cost for developing the software considered is Cost = 1 * 3 * (Rs. 30,000) = Rs. 90,000
2.3 RECONCILED ESTIMATE:
The final estimation of effort, time and cost for developing the project undertaken can be fixes to be, Effort = 3 person-months Time = 3 months Cost = Rs. 90,000
2.4 PROJECT RESOURCES:
i. ii. iii.
People: To develop this software in 3 months time, one person is sufficient. Hardware: 4 GB Hard Disk, 256 MB RAM, 133 MHz processor. Software:
iv.
Windows 98 or any higher version, Visual Basic 6.0 (VB) and Microsoft Access. Tools: Rational Rose, Win Runner.
a. Project Complexity: Lack of identifying the modules and functions in detail. b. Lack of involvement: Lack of customers full involvement in the definition of requirements and their commitment to the project. c. Staffs inexperience: Risks associated with the technical and project inexperience of the staff who are involved in the development of the software. d. Schedule risks: The degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time.
3.2 RISK TABLE: NAME OF RISKS PROBABILITY (%) IMPACT
Project Complexity Lack of involvement Staffs inexperience Schedule Risks Impact Values: 1 2 3 4 -
40 45 35 45
2 3 1 2
RMMM documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan. Risk mitigation is a problem avoidance activity. Risk monitoring attempts to allocate the origin of risks. Risk management assumes that the mitigation efforts have failed and that the risk has become a reality. These RMMM steps incur additional costs. 4.0 PROJECT SCHEDULE:
To develop the software under consideration, The Linear Sequential Model also known as Waterfall Model can be used. It includes the following major activities: a. Analysis and Planning: By effectively analyzing the problem domain and the requirements, an overall plan for the project is created. b. Design: The requirements analyzed are translated into a representation of the software that includes data structure, software architecture, interface representations and procedural detail. c. Implementation Of Code: The detailed design is then translated into a machine readable form. d. Testing and Maintenance: The code is generated is tested logically and the results are analyzed and errors are uncovered. The software must also be maintainable over its lifetime with the changing requirements. 4.2 FUNCTIONAL DECOMPOSITION: The entire team can be divided into 4 major teams: a. Planning b. Design c. Code Implementation d. Testing Initially the problem domain is analyzed after which a proper plan is developed. Based on this overall plan, a good quality design is made by the design group. Then the actual implementation is done after which the software is put for testing.
4.3 TASK NETWORK:
The various activities and the dependencies among them can be represented diagrammatically as: Planning Design Coding Testing
feedback
4.4 TIMELINE CHART:
A timeline chart also known as Gantt chart depicts the software project schedule, with the project tasks listed in the left hand column.
Work Tasks Month1 1) a.Analysis b.Planning 2) Design 3)Code Implementation 4) a.Testing b.Maintenance 5.0 STAFF ORGANISATION:
5.1 TEAM STRUCTURE:
Months Month2
Month3
The project team has one project manager who controls and coordinates the various teams each with a team leader throughout the definition, development and support of the software under consideration. The project manager communicates with the business analyst.
TEAM STRUCTURE
Business Analyst
Project Manager
Team 1 (Leader)
Team 2 (Leader)
M1
M2
M1
M2 M - Team Members
There will be regular meetings held among the teams and also within the teams. The team members should report their progress to their respective team leaders and the team leaders in turn to the project manager. 6.0 TRACKING AND CONTROL MECHANISM:
6.1 QUALITY ASSURANCE AND CONTROL:
Quality must be ensured at each and every level. It can be done by ensuring Conformance to specifications Tight change management. Close contact with clients
6.2 CHANGE MANAGEMENT AND CONTROL:
Any changes to be made to the software can be controlled and managed by Deciding the right person to access and modify particular objects Making sure that the changes suggested by one member are approved by all other members All version changes must be documented in a common document accessible to all team members before a new version is released
1. LOGIN:
1.1 BRIEF DESCRIPTION:
This use case allows the manager to login in order to view or edit the details of the raw materials purchased and the finished products that were sold.
1.2 FLOW OF EVENTS:
1.2.1 BASIC FLOW:
The manager has to enter the correct login name and the password to login to know about the raw materials and finished products. 1.2.2
ALTERNATE FLOWS:
If an incorrect login name or password is entered then the manager has to be notified by the system about it.
1.3 SPECIAL REQUIREMENTS:
None
1.4 PRE CONDITIONS:
The user must know the correct the login name and password.
1.5 POST-CONDITIONS:
If this use case was successful, the user will be successfully logged on. 1.6 EXTENSION POINTS: None 2. VIEW RAW MATERIALS AND FINISHED PRODUCTS DETAILS:
2.1 BRIEF DESCRIPTION:
This allows the manager to view the details about the raw materials purchased long with the respective subcontractor details and also the details about the finished products along with the buyer details.
2.2 FLOW OF EVENTS:
2.2.1 BASIC FLOW: 2.2.1.1 Raw Material
details: This use case starts when the user wishes to know the details about various raw materials like the name, model number of the vehicle in which it is going to be used, the subcontractor details, date of purchase and the cost of each piece.
2.2.1.2
This enables the manager to view the details about the finished products like name, model number, the buyer details, date of sale and the cost when that option is selected in the browser. 2.2.2
ALTERNATE FLOWS:
None
2.3 SPECIAL REQUIREMENTS:
None
2.4 PRE CONDITIONS:
In order to view the details, the user should choose the corresponding option in the browser.
2.5 POST-CONDITIONS:
If this use case was successful, then the manager can view the details corresponding to the option chosen. 2.6 EXTENSION POINTS: None 3. PURCHASE RAW MATERIALS:
3.1 BRIEF DESCRIPTION:
This use case allows the manager to purchase raw materials and update the details in the database by filling up a form.
3.2 FLOW OF EVENTS:
3.2.1 BASIC FLOW:
This use case starts when the manager wishes to enter the details about the raw materials purchased from a subcontractor. These details should be entered in a form and they include: 3.2.2 Name of the raw material Model Number Subcontractor details Date of purchase Cost of each piece
ALTERNATE FLOWS:
Invalid input details: If the input details are not within the valid range, then the user will be notified about the invalidity and will be prompted to fill up the form again.
3.2.2.1
None
3.4 PRE - CONDITIONS:
The user must input all the details that are required in the form within the valid range.
3.5 POST-CONDITIONS:
If this use case was successful then the details will be updated as entered by the manager. 3.6 EXTENSION POINTS: None 4. CONSUME RAW MATERIALS:
4.1 BRIEF DESCRIPTION:
This use case is used to update the number of raw materials after they are assembled to form a complete product.
4.2 FLOW OF EVENTS:
4.2.1 BASIC FLOW:
This use case starts when the raw materials are assembled into a single product and the details are updated in the database. This helps in maintaining a balance in the number of raw materials purchased and consumed. 4.2.2
ALTERNATE FLOWS:
If the updation is not made then the details maintained for each raw material will be incorrect which will have effects later.
4.3 SPECIAL REQUIREMENTS:
None
4.4 PRE CONDITIONS:
The user must have made knowledge about the raw materials that are consumed.
4.5 POST-CONDITIONS:
If this use case was successful, then the details will be updated which will enable to keep track of the number and type of raw materials that are currently in stock. 4.6 EXTENSION POINTS: None
This use case is used to keep track of the finished products obtained after assembling the raw materials together.
5.2 FLOW OF EVENTS:
5.2.1 BASIC FLOW:
This use case starts when the raw materials have been assembled together as a complete product and is sold to the customer. The details of the buyer along with the date of sale are stored. 5.2.2
ALTERNATE FLOWS:
If the updation is not made then there will be an imbalance in the number of raw materials purchased and that were consumed.
5.3 SPECIAL REQUIREMENTS:
None
5.4 PRE CONDITIONS:
The user must have knowledge about the product that was sold and also the buyer of that product.
5.5 POST-CONDITIONS:
If this use case was successful, then the details about the finished products will be maintained which will enable to keep track of the finished products that were produced and sold. 5.6 EXTENSION POINTS: None 6. GENERATE REPORT:
6.1 BRIEF DESCRIPTION:
This use case is used to generate a report about the overall performance of the company throughout the year.
6.2 FLOW OF EVENTS:
6.2.1 BASIC FLOW:
This use case starts when the manager wishes to assess the companys performance during that year. It also helps the manager to know which raw materials have been in more demand and which have been in less demand. Accordingly the number of raw materials can be purchased the next time.
6.2.2
ALTERNATE FLOWS:
None
6.3 SPECIAL REQUIREMENTS:
None
6.4 PRE CONDITIONS:
If this use case was successful, then the company manager can visualize and analyze the performance of the company throughout the year. This also helps to get an idea whether the company is making profit or is going in loss. 6.6 EXTENSION POINTS: None
Login
Generate Report
CLASS DIAGRAM
Manager login_name : string password : string 1 * FinishedProducts name : string model_no : integer buyer : string cost : integer date_of_sale : date sell() * 1 login() view_details() edit_details() view_report() 1 1 * RawMaterials name : string model_no : integer subcontractor : string no_of_pieces : integer date_of_purchase : date cost : integer purchase() consume() * 1