A3, Inc.

CPSC 547

Dr. Chen

Measurement Process Plays a key role in an enterprise IT environment.

Begins with planning and involves Selecting and defining product process measurement

Integrating the resulting measurement activities into organization’s existing software process.

Identify issues during the software development.

Software projects have been failing due to poor project planning and time estimation.

Estimation process reduces the risk around schedule and cost.

Estimation also helps the cost of delivering business functionality and provides a starting point for managing the schedule and cost of a project.

How would we solve the problem? (next slide…)

Improve estimation of building software, or the phases of various software cycles.

Abstract software requirement into different modules by using OOD techniques of abstract classes and interfaces.

Decompose requirements into manageable chunks. These chunks are then abstracted and their abstractions

are categorized. The abstraction categories are then estimated and recorded.

Over time there will be significant data representing the estimates of each abstraction category.

Collect the data to visualize the measurement process in order to investigate the cause and as result this project will improve overall productivity of an organization.

Software requirements are documented clearly in software requirements specification document.

Abstraction represents the essential characteristics of an object that differentiate the object from the all kind of various objects and thus provide crisp defined conceptual boundaries, relative to the perspective of the viewer.

Goal of this project is to abstract the software requirements into similar categories. And use object-oriented analysis techniques such as abstraction and estimate the time and cost by using measurement techniques.

For the estimation and data collection, this project will use decomposed requirements or individual chunks of the information.

For this purpose, these individual chunks will be recorded so that we can apply measurement technique.

For the measurement these chunks will be used as the data elements.

This project will use various tools for understanding of the collected data. This is because as we collect data to visualize the abstracted category or to investigate

Problem, and improvement

This project would use tools such as Control charts, scatter diagrams, cause-and-effect diagrams.

As time goes on we will gain significant data to measure.

The data could be represented in a table of abstraction categories and the estimate times for those categories.

Using this table we could create a scatter plot for example to analyze the data and find useful statistical information such as the mean and standard deviation.

Over time, we should be able to reduce the standard deviation and get more and more accurate estimates.

The technique described in this paper relies heavily on use cases since they consist of the strategic goals and scenarios that provide value to a business domain.

Use cases also provide insight into an application’s complexity.

A use case defines a goal-oriented set of interactions between external actors and the system under consideration.

Use case driven analysis helps manage complexity, since it focuses on one specific usage aspect at a time.

Use cases encourage designers to envision outcomes before attempting to specify outcomes, and thereby they help to make requirements more proactive in system development.

The first sub-phase of the analysis phase is determining user requirements.

Future users should be involved in the process early on so that their views of the system are taken into consideration.

Using the SRS, this technique would carve out the abstractions into categories necessitating the framework itself.

SRS would provide feedback to the customer and decomposes the problem into component parts.

It serves as an input to the design specification as well as a product validation check.

Two Phases Project Planning Phase

Project Post Mortem Phase

In the first step we analyze the use cases and software requirement specification in an attempt to retrieve an abstraction of both the functional requirements and the quality attributes.

Our goal is to parse out the generalization of the requirement without the fine details.

There is a series of steps that we can take to retrieve an abstraction of a requirement.

We first combine functional requirements (FR) with the quality attribute requirements (QAR) to understand the full scope requirement (FSR). FR+QAR = FSR

Then we reduce the fine details of a requirement. To do this we repeat the following steps: Analyze each FSR to categorize it into a hierarchy. The hierarchy

should represent a tree like structure with the most general concepts at the top and the most detailed concepts at the bottom.

Analyze a leaf at the bottom of the tree and determine if the essence of the FSR will remain stable if a leaf is removed.

If it doesn’t destabilize the essence of the FSR, then remove the node.

Repeat steps b and c until no more leafs can be removed without destabilizing the essence of the FSR. At the end we will have an abstraction of the full scope requirement (AFSR).

Compare with Existing Abstractions Catalog Here we compare the AFSR with the existing AFSR

catalog.

If no catalog exists this is where we would create one.

The catalog entry should contain the AFSR ID and its accompanying FSR for reference.

ID AFSR FSR

0 {detailed name of the abstraction} {detailed description of the functional requirement as

well as any quality attributes that apply}

1 … …

Create New Catalog Entry if Required If the AFSR does not exist in the catalog we need to create a

new catalog entry unique to this AFSR.

Re-factor Existing Abstraction Catalog if Required This is a critical step and one that has to be thought about

thoroughly. Once we have compared the AFSR with the catalog and have

determine that we have found a match, we must determine if re-factoring of the existing catalog is required.

We do this by determining if the existing AFSR and FSR list are comparable in essence to the new AFSR that is about to be entered.

If not then we need decompose the AFSR into two (or more) more detailed AFSR’s that capture the essence of the requirement at a finer level of detail.

Analyze Existing Data for Abstraction Category Based on Historical Data Here we analyze the existing data that we have

accumulated over time for a particular AFSR. This data is an accumulation of the estimated time vs.

actual time it took to complete the FSR post project mortem.

The goal here is to get an understanding of how much data we have collected, and how far off we were in our estimations in the past.

We can also determine what the mean and standard deviation for the actual time spent for a particular AFSR.

