Write short notes on

• Cohesion and coupling
• Decision Tree and Decision Table
• Software quality metrices

Cohesion and coupling:

Cohesion refers to the degree to which the elements of a module belong together. Thus, cohesion measures the strength of relationship between pieces of functionality within a given module. For example, in highly cohesive systems functionality is strongly related.

Cohesion is an ordinal type of measurement and is usually described as “high cohesion” or “low cohesion”. Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability whereas low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.

Cohesion is increased if:

• The functionalities embedded in a class, accessed through its methods, have much in common.
• Methods carry out a small number of related activities, by avoiding coarsely grained or unrelated sets of data.

Advantages of high cohesion (or “strong cohesion”) are:

• Reduced module complexity (they are simpler, having fewer operations).
• Increased system maintainability, because logical changes in the domain affect fewer modules, and because changes in one module require fewer changes in other modules.
• Increased module reusability, because application developers will find the component they need more easily among the cohesive set of operations provided by the module.

Coupling is the manner and degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.

Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability

Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). 

Procedural programming:

A module here refers to a subroutine of any kind, i.e. a set of one or more statements having a name and preferably its own set of variable names.

Content coupling (high)

Content coupling  occurs when one module modifies or relies on the internal workings of another module .Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module.

Common coupling

Common coupling occurs when two modules share the same global data (e.g., a global variable). Changing the shared resource implies changing all the modules using it.

External coupling

External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface. This is basically related to the communication to external tools and devices.

Control coupling

Control coupling is one module controlling the flow of another, by passing it information on what to do.

Data coupling

Data coupling occurs when modules share data through, for example, parameters.

No coupling

Modules do not communicate at all with one another.

Decision Tree and Decision Table:

A decision tree is a decision support tool that uses a tree-like graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. It is one way to display an algorithm. Decision trees are commonly used in operations research, specifically in decision analysis, to help identify a strategy most likely to reach a goal. A decision tree is a flowchart-like structure in which each internal node represents a "test" on an attribute, each branch represents the outcome of the test and each leaf node represents a class label.The paths from root to leaf represents classification rules.

A decision table is an excellent tool to use in both testing and requirements management. Essentially it is a structured exercise to formulate requirements when dealing with complex business rules. Decision tables are used to model complicated logic. Decision tables provide a systematic way of stating complex business rules, which is useful for developers as well as for testers. They  can be used in test design whether or not they are used in specifications, as they help testers explore the effects of combinations of different inputs and other software states that must correctly implement business rules. It helps the developers to do a better job can also lead to better relationships with them.

Software quality metrices:

The quality of a product is defined in terms of its fitness of purpose. That is, a good quality product does exactly what the users want it to do. Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process, and project.

The quality associated with a software product are mainly:

1. Portability: A software product is said to be portable, if it can be easily made to work in different hardware and operating system environmnent, and easily interface with external hardware devices and software products.
2. Usability: A software product has good usability, if different categories of users can easily invoke the functions of the product.
3. Reusability: A software product has good reusability, if different odules of the product can easily be reused to develop new products.
4. Correctness: A software product is correct, if different requirements as specified in the SRS document have been correctly implemented.
5. Maintainability: A software product is maintainable, if errors can be easily corrected as and when they show up, new functions can be easily added to the product and the functionalities of the product can be easily modified.

As software development is a complex process, with high variance on both methodologies and objectives, it is difficult to define or measure software qualities and quantities and to determine a valid and concurrent measurement metric, especially when making such a prediction prior to the detail design. Another source of difficulty and debate is in determining which metrics matter, and what they mean. The practical utility of software measurements has therefore been limited to the following domains:

• Scheduling

• Software sizing

• Programming complexity

• Software development effort estimation

• Software quality