Partner Developed Solution Estimation Guidelines
A reasonable attempt should be made to estimate how much resources will be used by a solution. The types of things that should be evaluated are Storage, Bandwidth and Processing Time. Each solution should provide this information to guide both the consumer as well as the host what can be expected. As much as possible, quantitative guides or results from testing should be provided.
Expected User Profile / Intended User Access
In this section, describe the typical users of the solution, as well as their corresponding level of access.
Example
| User Profile | Intended User Access |
|---|---|
| Corporate Finance Personnel | Review global consolidated forecast |
| Functional Managers | Prepare sales forecast |
Storage
Each solution will have different uses for RDBMS storage. Some may have no extra requirements while some may have custom tables with regularly stored data. Data may be stored as the result of user operations or system operations. Some examples:
Example 1
Solution regularly captures bits of information on a schedule and stores them to custom table. This example can calculate#e almost exactly how much storage is needed over time:
- Each record is 256 bytes
- Information is captured once a minute and a record is created on that frequency.
- Amount of data stored per day: 256*(60*24) = 368,640 byes = ~1/3 MB per day
- Amount of data stored per quarter: ~90*368K = ~33MB/Quarter
Example 2
Solution will save a record every time a user performs a particular action:
- Each record is 1MB
- It is estimated that 20 users will perform an operation 3 times a week.
- Amount of data stored per week: 3031MB = 90MB/Week
- Amount of data stored per quarter: ~12*90 = 1,080MB/Quarter
| Describe Expected Data Storage |
|---|
Bandwidth
The amount of information passed over the network can have a significant impact on both cost to the host as well as response time. Depending on the connection, the response time may vary proportionally with the size of the payload. It is important for the developer of the solution to have a sense for what information is being packaged for sending as well as receiving. An example of a non-obvious use of bandwidth (from a user’s perspective) is a sparse grid where 10,000 rows are retrieved but only 4 are shown. If the filtering is being done on the client side of the network then a large amount of data will be transferred for a small amount of data to be presented in the user interface.
Example
Solution presents some analysis after retrieving an entire account hierarchy for all entities along with an account value for each member.
- Solution should document that large applications may have a large result set for this operation. Developer should report the size of the structure for a known sample application as a data point.
| Describe Expected Bandwidth Usage |
|---|
Processing Time
Solutions may offer user interaction options that result in long processing times on the server. Any server operation that takes more than a few seconds should be handled with one of the following options:
- Operations of possible long durations (>10 seconds) should use Asynchronous processing: Request is made and control is immediately returned to client. A message box stating that operation is being processed along with guidance on how/where the user can find results of operation.
- Operations of possible shorter durations (3-10 seconds) should use a Spinner indicator. It is documented that users lose faith in a spinner after approximately 10 seconds and may attempt to start the operation again. Doing so could cause undo load on the server.
- Operations of long duration that require synchronous operation: If an operation is required to be synchronous but may take longer than 10 seconds then a percentage complete indicator is desired. Implementing this will require the developer to have some feedback from the server to update the UI appropriately unless the operation is a multi-part operation from the client-side in which case the status is known at the client and can be presented as such.
| Data | Source | Average Records | Frequency |
|---|---|---|---|