ID AFSR_ID Estimated_Time Actual_Time Delta_Time

0 {id of AFSR} {Estimate} {Actual Time Spent} {+- original estimate}

1 … … … …

Enter Estimate for Requirement into Database in Relation to Abstraction Category

Finally, using the historical data we have we can systematically come up with an estimate for the given AFSR. We then record this data in relation to the AFSR ID for future analysis.

Step 1: Generate a report This report contains following data

a) The list of AFSR

b) How much original time was estimated for each AFSR?

c) How much actual time took for the corresponding AFSR?

d) Delta Time

Step 2: Analyze the delta between original time and actual time and finding the root cause. At this stage we will determine the root cause of delta's time

for each AFSR items For instance, AFSR_ID 0 delta time, we found out that

development phase took longer than expected time. This is because, the developer who developed the AFSR 0 functionality was trying to use new technology because of new security requirement. Moreover this security requirement was added later in the development phase. As a result, it took longer.

Thus, by the end of this phase we will find the root cause of each delta. In addition, senior management would also obtain a clear picture of the project and determine whether the product was under budget and on time.

Re-factor Existing Abstraction Catalog if Required Following are the step for re-factoring existing abstraction

catalog phase Step 1: Collect the list of AFSR with delta. Step 2: Identify the root cause of delta for AFSR from post project

mortem phase Step 3: Go through with the list of abstraction catalog (AFSR) Step 4: Determine if the existing catalog entry has the same AFSR

but different FSR. This can be determine during the root cause phase

Step 5: if same AFSR has different FSR Then re factor the existing AFSR

Thus by re-factoring activity, we can predict the output accurately and as a result organization productivity will be increased.

To help clarify this framework let us go through an example.

For the sake of this example let's assume the prerequisites are in place and we have the appropriate use cases and software requirement specification.

Let's say that the product is a simple form of application that allows the user to securely enter in their address into the system to become a part of a mailing list.

Determine Functional and Quality Attribute Abstractions

1. FR = Enter in address

2. QAR = Secure transaction

FR + QAR = FSR

Hierarchy FSR

ID AFSR FSR

0 Secure Data Capture The system shall allow the user to enter their address to be a part of a

mailing list. The system shall have the quality attribute of security

implemented by SSL.

1 … …

ID AFSR_ID Est_Time (hours) Actual_Time (hours) Delta_Time (hours)

0 0 6 5 -1

1 0 5.5 6.5 1

2 0 6.25 6.5 .25

ID AFSR_ID Est_Time (hours) Actual_Time (hours) Delta_Time (hours)

0 0 6 5 -1

1 0 5.5 6.5 1

2 0 6.25 6.5 .25

3 0 6.375 ? ?

Analyze Original Estimate and Actual Effort Here we need to analyze our data again. More

specifically we need to analyze our original estimate and the actual result.

ID AFSR_ID Est_Time (hours) Actual_Time (hours) Delta_Time (hours)

0 0 6 5 -1

1 0 5.5 6.5 1

2 0 6.25 6.5 .25

3 0 6.375 6 .375

After recording our data we need to pay special attention to the delta time, which is the difference between the estimate time and the actual time. For example if this number is more than 20% of the original estimate we need to analyze why there is this much of a difference. There might be problems with incomplete requirements, poor architectural design, or maybe a technical problem with a particular language or runtime. If however the problem is determine to be a poorly categorized AFSR then we need to determine how to re-establish the integrity of the catalog.

Here we determine if in fact there is a need to re-factor the existing catalog. For example if the AFSR of Secure Data Capture is not sufficient for a scenario where much more data needs to be captured then we will need to re-factor the catalog like displayed in figure 3.6

ID AFSR FSR

0 Secure Data Capture (0-10

fields)

The system shall allow the user to enter their address to be a part of a mailing

list. The system shall have the quality attribute of security implemented by

SSL.

1 Secure Data Capture

(10-20 fields)

The system shall allow the user to enter their personal information to apply for

a car loan. The system shall have the quality attribute of security implemented

by SSL

Estimates and measurements are wishful thinking. They are dependent on perfect scenarios with no distractions. Unclear and incomplete requirements and use cases can throw

the measurement off. If a certain requirement was categorized under a different

abstraction at the beginning of the project and not apparent until the end, it might be too late at that moment to fix budget over runs and/or adjust schedules.

The development schedule might be overly aggressive and result in insufficient resources.

If after the project completion, when actual project time lines were not recorded with the correct abstractions and elements in mind, that would never work towards building a comprehensive database of close to real estimations.

In this paper we proposed a framework for measuring software effort using abstraction techniques.

Certain guidelines have to be followed in order for this to be a success and accurate.

The measurement’s accuracy is related to its purpose at a particular point in time.

The effort measurement at a project’s feasibility stage needs only be accurate enough to support a decision to prepare a more detailed project timeline estimation.

Once the detailed requirements and use cases have been developed, and hopefully most of the unknowns have become known, it’s time to jump into this framework for hopefully very accurate measurements based on abstract requirements.

Due to the inherent uncertainties in all projects, one might need to re-estimate as you learn more.

Whenever major unplanned events occur, one would need to understand how they impact the schedule and effort, and bake that into the final actual recording phase.