Home » SOFTWARE ENGINEERING
Category Archives: SOFTWARE ENGINEERING
CLASSIFICATION OF COHESION
- COINCIDENTAL COHESION
- LOGICAL COHESION
- TEMPORAL COHESION
- PROCEDURAL COHESION
- COMMUNICATION COHESIONAL
- SEQUNTIAL COHESION
- FUNCTIONAL COHESION
CLASSIFICATION OF COUPLING
- DATA COUPLING
- STAMP COUPLING
- CONTROL COUPLING
- COMMON COUPLING
- CONTENT COUPLING
THE NEED FOR SOFTWARE LIFE CYCLE MODEL:
TYPES OF SOFTWARE LIFE CYCLE MODEL:
- CLASSICAL WATER FALL MODEL
- ITERATIVE WATER FALL MODEL
- PROTOTYPING WATER FALL MODEL
- EVOLUTIONARY MODEL
- SPIRAL MODEL
- COCOMO 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
- FEASIBILITY STUDY
- REQUIREMENT ANALYSIS AND SPECIFICATION
- CODING AND UNIT TESTING
- INTEGRATION AND SYSTEM TESTING
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.
- Requirement Gathering and Analysis
- 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.
- Functional document
- Non functional document
- Goal of implementation
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.
- The Tradition Design Approach
- 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.
- Black box testing
- White box testing
- 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.
- Alpha testing
- Beta testing
- Acceptance testing
It is the system testing performed by development team.
It is the system testing performed by a friendly set of customers.
It is the system testing performed by customer itself after the product delivery to determine whether to accept or reject the product.
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:
- Corrective maintenance
- Perfective maintenance
- Adaptive maintenance
Correcting errors that were not discovered during the product development.
Improving the implementation of the system and enhancing the system functionalities according to the customer requirements.
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.