By: Eng. Mohammed T. Abo Alroos

By: Eng. Mohammed T. Abo Alroos

Use Case Points The formula for calculating UCP is composed of three variables: 1. Unadjusted Use Case Points (UUCP), which measures the complexity of the functional requirements 2. The Technical Complexity Factor (TCF), which measures the complexity of the nonfunctional requirements 3. The Environment Complexity Factor (ECF), which assesses the development team s experience and their development environment

UCP = UUCP * TCF * ECF Unadjusted Use Case Points (UUCPs) are computed as a sum of these two components: 1. The Unadjusted Actor Weight (UAW), based on the combined complexity of all the actors in all the use cases. 2. The Unadjusted Use Case Weight (UUCW), based on the total number of activities (or steps) contained in all the use case scenarios.

UAW

UAW - Example

UUCW

UUCW-Example

Technical Complexity Factor (TCF) Nonfunctional Requirements Thirteen standard technical factors were identified (by expert developers) to estimate the impact on productivity of the nonfunctional requirements for the project. Where : constant1=0.6 and Constant2=0.01 Wi = weight of ith technical factor Fi = perceived complexity of ith technical factor

TCF-Example TCF=0.6+0.01(31)=0.91

Environment Complexity Factor (ECF) The environmental factors measure the experience level of the people on the project and the stability of the project Where : Constant1 = 1.4 Constant2=-0.03 Wi = weight of ith environmental factor Fi = perceived impact of ith environmental factor

ECP-Example ECP=1.4-0.03(11)=1.07

UCP-Example UUCP = 97 TCF = 0.91 ECF = 1.07 For the sample case study, the final UCP is the following: UCP = 97 * 0.91 * 1.07 = 94.45 or 94 use case points.

Project Duration Suppose the project has Productivity Factor (PF) = 20, so find the project duration : Project Duration =94.45 * 20=1889 hours Dividing the Project Duration by 40 hours (for one man work week) = 47 man-weeks. Therefore, for the sample values in this article, it would take one developer 47 weeks (or about 12 months) to complete the application.

Example 1 To illustrate the process of calculating the UCP, an Online Shopping System will be used. The diagram below depicts the Use Case Diagram for the system to be developed.

UUCW To calculate the UUCW, the use cases must be defined and the number of transactions for each use case identified. The Online Shopping System use case diagram is depicting that nine use cases exist for the system. Assuming 2 of these use cases are simple, 3 are average and 4 are complex, the calculation for UUCW is as follows: UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) + (Total No. Complex Use Cases x 15) For the Online Shopping System, the UUCW = (2 x 5) + (3 x 10) + (4 x 15) = 100 UUCW = 100

UAW To calculate the UAW, the actors must be identified. The Online Shopping System use case diagram is depicting five actors; One simple for the Payment Processing System and four complex for each of the human users actors (i.e. Online Customer, Marketing Administrator, Warehouse Clerk, Warehouse Manager.) The calculation for UAW is as follows: UAW = (Total No. of Simple Actors x 1) + (Total No. Average Actors x 2) + (Total No. Complex Actors x 3) For the Online Shopping System, UAW = (1 x 1) + (0 x 2) + (4 x 3) = 13 UAW = 13

TCF To calculate the TCF, each of the technical factors is assigned a value based on how essential the technical aspect is to the system being developed. The diagram below shows the assigned values for the Online Shopping System. The values are multiplied by the weighted values and the total TF is determined.

Factor Description Weight Assigned Value Weight x Assigned Value T1 Distributed system 2.0 5 10 T2 Response time/performance objectives 1.0 5 5 T3 End-user efficiency 1.0 3 3 T4 Internal processing complexity 1.0 2 2 T5 Code reusability 1.0 3 3 T6 Easy to install 0.5 1 0.5 T7 Easy to use 0.5 5 2.5 T8 Portability to other platforms 2.0 2 4 T9 System maintenance 1.0 2 2 T10 Concurrent/parallel processing 1.0 3 3 T11 Security features 1.0 5 5 T12 Access for third parties 1.0 1 1 T13 End user training 1.0 1 1 Total (TF): 42

TCF Next, the TCF is calculated: TCF = 0.6 + (TF/100) For the Online Shopping System, TCF = 0.6 + (42/100) = 1.02 TCF = 1.02

