1-Nature of Software Software Engineering Software process project product Process Models-14-12-2024.pptx

Nature of Software Engineering

1. BCSE301L – Software Engineering Dr. P. Baskaran Asst. Professor Senior Grade, School of Computer Science & Engg .(SCOPE) VIT, Vellore 9095075951 [email protected] Dr Baskaran.P , SCOPE, VIT, Vellore Winter 24-25 1

2. Course Objectives To introduce the essential Software Engineering concepts. To impart concepts and skills for performing analysis, design ,develop, test and evolve efficient software systems of various disciplines and applications To make familiar about engineering practices, standards and metrics for developing software components and products. Dr Baskaran.P, SCOPE, VIT, Vellore Winter 24-25 2

3. Course Outcomes On completion of this course, student should be able to: Apply and assess the principles of various process models for the software development. Demonstrate various software project management activities that include planning , Estimations, Risk assessment and Configuration Management Perform Requirements modelling and apply appropriate design and testing heuristics to produce quality software systems. Demonstrate the complete Software life cycle activities from requirements analysis to maintenance using the modern tools and techniques. Escalate the use of various standards and metrics in evaluating the process and product. Dr Baskaran.P, SCOPE, VIT, Vellore Winter 24-25 3

4. Module:1 Overview Of Software Engineering 6 hours Nature of Software, Software Engineering, Software process, project, product, Process Models Classical Evolutionary models, Introduction to Agility - Agile Process-Extreme programming - XP Process – Principles of Agile Software Development framework - Overview of System Engineering Module:2 Introduction To Software Project Management 6 hours Planning, Scope, Work break-down structure, Milestones, Deliverables, Cost and Estimates - (Human Resources, Time-scale, Costs), Risk Management, RMMM Plan, CASE TOOLS, Agile Project Management, Managing team dynamics and communication, Metrics and Measurement Module:3 Modelling Requirements 8 hours Software requirements and its types, Requirements Engineering process, Requirement Elicitation, System Modeling – Requirements Specification and Requirement Validation, Requirements Elicitation techniques, Requirements management in Agile. Module:4 Software Design 8 hours Design concepts and principles - Abstraction - Refinement - Modularity Cohesion coupling, Architectural design, Detailed Design Transaction Transformation, Refactoring of designs, Object oriented Design User-Interface Design Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 4 Syllabus

5. Cont.. Module:5 Validation And Verification 7 hours Strategic Approach to Software Testing, Testing Fundamentals Test Plan, Test Design, Test Execution, Reviews, Inspection and Auditing – Regression Testing – Mutation Testing - Object oriented testing - Testing Web based System - Mobile App testing – Mobile test Automation and tools – DevOps Testing – Cloud and Big Data Testing Module:6 Software Evolution 4 hours Software Maintenance, Types of Maintenance, - Software Configuration Management – Overview – SCM Tools. Re-Engineering, Reverse Engineering, Software Reuse Module:7 Quality Assurance 4 hours Product and Process Metrics, Quality Standards Models ISO, TQM, Six-Sigma, Process improvement Models: CMM & CMMI. Quality Control and Quality Assurance – Quality Management - Quality Factors - Methods of Quality Management Module:8 Contemporary Issues 2 hours Dr Baskaran.P, SCOPE, VIT, Vellore Winter 24-25 5

6. Text Book Ian Somerville, Software Engineering, 10 th Edition, Addison-Wesley, 2015 Reference Books Roger S. Pressman and Bruce R. Maxim, Software Engineering: A Practitioner’s Approach, 10th edition, McGraw Hill Education, 2019 William E. Lewis , Software Testing and Continuous Quality Improvement, Third Edition, Auerbach Publications, 2017 Dr Baskaran.P, SCOPE, VIT, Vellore Winter 24-25 6

7. Method of Evaluation Quiz -1 10 Marks (before cat1)* CAT - 1 15 Marks ( Closed Book ) QUIZ -2 10 Marks CAT - 2 15 Marks ( Open Book ) Digital Assignment-1 10 Marks FAT 40 Marks Total 100 Marks * Tentative dates Dr Baskaran.P, SCOPE, VIT, Vellore Winter 24-25 7

8. Rubrics for Assessment Dr Baskaran.P, SCOPE, VIT, Vellore Winter 24-25 8

9. Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 9 Module: 1 Overview of Software Engineering Nature of Software, Software Engineering, Software process, project, product, Process Models: Classical Evolutionary models, Overview of System Engineering Introduction to Agility - Agile Process-Extreme programming - XP Process Principles of Agile Software Development framework – Overview of System Engineering

10. 10 What is Software? Software is: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information and (3) documentation that describes the operation and use of the programs.

11. 11 What is Software? Software is developed or engineered, it is not manufactured in the classical sense. Software doesn't "wear out." Although the industry is moving toward component-based construction, most software continues to be custom-built.

12. Hardware Vs Software Hardware Software Manufactured Developed/ engineered wear out deteriorate Built using components Custom built Relatively simple Complex 12

13. Failure curve for Hardware Source : Pressman Book 13

14. Failure curve for Software 14

15. Take a good look at these pictures 15

16. What are the expectations from these? 16 • Machine which flies • Supports going to a specified place • Carries people and goods • Reliably functions • Market System supporting buying and selling of stocks/bonds/ securities • Supports buyers and sellers to be local/remote for all transactions • Regulation, Data Integrity, Security

17. What are the expectations from these? 17 • System to play a video game for entertainment and competition • Supports individuals and groups • Runs on dedicated or general purpose systems • Supports various levels of skills and complexity • Supports a market place featured around a web site • Will have number of upgrades and revisions

18. What else do you think they have in common? 18 LOTS OF LINES OF CODE

19. In Detail 19 A Boeing 747 has more lines of code than the parts of the aeroplane including nuts and bolts ~ 5 Million lines of Code Most Games have ~ 6 Million or more lines of code We also have to deal with ‘ Diminishing Value ’ or ‘ Obsolescence ’

20. What do you think is the impact of a 90 minute outage at Amazon? 20 Loss of 2.8 Million $ revenue Loss of customers Everything in an environment like Amazon must be functioning in a user friendly way with the expectation that there will be no errors. All these points have to be factored in!

21. There is hence a need for – 21 Interacting with customers and stakeholders on what is needed Good planning Team work Ability to scale and support Understanding who and how this is going to be used Experts in multiple domains This will require a lot of engineers. Lots of engineers implies many teams and team work!

22. A quick calculation 22 Let us assume a software engineer can code 1 LOC a minute. Then, 1 LOC/minute * 60 minutes/hour = 60 LOC/hour Say for 40 hours/week, 60*40 = 2400 LOCs/week/SE Which implies, 2400 LOC/week * (~)50 = 1,20,000 LOCs/year/SE Engineers will thus be working for long periods of time!

23. Let us look at some definitions 23 Software can be collection of executable computer programs (code), their configuration files and associated libraries and their documentations serving a computational purpose. Software Product is software when made for a specific or specific group of requirements. Software prefixes Application System Custom Generic

24. Let us look at some definitions 24 Engineering is all about acquiring and using well defined scientific principles and systematic methods for developing products, with economic sense, social perspective and practical considerations. Software Engineering is the systematic, disciplined, quantifiable approach towards the development, operation, and maintenance of software products and thus supports managing of complexity. Software Engineering principle drives usage of appropriate tools and techniques depending on the problem to be solved, while considering the constraints and resources available. Focuses more on techniques for developing and maintaining software that is correct from its inception.

25. Is Computer Science the same as Software Engineering? 25 Think about it Consider a bridge collapse. Is this issue a scientist’s problem or an engineer’s problem? Hint Scientist build something to learn something new whereas Engineer learns things to design and build quality products Scientists want to achieve scientific breakthroughs whereas Engineers want to avoid engineering failures

26. Differences between Computer Science and Software Engineering 26

27. Fundamental Drivers of Software Engineering 27 Industrial Strength Software Software is expensive Can influence the life or death of a person Needs to be operational Capable of being moved Needs to be maintainable Should have elaborate documentation Absence or minimal number of bugs Impactful to the business Software labor is expensive Each line of code can cost between $5 - $35 Maintenance and rework costs money Example – Therac 25 (Radiation therapy) One software bug caused over exposure to radiation Death of 6 people

28. Fundamental Drivers of Software Engineering 28 Heterogeneity Diversity Business and Social changes Systems should work as distributed systems Different types of software systems Ability to change existing software and develop new software Organizations are becoming global Security and trust Scale Trust the software Scale easily with size

