Home » SOFTWARE ENGINEERING

Category Archives: SOFTWARE ENGINEERING

WHAT IS COHESION AND COUPLING

Cohesion is the measurement of functional strength of a module.

CLASSIFICATION OF COHESION

The classes of cohesion are as follows:
  1. COINCIDENTAL COHESION
  2. LOGICAL COHESION
  3. TEMPORAL COHESION
  4. PROCEDURAL COHESION
  5. COMMUNICATION COHESIONAL
  6. SEQUNTIAL COHESION
  7. FUNCTIONAL COHESION
COINCIDENTAL COHESION: A module is said to have coincidental cohesion if it performs a set of tasks that relate to each other very loosely. In this case modules contain a random collection of functions.
LOGICAL COHESION: A module is said to have logical cohesion if all elements of the module perform similar operations. For example data input, data output etc.
TEMPORAL COHESION: When a module contains functions that are related by facts that all the functions must be executed at the same time the module is said to execute temporal cohesion. For example the set of functions responsible for initialization and start up, shut down etc execute temporal cohesion.
PROCEDURAL COHESION: A module is said to have procedural cohesion if the set of functions of the module are all part of procedural (Algorithm), in which certain sequence of steps has to be carried out for achieving an objective. For example algorithm for decoding a message.
COMMUNICATIONAL COHESION: A module is said to have communication cohesion if all the functions of the module refers to or update the same data structure. For example the set of functions defined on an array or stack.
SEQUNTIAL COHESION: A module is said to have sequential cohesion if the elements of a module form the part of a sequence, where the output from one element of the module is input to the next.
FUNCTIONAL COHESION: A module is said to have functional cohesion if the different elements of a module cooperate to achieve a single function. For example a module containing all the function required to manage employs pay roll displays function cohesion.

COUPLING

Coupling between two modules is the measurement of degree of interdependence or interaction between two modules.

CLASSIFICATION OF COUPLING

The classification of coupling is as follows:
  1. DATA COUPLING
  2. STAMP COUPLING
  3. CONTROL COUPLING
  4. COMMON COUPLING
  5. CONTENT COUPLING
DATA COUPLING: Two modules are data coupled if they communicate using an elementary data item that is passed as parameter between the two modules. For example an integer, a float, and a character, this data item should be problem oriented and it is not used for control purpose.
STAMP COUPLING: Two modules are said to be stamp coupled if they communicated using a composite data item such as structure in C.
CONTROL COUPLING: Control coupling exists between two modules if data from one module is used to direct the order of instruction in another. An example of control coupling is flag set in one module and tested in another module.
COMMON COUPLING: Two modules are common coupled if they share some global data item.
CONTENT COUPLING: Content Coupling execute between two modules if their code is shared. For example a branch from one module into another module. 
FUNCTIONAL INDEPENDENCE: A module having high cohesion and low coupling is called functional independence of other modules.

SOFTWARE LIFE CYCLE MODEL

A software life cycle model is also called process model. It is a descriptive and diagrammatic representation of a software life cycle. A life cycle model gives a list of all activities required to make a software product. It also captures the order in which these activities are to be undertaken. Different life cycle models may map the basic development activities in different ways.

THE NEED FOR SOFTWARE LIFE CYCLE MODEL:

Before developing any software product, the development team must identify a suitable life cycle model for the particular project. And then they can go ahead to with selected model. Without choosing a particular life cycle model, the development of a software product would not be in a systematic and discipline order. When a software product is being developed by a team then there must be clear understanding among team member about when and what to do. Otherwise the project would lead to chaos and failure. This problem can be explained by an example. Imagine a software development team is divided into several units. Each unit is assigned a particular task. Suppose each unit has freedom of work. So they can develop the tasks assigned to them in whatever way they want. It is possible that one unit might start writing the code. Another might start to test the documents and some other might start the design phase. This should be the best example of a project failure. Because a software life cycle model defines entry and exit criteria for its every phase. A phase can only start if its entry criteria have been satisfied. So without a software life cycle model the entry and exit criteria of a phase cannot be recognized. Without life cycle model it becomes difficult for software project manager to monitor the progress of the project.

TYPES OF SOFTWARE LIFE CYCLE MODEL:

Many life cycle models have been proposed so far. Each of them has some advantages as well as disadvantages. A few important and commonly used life cycle models are as follows:
  1. CLASSICAL WATER FALL MODEL
  2. ITERATIVE WATER FALL MODEL
  3. PROTOTYPING WATER FALL MODEL
  4. EVOLUTIONARY MODEL
  5. SPIRAL MODEL
  6. COCOMO MODEL

CLASSICAL WATERFALL MODEL

The classical waterfall model is the most obvious way to develop a software. Though classical waterfall model is elegant and it is not a practical model in sense. That it cannot be used in actual software development projects. Thus this model can be considered as a theoretical way of developing software. Other life cycle models are driven from classical waterfall model. So in order to be able to understand other life cycle models clearly. It is necessary to learn the classical waterfall model first. The classical waterfall model divides the life cycle model of a software in the following phases.