ECF To calculate the ECF, each of the environmental factors is assigned a value based the team experience level. The diagram below shows the assigned values for the Online Shopping System. The values are multiplied by the weighted values and the total EF is determined.

E1 Factor Description Weight Assigned Value Familiarity with development process used Weight x Assigned Value 1.5 3 4.5 E2 Application experience 0.5 3 1.5 E3 Object-oriented experience of team 1.0 2 2 E4 Lead analyst capability 0.5 5 2.5 E5 Motivation of the team 1.0 2 2 E6 Stability of requirements 2.0 1 2 E7 Part-time staff -1.0 0 0 E8 Difficult programming language -1.0 4-4 Total (EF): 10.5 ECF = 1.4 + (-0.03 x EF) For the Online Shopping System, ECF = 1.4 + (-0.03 * 10.5) = 1.085 ECF = 1.085

UCP UCP = (UUCW + UAW) x TCF x ECF For the Online Shopping System, UCP = (100 + 13) x 1.02 x 1.085 = 125.06 UCP = 125.06 For the Online Shopping System, the total estimated size to develop the software is 125.06 Use Case Points.

Project Duration Now that the size of the project is known, the total effort for the project can be estimated. For the Online Shopping System example, 28 man hours per use case point will be used. For the Online Shopping System, Estimated Effort (Project Duration )= 125.06 x 28 Estimated Effort = 3501 Hours

Example 2 Use Case Type Description Weight Number of Use Cases Simple A simple user interface and touches only a single database entity; its success scenario has 3 steps or less; its implementation involves less than 5 classes. Result 5 8 40 Average Complex More interface design and touches 2 or more database entities; between 4 to 7 steps; its implementation involves between 5 to 10 classes. Involves a complex user interface or processing and touches 3 or more database entities; over seven steps; its implementation involves more than 10 classes. 10 12 120 15 4 60 Total UUCW 220

UAW Actor Type Description Weight Number of Actors Result Simple Average The Actor represents another system with a defined API The Actor represents another system interacting through a protocol, like TCP/IP 1 8 8 2 12 24 Complex The Actor is a person interacting via an interface. 3 4 12 Total UAW 44

TCF Technical Factor Description Weight Perceived Complexity Calculated Factor (weight*perceived complexity)> T1 Distributed System 2 5 10 T2 Performance 1 4 4 T3 End User Efficiency 1 2 2 T4 Complex internal Processing 1 4 4 T5 Reusability 1 2 2 T6 Easy to install 0.5 5 2 T7 Easy to use 0.5 3 2 T8 Portable 2 3 6 T9 Easy to change 1 3 3 T10 Concurrent 1 2 2 T11 Special security features 1 2 2 T12 T13 Provides direct access for third parties Special user training facilities are required 1 5 5 1 3 3 Total Factor 47 TCF = 0.6 + (.01*Total Factor). the TCF = 1.07

