3. Software Process

1
3. Software Process
2
Whats a process?

• Set of activities in creating software
• It involves creativity
• hard to automate
• Requires human judgment
• No one approach to create software
• Different organizations and groups within
  organization do different things

3
Activities

• Requirements specification
• Analysis
• Design
• Implementation
• Testing
• Maintenance and evolution

4
Different Approaches

• Waterfall
• Spiral
• Iterative Incremental Development
• Agile

5
Waterfall Model
Requirements
Analysis
Design
Implementation Testing
Integration
Maintenance
6
Whats good about Waterfall

• Easy to plan
• (but hard to execute)
• Easy to explain the progression of the project
• (but may not be the reality, however)
• Help with budgeting and estimating time upfront
• (often overrun though)

7
Problems with Waterfall

• Sequential steps
• Not easy to work with
• Each stage expected to be complete and well done
• Assumes requirements are well understood
• (Are they ever?)
• Hard to keep up with change
• (change is the only constant)
• Hard to meet users needs

8
Spiral Model
Analysis
Requirements Specification
Design
Implementation Unit Testing
Integration
9
Whats good about Spiral

• Recognizes that software applications need to
  evolve
• Each version may be one loop though the spiral
• You have a chance to revisit and modify things
  that may not be correct or adequate

10
Problems with Spiral

• Each cycle may be long waterfall
• If each cycle is large, hard to modify system
• change may be prohibitive
• May be expensive
• If cycles are short, planning may be hard
• Project management and reporting will be an issue

11
Iterative Incremental Dev.

• Consider waterfall as a guiding framework, but
  not execution model
• Consider spiral as execution model within that
  guiding framework
• Planned with versions in mind
• incremental
• Each increment involves many cycles of all the
  activities, ending with executable application

12
Iterative Incremental Dev.
Waterfall
Spiral
Iterative Incremental Development
13
Advantages Disadvantages of IID

• Provides good opportunity to analyze risk
• System evolves
• Coding starts early
• Integration start sooner
• May still be ceremonial
• Iteration may be too long
• Some companies that claim to be doing IID
  actually are doing waterfall

14
Agile Development Process

• Iterative and evolutionary development
• Adaptive planning
• Incremental delivery
• Agility
• More focused on success than sticking with a plan
• Working software is valued and considered measure
  of progress

15
Advantages

• Closely matches user expectations
• You may modify and evolve as understanding as
  requirements evolve
• Functionality stabilizes overtime

16
Disadvantage

• Hard to document each step
• Project management is not easy
• System may be poorly structure
• You may hack your way though
• Works effectively only for small teams

17
Where does it work?

• For small teams
• Small to medium size projects
• Not effective on large projects
• (large projects are not effective any ways!!)
• Requires competent team

18
The Agile Manifesto

• Individuals and interactions
• over process and tools
• Working Software
• over comprehensive documentation
• Customer collaboration
• over contract negotiations
• Responding to change
• over following a plan

19
The Agile Principles

• Satisfy Customer through early and continuous
  delivery of valuable software
• Welcome changing requirements any time
• Deliver working software frequently
• Business people and developers work closely
• Motivated individuals trusted to do job
• Face-to-face conversation
• Working software measure of progress
• Processes that promote sustainable development
• Sponsors, developers, users should maintain
  constant pace indefinitely
• Attention to technical excellence and good design
  enhances agility
• Simplicity is essential
• Reflect on how to become more effective, and
  tunes and adjusts behavior accordingly

20
Agile Modeling

• UML is for understanding/communication not for
  documentation
• Agile modeling is not avoiding modeling
• Do not apply UML to all or most of software
• Defer simpler design till programming
• Use UML for smaller percentage of system where it
  is required
• Choose lightweight simpler tools
• Dont model alone
• Look for good enough solution
• Use design as guidelines it will be inaccurate
  when you start
• Do not expect (or be expected) to design and hand
  off for coding developer must be part of
  designing

21
Agile Processes

• Scrum
• Self-organizing teams
• Daily team measurement
• Avoid following predefined steps
• Standup meetings, 30 day iteration, demo to stake
  holders at end of iteration
• XP
• Collaboration
• Quick and early software creation
• Communication, simplicity, feedback, courage
• Constant feedback, test driven development