Contrast With Waterfall Development Method Information Technology Essay

The requirement specification document describes the functions and requirement for the Inventory Management System which is also known as Inventory control system. The system is needed to ensure that the super markets are stocked at all times and to effectively and efficiently controlling the inventories. The IMS should alert those occupy management positions in the super market of products which are selling and those that are gathering dust and taking up warehouse shelf space. It is financial management best practise for any business selling products to have the correct balance of safety inventory to accommodate seasonal demands and not be caught off guard by the customers as reputations are at stake. IMS keeps track of sales, available inventory and communicates with suppliers in real time for inventory reordering purposes.

1.2 Scope

The inventory management basically deals with the order quantities, order intervals and finally the complete inventory management system. Inventory management system will assist the management of the super markets in quickly and efficiently ordering and keeping track of inventory for accounting purposes, the system will reduce the traditional paperwork and time consumption which shall in turn lower costs.

Barcodes at cashiers are the exit points of inventory and updates the inventory database to keep track of stock.

According to Wikipedia (2011) ” Another promising technology for tracking inventory has also has made its way into stores, warehouses and factories. Radio frequency identification, or RFID, uses a microchip to transmit product information — such as type, manufacturer and serial number — to a scanner or other data collection device. It’s superior to bar codes in several ways. For instance, a scanner reads the information from an RFID from several yards away, making it ideal for tracking items stacked on high shelves in warehouses. It also can encode more data than a bar code and in some systems tell merchants if an item is out of place in the store, providing excellent anti-theft characteristics.”

But the Inventory management system that we will be looking at will not incorporate the RFID technology.

Development methodology

To develop the inventory management system, an Iterative and incremental development methodology approach will be adopted (figure1).

The iterative and incremental development methodology being part of the prescriptive process methods allows the developers of the system to excessively exhaust the stages of the software life cycle. The aim is to have multiple deliveries of working software with increased functionalities over time, since the requirements are derived from cross-functional teams.

Figure1 IID method, Roger S. Pressman (2001)

The system is developed in small portions of functional requirements over a period of iterations and each iterations time is shorter than the previous iteration time due to that the system developers have the advantage of what was learned in the previous iteration. Each iteration allows modification and new functional capabilities according to user feedback, which will reduce overall project risk, iterations can overlap and risk is spread out over iteration.

According to Pascal Van Cauwenberghe (2011) “

In the first iteration we will do 90% analysis, 10% design

In the second iteration we will do 30% analysis, 50% design, 20% coding

In the third iteration we will do 10% analysis, 30% design, 70% coding

In the fourth iteration we will do 10% design, 50% coding, 40% testing and bug fixing

In the fifth iteration we will do 50% testing and bug fixing, 30% integration, 20% deployment.”

It’s a good for projects where funding is not assured, as supermarket is a competitive market.

2.1 Contrast with Waterfall development Method

Although is it a cheaper approach of system development and the most experienced or oldest method, there are a few issues that make it not a viable approach. The stages are exactly the same as in Iterative and incremental approach. The only difference is that waterfall model does not support iteration of the stages and the IMS will only be delivered all at once at the last stage and no backtracking will be possible. The corrections can only be made during the maintenance stage. On the customer or user side progress is only observed at later stages. Customer or users unsure of the requirements at the early stage of the system development will face length development time and soaring costs. It’s for projects that have a relatively low risk and the IMS is a medium risk program.

Figure 2 Source: Google Images

2.2 Contrast with V- Shape Waterfall development Method

The V shape waterfall method was introduced to better the issues that are experienced by a traditional waterfall model. Testing is highly emphasised on each development stage in the V shape model and it does not support exhaustive repetition of the stages, major requirement changes and risk are only discovered later and corrections are to be made during the maintenance stage. In the case of the Inventory management system so much emphasis should not be put on testing the system but the user requirements are much more important. V-shape is suitable for critical systems like airplane, hospital systems.

Figure 3 Source: Google Images

2.3 Contrast with Prototype development Method

