Agile Software Development - PowerPoint PPT Presentation

1 / 16
About This Presentation
Title:

Agile Software Development

Description:

Agile Software Development Traditional Software Development Initiation (RFP) Feasibility study Technical can we build it? – PowerPoint PPT presentation

Number of Views:135
Avg rating:3.0/5.0
Slides: 17
Provided by: Leeds92
Category:

less

Transcript and Presenter's Notes

Title: Agile Software Development


1
Agile Software Development
2
Traditional Software Development
  • Initiation (RFP)
  • Feasibility study
  • Technical can we build it?
  • Economic should we build it?
  • Operational if we build it, will it be used?
  • Schedule will it be ready in time?
  • Requirements definition
  • Specifications
  • Project plan

3
Traditional Software Development
  • 6. Logical design (external view)
  • 7. Physical design (internal view)
  • 8. Coding (or code acquisition)
  • Testing
  • Maintenance
  • SDLC Investigate, Analyze, Design, Implement
    and Maintain

4
Plan Driven Approach
  • Roots may be traced to engineering concepts
  • Standards and well-defined processes process
    discipline
  • Adherence to processes
  • Completeness of documentation
  • Traceability across requirements, design, and
    code is mandatory

5
Plan driven Approach
  • Processes are defined, standardized, and
    incrementally improved
  • Standardization allows for comparisons and
    repeatability
  • Training, getting information, and estimating are
    supposedly easier
  • Less need for retraining
  • People can be replaced! Loss of key personnel
    does not doom a project!

6
Advantages
  • Easy to understand, easy to use
  • Provides structure to inexperienced staff
  • Milestones are well understood
  • Sets requirements stability
  • Good for management control (plan, staff, track)
  • Aim for predictability and stability
  • Plan extensively at the outset to anticipate
    changes/variations
  • They try to tame change
  • Emphasis on quality of software and
    predictability
  • Exemplified by the Capability Maturity Model

7
Capability Maturity Model
  • A bench-mark for measuring the maturity of an
    organizations software process
  • CMM defines 5 levels of process maturity based on
    certain Key Process Areas (KPA)
  • SEI rates organization on their maturity levels.

8
Capability Maturity Model
Level Focus Key Process Area
5 Optimizing (1) Continual process improvement Defect Prevention, Technology Change Management, Process Change Management
4 Managed (5) Product and process quality Quantitative process and software quality management
3 Defined (10) Engineering processes and organizational support Organizational process focus, organizational process definition, training program, integrated software management, software product engineering, inter-group coordination, peer reviews
2 Repeatable (15) Project management processes Requirements management, software project planning, sw project tracking oversight, sw subcontract management,
1 Initial (a little less than 70) Competent people heroics - ad hoc Competent people heroics - ad hoc
9
Disadvantages
  • However
  • All requirements must be known upfront
  • Deliverables created for each phase are
    considered frozen inhibits flexibility
  • Can give a false impression of progress
  • Does not reflect problem-solving nature of
    software development iterations of phases
  • Integration is one big bang at the end
  • Little opportunity for customer to preview the
    system (until it may be too late)

10
Challenges
  • Standish Group gt 50 of software projects fail
    to meet their productivity, cost or functionality
    goals
  • Changing requirements (25?)
  • User involvement (13?)
  • Executive Support (7.5?)
  • Lack of skills/technical incompetence (7)
  • Lack of resources (6.4)
  • Unrealistic expectations (6?)
  • Unclear objectives (5.3)
  • Unrealistic deadlines/time-frames (4.3)

11
Discipline vs Agility
  • Discipline creates well-organized memories,
    history, and experience
  • Agility makes use of memory and history to adapt,
    react, and to be opportunistic
  • What do you think is more important? Why?

12
Agile Manifesto
  • Value
  • Individuals and their interactions over processes
    and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

13
Agile Methods
  • Agile software development is a conceptual
    framework for undertaking software engineering
    projects.
  • Most agile methods attempt to minimize risk by
    developing software in short timeboxes, called
    iterations, which may typically last one to four
    weeks.
  • Each iteration is like a miniature software
    project of its own, and includes all of the tasks
    necessary to release the mini-increment of new
    functionality.
  • Agile methods emphasize realtime communication,
    preferably face-to-face, over written documents.
  • Agile methods rely on the close collaboration of
    activity engaged individuals with ordinary
    talents and has the ability to flexibly schedule
    the implementation of functionality, responding
    to changing business needs.

14
Examples
  • Extreme Programming ( X P)
  • Adaptive Software Development
  • Crystal
  • Scrum
  • Feature-Driven Development

15
Extreme programming Practices
  1. Planning game determine scope of the next
    release by combining business priorities and
    technical estimates
  2. Small releases put a simple system into
    production, then release new versions in very
    short cycle
  3. Metaphor all development is guided by a simple
    shared story of how the whole system works
  4. Simple design system is designed as simply as
    possible (extra complexity removed as soon as
    found)
  5. Testing programmers continuously write unit
    tests customers write tests for features
  6. Refactoring programmers continuously
    restructure the system without changing its
    behavior to remove duplication and simplify

16
Extreme programming Practices
  • Pair-programming -- all production code is
    written with two programmers at one machine
  • Collective ownership anyone can change any code
    anywhere in the system at any time.
  • Continuous integration integrate and build the
    system many times a day every time a task is
    completed.
  • 40-hour week work no more than 40 hours a week
    as a rule
  • On-site customer a user is on the team and
    available full-time to answer questions
  • Coding standards programmers write all code in
    accordance with rules emphasizing communication
    through the code
Write a Comment
User Comments (0)
About PowerShow.com