Review Software life cycle Software process Various software

  • Slides: 39
Download presentation
Review § Software life cycle § Software process § Various software process models •

Review § Software life cycle § Software process § Various software process models • Have advantages and disadvantages § A unified model • Iterations • Many ways of tailoring it for specific project 1

A Process Management Challenge § Process complexity • Many interacting processes • Different processes

A Process Management Challenge § Process complexity • Many interacting processes • Different processes may follow different process models § The challenge • To ensure the effectiveness and the efficiency of the processes involved in software projects • To increase the predictability of the outcome for each process 2

Answer #1 § Keep it simple (KIS) § Rapid feedback 3

Answer #1 § Keep it simple (KIS) § Rapid feedback 3

4 Agile Software Processes Slides adapted from a tutorial presented by Pekka Abrahamsson from

4 Agile Software Processes Slides adapted from a tutorial presented by Pekka Abrahamsson from VTT Eletronics

Key Questions § What is agility? § Where is agility needed? § What are

Key Questions § What is agility? § Where is agility needed? § What are agile software development methods? 5

What is agility § Agile (Webster’s 1913) • Having the faculty of quick motion

What is agility § Agile (Webster’s 1913) • Having the faculty of quick motion in the limbs • Apt or ready to move § Agility for a software development organization • The ability to adapt and react expeditiously and appropriately to changes in its environment and demands imposed by the environment • The ability to both create and respond to change in order to profit in a turbulence business environment • Agility at organization, project, and individual levels 6

Where agility is needed? § Complex problems characterized by • Change • Turbulence §

Where agility is needed? § Complex problems characterized by • Change • Turbulence § Situations where accelerated development is required • To meet tight delivery schedule • To reduce the significant risk and uncertainty § Changes imposed by rapidly evolving technology, business, and product needs 7

Agile Thinking Explained The fundamental reason Need to respond To constant changes For a

Agile Thinking Explained The fundamental reason Need to respond To constant changes For a new paradigm Values Principles Practices Defines the set of beliefs About what is the most important Defines a set of ways To meet the values Defines in detail how this Is implemented in practice 8

Need to respond to constant change § Software development can be affected by many

Need to respond to constant change § Software development can be affected by many changes • Changes in development environment and technology • Organizational changes • Personnel changes • Product requirement changes • … § Software development should embrace change rather than avoid it 9

Manifesto for Agile Software Development We are uncovering better ways of developing software by

Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • • Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Source: www. agilemanifesto. org 10

The 12 Principles § Flexible and simple planning 1. Satisfy customer’s need through early

The 12 Principles § Flexible and simple planning 1. Satisfy customer’s need through early and frequent delivery 2. Keep delivery short (e. g. , every couple of weeks) 3. Working software is the primary measure of progress 4. Welcome changing requirements even late in the project 11

The 12 Principles (cont’d) § Building and maintaining a good team 5. Business people

The 12 Principles (cont’d) § Building and maintaining a good team 5. Business people and developers work together daily throughout the project 6. Build projects around motivated individuals 7. Place emphasis on face-to-face communication 8. The best results emerge from self-organizing teams 12

12 Principles (cont’d) § Simple and good design 9. Continuous attention to technical excellence

12 Principles (cont’d) § Simple and good design 9. Continuous attention to technical excellence and good design 10. Promote sustainable development pace 11. Simplicity is essential 12. Team reflects regularly where and how to improve 13

Agile Philosophy § The importance of self-organizing teams § Communication and collaboration between team

Agile Philosophy § The importance of self-organizing teams § Communication and collaboration between team members § Recognition that changes represent opportunities § An emphasis on rapid delivery that satisfies the customer 14

How agility can change your organization § Interaction and communication • Much more interaction

How agility can change your organization § Interaction and communication • Much more interaction between developers, management, and customers • Level of informal communication increases § Visibility • Related stakeholders know the exact status of the project § Much shorter development cycle • The pace of development can become very high § Less effort spent up front 15

Agile Software Development Methods (Processes) § Share the following characteristics • Incremental • Small

Agile Software Development Methods (Processes) § Share the following characteristics • Incremental • Small releases, rapid cycles • Cooperative • Customers and developers working constantly together with close communication • Straightforward • The method is light, simple, well documented, easy to modify • Adaptive • The method is able to take into account last moment changes 16

17 Extreme Programming (XP)

17 Extreme Programming (XP)

Introduction § Developed by Kent Beck in 1999 § Address the basic risks in

Introduction § Developed by Kent Beck in 1999 § Address the basic risks in software development § Method is formed around common sense principles and simple to understand practices • No process fits every project, rather, simple practices should be tailored to suit an individual project 18

19

19

Some XP Key Words § Client as a team member § User stories •

Some XP Key Words § Client as a team member § User stories • Short description of a desired functionality • Fit on a 3”x 5” note card § § • Stories can evolve The planning game Pair Programming Test-first software development Refactoring and continuous design improvement 20