It is classified the same as iterative and incremental approach, the only difference is that after each iteration a working prototype system is produced and customers do an evaluation. Prototype development is less manageable than iterative and incremental development as the normal software process standards are followed. Users of the system should be willing to learn how to use each prototype produced, this can be time consuming (schedule), costly to the supermarket and users end up mistaken the prototype to be the final system. It is more suitable for medium to high risk systems where requirements are all known as the system evolves and system must have rapid software changing technology. In this case all the application characteristics mentioned above are not worth to follow for the inventory management system. According to stsc.hill.af.mil (2008) the prototype or evolution model is not useful when the system being designed needs to interface with another system, and the inventory management system will need to interface with the Point of sale (POS) system.

Figure 4 Source: Google Images

According to (2009) “Risks may be increased in the following areas:

Requirements – Temptation to defer requirements definition.

Management – Programs are more difficult to control. Better government/contractor cooperation needed.

Approval – Vulnerable to delays in funding approval, which can increase schedule and costs.

Architectural – Initial architecture must accommodate later changes.

Short term benefits – Risk of becoming driven by operational needs rather than program goals.

Risk avoidance – Tendency to defer riskier features until later.

Exploitation by suppliers – Government bargaining power may be reduced because initial contract may not complete the entire task, and subsequent contracts are not likely to be completed.

Patch works quilt effects – If changes are poorly controlled, the product quality can be compromised.”

2.4 Contrast with Spiral development Methodology

The main aim of spiral development model is to reduce risk in the software life cycle stages. It combines or is made of a combination of development methods namely waterfall, prototype, and Iterative and incremental but can also accommodate more models. The model is in spiral shape and it allows each stage to be repeated likewise the iterative and incremental but great emphases is put on identifying highest risk problems and mitigating the problems in each cycle. It allows incorporation of new technology and innovation unlike iterative and incremental model, but since this an inventory management system for a supermarket cost and schedule (time) plays a great limitation on using the spiral model due to its complexity and hard to manage. Software development projects that require or use the spiral development model is usually Department of Defence or aerospace projects. Spiral model is more useful where user needs are important.

Figure 5 Source: Google Images

2.5 Contrast with Rapid Application development Method

According to Wikipedia (2010) “Rapid application development is a software development methodology that involves methods like iterative development and software prototyping.”

Rapid application model falls under agile methods, which makes it a fast and reliable development approach which reduces cost while maintaining system quality. Initially a prototype system is designed and improvements are made on that prototype to be the finished system, but if some features of the Inventory management system are not included in the initial stages then they are shifted to the next system version. So scalability and the features are reduced. Rapid application method is usually used in an environment that is data driven and data batches are processed without user intervention. But in this case the Inventory management system is transaction processing application.

Figure 6 Source: Google Images

2.6 Contrast with Component based development Methodology

Component based approach is a reusable software unit. It was introduced to improve object orientated development non support for effective reuse. All though it’s a faster way and cheaper approach of developing a system by just getting different components and interfacing them to one another, you may in counter maintenance difficulties, which may turn out to be costly due to replacement of component software units. The supermarket IMS system needs to be available at all times for the smooth running of the daily operations and the functional requirements will only be fulfilled on the availability of the components. Customer need to clearly understand the component specifications, so an ignorant customer will not pay attentions to the component specifications. Component trust is another issue.

Figure 7 Source: Google Images

Functional and Non Functional Requirements

Definitions adopted from lessons-from-history.com

“A requirement specifies a function that a system or component must be able to perform.”

“A non-functional requirement is a statement of how a system must behave, it is a constraint upon the systems behavior.”

3.1 Functional Requirements

Allows user defined supplier types

Allows unique supplier address and contact information for supplier corporate address, remit to address, and ship to address.

Allow automatic backorders of inventory by super market

Provides minimum and maximum receipt allowances by supplier

Allows recording of last price paid for a product by supplier

Supports online inquiry or report to compare actual vs. expected purchase costs

Tracks supplier performance on late deliveries

Tracks supplier performance on order fill rates

Supports inventory specific unit of measures

Supports basic Internet based purchasing functionality to supplier

Monthly detail by cardholder customer and invoice

Graphic trend charts by cardholder customer, cashier, product type, and others

Supports sales analysis by product and supermarket

Daily activity report by supermarket

Print Inventory breakdown by supermarket

Support Standard Report for Back Orders

Support Standard Report for Inventory Adjustments

Support Standard Report for Inventory Transactions

Supports Stocking Specific Unit of Measures

Supports Purchasing Specific Unit of Measures

