------------tutorial 3 after the handwritten pdf-------------------

the final answer is:

Project type: Organic

Project size: 4.5 KDSI

Initial effort estimation: 12.69 Person-Months

Adjusted effort estimation: 9.52 Person-Months

Schedule: 8.85 Months

Minimum team size: 6 team members

Likely billing: Rs. 442,500

Assuming that the client would pay Rs. 50,000 per month of development, the likely billing would be
calculated as follows:

Likely billing = Schedule * Monthly rate

Likely billing = 8.85 Months * Rs. 50,000 per month

Likely billing = Rs. 442,500

Therefore, the likely billing for this project would be Rs. 442,500.

---------------TUTORIAL 3 Completed----------------
 Tutorial-4

Aim: - Function Point: Analyze the case study and identify the error and solve it. At

the end, need to assess calculation part of effort using FP oriented estimation

model.

Case Study – Function Point Analysis Form a team of 2 to 4 students. You are about to develop an app
for

a Pizzeria. People can order pizzas with the app. You have started with the GUI design. The following

shows two options for the Pizza Selection Screen.

Form a team of 2 to 4 students.

You are about to develop an app for a Pizzeria. People can order pizzas with the app. You have started

with the GUI design.

The following shows two options for the Pizza Selection Screen.

Option 1:

Explanation: • Toppings are read from another application (kitchen application). If the topping is not
available, it is not displayed. • The cost of the Pizza is calculated automatically. • When the OK button is
clicked the Toppings, Pizza Crust Type and Cost of Pizza are saved for further processing.
Option 2:

Explanation:

• The Items in the drop down box are hard coded – not read from a file.

• Available Toppings are read from another application (kitchen application).

• When a Topping is selected from Available Toppings it is copied to Selected Toppings

• The Cost of the Pizza is automatically calculated.

• When the OK button is clicked the Selected Toppings, Pizza Crust Type and Cost of Pizza are saved for
further processing.

Answers:

Ad 1: Option 1 = Option 2

Function types:

1 EIF: topping data – 1 RET, 1 DET (topping, perhaps more but probably <15)

1 ILF: order – 1 RET, 3 DETs (crust, topping, price, more? But probably <15)

1 EQ: topping choices – 1 FTR, 1 DET (topping, recursive)

1 EI: order – (crust, topping, price, OK)

What about “Cancel” button? -> does not count because not involved in a transaction. (just like

navigation or like showing static information via hyperlinks)

EIF: <=5 RETs, <=19 DETs -> low -> 5 unadjusted FPs

ILF: <=5 RETs, <=19 DETs -> low -> 7 unadjusted FPs

EQ: 1 FTR, 1 DET -> low -> 3 unadjusted FPs

EI: 1 FTR, 1 DET -> low -> 3 unadjusted FPs

Sum: 18 unadjusted FPs

Ad 3:

The following GSCs are affected: - 3-

Performance: score = 0

- 6-Online Data Entry: score = 5

Those two GSCs would cancel each other out -> Adjustment Factor = 1 if the same holds for the

remaining 12 GSC
 Tut 5

Aim: - Consider the following Java code segment:

1. Guarantees that all independent execution path is exercised at least once;

2. Guarantees that both the true and false side of all logical decisions are

exercised;

3. Executes the loop at the boundary values and within the boundaries.

Sketch out Design control flow diagram and Apply Cyclomatic complexity for given

Code. Identify numbers of Independence path require for testing

1. Example: Consider the Euclid’s GCD computation algorithm:

int compute_gcd (x, y)

int x, y;

1 while (x! = y) {

2 if (x>y) then

3 x= x – y;

4 else y= y – x;

5}

6 return x;

By choosing the test set {(x=3, y=3), (x=4, y=3), (x=3, y=4)}, we can exercise the

program such that all statements are executed at least once.

2. Branch coverage In the branch coverage-based testing strategy, test cases are designed to make each
branch condition to assume true and false values in turn. Branch testing is also known as edge testing as
in this testing scheme, each edge of a program’s control flow graph is traversed at least once. It is
obvious that branch testing guarantees statement coverage and thus is a stronger testing strategy
compared to the statement coverage-based testing? For Euclid’s GCD computation algorithm, the test
cases for branch coverage can be {(x=3, y=3), (x=3, y=2), (x=4, y=3), (x=3, y=4)}.
Cyclomatic complexity

For more complicated programs it is not easy to determine the number of independent paths of the
program. McCabe’s cyclomatic complexity defines an upper bound for the number of linearly
independent paths through a program. Also, the McCabe’s cyclomatic complexity is very simple to
compute. Thus, the McCabe’s cyclomatic complexity metric provides a practical way of determining the
maximum number of linearly independent paths in a program. Though the McCabe’s metric does not
directly identify the linearly independent paths, but it informs approximately how many paths to look
for.

There are three different ways to compute the cyclomatic complexity. The answers computed by the
three methods are guaranteed to agree.

Method 1:

Given a control flow graph G of a program, the cyclomatic complexity V(G)

can be computed as:

V(G) = E – N + 2

where N is the number of nodes of the control flow graph and E is the

number of edges in the control flow graph.

Method 2: An alternative way of computing the cyclomatic complexity of a program from an inspection
of its control flow graph is as follows: V(G) = Total number of bounded areas + 1 In the program’s control
flow graph G, any region enclosed by nodes and edges can be called as a bounded area. This is an easy
way to determine the McCabe’s cyclomatic complexity. But, what if the graph G is not planar, i.e.
however you draw the graph, two or more edges intersect? Actually, it can be shown that structured
programs always yield planar graphs. But, presence of GOTO’s can easily add intersecting edges.
Therefore, for non-structured programs, this way of computing the McCabe’s cyclomatic complexity
cannot be used. The number of bounded areas increases with the number of decision paths and loops.
Therefore, the McCabe’s metric provides a quantitative measure of testing difficulty and the ultimate
reliability. For the CFG example shown in fig. 10.4, from a visual examination of the CFG the number of
bounded areas is 2. Therefore, the cyclomatic complexity, computing with this method is also 2+1 = 3.
This method provides a very easy way of computing the cyclomatic complexity of CFGs, just from a
visual examination of the CFG. On the other hand, the other method of computing CFGs is more
amenable to automation, i.e. it can be easily coded into a program which can be used to determine the
cyclomatic complexities of arbitrary CFGs.

Method 3: The cyclomatic complexity of a program can also be easily computed by computing the
number of decision statements of the program. If N is the number of decision statement of a program,
then the McCabe’s metric is equal to N+1.