Sizing Applications from User Perspective

Applications are software programs designed to perform functions for users or for other applications. Some examples of application include ATM programs for managing cash dispensing machines, word processors, database programs, web browsers, development tools, CAD/CAM programs for design work, and communication programs.

Application programs use the services of the computer's operating system and other supporting programs to perform a designated function, and programs communicate with other programs through the application program interface.

The idea here is not to illustrate how to build an application but how to make a high level estimation of its size from a user’s perspective. After having analyzed its size it’s possible to estimate the cost required to build it. 

Applications can be big and complex or small and simple. People use web applications to order products online, make reservations for hotels, apply for jobs and so on, also, use mobile applications when on the move or travelling and, furthermore, use specific applications to communicate with cash dispensing machines to take out money or for business purposes to manage stock, to meet their customer needs and other aspects of their business.

An application that needs to interface and interact with users can be characterized by a certain number of elements. These elements in a way govern the application and they are: wireframes, use cases, business rules, data tables, reports and correspondences. The size of an application can be determined by the number of these elements. For the purpose of illustrating an example, a simple hypothetical case is taken into consideration.

Application
Number of Elements
Wireframes
Use Cases
Business Rules
Data Tables
Reports
Correspondences
10
50
90
100
10
15
Estimated effort to develop one element of simple complexity level in man-days
3
5
3
3
2
2
Development Effort (man-days)
30
250
270
300
20
30
Estimated effort to capture one element during the analysis phase of simple complexity level in man-days
3
3
3
3
1
1
Analysis Effort (man-days)
30
150
270
300
10
15
Total Effort (man-days)
60
400
540
600
30
45

Legend of elements:
-Wireframes are user interfaces and it’s the way the user communicates with the application.
-Use Cases describe how a user interacts with the application in a procedural way.
-Business Rules govern the flow of procedures and data.
-Data Tables are the data required for the application to perform its function.
-Reports are printable information.
-Correspondences can be notes, messages, and emails.

N.B.- All of the above elements are managed by the application. The numbers in the table above do not refer to any industry standard, they are all hypothetical numbers just for calculation and illustration purposes.

Mathematical format:

By introducing hypothetical unit rates per day it’s possible to calculate the relative and total costs.

-Development unit rate per day = $300 
-Analysis unit rate per day = $500
Putting data in table format:

Costs
Total Effort Development in man-days
900
Developers rate per day in $
300
Developers Cost in $
270000
Total Effort Analysis in man-days
775
Analyst rate per day in $
500
Analysts Cost in $
387500
Total Cost in $
657500

All data in this example is hypothetical. For better accuracy it’s possible to add more variables and factors to this approach.

Popular posts from this blog

The differences between Project, Operation and Program

Using PERT for estimating tasks

Forecasting Project Costs using Variance Analysis