Custom Software for Wholesaler & Retailer Dealer
Our client, a wholesale dealer and retailer of commodity items was looking for a system that would integrate their fragmented business into one. Their existing IT infrastructure was presenting following problems.
- Since each functional unit within our client's organization created, updated and maintained their own databases, this led to problems like data redundancy, increased chances of errors and flow of information was not proper.
- High cost of maintenance of separate systems, also there was high cost involved for reentering and reformatting data from one system for use in another.
- High lead time for a customer order to be processed. This was due to poor synchronization between retail outlets, warehouses and suppliers.
Our client, being a wholesaler and retailer decided not to go for generic, off-the-shelf solutions but to build their own proprietary software. After detailed analysis, they realized that they would lose their competitive advantage that came more from services and prices than the quality of the product if they implemented a generic solution that was present to their competitors too.
Note: Some of the information in this case study is protected to respect our NDA with the customer. Our client does not want to disclose that it has used the services of an offshore software development company for its developing its mission critical application. All the information shared in this document has been discussed with our customer.
- Whenever a customer's order was made, the sales order was recorded. The client's credit limit and past payment history was checked with the financial department.
- The sales order was released to the warehouse where it inventory level was checked. In case the inventory fell short of the current order or it went below the minimum inventory level, then order was placed to the supplier.
- Delivery documents were released to the warehouse. Items were picked; orders were packed and shipped.
- Sales order data was sent to financial department used to create an invoice. Quantity discount was given based on the sales order data. Customer's accounts receivables was increased and credit limit was accordingly adjusted.
- After payment was accepted, customer's accounts receivable was decreases. All other financial information like sales person's commission, balance sheet, ledger was updated.
This web application uses N-tier client/server architecture. N-Tier architecture produces a far more flexible and scalable client/server environment. In this model, both the presentation layer and the middle layer are handled by the client. N-Tier architecture has a presentation layer and three separate layers - a business logic layer, a data access logic layer and a database layer. ASP.Net was used for developing this application. SQL server 2000 was used as DBMS The following section discusses each of these layers in detail.
- Presentation Layer: This is a front-end component, which is responsible for providing portable presentation logic. Since the client is freed of application layer tasks, which eliminates the need for powerful client technology. The presentation logic layer consists of standard ASP.NET web forms, ASP pages and documents. This layer works with the results/output of the business logic layer and transforms the results into something usable and readable by the end user.
- Business Logic Layer: Allows users to share and control business logic by isolating it from the other layers of the application. The business layer functions between the presentation layer and data access logic layers, sending the client's data requests to the database layer through the data access layer.
- Data Access Logic Layer: Provides access to the database by executing a set of SQL statements or stored procedures. This is where we write generic methods to interface with data. For example, we write a method for creating and opening a SqlConnection object, create a SqlCommand object for executing a stored procedure, etc. As the name suggests, the data access logic layer contains no business rules or data manipulation/transformation logic. It is extensible interface to the database, and the client plan on migrating to either SQL server 2005 or Oracle when the user base grows.
- Database Layer: Made up of a RDBMS database component such as SQL Server that provides the mechanism to store and retrieve data. The customer has plans to explore using SQL server 2005 or Oracle.
To ensure quality deliverables we have replicated production environment including volume of data. Note that all the data is scrubbed before it is downloaded to our development center to protect against random emails or testing information being sent to the actual end customers.
Our engagement model was onshore-offshore model. Our team comprised of project manager, business consultant, account manager, architects, team leaders, developers and quality analysts. We worked closely with the in-house IT team of the client that consisted of project manager and an architect.
Our business consultant analyzed the entire business process to understand our client's business requirements. This detailed analysis was done with the purpose to align the IT systems with existing business process and requirements. Also, detailed analysis of the existing system was done at the inception phase too, so that migration of data could be simplified.
The architecture of the system was then designed by the architects from both the sides, based on the business requirements captured by our business consultants. Our team leader was then responsible for developing code based on the architecture designed, managing his team and preparing the status report. The developers were responsible for developing test cases, developing codes, doing independent unit testing, cross development testing and documentation. The quality assurance team was then responsible for setting up test environment and test databases, performing testing services like integration, functional, compatibility and performance testing. They also defined user acceptance tests. In addition to the human oracle, test automation tools like JMeter, e-Test suite were used. All the data was scrubbed before it was downloaded to our development center to protect against random emails or testing information being sent to the actual end customers. Also, we have standard process and algorithm for data scrambling. This ensured that all confidential information of our client was replaced by similar but artificially generated data.
The team leader, with our onsite team was responsible for seamless integration of the system with the business process. Data migration and system testing was done. The old system and new system were run simultaneously for a short period, and when the quality of the system was ensured after which the old system was abandoned.
Our project manager, who was responsible for technical and contractual success of the project, acted as a coordinator between our developer team and the client. All technical and/or other issues were discussed with the client on a timely basis.
We adopted the Spiral Progressive Approach to deliver a project for the initial delivery. This approach follows an iterative Development model through which the development phases are revisited with a feedback loop from forward stages at the end of critical milestones/changes. In this approach at one particular time all discipline of projects are active but their active percentages are different, This is equivalent to saying that at one particular time we will be doing a% requirements, b% design, c% construction, d% deployment.
The main benefit of this approach is that we are able to incorporate end user feedback about the website usage very quickly in the main website. This process has helped in releasing some of the features even in a turn around time of a few days. UML is used as a base modeling language in each phase.
- Migration of data: The legacy applications used in different functional units had redundancy of information. Also, there were times the redundant information did not match. Also, at one time, the knowledge transferred on the databases that were used did not match the exact database and so our development center faced problem in replicating the database. However, these issues, after effective communication were sorted out soon and it did not effect the time or budget of the project.
- Quality Assurance: This project had continuous weekly targets with critical requirements. It required faster turn around time to fix the bugs reported. Uploading the changes were also very critical with little window for downtime. We have continuous focus on ensuring high quality with each release build. The QA team goes through test cases on staging server rigorously and Release Candidate 3 (RC3) build is released to production server after three rounds of testing.
- Co-ordination with our client's team: Our global operations for the web development run round the clock, and it's always critical to maintain effective communication with the team based in the US . We have employed task assignment and knowledge sharing tools to capture all the discussion threads.