Statistical Control Techniques-Methods Of Software Engineering-Lecture Notes, Study notes of Software Engineering

Download Statistical Control Techniques-Methods Of Software Engineering-Lecture Notes and more Study notes Software Engineering in PDF only on Docsity!

In order to do that, we need to employ some statistical techniques and plot the result graphically. This is known as statistical control techniques.

Lecture No. 15

Statistical Control Techniques – control charts

Same process metrics vary from project to project. We have to determine whether the trend is statistically valid or not. We also need to determine what changes are meaningful. A graphical technique known as control charts is used to determine this.

This technique was initially developed for manufacturing processes in the 1920‘s by Walter Shewart and is still very applicable even in disciples like software engineering. Control charts are of two types: moving range control chart and individual control chart. This technique enables individuals interested in software process improvement to determine whether the dispersion (variability) and ―location‖ (moving average) of process metrics are stable (i.e. the process exhibits only natural or controlled changes) or unstable (i.e. the process exhibits out-of-control changes and metrics cannot be used to predict performance).

Let us now demonstrate the use of these control charts with the help of an example. Let us assume that the data shown in the following table regarding the average change implementation time was collected over the last 15 months for 20 small projects in the same general software domain 20 projects. To improve the effectiveness of reviews, the software organization provided training and mentoring to all project team members beginning with project 11.

Project

Time /change implementation 1 3 2 4. 3 1. 4 5 5 3. 6 4. 7 2 8 4. 9 4. 10 2. 11 3. 12 5. 13 4. 14 3. 15 4 16 5. 17 5. 18 4 19 3. 20 5.

This chart is then used to develop the individual control chart as follows:

1. Plot individual metric values
2. Compute the average value for the metrics values - Am
3. Multiply the mean of moving average by 2.66 and add average computed in step 2 above. The result is Upper Natural Process Limit (UNPL)
4. Multiply the mean of moving average by 2.66 and subtract average computed in step 2 above. The result is Lower Natural Process Limit (LNPL)
5. Plot UNPL and LNPL. If LNPL is less than zero than it need not be plotted unless the metric being evaluated takes on values that are less than 0.
6. Compute a standard deviation as (UNPL – Am)/3.
7. Plot lines 1 and 2 standard deviations above and below Am.
8. Applying these steps we derive an individual control chart.

This chart may be used to evaluate whether the changes represented by metrics indicate a process that is in control or out of control. For this, the following 4 criteria zone rules are used.

1. A single metrics value lies outside UNPL
2. Two out of three successive values lay more than 2 standards deviations away from Am.
3. Four out of five successive values lay more than one standard deviation away.
4. Eight consecutive values lie on one side of Am.

If any of these tests passes, the process is out of control otherwise the process is within control.

Since none of the test passes for the data in our example, our process is in control and this data can be used for inference.

We now analyze our results. It can be seen that the variability decreased after project

10. By computing the mean value of the first 10 and last 10 projects, it can be shown that the remedial measure taken was successful and resulted in 29% improvement in efficiency of the process. Hence the process changes incorporated were useful and bore fruit.

Lecture No. 16

Interpreting Measurements

A good metric system is the one which is simple and cheap and at the same time adds a lot of value for the management. Following are some of the examples that can be used for effective project control and management.

We can collect data about the defects reported, and defects fixed and plot them in the following manner, with their difference showing the defects yet to be fixed. This can give us useful information about the state of the product. If the gap between the defects reported and defects fixed is increasing, then it means that the product is in unstable condition. On the other hand if this gap is decreasing then we can say that the product is in a stable condition and we can plan for shipment.

Similarly, we can gain useful information by plotting the defects reported against the number of use cases run. We can use control lines from our previous data and see if the actual defects are within those control limits. If the defects at any given point in time are less than the lower limit then it may mean that out testing team is not doing a good job and coverage is not adequate. On the other hand, if it crosses the upper line then it indicates that the design and coding is not up to mark and we perhaps need to check it.

Defects

Time

Total reported defects

Defects yet to be fixed

Defects fixed to date

Defects

Test cases

Upper limit

Lower limit

Actual defects

Lecture No. 17

Software Project Planning

