‭INTRODUCTION:‬

S‭ oftware Engineering‬‭is a framework for building software‬‭and is an engineering approach to‬

‭software development. Software programs can be developed without S/E principles and‬
‭methodologies but they are indispensable if we want to achieve good quality software in a‬
‭cost effective manner.‬

S‭ OFTWARE ENGINEERING‬‭is defined as a systematic, disciplined‬‭and quantifiable approach for‬

‭the development, operation and maintenance of software.‬

‭SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY‬

‭• Quality focus - Bedrock that supports Software Engineering.‬

‭• Process - Foundation for software Engineering‬

‭• Methods - Provide technical How-to’s for building software‬

‭• Tools - Provide semi-automatic and automatic support to methods‬

‭NEED OF SOFTWARE ENGINEERING‬

T‭ he need of software engineering arises because of higher rate of change in user requirements‬
‭and environment on which the software is working.‬

∙‭‬‭Large software -‬‭It is easier to build a wall than‬‭to a house or building, likewise, as the size‬
‭of software become large engineering has to step to give it a scientific process.‬

∙‭‬‭Scalability-‬‭If the software process were not based‬‭on scientific and engineering concepts,‬
‭it would be easier to re-create new software than to scale an existing one.‬

∙‭‬ ‭Cost-‬ ‭As‬ ‭hardware‬ ‭industry‬ ‭has‬ ‭shown‬ ‭its‬ ‭skills‬ ‭and‬ ‭huge‬ ‭manufacturing‬ ‭has‬ ‭lower‬ ‭down‬ ‭the‬
‭price‬ ‭of‬ ‭computer‬ ‭and‬ ‭electronic‬ ‭hardware.‬ ‭But‬ ‭the‬ ‭cost‬ ‭of‬ ‭software‬ ‭remains‬ ‭high‬ ‭if‬ ‭proper‬
‭process is not adapted.‬

∙‭‬‭Dynamic Nature-‬‭The always growing and adapting‬‭nature of software hugely depends upon the‬
‭environment in which the user works. If the nature of software is always changing, new‬
‭enhancements need to be done in the existing one. This is where software engineering plays a‬
‭good role.‬

∙‭‬‭Quality Management-‬‭Better process of software development‬‭provides better and quality‬

‭software product.‬
‭CHARACTERESTICS OF GOOD SOFTWARE‬

‭ software product can be judged by what it offers and how well it can be used. This software‬
A
‭must satisfy on the following grounds:‬
‭∙‬‭Operational‬

‭∙‬‭Transitional‬

‭∙‬‭Maintenance‬

‭Operational‬

‭This tells us how well software works in operations. It can be measured‬

‭on:‬ ‭∙‬‭Budget‬

‭∙‬‭Usability‬

‭∙‬‭Efficiency‬

‭∙‬‭Correctness‬

‭∙‬‭Functionality‬

‭∙‬‭Dependability‬

‭∙‬‭Security‬

‭∙‬‭Safety‬

‭Transitional‬

‭This aspect is important when the software is moved from one platform to‬

‭another:‬ ‭∙‬‭Portability‬

‭∙‬‭Interoperability‬

‭∙‬‭Reusability‬

‭∙‬‭Adaptability‬

‭Maintenance‬

T‭ his aspect briefs about how well a software has the capabilities to maintain itself in the‬
‭ever changing environment:‬

‭∙‬‭Modularity‬

‭∙‬‭Maintainability‬
∙‭‬‭Flexibility‬

‭SOFTWARE DEVELOPMENT LIFE CYCLE(SDLC)‬

L‭ IFE CYCLE MODEL A software life cycle model (also called process model) is a descriptive and‬
‭diagrammatic representation of the software life cycle. A life cycle model represents all the activities‬
‭required to make a software product transit through its life cycle phases. It also captures the order‬
‭in which these activities are to be undertaken.‬

‭THE NEED FOR A SOFTWARE LIFE CYCLE MODEL‬

