‘ oBJE! ? + ‘Adaptability — In pifectiveness according to th es tO mal e standards. Software standards are the big target of sompani ke it more effective. So Software becomes more c effective i7 the act with the help of software engineering. CTIVES oF SOFTWARE ENGINEERING Maintainability — It should be feasible for the software to evolve eet changing requirements. ‘oftware should not make wasteful use of ry, processor cycles, etc. tom Efficiency — The s computing devices such as memo! ‘A software product is correct if the different Correctness — ified in the SRS document have been requirements as spet correctly implemented. Reusability — A software product has good reusability if the different modules of the product can easily be reused to develop ar new products. Testability — Here software of test criteria and the eval those criteria. Reliability — It is an attri which a program can be exp c over an arbitrary time peri Portability — In this case, one computer system or constraints and the to the software.Software En, INeerin M4 fhware & 4.3) NATURE OF SOFTWARE The nature of software has changed a lot over the years 1. System Software: Infrastructure software come under 4 hig category like compilers, operating systems, editors 8, drive Tivers, et, Basically, system software is a collection of prog: TAMS t0 provig ide service to other programs Real Time Software: These software are used to monitor. Contro, 0 and analyze real world events as they occur, An example m, a T forecasting. Such Softwar gather and process the status of temperature, be software required for weathe: © wily i humidity and other environmental parameters to for cast the weather, 3. Embedded Software: This ty Only- Memory (ROM)” of the Product and control t! functions of the product. The Product could be automobile, security system, signalling system, control unit of Power plants, etc. The embedded software handles hardware components and is also termed as intelligent software . monitoring system, employee management, account management, It may also be a data warehousing tool which helps us to take decisions based on available data. Management information system, enterprise resource planning (ERP) and such other software are popular examples of business software. 5. Personal Computer Software : The software used in personal computers are covered in this . Examples are word 1 and animating tools,introdvetion to Software Engineering 15 ie i " | 6. Artificial Intelligence Software: Artificial Intelligence software makes use of non numerical algorithms to solve complex problems ation or straight forward analysis. Examples are expert systems, artifici that are not amenable to comput. : ial neural network, signal processing software etc, Web Based Software: The software related to web applications come under this category. Examples are CGI, HTML, Java, Perl. DHTML ete. 4.4 SOFTWARE ENGINEERING VS COMPUTER SCIENCE The difference between the software engineering and computer science given in the table. Table 1.1 Software Engineering VS Computer Science Parameter Software Engineering Computer Science Software engineering is defined as a process of Definition Computer science is a discipline that involves the design and understanding of computers and computational processes. analyzing user requirements and then designing, building, and testing software applications. “Computer Science is the of how computers Software Engineering a study of how systems are built. SelectionSoftware Engineering Lé Parameter | sonware Engineering Computer Science iad | Project Students of software | Project management management | engineering will likely | is often included in | take courses on project | the computer science | management, both in | curriculum. Mostly as part undergraduate and graduate | of a software engineering [ programs. course. | | Course In Software Engineering, you | Computer science students | include will also learn programming | will study how data is | languages and general | stored, processed, and | computing principles. applied on various other | computing devices. Scope Emerging occupations | It is a field of computer related to software | science which also includes | engineering depend on | careers in cloud computing | the state of software and | and Al technology. technology in the future. 1.5 EVOLUTION - FROM AN ART FORM TO AN ENGINEERING DISCIPLINE Software Engineering principles have evolved over the years with the contributions of various researchers and software professionals. From the beginning period Software Engineering acts as an Art after that with time, it transformed into a craft and finally to Engineering Discipline. 1.5.1 Evolution of an Art into an Engineering Discipline Software engineering principles have evolved over the last sixty years with contributions from numerous researchers and software professionals. Over the years, it has emerged from a pure art to a craft, and finally to an engineering discipline. The early programmers used an ad hoc programming style. This style of program developn variously being referred to as exploratory, build and fix, and styles. The exploratory i there are no set rulesyirogvetion to Somwore Eromeemn@ “ recommendations that a programmer has to adhere to-every programmer pimseif evolves his own software development techniques solely guided py hisown intuition, experience, whims, and fancies. The exploratory style comes naturally to all first time programmers. The build and fix style was widely adopted by the Programmers in the early years of computing history. We can consider the exploratory program development style as an art-since this style, as is the case with any art, is mostly guided by intuition. There are many stories about Programmers in the past who were like proficient artists and could write good programs using an essentially build and fix model and some esoteric knowledge. The bad programmers were left to wonder how could some programmers effortlessly write elegant and correct programs each time. In contrast . the programmers working in modern software industry rarely make use of any esoteric knowledge and develop software by applying some well-understood principles. 1.5.2 Evolution Pattern for Engineering Disciplines If we analyse the evolution of the software development styles over the last sixty years, we can easily notice that it has evolved from an esoteric art form to a craft form, and then has slowly emerged as an engineering discipline. As a matter of fact, this pattern of evolution is not very different _ from that seen in other engineering disciplines. Irrespective of whether itis iron making, paper making, software. ) ildit tr n evolution of technology has followed strikingl} ! This pattern of technology shown in Figure 1.1. It can be seen in the initial years starts as a fon and finally emerges as anA Software Engineering 18 making, kept it a closely-guarded transferred from generation to generation This esoteric knowledge gor as a family secret. Slowly, over time technology graduated from an art to a craft form where tradesmen shared their knowledge with their apprentices and the knowledge pool continued to grow. Much later, through a systematic organisation and documentation of knowledge, and incorporation of scientific basis, modern steel making technology emerged. The story of the evolution of the software engineering discipline is not much different. Engineering Unorganised use of Past experience Systematic use of past ‘experience and formulation of scientific basis ‘Technology Esoteric use of past experience Time Fig. 1.1 Evolution of Technology with Time Software engineering principles are now being widely used in industry, and new principles are still continuing to emerge at a very rapid rate - making this discipline highly dynamic. In spite of its wide acceptance, critics point out that many of the methodologies and guidelines provided by the software engineering discipline lack scientific basis, are subjective, and often inadequate. Yet, ‘is no denying the fact that adopting software ques facilitate development of high quality software in € proven to be indispensable to though exploratory styles areraroguctionte Sofware Engivewtng ng often used successfully to develop small programs such as those written by sofware Development Life Cye Je io a spiritual model used in prey oniware agement that defines the stages include in an information 4y: mManagene : es development project, from an initial feasibility study to the rvaintey of the completed application, 1 here are different software developmens jj eycle models specify and design, which are followed during the softy development phase, These models are also called Process Models.” Bach process model follows a series of phase unique its type to ensure success in the step of software development. “Software Develop ‘Types (Examples) of Software developing life cycles (SDLC) 1, Waterfall Model 2. V-Shaped Model 3. Evolutionary Prototyping Model 4, Spiral Method (SDM) 5. Iterative and Incremental Method 6. Agile development 1.8.2 Process versus Methodology Process has a broader scope and addresses either all the acti taking place during software development, or certain coarse activities such as design, testing, etc. Further, a software process not ident the specific activities that need to be carried out, but may prescribe certain methodology for carrying out each activity. For exan a design process may recommend that in the design stage, the design activity be carried out using Hatley and Pirbhai’s and design methodology. A methodology, on the other hand, has a narrower on finer-grained activities as compared to a process, steps for carrying out a specific life cycle activity. It rationale and philosophical assumptions behind the which the activity is accomplished. :auction to Software Engineering 149 403 advantage of using a development process rhe primary advantage of using a development process is that it es development of software in a systematic and disciplined encourag’ manner Ad software needing team effort. When software is developed by ering to a process is especially important for development of fessional Pca rather than by an individual programmer, use of a life cycle model pecomes indispensable for successful completion of the project. Let us first consider the case of a single programmer developing a ‘small program An example of this is that a student is writing the program for a classroom assignment. The student might succeed even when he does not strictly follow a specific development process and adopts a build and fix style of development. However, it is a different ball game when a professional software is being developed by a team of programmers. When a software is developed by a team, it is necessary to have a precise understanding among the team members as to—when to do what. In the absence of such an understanding, each member at any time would do whatever activity he feels like doing. This would be an open invitation 40 developmental chaos and project failure. The use of a suitable life cycle ‘model is crucial to the successful completion of a team-based development project. 1.8.4 Document a development process ‘ <2 hi pee ened t It is not enough for an organisation to just have a eriieine development process, but the development process needs to evelopment process is not adequately as follows: :software Engineering 1,20 PERRI ELT % A-documented process model ensures that every activity in qe life eyele is necurately defined, Vurther, the methodologies foy carrying out the activities are described, Without documentation, the activities and their ordering tend to be loosely defined, ang different methodologies may be used by the developers even fa, the same activity, This can lead to confusion and is iMMerpretation, © An undocumented process gives a clear indication to the member, of the development teams about the lack of seriousness on the part of the management of the organisation about following the process, Therefore, an undocumented process serves as a hint to the developers to loosely follow the process, © A project team might often have to tailor a standard process mode} for use in a specific project. It is easier to tailor a documenteg process model, when it is required to modify certain activities or phases of the life cycle. ~* A documented process model, as we discuss later, is a mandatory requirement of the modern quality assurance standards such as 1SO 9000 and SEI CMM. In the absence of a quality certification for the organisation, the customers would be Suspicious of its capability of developing quality software and the organisation might find it difficult to win tenders for software development. api Sta 1.8.5 Phase entry and exit ortteg Se 5 A good SDLC besides the different phases in the life cycle, should unambiguou entry and exit criteria for each ) usually expressed as a set of As an e Specification p (SRS) document is reviewed and satisfied, theif the entry and exit criteria for ghen that would leave enough scope for ambiguity in starting and ending phases, and cause a lot of confusion among the developers. The various decision regarding whether a phase is complete or not becomes subjective and it becomes difficult for the project manager to accurately tell how much has the development progressed. When the phase entry and exit criteria are not well-defined, the jopers might close the activities of a phase much before they are Jete, giving a false impression of rapid progress. In this case, it becomes VeTY difficult for the project manager to determine the exact status of development and track the progress of the project. 4.9 CLASSICAL WATERFALL MODEL devel actually comp! Classical waterfall model is intuitively the most obvious way to develop software. It is simple but idealistic. The waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. In this waterfall model, the phases do not overlap. The classical waterfall model divides the life cycle into six phases as shown in Fig. 1.4. It can be easily yed fro is figure that the diagrammatic representation of the cl multi-level waterfall.Feasibility study | Roquirements analysis — and specification Coding and — unit testing , Integration and — system testing Maintenance Fig. 1.4 Classical Waterfall Model 1.8.1 Phases of Classical Waterfall Model The following are six phases 1. Feasibility Study Requirement Analysis & Specification Design Coding and Unit Testing Integration and Unit Testing Stier 4) Ky Maintenance 1.. Feasibility study The feasibility study is a very crucial stage in software development. The main focus of the feasibility study stage is to determine whether it would be financially and technically feasible to develop the software. The feasibility study involves carrying out several activities such as collection of basic information relating to the software such as the different data items that would be input to the system, the processing required to be carried out on these data, the output data required to be produced by theto Softwore Engineering 1.23 cystem, @S well as various constraints on the development. These collected data are analysed to perform the following: i pevelopment of an overall understanding of the problem: jt is necessary to first develop an overall understanding of what the customer requires to be developed. For this, only the important requirements of the customer need to be understood and the details of various requirements such as the screen layouts required in the graphical user interface (GUD, specific formulas or algorithms required for producing the required results, and the databases schema to be used are ignored. it Formulation of various possible strategies for solving the problem: In this activity, various possible high-level solution schemes to the problem are determined. For example, solution ina client-server framework and a standalone application framework may be explored. iii. Evaluation of the different solution strategies: The different identified solution schemes are analysed to evaluate their benefits and shortcomings. Such evaluation often requires making approximate estimates of the resources required, cost of development, and development time required. eee ‘ : The different solutions are compared based on the estimations that have been worked out, Once the best solution is identified, all activities in the later phases are carried out as per this solution. — s pee ravi 2. Requirements analysis and specification . The use of the requirements a understand the exact requirements of properly. This phase consists of two d i. Requirements gathering ii. Requirements sThe goal of the requirements gathering activity is to collect aly Teley, a3 a stomer Wi Tequiremen, tivity is to Weed out the incompleteness and inconsistencie, 4 i these gathered requirements. information regarding the software to be developed from the cu @ View to clearly understand the requirements. The goal of the analy ii, Requirements specification: After the requirement gathering and analysis activities are com, the identified requirements are documented. This document is cal software requirements specification (SRS) document. The SRS doe is written using end-user terminology. This makes the SRS doc understandable to the customer, Plete, led 4 ‘UMent ‘Uument The SRS document normally serves as a contract between the development team and the customer. Any future dispute between the customer and the developers can be settled by examining the SRS document, 3. Design The goal of the design phase is to transform the requirements Specified in the SRS document into a structure that is suitable for implementation in some programming language. Two distinctly different design approaches are popularly being used at present-the Procedural and object-oriented design approaches. ise i. Procedural design approach: The traditional procedural design 0 developments projects at the present time. This: is based on data flow modelling. It co structured analysis of the r ; spei the data flow structure of th 1 This is followed by structured analysis are tra| _ modules are added to the ps g (Cibject-oriented design approach: In this technique. various objects that occur in the problem domain pnd the solution domain are first identified and the different relationships goat exist among these objects are identified. The object structure is further wefined to obtain the detailed design. The OOD approach is credited to jnave several benefits such as lower development time and effort, and better maintainability of the software. 4. Coding and unit testing The purpose of the coding and unit testing phase is to translate 2 software design into source code and to ensure that individually each function is working correctly. The coding phase is also sometimes called implementation phase, since the design is implemented into a workable in this phase. Each component of the design is implemented as a athe solution program module. The end-product of this phase is a set of program modules that have been individually unit tested. The main objective of unit testing is 40 determine the correct working of the individual modules. The specific activities carried out during unit testing include designing test cases, testing, debugging to fix problems, and management of test cases. Integration of different modules is undertaken soon after they have been coded and unit tested. During the integration and n | weer phase, the different modules are integrated i planned ious. s modules making up a software are almost Integration of various modules are n over a number of steps. During system is tested, Finally, after all the m tested, the full working sy:Software Engines 1.26 Iterative W aterfal : fe ck i vious © Every phase contains feedback path to its pre phase. : -e changes or any modifications 2, _ is is an simple to make chang! at any > Thi phase. : By using this model, developer can completer project earlier : i i ired during the Customer involvement 1s not requir ig Softwa development. This model is suitable for large and complex projects. 1.10.2 Disadvantages of Iterative Waterfall Model Difficult to accommodate change requests: A major Problem, with the waterfall model is that the requirements need to be frozen before the development starts. Based on the frozen requirements detailed plans are made for the activities to be carried out during the design, coding, and testing phases. Incremental delivery not supported: In the iterative waterfal] model, the full software is completely developed and testeq before it is delivered to the customer. There is no provision fo; any intermediate deliveries to occur. This is problematic because the complete application may take several months or years to be completed and delivered to the customer. Error correction unduly expensive: In waterfall model, validation is delayed till the complete development of the software. As a result, the defects that are noticed at the time of validation incur expensive rework and result in cost escalation and delayed delivery. + Limited customer interactions: This model supports very limited customer interactions. It is generally accepted that software developed in isolation from the customer is the cause of manyIntroduction to Software Engineering 131 habitat etre D bhi hihi, ee Ft) F problems. In fact, interactions occur only at the start of the project and at project completion. Heavy weight: The waterfall model — overemphasises documentation. A significant portion of the time of the developers is spent in preparing documents, and revising them as changes occur over the life cycle. Heavy documentation though useful during maintenance and for carrying out review, is a source of team inefficiency. No support for risk handling and reuse: It becomes difficult to use the waterfall model in projects that are susceptible to various + types of risks, or those involving significant reuse of existing development artifacts. Please recollect that software services type of projects usually involve significant reuse of requirements, design and code. Therefore, it becomes difficult to use waterfall model in services type of projects. 4.11 RAPID APPLICATION DEVELOPMENT (RAD) Rapid application development is a software development methodology that uses minimal planning in favour of rapid prototyping. A prototype is a working model that is functionally equivalent to a component of the product. The Rapid Application Development (RAD) model is based on prototyping and iterative development with no specific planning involved. The process of writing the software itself involves the planning required for developing the product. Rapid Application Development focuses on gathering customer requirements through workshops or focus groups, early testing of the prototypes by the customer using iterative concept, reuse of the existing prototypes (components), continuous integration and rapid delivery. Applications ~ This model should be used for a system with known requirements and requiring short development time. Oe PEO een modularized and reusable components are also availabe A fy development, The model can also be used when already existing sys components can be used in developing a new system minimum changes, This model can only be used if the teams consist of domain na ‘This is because relevant knowledge and ability to Use po) techniques is a necessity. Advantages * Use of reusable components helps to reduce the cycle time Of the project. © Feedback from the customer is available at initial stages, ~ Reduced costs as fewer developers are required, © Use of powerful development tools results in better quality Products in comparatively shorter time spans. * The progress and development of the Project can be measured * It is easier to accommod: 1 ? ents due to the Disadvantages + The use ofintroduction to Software Engineering tas Customer involvement is required throughout the life cycle. It is not meant for small scale Projects as for such cases, the cost of using automated tools and techniques may exceed the entire budget of the project. The model should be chosen when the budget permits the use of automated tools and techniques required. 4.12 COMPARISON OF RAD WITH OTHER MODELS The comparison of RAD with other models is shown in table 1.3. Table 1.3 Difference between RAD and other models Properties of | Water-Fall | Incremental Model Model Yes Returning to an | No ‘Yes earlier phase Handle Large- | Not Project Detailed Yes Requirement SpecificationsSoftware Engin, 1.34 Spiral ps fall | Incremental Properties of Water-Fa asia Model Model Model 1 rr Linear +] Linear + | Linear eee a Iterative Iterative Type el : er ery | At the | After Testing After ARSE os. shs na) Seal Ocatne completion of | iteration en ; coding phase engineering codices phase Overlapping | No Yes (As parallel | No Yes Phases development is there) Maintenance Least Maintainable Yes E"a soi Maintainable = Maintainable Re-usability Least To some extent | To some | Yes possible extent Time-Frame Very Long Long Long Short Working At the end of | At the end of | At the end | At the end of software the life-cycle | every iteration | of every | the life cycle availability = iteration Objective High Rapid High Rapid t Assurance Development Assurance development ‘Team size Large Team | Not Large Team oe Customer | Very Low Yes control over administrator 1.13 AGILE DEVELOPMENT MODELS In earlier days Iterative Waterfall model a project. But nowadays developers face vario develop software. The main difficulties from customers during project de required to incorporate these chi Waterfall model, in the mid-1990s th was proposed.to Sofware Engineering The Agile mode! was primarily designed to help a project to adapt to “hance requests quickly. So, the main aim of the Agile model is to facilitate quick project completion. To accomplish this task agility is required. Agilit is achieved by fitting the process to the project, removing activities “het may not be essential for a specific project. Also, anything that is waste “pftime and effort is avoided. 4.13.1 Agile Model Actually Agile model refers to a group of development processes. | hese processes share some basic characteristics but do have certain subtle GiSierences among themselves. A few Agile SDLC models are given below: 1. Crystal 2. Aten 3. Feature-driven development 4. Scrum Extreme programming (XP) 6. Lean development Ww 7. Unified process In the Agile model, the requirements are d small parts that can be incrementally developed. The A Iterative development. Each incremental part is iteration. Each iteration is intended to be small and _ can be completed within a couple of weeks only. A planned, developed and deployed to the c hot made. Agile model is the combination of models. The steps involve in agile $ Step 1: Requirement gathering Step 2: Requirements aaa Step 3: Designpoeore Engine, 7 SS ——————_ Step 4: Coding Step 5: Unit testing Step 6: Acceptance testing The time to complete an iteration is known as a pie Box. Time refers to the maximum amount of time needed to deliver an iteration customers. So, the end date for an iteration oes not changes Though ; development team can decide to reduce the delivered Tunchonality def a Time-box if necessary to deliver it on time. The central Principle of Agile model is the delivery of an increment to the customer after oul Time-box. 1.13.2 Principles of Agile Model ~ To establish close contact with the customer during developmen, and to gain a clear understanding of various requirements, each Agile project usually includes a customer representative on team. At the end of each iteration stakeholders and the custome, representative review, the progress made and re-evaluate the requirements. ~* Agile model relies on working software deployment rather than comprehensive documentation. ~* Frequent delivery of incremental customer representative i ~ Requirement change requests and efficiently incorporated. ~ It emphasizes on having communications among team memberscanbeach rather than through the > Itis recommended tha small (5 to 9 peIntroduction to Software Engineering 1.37 engage in face-to-face communication and have collaborative work environment, ~ Agile development process usually deploys Pair Programming. In Pair programming, two programmers work together at one work- station. One does coding while the other reviews the code as it is typed in. The two programmers switch their roles every hour or so. 4.13.3. Advantages: Working through Pair programming produce well written compact programs which have fewer errors as compared to programmers working alone. > It reduces total development time of the whole project. Customer representatives get the idea of updated software products after each iteration. So, it is easy for him to change any requirement if needed. 1.13.4 Disadvantages: “Due tolack of formal documents, it creates confusion and important decisions taken during different phases can be misinterpreted at any time by different team members. “+ Due to the absence of proper documentation, when the project completes and the developers are assigned to another project, maintenance of the developed project can become a problem. 1.14 SPIRAL MODEL Spiral model is one of the most Life Cycle models, which provides support _ diagrammatic representation, it looks il The exact number of loops of the spira _ Project to project. Each loop of the. ; development process.Software Engine, a The exact number of phases d to develop te Product can varied by the project manager depending upon the project risks, As project manager dynamically determines the number of phases, So project manager has an important role to develop a product using the of model. The Radius of the spiral at any point represents the expenses(costy the project so far, and the angular dimension represents the progress mag rq so far in the current phase. 2. Identify and resolve risks 1. Determine objectives and identify alternative solutions | shown in the above figure. The discussed below- 1, Objectives d Requirements. are identified, elabotatroduction to Softwore Engineering 1.39 | alternative solutions possible for the phase are proposed in this quadrant. 2. Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select the best possible solution. Then the risks associated with that solution are identified and the risks are resolved using the best possible strategy. At the end of this quadrant, the Prototype is built for the best possible solution. 3. Develop next version of the Product: During the third quadrant, the identified features are developed and verified through testing. At the end of the third quadrant, the next version of the software is available. 4 Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far developed version of the software. In the end, planning for the next phase is started. 1.14.1 Risk Handling in Spiral Model A risk is any adverse situation that might affect the successful completion of a software project. The most important feature of the spiral model is handling these unknown risks after the project has started. Such risk resolutions are easier done by developing a prototype. The spiral model supports coping up with risks by providing the scope to! build ilda prototype at every phase of the software development. er to The Prototyping Model also supports sick bntlg the risks must be ¢ identified completely before the start of braces work of In each phase of the Spiral analyzed, and the risks at that point through prototyping. Thus, this mo other SDLC models.1.40 Software Engi tin, 1.14.2 Why Spiral Model is called Meta Model? N The Spiral model is called a Meta-Model because it subsumes all th actually represen, ‘al model incorporates the ‘ sical Waterfall Model. other SDLC models. For example, a single loop spiral the Iterative Waterfall Model. The spir S : Stepwig, approach of the Cl The spiral model uses the approach of the Prototyping Mode 5, building a prototype at the start of each phase as a risk-handling technigy, i nay evolutionary Also, the spiral model can be considered as supporting the Evolutio, model — the iterations along the spiral can be considered as levels through which the complete system is built. 1.14.3 Advantages of Spiral Model: > < Handling: The projects with many unknown risks that occy, as the development proceeds, in that case, Spiral Model is the beg development model to follow due to the risk analysis and Tisk handling at every phase. ~* Good for large projects: It is recommended to use the Spiral Model in large and complex projects. <> Flexi in Requirements: Change requests in the Requirements at later phase can be incorporated accurately by using this model, ~ Customer Satisfaction: Customer can see the development of the product at the early phase of the software development and thus, they habituated with the system by using it before completion of the total product. 1.14.4 Disadvantages of Spiral Model “ Complex: The Spiral Model is much more complex than other SDLC models. ‘ ++ Expensive: Spiral Model is not suitable for supall peniects as itis expensive. n tates .