29. 29 Software Applications Computer Programs fall into one of the following broad application domains System Software Application Software Embedded Software Product Software WebApps (Web applications) AI application

30. 30 Legacy Software – old software continually modified to meet changes in business requirements and computing platforms software must be adapted to meet the needs of new computing environments or technology. software must be enhanced to implement new business requirements. software must be extended to make it interoperable with other more modern systems or databases. software must be re-architected to make it viable within a network environment . Why must it change? For one or more of the following reasons

31. Changing Nature of Software System Software System Software 31

32. Changing Nature of Software Application Software Application Software 32

33. Changing Nature of Software Embedded Software Embedded Software 33

34. Changing Nature of Software AI Software AI Software 34

35. Software Myths Beliefs about software and the process used to build it. Myths have number of attributes that have made them insidious 35

36. Management Myths Myth1 : We already have a book that's full of standards and procedures for building software, won't that provide my people with everything they need to know? Reality : Are software practitioners aware of existence standards? Does it reflect modern software engineering practice? 36

37. Customer Myths Myth1 : A general statement of objectives is sufficient to begin writing programs— we can fill in the details later. Reality : A poor up-front definition is the major cause of failed software efforts. A formal and detailed description of the information domain, function, behavior, performance, interfaces, design constraints, and validation criteria is essential. These characteristics can be determined only after thorough communication between customer and developer. 37

38. Practitioner’s Myths Myth1 : Once we write the program and get it to work, our job is done. Reality : "the sooner you begin 'writing code', the longer it'll take you to get done." Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time. 38

39. What is SE ? The IEEE definition: Software Engineering: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software 39

40. 40 Software Engineering - A Layered Technology Software Engineering layers : A quality focus: the “bedrock” Process: the “Foundation” Methods: technical “how to’s ” Tools : CASE preferred Software engineering is a fully layered technology. To develop a software, we need to go from one layer to another. All these layers are related to each other and each layer demands the fulfillment of the previous layer.

41. Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 41 Quality focus The characteristics of good quality software are: • Correctness of the functions required to be performed by the software. • Integrity i.e. providing security so that the unauthorized user cannot access information or data. • Usability i.e. the efforts required to use or operate the software. Process • It is the base layer or foundation layer for the software engineering. It covers all activities, actions and tasks required to be carried out for software development. Methods • It provides the technical way to implement the software. It includes collection of tasks starting from communication, requirement analysis, analysis and design modelling, program construction, testing and support. Tools -The software engineering tool is an automated support for the software development. The tools are integrated i.e the information created by one tool can be used by the other tool. Software Engineering - A Layered Technology

42. Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 42 Software product A software product is a computer program that's developed and maintained to meet a user need or market requirement. For example, Microsoft Office is a software product that's traditionally distributed as a file package or downloaded over a network.  Software process A software process is a set of activities that produce a software product. These activities include:  Software specifications : Defining the software's functionality and constraints  Software development : Producing the software to meet requirements  Software validation : Ensuring the software does what the customer wants  Software evolution : Evolving the software to meet changing client needs  Software project A software project is a group of tasks that need to be completed to reach a clear result.  Projects can be simple or difficult, and can be operated by one person or a hundred.  A software application developed for a specific customer is considered a project.

43. 43 A Software Process Framework

44. 44 Process - A Process defines who is doing what, when, and how to reach a certain goal A Process Framework - A process framework establishes the foundation for a complete software process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. Umbrella Activities- A process framework encompasses a set of Umbrella activities that are applicable across the entire software process. Framework Activities- Each framework activity is populated by a set of software engineering actions. Each action is populated with individual work tasks that accomplish some part of the work implied by the action.

45. 45 Framework Activities Communication Planning Modeling Analysis of requirements Design Construction Code generation Testing Deployment

46. 46 Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management The process framework encompasses a set of umbrella activities that are applicable across the entire software process

47. Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 47

48. Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 48

49. Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 49

50. 50 Types of Process Models 1. Prescriptive Process Models 1.1 Water Fall Model 1.2 V-Model 1.3 Incremental Model 1.4 RAD (Rapid Application development) 2. Evolutionary Process Models 2.1 Evolutionary Models: Prototyping 2.2 Evolutionary Models: Spiral 2.3 Evolutionary Models: Concurrent 3. Specialized Process Models 3.1 Component based development 3.2 Unified Process 4. Dynamic Models: Agile Model 4.1 Extreme Programming 4.2 Scrum