ECF Environmental Factor Description Weight Perceived Impact Calculated Factor (weight*perceived complexity) E1 Familiarity with UML 1.5 4 6 E2 Application Experience 0.5 2 1 E3 Object Oriented Experience 1 5 5 E4 Lead analyst capability 0.5 2 1 E5 Motivation 1 1 1 E6 Stable Requirements 2 5 10 E7 Part-time workers -1 0 0 E8 Difficult Programming language 2 1 2 Total Factor 26 ECF = 1.4 + (-0.03*Total Factor, the ECF = 0.62

UCP UCP = TCP * ECF * UUCP UCP= 1.07 * 0.62 * 264 =175.1376 The Productivity Factor (PF) is a ratio of the number of man hours per use case point based on past projects. A typical value is 20. Duration = 1.07 * 0.62 * 264 * 20 = 3502.752 or 3503 hours. Dividing the UCP by 40 hours (for one man work week) = 88 man-weeks. Therefore, for the sample values in this article, it would take one developer 88 weeks (or about 22 months) to complete the application

Cyclomatic Complexity Thomas McCabe [1974] devised a measure of cyclomatic complexity, intended to capture the complexity of a program s conditional logic. A program with no branches is the least complex; a program with a loop is more complex; and a program with two crossed loops is more complex still. Cyclomatic complexity corresponds roughly to an intuitive idea of the number of different paths through the program the greater the number of different paths through a program, the higher the complexity.

Cyclomatic complexity of graph G equals #edges - #nodes + 2 V(G) = e n + 2 Also corresponds to the number of binary decisions in a program plus 1 If all decisions are not binary, a three-way decision is counted as two binary decisions and an n-way case (select or switch) statement is counted as n 1 binary decisions. The iteration test in a looping statement is counted as one binary decision.

Converting Code to Graph

Given p the number of connected components of a graph: V(G) = e n + 2p (1) V LI (G) = e n + p + 1 (2) (2) is known as linearly-independent cyclomatic complexity V LI does not change when program is modularized into p modules

Cyclomatic Complexity Drawback Cyclomatic complexity ignores the complexity of sequential statements. In other words, any program with no conditional branching has zero cyclomatic complexity. It does not distinguish different kinds of control flow complexity, such as loops vs. IF-THEN-ELSE statements or selection statements vs. nested IF- THEN-ELSE statements.

Cyclomatic complexity metric was originally designed to indicate a program s testability and understandability. It allows you to also determine the minimum number of unique tests that must be run to execute every executable statement in the program. To have good testability and maintainability, McCabe recommends that no program module should exceed a cyclomatic complexity of 10.

Example 1 Compute The cyclomatic Complexity????!!! And derive the independent paths

Solution By one of these ways : V(G)=number of simple decisions + 1 =3+1=4 V(G)=number of enclosed areas + 1=3+1=4 V(G)=e-n+2p=11-9+2=4

1 2 Next, we derive the independent paths: Since V(G) = 4, there are four paths 4 3 5 6 Path 1: 1,2,3,6,7,8 Path 2: 1,2,3,5,7,8 Path 3: 1,2,4,7,8 Path 4: 1,2,4,7,2,4,...7,8 7 8 Finally, we derive test cases to exercise these paths.

What is the complexity V(G)? public void howcomplex() { int i=20; while (i<10) { System.out.printf("i is %d", i); if (i%2 == 0) { System.out.println("even"); } else { System.out.println("odd"); } } }

Solution public void howcomplex() { int i=20; i); } while (i<10) { System.out.printf("i is %d", } if (i%2 == 0) { System.out.println("even"); } else { System.out.println("odd"); } V(G) = 2 enclosed area + 1 = 3

Example 2

Solution

Example 3

Solution

Example 4 Void Test::Test3(){ String a,b,c,d,e,f; If((a ==b) (e == f)) C=d Else C=f }

Example 5

Solve (a) Draw the flowchart of the above algorithm. (b) Draw the corresponding graph and label the nodes as n1, n2, and edges as e1, e2, (c) Calculate the cyclomatic complexity of the above algorithm.

Solution / a

Solution /b

Solution / c Using the original formula by McCabe [1974] we have V(G) = 22-19 + 2*2 = 7 Notice that there are a total of 19 nodes in Quicksort and Partition because nodes n4 and n5 are each split in two. Alternatively, [Henderson-Sellers & Tegarden, 1994] linearly-independent cyclomatic complexity for the graph yields VLI(G) = 22-19 + 2 + 1 = 6 which is what we obtain, as well, by a simple rule: VLI(G) = number of closed regions + 1 = 5 + 1 = 6

Measuring Module Cohesion Cohesion is defined as a measure of relatedness or consistency in the functionality of a software unit. It is an attribute that identifies to which degree the parts within that unit belong together or are related to each other. Modules with high cohesion : robust, reliable, reusable, and easy to understand. Modules with low cohesion : difficult to understand, test, maintain, and reuse

Internal Cohesion or Syntactic Cohesion Internal cohesion can best be understood as syntactic cohesion evaluated by examining the code of each individual module A very crude modularization is to require that each module should not exceed certain size, e.g., 50 lines of code. This would arbitrarily quantize the program into blocks of about 50 lines each. Alternatively, we may require that each unit of design has certain prescribed size. For example, a package is required to have certain number of classes, or each class a certain number of attributes and operations.

An Ordinal Scale for Cohesion Measurement high cohesion 6 - Functional cohesion module performs a single well-defined function 5 - Sequential cohesion >1 function, but they occur in an order prescribed by the specification 4 - Communication cohesion >1 function, but on the same data (not a single data structure or class) 3 - Procedural cohesion multiple functions that are procedurally related 2 - Temporal cohesion >1 function, but must occur within the same time span (e.g., initialization) 1 - Logical cohesion module performs a series of similar functions, e.g., Java class java.lang.math 0 - Coincidental cohesion PROBLEM: Depends on subjective human assessment low cohesion

An early metric of this type is the Lack of Cohesion of Methods (LCOM1). This metric counts the number of pairs of methods that do not share their class attributes. Under LCOM1, the perfect cohesion achieved when all methods access all attributes. Because of perfect cohesion, we expect the lack-of-cohesion value to be 0. At the opposite end of the spectrum, each method accesses only a single attribute (assuming that m = a). In this case, we expect LCOM = 1, which indicates extreme lack of cohesion.

Example Metrics (1) class C1 class C2 class C3 class C4 a 1 a 4 a 1 a 4 a 1 a 4 a 1 a 4 m 1 m 4 m 1 m 4 m 1 m 4 Class Cohesion Metric Definition / Formula m 1 m 4 (1) Lack of Cohesion of Methods (LCOM1) (Chidamber & Kemerer, 1991) LCOM1 = Number of pairs of methods that do not share attributes (2) LCOM2 (Chidamber & Kemerer, 1991) P = Number of pairs of methods that do not share attributes Q = Number of pairs of methods that share attributes LCOM2 = P Q, if P Q 0 0, otherwise (3) (4) LCOM3 (Li & Henry, 1993) LCOM4 (Hitz & Montazeri, 1995) LCOM3 = Number of disjoint components in the graph that represents each method as a node and the sharing of at least one attribute as an edge C1, C4: C2: C3: Similar to LCOM3 and additional edges are used to represent method invocations C1: C2, C3: C4: # Method Pairs = NP = M 2 = M! 2! (M 2)! LCOM1: LCOM1(C1) = P = NP Q = 6 1 = 5 LCOM1(C2) = 6 2 = 4 LCOM1(C3) = 6 2 = 4 LCOM1(C4) = 6 1 = 5 LCOM2: LCOM2(C1) = P Q = 5 1 = 4 LCOM2(C2) = 4 2 = 2 LCOM2(C3) = 4 2 = 2 LCOM2(C4) = 5 1 = 4 NP(Ci) = 4 2 = 6 LCOM3: LCOM3(C1) = 3 LCOM3(C2) = 2 LCOM3(C3) = 2 LCOM3(C4) = 3 LCOM4: LCOM4(C1) = 3 LCOM4(C2) = 2 LCOM4(C3) = 2 LCOM4(C4) = 1 57

LCOM3 and LCOM4 for class C7 class C7 a 1 a 4 LCOM3 = Number of disjoint components in the graph that represents each method as a node and the sharing of at least one attribute as an edge Steps: 1. Draw four nodes (circles) for four methods. 2. Connect the first three circles because they are sharing attribute a 1. m 1 m 4 class C7 C7 & C7 : m 1 m 2 m 3 m 4 LCOM3 creates the same graph for C7 and C7 --- there are two disjoint components in both cases LCOM3(C7) = LCOM3(C7 ) = 2 a 1 a 4 m 1 m 4 LCOM4 = Similar to LCOM3 and additional edges are used to represent method invocations Steps: 1. Draw four nodes (circles) for four methods. 2. Connect the first three circles because they are sharing attribute a 1. 3. For C7 only: Connect the last two circles because m 3 invokes m 4. C7: C7 : m 1 m 2 m 3 m 4 m 1 m 2 m 3 m 4 LCOM4 finds two disjoint components in case C7 LCOM4(C7) = 2 LCOM4 finds one disjoint component in case C7 LCOM4(C7 ) = 1 58

Example Metrics (1) class C7 class C8 class C9 a 1 a 4 a 1 a 4 a 1 a 4 m 1 m 4 m 1 m 4 m 1 m 4 Class Cohesion Metric Lack of Discrimination Anomaly (LDA) Cases (1) (2) Lack of Cohesion of Methods (LCOM1) (Chidamber & Kemerer, 1991) LCOM2 (Chidamber & Kemerer, 1991) LDA1) When the number of method pairs that share common attributes is the same, regardless of how many attributes they share, e.g., in C7 4 pairs share 1 attribute and in C8 4 pairs share 3 attributes each LDA2) When the number of method pairs that share common attributes is the same, regardless of which attributes are shared, e.g., in C7 4 pairs share same attribute and in C9 4 pairs share 4 different attributes LDA1) and LDA2) same as for LCOM1 LDA3) When P Q, LCOM2 is zero, e.g., C7, C8, and C9 (3) LCOM3 (Li & Henry, 1993) LDA1) same as for LCOM1 LDA4) When the number of disjoint components (have no cohesive interactions) is the same in the graphs of compared classes, regardless of their cohesive interactions, e.g., inability to distinguish b/w C1 & C3 (4) LCOM4 (Hitz & Montazeri, 1995) Same as for LCOM3 class C1 a 1 a 4 m 1 m 4 class C3 a 1 a 4 m 1 m 4 LCOM1: LCOM3: LCOM1(C1) = P = NP Q = 6 1 = 5 LCOM1(C3) = 6 2 = 4 LCOM1(C7) = 6 4 = 2 LCOM1(C8) = 6 4 = 2 LCOM1(C9) = 6 4 = 2 LCOM3(C1) = 3 LCOM3(C3) = 2 LCOM3(C7) = 2 LCOM3(C8) = 2 LCOM3(C9) = 1 LCOM2: LCOM4: LCOM2(C1) = P Q = 5 1 = 4 LCOM2(C3) = 4 2 = 2 LCOM2(C7) = 0 P < Q LCOM2(C8) = 0 P < Q LCOM2(C9) = 0 P < Q LCOM4(C1) = 3 LCOM4(C3) = 2 LCOM4(C7) = 2 LCOM4(C8) = 2 LCOM4(C9) = 1 59