Software project planning is an activity carried out by the project manager to estimate and address the following points:

1. Software scope estimation
2. Resources requirements
3. Time requirements
4. Structural decomposition
5. Risk analysis and planning

Software scope estimation Software scope describes the data and control to be processed, function, performance, constraints, interfaces, and reliability. Determination of the software scope is a pre- requisite of all sorts of estimates, including, resources, time, and budget.

In order to understand the scope, a meeting with the client should be arranged. The analyst should start with developing a relationship with the client representative and start with context-free questions. An understanding of the project background should also be developed. This includes understanding:

• Who is behind the request (sponsor)?
• Who will use the solution (users)?
• What are the economic benefits (why)?

Now is the time to address the find out the more about the product. In this context, the following questions may be asked:

• How would you characterize good output?
• What problems will the solution address?
• Can you show me the environment in which the solution will be used?
• Will any special performance issues or constraints affect the way the solution is approached?
• Are you the right person to answer these questions? Are answers ―official‖?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

In this regards, a technique known as Facilitated Application Specification Techniques or simply FAST can be used. This is a team-oriented approach to requirement gathering that is used during early stages of analysis and specification. In this case joint team of customers and developers work together to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of requirements.

Feasibility The purpose of the feasibility analysis is to determine can we build software to meet the scope? For this purpose, the project is analyzed on the following 4 dimensions:

Technology

• Is the project technically feasible?
• Is it within the state of the art?
• Can defects be reduced to a level matching the application needs?

Finance

• Is it financially feasible?
• Can development be completed at a cost that software organization, its client, or the market can afford?

Time

• Will the project time to market beat the competition?
• Can we complete the project in the given amount of time?

Resources

• Does the organization have resources needed to succeed? The resources include:
  • HW/SW tools
  • Reusable software components
  • People

Software Project Estimation Once the project feasibility has been determined, the project manager starts the estimation activity. It is a relatively difficult exercise and has not become an exact science. It is influenced by human, technical, environmental, political factors.

For software project estimation, a project manager can use historic data about its organizations previous projects, decomposition techniques, and/or empirical models developed by different researchers.

Empirical Models

Empirical models are statistical models and are based upon historic data. Although there are many different models developed by different researchers, all of them share the following basic structure:

E = A + B * (ev)C

where A, B, c are empirical constants, ‗ev‘ is the effort in terms of lines of code or FP, and ‗E‘ is the effort in terms of person months.

The most famous of these models is the COCOMO - COnstructive COst MOdel – model. It also has many different versions. The simplest of these versions is given below: E = 3.2 (KLOC)1.

• Evaluate each software package or component based on past product quality, vendor support, product direction, reputation, etc.
• Contact other users of the software and ask for opinion.

The following key considerations must always be kept in the perspective:

• Delivery date
• Development Cost
  • Acquisition + customization
• Maintenance Cost

A decision tree can be built to analyze different options in this regards. As an example of this, let us consider the following. In this case, we have four different options, namely, build, reuse, buy, and contract. We analyze each one of these with the help of a decision tree. Each node of the tree is further partitioned a probability is assigned to each branch. At the end, cost for each path in the tree, from root to a leaf, is estimated and associated with that path. This process is shown in the following diagram.

Once the information in the tree is complete, it is used to determine the most viable option. For each option the expected cost is determined as follows:

Expected cost = ∑ (path probability)I x (estimated path cost)

Using this formula, we calculate the expected cost of each option as follows:

Build = 0.30380 + 0.70450000 = 429000 Reuse = 0.4275000 + 0.60.2310000 + 0.60.8*490000 = 382000

The expected cost of Buy and Contract can also be calculated in a similar fashion and comes out to be:

Buy = 267000 Contract = 410000

Therefore, according to this analysis, it is most viable to buy than any other option.

Build

Reuse

Buy Contract

Simple (0.30)

Difficult (0.70) Minor changes (0.40)

Major changes (0.60)

Simple (0.20) Complex (0.80)

Minor changes (0.70) Major changes (0.30) Without changes (0.80)

With changes (0.20)

• 380,
• 450,
  • 275,
    • 310,
    • 490,
• 210,
• 400,
• 350,
• 500,