51. 51 1.1 The Waterfall Model / Classical Life Cycle Model / Sequential Model

52. What factors contribute to choosing the Waterfall approach? Short-term projects Clear, fixed, and well-documented requirements Static technology that is understood Stable product definition A variety of resources for product support Low Product Owner Involvement Strictly-set timeline Fixed budget that cannot be changed 52

53. Advantages of Waterfall model The waterfall model is simple and easy to understand , to implement, and use. All the requirements are known at the beginning of the project, hence it is easy to manage . It avoids overlapping of phases because each phase is completed at once. This model works for small projects where the requirements are easily understood. This model is preferred for those projects where the quality is more important as compared to the cost of the project. 53

54. Disadvantages of the Waterfall model This model is not good for complex and object oriented projects. In this model, the changes are not permitted so it is not fit for moderate to high risk changes in project. It is a poor model for long duration proj ects. The problems with this model are uncovered , until the software testing . The amount of risk is high . No feedback path: In classical waterfall model evolution of a software from one phase to another phase is like a waterfall. It assumes that no error is ever committed by developers during any phases. Therefore, it does not incorporate any mechanism for error correction. 54

55. Waterfall model – Advantages, Disadvantages & Usage 55 ADVANTAGES DISADVANTAGES Simple Assumes requirements are frozen Clear identified phases Difficult to change & sequential Easy to manage due to rigidity Poor model for long projects Each phase – specific deliverables + reviews Big Bang approach Easy to departmentalize and control High risk + Uncertainty USAGE Pure form : Short projects where requirements are well known Product definition is stable & technology is understood Variant form : High level in long projects

56. 56 1.2 The V-Model A variation in the representation of the waterfall model is called the V-model 1.Left Side of ‘V’ – Basic Problem Requirements 2.Right Side of ‘V’ – Quality Assurance Actions No fundamental difference between Waterfall and ‘V’ Model

57. The V-model is  an SDLC model where execution of processes happens in a sequential manner in a V-shape . It is also known as Verification and Validation model. The V-Model is an extension of the waterfall model and is based on the association of a testing phase for each corresponding development stage. 57 1.2 The V-Model contd.

58. In the V-shaped Model, the development phase corresponds to the testing phase and they go in parallel. Verification phases are on one side of the image and the Validation  phases are  on the other. there are 4 Verification phases Requirements analysis System design Architectural design Module design The validation phase also includes 4 stages: Unit testing Integration testing System testing Acceptance testing The V-shaped model has the same applicability as the Waterfall Model. Requirements have to be clearly defined from the very beginning of the  SDLC  as going back and making changes will increase the product development costs. This model suits best for the healthcare industry. 58 1.2 The V-Model contd.

59. Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 59

60. When to implement the V-Shaped Model? There are clearly defined, documented, stable requirements The technology used is also stable and the project team has a full understanding of it All of the require ments are extra clear The project is short-term and not complex The best advantage of the V-shaped Model is that you can both understand, apply to, and manage it in an  SDLC  easily. However, on the contrary, the model lacks flexibility when changes are on the horizontal and it is quite expensive for the customer to implement those changes as they trigger additional development costs. 60 1.2 The V-Model contd.

61. Advantages of V-model V-model is easy and simple to use. Many testing activities i.e planning, test design are executed in the starting , it saves more time. Calculation of errors is done at the starting of the project hence, less chances of error occurred at final phase of testing. This model is suitable for small projects where the requirements are easily understood. Disadvantages of V-model V-model is not suitable for large and composite projects. If the requirements are not constant then this model is not acceptable. 61

62. 62 1.3 The Incremental Model / Iterative

63. Incremental delivery Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 63

64. Staged Delivery Model Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 64

65. Winter 24-25 Dr Baskaran.P, SCOPE, VIT, Vellore 65 Parallel Development Model

66. Incremental model 66 Requirements are partitioned Working software in first module Each subsequent release adds functionality to previous module Continuous integration is done until entire system is achieved

67. In the incremental model, the development starts with implementing several small requirements, and then the product is enhanced with the help of numerous iterations ( incrementally ). The process of enhancement goes on in increments (iterations) until the application  features  are complete and it is ready to be deployed. Developing only a small part of the software is a smart approach as you can easily review what was done, quickly identify further requirements and proceed with the implementation or provide some changes to the app and then proceed. Either way, you’ll benefit from the  solutions  as every new  iteration  will bring you a new and better version of the software. 67 1.3 The Incremental Model Contd.