T‭ he development team must identify a suitable life cycle model for the particular project and‬
‭then adhere to it. Without using of a particular life cycle model the development of a software‬
‭product would not be in a systematic and disciplined manner. When a software product is being‬
‭developed by a team there must be a clear understanding among team members about when‬
‭and what to do.‬

E‭ xample- Suppose a software development problem is divided into several parts and the parts are‬
‭assigned to the team members. From then on, suppose the team members are allowed the‬
‭freedom to develop the parts assigned to them in whatever way they like. It is possible that one‬
‭member might start writing the code for his part, another might decide to prepare the test‬
‭documents first, and some other engineer might begin with the design phase of the parts assigned‬
‭to him. This would be one of the perfect recipes for project failure. A software life cycle model‬
‭defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria have‬
‭been satisfied. So without software life cycle model the entry and exit criteria for a phase cannot‬
‭be recognized. Without software life cycle models it becomes difficult for software project‬
‭managers to monitor the progress of the project.‬

‭Different software life cycle models‬

‭ any life cycle models have been proposed so far. Each of them has some advantages as well‬
M
‭as some disadvantages. A few important and commonly used life cycle models are as follows:‬

‭∙‬‭Classical Waterfall Model‬

‭∙‬‭Iterative Waterfall Model‬

‭∙‬‭Prototyping Model‬

‭∙‬‭Evolutionary Model‬

‭∙‬‭Spiral Model‬
‭1. CLASSICAL WATERFALL MODEL‬
T‭ he classical waterfall model is intuitively the most obvious way to develop software.‬
‭Though the classical waterfall model is elegant and intuitively obvious, it is not a practical‬
‭model in the sense that it cannot be used in actual software development projects. Thus,‬
‭this model can be considered to be a theoretical way of developing software. But all other‬
‭life cycle models are essentially derived from the classical waterfall model. So, in order to‬
‭be able to appreciate other life cycle models it is necessary to learn the classical waterfall‬
‭model.‬
‭Feasibility study –‬
T‭ he main aim of feasibility study is to determine whether it would be financially‬
‭and technically feasible to develop the product.‬
∙‭‬‭At first project managers or team leaders try to‬‭have a rough understanding of what is‬
‭required to be done by visiting the client side. 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 these data and they look at the various constraints on the behavior‬
‭of the system.‬
∙‭‬‭After they have an overall understanding of the‬‭problem they investigate the different‬
‭solutions that are possible. Then they examine each of the solutions in terms of what kind‬
‭of resources required, what would be the cost of development and what would be the‬
‭development time for each solution.‬
‭∙‬‭Based‬‭on‬‭this‬‭analysis‬‭they‬‭pick‬‭the‬‭best‬‭solution‬‭and‬‭determine‬‭whether‬‭the‬‭solution‬‭is‬
‭feasible‬‭financially‬‭and‬‭technically.‬‭They‬‭check‬‭whether‬‭the‬‭customer‬‭budget‬‭would‬‭meet‬
‭the‬‭cost‬‭of‬‭the‬‭product‬‭and‬‭whether‬‭they‬‭have‬‭sufficient‬‭technical‬‭expertise‬‭in‬‭the‬‭area‬
‭of development.‬

‭Requirements analysis and specification: -‬

T‭ he aim of the requirements analysis and specification phase is to understand the exact‬
‭requirements of the customer and to document them properly. This phase consists of‬
‭two distinct activities, namely‬
∙‭‬‭Requirements gathering and analysis‬
‭∙‬‭Requirements specification‬
‭The goal of the requirements gathering activity is to collect all relevant information from‬
‭the customer regarding the product to be developed. This is done to clearly understand‬
‭the customer requirements so that incompleteness and inconsistencies are removed.‬