Supports Minimum and Maximum Stocking Levels by product number and super market

Supports Safety Stock Calculations for Replenishments by product number and supermarket

Manage interface to supplier

Manage interface to Point of sale (POS)

3.1 Non-Functional Requirements

Sufficient network bandwidth

System accessibility

System audit ability

System configurability

System backup

System disaster recoverability

System efficiency

System extensibility

System security

System installation

System main ability

System testability

System usability

Robustness

System performance

ERD Diagram

Figure 2 Inventory Management ERD by freesoftwarebusiness.com ( 2011)

Figure 3 Inventory Management UML by inventory-system.com ( 2011)

Project schedule chart

See attached sheet for the Gantt chart. The below data is only there to explain the tasks in details.

Task 1: System feasibility – Is Part of the SDLC, with the aim to determine whether it worthy to develop the system. It will be focusing on Technical, Economic, Operational and Schedule.

According to the free dictionary.com (2011)”

Technical Feasibility: does the technology exist to implement the proposed system? Is it a practical proposition?

Economic Feasibility: is the system cost-effective? Do benefits outweigh costs?

Operational Feasibility: are the current work practices and procedures adequate to support the new system?

Schedule Feasibility: can the system be developed in time? “

Task 2: Software Plans and Requirements – Is part of the SDLC, with aim to gather requirements of the system (IMS) to be developed. Timeline is important but is difficult to predict as customer requirements can change anytime and it can cause delay. According to Wikipedia (2011) the following requirements are important.

“Customer Requirements: Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints by the customers.

Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished.

Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviours.

Architectural requirements explain what has to be done by identifying the necessary system architecture of a system. “

Task 3: Software Design – Is part of the SDLC, which is a critical phase because, it determines the quality of the software. The requirements are mapped into the architecture, the coding of the system is performed, the interface between the subsystems is coded, the system is delivered or implemented and the system is operational and maintained.

Architectural distribution, Platform, Hardware and software requirements

Regarding the architecture distribution of the Inventory Management System a 3 tier approach should be adopted for the project, consisting of the client process, application and database server. The application server will also act as firewall, to restrict unauthorized access. This architecture is scalable and new servers can be added as the number of clients increase. According to Ian Sommerville (2007), the use of three-tier architecture allows the information transfer between the servers to be optimised and low level communication protocol between the systems can be used. “Applications where both the data and the application are volatile. Applications where the data from multiple sources are integrated”

Client Request

Application Server

Reply

Command Result

Database Server

6.1 Client

The minimum requirements are noted below.

Platform:

Windows XP Professional and above

Hardware:

Standard Computer: Processor 1.70 GHz and Above, RAM 512 MB, Hard Disk 20 GB, Keyboard ANY, Mouse ANY, Monitor ANY, CD ROM Drive Receipt Printers

Cash Drawers

Pole Displays/Customer Displays

Magnetic Stripe Readers/ or chip reader

Bar code scanner or reader

Software:

Microsoft word, excel, PowerPoint (standard), antivirus ect.

6.2 Application Server

The minimum requirements are noted below.

Platform:

Windows Server 2008

Hardware:

Processor 4 core, RAM 8 GB, 80 GB HD, Keyboard ANY, Mouse ANY, Monitor ANY, CD ROM Drive

Software:

Microsoft .NET Framework 3.5 SP1

Application Server role

Web Server (IIS) role

SQL Server 2008 Native Client

Anti Virus

6.3 Database Server

The minimum requirements are noted below.

Platform:

Windows Server 2008

Hardware:

Processor 4 core, RAM 16 GB, 160 GB Hard drive SCSI, RAID 1, 1GB Ethernet card, Keyboard ANY, Mouse ANY, Monitor ANY, CD ROM Drive

Software:

Microsoft SQL Server 2008

SQL Server 2008 Native Client

Microsoft .NET Framework 3.5 SP1

Application Server role

Web Server (IIS) role

SQL Database backup software

Anti-virus

Test plan for the system

Testing may be easier on smaller portions of the system.

Unit testing: Each module will be tested.

Integration Testing: linking and testing new code with previous written code that has already been integrated.

Function interface testing: Testing will be done at the different functions interfaces, as it’s a area that is prone to errors.

System testing: The software is executed to find traces of defects, bugs and errors. This will intent help in grading the quality of the system