68. Unlike the Waterfall model, the Iterative Model allows carrying out multiple iterat ions at a time and receives the product output simultaneously. The key to success , which the model offers, is in validating the versions of the software and testing them according to the requirements. This allows a better understanding of where the team is at with the project, the product’s functionality verification, and 100% confidence that the product will be a success. 68 1.3 The Incremental Model Contd.

69. Where is the Iterative Model applicable in software development? System requ irements are clearly defined and fully understood Addit ional req uirements can occur with time When the team learns new te chnology and works on the project simultaneously Specific resources are to be used only when they are required for specific iterations according to the contract 69 1.3 The Incremental Model Contd.

70. Advantages of Incremental model This model is flexible because the cost of development is low and initial product delivery is faster. It is easier to test and debug in the smaller iteration . The working software is generated quickly in the software life cycle. The customers can respond to its functionalities after every increment. Disadvantages of the incremental model The cost of the final product may cross the cost initially estimated . This model requires a very clear and complete planning . The planning of design is required before the whole system is broken into smaller increments. The demands of customer for the additional functionalities after every increment causes problem in the system architecture. 70 1.3 The Incremental Model Contd.

71. 1.4 RAD - Model RAD is a Rapid Application Development model. Using the RAD model, software product is developed in a short period of time. The initial activity starts with the communication between customer and developer. Planning depends upon the initial requirements and then the requirements are divided into groups. Planning is more important to work together on different modules. 71

72. 72

73. Applications This model should be used for a system with known requirements and requiring short development time. It is also suitable for projects where requirements can be modularized and reusable components are also available for development. This model can only be used if the teams consist of domain experts. This is because relevant knowledge and ability to use powerful techniques is a necessity. The model should be chosen when the budget permits the use of automated tools and techniques required. 73

74. 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. It is easier to accommodate changing requirements due to the short iteration time spans. 74

75. Disadvantages The use of powerful and efficient tools requires highly skilled professionals. The absence of reusable components can lead to failure of the project. The team leader must work closely with the developers and customers to close the project in time. The systems which cannot be modularized suitably cannot use this model. Customer involvement is requ ired 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. 75

76. 76 2.1. Evolutionary Models: Prototyping Initial implementation starts from a skeleton of product This is followed by refinement through user feedback & evolution Built with dummy modules Rapid prototyping Successive refinement The  evolutionary model  is a combination of the Iterative and Incremental models of the  software development  life cycle.

77. A prototype is an early version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and its possible solutions. This enables understanding customer requirements early in the development stage and getting valuable feedback. The model includes: Identification of basic requirements Initial prototype development Prototype review Prototype revision and enhancement 77 Prototyping

78. Prototyping 78

79. Where and when is the Prototyping Model applicable? Prototyping is applicable to online software system development where there is a high level of user interaction . For example, Systems that require users to fill out forms Software that requires lots of data processing Advantages Prototype model need not know the detailed input , output, processes, adaptability of operating system and full machine interaction. In the development process of this model users are actively involved. The development process is the best platform to understand the system by the user . Errors are detected much earlier . Gives quick user feedback for better solutions. It identifies the missing functionality easily. It also identifies the confusing or difficult functions. 79

80. Disadvantages of Prototyping Model: The client involvement is more and it is not always considered by the developer. It is a slow process because it takes more time for development. Many changes can disturb the rhythm of the development team. It is a thrown away prototype when the users are confused with it. 80

81. 2.2 Evolutionary Models: The Spiral 81

82. Spiral Model The Spiral Model is a combination of the Iterative and Waterfall models. From the Iterative methodology, it took the cycled development , and from the Waterfall one, it borrowed a systematic  approach   and the ability to control the process. The biggest emphasis of the current model falls on risk analysis . Also, it delivers a project in iterations, which swirl around the spiral. 82

83. The Spiral Model is designed in 4 stages. The product under development passes all of these stages during its iterations, which are also called spirals in this methodology. The stages include: Identification Design Construct (Build) Evaluation (Risk analysis) 83 Spiral Model Contd.

