Bsit-4207.weebly.com
CHAPTER 1.0 – PROJECT CHARTER
1 PROJECT BACKGROUND
Product management is the process of collecting and using data on the products that a business or organization sells, handles or makes. This type of analysis can be applied to finished products, product components, raw materials or items in any part of a supply chain. Business and nonprofit users can use product management to benefit from more knowledge about their internal processes.
In terms of its common use, product management is often a single component of a more comprehensive process called customer relationship management, a process that involves collecting and using data about an enterprise's customers. Businesses and organizations use customer relationship management solutions and resources to improve customer service systems, sales methods or any other goal related to customer interaction. Within these sorts of services, solutions and software packages, a product management solution will focus on how to use data about products for the benefit of the enterprise.
Many different types of data get recorded by a product management resource or tool. For example, details on product versions, the dates of intake or production, product weights and dimensions, and other physical or chronological information can be put into a database for use by top management. Those in leadership positions can use the information to continuous inventory, make a supply chain more efficient, or to give authority to the sales staff.
Stock control, otherwise known as inventory control, is used to show how much stock you have at any one time, and how you keep track of it.
It applies to every item you use to produce a product or service, from raw materials to finished goods. It covers stock at every stage of the production process, from purchase and delivery to using and re-ordering the stock.
Efficient stock control allows you to have the right amount of stock in the right place at the right time. It ensures that capital is stable not tied up unnecessarily, and protects production if problems arise with the supply chain.
1. Problem / Opportunity Description
There are number of problems that can cause destruction with inventory management. Some happen more frequently than others. Here are some of the common problems with inventory systems.
• Too much distressed stock in inventory
Distressed stock is products or materials in inventory that has or will soon pass the point where it can be sold at the normal price before it expires. This happens all the time in grocery stores. As a particular food product nears its expiration date, the business will discount the item in order to move it quickly before it expires.
• Excessive inventory in stock and unable to move it quickly enough
If a company buys an amount of product for their inventory and they do not move it, the company ends up losing money.
• Items in-stock is misplaced
Even if the computer accurately shows the item as in stock, it may have been misplaced somewhere at the warehouse, or in the wrong location within a store. This can lead to a decrease in profits due to lost sales and higher inventory costs because the item must be re-ordered. Plus, the company must spend the time for employees to track down the misplaced item.
1 Benefits
Product Management with Store Inventory Control Module (PMSICM) is a computer-based system of tracking inventory levels, orders, sales and deliveries. Companies use this system to avoid product overstock and outages. It is a tool for organizing inventory data that before was generally stored in hard-copy form or in spreadsheets.
• Cost saving
PMSICM helps companies keep lost sales to a minimum by having enough stock on hand to meet demand.
• Increased efficiency
PMSICM often allows for automation of many inventory-related tasks. For example, system can automatically collect data, conduct calculations, and create records. This not only results in time savings, cost savings, but also increases business efficiency.
• Updated data
Administrator, Store Manager and Merchandiser can usually access the system through a mobile device, laptop or PC to check current inventory numbers. This automatic updating of inventory records allows businesses to make informed decisions.
• Data security
With the aid of restricted user rights, company managers can allow many employees to assist in inventory management. They can grant employees enough information access to receive products, make orders, transfer products and do other tasks without compromising company security. This can speed up the PMSICM process and save managers’ time.
• Insight into trends
Tracking where products are stocked, which suppliers they come from, and the length of time they are stored is made possible with PMSICM. By analyzing such data, companies can control inventory levels and maximize the use of warehouse space.
2. Goals
Ensuring Safety of Inventory
One of the goals of PMSICM is to keep products safe. The inventory should be handled carefully, as well, to avoid breakage. Broken or lost inventory means a financial loss for the company.
Tracking Sales
Note the items that don’t sell and have a tendency to sit for prolonged periods of time. Also, track the best sellers and seasonal items that experience increased sales at different times of the year. Use this data to manage the quantity of items and when to order them.
Ensuring Accuracy of Inventory Systems
A goal of PMSICM should be to keep the inventory database up to date. Each item sold should be removed from the inventory log promptly.
Eliminating Excess Products
PMSICM also will keep dead stock off of the shelves, stock that does not sell and takes up space in your store or warehouse. Promotion can be used to push stock that has not been performing well. Another strategy would be to return stock that is not selling or offer the products at a discounted rate.
3. Stakeholders and Clients
This study will give specific contributions to the following:
|Stakeholders |Description / Participation |
|Proponents |The proponents may apply their knowledge in making an |
| |effective inventory system, and their knowledge in database |
| |making and design. |
|Client |They will benefit for the outputs of the proposed inventory |
| |system. |
|Manager |Oversee one or more employees, divisions, or volunteers to |
| |ensure that they carry out certain duties or meet specific |
| |group goals. |
|End Users |The proponents will provide them a simple yet effective system|
| |that is easy for them to understand and operate. |
|Employer |It would help lessen paper works for the employers and |
| |decrease human errors. |
|Students / Future Researcher |It would help students by guiding them what should an |
| |inventory system would look like. It would be a good reference|
| |for the students for future study. |
Table No. 1 – Stakeholders and Clients
2. PROJECT SCOPE
1. Objectives
|Project Objective |Work Products / Description |
|To minimize the time spent in taking inventory. |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. |
|To provide an interface that can give the exact |To display direction and the exact location of the product to the user. |
|location of a product. | |
|To generate accurate reports. |Lists all data associated with a part including pricing, product type, |
| |current quantities, detailed transaction history, stock control |
| |averaging formulas with minimum, order point and maximum. |
Table No. 2 – Objectives
1 Deliverables
Objective 1: To minimize the time spent in taking Inventory.
|Project Deliverable |Work Products / Description |
|*Computerized Inventory System |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. |
Table No. 3 – Objective 1
Objective 2: To provide an interface that can give the exact location of a product.
|Project Deliverable |Work Products / Description |
|*Store Map |*Maps can display directions for the user. |
Table No. 4 – Objective 2
Objective 3: To generate accurate report.
|Project Deliverable |Work Products / Description |
|*Reports |*INVENTORY MASTER LISTING - lists all data associated with a part including |
| |pricing, product type, current quantities, and detailed transaction history, |
| |stock control averaging formulas with minimum, order level and maximum. |
| |*STOCKING REPORTS - list the current Quantity On Hand, Available, and On Order,|
| |along with the Minimum, Order point, and |
| |Maximum stocking level and suggested Reorder Quantity. |
| |*REORDER REPORT - lists only those items which have fallen below their order |
| |point. |
Table No. 5 – Objective 3
2 Out of Scope
• Sales Monitoring, Warehousing and Price Management
The system will not cover the Sales Monitoring, Price Management and Warehousing because other modules will handles it.
1.2.4 Enterprise Information System Required Functionalities:
• Mobile Apps
• Free Format Query
• Personalized Screen
• Import Export
• Analytical Reports
10 PROJECT PLAN
1. Approach and Methodology
1.3.1.1 Approach
Developing huge and critical software is not a very easy task. It requires expertise, skills, resources and experience to take up and successfully complete a proper business software development project. As a client you should be very careful while choosing the software development company for your project. It is very important that you partner with the right development company in order to receive the most suitable and effective solution.
1.3.1.2 Methodology
For the completion of the proposed system, the proponents used Waterfall model.
The waterfall model is one of the oldest and most basic software development methodologies which is still followed (mostly in its various modernized versions) by many software development companies while developing software solutions.
The waterfall model is a linear process where a sequential methodology is followed and the project progress is monitored and measured according to the completion of each phase. Every software development company has a particular strategy of developing software solutions and clients should know about these SDLC models in order to choose the one that best suits their requirements.
The waterfall model consists of following phases:
• Requirements specification
The very first step in the waterfall model starts with requirement analysis and checking whether the project is actually feasible with the present technologies or not. Requirements are gathered, analyzed and then proper documentation is prepared which helps further in the development process.
• Design
The requirements gathered in the above phase are evaluated and a proper implementation strategy is formulated according to the software environment. The design phase is further categorized into two sections, i.e. system design and component design. The system design contains details and specifications of the whole system and explains how each component of the system will interact with others. The component design contains specifications as to how each component will work separately and how results from one component will travel to another. Individual coders are usually assigned to develop each component.
• Implementation
Now is the time to actually start creating the components. The information gathered in the first two phases is applied in this step to create the actual working parts of the system. The design generated in the above phase is converted into machine language that the computers can actually understand and process.
• Testing
The testing phase is where the software is checked for any errors or discrepancies. The testing of the software actually starts after the code is finished which is usually in the ending stages of implementation phase. Various different tools, software and strategies are used for testing the solution in order to make sure that it is error free.
• Installation
Once software is tested it needs to be assembled as a whole system and installed on the computer or required device. The installation phase should go smoothly if the above steps have been carefully completed.
• Maintenance
Maintenance is an ongoing process which may stretch from a few months to many years. It is a fact that all software has bugs no matter how cautiously it has been developed and tested. Furthermore, with the passage of time, requirements will also change and modifications or additions will be required to keep it effective. All this work comes under the umbrella term - maintenance.
2. Project Timeline
|ID |Task Name |Start |Finish |Duration |
|1 |Planning: |June 20, 2014 |July 08, 2014 |5 days |
| |*Schedule initial visit to user site. | | | |
| |*Gather and read background materials. | | | |
| |*Establish data gathering objectives. | | | |
| |*Determine what data gathering | | | |
| |techniques to use. | | | |
| |*Identify contact person. | | | |
| |*Schedule data gathering activities. | | | |
| |*Assign to data gathering teams. | | | |
| |*Identify deliverables. | | | |
|2 |Analysis: |July 14, 2014 |July 26, 2014 |12 days |
| |*Analyze the problem of the existing | | | |
| |system. | | | |
| |*What will be the solution to that | | | |
| |problem? | | | |
|3 |Design: |July 28, 2014 |Aug. 16, 2014 |3 weeks |
| |*Identify the software modules and | | | |
| |interfaces. | | | |
| |*To present a detailed description of | | | |
| |the database schema needed to support | | | |
| |the high-level and detailed design. | | | |
|4 |Implementation: |Aug. 18, 2014 |Nov. 29, 2014 |3 months |
| |*Transformation of the high-level design| | | |
| |into an executable codes. | | | |
| |*Developing codes according to the | | | |
| |coding standards. | | | |
|5 |Maintenance: |Dec. 01, 2014 |March 28, 2014 |4 months |
| |*Improving some features to the proposed| | | |
| |system. | | | |
| |*To fix the discovered bugs and errors. | | | |
| |*To fix the system when it cause | | | |
| |malfunctions. | | | |
Table No. 6 – Project Timeline
3. Success Criteria
The project is considered successful if:
• The system meets the standard requirement of a business process.
• The system is well integrated with the other sub-systems.
• The system is fully functional.
• The system generates suitable report for specific action.
• The system provides quality service for the users.
4. Issues and Policy Implications
A good integration is needed to have a fully functional system but one of the issues of a whole system is the dependency of a sub-system to the other sub-system, one cannot begin or be-completed until one or more other conditions, events, or tasks have occurred, begun, or completed. If the first module sends a wrong data the other will send it to the other and the process will continue until the data is saved to the systems database. Wrong data transfer poses a serious issue for companies, as the number of incidents and the cost to businesses continues to increase.
5. Risk Management Plan
|Risk Factor |Probability (H-M-L) |Impact (H-M-L) |Risk Management Action |
|Lack of Knowledge in Software Development |M |M |Make further research on Software Development |
|Process. | | |Process. |
| | | | |
|Less experience working with a client |L |L |Always monitor the quality of communication |
| | | |with the client. |
| | | | |
|Can’t determine what would be the exact |H |H |Re-estimate the project size based on the |
|size of the Project. | | |evaluations that have been done. |
| | | | |
|Availability of the Members |M |M |Give the members a task that can be done at |
| | | |home. |
| | | | |
|Lack of materials |H |H |Rent or borrow materials that can be essential|
| | | |for the project |
|Financial Risk |M |M |Save some funds that the members can use for |
| | | |the continuation of the project |
|Corrupted file/s |H |H |Back-up files to other Flash disks or PC's & |
| | | |laptops |
| | | |Study the integration process of whole system |
|System is not well integrated with other |H |H | |
|modules | | | |
| |M |M |Auxiliary gas-driven power generators are a |
| | | |good back-up system to provide electrical |
|Power outage | | |energy for lighting. |
Table No. 7 – Risk Management Plan
6. Service Transition
• Training of Employees involve in using the system.
• There will be a support center that will cater the needs of employees
• Providing service maintenance on the system.
7. Option Analysis
Taking into account legal, economic, technological, scheduling and other factors is the ability to complete a project successfully. Rather than just diving into a project and hoping for the best, a good planning allows project managers to investigate the possible negative and positive outcomes of a project before investing too much time and money.
• In terms of system integration, the project team will be on the guard for any adjustment and revision that will be needed by the whole Merchandising system.
• In terms of the budget, the whole team will stick in the budget of the project however if there are unexpected necessities for the project, the team will produce the needed money to support the necessities.
• The team’s thoughts about the software and the technical support of the development of the project is that the software that will be needed should be licensed and for the technical support that team will have their own gadget or laptops that is needed for the development.
3. TECHNICAL FEATURES
Hardware Specifications
• Processor type
➢ Core i3 - Compatible processor or higher
• Processor speed
➢ Minimum: 1 GHz
➢ Recommended: 2.27 GHz or higher
• Memory
➢ Minimum: 1 GB
➢ Recommended: 2 GB or more
➢ Maximum: Operating system maximum
Software Specifications
• Operating System
➢ Windows7 64-bit / Windows8 64-bit
• Programming Language
➢ NetBeans Platform (V.8) is a generic framework for Swing applications. It provides the "plumbing" that, before, every developer had to write themselves—saving state, connecting actions to menu items, toolbar items and keyboard shortcuts; window management, and so on. It provides all of these out of the box. You don't need to manually code these or other basic features.
• Database
➢ MsSql (Microsoft SQL Server 2005) is an open source relational database management system. It is based on the structure query language (SQL), which is used for adding, removing, and modifying information in the database. Standard SQL commands, such as ADD, DROP, INSERT, and UPDATE can be used with MsSQL.
Hardware Features
• Terminals – is an electronic device that manipulates information, or data. It has the ability to store, retrieve, and process data. It can use to type documents, send email, and browse the Web. It can also use to handle spreadsheets, accounting, database management, presentations, and more.
• Printers – use for printing documents, reports, scanning and as a copy and fax machine.
Special Features
• Computer Security – Techniques developed to safeguard information and information system stored on computers.
• Reports – Get a full history of any inventory or adjustments to track down any problems and to get detailed information like best selling products on back order, and how long your inventory will last.
4. PROJECT ORGANIZATIONS AND STAFFING
|ROLE |NAME & CONTACT INFORMATION |RESPONSIBILITIES |TIME |
|Project Manager |Gabales, Dannisa |Define tasks and deliver on time. Undertake risk management. | |
| | |Demonstrate high level of communication skills. Produce | |
| | |management project reports, including project evaluation and | |
| | |project closure. | |
|Lead Programmer |Macalalad, Lloyd |Is a software engineer in charge of one or more software | |
| | |projects. Alternative titles include Development Lead, | |
| | |Technical Lead, Senior Software Engineer, Software Design | |
| | |Engineer Lead, Software Manager, or Senior Applications | |
| | |Developer. | |
|System Analyst |Flores, Rommel |Who specializes in analyzing, designing and | |
| | |implementing information systems. System analysts assess the | |
| | |suitability of information systems in terms of their intended | |
| | |outcomes and liaise with end users, software vendors and | |
| | |programmers in order to achieve these outcomes. | |
|Business Analyst |Cadiente, Ian Pauline |A bridge between the business problems and the technology | |
| | |solutions who analyze, transform and ultimately resolve the | |
| | |business problems with the help of technology. | |
|Document Specialist |Beo, Jerralyn |Revise and re-write all documents prepared by self and staff | |
| | |relating to procedures and reporting of programs. Coordinate | |
| | |with staff, vendors and technical specialists to decide upon | |
| | |material and graphics for documents. Assist in production | |
| | |process and contribute towards reviewing and updating content | |
| | |and packaging of published documents. | |
|PEC | |They are responsible in implementing rules and regulations of | |
|(Project Evaluation | |project making and a board that checks the proposed system. | |
|Committee) | | | |
|Adviser |Sir. Billy Joel Tierra |Inspire, support, and challenge the group to reach the highest| |
| | |level of success. | |
Table No. 8 – Project Organization and Staffing
5. PROJECT BUDGET
|Budget Item |Description |Budgeted Cost |
|One-Time Cost |
|One-time Item 1 |Terminal – 10, 000.00 x 5 | |
| | |50,000.00 |
|One-time Item 2 |Printer – 1,000.00 x 5 | |
| | |5,000.00 |
|One-time Item 3 |Cable Wires |1,000.00 |
|One-time Item 4 |Server |1,000,000.00 |
|Total One-Time Costs | |
| |1,056,000.00 |
|Ongoing Cost |
|Utilities Expense |*Electricity – 3,000.00 x 10 |30,000.00 |
| |*Water – 3,000.00 x 10 |30,000.00 |
| |*Telephone – 1,000.00 x 10 |10,000.00 |
| |*Internet – 1,000.00 x 10 |10,000.00 |
|HR |*PM – 50,000.00 x 10 |500,000.00 |
| |*SA – 40,000.00 x 10 |400,000.00 |
| |*LP – 18,000.00 x 5 |90,000.00 |
| |*DBA – 35,000.00 x 5 |175,000.00 |
| |*2 NA – 100,000.00 x 2 |200,000.00 |
|Total Ongoing Costs | |
| |1,445,000.00 |
Table No. 9 – Project Budget Table
CHAPTER 2.0 - RELATED STUDIES AND SYSTEMS
Introduction
This chapter deals with the different literature and studies base on different sources such as books, magazine, newspaper and internet. The related studies is written based on the needed information related to the system to provide the better understanding how Product Management with Store Inventory Control works and give a brief theoretical background.
2.1 Foreign Studies
Silver Net Inventory System 1.0
Web based multi warehouse inventory system integrated with online store. This system allows user and customers to see the data they need in real time anywhere. All they need is an internet connection. Silver Net Inventory will help the management of business including receiving and shipping of products, sales, and payments. Silver Net Inventory System is a complete web based inventory management system that performs the functions of Purchases, Sales and payments. This system will guide through the creation of vendors list, purchase orders, products list, receiving lists, sales orders, invoices, sales and payment receipts. This is in addition to transfer orders between locations, customers and vendors balances and various types of reports for monitoring the business.
[pic]
• MAX-OR Scheduling Software
Offers a complete inventory table (part of the inventory components) that includes inventory management by location, purchase order system, order receiving and inventory count. The inventory system depletes inventory when consumed during a procedure, tracks costs on inventory and even supports bar codes.
[pic]
MyHome Inventory System
This is a complete inventory management system performs multi warehouse stock control. System has receiving and shipping functions, generates invoices, sale receipt. Export and import functions
[pic]
• OWL Software
A complete sales management system that includes: invoicing, inventory management, automated billing, mailing list management, customer management and sales tracking. Invoices and bills can be printed on plain paper or emailed directly to customers. Program features an intuitive interface with pick lists and menus that minimize typing and maxamize productivity. Includes extensive reporting for sales, tax, inventory and customer analysis. OWL Software is easy to use accounting, invoicing and investment management software.
[pic]
• EZ Inventory
The Inventory & Purchasing module of EZ Maintenance software allows to track and control all inventory, including minimum and maximum reorder points, inventory levels, inventory tracking, purchase orders, requests for quotes, vendors and much more. The Inventory & Purchasing module is designed so that materials and parts used to complete work orders are automatically deducted from inventory levels if choose to allow such deduction. The Inventory module is also designed to allow an operator of EZ Maintenance to issue a purchase order for more materials or parts directly from the work order screen if needed. In order for the Inventory & Purchasing module of EZ Maintenance fleet maintenance software to function, basic information must be entered first.
[pic]
2.2 Local Studies
• Material and Spare Parts Acquisition and Inventory Control System
Capiz Sugar Central, Inc.
Capiz, Philippines
The Material and Spare Parts Acquisition and Inventory Control System was developed for Capiz Sugar Central, Inc. of Capiz, Philippines. Capiz is the second-largest sugar cane miller in this region with over 420 employees, and this application is used by all of their office personnel.
This application processes a variety of different business transactions, including: Requests to Purchase (RTP), Quotations, Budget Checking, Purchase Orders, Receiving Reports, Accounts Payable, and Stock Requisition Slips. It also handles all Warehouse Issue Requests (WIR) in dynamic real-time. The Inventory Control System has a paperless validation and approval schema and the inventory counts are maintained in master files and can be traced back to item-by-user departments.
When an employee requests material, he logs into the program and checks availability through the Inventory master control. From there, the employee opens a new Request to Purchase and adds additional materials if needed. Once the request is initiated, the application automatically selects the recommended canvasser, warehouseman, purchaser, budget officer, controller, and final approving officer. It also auto-populates the current date, delivery date, and requesting department. Additionally, the application filters all materials associated with the user and any items that are common to all departments.
Once the RTP is initiated, only the requester can edit a recommendation prior to its approval. From this point, the document is ready for the second approval, prompting an activation button to appear in the RTP. Once approved by the overseeing officer, the button disappears and the RTP continues to the next officer until final sign-off is obtained. All completed documents are available for viewing and sorted according to user, department, and user role. Upon final sign-off, a purchase order is created through the system. The application only allows this transaction to occur once the RTP has been approved. Similar to the RTP process, additional modules follow the same security protocol, though to a lesser degree.
If the user finds sufficient materials in stock, he can logon to the Stock Requisition Slip (SRS) portion of the application and initiate processing; the requested materials are filtered through a dropdown list based on dynamic allotment by department. This is determined the department's inventory and usage.
Application size and scope
The application uses one Microsoft SQL 2000 database with over 30 tables. There are over 86 web pages accessed by 100 users who process approximately 2,000 transactions per month. The largest database table is the Inventory table, containing approximately 5,000 records at the time of this writing. The RTP master and detail tables are also about 5,000 records, and the number of records in these tables will likely double each year.
The project
The Request to Purchase and Purchase Order modules were implemented in about 60 person-days over three months.
Code extensions and customizations
The major customizations include:
• Password security.
• Custom saving routine for complete control of administrative processes.
• Dropdown list customizations. 90% of the dropdown boxes were customized to include filters based on planned sources within the table panels. The new fields incorporate a dropdown list loaded with the filtered data, while the existing fields remain hidden without the large list selector control. This value is replaced with literals in the form of show fields.
• Validation tags.
• Email workflows.
▪ Custom stored procedures.
▪ Duplicate entry detection.
Layout customizations
The page layout modified minimally in order to increase visibility, making the data easier to understand. These customizations included:
• Reducing page size.
• Removing redundant built-in buttons.
• Increasing the number of columns on a page.
• Altering several display types.
• Incorporating custom buttons.
• Integrating an export-to-PDF button.
About the developer
Jaime Jegonia
IT Consultant and Owner JimiTron Software
• A Chemical Engineer by training and a .NET web developer by avocation. His passion for development has transformed him into an Information Technology Consultant and owner of JimiTron Software.
• Holds a degree in Chemical Engineering from the University of San Agustin of Iloilo City, Philippines.
[pic]
• Inventory Plus
Benefits of inventory management system
Inventory is the most effective system of controlling the effectiveness of growing the business and also controlling the complex and hard jobs. This really is lately computerized system to use the system and monitor the sales and profits and also small business dealings and many items. It can be utilized mostly for various providers for industrial reasons. This is most recent online software to look for the records and also databases to handle the records and also files.
This kind of difficulties cost a lot of time and effort to discover and proper whenever staff could be better used doing other, much more effective chores. They can cause several hours of aggravation and extra work as you or even your staffs looks for the errors.
Just lately, Inventory Management System is extremely most recent computerized system useful for storing the software to calculate the different accurate databases. This is very well-known computerized system to keep the records and also control all sorts of business actions. This particular computerized system is extremely latest to maintain the whole details of internet business; therefore it can ensure that you should have great knowledge about the inventory procedure. As a result, business people measure the prime guidelines for the effectiveness of your business via inventory management options.
Right now, all duties of managing the business actions are extremely difficult, but also these types of tasks are extremely complex and complicated, for this specific purpose you should have great understanding of the business inventory. For this specific purpose, we need to utilize the latest computerized system that can shop the whole database to do the business activities. Thus, we utilize computerized system to store the entire database and relevant info. This is latest computerized system to store the data totally.
When you wish to maintain the information and also store the database, then you need to handle the business completely. This is very great way to utilize the inventory in unique methods. How do you keep up with the inventory records and business inventory? Inventory Management System for this specific purpose, you need to understand different types of functions of the main supply. So, you should utilize latest strategies to maintain a few essential particulars in the mind. Thus, it's playing an important role to handle the business activities effectively.
The inventory management system is extremely necessary to make common entry of the business. This technique is extremely required to software program and also hardware to keep track of every item in the production lines. This is very necessary to maintain all the tracks of whole supply management system. This really is a lot computerized system to be useful for keeping the data and also calculate the correct database. It can supervise your provide chain and also lessen the price sustained on computerized system. As a result, it can be useful for keeping the data and managing the records totally. Order Management is extremely important tool to perform the various kinds of business accounting activities like balance bedding, stock and also inventory management software methods to business people.
The benefits of a great inventory management system are usually many. That can be done without count teams as the job can simply be done with one person armed using a hand-held scanner. The actual count is actually joined onto the numeric keyboard and also the device can then be connected to your computer and also the counts downloaded rapidly, thus saving the requirement for manual input.
Jinisys is a world most leading software company who provides the inventory management software. In the following is given the main features of this outstanding software.
Main Features:
• Restocking (Adding items to Resto Plus)
• Remove Stocks, Stock Request from the warehouse, Good Receipt (List of Suppliers and supplied items), Inventory Reports, Item Ledgers, Inventory Tracking for restaurant use, and Link to Resto+
[pic]
• IBM - Sterling Warehouse Management
IBM® Sterling Warehouse Management System (Sterling WMS) optimizes complex distribution networks by enabling central management of inventory, labor and processes across multiple warehouse facilities.
Sterling Warehouse Management System enables you to:
Manage inbound receiving processes
• Gain thorough global visibility into your inbound shipments and track received inventory against purchase orders (POs), advanced shipment notifications (ASNs) and blind receipts.
• Configure putaway execution as system directed or ad hoc product diversions for quality assurance, CubiScan® and other activities.
• Take advantage of cross-docking opportunities.
• Establish and measure labor standards and performance.
• Provide condition-based processing for returns management.
Coordinate wide-ranging order fulfillment processes
• Plan shipments to meet user-defined and economic shipping parameters.
• Configure shipment grouping, wave planning and release schedule processes.
• Support batch, order and item pick processes.
• Perform order pick tasks using paper, radio frequency (RF), material handling equipment (MHE) or voice technology.
• Provide integrated parcel shipping capabilities with full delivery service and option support for major carriers.
Manage and allocate inventory across warehouse locations
• Manage inventory centrally though a single global view across your distribution network.
• Optimize use of warehouse space and assets with true multi-tenant support.
• Enable advanced capabilities such as activity tracking and consigned inventory in all or selected warehouses in the network.
• Maintain your inventory accuracy with cycle and physical count.
• On-boards new warehouses and clients rapidly to help speed the implementation of startups and reduce total cost of ownership.
Respond rapidly to customer-specific, value-added services requests
• Create and manage work orders across facilities to satisfy customers' unique fulfillment requests based on demand or to stock in anticipation of demand.
• Track pre-pack and work order kits as unique inventory.
• Manage light manufacturing operations, as well as cross-facility and multi-step processes.
• Enhance visibility into costs associated with value-added services related to work orders.
• Generate more revenue from value-added service operations and capture labor and costs associated with work orders.
[pic]
• ACCTivate! Inventory & Warehouse management software
• Visibility
ACCTivate!'s dashboards have the information you want to see, organized how you want to see it.
From summaries to details, dashboards provide instant visibility throughout the warehouse and entire business and enable each user to organize and display their information in the way that makes the most sense to them.
• Multi-channel order management & fulfillment
ACCTivate!'s order management & fulfillment allows your business to capture, process, ship, track and service orders from multiple sales channels.
With seamless integration to major eCommerce web stores and eCommerce platforms, ACCTivate! brings all channels - online, offline, catalog - together into one system for fulfillment from one or multiple physical and/or virtual locations or warehouses.
• Barcoding
Barcoding brings speed, accuracy & efficiency and can transform how your business operates.
ACCTivate! supports leading barcoding hardware devices, scanners and printers and ACCTivate!'s barcoding is built on a flexible foundation that allows us to work with you to understand your specific environment, and then create a customized barcoding solution to meet your business needs, goals and budget.
• Workflow management
ACCTivate! workflow management enables businesses to monitor and manage common business processes to improve quality, consistency, visibility and efficiency.
Two frequent uses in the warehouse are work-in-progress (WIP) and order fulfillment, track the movement of items as they progress through the warehouse, with status changes visible in real-time to all ACCTivate! users.
[pic]
2.3 Synthesis and Relevance to the Study
Almost every business uses inventory as part of its business operations. Some companies buy inventory from others to resell while other companies make inventory called components to use in the creation of finished products. Whichever category a company falls under, inventory represents a significant capital investment for most businesses. It becomes imperative to know how much inventory a company owns in units and dollars to manage and optimize this capital investment. Inventory management systems perform these tracking and management functions
Efficiently tracking inventory is an imperative component to a small business successful operation. By having up-to-date data regarding all needed office supplies, raw manufacturing materials and merchandise for sale, an organization will drastically increase its bottom line. In addition to the money saved by not reordering unnecessary goods, an enterprise will be better positioned to services customers quickly, as well as navigate any unexpected changes in business, such as a supplier abruptly going out of business. Although many companies maintain this information manually, there are benefits to using a computerized inventory system.
|System |Features |
| |Web Based |Allow Customer to see |Tracks product |Can monitor the |
| |System |data in real time |location in store |expired products |
|1. Silver Net Inventory System | | | X | X |
|2. MAX-OR Scheduling Software | X | X | X | |
|3. MyHome Inventory System | X | X | X | |
|4. OWL Software | X | X | X | |
|5. EZ Inventory | X | X | X | |
|6. Material and Spareparts Acquisition and | X | X | X | |
|Inventory Control System | | | | |
|7. Inventory Plus | X | X | X | |
|8. IBM - Sterling Warehouse Management | X | X | X | |
|9. Activate Inventory and Warehouse | X | X | X | |
|10. Product Management with Store Inventory | X | | | |
|Control | | | | |
Table No. 10 – Synthesis and Relevance to the Study Table
CHAPTER 3 - EIS PROJECT MANAGEMENT AND DEVELOPMENT
1 RISK MITIGATION, MONITORING AND MANAGEMENT PLAN
1 Introduction
Product Management with Store Inventory Control is an inventory system which involve processing inventory transaction such as normal transaction recording, database updating, as well as stock checklist printing; product tracking which enables system user to check their inventory and generate record; customer information retrieving which keep tracks of user’s company customer records; supplier information which keep tracks of company raw materials suppliers; and report generating.
1. Scope and Intent of RMMM Activities
The goal of the risk mitigation, monitoring and management plan is to identify as many potential risks as possible. To help determine what the potential risks are. When all risks have been identified, they will then be evaluated to determine their probability of occurrence. Plans will then be made to avoid each risk, to track each risk to determine if it is more or less likely to occur, and to plan for those risks should occur.
It is the organization’s responsibility to perform risk mitigation, monitoring, and management in order to produce a quality product. The quicker the risks can be identified and avoided, the smaller the chances of having to face that particular risk’s consequence. The fewer consequences suffered as a result of good RMMM plan, the better the product and the smoother the development process.
2. Risk Management Organizational Role
Each member of the organization will undertake risk management. The development team will consistently be monitoring their progress and project status as to identify present and future risks as quickly and accurately as possible. With this said, the members who are not directly involved with the implementation of the product will also need to keep their eyes open for any possible risks that the development team did not spot. The responsibility of risk management falls on each member of the organization.
• Document specialist can help avoid the risk by double-checking if the document is match with the system.
• Lead Programmer can avoid risk by providing all necessary software information before the start of the project.
• Project Manager can avoid risks by creating risk management plan to define certain risk approaches.
• Business Analyst provide counsel and assistance regarding risk identification/assessment/analysis/handling.
2 Functional Data Description
The identified risks are analyzed to establish the project exposure for each risk and to determine which risk items are the most important ones to address. Risk exposure is defined as the product of the likelihood that the risk will occur and the magnitude of the consequences of its occurrence. In rare cases, the overall project risk exposure will be so high that the opportunities represented by the project really cannot be attained at a reasonable expense. In most cases, though, attacking the most significant of the risk items will maximize the project opportunity. While the initial risk analysis deals with those risks identified early in the project, more analysis may be needed as the project proceeds. In cases where a new risk is identified, that new risk is analyzed and its exposure compared to that risks already being handled. That new risk may or may not be addressed with a mitigation action, depending on the cost of that action and the ranking of this new risk against others already being handled.
3. Risk Table
The first step is to identify ‘all’ the risks. To do this fully needs two things, a fairly detailed working knowledge of the given organization plus an appreciation of likely vulnerability areas. The understanding of the of likely risk, can reasonably be done by external advisors, but the first part , the identification of the specific threats, is probably best done by internal or internal consultants. During the risk analysis, each risk is considered in turn and a judgment made about the probability and the seriousness of the risk. The risks are stated below and have been identified according to the type.
|Risk Factor |Probability (H-M-L) |Impact (H-M-L) |Risk Management Action |
|Lack of Knowledge in Software |M |M |Make further research on Software |
|Development Process. | | |Development Process. |
| | | | |
|Less experience working with a client|L |L |Always monitor the quality of |
| | | |communication with the client. |
| | | | |
|Can’t determine what would be the |H |H |Re-estimate the project size based on|
|exact size of the Project. | | |the evaluations that have been done. |
| | | | |
|Availability of the Members |M |M |Give the members a task that can be |
| | | |done at home. |
| | | | |
|Lack of materials |H |H |Rent or borrow materials that can be |
| | | |essential for the project |
|Financial Risk |M |M |Save some funds that the members can |
| | | |use for the continuation of the |
| | | |project |
|Corrupted file/s |H |H |Back-up files to other Flash disks or|
| | | |PC's & laptops |
| | | |Study the integration process of |
|System is not well integrated with |H |H |whole system |
|other modules | | | |
| |M |M |Auxiliary gas-driven power generators|
|Power outage | | |are a good back-up system to provide |
| | | |electrical energy for lighting. |
Table No. 11 – Risk Table
1. Description of Risk M
Business Impact Risk:
Risks associated with constraints imposed by management or the marketplace
Customer Risk:
Risks associated with sophistication of the customer and the developer's ability to communicate with the customer in a timely manner.
Development Risks:
Risks associated with availability and quality of the tools to be used to build the project.
Employee Risks:
Risks associated with overall technical and project experience of the software engineers who will do the work
Process Risks:
Risks associated with the degree to which the software process has been defined and is followed.
Product Size:
Risks associated with overall size of the software to be built.
Technology Risks:
Risks associated with complexity of the system to be built and the "newness" of the technology in the system.
2. Probability and Impact for Risk M
|Category |Risks |Probability |Impact |
|Development Risk |Corrupted Files - Hardware and Software |50% |1 |
| |malfunctions. Unexpected problems that will | | |
| |encounter during the making of the project. | | |
|Product Size |The size of the software is under estimated. |50% |3 |
|Process Risk |Financial Risk - Reviews may not be conducted |45% |2 |
| |regularly. | | |
|Business Impact |Availability of the Members - Skilled members |30% |3 |
| |and their availability are unavailable during | | |
| |the critical times in the project. | | |
|Technology Risk |Lack of Materials - Technology will not meet |25% |1 |
| |expectations. | | |
|Employee Risk |Lack of knowledge in software development |20% |2 |
| |process. | | |
|Customer Risk |Less experience working with a client. |10% |2 |
Table No. 12 – Probability and Impact for Risk M Table
Table – Risk Table (sorted)
Impact Values Description
1 Catastrophic
2 Critical
3 Marginal
3. Negligible
3 Risk Mitigation, Monitoring and Management
1. Risk Mitigation for Risk M
Mitigation is designed to reduce the probability that a risk will materialize. Normally you will only do this for High and Medium elements. You might want to mitigate low risk items, but certainly address the other ones first. For example, if one of your risk elements is that there could be a delay in delivery of critical parts, you might mitigate the risk by ordering early in the project.
1. Product Size
Evaluate every stage in the project's life cycle.
2. Business Impact
Ensure that there is always an emergency person who can always take over or continue a specific task whenever the task assignee is not available and organize a regular weekly meeting time, so that at least the development team meet once every week.
3. Customer Risk
Try to avoid miscommunication with the client that the development team has never worked with before and have a regular way to communicate with them.
4. Process Risk
Re-write the project plan to make sure that a fund is enough to make a project.
5. Technology Risk
The members can rent or barrow materials that can be use in the development of the system.
6. Development Risk
In order to prevent this from happening, always have a back-up file either on external or on cloud storage to avoid distractions.
7. Employee Risk
Read a lot of books on Software Development Process.
1. Risk Monitoring for Risk M
Monitoring is designed to reduce the impact if a risk does materialize. Again, you will usually only develop contingencies for High and Medium elements. For example, if the critical parts you need do not arrive on time, you might have to use old, existing parts while you’re waiting for the new ones.
1. Product Size
Check the difference between the expected sizes of the sub-system with the size of the outcome sub-system at the end of the stage.
2. Business Impact
All team members can attend to the specified meeting time.
3. Customer Risk
Always monitor the quality and frequency of communications with the client.
4. Process Risk
Make sure that the project is still monitored whether the fund for the continuation is not enough.
5. Technology Risk
The proponents can save some funds that they can use when they need to bought materials for the completion of the project.
6. Development Risk
When developing always have a back-up of an updated version of a system to escape on any problem.
7. Employee Risk
The team follows all the Software Development Processes which are described in the plan earlier.
2. Risk Management for Risk M
How much have you reduced the Probability and Impact? Evaluate your Mitigation and Monitoring strategies and reassign effective ratings to your risks.
1. Product Size
If the size is above average, discuss with the customer of the probability of cutting down requirements as it will reduce the size, vice versa. Re-estimate the project size based on the evaluations that have been done.
2. Business Impact
Discuss the problem with the development team. Contact the specific team member, who can't make it to the meeting, by phone or e-mail, and ask for a good reason why she /he can't attend.
3. Customer Risk
Seek guidelines from the Project Manager on how to obtain a good relationship with the client. Contact the client as soon as possible to clear up any misunderstanding that may have taken place.
4. Process Risk
Save some funds that the members can use for the continuation of the project.
5. Technology Risk
Look for materials before developing a project to avoid the problem than they may encounter.
6. Development Risk
Create a cloud storage that you can use to back-up all your files.
7. Employee Risk
Do more research on Software Development Process.
4 Special Conditions
Special conditions that are associated with the software are as follows.
• Login:
The login of the system make sure that the access is limited to certain parts depends on the selected user.
2 SOFTWARE CONFIGURATION MANAGEMENT PLAN
1 Introduction
The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration items.
1. Scope and Intent of SCM Activities
Software Configuration management (SCM) refers to a discipline for evaluating, coordinating, approving or disapproving, and implementing changes in software development that are used to construct and maintain software systems. A software development may be a piece of hardware or software or documentation. SCM enables the management of software development from the initial concept through design, implementation, testing, building, release, and maintenance.
SCM is intended to eliminate the confusion and error brought about by the existence of different versions of software development. A change in software development is a fact of life: plan for it or plan to be overwhelmed by it. Changes are made to correct errors, provide enhancements, or simply reflect the evolutionary refinement of product definition. SCM is about keeping the inevitable change under control. Without a well-enforced SCM process, different team members (possibly at different sites) can use different versions of software development unintentionally; individuals can create versions without the proper authority; and the wrong version of a software development can be used inadvertently. Successful SCM requires a well-defined and institutionalized set of policies and standards that clearly define.
• How software development are changed.
• How software development ensures that change is properly implemented.
• How software development under SCM is allowed to change.
• How different versions of a software development under SCM are made available and under what conditions each one can be used.
These policies and standards are documented in a SCM plan that informs everyone in the organization just how SCM is carried out.
2. SCM Organizational Role
Gabales, Dannisa – Project Manager
Macalalad, Lloyd – Lead Programmer
Flores, Rommel – System Analyst
Cadiente, Ian Pauline – Business Analyst
Beo, Jerralyn – Document Specialist
Each member will accept responsibility for SCM. This is necessary since there are only 5 members in the team, if one of the member reports changes the remaining members will have to take up a job of authorizing change and to ensure that change is properly implemented.
2 SCM Task
All the proponents of the proposed system are involved in the Software Configuration Management activities. Basically:
• The proponents implement software enhancements and report, analyze and fix defects.
• The software configuration manager is responsible for baselines identification.
• The users may use the software configuration management system to retrieve a particular baseline, to report defects or to propose software enhancements
• The testers report defects
Actually in this proposed system the same proponent can be in charge of many activities.
3.2.2.1 Identification
In this section will describe the way software configuration items will be identified for the software configuration management plan.
1. Description
• How software development are changed.
If during the software development phase, and a team member suggest a change, they need to have a work on the suggestion to figure out if the change is necessary and is justified.
• How software development ensures that change is properly implemented.
Since the proponents will be working separately, it is possible to have made mistake in implementing the change. To make sure this doesn’t happen, the proponents need to set up time to look over the change that the other members have implemented and to finalize the change.
• How software development under SCM is allowed to change.
The proponents will be using the change request report form to suggest changes in the software.
• How different versions of a software development under SCM are made available and under what conditions each one can be used.
Once the change is approved the proponents will change the software version number if it is necessary.
2. Works Products and Documentation
• Change control is not used for development or unstable releases. Consequently any change request refers to a baseline fully identified in the configuration management system.
• A proponent can raise a change request. This change request shall include the identification of the concerned component. It may also include a priority.
• The project manager receives a notification for each new change request. The project manager shall define the priority and affect a responsible for the implementation of the request. Eventually the project manager can cancel a change request.
• A proponent can close a change request. Before closing a change request, they shall identify the plan in which he implemented.
3. Configuration Control
3.2.2.2.1 Description
• Identify the configuration items, components, and related work products that will be placed under configuration management.
• Establish and maintain a configuration management and change management system for controlling work products.
• Track change requests for the configuration items.
• Control changes in the content of configuration items.
• Establish and maintain records describing configuration items.
• Perform configuration audits to maintain the integrity of the configuration plan.
4. Version Control
1. Description
Whenever the system or a subsystem is updated, the program build number (version number) will be updated to reflect the change. The version number will follow a standard x.x input mask (for example, version 1.2), with each digit place corresponding to an increasing severity of change. The tenths place (x.x) will reflect minor changes to the software. The ones place (x.x) will reflect severe changes to the software. Version control will be done by hand. No source code tracking / version control tools will be used.
2. Increasing Version Number
When the documents or system needs to be change, it subjected for version numbering. After the change is finalized, it will be checked if it still conforms to the standards implemented. The team will be using a decimal point version number system:
For Documentation:
.
For the System:
.
Bug Fix
For the system, Bug fix numbers are to be incremented if the bug to be fixed is visible. The more visible bug fixes have been made, the closer the bug fix number will need to be incremented.
Minor Version Change
The SCM plan will note the version change and the bug that was fixed.
Severe Version Change
The SCM plan will note the version change and the design decisions that were made. All affected subsystems will be updated in the SCI document.
3. Work Products and Documentation
There will be a document entitled Versions Revision History to be used to record all the version revisions of this project.
5. Configuration Status Accounting
The proponents will be using three different tools/ways to communicate to others that changes may concern.
1. Description
Describes on how the Configuration Status Accounting will be done.
• Verbal Communication
Since the hospital team is small and they commonly at the university and constantly see each other, it would be necessary to communicate verbally.
• Change Request Report
This will be used by the client to request some changes in the developed software or other concerns. They may send their request through e-mail or through the meeting together with the team.
• Social Networking Site
This tool is commonly used to communicate online. The client may announce the changes or enhancements. Also, the developers can communicate with each other by this tool.
2. Work Products and Documentation
• E-mails and chats
• Notes of client’s suggestions
• Documentation of test
3 Software Quality Assurance Overview
Scope and Intent of SQA Activities
SQA plan provides a road map for instituting software quality assurance. Developed by the SQA group and the proponents, the plan serves as a template for SQA activities that are instituted for each software proposal. (For the description of the methods for SQA please refer to Software Quality Assurance Plan (SQA).
Reviews and Audits
A Formal Technical Review (FTR) is SQA activity that is performed by software engineers. The objectives of FTR are:
• To uncover error in function, logic, or implementation for any representation of the software.
• To verify that the software under review meet its requirements.
• To ensure that the software has been represented according to predefined standards.
• To achieve software that is developed in a uniform manner.
• To make projects more manageable.
6. Generic Review Guidelines
Conducting a Review
The proposed system is review the any changes that will affect in using the software, the entire team member has to agree with the change and keep a good work of the project before and after changes.
Roles and Responsibilities
|ROLE |RESPONSIBILITIES |
|Project Manager |Define tasks and deliver on time. Undertake risk management. Demonstrate |
| |high level of communication skills. Produce management project reports, |
| |including project evaluation and project closure. |
|Lead Programmer |Is a software engineer in charge of one or more software projects. |
| |Alternative titles include Development Lead, Technical Lead, Senior |
| |Software Engineer, Software Design Engineer Lead (SDE Lead), Software |
| |Manager, or Senior Applications Developer. |
|System Analyst |Who specializes in analyzing, designing and implementing information |
| |systems. System analysts assess the suitability of information systems in |
| |terms of their intended outcomes and liaise with end users, software |
| |vendors and programmers in order to achieve these outcomes. |
|Business Analyst |A bridge between the business problems and the technology solutions who |
| |analyze, transform and ultimately resolve the business problems with the |
| |help of technology. |
|Document Specialist |Revise and re-write all documents prepared by self and staff relating to |
| |procedures and reporting of programs. Coordinate with staff, vendors and |
| |technical specialists to decide upon material and graphics for documents. |
| |Assist in production process and contribute towards reviewing and updating |
| |content and packaging of published documents. |
Table No. 13 – Roles and Responsibilities Table
Review Work Product
The proponents review a work report for the past week, problems encountered, problem that can’t be solved and any caution. This report will be extremely helpful when comes to documentation.
7. Formal Technical Reviews
After the designing, the proponents will do a test on the interface. And each week, they will ask to do an inspection on the interface, and then hook up the other’s work to do a walkthroughs of the entire interface.
8. SQA Audits
• The team members will have a report for performance for any problems, question regardless on the performance of other team members will also noted there.
• Member will write part of the help menu that related to their design work.
• Any changes that will affect the project will be presented to other team members before doing any change. These are the changes that are minor or required little code change. But still are different from the original architectural design.
9. Problem Reporting and Corrective Action/Follow-Up
This will describe the problem of reporting mechanism that occur as a consequence that are conducted and the means for corrective action and follow – up.
1. Reporting Mechanism
Reporting mechanisms is to measure all the Avoiding / Missing out on sales due to out-of-stock situations.
2. Responsibilities
The SQA team will perform a walkthrough to analyze the product’s quality, error detection and possible enhancements at any particular stage of development.
The SQA team will directly interact in group discussions, discussing any errors or possible enhancements that have been identified. In addition, the SQA team will ensure that the software development has not deviated in any way from the initial design specifications.
3. Data Collection and Valuation
The conduct of software quality assurance, about data gathering in the proposed system should be evaluated and disseminated. The SQA is a help to improve the quality of the project.
3. SOFTWARE QUALITY ASSURANCE PLAN
1. Introduction
This section provides and overview of the Software Quality Assurance activities and procedures that will be carried out by the Product Management with Store Inventory Control development team ultimately yielding high quality software.
1. Scope and Intent of SQA Activities
The SQA process will include and examine every major work product in attempt to perform quality assurance toward every major feature of the Product Management with Store Inventory Control. The overall intent of the SQA activities is to provide high quality software. To achieve such a high standard, the SQA tasks are designed to maintain high software usability, reliability, integrity, and robustness. By continually hearing to the high quality standards while learning of strengths and weakness, the SQA team can improve the software process to create even higher quality software. During the development process, the SQA activities will monitor for defects, both present and potential, and provide a means to correct these defects in an efficient and timely manner by knowing all the personnel needs to be involved. Moreover, the SQA team considers maintaining conformance to the requirements document as a measure of high quality, and therefore a key focus in performing SQA activities. Furthermore, the SQA activities can be used to improve the process of software development by measurement and reporting mechanisms.
2. SQA Organizational Role
* ORGANIZATIONAL DIAGRAM*
Gabales, Dannisa – Project Manager
Macalalad, Lloyd – Lead Programmer
Flores, Rommel – System Analyst
Cadiente, Ian Pauline – Business Analyst
Beo, Jerralyn – Document Specialist
2. SQA Tasks
These are the following task that we have for Software Quality Assurance:
• Voting system when it comes to decision making about the system.
• Have a good communication and relationship in the client.
• Create a system with an extensive and detailed design.
• Researching about the process of the Vendor Consignment and Contract by interviewing different company.
1. Task Overview
Task that described above will cover the product quality control, survey, gathering of data, and System design.
• Group meeting, Brain storming
The proponents conducted group meetings and brain storming about the proposed system.
• Company Search, Interview, Survey Gathering of Data
- The proponents conducted a research at companies that are related within the proposed system.
- Interviewed people that more knowledgeable on the proposed system.
- Conducted a survey and gathered data to become useful information.
• Analyzing Gathered Information and System Planning
- The proponents analyze about gathered information for proposed system and making the planning for system design.
• System Design
- The proponents provide a lot of time to develop the proposed system to finish at the right time and at the right way.
2. Standard, Practices and Conversation (SPC)
The majority of changes will be done with verbal meetings, phone calls, or group emails. During these discussions, no formal documents will be created, and no standard conventions or practices will need to be followed. For major changes, we will use standard change management procedures and note the changes in the document.
• Voting system when it comes to decision making about the system.
• Have a good communication and relationship in the client.
• Create a system with an extensive and detailed design.
3. SQA Resources
The proponents used these resources as a guide in developing the proposed system.
• Modules
• People
• Hardware (Computer)
• Software (Google Chrome, Word reader and PDF reader)
3. Reviews and Audits
A Formal Technical Review (FTR) is SQA activity that is performed by software engineers. The objectives of FTR are:
• To uncover error in function, logic, or implementation for any representation of the software.
• To verify that the software under review meet its requirements.
• To ensure that the software has been represented according to predefined standards.
• To achieve software that is developed in a uniform manner.
• To make projects more manageable.
1. Generic Review Guidelines
Conducting a Review
The proposed system is review the any changes that will affect in using the software, the entire team member has to agree with the change and keep a good work of the project before and after changes.
Roles and Responsibilities
|ROLE |RESPONSIBILITIES |
|Project Manager |Define tasks and deliver on time. Undertake risk management. Demonstrate |
| |high level of communication skills. Produce management project reports, |
| |including project evaluation and project closure. |
|Lead Programmer |Is a software engineer in charge of one or more software projects. |
| |Alternative titles include Development Lead, Technical Lead, Senior |
| |Software Engineer, Software Design Engineer Lead, Software Manager, or |
| |Senior Applications Developer. |
|System Analyst |Who specializes in analyzing, designing and implementing information |
| |systems. System analysts assess the suitability of information systems in |
| |terms of their intended outcomes and liaise with end users, software |
| |vendors and programmers in order to achieve these outcomes. |
|Business Analyst |A bridge between the business problems and the technology solutions who |
| |analyze, transform and ultimately resolve the business problems with the |
| |help of technology. |
|Document Specialist |Revise and re-write all documents prepared by self and staff relating to |
| |procedures and reporting of programs. Coordinate with staff, vendors and |
| |technical specialists to decide upon material and graphics for documents. |
| |Assist in production process and contribute towards reviewing and updating |
| |content and packaging of published documents. |
Table No. 14 – Roles and Responsibilities Table
Review Work Product
The proponents review a work report for the past week, problems encountered, problem that can’t be solved and any caution. This report will be extremely helpful when comes to documentation.
2. Formal Technical Reviews
Here are the FTR that the products will conduct during the software process:
• Description of Review Walkthroughs
This review mainly focuses on the integration of the parts such as interfaces, form, and database. The Project Manager will ask the other team members to do walkthroughs with the presence of the Lead programmer.
• Description of Review Inspection
This review mainly focuses on the correctness of the parts that the System Analysts designed. Usually the Project Manager allows the other team member to do a test.
• System Specification Review
The systems specification is usually changed after each weekly meeting, and after each meeting with the client.
• Software Project Plan Review
The purpose of software project plan is over look of the whole project.
• RMMM Review
RMMM is use to prevent, monitor and manage the risk.
• Requirements Reviews (Models, Specification)
Software requirements stated the data requirement, specification.
• Data Design Review
The Data Design Document is about the data flow between each form (interface), and forms to the database.
• Architectural Design Review
The Architectural Design Document is about the whole project design, layout and data flow.
• Interface (GUI)
Up on the request of the client, the proponents will design the interface from the previous version.
• Component Design Review
The proponents will also do integration and help desk for a period of time. And do some database re-engineering for the client’s database to make it more efficient and suit for project need.
• Code Review
• Test Specification Review
• Change Control Reviews and Audits
3. SQA Audits
• The team members will have a report for performance for any problems, question regardless on the performance of other team members will also noted there.
• Member will write part of the help menu that related to their design work.
• Any changes that will affect the project will be presented to other team members before doing any change. These are the changes that are minor or required little code change. But still are different from the original architectural design.
• After presenting the changes in the team members, the client should also know the changes made. Clients will be notified for small changes, while an agreement between the client and the development team should be made for major changes.
• Past and revised versions of the project will also be recorded. The documents will be noted to identify what kind of revision was made and by who.
4. Problem Reporting and Corrective Action / Follow – Up
This will describe the problem of reporting mechanism that occur as a consequence that are conducted and the means for corrective action and follow – up.
1. Reporting Mechanisms
Reporting mechanisms is to show information about the procedure in producing reports about quality assurance.
2. Responsibilities
The SQA team will perform a walkthrough to analyze the product’s quality, error detection and possible enhancements at any particular stage of development.
The SQA team will directly interact in group discussions, discussing any errors or possible enhancements that have been identified. In addition, the SQA team will ensure that the software development has not deviated in any way from the initial design specifications.
Gabales, Dannisa – Project Manager
Macalalad, Lloyd – Lead Programmer
Flores, Rommel – System Analyst
Cadiente, Ian Pauline – Business Analyst
Beo, Jerralyn – Document Specialist
3. Data Collection And Valuation
To properly conduct software quality assurance, data about the software engineering should be collected, evaluated, and disseminated. Statistical SQA helps to improve the quality of the project and the software process itself.
4. Statistical SQA
Statistical quality assurance reflects a growing trend throughout industry to become more quantitative about quality. *SQA PAGE 9*
5. Software Process Improvement Activities
Determinants for Software Quality Assurance Plan
Figure No. 1 – Determinants for Software Quality Assurance Plan
1. Goal and Object of SPI
Here are some goals of SPI:
1. All errors and defects are categorized by origin.
2. The cost to correct each error and defects is recorded.
3. The numbers of error and defects in each category are counted and ordered in descending order.
4. The overall cost of error and defects in each category is computed.
5. Resultant data are analyzed to uncover the categories.
6. Plans are developed to modify the process with the intent of eliminating.
*The graph below illustrated the error that must expect on this project. They categorized in six fields.
|Field |% |Reason |
|Logic |30 |None of the member has any experience on doing a project in this size, or the experience on the project in this degree |
| | |of difficulties. |
|Interface |25 |Up on the request of the client, the proponents will design the interface from the previous version. |
|Data Handling |15 |This project involved a lot of data accessing / storing, data flow between each interfaces. It's not easy to keep track |
| | |of them. And the queries that the database used are pretty much outdated. |
|Error Checking |10 |Since the member have a very close contact with the client, and have done an exceptional work on research and study the |
| | |old version, the member can keep the field under 10%. |
|HW / SW |10 |The proponents will also do integration and help desk for a period of time. And do some database re-engineering for the |
| | |client’s database to make it more efficient and suit for project need. |
|Standard |10 |Since the member has no experience on such degree of project, so other errors might be uncover, but the member must be |
| | |optimist since they did a pretty good research on the project, and spent many times on designing phase before any actual|
| | |coding. |
Table No. 15 – Goals and Object of SPI Table
2. SPI Tasks and Responsibilities
Since the proponents is not a large team, the responsibilities of each team member will do SPI activities
6. Software Configuration Management and Overview
During the time of the software development the other plans will soon to change. Software configuration management plan is to identify the changes and to control the changes. Making sure the plan and report is implemented correctly.
7. SQA Tools, Techniques, Methods
All SQA activities will follow the same guidelines and methods (see appendix). Every SQA meeting will include every group member. Every group member is expected to participate in the discussion. Any group member not attending the review will be notified by the SQA manager of what took place at the review. The SQA manager will oversee the discussion and will take notes of any defects or enhancements that need to be analyzed.
The SQA team will analyze the defects or enhancements and determine their complexity, impact on the system, and priority. Once prioritized, the SQA manager will assign each member along with their priority.
After a defect has been eliminated or an enhancement added, each member will inform the SQA manager at the next SQA review. The SQA manager will take note of the correction in the SQA plan.
4. SYSTEM SPECIFICATION
1. Introduction
The system specification document describes what the system is to do, and how the system will perform each function. The audiences for this document include the proponents and the users. The proponent uses this document as the authority on designing and building system capabilities. The users review the document to ensure the documentation completely and accurately describes the intended functionality.
1. Goals and Objectives
The proponents proposed a system that can track products and parts as they are transported from a vendor to a warehouse, between warehouses, and finally to a retail location or directly to a customer and to help the user to automate the entire process.
• The projects aims to provide solutions that will help the current situation of companies in terms of product management.
• The project aims to promote the efficiency of using technology on companies to improve its productivity.
2. System Statement of Scope
Product Management with Store Inventory Control is used for variety purposes. This study focused on creating an automated system that allows the company to save money and time. The proponents used the Netbeans for the Programming Language and MSSql for the back-end.
• Request for Product Replenishment
• Approval of Request
• Record of Critical Level Products
• Record of Distressed Stock
• Record of Expired Products
1. General Requirements
The General requirement of the system is specified:
• Interface
• Database
• Training
• Mobile Apps
• Free Format Query
• Personalized Screen
• Import/Export
• Analytical Reports
2. Extended Enhancement
This allows the user to select the most appropriate format for the type of system they are trying to specify. Because of the possibly infinite number of possible cases that the specification may be used in this is an appropriate approach. Having a rigid format, would dissuade companies from adopting the standard because it may be an inappropriate format for some types of software development. Large organizations have the might and will to create their own format of software requirement specification
3. System Context
A system specification should be clear, concise, consistent and unambiguous. It must correctly specify all of the software requirements, but no more. However the system specification should not describe any of the design or verification aspects, except where constrained by any of the stakeholder’s requirements.
• Must include information about the importance of the system.
• Usage of the system results to faster transactions
• Accuracy and Reliability of Data
4. Major Constraints
The major constraints of the system are:
• Compatibility
• Integration
• Peopleware
• Data Requirements
4 Functional Data Description
*SS PAGE 5*
5. System Architecture
1. Architectural Model
Appropriate Use of Figures
• Sales Person
• Sales Manager
• Maintenance Self Test
• Administrator
• System
2. Current Sub-system Overview
➢ Subsystem overview is appropriate to product management
• Recording of Product
• Replenishment of Product
➢ Information is clearly defined.
1. Data Description
3.4.2.2.1 Major Data Objects
• Product Group Data Object
Group_ID – A unique identifier assigned to the designated group of a product.
Group_Name – It is the title of product group.
Group_Desc – It is the descriptive and supporting description definition of the product group.
• Product Category Data Object
Cat_ID – A unique identifier assigned to the designated category of a product.
Cat_Name – it is the title of the product category.
Cat_Desc – It is the supporting definition of the product category.
• Product Subcategory Data Object
Subcat_ID – A unique identifier assigned to the designated subcategory of a product.
Subcat_Name – It is the title of the product subcategory.
Subcat_Desc – It is the supporting definition of the product subcategory.
• Product Data Object
Prod_ID – A unique identifier assigned to each sort of products.
Prod_SKUCode – The preprogrammed code combination assigned by the SKU module.
Prod_Barcode – The generic code assigned by the supplier.
Prod_Type – The type of the selling product either outright or consignor.
Prod_Desc – It is the supporting details of the merchandise.
Prod_Cat – It is assigned product category.
Prod_Subcat – It is the assigned product category.
Prod_Qty_Per_Box – It is the number of merchandise stored in each box.
Prod_Qty_Per_Pack – It is the number of item stored in each pack.
Prod_Qty_Per_Measure – It is the merchandise net weight/net content.
Prod_Mfgdate – It is the date of production assigned by the supplier.
Prod_Expdate – It is the date of perish assigned by the supplier.
Prod_Shelfdue – It is the final date of the products shelf life.
Prod_Promodue – it is the final date of the products promotion for discounts and freebies.
Prod_Reorderlevel – It is the product status according to the customer’s patronage.
Prod_Ordercode – It is the unique number combination assigned for each product order.
Location_No – It is the shelf location assigned to each product.
Prod_Srp, Prod_Wsp, Prod_Fsp – The price of merchandise which differ as per SRP (Suggested Retail Price), WSP (Whole Sale Price) and FSP (For Sale Price).
2. Relationships
2. Human Interface Description
A first-time user of the system should see the log-in page when he/she opens the system. If the user has not registered, he/she should be able to do that on the log-in page.
If the user is not a first-time user, he/she should be able to see the search page directly when the system is opened. Here the user chooses the type of search he/she wants to conduct. Every user should have a profile page where they can edit their e-mail address, phone number and password.
6 Subsystem Description
3. Subsystem Flow Diagram
3.4.3.1.1 Create Checklist
3.4.3.1.2 Print Checklist
3.4.3.1.3 Generate Letter
3.4.4 Enhanced Interface Prototyping
3.4.4.1 Prototyping Requirements
3.5 SOFTWARE REQUIREMENTS SPECIFICATION
3.5.1 Introduction
A software requirements specification is a document which is used as a communication medium between the customer and the developer. When the software requirement specification is completed and is accepted by all parties, the end of the requirements development phase has been reached. This is not to say, that after the acceptance phase, any of the requirements cannot be changed, but the changes must be tightly controlled.
3.5.1.1 Goals and Objectives
• To provide software that will automate process of Product Management.
• To create a generic system to be used by any merchandising company.
• The system must be integrated with the other module of Merchandising System.
2. System Statement of Scope
Product Management with Store Inventory Control is used for variety purposes. This study focused on creating an automated system that allows the company to save money and time.
• Request for Product Replenishment
• Approval of Request
• Record of Critical Level Products
• Record of Distressed Stock
• Record of Expired Products
1. General Requirements
• Functionality
These requirements are organized by the features discussed in this document that refined into use case diagrams and to sequence diagram to best capture the functional requirements of the system.
• Sell Configured to Ordered Products
- The system shall display all the products that can be configured.
- The system shall allow user to select the product to configure.
- The system shall display all the available components of the product to configure.
- The system shall enable user to add one or more component to the configuration.
- The system shall notify the user about any conflict in the current configuration.
- The system shall allow user to update the configuration to resolve conflict in the current configuration.
- The system shall allow user to confirm the completion of current configuration
Provide comprehensive product details
The system shall display detailed information of the selected products.
The system shall provide search options to see product details.
Detailed product Categorization
- The system shall display detailed product categorization to the user.
Provide Search facility
- The system shall enable user to enter the search text on the screen.
- The system shall enable user to select multiple options on the screen to search.
- The system shall display all the matching products based on the search
- The system shall display only 10 matching result on the current screen.
- The system shall enable user to navigate between the search results.
- The system shall notify the user when no matching product is found on the search.
Maintain customer profile
- The system shall allow user to create profile and set his credential.
- The system shall authenticate user credentials to view the profile.
- The system shall allow user to update the profile information.
Provide personalized profile
- The system shall display both the active and completed order history in the customer profile.
- The system shall allow user to select the order from the order history.
- The system shall display the detailed information about the selected order.
- The system shall display the most frequently searched items by the user in the profile.
Provide Customer Support
- The system shall provide help, FAQ’s customer support, and sitemap options for customer support.
- The system shall allow user to select the support type he wants.
- The system shall allow user to enter the customer and product information for the support.
- The system shall display the customer support contact numbers on the screen.
- The system shall allow user to enter the contact number for support personnel to call.
Provide detailed Store map
The system shall allow user to view detailed Store map.
Usability
Graphical User Interface
- The system shall provide a uniform look and feel between all the web pages.
- The system shall provide a digital image for each product in the product catalog.
- The system shall provide use of icons and toolbars.
Accessibility
- The system shall provide multi language support.
Reliability & Availability
Back-end Internal Computers
- The system shall provide storage of all databases on redundant computers with automatic switchover.
- The system shall provide for replication of databases to off-site storage locations.
Performance
- The performance shall depend upon hardware components of the client/customer.
Security
Data Transfer
- The system shall use secure sockets in all transactions that include any confidential customer information.
- The system shall automatically log out all customers after a period of inactivity.
- The system shall confirm all transactions with the customer’s web browser.
- The system shall not leave any cookies on the customer’s computer containing the user’s password.
- The system shall not leave any cookies on the customer’s computer containing any of the user’s confidential information.
Data Storage
- The system’s back-end servers shall only be accessible to authenticated administrators.
The system’s back-end databases shall be encrypted.
Supportability
Configuration Management Tool
- The source code developed for this system shall be maintained in configuration management tool.
Design Constraints
Standard Development Tools
The system shall be built using a standard web page development tool that conforms to either IBM’s CUA standards or Microsoft’s GUI standards.
Interfaces
User Interfaces
- The user interface shall be implemented using any tool or software package like Java Applet, MS Front Page, etc.
Software Interfaces
- The system shall communicate with the Configurator to identify all the available components to configure the product.
- The system shall communicate with the content manager to get the product specifications, offerings and promotions.
- The system shall communicate with Sales system for order management.
- The system shall communicate with external Tax system to calculate tax.
- The system shall communicate with Point of sale with Price Management.
- The system shall be like software which shall allow the users to complete secured transaction. This usually shall be the third party software system which is widely used for internet transaction.
2. Extended Enhancement
This allows the user to select the most appropriate format for the type of system they are trying to specify. Because of the possibly infinite number of possible cases that the specification may be used in this is an appropriate approach. Having a rigid format, would dissuade companies from adopting the standard because it may be an inappropriate format for some types of software development. Large organizations have the might and will to create their own format of software requirement specification
.
3. System Context
A system specification should be clear, concise, consistent and unambiguous. It must correctly specify all of the software requirements, but no more. However the system specification should not describe any of the design or verification aspects, except where constrained by any of the stakeholder’s requirements.
4. Major Constraints
• Time
This usually comes in the form of an enforced deadline, commonly known as the “make it happen now” scenario. You can’t just go into your software and move the tasks further out. It’s set in stone now – all activities on this project are driven by the due date.
• Integration
• Developing Environment
The use of Open Source Software and Proprietary Software is an advantage in the system. From the flexibility of the open source and security of the proprietary produces powerful system.
• Compatibility
The system can be used in different environment and will encounter minimal error.
3 Usage Scenario
3.5.2.1 User Profiles
The following actors and definitions will draw the procedural flow of the Merchandising System.
• Administrator
An administrator has the full access for the whole system; even the capable of giving or creating various grant privileges for any other users. It may represent the manager, supervisor, department head or any other position with equivalent administrative tasks. He/she is the one responsible for adding new user and product classification; modifies user profile, user status, etc.
• Store Manager
Personnel inside the organization granted with privileges to utilize the system’s functionalities with a limit. He/she is usually granted with an executive access as discussed above.
• Merchandiser
He/she is a registered user from other modules (Warehouse Inventory, Store Inventory Control, Price Management, Allocation and Replenishment).
5. Use-Cases
The following use-cases define the transactional and procedural interactions between the external environment and the internal software system. Each use-case is describe in 3.5.2.2.2
• Login to the system
• Request for Replenishment
• Approve Request
• Record Critical Level Stock
• Record Distressed Stock
• Record Expired Product
• Generate Inventory Report
• Logout from system
1. Use-Case Diagram
Login
Request for Replenishment
Approve Request
Record Critical Level Stock
Record Distressed Stock
Record Expired Product
Generate Inventory Report
Logout
Figure No. 2 - Use-case Diagram of Product Management with Store Inventory Control Module
2. Use-Case Description
3. Special Usage Considerations
Constraints of the system:
• Administrator has full access in the system
• Only Sales Manager can approve request
4. Activity Diagrams
3.5.3 Data Model and Description
3.5.3.1 Data Description
3.5.3.2.1.1 Data Objects and Dictionary
• Product Group Data Object
Group_ID – A unique identifier assigned to the designated group of a product.
Group_Name – It is the title of product group.
Group_Desc – It is the descriptive and supporting description definition of the product group.
• Product Category Data Object
Cat_ID – A unique identifier assigned to the designated category of a product.
Cat_Name – it is the title of the product category.
Cat_Desc – It is the supporting definition of the product category.
• Product Subcategory Data Object
Subcat_ID – A unique identifier assigned to the designated subcategory of a product.
Subcat_Name – It is the title of the product subcategory.
Subcat_Desc – It is the supporting definition of the product subcategory.
• Product Data Object
Prod_ID – A unique identifier assigned to each sort of products.
Prod_SKUCode – The preprogrammed code combination assigned by the SKU module.
Prod_Barcode – The generic code assigned by the supplier.
Prod_Type – The type of the selling product either outright or consignor.
Prod_Desc – It is the supporting details of the merchandise.
Prod_Cat – It is assigned product category.
Prod_Subcat – It is the assigned product category.
Prod_Qty_Per_Box – It is the number of merchandise stored in each box.
Prod_Qty_Per_Pack – It is the number of item stored in each pack.
Prod_Qty_Per_Measure – It is the merchandise net weight/net content.
Prod_Mfgdate – It is the date of production assigned by the supplier.
Prod_Expdate – It is the date of perish assigned by the supplier.
Prod_Shelfdue – It is the final date of the products shelf life.
Prod_Promodue – it is the final date of the products promotion for discounts and freebies.
Prod_Reorderlevel – It is the product status according to the customer’s patronage.
Prod_Ordercode – It is the unique number combination assigned for each product order.
Location_No – It is the shelf location assigned to each product.
Prod_Srp, Prod_Wsp, Prod_Fsp – The price of merchandise which differ as per SRP (Suggested Retail Price), WSP (Whole Sale Price) and FSP (For Sale Price).
3.5.3.2.1.2 Relationships
3.5.4 Functional, Model and Description
3.5.4.1 Subsystem Flow Diagram
3.5.4.1.1 Create Checklist
3.5.4.1.2 Print Checklist
3.5.4.1.3 Generate Letter
3.5.4.2 Human Interface
A first-time user of the system should see the log-in page when he/she opens the system. If the user has not registered, he/she should be able to do that on the log-in page.
If the user is not a first-time user, he/she should be able to see the search page directly when the system is opened. Here the user chooses the type of search he/she wants to conduct. Every user should have a profile page where they can edit their e-mail address, phone number and password.
5. Restrictions, Limitations and Constraints
• The module shall be integrated with the other modules of Merchandising System.
• JAVA is the only or preferred language in developing the system.
• The system prefers a stand-alone based computer for production purposes.
• The system will utilize Microsoft SQL in managing database.
• Procurement will not be covered in the module.
6. Validation Criteria
Functional Requirements
• The transaction processes that are needed in the system should all be working and can generate real time records.
• Search engine on the Query section should produce a real time data that is stored in the database. 3. Reports should be informational and the contents should be based on the data that has been inputted in the system and stored in the database.
• The contents and setting should be based on the user (e.g. Admin, Consignee).
• The System set-up should be working in terms of generating on time data that was inputted in the database.
• The system should be well-integrated to the system that is related to it.
• Data migration should be flawless or data that are needed should not be jammed or lost.
Non-Functional Requirements
• The system should have a splash screen and it should be working.
• As for the security of the system, the log in page should be working and should be strict when it comes to inputting the username and the password. The password should display asterisk (*) instead of the actual password for the privacy and security purposes of the user.
• The report should be viewable and can be printed.
• System should have windows dialog for warning, errors, success and conformation for the user’s awareness in the system.
• The system should follow the standards that have been approved by the Merchandising System and by the client
• The data that have been inputted in the system should be stored in the database.
• System interface should be organized and easily understandable by the users of the system.
• The system should be well integrated to the other module or system.
5. SOFTWARE DESIGN SPECIFICATION
3.6.1 Introduction
This section describes the design for Product Management with Store Inventory Control Module.
3.6.1.1 Goals and Objectives
The proponents proposed a system that can track inventory in replenishing the products and to determine what is the Fast / Slow Moving Products, Critical Level Products and Expired Products.
• To reduce difficulty
• To have less cost
• To be efficient
• To provide a User Interface and Database Design that will follow the standard of the Quality Assurance Team.
• To provide a generic system that can be configured (ex. Logo) to cater any Merchandising using the system.
3.6.1.2 System Statement of Scope
The system can manage the accuracy in inventory such as monitoring or filtering of incoming and out coming of the products and including the accurate stock records.
• Request for Product Replenishment
The proposed module shall request for product to be replenished from the order distribution module.
• Approval of Request
The proposed module shall wait for the requested products for approval or rejection from Order and Distribution.
• Record of Critical Level Product
The proposed module shall monitor and record the stocks of products in the inventory that are nearly depleting and running low.
• Record of Distressed Stock
The proposed module shall monitor and record for distressed product management with store inventory control.
• Record of Expired Products
The proposed module shall monitor and record for those products which are expired and apply proper management with store inventory control.
3.6.1.2.1 General Requirements
• Use a clear text for easy reading of instructions, notifications and messages
• An appropriate use of colour schemes that is not striking to the eye and merely represents the system
• Simple or layman terms are required for easy understanding of the system
• Short but brief and organized explanation of words and messages on every field
• User friendly interface comprising the system components, main menus etc.
3.6.1.3 System Context
Benefits of the design applied in the system.
• User-friendly interface for an organized system resulting to more faster processing of transactions
• Database Design structure following the business intelligence of the system
3.6.1.5 Major Constraints
• Developing Environment
The use of Open Source Software and Proprietary Software is an advantage in the system. From the flexibility of the open source and security of the proprietary produces powerful system.
• Compatibility
The system can be used in different environment and will encounter minimal error.
3.6.2 Data Design
3.6.2.1 Database Description
3.6.3 Architectural and Component-Level Design
3.6.3.1 Program Structure
3.6.3.1.1 Overall
This diagram shows the program structure of the system in terms of process and overall system.
Figure No. 3 – Overall (System Set-up)
Menu Items
The following shows the architecture of the main menu.
• System Setup
Product
Product Category
Location
Store
• Transaction
Request Replenishment
Approve Request
Critical Level Stock
Distressed Stock
Expired Products
• Queries
List of Expired Products
List of Critical Level
List of Distressed Products
• Reports
Inventory Master List
Inventory
Stocking Report
• Utilities
Configuration
Logout
3.6.3.1.2 Create Inspection
3.6.3.1.3 During Inspection
3.6.3.1.4 Post-Inspection
3.6.3.1.4 Approval
3.6.3.2 Description for Components
3.6.3.2.1 Switch User
3.6.3.2.2 Facility
3.6.3.2.3 Create / Modify Inspection – Step 1
3.6.3.2.4 Create / Modify Inspection – Step 2
3.6.3.2.5 File Results – Step 1
3.6.3.2.6 File Results – Step 2
3.6.3.2.7 Approval
3.6.3.2.8 Checklist Maintenance
3.6.3.2.9 Letter Maintenance
3.6.4 User Interface Design
3.6.4.1 Description of the User Interface
Below are some of the forms in the program.
3.6.4.1.1 Screen Images
Main Interface
Search Pages
Approval Queue
3.6.4.1.2 Object and Actions
Menu Items
The following shows the architecture of the main menu.
• System Setup
Product
Product Category
Location
Store
• Transaction
Request Replenishment
Approve Request
Critical Level Stock
Distressed Stock
Expired Products
• Queries
List of Expired Products
List of Critical Level
List of Distressed Products
• Reports
Inventory Master List
Inventory
Stocking Report
• Utilities
Configuration
Logout
3.6.4.2 Interface Design Rules
3.6.4.3 Component Available
1. Intrinsic Control
JTextField
- A lightweight component that allows the editing of a single line of text.
JLabel
- A display area for a short test string or an image or both.
JList
- A component that allows the user to select one or more objects from a list.
JScrollBar
- A scrollbar provides a convenient means for allowing a user to select from range of values
JButton
- A “push” button.
JMenuBar
- A container for menus and menu items.
JComboBox
- A component that combines a button or editable field and a drop down list.
JCheckBox
- An item that can be selected or deselected. By convention or any number of check boxes in a group can be selected.
JRadioButton
- An item that can be selected or deselected. Used with a button group object to create a group of buttons in which only one button at a time can be selected.
JSeparator
- A general purpose component for implementing divider lines.
3.6.4.3.2 Active X Control
JDatePicker
- Where you can select the date by just clicking.
JTree
- A control that displays a set of hierarchical data as an outline.
JToolBar
- A component that is useful for displaying commonly used actions or controls.
JDialog
- A dialog window.
3.6.5 Restriction, Limitation and Constraints
Time
So far, Time is the biggest restriction or constraint in creating the project, as the team only has 5 months to finish the entire project. It is very important to watch the time spend over every phase of the software development project. The team needs to include some components like online help menu, but time restricts from doing so.
Employee Skills
The Lead programmer and the system analyst need more time to enhance their ability to create a system.
Insufficient Resources
Rent or borrow materials that can be essential for the project.
3.6.6 Testing Issues
3.6.6.1 Classes of Test
3.6.6.2 Performances Bounds
3.6.6.3 Identification of Critical Components
3.6.7 Appendices
3.7 TEST SPECIFICATION
3.7.1 Introduction
This section gives a general overview of the Test Specification for the Product Management with Store Inventory Control Module.
3.7.1.1 Goals and Objects
The proponents would like to have a test specification to counter any difficulties that may impact the development and the future performance of software. The proponent’s goal is to have a developing strategy that can deal with any errors. The proponents will take look at the most common errors to some very common errors.
3.7.1.2 Statement of Scope
An overall plan for integration of the software and a description of specific tests are documented in this section. Below are the different kinds of tests that the team will take to ensure the quality of the software.
• Unit Testing – Unit test will be performed using block box testing methods.
• Desktop Application
• Database
• Palm-size PC Application
• Integration Testing
• Desktop Application
• Database
• Palm-size PC Application
• Validation Testing – To test software as a whole, so all the units of the software will be included.
• Desktop Application
• Database
• Palm-size PC Application
• High-order Testing – The software will be tested for several test methods.
• Desktop Application
• Database
• Palm-size PC Application
3.7.1.3 Major Constraints
• Time as a constraint
This usually comes in the form of an enforced deadline, commonly known as the “make it happen now” scenario. You can’t just go into your software and move the tasks further out. It’s set in stone now – all activities on this project are driven by the due date.
• Budget as a constraint
Budgets limit the project team’s ability to obtain resources and might potentially limit the scope of the project. For example, component X cannot be part of this project because the budget doesn’t support it.
• Quality as a constraint
Quality would typically be restricted by the specifications of the product or service. Most of the time, if quality is a constraint; one of the other constraints – time or budget – has to have some give. You can’t produce high quality on a restricted budget and within a tightly restricted time schedule. Of course, there are exceptions, but usually not in reality – just in the movies.
3.7.2 Testing Plan
The proponents want the proponents to be bug free. They also want to make sure that they are no defects in the product. The proponents will be spending large amount of total software development time on testing. Below is the description of the testing procedure and strategy.
3.7.2.1 Software (SCIs) to be tested
3.7.2.1.1 Interfaces
3.7.2.2 Testing Strategy
In the following section it describes the testing strategy. The proponents use four different methods to test the product.
3.7.2.2.1 Unit Testing
In the unit test case the proponents will be testing the separate modules of the software. They will be looking for entry and exit conditions of the data. They will make sure that all the components work without any trouble.
3.7.2.2.2 Integration Testing
In this method of testing the proponents will implement the software at the client’s location and will run it. The proponents will be looking for any sorts of collision between several different applications from log-in window to all the software functions.
3.7.2.2.3 Validation Testing
In this method of the test the proponents will be working with the customer to find out if the software developed in valid for the clients. They want to make sure that the client is getting what he asked for. The proponents will look at the software requirement document in the case of conflict or misunderstanding with client regarding software components.
3.7.2.2.4 High-order Testing
In this method the proponents will combine several different other types of testing.
• Recovery Testing – Concerned with the ability of the software to retrieve lost data.
• Security Testing – To check that the security is working and no one is able to temper with the data.
• Stress Testing – To monitor the tress caused to system and the software due to simultaneous use.
• Performance Testing – it helps to determine the effectiveness of the software. It will also help to minimize stress level.
3.7.2.3 Testing Resources and Staffing
The proponents will use several different resources to carry out the test on the software.
Gabales, Dannisa – Project Manager
Macalalad, Lloyd – Lead Programmer
Flores, Rommel – System Analyst
Cadiente, Ian Pauline – Business Analyst
Beo, Jerralyn – Document Specialist
3.7.2.4 Test Record Keeping
Test record keeping and Test Work Procedures are described in section 3.7.3.4 of Test Specification Document. For Information regarding these topics, please refer to section 3.7.3.4 of Test Specification Document.
3.7.2.5 Testing Tools and Environment
3.7.2.6 Test Schedule
3.7.3 Test Procedure
3.7.3.1 Software (SCIs) to be tested
3.7.3.2 Testing Procedures
3.7.3.2.1 Unit Testing
3.7.3.2.2 Integration Testing
3.7.3.2.3 Validation Testing
3.7.3.2.4 High-order Testing
3.7.3.3 Testing Resources and Staffing
3.7.3.4 Test Record Keeping and Log
CHAPTER 4 – RESULT AND DISCUSSION INCLUDES TEST SCENARIOS AND EVIDENCE
|3.1 Risk Mitigation, Monitoring, and Management Plan |
|Specific Transaction |Procedure |Evaluation |Remarks |
|3.1.1 Introduction |The goal of the risk mitigation, |It is the organization’s | |
|3.1.1.1 Scope and Intent of RMMM |monitoring and management plan is to |responsibility to perform risk | |
|Activities |identify as many potential risks as |mitigation, monitoring, and | |
| |possible. To help determine what the |management in order to produce a | |
| |potential risks are. When all risks |quality product. The quicker the | |
| |have been identified, they will then |risks can be identified and avoided, | |
| |be evaluated to determine their |the smaller the chances of having to | |
| |probability of occurrence. Plans will|face that particular risk’s | |
| |then be made to avoid each risk, to |consequence. | |
| |track each risk to determine if it is| | |
| |more or less likely to occur, and to | | |
| |plan for those risks should occur. | | |
|3.1.1.2 Risk Management Organizational|*Document specialist can help avoid |Each member of the organization will | |
|Role |the risk by double-checking if the |undertake risk management. The | |
| |document is match with the system. |development team will consistently be| |
| | |monitoring their progress and project| |
| |*Lead Programmer can avoid risk by |status as to identify present and | |
| |providing all necessary software |future risks as quickly and | |
| |information before the start of the |accurately as possible. | |
| |project. | | |
| | | | |
| | | | |
| | | | |
| |*Project Manager can avoid risks by | | |
| |creating risk management plan to | | |
| |define certain risk approaches. | | |
| | | | |
| |*Business Analyst provides counsel | | |
| |and assistance regarding risk | | |
| |identification/assessment/analysis/ | | |
| |handling. | | |
|Functional Data Description |The identified risks are analyzed to |The initial risk analysis deals with | |
| |establish the project exposure for |those risks identified early in the | |
| |each risk and to determine which risk|project, more analysis may be needed | |
| |items are the most important ones to |as the project proceeds. In cases | |
| |address. |where a new risk is identified, that | |
| | |new risk is analyzed and its exposure| |
| | |compared to that risks already being | |
| | |handled. | |
|3.1.2.1 Risk Table |The first step is to identify ‘all’ |During the risk analysis, each risk | |
| |the risks. To do this, fully needs |is considered in turn and a judgment | |
| |two things, a fairly detailed working|made about the probability and the | |
| |knowledge of the given organization |seriousness of the risk. | |
| |plus an appreciation of likely | | |
| |vulnerability areas. | | |
|Risk Mitigation, Monitoring and |Mitigation is designed to reduce the |Normally you will only do this for | |
|Management |probability that a risk will |High and Medium elements. You might | |
|3.1.3.1 Risk Mitigation for Risk M |materialize. |want to mitigate low risk items, but | |
| | |certainly address the other ones | |
| | |first. | |
|3.1.3.2 Risk Monitoring for Risk M |Monitoring is designed to reduce the |You will usually only develop | |
| |impact if a risk does materialize. |contingencies for High and Medium | |
| | |elements. | |
|3.1.3.3 Risk Management for Risk M |How much have you reduced the |Evaluate your Mitigation and | |
| |Probability and Impact? |Monitoring strategies and reassign | |
| | |effective ratings to your risks. | |
|Special Conditions |Special conditions that are |*Login - The login of the system make| |
| |associated with the software |sure that the access is limited to | |
| | |certain parts depends on the selected| |
| | |user. | |
Table No 4.1 Findings in risk mitigation, Monitoring and Management Plan
-----------------------
Product
Customer
Characteristics
Business
Conditions
Process
Technology
People
Development
Environment
Merchandiser
Store Manager
Login
Main Screen
Utilities
Reports
Queries
Transaction
System Setup
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
Related searches
- getroman com reviews
- acurafinancialservices.com account management
- acurafinancialservices.com account ma
- getroman.com tv
- http cashier.95516.com bing
- http cashier.95516.com bingprivacy notice.pdf
- connected mcgraw hill com lausd
- education.com games play
- rushmorelm.com one time payment
- autotrader.com used cars
- b com 2nd year syllabus
- gmail.com sign in