T‭ he requirements analysis activity is begun by collecting all relevant data regarding the‬
‭product to be developed from the users of the product and from the customer through‬
‭interviews and discussions. For example, to perform the requirements analysis of a‬
‭business accounting software required by an organization, the analyst might interview all‬
‭the accountants of the organization to ascertain their requirements. The data collected‬
‭from such a group of users usually contain several contradictions and ambiguities, since‬
‭each user typically has only a partial and incomplete view of the system. Therefore it is‬
‭necessary to identify all ambiguities and contradictions in the requirements and resolve‬
‭them through further discussions with the customer. After all ambiguities, inconsistencies,‬
‭and incompleteness have been resolved and all the requirements properly understood, the‬
‭requirements specification activity can start. During this activity, the user requirements are‬
‭systematically organized into a Software Requirements Specification (SRS) document. The‬
‭customer requirements identified during the requirements gathering and analysis activity‬
‭are organized into a SRS document. The important components of this document are‬
‭functional requirements, the non functional requirements, and the goals of‬
‭implementation.‬

‭ esign: - The goal of the design phase is to transform the requirements specified in the‬
D
‭SRS document into a structure that is suitable for implementation in some programming‬
‭language.‬
‭In‬ ‭technical‬ ‭terms,‬ ‭during‬ ‭the‬ ‭design‬ ‭phase‬ ‭the‬ ‭software‬‭architecture‬‭is‬‭derived‬‭from‬‭the‬
‭SRS‬ ‭document.‬ ‭Two‬ ‭distinctly‬ ‭different‬ ‭approaches‬ ‭are‬ ‭available:‬ ‭the‬ ‭traditional‬ ‭design‬
‭approach and the object-oriented design approach.‬
∙‭‬‭Traditional design approach -‬‭Traditional design‬‭consists of two different activities; first‬
‭a structured analysis of the requirements specification is carried out where the detailed‬
‭structure of the problem is examined. This is followed by a structured design activity.‬
‭During structured design, the results of structured analysis are transformed into the‬
‭software design.‬
∙‭‬‭Object-oriented design approach -‬‭In this technique,‬‭various objects that occur in the‬
‭problem domain and the solution domain are first identified, and the different‬
‭relationships that exist among these objects are identified. The object structure is further‬
‭refined to obtain the detailed design.‬

‭Coding and unit testing:-‬

T‭ he purpose of the coding phase (sometimes called the implementation phase) of‬
‭software development is to translate the software design into source code. Each‬
‭component of the‬
‭design is implemented as a 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 correct working of all the individual modules. It involves‬
‭testing each module in isolation as this is the most efficient way to debug the errors‬
 ‭identified at this stage.‬
‭Integration and system testing: -Integration of different modules is undertaken once they‬
‭have been coded and unit tested. During the integration and system testing phase, the‬
‭modules are integrated in a planned manner. The different modules making up a software‬
‭product are almost never integrated in one shot. Integration is normally carried out‬
‭incrementally over a number of steps. During each integration step, the partially integrated‬
‭system is tested and a set of previously planned modules are added to it. Finally, when all‬
‭the modules have been successfully 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 in the SRS document. System testing usually consists of three‬
‭different kinds of testing activities:‬
‭∙‬‭α – testing:‬‭It is the system testing performed‬‭by the development team.‬ ‭∙‬‭β –testing:‬‭It‬
‭is the system testing performed by a friendly set of customers.‬ ‭∙‬‭Acceptance testing:‬‭It is‬
t‭ he system testing performed by the customer himself after the product delivery to‬
‭determine whether to accept or reject the delivered product. System testing is normally‬
‭carried out in a planned manner according to the system test plan document. The system‬
‭test plan identifies all testing-related activities that must be performed, specifies the‬
‭schedule of testing, and allocates resources. It also lists all the test cases and the expected‬
‭outputs for each test case.‬

‭Maintenance: -‬‭Maintenance of a typical software product‬‭requires much more than the‬

e‭ ffort necessary to develop the product itself. Many studies carried out in the past‬
‭confirm this and indicate that the relative effort of development of a typical software‬
‭product to its maintenance effort is roughly in the 40:60 ratios.‬

‭Shortcomings of the classical waterfall model‬