Example Metrics (2) class C1 class C2 class C3 class C4 a 1 a 4 a 1 a 4 a 1 a 4 a 1 a 4 m 1 m 4 m 1 m 4 m 1 m 4 Class Cohesion Metric Definition / Formula m 1 m 4 (5) LCOM5 (Henderson-Sellers, 1996) LCOM5 = (a kl) / (l kl), where l is the number of attributes, k is the number of methods, and a is the summation of the number of distinct attributes accessed by each method in a class (6) Coh (Briand et al., 1998) Coh = a / kl, where a, k, and l have the same definitions as above Coh = 1 (1 1/k)LCOM5 k (1 Coh) LCOM5 = k 1 a(c1) = (2 + 1 + 1 + 1) = 5 a(c2) = (2 + 1 + 2 + 1) = 6 a(c3) = (2 + 2 + 1 + 1) = 6 a(c4) = (2 + 1 + 1 + 1) = 5 LCOM5: LCOM5(C1) = (5 4 4) / (4 4 4) = 11 / 12 LCOM5(C2) = 10 / 12 = 5 / 6 LCOM5(C3) = 5 / 6 LCOM5(C4) = 11 / 12 Coh: Coh(C1) = 5 / 16 Coh(C2) = 6 / 16 = 3 / 8 Coh(C3) = 3 / 8 Coh(C4) = 5 / 16 60

