Scoping, analysis and estimation

Introduction

Aim

All of us do it at some time in our work place. In fact we do it all the time in our lives. Trying to figure out how much of our resources (e.g. time, money, effort) we need to achieve our goals. It may be an attempt to calculate expected expenses, throw a scrap of paper into the waste basket a few feet away or time required to write some code or whatever-whenever.

To better understand what is involved to get a job done, we need to do an estimate. The estimate itself depends upon our analyzing the scope of work. The analysis cannot be done correctly if the scope of work is not explained clearly. Understanding, explaining and documenting the scope of work is rather difficult. This is usually due to poor domain knowledge, complexity of the business, specific requirements of each customer and poor presentation of the workflows and processes. This article focuses on scoping, analysis and estimation from a developer’s view and not an analyst view while at the same time keeping in mind the above shortcomings.

Proposal

For this article, I will attempt to explain how to create a resource management tool. I will use the object hierarchy tree to identify business objects in my application, create some simple workflows to understand what needs to be done and identify the users of the application.

1.1 Vision

“To develop an easy to use, general purpose, resource management tool.”

1.2 Use cases

• Request a resource: A request is made by an authorized person for a resource to the concerned department.
• Identify a resource: The resource manager then searches for availability of any matching resources.
• Evaluate a resource: The resource is evaluated by the authorized person.
• Allocate a resource: The resource is assigned to a person or department.

1.3 Requirements for each workflow

1.3.1 Request for a resource

• Give the name of the resource.
• Give the type of the resource.
• Give the description of the resource.
• Give the reason for wanting the resource.
• Give the date of the request.
• Give the date by which the resource is expected.
• Give the approximate cost range expected for the resource.
• Give the importance of the resource.

1.3.3 Identify a resource

• Search for the requested resource.
• Display search results.
• View details of available resources.

1.3.4 Evaluate a resource

1.3.5 Allocate a resource

1.4 Identifying business entities.

Now comes the part I like. Using the limited documentation above, we can cover a lot of ground using a little thinking. We first identify the business objects as best as we can and then create an object hierarchy tree to understand them better.

First, let us start with a general object to represent the tool we are developing. I am calling it “Rap”. Then reading the documentation provided, I have identified possible business object and changed their font to bold-italic-orange.

Besides the business entities are the utility objects like the objects for data access, custom exception handling, logging, data formatters, security, constants and external interfaces. Also keep in mind regular objects like the users, forms, error and other message texts.

So using a combination of experience as well as the available documentation I came up with the following object tree. Now this isn’t the final story and based upon our further understanding we could revise the object tree.

The object tree gives me a better picture of what is involved in developing the application and would be easier to grasp than several thousand lines of documents. While this is not an OOP inheritance tree, it does involve similar thinking. So as we get into scoping and analysis, this tree will go on expanding and we would end up with several objects.

1.5 Map the objects to the workflows

This part of the scoping and analysis is used more for traceability. It helps us understand how are objects are connected to the workflows provided and justifies their existence. This has similarities to the activity diagrams used in UML. The objects are the “streams” and the nodes of the workflow are the “activities”.

We could debate exactly which workflow node belongs to which object. This is exactly what is needed to improve our understanding of the application. The more we try to fit things into the object tree and work flow map, the more we are able to identify what we still need to do to satisfy the requirements. The more we try to fit things into the object tree and work flow map, the more we understand if the requirements have any gaps or are self explanatory. It helps us realize if we have understood the customer’s needs correctly. For example, I did not identify the object “Data” until I tried to finish the mapping. And I still am not sure if the “Fill request form” workflow node should be with the “Request” object or the “Form” object. But I still feel that the above mapping gives me a clearer picture of what is involved here.

1.6 Estimating effort.

I had written two articles of my approach to estimation. They are How to estimate a software project and How to estimate a software project in man-hours.

For estimation, consider the following general points:

• Identifying the architecture, forms, classes, components and supporting documents required.
• Defining the structure and purpose of all the items.
• Writing test cases.
• Coding, code optimizing, unit testing and integration testing.
• Regression testing, performance testing.
• Deployment issues and acceptance testing.
• Beta testing and warranty.

I will focus on only two objects identified in this article as follows:

1.6.1 Forms

From the objects and workflow map we can now break down the details further almost to a GUI level. The forms in the figure object/workflow above would be the request and reasons forms. The request details are provided in section 1.3.1. Using this, we can arrive at the control types required in each form.

For example,

• Give the name of the resource -> label and text box.
• Give the type of the resource -> label and drop down list.
• Give the description of the resource -> label and multi line text box.
• Give the reason for wanting the resource -> label and multi line text box.
• Give the date of the request -> label and calendar control.
• Give the date by which the resource is expected -> label and calendar control.
• Give the approximate cost range expected for the resource -> two labels and two text boxes.
• Give the importance of the resource -> label and drop down list.

Most forms are placed inside a template divided into a combination of top, left, right, bottom and central sections. Each of these sections may contain dynamic or static information which has to be estimated separately. Again a document describing the form, the location of the controls and content, the human engineering effort, the time and effort to get the form approved from various stake holders are all part of the estimate.

From my experience, it would take at least two man days from concept to customer approval for this form.

1.6.2 Validater

The validater normally implements data integrity rules and business rules. Data integrity means the data has acceptable characters in it. A simple example being numeric data usually doesn’t include non numeric characters. Business rules would be verifying a value calculated during the process or a limitation rule like “A user cannot select more than one resource per request”. So I have defined two specific validation objects to do the specific type of validations, the “Business Rules” object and the “Valid Data Type” object. Now validations may be distributed across the different layers in an application. For example validating data types may happen only at the client in case of a Windows forms application deployed on a LAN. But the business rules would usually happen at the database tier and business tiers (if any). So while estimating the effort for the “Validater” object, remember that it could be used by different layers. Depending upon the form or set of forms, there could be more specific type of validater classes to be developed.

The (valid) validations I can think of for the above requirements are,

• resource name is mandatory.
• requester's name is mandatory.
• evaluation reasons for accepting or rejecting a resource is mandatory.
• size restrictions for text box values.
• dates to be in suitable format and range.
• type of resource should match to a predefined value.

From my experience, it would take at least two man days (again) to provide these validations including design, coding, testing and customer approval.

For both 1.6.1 and 1.6.2, we have identified some of the possible things to be done during development and we haven't even finished our scoping and analysis as yet. So the chances of discovering what more has to be done keep increasing and that too at a very low level where it is easier to judge the effort involved. This is a simple and not so crude way to estimate the effort.

1.7 Who qualifies as a beginner?

For any estimating, scoping or analysis, work knowledge of all development phases play an important role. And the steps mentioned in this article would be easier to understand if one has experience in development, design and testing along with a couple of end to end projects behind them. The advantage of this approach is that you could estimate applications and modules even if you do not know any industry accepted means of estimation like function point analysis. And you get three for the price of one i.e. estimating, scoping and analysis can happen side by side. Think of this as an intermediate phase to becoming an analyst, architect or even project manager.