Review - PowerPoint PPT Presentation

Loading...

PPT – Review PowerPoint presentation | free to download - id: 682aa8-MWMxM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Review

Description:

Software life cycle Software process Various software process models Have advantages and disadvantages A unified model Iterations Many ways of tailoring it for ... – PowerPoint PPT presentation

Number of Views:18
Avg rating:3.0/5.0
Slides: 40
Provided by: facultyKu3
Category:
Tags: review | scrum

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Review


1
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

2
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

3
Answer 1
  • Keep it simple (KIS)
  • Rapid feedback

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

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

6
What is agility
  • Agile (Websters 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

7
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

8
Agile Thinking Explained
The fundamental reason For a new paradigm
Need to respond To constant changes
9
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

10
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

11
The 12 Principles
  • Flexible and simple planning
  • 1. Satisfy customers 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

12
The 12 Principles (contd)
  • 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

13
12 Principles (contd)
  • 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

14
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

15
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

16
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

17
Extreme Programming (XP)
18
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

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

21
(No Transcript)
22
XP Management Practices
  • Small/short releases
  • Planning game
  • Release planning
  • Iteration planning
  • 40 hour weeks?

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

24
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.

25
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.

26
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 companys CEO

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

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

29
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
Defect rates Unit tests, customer tests
Misunderstand the business Customer part of the team
Business changes Changes are welcome
Staff turnover Intensive teamwork
30
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.

31
Scrum
32
Introduction
  • Developed by Schwaber in 1995
  • Based on experiences from adaptive,
    self-organizing 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

33
(No Transcript)
34
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?

35
(No Transcript)
36
Key Concepts
  • Effort estimation
  • Product backlog
  • Sprint
  • Sprint planning meeting
  • Sprint backlog
  • Daily scrum meeting (15 minutes)
  • Sprint review meeting (4 hours)

37
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 sprints
    executable, and can be completed within the
    sprints 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.

38
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

39
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
About PowerShow.com