Example Metrics (2) class C1 class C2 class C3 class C4 a 1 a 4 a 1 a 4 a 1 a 4 a 1 a 4 m 1 m 4 m 1 m 4 m 1 m 4 m 1 m 4 Class Cohesion Metric Lack of Discrimination Anomaly (LDA) Cases (5) LCOM5 (Henderson-Sellers, 1996) LDA5) when classes have the same number of attributes accessed by methods, regardless of the distribution of these method-attribute associations, e.g., C2 and C3 (6) Coh (Briand et al., 1998) Same as for LCOM5 Coh = 1 (1 1/k)LCOM5 k (1 Coh) LCOM5 = k 1 a(c1) = (2 + 1 + 1 + 1) = 5 a(c2) = (2 + 1 + 2 + 1) = 6 a(c3) = (2 + 2 + 1 + 1) = 6 a(c4) = (2 + 1 + 1 + 1) = 5 LCOM5: LCOM5(C1) = (5 4 4) / (4 4 4) = 11 / 12 LCOM5(C2) = 10 / 12 = 5 / 6 LCOM5(C3) = 5 / 6 LCOM5(C4) = 11 / 12 Coh: Coh(C1) = 5 / 16 Coh(C2) = 6 / 16 = 3 / 8 Coh(C3) = 3 / 8 Coh(C4) = 5 / 16 61

