Estimating Return on Investment

Overview

In this example, we will have invented a fictitious company called Acme Paint, to illustrate the potential return on investment (ROI) provided by Visible's Model Driven Architecture (MDA) Solution, which includes the Visible Analyst and Visible Developer. Acme is planning their first web services software project using Microsoft's .Net technology. A staffing plan and schedule is created, based on certain assumptions about:

• Expertise in distributed application design
• Familiarity with .Net platform
• Size of application

In this scenario, Acme is redesigning and modernizing its inventory management system (IMS) written ten years ago. IMS is a client/server application written in a 4GL with a backend relational database. There is only one employee left who can maintain IMS and the people with skills in the 4GL are difficult to find and very expensive.

The IMS database duplicates information in other corporate systems and requires additional interface programs to synchronize overlapping data. Although IMS fulfills Acme's basic needs, there are many new features that users have asked for but IT cannot provide because maintenance is time consuming and difficult.

Acme would like to update IMS, add new features, and move it from the proprietary 4GL technology to a new widely adopted .NET platform.

Planning the Project

The project work plan consists of four phases:

• Requirements Analysis
• Database and System Design
• Application Development and Test
• Maintenance

Each phase is broken into tasks and staffs with appropriate skills are assigned to each task. Two work estimates are created for each task: the first is based on traditional tools and methods and the second is based on the same work done with Visible's MDA Solution.

Visible Cost Savings Estimator

Savings

Assumptions

Requirements

Traditional

Scenario assumes a small requirements effort because the project is upgrading an existing system. Two business analysts are working full time over a 2 month period. A database engineer works part time to assist the analysts in understanding and documenting the business information managed in the IMS database.

During this task the analysts capture documentation on the existing IMS application from a variety of sources and present the results to business experts for confirmation.

Because the IMS system has been in maintenance for nearly 10 years whatever system documentation exists is probably out of date.

Visible Solution

The corresponding tasks using Visible's solution are identical. The difference is in how the results of the requirements analysis are documented. The traditional method typically produces text documents whereas Visible's solution captures requirements as interrelated models in its repository.

The advantage is the accuracy, quality, and the ability to later use the more rigorous .NET models in subsequent phases. Since analysis tasks require intensive interaction with business experts, this phase has the smallest savings in effort.

Design

Traditional

The database engineer produces the physical IMS database in this phase. The first step is to design the tables, fields, foreign keys, etc. that define the physical database schema using DDL. This is essentially a programming task and as the requirements change the DDL must also be modified.

Writing stored procedures to access and maintain business data stored in the IMS database are written in the SQL programming language. While DDL and SQL are recognized standards, subtle variations exist for most DBMS products. The DDL and SQL has to be carefully examined and changed if the underlying DBMS later changes.

The software engineer designs the software components in sufficient detail so less experienced programmers can later write the detail code. We assume the senior software engineer uses UML to define the software components in the traditional approach.

Visible Solution

The data and process models produced in the requirements phase are the primary input used by the senior software engineer when creating software components. But instead of using UML, which is a very technical description, the engineer uses Visible Developer's intuitive, business-like concepts. The resulting model can be reviewed with business experts and even developed interactively.

The estimates include a very significant one-time saving in developing the corporate standards and practices for distributed, .Net applications. The scenario assumes this is the first .Net application built by the organization and entails a large learning curve. In the traditional approach, a senior software engineer must be the 'pioneer' and blaze the trail for others to follow.

However, .Visible Developer has the needed expertise and best practices built into the code patterns. Instead of spending months experimenting and discovering what works best - the senior engineer studies Visible Developer's generated code. And since code is generated automatically from the models, every application is guaranteed to follow these standards and practices.

Development

Traditional

The UML specifications used in the traditional method provide a programming 'shell' that is only the starting point. Each developer must add the detailed logic to make a functioning application. A typical UML design might provide 10% of the code in the final application. The remaining 90% is hand crafted by a programmer.

The large percentage of 'personalized' code makes maintenance more difficult later because the person who originally wrote the code is on another assignment or left the company.

As requirements continue to change during the phase, rework is constantly required and it is difficult to maintain consistency between the requirements documents, design documents, and the actual code.

Visible Solution

The investment in Visible's models pays its largest dividend during the development phase. The consistency and rigor of the models combined with the power of the code patterns makes it possible to generate 90% of the code the business logic and database access.

Using Visible Developer, time is spent writing business rules logic, often interactively with the business expert. The code patterns take care of the technical details and allow developers to concentrate on adding true business value.

The UI portion of the application also benefits from Developers code generators, but to a lesser extent because user interfaces are not easily standardized.

Maintenance

Traditional

In the scenario we consider maintenance to include fixing problems and incrementally adding new features.

Using traditional approaches, maintenance is time consuming and error-prone task. The chief difficulty is determining what code needs to be changed because a simple, at least to the business user, new feature might cause impacts that ripple throughout the application.

If the developer has to write 90% of the code, as is the case in the traditional method, then 90% of the code requires manual maintenance.

Visible Solution

The maintenance phase vividly demonstrates the power of Visible's model-driven approach.

The most compelling difference is the amount of code that actually needs to be maintained. Since Visible Developer can generate 90% of the business and database access logic, which is typically 10 time more than the traditional approach, there is 1/10 as much code to maintain.

In many cases, maintenance is done by modifying the model of the application in Developer and regenerating the code. If a business rule changes, the corresponding code is easily found and the change is isolated to one piece of code.

Finally, since the information in the model is tightly integrated, the developer can see an impact analysis report to determine what other portions of the application need to change.

If you would like a copy of this spreadsheet to do your own cost savings estimations, please contact the Visible sales team at 781-778-0200.

When you open the Excel spreadsheet, “Cost Calculator”. It contains six worksheets:

To view a particular worksheet, click on the corresponding tab on the bottom of the spreadsheet.

A detailed breakdown of the cost estimates on the first work sheet, Summary, is shown on the Design, Development, and Maintenance work sheets. On the detail worksheets, estimates are broken down by labor category and task. To view the individual work tasks, click on the “+” in the left hand margin of the work sheet.

Cells containing a red triangle in the upper right hand corner have a brief comment that explains the contents. To view the comment, move the cursor over the cell or click in the cell and the comment will pop up.