PHASES INVOLVED IN CLASSICAL WATERFALL MODEL

  1. FEASIBILITY STUDY
  2. REQUIREMENT ANALYSIS AND SPECIFICATION
  3. DESIGN
  4. CODING AND UNIT TESTING
  5. INTEGRATION AND SYSTEM TESTING
  6. MAINTENANCE

FEASIBILITY STUDY

The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the software. At first project manager or team leader tries to have a rough understanding of what is required to be done. They study different input data to the system and output data to be produced by the system. They study what kind of processing is needed to be done on this data. And they look at the various restrictions of the system. After they have an overall understanding of the problems then they investigate the different solutions that are possible. They examine each of the solutions in terms of what kind of resources are required. And also what would be the development cost and time for each solutions based on these analysis. Then they pick up the best solution. And they determine whether it is financially and technically feasible or not. They also check if the customer budget would meet the cost of the product. They also check that they have sufficient experts in the area of development.

REQUIREMENT ANALYSIS AND SPECIFICATION

The aim of requirement analysis and specification is to understand the exact requirements of the customer. Documentation is also done in this phase. This phase is consist of two activities.

  1. Requirement Gathering and Analysis
  2. Requirement Specification

The goal of requirement gathering activity is to collect all relevant information from the customer. This is done to understand the customer requirements. The requirement analysis is started by collecting all relevant data of project from users and customers through discussion. For example to perform the requirement analysis of a business accounting software, analysts might interview all the accountants of company to know the requirements. The data collected from such a group of users contains several contradiction and inexactness. Because each user has a partial and incomplete view of the system. Therefore it is necessary to identify all inexactness and contradictions. Now these problems have to be resolved through further discussion with the customer. After all inexactness, inconsistency and incompleteness have been resolved and all the requirements are properly understood. The requirement specification can be started. During these activities the user requirements are systematically organized in software requirement specification document. The customer requirement identified during requirement gathering and analysis are known as SRS document. The important components of this document are listed below.

  1. Functional document
  2. Non functional document
  3. Goal of implementation

DESIGN

The aim of this phase is to transform the requirements specified into SRS document into the structure using some programming languages. In technical terms during the design phase the software architecture is derived from the SRS document. Two different approaches are used for designing.

  1. The Tradition Design Approach
  2. The Object-Oriented Design Approach

In object-oriented design approach various objects that occurred in problem and solution domain are first identified. Then different relationships that exist among them are identified. The object structure is further refined to obtained the detail design.

CODING AND UNIT TESTING

This phase is also called implementation phase. The purpose of coding and unit testing phase of software product is to convert SRS document into source code. Each component of design phase is treated as program module. The end product of this phase is a set of program modules that have been individually tested. During this phase each module is unit tested to determine the proper working of the individual modules. It involves testing of each module in isolation. Because this is the most efficient way to debug the errors identified at this stage. Unit testing is under taken when a module has been coded completely and successfully reviewed. Different methods are used for unit testing.

  1. Black box testing
  2. White box testing
  3. Mutation testing

INTEGRATION AND SYSTEM TESTING

Integration of different modules is done once they have been coded and unit tested. During integration and system testing the modules are integrated in a plane manner. The different modules making of a software are almost never integrated in one shot. Integration is normally carried out incrementing over number of steps. During each integration step the partially integrated system is tested and set of previously planned modules are added. Finally when all modules are integrated and tested, system testing is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements laid out into the SRS documents. System testing is usually consisted of three kinds of activities.

  1. Alpha testing
  2. Beta testing
  3. Acceptance testing

ALPHA TESTING:
It is the system testing performed by development team.

BETA TESTING:
It is the system testing performed by a friendly set of customers.

ACCEPTANCE TESTING:
It is the system testing performed by customer itself after the product delivery to determine whether to accept or reject the product.

MAINTENANCE

Maintenance of a typical software product requires much more effort than to develop the product. Many studies are carried out in the past conforms this and indicate that the relative effort of development of a typical software product to its maintenance is roughly 40 x 60 ratio. Maintenance of a software product involves performing anyone or more of the following kinds of activities:

  1. Corrective maintenance
  2. Perfective maintenance
  3. Adaptive maintenance

CORRECTIVE MAINTENANCE:
Correcting errors that were not discovered during the product development.

PERFECTIVE MAINTENANCE:
Improving the implementation of the system and enhancing the system functionalities according to the customer requirements.

ADAPTIVE MAINTENANCE:
Porting the software to work in a new environment for example porting may be required to work on a new computer platform or with a new operating system.

SHORTCOMING OF CLASSICAL WATERFALL MODEL

The classical waterfall model is an idealistic one. Since it is assumed that no development is committed by engineers during the life cycle model of software, however in practical development engineers do commit a large number of errors in almost every phase of the life cycle. The source of the defect can be many wrong assumptions, use of inappropriate technology, communication gap among project engineers etc. this defect usually get detected much larger in the life cycle. For example a design defect might be unnoticed till we reach the coding and testing phase. Once a defect is detected the engineer need to go back to the phase where the defect has been occurred.