Example Metrics (3) class C1 class C2 class C3 class C4 a 1 a 4 a 1 a 4 a 1 a 4 a 1 a 4 m 1 m 4 m 1 m 4 m 1 m 4 Class Cohesion Metric Definition / Formula m 1 m 4 (7) Tight Class Cohesion (TCC) (Bieman & Kang, 1995) TCC = Fraction of directly connected pairs of methods, where two methods are directly connected if they are directly connected to an attribute. A method m is directly connected to an attribute when the attribute appears within the method s body or within the body of a method invoked by method m C1: C3: directly or transitively C2: C4: (8) (9) (10) Loose Class Cohesion (LCC) (Bieman & Kang, 1995) In class C3: m 1 and m 3 transitively connected via m 2 Degree of Cohesion-Direct (DC D ) (Badri, 2004) Degree of Cohesion-Indirect (DC I ) (Badri, 2004) NP P TCC = Q* / NP = NP Q*(C4) = 3 NP(Ci) = 6 = 1 LCOM1 NP TCC: TCC(C1) = 1 / 6 TCC(C2) = 2 / 6 TCC(C3) = 2 / 6 TCC(C4) = 3 / 6 LCC = Fraction of directly or transitively connected pairs of methods, where two methods are transitively connected if they are directly or indirectly connected to an attribute. A method m, directly connected to an attribute j, is indirectly connected to an attribute i when there is a method directly or transitively connected to both attributes i and j C3: C1, C2: same as for TCC C4: DC D = Fraction of directly connected pairs of methods, where two methods are directly connected if they satisfy the condition mentioned above for TCC or if the two methods directly or transitively invoke C3: C1, C2: same as for TCC the same method C4: DC I = Fraction of directly or transitively connected pairs of methods, where two methods are transitively connected if they satisfy the condition mentioned above for LCC or if the two methods directly or transitively invoke C3: the same method C1, C2: same as for TCC C4: LCC: LCC(C1) = 1/6 LCC(C2) = 2/6 LCC(C3) = 3/6 LCC(C4) = 3/6 DC D : DC D (C1) = 1/6 DC D (C2) = 2/6 DC D (C3) = 2/6 DC D (C4) = 4/6 DC I : DC I (C1) = 1/6 DC I (C2) = 2/6 DC I (C3) = 3/6 DC I (C4) = 4/6 62

Example Metrics (4) class C1 class C2 class C3 class C4 a 1 a 4 a 1 a 4 a 1 a 4 a 1 a 4 m 1 m 4 m 1 m 4 m 1 m 4 Class Cohesion Metric Definition / Formula m 1 m 4 (11) (12) (13) Class Cohesion (CC) (Bonja & Kidanmariam, 2006) Class Cohesion Metric (SCOM) (Fernandez & Pena, 2006) Low-level design Similarity-based Class Cohesion (LSCC) (Al Dallal & Briand, 2009) CC = Ratio of the summation of the similarities between all pairs of methods to the total number of pairs of methods. The similarity between methods i and j is defined as: I i I j Similarity(i, j) = where, I i and I j are the sets of attributes referenced by methods i and j I i I j CC = Ratio of the summation of the similarities between all pairs of methods to the total number of pairs of methods. The similarity between methods i and j is defined as: I i I j I i I j Similarity(i, j) =. where, l is the number of attributes min( I i, I j ) l LSCC(C) = 0 1 if k = 1 l i=1 x i (x i 1) if k = 0 or l = 0 otherwise lk (k 1) where l is the number of attributes, k is the number of methods, and x is the number of methods that reference attribute i CC: CC(C1) = 1 / 2 CC(C2) = 1 CC(C3) = 1 CC(C4) = 1 / 2 SCOM: SCOM(C1) = 2 / 4 = 1 / 2 SCOM(C2) = 2 / 4 + 2 / 4 = 1 SCOM(C3) = 2 / 4 + 2 / 4 = 1 SCOM(C4) = 2 / 4 = 1 / 2 LSCC: LSCC(C1) = 2 / (4*4*3) = 2 / 48 = 1 / 24 LSCC(C2) = (2 + 2) / (4*4*3) = 1 / 12 LSCC(C3) = 1 / 12 LSCC(C4) = 1 / 24 63