SUBJECT CODE : 210953 As per Revised Syllabus of SAVITRIBAI PHULE PUNE UNIVERSITY Choice Based Credit System (CBCS) S.E. (Computer) Semester - IV SOFTWARE ENGINEERING Anuradha A. Puntambekar ME. (Computer) rmerly Assistant Professor in RE.S. Modem College of Dr. Jayashree R. Prasad Ph.D. (Computer Engin: ME ing) Professor Computer Engineering) Sinhgad College of Engineering, Pune ing) puter Eng =" TECHNICAL PUBLICATIONS An Up-Thrust for Knowledge oSOFTWARE ENGINEERING Subject Code : 210253 S.E. (Computer) Semester - IV © Copyright with A. A. Puntambekar technicalpublications.org Website : www technicalpublicotions.org inter aj Printer & Binder: 101A Industial Estate, Nanded Vilage Road, Tol. Haveli, Dist. - Pune - 411041 ISBN 978-93-90450-41-1 ol7§9390 llPREFACE The importance of Software Engineering is well known in various engineering fields. Overwhelming response to our books on various subjects inspired us to write this book. The book is structured to cover the key aspects of the subject Software Engineering The book uses plain, lucid language to explain fundamentals of this subject. The book provides logical method of explaining various complicated concepts and stepwise methods to explain the important topi practical examples and solved problems. All chapters in this book are arranged in a proper sequence that permits each topic to build upon earlier studies. All care has been taken to make students comfortable in understanding the basic concepts of this subject. 's. Each chapter is well supported with necessary illustrations Representative questions have been added at the end of each section to help the students in picking important points from that section The book not only covers the entire scope of the subject but explains the philosophy of the subject. This makes the understanding of this subject more clear and makes it more interesting. The book w teachers. The students have to omit nothing and possibly have to cover nothing more. il be very useful not only to the students but also to the subject We wish to express our profound thanks to all those who helped in making this book a Much needed moral support and encouragement is provided on numerous occasions by our whole family. We wish to thank the Publisher and the entire team of Technical Publications who have taken immense pain to get this book in time with quality printing, reali Any suggestion for the improvement of the book will be acknowledged and well appreciated, Authors A.A. Puntambekar De. ayashree R. Prasad Dedicated to GodSYLLABUS Software Engineering - 210253 Credit Scheme Examination Scheme and Marks 03 Mid _Semester (TH) : 30 Marks End _ Semester (TH) : 70 Marks Unit I Introduction to Software Engineering and Software Process Models Software Engineering Fundamentals : Introduction to software engineering, The Nature of Software, Defining Software, Software Engineering Practice. Software Process : A Generic Process Model, defining a Framework Activity, Identifying a Task Set, Process Patterns, Process Assessment and Improvement, Prescriptive Process Models, The Waterfall Model, Incremental Process Models, Evolutionary Process Models, Concurrent Models, A Final Word on Evolutionary Processes. Unified Process, Agile software development: Agile methods, plan driven and agile development. (Chapter 1) Unit I Software Requirements Engineering and Analysis Modeling : Requirements Engineering, Establishing the Groundwork, Identifying Stakeholders, Recognizing Multiple Viewpoin working toward Collaboration, Asking the First Questions, Eliciting Requirements, Collaborative Requirements Gathering, Usage Scenarios, Elicitation Work Products, Developing Use Cases, Building the Requirements Model, Elements of the Requirements Model, Negotiating Requirements. Validating Requirements. Suggested Free Open Source tools : StarUML, Modelio, SmartDraw. (Chapter 2) Unit I Estimation and Scheduling Estimation for Software Projects : The Project Planning Process, Defining Software Scope and Checking Feasibility. Resources management, Reusable Software Resources. Environmental Resources, Software Project Estimation, Decomposition Techniques, Software Sizing, Problem-Based Estimation, LOC-Based Estimation, FP-Based Estimation, -Bas Object Point (OP)-based estimation, Proce: .d Estimation, Estimation with Use C Use- Case - Based Estimation, Reconciling Estimates, Empirical Estimation Models, The ©)Structure of Estimation Models, The COCOMO II Mode, Preparing Requirement Traceability Matrix Project Scheduling : Project Scheduling. Defining a Task for the Software Project, s heduling. Suggested Free Open Source Tools : Gantt Project, Agantty, Project Libre. (Chapter 3) Unit IV Design Engineering Design Concepts : Design ithin the Context of Software Engineering, The Design Process, Software Quality Guidelines and Attributes, Design Concepts - Abstraction, Architecture, design Patterns, Separation of Concerns, Modularity, Information Hiding, Functional Independence, Refinement, Aspects, Refactoring. Object-Oriented Design Concept, Design Classes. The Design Model , Data Design Elements, Architectural Design Elements, Interface Design Elements, Component-Level Design Elements, Component Level Design for Web Apps. Content Design at the Component Level, Functional Design at the Component Level, Deployment-Level Design Elements. Architectural Design : Software Architecture, What is Architecture, Why is Architecture Important, Architectural Styles, A brief Taxonomy of -chitectural ryles, Suggested Free Open Source Tool art Draw (Chapter 4) Unit V Risks and Configuration Management Risk Management : Software Risks, Risk Identification, Risk Projection, Risk Refinement. Risk Mitigation, Monitoring. and Management. The RMMM Plan. Software Configuration Management : Software Configuration Management, The SCM Repository The SCM Process, Configuration Management for any uitable software system. Suggested Free Open Source Tools : CF Engine Configurati n Tool, Puppet Configuration Tool, (Chapter 5) Unit VI Software Testing A Strategic Approach to Software Testing, Verification and Validation, Organizing for Software Testing, Software Testing Strategy - The Big Picture, Criteria for Completion of Testing, Strategic Issues, Te: Strategies for Conventional Software, Unit Tesing, Integration Testing, Test Strategies for Object-Oriented Software, Unit Testing in the OO Context. Integration Testing in the OO Context, Test Strategies for WebApps, Validation Testing, Validation -Test Criteria, Configuration Review. Suggested Free Open Source Tools lenium, JUnit. (Chapter 6) oTABLE OF CONTENTS Chapter-1 Introduction to Software Engineering 11 1.2 13 14 15 1.6 17 18 19 1.10 1.11 1.12 1.13 1.14 1.15 1.16 and Process Models (1 - 1) to (1 - 48) Part I: SOFTWARE ENGINEERING FUNDAMENTALS Introduction to Software Engineering ... The Nature of Software..... Defining Software. Software Engineering Practice ..ccusnnnsntnnennnnesnannesnesne = 3 Software Characteristics... Software Engineering Myths. eset 1-6 PART II : SOFTWARE PROCESS Generic Process Model... 1-7 1.7.1 Layered Technology Defining Framework Activity... Identifying a Task Set. Process Pattern .... Process Assessment and Improvement .. Prescriptive Process Model... 1.12.1 Need for Process Model ....... The Waterfall Model... Increment Process Model... 1.14.1 Incremental Model 1.14.2 RAD Model Evolutionary Process Model. 1.15.1 Prototyping .. 1.15.2 Spiral Model Comparison between Various Process Model: wi)1.17 Concurrent Models 1.18 Unified Process..... 1.19 Agile Software Development .. 1.20 Agile Methods 1.21 Plan Driven and Agile Development... 1.22 Multiple Choice Questions with Answers... 1.19.1 Agility Principles. 1.19.2 Concept of Agile Process.... 1.19.3 Software Evolution and Merits and Demerits of Agile Methods 1-34 1.20.1 Adaptive Software Development (ASD). 1-35 1.20.2. Dynamic System Development Method (DSDM) 1-36 1.20.3 Serum 1.20.4 Feature Driven Development (FDD) 1.20.5 Crystal esses 1.20.6 Agile Modeling (AM)... Chapter-2 Software Requirement Engineering and 21 2.2 23 Analysis Modeling (2 - 1) to (2 - 82) Requirements Engineering... 2-2 2.1.1 Need for Requirements to be Stable and Correct 0. 2-2 Requirements Engineering Tasks. 2-3 2.2.1 Inception 2-4 2.2.2. Elicitation 2-4 2.2.3 Elaboration.. wD -5 2.2.4 Negotiation. w2-5 2.2.5 Specification we 2-5 2.2.6 Validation. 12-6 2.2.7 Requirement Management 2-6 Establishing the Groundwork... 2-7 2.3.1. Identifying the Stakeholders. 2-7 2.3.2. Recognizing Multiple Viewpoints... 22-8 (vil)2.4 25 2.6 27 28 2.9 2.10 2.11 2.3.3 Working Towards Collaboration 2-9 2.3.4 Asking the First Questions 2-9 Eliciting the Requirements...... 2-10 2.4.1 Collaborative Requirements Gathering 2-10 2.4.2. Quality Function Development. 2-12 2.4.3 Usage Scenario. 2-13 2.4.4. Elicitation Work Products..... w2-13 Developing Use Cases........ 2-14 Building Requirements Models... 2-17 2.6.1 Overall Objectives... w2-18 2.6.2 Analysis Rules of Thumb 2-19 2.6.3. Domain Analysis. 2-19 Elements of the Requirements Model.. 2-20 Scenario Based Modeling... 2-20 2.8.1 Writing Use Cases... 2-21 2.82. Activity Diagram..... 2-26 2.8.3. Swimlane Diagram... wed -27 Class Based Modeling...» 2-29 2.9.1 Objects and Object Classes... . 2-29 2.9.2. Generalization and Inheritance Relationship 2-30 2.9.2.1 Association Relationship 2-33 2.9.3 Object Identification wa. se .2-35 2.9.4 Class-Responsibility-Collaborator(CRC) Modelling 2-37 2.9.5 Object Relationship Model 2-40 Data Modeling... 2-42 2.10.1 Data Object, Attributes and Relationships «0.0.00 v2 43 2.10.2 Cardinality and Modality... ond AG 2.10.3 Entity Relationship Diagram ..... sessesessieniessennees2 AS 2.10.31 Design Guideline and Examples .n.vnenennnnne sess = 47 Flow Modeling... 2-50 2.1L. Data Flow Diagramme esse sensssnenees2 = 50 iil)21.1.1 Designing Data Flow Diagrams 2-51 2.11.2 Control Flow Diagram 2-54 2.1.2.1 Designing Control Flow Diagrams 2-55 2.11.3 Examples... 2-56 2.12 Behavioral Modeling... - 2-73 2.12.1 Identifying Events with Use Cases 2-73 2.12.2 State Representation 2-73 2.12.3 Sequence Diagram 2-74 2.13 Negotiating the Requirements...... 12-76 2.14 Validating Requirements... .2-76 2.15 Preparing Requirements Traceability Matrix. 2-7 2.16 Multiple Choice Questions with Answers 2-78 Unit - II Chapter-3 Estimation and Scheduling (8 - 1) to (3 - 28) 3.1. The Project Planning Process 3.2 Defining Software Scope and Checking Feasibility 3.3. Resource Management... 3.3.1 Human Resources. seen . 3-4 3.3.2 Reusable Software Resources.. 3.3.3. Environmental Resources 3.4 Software Project Estimation ... 3.5 Decomposition Techniques... 3.5.1 Software Sizing. 3.5.2 Problem Based Estimation... 3.5.3. Example of LOC Based Estimation 3-8 3.5.4 Example of FP Based Estimation..... 3.5.5 Process Based Estimation 3.5.6 Example of Process Based Estimation sonnsinnisetinseinnnnsniene “LL 3.5.7 Estimation with Use Case ..... 3.5.8 Reconciling Estimation... 3.6 Empirical Estimation Model... (ix)3.6.1 The Structure of Estimation Model 3-14 3.6.2. The COCOMO II Model 3-15 3.7 Object Point(OP) Based Estimation... 3-19 3.8 Project Scheduling...... 3-19 3.9 Defining a Task Set for the Software Project...... 3-21 3.10 Task Network. 3-22 3.11 Scheduling with Time Line Chart. 3-23 3.12 Schedule Tracking Tools.. 3-24 3.12.1 Microsoft Project 3-24 3.12.2 Daily Activity Reporting & Tracking (DART) 3-25 3.13 Multiple Choice Questions with Answers 3-25 Unit - IV Chapter-4 Design Engineering (4- 1) to (4-36) ParT I; INTRODUCTION TO DESIGN CONCEPTS 4.1 Concept of Design ...csssessssssessensese 14-2 4.1.1 Design within the Context of Software Engineering. aoeeeeee 2 4.2. The Design Process. 4-3 4.3 Software Quality Guidelines and Attributes . 4-4 4.4. Design Concepts... 4-5 4.4.1 Abstraction 4-6 4.4.2 Modularity ... A -6 4.4.3. Architecture 4.4.4 Refinement ....0s 4.4.5. Pattern... 4.4.6 Information Hiding... 4.4.7 Functional Independence... 4.4.7.4 Cohesion 44.72 Coupling 44.8 Refactoring.............. 4.5 Object Oriented Design Concepts... 4.6 Design Classes .. co)4.7 The Design Model and Elements. sseeseneensissenenensinsn ses 4- 4.7.1. Data Design Elements wo 4.7.2 Architectural Design Elements. 4- 4.73. Interface Design Elements... wo 4.7.4 Component Level Design Elements 4- 4.7.5 Deployment Level Design Elements wo 4.8 Component Level Design........ 4- 4.9 Class Based Design... .4- 4.9.1 Basic Design Principle 4- 4.9.2 Component Level Design Guideline. 4° 4.93 Cohesion 4. 4.9.4 Coupling... se 4- 4.10 Conducting Component Level Design ......... in 4- 4.11 Component Level Design for Web Apps 4- 4.11.1 Content Design at the Component Level. 4- 4.11.2 Functional Design at the Component Level 4. Part II: ARCHITECTURAL DESIGN 4.12 Software Architecture... 4- 4.12.1 What is Architecture ? wu. 4 4.12.2 Why is Architecture Important ? 4. 4.12.3 Structural Partitioning... Ae 4.12.4 Difference between Horizontal and Vertical Partition ..n.osensceneneenenel = 4.13 Architectural Styles .... Ae 4.13.1 Architectural Styles... 4° 4.13.1.1 Data Centered Architectures 4 4.13.12 Data Flow Architectures 4 4.13.13 Call and Return Architecture 4 4.13.14 Object Oriented Architecture... 4 4.13.15 Layered Architecture... en a) 4.13.2 Architectural Patterns. ses ade 4.14 Multiple Choice Questions with Answers .........- 4- 7 18 19 19 19 20 20 21 21 22 22 23 23 24 24 24 25 25 25 25 27 27 27 28 28 29 30 31 31 32 (xi)Chapter -5 Risk and Configuration Management (5 - 1) to (5 - 28) PaRT I: RISK MANAGEMENT 5.1 Introduction to Concept of Risk management... 5-2 5.2 Reactive Vs. Proactive Risk Strategies........ 5-2 5.3 Software Risks... 5.4 Risk Identification... 5.4.1 Risk Components and Drivers.. 5.4.2 How to Asses Overall Project Risk ? 5-6 5.5 Risk Projection.. 5.5.1 Building Risk Table 5-8 5.5.2. Assessing Risk Impact 5-9 5.6 Risk Refinement ... 5.7 _ Risk Mitigation, Monitoring and Management... 5.8 The RMMMPlan... Part II: SOFTWARE CONFIGURATION MANAGEMENT 5.9 Concept of Software Configuration Management... 5-14 5.9.1 Goals in Change Management...» . 5-14 5.9.2 Elements of Configuration Management System, 5-15 5.9.3 Baselines 5-15 5.9.4 Software Configuration Items. 5-16 5.10 The SCM Repository 5-17 5.10.1 Role of Project Repository... 5-17 5.10.2 Features... ssn sestnnntnstanesa 5-18 5.11 The SCM Process... 5-18 5.11.1 Identification of Objects in Software Configuration wu 5- 19) 5.11.2 Change Control 5-20 5.11.3 Version Control 5-21 5.11.4 Configuration Audit... 5-22 5.115 Status Reporting....... 5-23 5.12 Configuration Management for Any Suitable Software System... ..5-23 ail)5.12.1 Dominant Issues. 5-23 5.12.2 Content Management. 5-24 5.12.3 Change Management 5-25 5.12.4 Version Control 5-26 5.12.5 Auditing and Reporting... 25-26 5.13 Multiple Choice Questions with Answers 5-26 Lita ed Chapter-6 Software Testing (6 - 1) to (6 - 40) 6-2 6.1 Fundamental Concepts of Testing .... 6.1.1 Testing Objectives 6-2 6.1.2. Testing Principles 6-2 6.1.3 Why Testing is Important ?... 6-2 6.2 A Strategic Approach to Software Testing..... 6-3 6.2.1 Verification and Validation 6-4 6.3 Organizing for Software Testing... 6-6 6.4 Criteria for Completion of Testing .. 6-6 6.5 Strategic Issues. 6-7 6.6. Testing Strategies for Conventional Software sssesssensesee 6-8 6.6.1 Unit Testing.. ese 6-9 6.6.1.1 Errors Identified during Unit Testing 6-10 6.6.1.2 Driver and Stub. 6-11 6.6.2 Integration Testing. 6-11 6.6.2.1 Top Down Integration Testing 6-13 6.6.2.2 Bottom Up Integration Testing sesinnnnnnee® 1B 6.6.2.3 Regression Testing...» snnnnnnesnnnnnnsnnnnene6* Mh 6.6.24 Smoke Testing 6-15 6.6.3 System Testing.......... .6-15 6.6.3.1 Recovery Testing 6-16 6.6.32 Security Testing 6-16 6.6.3.3 Stress Testing. 6-16 (ai)6.6.3.4 Performance Testing 6.7 Testing Strategies for Object Oriented Software... 6.7.1. Unit Testing in OO Context 6.7.2. Integration Testing in OO Context 6.7.3 Difference between OO Testing Strategy and Conventional Testing Strategy 6-19 6.8 Test Strategies for Web Apps... 6-19 6.9 Validation Testing... 6-20 6.9.1 Acceptance Testing. 6-20 6.9.2. Validation Test Criteria 6-21 6.9.3 Configuration Review. 6-22 6.10 Types of Testing ... 6-22 6.11 White Box Testing 6-22 6.11.1 Basis Path Testing..... 6-22 6.1.1.1 Flow Graph Notation sree seosnnnisB 22 6.11.12 Graph Matrices. 6-27 6.11.2 Control Structure Testing 6-28 6.11.21 Condition Testing. 6-29 6.1.2.2 Loop Testing 6-29 6.12 Black Box Testing.. 6-31 6.12.1 Equivalence Partitioning 6-32 6.12.2 Boundary Value Analysis (BVA). 6-33 6.12.3 Graph based Testing eee seanenmnnneneanenminnes® 34 6.12.4 Orthogonal Array Testing... a sence 6 = 34 6.13 Comparison between Black Box and White Box Testing... 6 - 36 6.14 Multiple Choice Questions with Answers ..... Solved Model Question Papers M-1toM-4 (xiv)UNIT -I Introduction to Software Engineering and Process Models Syllabus Software Engineering Fundamentals : Introduction to software e1 Software, Defining Software, Software Engineering Practice Software Process : A Generic Process Model, defining a Framework Activity, Identifying a Task Set, Process Patterns, Process Assessment and Improvement, Prescriptive Process Models, The Waterfall Model, Incremental Process Models, Evolutionary Process Models, Concurrent Models, A Final Word on Evolutionary Processes. Unified Process, Agi sare development: Agile methods, plan driven and agile development. igineering, The Nature of le soft Contents 1.1 Introduction to Software Engineering 1.2 The Nature of Software 1.3 Defining Software 1.4 Software Engineering Practice 1.5 Software Characteristics May-11,14,19, Aug.-17, Oct.-18, Dec.-16, Marks 10 1.6 Software Engineering Myths April-16, Aug. 17, Dec.-17, 18, 19, veces OCCAAD varnesterenn Marks 5 1.7 Generic Process Model. Dec.-19, May-13 Marks 7 1.8 Defining Framework Activity. May-16 Marks 7 1.9 Identifying a Task Set. ceeuennn DOC, April-15, 16, Aug.-17 -May-18, 061-19... - Marks 8 1.10 Process Pattern 1.11 Process Assessment and Improvement 1.12 Prescriptive Process Model 1.13 The Waterfall Model April-16, Dec.-18, Oct-19 Marks 6 1.14 _ Increment Process Model May-18, May-19, Dec.-19 Marks 6 1.15 Evolutionary Process Model 1.16 Comparison between Various Process Models ..... May-11,12,13,14, Dec.-12,13 Marks 8 1.17 Concurrent Models 1.18 Unified Process 1.19 Agile Software Development... AUg.-17, Dec.-17, 18, Oct-19, May-19... Marks 5 7.20 Agile Methods 1.21 Plan Driven and Agile Development 1.22 Multiple Choice Questions a1)Software Engineering 1-2 Introduction to Software Engineering and Process Models Part I: Software Engineering Fundamentals Introduction to Software Engineering “Software engineering is a discipline in which theories, methods and tools are applied to develop professional software product.” In software engineering the systematic and organized approach is adopted. Based on the nature of the problem and development constraints various tools and techniques are applied in order to develop quality software The definition of sofiware engineering is based on two terms : © Discipline : For finding the solution to the problem an Engineer applies appropriate theories, methods and tools. While finding the solutions, Engineers must think of the organizational and financial constraints. Within these constraints only, he/she has to find the solution © Product : The software product gets developed after following systematic theories, methods and tools along with the appropriate management activities. The Nature of Software Sofiware can be applied in a s (algorithm) exists. Based on a complex g categories. ituation for which a predefined set of procedural steps owth of software it can be classified into following © System software : It is collection of programs written to service other programs. Typical programs in this category are compiler, editors ystem and assemblers, The purpose of the software is to establish a communication with the hardware. © Application software : It consists of standalone programs that are developed for specific business need. This software may be supported by database systems. © Engincering/scientific software : This software category has a wide range of programs huttle orbital from astronomy to volcanology, from automative stress analysis to spa dynamics and from molecular biology to automated manufacturing. This software is based o on complex numeric computations. © Embedded software : This category consists of program that can reside within a product id functions for or system. Such software can be used to implement and control feature the end-user and for the system itself. © Web applications : Web application software consists of various web pages that can be retrieved by a browser. The web pages can be developed using programming languages like JAVA, PERL, CGI, HTML, DHTML. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-3 Introduction to Software Engineering and Process Models © Artificial intelligence software : This kind of software is based on knowledge based expert systems, Typically, this software is useful in robotics, expert systems, image and voice recognition, artificial neural networks, theorem proving and game playing. Defining Software Software is nothing but a collection of computer programs and related documents that are intended to provide desired features, functionalities and better performan: Software products may be 1, Generic : That means developed to be sold to a range of different customers. 2. Custom : That means developed for a single customer according to their specification. Software Engineering Practice Following are some principles that focus on software engi principles that are suggested by David Hooker ering practice. These are the 1. Reason for 2. Keep It Simple Stupid(KISS) : Software design must be simple to implement and the resultant software system must be more maintainable and less error-prone. 3. V 4. The produce is getting consumed : While developing the software system, the documentation must be maintained so that the maintenances of the system becomes easy. The intention of software system s to provide value to its users ion : The goal and objective of the software must be defined. Be Open to future : If some cha must be accommodated easily. 2 s need to be incorporated in the system, then those 6. Plan for Reuse : The software system components can be made reusable so that the time and efforts can be saved. The programming techniques like Object oriented programming can be used for it 7. Think : Before performing every software engineering activity think and understand it. Software Characteristics Software development is a logical activity and therefore it is important to understand b characteristi cs of software. Some important characteristics of software are * Software is engineered, not manufactured 1) Software development and hardware development are two different activities. 2) A good design is a backbone for both the activities. 3) Quality problems that occur in hardware manufacturing phase can not be removed easily. On the other hand, during software development process such problems can be rectified. 4) In both the activities developers are responsible for producing quali TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-4 Introduction to Software Engineering and Process Models © Software does not ware out 1)_In early stage of hardware development process the failure rate is very high because of manufacturing defects. But after correcting such defects the failure rate gets reduced 's constant for some period of time and again it starts increasir 2) The failure rate rem because of environmental maladies (extreme temperature, dusts, and vibrations). om such environmental maladies. Hence 3) On the other hand software does not get affected ed curve". But due to some undiscovered errors the ideally it should have an “idealiz failure rate is high and drops down as soon as the errors get corrected. Hence in failure rating of software the “actual curve” is as shown below Fale cues ean tub cures) Sar ater To ofchanges = Manufacturing ‘tects Fare Fare Taenized AC coratnt fare pare Tine Fig. 1.5.1 Failure curves for hardware and software troduced. This 4) During the life of software if any change is made, some defects may ge causes failure rate to be high 5) Before the curve can retum to original steady state another change is requested and again the failure rate becomes high. 6) Thus the failure curve looks like a spike. Thus frequent changes in software cause it to deteriorate. 7) Another issue with software is that there are no spare parts for software. If hardware component wears out it can be replaced by another component but it is not possible in case of software. 8) Therefore software maintenance is more difficult than the hardware maintenance. * Most software is custom built rather than being assembled from components design with desired functioning 1) Whi properties is registers are assembled according to the design, but this is not done while developing e developing any hardware product firstly the circui ated, Then required hardware components such as ICs, capacitors and software product. 2) Most of the software is custom built TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-5 Introduction to Software Engineering and Process Models 3) However, now the software development approach is getting cl reusability of software components anged and we look for 4) It is practiced to reuse algorithms and data structures, 5) Today software industry is trying to make library of reusable components. For example : In today’s software, GUI is built using the reusable components such as message windows, pull down menus and many more such components. 6) The approach is getting developed to use in-built components in the software. This stream of software is popularly known as component engineering, Difference between Hardware Engineering and Software Engineering Sr. No. 1 Hardware Engineering Hardware products are manufactured. The quality problems that occur in hardware manufacturing. pha be removed easily. © can not In early stage of hardware development process, the failure rate is very high because of manufacturing defects, But after correcting such defects the failure rate gets reduced. The failure rate remains constant for some period of time and again it starts increasing because of environmental maladies. There are spare parts available for the hardware components, The hardware unit is assembled from components, Software Engincering Software is engineered and not manufactured, During software development process, various problems ean be identified and rectified. On the other hand, software does not get affected from the environmental maladies. But due to some undiscovered errors the failure rate is high and drops down as soon as the errors get corrected There are no spare parts for software components to replace. Most software is custom built rather than being assembled from components, Define software engineering. What are the software characteristics ? What are the various categories of software ? SU sr ee) Define software engineering. How software engineering is different from hardware engineering ? Justify, Ses) What is software engineering ? What are the characteristics of software ? SPPU : Dec.-16, End Sem, Marks 5 Define terms ‘Software’ and ‘Software engineering’. “Software does not wear out” State whether this statement is true or false. Justify your answer SPPU : Aug-17, Oct.-18, In Sem, Marks 3, May -19, End Sem, Marks 6 TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-6 Introduction to Software Engineering and Process Models Software Engineering Myths There are some misbelieves in the software industry about the softwa nd process of building software. For any software developer it is a must to know such beliefs and reality about them. Here are some typical myths - andards © Myth : Using a collection of s and procedures one can build software. (Management Myth) © Reality : Even though we have all standards and procedures with us for helping the onals to build desired developer to build software, it is not possible for software profe t should product. This is because - the collection which we have should be complet. reflect modern techniques and more importantly it should be adaptable. It should also help the software professional to bring quality in the product. © Myth : Add more people to meet deadline of the project. (Management Myth) Reality : Adding more people in order to catch the schedule will cause the reverse effect on the software project i.e. software project will get delayed. Because, we have to spend more time on educating people or informing them about the project. © Myth : Ifa project is outsourced to a third pa ty then all the worries of software building are over. (Management Myth) * Reality : When a company needs to outsource the project then it simply indicates that the company does not know how to manage the projects. Sometimes, the outsourced projects require proper support for development © Myth : Even if the software requirements are changing continuously it is possible to accommodate these changes in the software. (Customer Myth) © Res ty + It is true that software is a flexible entity but if continuous changes in the requirements have to be incorporated then there are chances of introducing more and more errors in the software. Similarly, the additional resources and more design modifications may be demanded by the software. © Myth : We can start writing the program by using genei ‘al problem statements only. Later ing problem description we can add up the required functionalities in the program. (Customer Myth) on us © Reality : It is not possible each time to have comprehensive problem statement. We have to start with general problem statements; however by proper communication with customer the software professionals can gather useful information, The most important thing is that the problem statement should be unambiguous to begin with. ©) Myth : Once the program is running then its over! (Practitioner's Myth) TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-7 Introduction to Software Engineering and Process Models © Reality : Even though we obtain that the program is running major part of work is after delivering it to customer. © Myth : Working program is the only work product for the software project. (Practitioner's Myth) © Reality : The working program/software is the major component of any software project but along with it there are many other elements that should be pr project such as documentation of software, guideline fo ent in the software software support. © Myth : There is no need of documenting the software project; it unnecessarily slows down the development process. (Practitioner's Myth) Reality : Documenting the software project helps in establishing ease in use of software, It helps in creating better quality and maintaining the software system, Hence documentation is not wastage of time but it is a must for Review Questions 1. What are customer myths ? Discuss the realty of these myths, ny software project SUPT STares 2. What are the practitioner's myths ? Discuss the reality of these myths. 3. PartII: Software Process Generic Process Model Software process can be defined as the structured set of activities that are required to develop the software system. The fundamental activities © Specific ion © Design and implementation © Validation © Evolution A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. 1.7.1. Layered Technology Bag * Software engineering is a layered technology. Any softwa can be developed using these layered approaches. Various layers on which the technology is based are quality management layer, process layer, methods layer, tools layer. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-8 Introduction to Software Engineering and Process Models Automatic Sapper satware Provice echnical etal ‘arcotware Foundation Drsotiere eackbone ofeotiare 1 Software engineering : A layered approach * A disciplined quality management is a backbone of software engineer ig technology. © Process layer is a foundation of software engineering. Basically, process defines the framework for timely delivery of software. © In method layer the actual method of implementation i carried out with the help of requirement analysis, designing, coding using desired programming constructs and testing. Software tools are used to bring automation in software development process. Thus software en} ering is a combination of process, methods, and tools for development of q 2 Review Question 1. Elaborate how software engineering is a layered technology. eso ee Defining Framework Activity The process framework is required for representing the common process activities. As shown in Fig. 1.8.1, the software process is characterized by process framework activities, task sets and umbrella activities. Process framework activities © Communication © By communicating customer requirement gathering is done. © Planning - Establishes engineering work plan, describes technical risks, requirements, work products produced and defines work schedule. lists resource TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-9 Introduction to Software Engineering and Process Models © Modeling - The software model is prepared by © Analysis of requirements © Design © Construction - The software design is mapped into a code by © Code generation o Tes ing © Deployment - The software delivered for customer evaluation and feedback is obtained Software Process Process Framawork Action #1. aate | Wik Teak Milestone SOA Pain Action 1.0 Crasies [Work Task Milestone: SOA Poin Fig. 11 1 Software process framework Review Question 1. Whatare the various umbrella activities applied throughout a software project ? Sess Identifying a Task Set SPPU ; Dec.-11, April-15, 16, Aug.-17, May-18, Oct-19, Marks 8 Task sets : The task set defines the actual work done in order to achieve the software objective. The task set is used to adopt the framework activities and project team requirements usi © Collection of software engineering work tasks TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 41-10 Introduction to Software Engineering and Process Models © Project milestones © Software quality assurance points Umbrella activities The umbrella activities occur throughout the process. on project management, tracking and control. The umbrella activities are They focus 1. Software project tracki nd control : This is an activity in which sofiware team assess progress and take corrective action to maintain schedule. 2. Risk management : The risks that may affect project outcomes or quality can be analyzed. 3. Software quality assurance : These are activities required to mai ain software quality, 4. Formal tec ical reviews : It is required to assess en; g work products to uncover and remove errors before they propagate to next activity, 5. Software configuration management : Managing of configuration process when any change in the software oceur 6. Work product preparation and production : The activ ies to create models, documents, logs, forms and lists are carried out 7. Reusabi 8 M and product measu Y management : It defines criteria for work product reuse. surement : In this activity, the process can be defined and collected. Also projes re used to assist the software team in delivering the required software, 1. Explain the generic framework activities in a software engineering process and also mention the umbrella activities. Sse) 2. What are various umbrella activities applied throughout a software project ? Ss a ee ee ee es What is software process framework ? Explain in detail 4. What are the reasons to have a software process ? What are the issues addressed by umbrella activities in layered model of software engineering. What are the issues addressed by umbrella activities in layered model of software engineering, Sec rks 5 Process Pattern * Process is defined as a series of activities in which one or more inputs are used to produce one or more outputs. © The process pattern is a template which appears as a general solution to a common problem, TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-11 Introduction to Software Engineering and Process Models © Process pattern acts as a consistent method for describing an important characteristic of software proc * Using process pattern we can easily build the process that satisfies all the requirements. © Process pattern describes © Complete process © Important framework activity © Task within the framework activity © Scott Ambler - an object oriented consultant has proposed a template for process pattern as follows © Pattern name © Intent © Type © Initial context © Problem © Solution © Resulting context * Known uses The description of process patter is as follows - Pattern name The pattern name should be a meaningful name given to the pattem. From pattern name one can guess its functionality Intent The objective or the purpose of the pattern should be deseribed here. Type The type of pattern should be specified here. Ambler has suggested three types of patterns sk Pattern - It represents the software enginee process. For example, Formal Technical review is a task pattern. 2 action or work task which is a part of 2) Stage Pattern - It defines the process framework activity. A framework activity has multiple work tasks; hence stage pattern consists of multiple task pattems. For exampl: Coding phase is a stage pattern 3) Phase Patterns - It defines the sequence of framework activities, For example the phrase pattern can be spiral model or rapid prototype model. Initial context In this section the rribed. conditions under which the pattern applies are dk Sometimes the entry conditions must be true before the process begins TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 4-12 Introduction to Software Engineering and Process Models In this section following issues need to described 1. The set of organisational or team related activities that have already occurred. 2. The list of entry state processed. 3. Already existing software engineering or project related information. Problem Under this section the problem is mentioned for which the pattem is to be described. For example : insufficient requirements is a problem, That means customers are not sure about what they want exactly. They could not specify the requirements in proper manner. Solution Every problem for which pattern has to be deseribed should be accompanied with some solution. For example: The problem of insufficient requirements has solution, That is - Establish effective communication with the customer. Ask questions in order to obtain meaningful requirements. Conduct timely reviews to modify/redefine the requirements. This solution will help the software developer to get useful information before the actual work starts, Resulting context It describes the results after successful implementation of pattern, The resulting context should have following type of information on successful completion of pattem - 1. The team-related or organizational activities that must have occurred. Exit state for the proc s. ‘The software engineering information or project information that has been developed. Known uses/Examples The specific instances or applications in which the described pattem is usefull should be mentioned under this section, In other words we describe applicability of the pattern. For example : spiral model is useful for the large scale projects in which work products must be examined in several iterations. Process Assessment and Improvement Normally process is suffered by following problems - 1. The software has to be delivered on time. 2. The software should satisfy customer needs and requirements 3. The software should posses the long term quality characteristics. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 18 Introduction to Software Engineering and Process Models sonware process vA T \ Analyzed by By improving the { Capabilities and process changes risk of processes initcanbe made [ Software process] _can be identified assessmer Leads to Leads to — Software process heel improvement Capability determination Fig. 1.11.1 Software process assessment Process assessment is an activity in which it is ensured whether the software meets the basic criteria for successful software engineering project. Following approaches are used for software assessment - Standard CMMI assessment method for process improvement It is a five step process assessment model. These five steps are initiating, diagnosing, establishing. and learning. This model makes use of SEI CMM as the base model. CMM-based appraisal for internal process improvement This method provides the diagnostic technique for internal process assessment SPICE Using this standard all the requirements are analyzed for software process assessment. This standard helps in doing an objective evaluation on effi ISO 9001:2000 iency of any process. This is a popularly used standard for improving the overall quality of the organization. The International Organization for Standardization i.e. ISO has developed this standard. Prescriptive Process Model model can be defined as the abstract representation of process. The appropriate process model can be chosen based on abstract © Definition of Process Model : The proce: representation of process. © The software process model is Model or software paradigm. so known as Software Development Life Cycle (SDLC) © These models are called prescriptive process models because they are following some rules for correct usa © In this model various activities are carried out in some spec’ desired software product. sequence to make the TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-14 Introduction to Software Engineering and Process Models 1.12. Various prescriptive process models are as shown in Proscripive proves models remonial process modal Evoutonary process macel Incremental Prototyping mode! pap moder [Stil model | concurrent dovelopmmant model Fig. 1.12.1 Prescriptive process model 1.12.1 Need for Process Model The software development team must decide the process model that is to be used for software produ nd then the entire team must adhere to it. This is ne be development sary use the software product development can then be done systematically Each team member will understand - what is the next activity and how to do it, Thus process model will bring the definiteness and discipline in overall development process. sts of del Every process model cons fe entry and exit eriteria for each phase. Hence the transition of the product through various phases is definite. If the process model is not followed for software development then any team member can perform any software development activity, this will ultimately cause a chaos and software project will definitely fail without using process model, it is difficult to monitor the progress of software product. Thus process model plays an important rule in software engineering. The Waterfall Model The waterfall model is also called as 'linear-sequential model or ‘classic life cycle mode!’ It is the oldest software paradigm. This model suggests a systematic, sequential approach to software development. The software development starts with requirements gathering phase. Then progresses through analysis, design, coding, testing and maintenance, Following figure illustrates waterfall model TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-15 Introduction to Software Engineering and Process Models Requrement gathering and analysis Desicn - 1.13.1 Waterfall model © In requirement gathering and analysis phase the basic requirements of the system must be understood by software engineer, who is also called Analyst. The information domain, function, behavioural requirements of the system are understood. All these requirements re then well documented and discussed further with the customer, for reviewing, © The de nis an intermediate step between requirements analysis and coding ssign focuses on program attributes such as - © Data strueture © Software architectu © Interface representation © Algorithmic details The requirements are translated in some easy to represent form using which coding can be done effectively and efficiently. The design needs to be documented for further use. © Coding is a step in which design is translated into mac done e-readable form. If design is in suff ted in this jent detail then coding can be done effectively. Programs a1 e cr phase. © Testing begins when coding is done. While performing testing the major focus is on logical internals of the software. The testing ensures execution of all the paths, functional behaviours. The purpose of testing is to uncover errors, fix the bugs and meet the customer requirements. © Maintenance is the I ngest life cycle phase. When the system is installed and put in practical use then error may get introduced, correcting such errors and putting it in use is the major purpose of maintenance activity. Similarly, enhancing system's services as new requirements are discovered is again maintenance of the system. This model is widely used model, although it has many drawbacks. Let us discuss benefits and drawbacks. TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-16 Introduction to Software Engineering and Process Models Benefits of waterfall model 1. The waterfall model is simple to implement. 2. For implementation of small systems waterfall model is useful Drawbacks of waterfall model There are some problems that are encounter ed if we apply the waterfall model and those are 1. It is difficult to follow the sequential flow in software development process. If some changes are made at some phases then it may cause some confusion. 2. The requirement analysis is done initially and sometimes it is not possible to state all the requirements explicitly in the beginning, This causes difficulty in the project. 3. The customer can see the working model of the project only at the end. After reviewing of the working model; if the customer gets dissatisfied then it causes s ‘ous problems. 4, Linear nature of waterfall model induces blocking states, because certain tasks may be dependant on some previous tasks. Hence it is necessary to accomplish all the dependant tasks first, It may cause long waiting time, Emin Explain how systems fall model is applicable for the development of the follozwing a) University accounting system b) Interactive system that allows railway passengers to find time and other information from the terminals installed in the station. Solution : a) University accounting system : If the software developers who have the experience in developing the account systems then building university account system based on existing design could be easily managed with water-fall model. b) Interactive system that allows railway passengers to find time and other information from the terminals installed in the station. © For developing such interactive system, all the requirements must be correctly identified and analyzed before the designing of the project. © The requirements of end-users must be correctly and un-ambiguously understood by the developers prior to design pha © Once the requirements are well defined then using disciplined design, coding and testing phases the required system can be built u ing water-fall model. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 117 Introduction to Software Engineering and Process Models ORME What is meant by ‘blocking states’ in linear sequential model ? Solution : © The linear nature of linear sequential model brings a situation in the project that some project team members have to wait for other members of the team to complete the dependent tasks in lineal This situation is called “blocking state’ sequential model. © For example, after performing the requirement gathering process can be started. nd analysis step the design © Hence the team worl 1g on design stage has to wait for gathering of all the necessary requirements. Similarly the programmers can not start coding step unless and until the design of the project is completed. 1. Whatare the elements of waterfall model ? State its merits and demerits. SPPU : April-16, In Sem, Marks 6 2. Explain classic life cycle paradigm for software engineering and problems encountered when it is applied. Sees Cee ed 3. Why waterfall model of software engineering is not accurate reflection of software development activities? Justify. Sea ee ed Increment Process Model slid Pace ery DESC eee In this model, the initial model with limited functionality is created for user's understanding about the software product and then this model is refined and expanded in later releases. 1.14.1 Incremental Model © The incremental model has same phases that are in waterfall model. But it is iterative in nature. The incremental model has following phases, 1. Analysis 2. Design 3. Code 4. Test © The incremental model deliver series of releases to the customer. These releases are called increments. More and more functionality is sociated with each increment. © The first nerement is called core product implemented and then In this release the basic requirements are subsequent increments new requirements are added. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-18 Introduction to Software Engineering and Process Models * The word processing software package can be considered as an example of incremental model. In the rst increment only the document processing facilities are available. In the second increment, more sophisticated document producing and processing facilities, file management functionalities are given. In the next increment spelling and grammar checking facilities can be given. Thus in incremental model progressive functionalities are obtained with each release. When to choose it ? 1. When requirements are reasonably well-defined, When overall scope of the development efi rt suggests a purely linear eft 3. When limited set of software functionality needed quickly. Merits of incremental model 1. The incremental model can be adopted when there are less number of people involved in the project. 2. Technical risks can be managed with each increment. 3. Fora very small time span, atleast core product can be delivered to the customer. [aie]-+ [Donan ]-+ [Sate [om Increment wit ‘enhanced functionalities Tnrement i O-O-o-0 Trevament Crore Sofware function Tharemant aT |< increment with very Decor limited functionality Tine Fig. 1.14.1 The incremental model Demerits 1) System structure tends to degrade when new increment is getting added to the existing system. This actually spends time and mone: y on refactoring to improve the software 2) Itis not cost effective to produce document for every version of the system, hence many times the complete process is not getting documented. TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-19 Introduction to Software Engineering and Process Models 1.14.2 RAD Model * The RAD model is a type of incremental process model in which there is extremely short development cyele. © When the requirements are fully understood and the component based construction approach is adopted then the RAD model is used. © Using the RAD model the fully functional system can be developed within 60 to 90 days. * Various phases in RAD are Requirements Gathering, Analysis and Planning, Design, Build or Construction and finally Deployment. © Multiple teams work on developing the software system using RAD model parallely © In the requirements gathering phase the develope s communicate with the users of the tem and understand the bus ness process and requirements of the software system. © During analysis and planning phase, the analysis on the gathered requirements is made and a planning for various software development activities is done. Development process, Tear Design ean uid Requirements Design ‘nent = [+ — Ll oaen ona Analysis ‘and planning S5=s05) f+ 5010 90 days pers ——e| Fig. 1.14.2 Rapid application development © During the design phase vari data model and process model. us models are created. Those models are Business model, TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 20 Introduction to Software Engineering and Process Models © The build is an activity in which using the existing software components and automatic code generation tool the implementation code is created for the software system, This code is well tested by its team. The functionalities developed by all the teams are integrated to form a whole. © Finally the deployment of all the software components (created by various teams working on the project) is carried out. Drawbacks of rapid application development It requires multiple teams or large number of people to work on the scalable projects. This model requires heavily committed developer and customers. If commitment is lacking then RAD projects will fail The projects using RAD model requires heavy 80 ces. 4. If there is no appropriate modularization then RAD projects fail. Performance can be problem to such projects. The projects using RAD model find it difficult to adopt new technologies. ESORRERD Wich type of applications suit RAD model ? Justify your answer. Solution : The RAD model is suitable for information sy em applications, business applications and the for systems that can be modularized because of following reasons - This model is similar to waterfall model but it uses very short development cycle. 2. It uses component-based construction and emphasises reuse and code generation. 3. This model uses multiple teams on scaleable projects. 4. The RAD model is suitable for the projects where technical risks are not high. ‘The RAD model requires heavy resources. % Review Questions 1. Explain with neat diagram incremental model and state its advantages and disadvantages LSE ed 2. Whatare the conditions in which rapid application development model is preferred? May-19, End Sem, Marks 5 3. Explain RAD model with the help of diagram Evolutionary Process Model While developing the software systems, it is often needed to make modifications in earlier development phases or the tasks sets. If the development process is linear or in a straight line (from requirements gathering to deployment) then the end product will be unrealistic. In such cases, the iterative approach needs to be adopted. The evolutionary process model is iterative model. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-21 Introduction to Software Engineering and Process Models 1.15.1 Prototyping In prototyping model initially the requirement gathering is done. Developer and customer define overall objectives; identify areas needing more requirement gathering. Then a quick design is prepared. This design represents what will be visible to user in input and output format From the quick design a prototype is prepared, Customer or user evaluates the prototype in e the requirements. Iteratively prototype is tuned for satisfying customer order to rel requirements. Thus prototype is important to identify the software requirements. When working prototype is built, developer use existing program fragments or program generators to throw away the prototype and rebuild the system to high qualit Certain classes of mathematical algorithms, subset of command driven systems and other xamined without real time interaction can be applications where results can be easily developed using prototyping paradigm. Communication Builing of vain ‘quick customer design ee a Construction delivery Fi ee prototyoe. foodoack Fig. 1.15.1 Prototyping When to choose it ? Software applications that are relatively easy to prototype almost always involve Human- machine Interaction (HCI) the prototyping model is suggested. A general objective of software is defined but not detailed input, processing or output requirements, Then in such a case prototyping model is useful. When the developer is unsure of the efficiency of an algorithm or the adaptability of an operating system then prototype serves as a better cho ice. TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-22 Introduction to Software Engineering and Process Models Merits 1. The development team has adequate domain knowledg: 2. All the 3. There is use of reusable components, nd users are involved in all phases of development. Drawbacks of prototyping 1. In the first version itself, customer often wants “few fixes” rather than rebuilding of the sy The fit stem whereas rebuilding of new tem maintains high level of quality version may have some compromis 3. Sometimes developer may make implementation compromises to get prototype working quickly. Later on developer may become comfortable with compromises they are inappropriate. and forget why Comparison between prototyping and incremental process model Sr. No. Prototyping 1 Some requirements are gathered initially, but there may be change in when the requirements working prototype is shown to the customer. The development team has adequate domain knowledge. Similarly they can adopt the new technologies if product demands. 3 Alll the end-users are involved in all phases of development. 4. There can be use of some reusable software components in project development process 1.15.2 Spiral Model Incremental process model The requirements are precisely defined and there is no confusion about the final product of the software, The development team with less domain commodated due to iterative knowledge ean be a nature of this model. The change in technology in the later phase can not be tolerated. All the end-users need not be involved in all the phases of development. There is no use of reusable components in development process. © This model possess the iterative nature of prototyping model and controlled and systematic approaches of the linear sequential mode * This model gives efficient development of incremental versions of software. In this model, the software is developed in series of increments TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-23 Introduction to Software Engineering and Process Models The spiral model is divided into a number of framework activities. These framework activities are denoted by task regions. © Usually there are six tasks regions. The spiral model is as shown in Fig. 1.1 © Spiral model is realistic approach to development of large-se: je systems and software. Because customer and developer better understand the problem statement at each evolutionary level. Also risks can be identified or rectified at each such level. © In the initial pass, product specification is built and in subsequent passes around the spiral the prototype gets developed and then more improved versions of software gets developed. Planning Risk analysis Customer ‘cersmunicaion JEraTBing Project entry pin axis projec rmainteranea} Customer evaluation Construction ‘and feedack ‘and release Fig. 4.15.2 Spiral model © During planning phase, the cost and schedule of software can be planned and adjusted based on feedback obiained from customer evaluation. © Inspi | model, project entry point axis is defined. This axis represents starting point for different types of project: For instance, concept development project will start at core of spiral and will continue along the spiral path. If the concept has to be developed into actual project then at entry point 2 the product development process starts, Hen e entry point 2 is called product development project entry point. The development of the project can be carried out in iterations. TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-24 Introduction to Software Engineering and Process Models © The task regions can be described as : i) Customer communication : In this reg sted to establish customer ion, it is su; communication. ii) Planning : All planning activities are carried out in order to define resources time line and other project related activities. is : The tasks required to calculate technical and management risks are carried Risk analysi out. ntations of iv) ngineering : In this task region, tasks required to build one or more repr applications are carried out v) Construct and release : All the necess application are conducted. Some tas! carried out in this task region. ary tasks required to construct, test, install the s that are squired to provide user support are also al vi) Customer evaluation : Customer's feedback is obtained and based on customer evaluation required tasks are performed and implemented at installation stage. + Ineach region, number of work tasks are carried out depending upon the characteristics of project. For a small project relatively small number of work tasks are adopted but for a complex project large number of work tasks can be carried out © In spiral model, the software engineering team moves around the spiral in a clockwise direction beginning at the core, Advantages of spiral model © Requirement chang: © Ris Drawbacks of spiral model s can be made at every stage. s can be identified and rectified before they get problematic. © It is based on customer communication. If the communication is not proper then the software product that gets developed will not be up to the mark. © Itdemands considerable risk assessment. If the risk assessment is done properly then only the successful product can be obtained. When to choose it ? 1. When the prototypes for the software functionality are needed. When requirements are not very clearly defined or complex. When the large or high budget projects need to be developed. 4, When the risk assessment is very critical and essential When project is not expected within a specific limited time span. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 41-25 Introduction to Software Engineering and Process Models Comparison between Spiral mode! and Prototyping model Sr.No. Spiral model Prototyping model 1, The development team with less domain The development team has adequate knowledge can be accommodated due to domain knowledge. Similarly they can iterative nature of this model. The change in adopt the new technologies if product technology in the later phase can not be demands, tolerated 2, All the end-users need not be involved in all Alll the end-users are involved in all ph the phases of development of development 3. Funding are not stable for the projects that Funding are stable for these type of can be developed using spiral model projects. 4, The requirements that are gathered and Some requirements are gathered initially, analyzed are high reliability requirements. but there may be change in requirements when the working prototype is shown to the customer. PEEEERRERD 4s you move outward along with process flow path of the spiral model, zwhat can ‘we say about the software that is being developed or maintained ? Solution : When software engineering team moves around the spiral, the first circuit around the spiral results around the in development of product specification. The subsequent pass spiral might be used to develop prototype in more subsequent manner, In each pass, through planning region, some adjustments to project plan are made. Cost and schedule adjustments can also be made according to customer feedback. EERRESY How coes “Project Risk” factor affect the spiral model of software development ? Solution : The spiral model demands considerable risk assessment bet ause if a major risk is not uncovered and managed, problems will occur in the project and then it will not be acceptable by end user. ORREED How does a spiral model represent a proces: problens ? uitable to represent a real time Solution : Spi al model represents a process suitable to represent a real time problem because of followi reasons - 1. Software evolves as the project progresses. And at every evolutionary level the risks are identified and managed and risks are reduced at every stage. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-26 product. It helps in adopting the approach sy 3. The iterative frameworks help in analyzing ¢ 4. The spiral model demands a direct consider Introduction to Software Engineering and Process Models It enables the developer to apply the prototype approach at any stage in the evolution of the stematic stepwise development of the product. fhe product at every evolutionary stage. ation of technical risks at all stages of project. ‘The risks are reduced before they get problematic. Comparison between Various Process Models 1. Evolutionary and Incremental Process Model Sr.No. Evolutionary process model Incremental process model 1. Some requirements are gathered The requirements are precisely defined and there initially, but there may be change in is no confusion about the final product of the requirements when the working _ software. prototype is shown to the customer 2. The development team has adequate The development team with less domain domain knowledge. Similarly they can knowledge can be accommodated due to adopt the new technologies if product iterative nature of this model. The change in demands technology in the later phase cannot be tolerated, 3. All the end-users are involved in all All the end-users need not be involved in all the phases of development phases of development. 4. There can be use of some reusable There is no use of reusable components in software components in project development process 2. Waterfall Model and Spiral Model Sr. No. 1 Waterfall model It requires well understanding of requirements and —_ familiar technology. Difficult to accommodate changes after the process has started. 3. Can accommodate iteration but indirectly. 4. Risks can be identified at the end which may cause failure to the product, development process. Spiral model It is developed in iterations. Hence the requirements can be identified at new iterations, ‘The required changes can be made at every stage of new version. Itis iterative model. Risks can be identified and reduced before they get problematic TECHNICAL PUBLICATIONS® st for knowledgeSoftware Engineering 1-27 Introduction to Software Engineering and Process Models The customer can see the working model of the project only at the end. Afier reviewing of the working model; if the customer gets dissatisfied then it causes serious problems. Customers prefer this model This model is good for small systems Ithas sequential nature The customer can see the working product at certain stages of iterations. Developers prefer this model. This model is good for large systems. Ithas evolutionary nature. 3. Waterfall, Spiral, Prototype and Incremental Model Requirements be clearly understood Waterfall model Spiral model must The requirements analysis and gathering and defined at the can be done in beginning only. iterations because requirements get changed quite often. The development The development team having the team having — less adequate experience experience of working of working on the on the similar projects similar project is is allowed in this chosen to work on process model this type of process model There is no user There is no user development process. wolvement in all involvement in all the phases of phases of development process, Prototyping model Requirements analysis can be made in the later stages of the development cycle, because requirements get changed quite often The development team having less experience of working on the similar projects is allowed in this process model There is user involvement in all the phases of development process, Incremental model The requirements analysis can be made in the later stages of the development eyele The development team having the adequate experience of working on the similar project is chosen to work on this type of process model. There is user wolvement in all the phases of development process. TECHNICAL PUBLICATIONS®. An up trust for knowledgeSoftware Engineering 1-28 Introduction to Software Engineering and Process Models When the Due to iterative nature When developer is When the requirements requirements are of this model, the risk unsure about the are reasonably well reasonably well identification and efficieney of an _ defined, the development defined and the rectification is done algorithm or the effort suggests a purely development effort before they get. adaptability of an linear effort and when suggests a purely problematic. Hence for operating system then limited set of software linear effort then the handling real time the prototyping functionality is needed model is problems the spiral _ model is chosen. quickly then the model is chosen. incremental model is chosen, What is software process model ? Explain the incremental process model. Explain evolutionary process models mentioning the types of projects for which they are suitable Explain the waterfall model with its advantages and disadvantages. Explain the waterfall model with work products of each activity. Explain the prototyping model with its advantages and disadvantages. Give the need of different process models in software development. Se SsEm ees What do you mean by evolutionary process models ? Explain spiral model as an evolutionary process model. Eee en Concurrent Models © The concurrent development model is also called as concurrent engineering. © In this model, the framework activities or software development tasks are represented as states * The modeling or designing phase of software development can be in one of the states like under development, waiting for modification, under revision or under review and so on. Fig. 1.17.1 represents these states. (Refer Fig. 1.17.1) TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-29 Introduction to Software Engineering and Process Models een oo {er ] Tas ion ee i 1 f Bele] I mete Fig. 1.17.1 Concurrent development model © All the sofiware development activities exist concurrently in this model but these can be in various states. © These states make transitions. That is during modeling, the transition from under development state to waiting for modification state occurs. © This model basically defines the series of events due to which the transition from one state to another state occurs. This is called triggering. These series of events occur for every software development activity, action or task. © This model defines various activities that occur concurrently and a network of activities is defined. Advantages 1. All types of software development can be done using concurrent development model, curate picture of current state of proje 2. This model provides a 3. Each activity or task can be carried out concurrently. Hence this model is an efficient Unified Process ‘The unified process is a framework for object oriented models. This model is also called as Rational Unified Process model (RUP). It is proposed by Ivar Jacobson, Grady Bootch and James Rumbaugh. This model is iterative and incremental by nature. Let us discuss various phases of unified process. TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-30 Introduction to Software Engineering and Process Models There are 5 phases of unified process model and those are - © Inception © Elaboration * Construction © Transition © Production Let us understand each of these phases in detail. Inception © In this phase there are two major activities that are conducted : Communication and planning. © By having customer communication business requirements can be identified. © Then a rough architecture of the system is proposed. Using this rough architecture it then becomes easy to make a plan for the project. * Use eases are created which elaborates the user s el cenario. ing use cases the sequence of actions can be identified. © Thus use cases help to identify the cope of the project which ultimately proves to be the basis for the plan Planning CCommunicaton Modetra Elaboration * Elaboration can be done using two activities : Planning and Modelling. © In this phase the use cases are redefined. And an architectural representation is created ive models such as use-case model, analysis model, de: using ign model, implementation model and deployment model. TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-31 Introduction to Software Engineering and Process Models © Thus executable baseline gets created. © Then a plan is created carefully to check whether scope, risks and delivery dates are reasonable. Construction * The main activity in this phase is to make the use cases operational. © The analysis and design activities that are started in elaboration phase are completed in this h phase and a so e code is developed whi mplements all desired functionalit © Then unit test ng is conducted and acceptance testing is carried out on the use cases. Transition © In the transition phase all the activities that are required at the time of deployment of the software product are carried out. © Beta testing is conducted when software is delivered to the end user. © User feedback report is used to remove defects from the created system, © Finally software team prepares user manuals, installation guides and trouble shooting procedures. This makes the software more usable at the time of release. Production © This is the final phase of this model, In this phase mainly the maintenance activities are conducted in order to support the user in operational environment. © Various work products that may get generated in every phase are as given below - Inception phase Elaboration phase Construction phase Transition phase © Initial use case © Use case model © Design model © Delivered software model. © Requirements # Software increments «© Initial risk analysismodel components © Beta test report assessment, © Architecture model # Test plan © User feedback «© Project plan, © Preliminary design model Test cases report. Risk list © User manual @ Iterative project plan «Installation manual Preliminary user manual © Thus the generic sofiware process models are applied for many years in software development process in order to reduce chaos in the proc: of development. © Each of these models suggest different process flow but they insist on performing the same set of generic framework activities. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 41-32 Introduction to Software Engineering and Process Models Agile Software Development © In 1980's the heavy weight, plan based software development approach was used to develop any software product. © In this approach too many things are done which were not directly related to software product being produced. © This approach was rigid, That means if requirements get changed, then rework was essential. © Hence new methods were proposed in 1990’s which are known as agile process © The agile processes are the light-weight methods are people-based rather than plan-based methods. © The agile proce: design and documentation. s forces the development team to focus on software itself rather than is to deliver the © The agile process believes in iterative method. The aim of agile proces working model of software quickly to the customer. © For example : Extreme programming is the best known of agile process. Conventional Software Development Methodology , the cost of the cl * As the software project makes the progres anges increases non linearly. © Iris easy to accommodate changes during the requirement gathering stage. At this stage to accommodate the changes - usage scenarios are modified, list of functions can be extended, or written specification be edited. * As the progresses and if the customer suggest the changes during the testing phase of the ectural software development life cycle then to accommodate these changes the arch design needs to be modified and ultimately these chi nges will affect other phases of software development cycle. These changes are actu lly costly to execute Agile Methodology © The agile method proponents claim that if the software development is carried out using the agile approach then it will allow the software te m to accommodate changes late in a software project without dramatic cost and time impact © In other words, if the incremental delivery is combined with agile practices such as continuous unit testing and pair programming then the cost of changes can be controlled. © The following graph represents how the software development approach has a strong influence on the development cost. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-33 Introduction to Software Engineering and Process Models Cost of changes dus to conventional software process: oat oF henge: due 1 agile process Developement cast Tire Fig. 1.19.1 Influence of software development approach on agile process 1.19.1 Agility Principles There are famous 12 principles used as agility principles - 1. Satis 2. The ch: late in the software development process, the agile proc y the customer by early and continuous delivery of valuable softwa must be accommodated. Even though the ch should help to accommodate nges in the requirements them, Deliver working software quite often. Within the shorter time span deliver the working unit. 4, Business people and developers must work together throughput the project. Motivate the people who are building the projects. Provide the environment and support to the development team and trust them for the job to be done. 6. The working software is the primary measure of the progress of the software development. 7. The agile software development approach promote the constant pr ject development. The constant speed for the development of the product must be maintained. 8. To enhance the agility there should be continuous technical excellence. 9. The proper attention to be given to technical exeellence and good design 10. The simplicity must be maintained while developing the project using this approach. 11. The teams must be the self-organizing team for getting best architecture, requirements and design. At regular intervals the team thinks over the issue of becoming effective. After the careful review the team members adjusts their behavior accordingly. TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-34 Introduction to Software Engineering and Process Models 1.19.2 Concept of Agile Process Agile process is based on following assumptions about software projects 1. It is difficult to predict the software requirements in advance. Similarly the customer P 2. Itis difficult to predict how much design is necessary before the implementation. ‘ority often get changed. All the software development activities such as analysis, design, construction and testing are just difficult to predict. Characteristics of Agile process are - Agile processes must be adaptable to technical and environmental changes. That means if any technological changes occur, then the gile process must accommodate it, 2. The development of agile processes must be incremental. That means, in each development the increment should contain some functionality that can be tested and verified by customer. 3. The customer feedback must be used to create the next increment of the process. 4, The software increment must be delivered in short span of time. 5, It must be iterative, so that each increment can be evaluated regularly 1.19.3 Software Evolution and Merits and Demerits of Agile Methods Software evolution : Software evolution is a process of developing a software initially and repeatedly updating it for various reasons. Software change occurs because of following reasons. 1. New requirements emerge when the software is used 2. The bu: ness environment changes. 3. Errors needs to be repaired. 4, New equipment must be accommodated. 5. The performance or reliability may have to be improved. Agile process model Merits : 1) Customer satisfaction can be attained by rapid and continuous delivery of usefull software. 2) Customer, developer and tester inte with each other during software development process. 3) Continuous attention can be given for excellent technical design and software quality. 4) Even late changes in requirements can be accommodated TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 35. Introduction to Software Engineering and Process Models Demerits : 1) There is lack of emphasis on necessary designing and documentation during sofiware development process. 2) The proje: ‘3 Review Questions 1. Describe agile manifesto. 2. Whatis agility? Explain about process model. 3. Whats the importance of agile/XP methodology for project development? SRS Ce oe Cee eo ed easily get off the track if customer is not cl ments. ar about his requir Agile Methods There are various agile process models 1, Extreme Programming 2. Adaptive Software Development 3. Dynamic System Development Method 4, Scrum 5. Feature Driven Development 6. Agile Modeling Let us discuss them in detail, 1.20.1 Adaptive Software Development (ASD) © The adaptive software development approach was proposed by Jim Highsmith, This approach is useful in building the complex software systems using iterative approach © The focus of this method is on working in collaboration and team self organization. © The life cycle of ASD consists of three phases of software dev opment and those are - 1. Speculation 2. Collaboration 3. Learning. Fig. 1.20.1 Adaptive software development life cycle TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 36 Introduction to Software Engineering and Process Models In this 1, Speculation : This is an initial phase of the adaptive software development process phase the adaptive cycle planning is conducted. In this cycle planning mainly three types of information is used such as - Customer's mission statement, project constraints (delivery date, user description, budgets and so on) and basic requirements of the project 2. Collaboration : The motivated people work in collaboration to develop the desired software product. In this phase collaboration among the members of development team is a key factor. For successful collaboration and coordination it is necessary 10 have following qualities in every individual - Assist each other without resentment Work hard ° ° © Poses the required skill set. © Communicate problems and help each other to accomplish the given task ° Criticize without any hate ning : As the team members go on developing the components, the emphasize is on arning new skills and techniques. There are three ways by which the team members am s is obtained about the software © Focus groups : The feedback from the end-u component being developed. Thus direct feedback about the developed component can be obtained, © Formal technical review : This review for software components is conducted for better quality © Postmortems : The team analyses its own performance and makes appropriate improvements. 1.20.2 Dynamic System Development Method (DSDM) In this agile method, the project deadline is met using the incremental prototyping approach. This is an iterative development process. The Dynamic System Development Method (DSDM) consortium has defined an agile alled DSDM life eyele. Various phases in this life cycle model are as follows - process model 1. Feasibility study : By analyzing the business requirements and constraints the viability of the application is determined in this phase. 2. Business study : The functional and informational requirements are identified and then the business value of the application is determined. The basic application architecture is decided in this phase TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-37 Introduction to Software Engineering and Process Models Functional model iteration : The i \eremental approach is adopted for development. The basic functionalities are demonstrated to the customer by building the suitable increments. The intention of iterative cycle is to gather additional requirements by eliciting the requirements from the customer as each prototype is being developed. 4. Design and build iteration : Each prototype is revisited during the functional model iteration to ensure that the business requirements are satisfied by each software component Sometimes if possible, the design and build activities ean be carried out in parallel. 5. Implementation : In this phase, the software increment is placed in the working environment. If changes are suggested or if the end-user feels it incomplete then the increment is placed in iteration for further improvement The DSDM model ation ‘an be combined with XP method or ASD concepts to create a combi 1.20.3 Scrum © SCRUM is an agile process model wh th is used for developing the complex software systems. * Itis a lightweight process framework that can be used to manage and control the software development using iterative an the overhead of the process time. cremental approach. Here the term lightweight means kept as small as possible in order to maximize productive © This model is developed by Jeff Sutherland and Ken Schwaber in 1995. Principles © Various principles using which the SCRUM works are as given below - 1. There are small working teams on the software development projects. Due to this num overhead. there is maximum communication and mini The tasks of people must be partitioned into small and clean packets or partitions. 3. The process must accommodate the technical or business ehanges if they occur. 4. The process should produce software increments. These increments must be inspected, tested, documented and built on. During the product building the constant testing and documentation must be conducted. 6. The SCRUM process must produce the working model of the product whenever demanded or required. © Various development activities (requirements analysis, design, evolution and delivery) are guided by SCRUM principles. TECHNICAL PUBLICATIONS®. An up thrust for knowledgeSoftware Engineering 1-38 Introduction to Software Engineering and Process Models Development Activities defines a set of development activities. Refer Fig. 1.20.2. In SCRUM emphasize is on software process pattern, The software process pattern Simin dally ‘meeting 1. What a activites ? 2. Obslacies ? 24 Hour 3. Next meetin| plan? 30 Daye Sprint backlog increment Produet backlog va specie functionality ig. 1.20.2 SCRUM workflow activities Various development activities in SCRUM are - Backlog : It is basically a list of project requirements or features that must be provided to the customer. The items can be included in the backlog list at any time. The product list and updates the priorities as per the requirements. manager analyses this Sprint : These are the work units that are needed to achieve the requirements mentioned in the backlogs. Typically the sprints have fixed duration or time-box (typically of 2 to 4 weeks). Thus sprints allow the team members to work in stable and short-term environment. Meetings : These are 15 minutes daily meetings to report the completed activities, obstacles and plan for next activities. Following are three questions that are mainly discussed during the meetings i) What are the tasks done since last meeting ? ii) What are the issues (obstacles) that team is facing ? iii) What are the next activities that are planned ? Demo : During this phase, the software increment is delivered to the customer. The implemented functionality which is demonstrated to the customer. Note that demo focuses on only implemented functionalities and not all the planned functionalities (and yet to get implemented) of the software product. TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 1-39 Introduction to Software Engineering and Process Models Roles: 1, Scrum Master - The Scrum master leads the meeting and analy the response of each team member. The potential problems are discussed and solved in the meeting with the help of master. 2. Team Members - These are the persons working in a team to develop the software solutions. Advantages and Disadvantages Advantages : 1. SCRUM model brings transparency in project development status. 2. It provides flexibility towards the changes. 3. There is improved communication, minimum overhead in development process. 4. The productivity can be improved. Disadvantages : 1. Some decisions are hard to track in fixed time spa 2. There are problems to deal with non-functional requirements of the system, 1.20.4 Feature Driven Development (FDD) © Originally Peter Coad suggested this approach for object oriented software engineering. © Stephen Palmer and John Flesing has extended and enhanced Coad's work. * In FDD, the feature means client valued function. It is an iterative and incremental software development process In FDD, the collaborative activities are carried out. These activities are called as proc shown in Fig, 1.20.3 List of Developmen! Design Client valued features plan functionality ig. 1.20.3 Feature driven development life cycle TECHNICAL PUBLICATIONS®. An up thrust or knowledgeSoftware Engineering 41-40 Introduction to Software Engineering and Process Models © Various phases in the FDD life cycle are 1. Dev domain walkthroughs are conducted. Later on peer reviews and discussions are carried out Jop overall model : In this phase the high-level walkthrough of scope and detailed on these walkthroughs and domain area models are created. These domain area models are then merged into the overall models. 2. Build features list : Initially the list of features is created. The domain is functionally decomposed into various subject areas. These subject areas contain the business activities. The steps within business activity forms the categorized feature list. Features are basically the client vi Jued functions and can be expressed in the form.