84. When is it best to use the Spiral Model? The Spiral Model is applied when there is a need to “ learn with the product’s maturity ” and: There’s a budget limit and you need to foresee risks You have a medium or high-risk project to carry out There is a long-term projec t, and changes might occur The  requirements  are vague to the customer Requirements need more clarity due to their complexity The primary product has to be released in several stages to get valuable customer feedback You expect major changes to the product during the SDLC 84 Spiral Model Contd.

85. Advantages of Spiral Model It reduces high amount of risk . It is good for large and critical projects. It gives strong approval and documentation control. In spiral model, the software is produced early in the life cycle process. Disadvantages of Spiral Model It can be costly to develop a software model. It is not used for small projects. 85 Spiral Model Contd.

86. 2.3Evolutionary Models: Concurrent 86 It allows a software team to represent iterative and concurrent elements of any of the process models

87. Advantages of the concurrent development model This model is applicable to all types of software development processes. It is easy for understanding and use. It gives immediate feedback from testing. It provides an accurate picture of the current state of a project. Disadvantages of the concurrent development model It needs better communication between the team members. This may not be achieved all the time. It requires to remember the status of the different activities . 87

88. Specialized Process Model 1.Component-Based Development 2.The Formal Methods Model 3.Aspect-Oriented Software Development

89. Specialized Process Model Component based development —the process to apply when reuse is a development objective ( like spiral model) Formal methods —emphasizes the mathematical specification of requirements ( easy to discover and eliminate ambiguity, incompleteness and inconsistency) Aspect Oriented software development (AOSD) —provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process (Late 90 s) —a “ use-case driven, architecture-centric, iterative and incremental ” software process closely aligned with the Unified Modeling Language (UML) to model and develop object-oriented system iteratively and incrementally.

90. The Unified Process (UP)

91. The Unified Phases

92. UP Work Products

93. INTRODUCTION TO AGILITY Agility is effective ( rapid and adaptive) response to change (changes in team members, new technology, requirements etc ) that may have an impact on the product being developed. It encourages effective communication in structure and attitudes among all team members, technological and business people, software engineers and managers. Agility can be applied to any software process but it is essential that the process should support incremental delivery strategy that gets working software to the customer as rapidly as feasible for the product type and operational environment The Agile methodology is a project management approach that involves breaking the project into phases and emphasizes continuous collaboration and improvement. Teams follow a cycle of planning, executing, and evaluating

94. What is “Agility”? 4.1 Dynamic Models: Agile Model 94 Effective (rapid and adaptive) response to change Effective communication among all stakeholders Drawing the customer onto the team Organizing a team so that it is in control of the work performed Yielding … Rapid, incremental delivery of software

95. The Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 95

96. Agile Methods Agile methods are designed to overcome the disadvantages of the traditional heavy weight methodologies (the difficulty of efficiently accommodating change requests from customers during execution of the project). Agile model is an umbrella term that refers to a group of development processes, and not any single model of software development. There are various agile approaches.. Kanban Scrum Extreme Programming (XP) Feature-driven Development (FDD) Dynamic Systems Development Method (DSDM) Crystal Techniques Lean 96

97. Agile Methods In Agile model the feature requirements are decomposed into several small parts that can be incrementally developed. The agile model adopts an iterative approach . Each incremental part is developed over an iteration. Each iteration is intended to be small and easily manageable, and lasts for a couple of weeks only . At a time only one increment is planned, developed, and then deployed at the customer’s site. No long-term plans are made. The time taken to complete an iteration is called a time-box . The implication of the term ‘time box’ is that the end date for an iteration does not change . 97

98. Agile Methods Agile model emphasizes face-to-face communication over written documents. Team size is deliberately kept small (5-6 people) to help the team members effectively communicate with each other and collaborate. An agile project usually includes a customer representative in the team. At the end of each iteration , the customer representative along with the stake holders review the progress made, re-evaluate the requirements, and give suitable feedback to the development team. Agile development projects usually deploy pair programming . In this approach, two programmers work together at one work station. One types the code, the other reviews the code as it typed. Two programmers switch their roles every hour or so. Studies indicate that working in pairs produce compact well-written programs and commit fewer errors as compared to programmers working alone 98

99. Agile Principles 99

100. 12 Agility Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements , even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face–to–face conversation . 100

101. 12 Agility Principles 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development . The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity – the art of maximizing the amount of work not done – is essential. 11. The best architectures, requirements, and designs emerge from self–organizing teams . 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 101

102. Extreme Programming (XP)