What is the difference between priority and severity?

Severity and priority have always been the most effective measure to characterize a bug. Severity and priority levels have been in use since a long time by most of the software development organizations and standards as a measure to calculate the degree of the harm that can be done by a bug.

"The severity of a bug is an indication of its harmfulness or badness whereas the priority level of a bug is an indication of the urgency for fixing it."

Role of Testing Team

- The testing team is responsible for setting up the severity as well the priority levels for the bugs.
- The way they set the severity and priority level, it should be meaningful, easy to understand, consistent and of course reasonable!
- A bug as we all know is a defect in the coding of a software program which hinders its development and meeting the expectations of the users.

About Priority

- Priority is way of rating the urgency for fixing or correcting a bug which in turn implies its importance also.
- The priorities are set keeping in mind the goals and the specifications of the software project.
- Priority has nothing to do with the quality of the software product as affected by the bug.
- Priority is nothing but a functional of the class and severity of the bug.

About Severity

- Severity is a means for the measurement of the harm and disruption caused by the bug to the functioning of the software system or application.
- It is the severity that gives the information regarding the impact as well as visibility of the bug on the quality of the software product and its functioning.
- Severity is an effective means for rating of the impact of a bug on the quality of a software product as it is perceived.
- Therefore, the severity of the bugs should be assigned very carefully.
- It is a commonly observed issue that the simple concept of severity is made over complicated due to a lack of data.

Sub-Components of Severity

To say severity has got many sub components but on a whole basis only two are considered:

1. Visibility
Visibility gives the probability of the occurrence of the bug again in the future in a particular feature and functionality of the program.

2. Impact
Impact gives the measure of the disruption caused to the user of the system when the bug is encountered.

How Severity and Priority Calculated?

- The total severity is calculated as an average of the values of the visibility and impact factors.
- This characteristic of severity allows us to view it as a measure of the quality of the software product s it is perceived.
- Using priority as a quality indicator is a great mistake.
- Unlike severity, the priority is measured as an attribute of the bug and the defined goals of the project.

Priority on the basis of Urgency

- Some testers define priority on the basis of the urgency which is an absolutely wrong way.
- The urgency should be defined on the basis of the priority level.
- Urgency is directly proportional to the priority.
- The priority levels range from 1 to 7 where 1 being the highest priority level and 7 being the lowest.
- By default the priority of each discovered bug is 3.
- It will be more good if one priority scheme is followed across all the projects i.e., to have a global priority scheme.
- Priority tells us how important or urgent is to get the bug fixed.

In some cases it happens that going gets tough without rectifying the bugs in the lower levels. Such situations demand the highest priority.

What are the metrics for object oriented design?

A more objective view of the characteristics of design can benefit both an experienced designer and the novice. The characteristics that can be measured when we assess an object oriented design are:

- Size which has four views: population, volume, length and functionality.
- Complexity is measured in terms of structural characteristics by checking how classes of an object oriented design are interrelated.
- Sufficiency is defined as the degree to which an abstraction possesses the features required from the point of view of current application.
- Coupling is defined as different connections between the elements of the object oriented design.
- Completeness is defined as the feature set against which we compare the abstraction or design component. It considers multiple points of view. It indirectly implies the degree to which abstraction or design component can be reused.
- Similarity is defined as the degree to which two or more classes are similar in structure, function, behavior etc.
- Volatility for object oriented design is defined as the likelihood that a change will occur.
- Cohesion is defined as the degree to which the set of properties it possesses is part of problem or design domain.
- Primitiveness is the degree to which the operation is not constructed out of a sequence of other operations within the class.

Relationships And Relationship Sets

A relationship is an association between several entities.
A relationship set is a set of relationships of the same type.
A relationship type R among n entity types E1, E2,....., En defines a set of associations or a relationship set among entities from these types.
In ER diagrams, relationship types are displayed as diamond-shaped boxes, which are connected by straight lines to the rectangular boxes representing the participating entity types. The relationship name is displayed in the diamond-shaped box.

RELATIONSHIP DEGREE : The degree of a relationship type is the number of participating entity types. A relationship type of degree two is called binary, and one with degree three is called ternary.




ROLE NAMES and RECURSIVE RELATIONSHIPS :
Role names signifies the role that a participating entity from the entity type plays in each relationship instance, and helps to explain what the relationship means.
Role names are not necessary in relationship types where all the participating entity types are distinct, since each entity type name can be used as a role name. However, in some cases, the same entity type participates more than once in a relationship type in different roles. In such cases the role name becomes essential for distinguishing the meaning of each participation. Such relationships are called recursive relationships.


MAPPING CONSTRAINTS :
An E-R scheme may define certain constraints to which the contents of a database must conform.
* Mapping Cardinality : It expresses the number of entities to which another entity can be associated via a relationship. For binary relationship sets between entity sets A and B, the mapping cardinality must be one of:
1. One-to-one: An entity in A is associated with at most one entity in B, and an entity in B is associated with at most one entity in A.
2. One-to-many: An entity in A is associated with any number in B. An entity in B is associated with at most one entity in A.
3. Many-to-one: An entity in A is associated with at most one entity in B. An entity in B is associated with any number in A.
4. Many-to-many: Entities in A and B are associated with any number from each other.
The appropriate mapping cardinality for a particular relationship set depends on the real world being modeled.
* Existence Dependencies: if the existence of entity X depends on the existence of entity Y, then X is said to be existence dependent on Y. (Or we say that Y is the dominant entity and X is the subordinate entity.)
For example,
o Consider account and transaction entity sets, and a relationship log between them.
o This is one-to-many from account to transaction.
o If an account entity is deleted, its associated transaction entities must also be deleted.
o Thus account is dominant and transaction is subordinate.