T‭ he classical waterfall model is an idealistic one since it assumes that no development error‬
‭is ever committed by the engineers during any of the life cycle phases. However, in practical‬
‭development environments, the engineers do commit a large number of errors in almost‬
‭every phase of the life cycle. The source of the defects can be many: oversight, wrong‬
‭assumptions, use of inappropriate technology, communication gap among the project‬
‭engineers, etc. These defects usually get detected much later in the life cycle. For example,‬
‭a design defect might go unnoticed till we reach the coding or testing phase. Once a defect‬
‭is detected, the engineers need to go back to the phase where the defect had occurred and‬
‭redo some of the work done during that phase and the subsequent phases to correct the‬
‭defect and its effect on the later phases. Therefore, in any practical software development‬
‭work, it is not possible to strictly follow the classical waterfall model.‬
‭2. ITERATIVE WATERFALL MODEL‬
T‭ o overcome the major shortcomings of the classical waterfall model, we come up with‬
‭the iterative waterfall model.‬
 ‭Here,‬
‭ e provide feedback paths for error correction as & when detected later in a phase.‬
w
‭Though errors are inevitable, but it is desirable to detect them in the same phase in‬
‭which they occur. If so, this can reduce the effort to correct the bug.‬

T‭ he‬‭advantage‬‭of this model is that there is a working‬‭model of the system at a very early‬
‭stage of development which makes it easier to find functional or design flaws. Finding‬
‭issues at an early stage of development enables to take corrective measures in a limited‬
‭budget.‬

T‭ he‬‭disadvantage‬‭with this SDLC model is that it is‬‭applicable only to large and bulky‬
‭software development projects. This is because it is hard to break a small software‬
‭system into further small serviceable increments/modules.‬

‭3.‬‭PRTOTYPING MODEL‬

‭ rototype‬
P
‭A prototype is a toy implementation of the system. A prototype usually exhibits limited‬
‭functional capabilities, low reliability, and inefficient performance compared to the‬
‭actual software. A prototype is usually built using several shortcuts. The shortcuts might‬
‭involve using inefficient, inaccurate, or dummy functions. The shortcut implementation‬
‭of a function, for example, may produce the desired results by using a table look-up‬
‭instead of‬
‭performing the actual computations. A prototype usually turns out to be a very‬
‭crude version of the actual system.‬

‭Need for a prototype in software development.‬

T‭ here are several uses of a prototype. An important purpose is to illustrate the input data‬
‭formats, messages, reports, and the interactive dialogues to the customer. This is a valuable‬
‭mechanism for gaining better understanding of the customer’s needs:‬ ‭∙‬‭How the screens‬
‭might look like‬
∙‭‬‭how the user interface would behave‬
‭∙‬‭how the system would produce outputs‬

‭Another reason for developing a prototype is that it is impossible to get the perfect‬
 ‭ roduct in the first attempt. Many researchers and engineers advocate that if you want to‬
p
‭develop a good product you must plan to throw away the first version. The experience‬
‭gained in developing the prototype can be used to develop the final product.‬

‭ prototyping model can be used when technical solutions are unclear to the‬
A
‭development team. A developed prototype can help engineers to critically examine the‬
‭technical issues associated with the product development. Often, major design decisions‬
‭depend on issues like the response time of a hardware controller, or the efficiency of a‬
‭sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way‬
‭to resolve the technical issues.‬

‭ prototype of the actual product is preferred in situations such as:‬

A
‭• User requirements are not complete‬
‭• Technical issues are not clear‬
‭4. EVOLUTIONARY MODEL‬
I‭t is also called successive versions model or incremental model. At first, a simple working model is‬
‭built. Subsequently it undergoes functional improvements & we keep on adding new functions till‬
‭the desired system is built.‬
‭Applications:‬
‭∙‬‭Large projects where you can easily find modules‬‭for incremental implementation. Often used‬
‭when the customer wants to start using the core features rather than waiting for the full software.‬
∙‭‬‭Also used in object oriented software development‬‭because the system can be easily portioned‬
‭into units in terms of objects.‬

‭Advantages:‬
∙‭‬‭User gets a chance to experiment partially developed‬‭system‬
‭∙‬‭Reduce the error because the core modules get tested‬‭thoroughly.‬

