Software Development Processes

1
Software Development Processes

• CSCI 5801 Software Engineering

2
Software Development Processes
3
Major Stages

• Major steps followed by all processes
• Feasibility study
• Requirements Analysis
• Architectural Design
• Implementation and Testing
• Product Delivery
• Maintenance

What we will focus on for now
4
Feasibility Studies

• Should we build this system?
• Will it solve the customers problems?
• Is it too costly?
• Development costs
• Hardware needed
• User training
• Maintenance
• Do we have the expertise/personnel to
  successfully create the system?

5
Requirement Analysis

• What should the system do?
• Identification of stakeholders and needs
• Elicitation of requirements
• Documentation of requirements in manner
  understood by developers and customers
• Validation of requirements
• Prototyping

6
Software Design

• How should system work?
• Determination of overall system architecture
• Decomposition into simpler modules/subsystems/obje
  cts
• Formal design of interfaces between subsystems

7
Implementation and Testing

• Implementation
• Individuals/small teams implement code at object
  level
• New objects integrated into overall system
• Testing
• Unit testing of individual objects
• Integration testing to insure system functions
  correctly when new objects added

8
Project Delivery

• Acceptance Testing
• Demonstrations of system to customer that product
  meets requirements
• Beta testing by users
• Installation
• User training

9
Maintenance

• Different types of maintenance
• Bug fixes
• Adapting to new environments
• Responding to evolution in requirements
• 50 to 70 of resources spent on maintenance
  over lifetime of software!

10
The Big Questions

• How many times is each phase done?
• Waterfall models once
• Incremental/agile models several cycles
• Is a product released each time?
• What is each phase expected to produce?
• How do we know we are done?

11
The Big Questions

• How much time to schedule for each phase?
• Reasonable estimates of delivery time
• Allocation resources between different projects
• What do you do if you are not finished?
• Release less product?
• Request extension?

12
How long do phases take? (relatively)
design 15
coding 20
requirements engineering 10
specification 10
testing 45
13
Scheduling

• 40-20-40 rule
• 40 of time on requirements/design
• 20 on coding
• 40 on testing
• Must allocate sufficient time for requirements,
  design, and testingThe longer you wait to
  begin coding, the sooner you will
  finish. -Hans Van Vliet

14
The Waterfall Model
Feasibility study
Steps done sequentially
Requirements
Architectural design
Object design
Unit coding and testing
Integration coding and testing
Each phase completed before next begun
Acceptance Delivery
Maintenance
15
Waterfall Model Document Heavy

• Requirements stage ? Requirements
  Specification Document
• Formal list of functional and non-functional
  requirements for delivered system
• Sufficiently detailed to be understood by client,
  developers
• Treated like legal document agreed on by all

16
Waterfall Model Document Heavy

• Design stage ? Design Document
• Overall system architecture
• APIs for major modules
• Sufficiently detailed for all developers to
  unambiguously understand their role
• Implementation stage ? Testing Plan
• Lists of tests to be performed at each milestone
• Results of tests

17
Problems with the Waterfall Model

• Cannot separate phases easily
• Will always need to revisit previous steps
• Need to gather some requirements before
  determining feasibility
• Will find further questions about requirements
  during design
• Will modify design during implementation
• Will revisit all stages during maintenance

18
Always revisiting earlier phases
Phase
Integration testing
Acceptance testing
Implementation ( unit testing)
Design
Activity
Integration testing
4.7
43.4
26.1
25.8
Implementation ( unit testing)
6.9
70.3
15.9
6.9
49.2
34.1
10.3
6.4
Design
19
Expect to revisit earlier phases

• At each phase plan to revisit earlier phases
• Allocate time and meetings for this process
• When collecting requirements, ask if project
  still feasible
• When creating design, look for unresolved
  requirements issues
• When writing code, reevaluate design
• Plan to reevaluate entire system during
  maintenance

20
Modified Waterfall Model
Feasibility study
Requirements
Architectural design
Object design
Unit coding and testing
Integration coding and testing
Acceptance Delivery
Maintenance
21
Modified Waterfall Still Insufficient

• Cannot validate earliest phases until latest steps