21

21

XP Management Practices § Small/short releases § Planning game • Release planning • Iteration

XP Management Practices § Small/short releases § Planning game • Release planning • Iteration planning § 40 hour weeks? 22

XP Implementation § § § Coding standards Pair programming Metaphor Simple designs Refactoring Test-driven

XP Implementation § § § Coding standards Pair programming Metaphor Simple designs Refactoring Test-driven 23

Coding Standards Recommendations for the programmer with regards to § how to lay out

Coding Standards Recommendations for the programmer with regards to § how to lay out the code, e. g. tabbing, braces, comments § where source code files should be located in the file system § which settings should be used for the compiler and linker § which naming conventions should be followed for files, classes, methods, attributes, parameters, and local variables. 24

Pair Programming TWO programmers working side-by-side, collaborating on the same design, algorithm, code or

Pair Programming TWO programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc. ) defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software. 25

Metaphor § Explaining the project in terms understandable to the audience § Different Metaphors

Metaphor § Explaining the project in terms understandable to the audience § Different Metaphors for different audiences • Patterns when explaining to other developers • Plain English for the ccient company’s CEO 26

Refactoring § Early coding is kept simple to facilitate rapid early progress § Subsequent

Refactoring § Early coding is kept simple to facilitate rapid early progress § Subsequent iterations bring in complexity, including application of patterns 27

Other Practices § XP SCM • Collective code ownership • Continuous integration § XP

Other Practices § XP SCM • Collective code ownership • Continuous integration § XP V&V • Continuous testing • On-Site customer test 28

How XP solve some SE problems Problem Solution Slipped schedule Short development cycles Cancelled

How XP solve some SE problems Problem Solution Slipped schedule Short development cycles Cancelled project Intensive customer presence Cost of changes Extensive, ongoing testing, system always running Unit tests, customer tests Defect rates Misunderstand the business Business changes Customer part of the team Staff turnover Intensive teamwork Changes are welcome 29

Known Limitations § Limitation • XP is aimed at small to medium-sized teams •

Known Limitations § Limitation • XP is aimed at small to medium-sized teams • Requires the development team to be located in one place • Cannot solve the problems in projects that are not XP-able. 30

31 Scrum

31 Scrum

Introduction § Developed by Schwaber in 1995 • Based on experiences from adaptive, selforganizing

Introduction § Developed by Schwaber in 1995 • Based on experiences from adaptive, selforganizing product development in Japan § Focuses on managing systems development in a changing environment • Strictly management only • The choice of the software development methods are up to the project 32

33

33

Key Concepts § Backlog • A dynamic set of product features § Sprints •

Key Concepts § Backlog • A dynamic set of product features § Sprints • A set of backlog items that can be done in a predefined timebox (30 days) § Scrum daily meetings • • 15 minute status report What did you do since the last meeting? What obstacles are you encountering? What do you plan to accomplish by the next team meeting? 34

35

35

Key Concepts § § § § Effort estimation Product backlog Sprint planning meeting Sprint

Key Concepts § § § § Effort estimation Product backlog Sprint planning meeting Sprint backlog Daily scrum meeting (15 minutes) Sprint review meeting (4 hours) 36

Sprint § a short burst of work lasting approximately 30 days during which an

Sprint § a short burst of work lasting approximately 30 days during which an executable and other deliverables are built by an engineering team, as indicated by the assigned backlog. § A sprint is undertaken by a cross functional team consisting of no more than 9 members. § Every sprint has a specific goal, expressed as the backlog. • the list of tasks that the Scrum team is committing that they will complete in the current sprint § An executable demonstrating the goal will be completed by the team during the sprint. § The sprint team has final say in estimating and determining what they can accomplish during the sprint. § Once the sprint is underway, new backlog cannot be added to the sprint except that, if the scrum master determines that a new backlog item will enhance the viability of the product, is in alignment with the sprint, builds on the sprint’s executable, and can be completed within the sprint’s time frame, the backlog item can be added. Examples are building a demonstration of the executable for a specific purpose, such as a trade show or prospect. § If external forces determine that the sprint is working on the wrong thing, a sprint can be halted and restarted with new backlog and purpose. 37

Mix-and-Match § The practices in different agile methods can be extracted and combined §

Mix-and-Match § The practices in different agile methods can be extracted and combined § Examples • Pair programming and its variation • Daily scrum meeting • Test-driven development approach § The key • Understand the problems the practice is addressing • Understand the essence of the practice 38

Agile method in one slide § Is suitable for a volatile development environment •

Agile method in one slide § Is suitable for a volatile development environment • Product requirements and business environment change often • Tight schedule are required § Places emphasis on individuals, interactions, and delivering working software § Is both light and sufficient § Are incremental, cooperative, straightforward, and adaptive in nature 39