‭Disadvantages:‬
∙‭‬‭It is difficult to divide the problem into several‬‭versions that would be acceptable to the customer‬
‭which can be incrementally implemented & delivered.‬
‭5. SPIRAL MODEL‬
T‭ he diagrammatic representation of this model appears like a spiral with many loops. The‬
‭exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase‬
‭of the software process.‬
‭For example, the innermost loop might be concerned with feasibility study, the next loop‬
‭with requirements specification, the next one with design, and so on. Each phase in this‬
‭model is split into four sectors (or quadrants) . The following activities are carried out‬
‭during each phase of a spiral model.‬
F‭ irst quadrant (Objective Setting)‬
‭• During the first quadrant, it is needed to identify the objectives of the‬
‭phase. • Examine the risks associated with these objectives.‬

S‭ econd Quadrant (Risk Assessment and Reduction)‬

‭• A detailed analysis is carried out for each identified project risk.‬
‭• Steps are taken to reduce the risks.‬
‭For example, if there is a risk that the requirements are inappropriate, a prototype‬
‭system may be developed.‬

‭Third Quadrant (Development and Validation)‬

‭• Develop and validate the next level of the product after resolving the identified‬
‭risks. Fourth Quadrant (Review and Planning)‬
‭• Review the results achieved so far with the customer and plan the next iteration‬
‭around the spiral.‬
‭• Progressively more complete version of the software gets built with each iteration‬
‭around the spiral.‬

‭ ircumstances to use spiral model‬

C
‭The spiral model is called a meta model since it encompasses all other life cycle models.‬
‭Risk handling is inherently built into this model. The spiral model is suitable for‬
‭development of technically challenging software products that are prone to several kinds‬
‭of risks. However, this model is much more complex than the other models – this is‬
‭probably a factor deterring its use in ordinary projects.‬
‭Comparison of different life-cycle models‬

T‭ he classical waterfall model can be considered as the basic model and all other life cycle‬
‭models as embellishments of this model. However, the classical waterfall model cannot be‬
‭used in practical development projects, since this model supports no mechanism to‬
‭handle the errors committed during any of the phases.‬

T‭ his problem is overcome in the iterative waterfall model. The iterative waterfall model is‬
‭probably the most widely used software development model evolved so far. This model is‬
‭simple to understand and use. However this model is suitable only for well-understood‬
‭problems; it is not suitable for very large projects and for projects that are subject to‬
‭many risks.‬

T‭ he prototyping model is suitable for projects for which either the user requirements or‬
‭the underlying technical aspects are not well understood. This model is especially popular‬
‭for development of the user-interface part of the projects.‬

T‭ he evolutionary approach is suitable for large problems which can be decomposed into a‬
‭set of modules for incremental development and delivery. This model is also widely used‬
‭for object oriented development projects. Of course, this model can only be used if the‬
‭incremental delivery of the system is acceptable to the customer.‬
‭The spiral model is called a meta model since it encompasses all other life cycle models.‬
‭Risk handling is inherently built into this model. The spiral model is suitable for‬
‭development of technically challenging software products that are prone to several kinds‬
‭ f risks. However, this model is much more complex than the other models – this is‬
o
‭probably a factor deterring its use in ordinary projects.‬

T‭ he different software life cycle models can be compared from the viewpoint of the‬
‭customer. Initially, customer confidence in the development team is usually high irrespective‬
‭of the development model followed. During the lengthy development process, customer‬
‭confidence normally drops off, as no working product is immediately visible. Developers‬
‭answer customer queries using technical slang, and delays are announced. This gives rise to‬
‭customer resentment. On the other hand, an evolutionary approach lets the customer‬
‭experiment with a working product much earlier than the monolithic approaches. Another‬
‭important advantage of the incremental model is that it reduces the customer’s trauma of‬
‭getting used to an entirely new system. The gradual introduction of the product via‬
‭incremental phases provides time to the customer to adjust to the new product. Also, from‬
‭the customer’s financial viewpoint, incremental development does not require a large‬
‭upfront capital outlay. The customer can order the incremental versions as and when he can‬
‭afford them.‬