Cant evaluate requirements until customer
acceptance testing
Requirements
Acceptance testing
Cant evaluate architecture until entire system
put together during integration
Architectural design
Integration testing
Object design
Unit testing
22
Biggest Problem Requirements

• Customers very bad at specifying all requirements
  verbally
• Customers, developers speak different languages
• Requirements are hard to understand until users
  can play with operational system
• In waterfall model, no operational system
  available until delivery
• Mistakes in requirements are the most expensive
  to correct

23
Iterative Development
24
Iterative Refinement

• Create multiple versions of product
• Perform entire development cycle several times
• Fast development cycle (weeks instead of months)
• Often includes risk analysis at each cycle
• Identification of possible failure points
• Consideration of alternatives

25
Prototypes

• First versions are prototypes
• Not released, or used in final version
• Can be code, mockup UI, etc.
• Evaluate prototype at end of each cycle
• Review it with clients
• Test it with users
• Use results to improve the understanding of the
  requirements

26
Sometimes called Spiral Model
27
Iterative Development Lowers Risk

• Better understanding of customer needs
• Major errors in requirements, design caught early
  (before release)
• Potential disadvantage
• Must throw away prototypes at end of each stage
  or final release will contain unreliable code
• May require more development time

28
Incremental Development

• Like iterative, but release product each cycle
• Can sell some product faster

Identification and Prioritization
Release 1
Release 2
29
Incremental Development

• Initial stage Determine and prioritize main
  features
• What features must be in every version for
  initial versions to sell?
• What additional features can be built on those
  features, and result in further sales?
• What upgrades would keep customers happy?
• Can reprioritize each cycle and add new feature
  based on user feedback

30
Iterative vs. Incremental Development

• Iterative
• Get the entire system working somewhat well
• Then improve features throughout the system
• Incremental
• Get some features of the system working perfectly
• Then add more features to the system

31
Iterative vs. Incremental Questions

• Incremental development only works if
• Can subdivide system into discrete features
• Dont need to have entire system working for some
  users to be interested
• Can easily release new features to existing
  customers
• True for online release
• Not true for shrinkwrapped/embedded software

32
Agile Models
33
Agile Manifesto

• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• Note More of a philosophy than an actual process

34
Why Agile Software Development?

• Waterfall model can be more management centered
  than developer centered
• Lots of time-consuming paperwork and reports
• Sticking to plans even if no longer viable
• Adversarial relationships with clients to
  preserve legal cover

35
Why Agile Software Development?

• Requirements can change quickly
• Much faster than waterfall-based systems can cope
  withThis can often take 6 to 12 months
• Major goal shorten development time
• Weeks instead of months
• Released in increments

Requirements
Coding and testing
Design
36
Agile Software Development

• Simplified requirements stage
• No attempt to determine requirements for entire
  system, just quickly develop requirements for
  next increment
• Prioritize features to make completion possible
  in limited time
• Immediate feedback available from customer,
  ideally on site

37
Agile Software Development

• Immediate implementation instead of design
• Knowledgeable, skilled, empowered developers with
  ability to write good code
• Automated testing tools used to speed up testing
  and continuously insure correctness
• Rework design after release to correct bad coding
  and make next increment easier (refactoring)

38
Agile Software Development
Customer provides short and simple requirements
for next increment
Refactoring to improve design
Prioritizerequirements
System and acceptance tests
Write and rununit tests
Implement
Delivery
39
Rapid Application Development

• Experienced SWAT (skilled workers with advanced
  tools) teams
• Automated testing, version control tools used to
  speed up development
• Developers empowered to make decisions on fly
• Time boxes fixed time periods for increment
• Usually 2 4 weeks
• Accomplish as much as possible within that time
• Deliver whatever is accomplished on time

40
Rapid Application Development

• Prioritization of features to insure most
  critical ones completed within time box (triage)
• MoSCoW designation of priorities
• Must haves top priority requirements
• Should haves highly desirable
• Could haves if time allows
• Wont haves will not be dont this increment

41
Dynamic Systems Delivery Model

• Overall development process based on RAD
• Additional phases
• Feasibility study (can we do this?)
• Feasibility report, development plan, quick
  prototype
• Business study (is there a market for this?)
• Post-project phase (how can we improve this?)
• Identify what worked well and what did not
• Ambassador Users and/or Facilitated Workshops
• Customers on call and/or focus groups available

42
Dynamic Systems Delivery Model
Feasibility Study
Business Study
Time box-based incremental development
Post-project evaluation
Customers/users
Prototype
43
Extreme Programming
44
13 Practices of Extreme Programming

• Whole team client part of the team
• Metaphor common analogy for the system
• The planning game, based on user stories
• Simple design
• Small releases (e.g. 2 weeks)
• Customer tests
• Pair programming

• Test-driven development tests developed first
• Design improvement (refactoring)
• Collective code ownership
• Continuous integration system always runs
• Sustainable pace no overtime
• Coding standards

45
XP Practices Customer Role

• Customer is part of the development team
• Cooperative, not adversarial relationship
• Should always be available to answer questions
  about requirements and to test system
• Ideally, on site in same room
• Should help develop test cases
• Should be empowered to make decisions

46
XP Practices Requirement Engineering

• Each increment is small release
• Generally implements single requirement
• Expressed as simple user story
• Role of users, system in simple scenario
• Fred wants to register for the MW 1000 section
  of CSIS 2610. He logs onto BANNER and tries to
  add it, but is told that it is closed. BANNER
  provides a list of open sections, which include
  one at MW 200. Fred is ok with that time, so he
  registers for that section.

47
XP Practices Design

• Keep design as simple as possible
• Simple models, simple architecture, simple code
• Minimizes possibility of error, makes change
  easier
• Design based on simple metaphors
• Class roster, list of courses being taken,
• Iterative design improvement
• Refactor design after increment to make next
  increment easier

48
XP Practices Coding and Testing

• Test-driven development
• Write tests first, then write code
• Test cases suggested by customer
• Continuous integration
• Regularly check to see if the system is on track
• Use automated testing tools to insure that any
  change does not break system

49
XP Practices Teamwork

• Pair programming
• All code is written with a co-pilot who can
  help correct code and suggest improvements
• Share single terminal
• Regularly swap roles
• Collective code ownership
• Everyone can modify any code in project
• Coding standards
• Standardized variable naming, spacing, etc. for
  universal readability

50
XP Practices Realism

• The planning game
• Meet overall client needs one increment at a time
• Design around 2-week increments
• Work at a sustainable pace
• No all nighters, no superheros
• Overwork ultimately decreases productivity

51
Concerns About Agile/XP Development

• Available empowered customer may not be
  realistic
• Decision makers time too valuable to stay on
  site
• No overall plan for architecture to meet all
  needs
• Current design only based on current increment
• Refactoring for next increment may become time
  consuming
• Knowledge lives in developers heads, not on paper
• What if someone leaves?
• Mollified by pair programming, collective code
  ownership
• Collective coding little individual
  responsibility
• Who insures a specific requirement is met?

52
SoWhich process to choose?

• Waterfall good choice for small systems whose
  requirements can be fully understood before any
  design or coding
• Spiral good choice for larger systems with vague
  requirements and many alternatives for designing
  and coding
• Agile good choice for systems something
  verysmall but useful can be created and then
  expanded upon in small increments

53
Often combine different models

• Example Client-server web site to sell used
  textbooks

Web server
Web pages
Textbook database
54
Often combine different models

• Risk analysis
• What is known? What requires more information?

Web server
Web pages
Textbook database
Low risk very similar to other e-commerce sites,
can use similar code or buy off shelf
High risk not sure what interfaces should look
like, site will fail if customers do not find
usable
55
Often combine different models

• Use iterative/agile model to develop web page UI
• Once stabilized, use simple waterfall for rest

Define basic requirements for site, initial site
design
Implement prototype of pages
Implement database and server software
Release
User testing of prototype, user stories for
missing features
Redesign pages and site structure
56
Often combine different models

• Use modified waterfall to develop initial version
• Use agile development to release upgrades quickly

Initial version of web site created
Released to customers
Get user feedback about site
Determine most needed bug fixes and additional
features
Design and implement changes