Informatics 43
Introduction to Software Engineering
Lecture 8-2
November 19, 2015
Emily Navarro
Duplication of course material for any commercial purpose without the explicit written
permission of the professor is prohibited.
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 1
Today’s lecture
• More Software Process Models
–
–
–
–
–
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
• Quiz 6 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 2
Today’s lecture
• More Software Process Models
–
–
–
–
–
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
• Quiz 6 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 3
Processes as a Remedy
• Software is engineered via a defined process
– Cover all steps from initial idea and requirements to delivery,
maintenance, and final retirement
– Make sure we do the right things/we do things right
– Make sure we do not forget to do anything
– Different processes for different kinds of software
• Not a silver bullet [Brooks “No Silver Bullet”]
– Software is still intrinsically difficult to deal with
– Processes help, but cannot guarantee anything
Remember: People + Processes + Tools  Product
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 4
Processes
• Elements
– Activities (“Phases”)
– Artifacts
• Requirements document, design document, code, test cases…
– Resources
• People (their time and their cost)
• Tools (their time and their cost)
• Relationships between the elements
– Precedence, requires, provides, refines to, …
• Constraints
– Time
– Cost
– Qualities (repeatable process?)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 5
Software Life Cycle Models
•
•
•
•
•
•
•
•
•
Build-and-fix
Waterfall
Rapid prototyping
Incremental
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
A software life cycle model is a high-level process
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 6
Software Life Cycle Models
•
•
•
•
•
•
•
•
•
Build-and-fix
Waterfall
Rapid prototyping
Incremental
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
Covered in Lecture 8-1
A software life cycle model is a high-level process
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 7
Today’s lecture
• More Software Process Models
–
–
–
–
–
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
• Quiz 6 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 8
Spiral
Risk
analysis
Risk
analysis
Risk
analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 9
Each loop through the spiral…
• Identify a high-risk sub-problem or aspect
• Resolve the risk (as far as possible)
• Verify
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 10
Spiral
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 11
Spiral
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 12
Spiral
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 13
Spiral
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 14
Spiral
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 15
Spiral
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 16
Spiral
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 17
Spiral
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 18
Spiral
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 19
Software Risks: Some of Boehm’s Top 10
Risk
Risk Management Techniques
Personnel shortfalls
Staff with top talent, job matching,
morale building
Unrealistic schedules and budgets
Detailed cost/schedule estimation, reuse,
incremental development
Developing the wrong software functions
User surveys, prototyping
Continuing stream of software changes
Information hiding, incremental
development
Shortfalls in externally furnished
components
Compatibility analysis
Shortfalls in externally performed tasks
Reference checking, competitive design
or prototyping
Adapted from Hans Schaefer’s “Software Risk Management: A Calculated Gamble”
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 20
Full Spiral
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 21
So…
• What is it good for? (strengths)
• What is it bad for? (weaknesses)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 22
So…
• What is it good for? (strengths)
– Large, expensive, complicated projects
– New projects with uncertain, complex requirements
• What is it bad for? (weaknesses)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 23
So…
• What is it good for? (strengths)
– Large, expensive, complicated projects
– New projects with uncertain, complex requirements
• What is it bad for? (weaknesses)
– Small projects
– Developers have to be competent at risk analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 24
Today’s lecture
• More Software Process Models
–
–
–
–
–
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
• Quiz 6 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 25
Rational Unified Process
• Influential, best practices of its time (1990s, Object-Oriented
SE)
• More realistic depiction of
– The non-discrete nature of SE
– The need to have flexibility/adaptability in the process itself
– The interplay of
• Processes
• Time
• Various SE activities over time
– Much more…
• Workflows, Activities, Artifacts, Workers…
• Makes more sense if you are a project manager…
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 26
The RUP Model
Phases
Process Workflows
Inception
Elaboration
Construction
Business Modeling
In an iteration,
you walk
Transition all
through
workflows
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Workflows
group
activities
logically
SDCL
Software Design and
Collaboration Laboratory
Environment
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
Iterations
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 27
RUP Workflow: Architectural Analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 28
RUP Workflow: Analysis & Design
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 29
The steps of use-case-analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 30
So…
• What is it good for? (strengths)
• What is it bad for? (weaknesses)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 31
So…
• What is it good for? (strengths)
– Risk-driven, incremental
– Lots of tool support
– Provides a lot of guidance
• What is it bad for? (weaknesses)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 32
So…
• What is it good for? (strengths)
– Risk-driven, incremental
– Lots of tool support
– Provides a lot of guidance
• What is it bad for? (weaknesses)
– Complicated (need a process expert to implement it)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 33
Today’s lecture
• More Software Process Models
–
–
–
–
–
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
• Quiz 6 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 34
Open-Source Software (OSS): Classic Version
• Source code is freely available and (usually) re-distributable
• Many contributors working in a distributed manner
–
–
–
–
–
Coders
Bug finders
Documenters
Project leadership
Often volunteers
• Heavy reliance on software tools
– The web and email
– Version control and repositories, bug trackers
• Scales up amazingly well
• Where do they find the time?
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 35
OSS Underlying Philosophy
“This is a way to optimize the usage of the work, the value
humanity as a whole gets from it. At the cost, of course, of the
ability of the producer to capture value.”
-Marijn Haverbeke (http://marijnhaverbeke.nl/blog/sustainable-maintenance.html)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 36
OSS Classic: Only Two Phases
• First, develop the initial version
– Usually one or a small number of developers
• Second, maintain (evolve!)
– Users become co-developers (co-maintainers!)
– Report and correct defects
• Corrective maintenance
– Enhance and add new functionality
• Perfective maintenance
– Port to a different environment
• Adaptive maintenance
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 37
OSS Success Stories
• Operating systems
– Linux
• Web browser
– Firefox
• Compiler
– gcc
• Web server
– Apache
• Database
– MySQL
• Development environment
– Eclipse
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 38
Open Source: The Corporate Version
• Use open source software
– Saves money
– Avoids “lock-in”
– Provides “business agility”
• Sponsor open source projects
– Provide funding, developer resources, infrastructure, management
– Company benefits from the resulting product and the “brownie
points”
• Examples
– Android
– Alliance for Open Media
• Mozilla, Microsoft, Google, Cisco, Intel, Amazon, Netflix
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 39
OSS has changed things…
• First step in a typical software process: look for open source
components to fulfill requirements
• Branching out
– Education
– Filmmaking
– Furniture
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 40
OSS Video
• https://www.youtube.com/watch?v=Tyd0FO0tko8
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 41
So…
• What is it good for? (strengths)
• What is it bad for? (weaknesses)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 42
So…
• What is it good for? (strengths)
– Software that benefits developers (oftentimes extends to the public
at large)
– Accessibility of open source software results in a huge user base,
which also results in huge advances
– Some of the greatest minds, motivated and working together to solve
hard problems, in which they themselves are the users, can result in
huge advances (novel features, better quality code)
“Given enough eyeballs, all bugs are shallow.” – Eric Raymond
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 43
So…
• What is it good for? (strengths)
– Software that benefits developers (oftentimes extends to the public
at large)
– Accessibility of open source software results in a huge user base,
which also results in huge advances
– Some of the greatest minds, motivated and working together to solve
hard problems can result in huge advances (novel features, better
quality code)
• What is it bad for? (weaknesses)
–
–
–
–
SDCL
Proprietary software
Software with strict requirements and/or tight deadlines
Technical support/maintenance can be iffy
Developers are often not compensated financially
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 44
Today’s lecture
• More Software Process Models
–
–
–
–
–
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
• Quiz 6 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 45
Extreme Programming (XP)
• More “extreme” reaction to Waterfall, other heavyweights…
• Kent Beck (also Ron Jeffries)
– Software engineering consists of
• Listening, Testing, Coding, Designing
– Based on
• Values of Simplicity, Communication, Feedback, Courage
– Works by
• Simple practices, such as bringing/keeping the team together
• Just enough feedback to know where you are
• Just enough (and just in time) “heavier” activities
• More “programmer welfare” than other process models…
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 46
XP Practices and Principles (I)
• Whole team
– Customer on site, part of the team
• Planning game
– Once per iteration
• Small releases
• Customer tests
• Simple design
– “Simple is best”
– Refactoring encouraged
• Pair programming
• Test-driven development
• Design improvement
– Refactor whenever, wherever possible
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 47
XP Practices and Principles (II)
• Continuous integration
– Everyone works on the most recent version of the code
• Collective code ownership
– Anyone can change any part of code
– All team members work on all development activities
• Coding standards
– Promotes shared understanding
• Metaphor
– A “story” about the system
• Sustainable pace
– 40-hour work weeks
– short iterations
• Open space
– Especially for pair programming
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 48
XP Process Steps
• Determine the desired features (stories)
– Estimate time/cost (effort) per feature
– Client can help determine order of development
• Story prioritization
• Stories further refined into development tasks
• Implement/deliver each task
– Typically using…
• Test-driven development
• Pair programming
• Follow values and principles
– (See previous slides)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 49
XP Philosophies (I)
• Rapid, fine feedback
– Frequent testing
– On-site customer
– Pair programming
• Continuous process
– Continuous integration
– Merciless refactoring
– Small, frequent releases
From Glenn Vanderburg, Delphi Consultants
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 50
XP Philosophies (II)
• Shared understanding
–
–
–
–
–
Planning game
Simple design
System metaphor
Collective code ownership
Coding conventions
• Developer welfare
– Forty hour week
From Glenn Vanderburg, Delphi Consultants
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 51
SimSE XP Demo
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 52
Today’s lecture
• More Software Process Models
–
–
–
–
–
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
• Quiz 6 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 53
From XP to Agile
• Agile includes and evolved from
– Extreme Programming
– Scrum, Crystal, others
• The Agile Manifesto (2001)
– “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
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 54
Some Agile Principles
• Welcome change in requirements
– Even late in development
– Harness change for competitive advantage
• Business people and developers work together daily
throughout the project
– Stand-up meetings
• Build projects around motivated individuals
– Give them the environment and support they need
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 55
More Agile Principles
• Best method of conveying information during development is
face-to-face conversation
– Informal communication
– Stand-up meetings
• Documentation is just a means to an end
– Do only the necessary amount
– Source code is the biggest part of the documentation
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 56
Some Agile Principles
• Continuous delivery: deliver working software frequently to
satisfy the customer
Figure credit: R. Souza, C. Chavez, and R. Bittencourt. Rapid releases and patch backouts: A software analytics approach.
Software, IEEE, 32(2):89–96, Mar 2015.
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 57
Continuous delivery
• Tools
– Integration repositories
– Automated testing
• Methods
– Timeboxing (time-based releases)
– Sprints (feature-based releases)
• For each release, tradeoffs between
– Schedule
– Features
– Quality
• Examples
–
–
–
–
SDCL
Firefox/Chrome: 6-week release cycle
Google+: 36 hour release cycle
Facebook: 2 releases per day
Etsy.com: 36 releases per day (11 commits per release)
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 58
A closer look at one agile process (Scrum)
• https://www.youtube.com/watch?v=XU0llRltyFM
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 59
Some real life agile examples
• https://www.youtube.com/watch?v=szr0ezLyQHY
• https://www.youtube.com/watch?v=q1RqhRcPJZ0
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 60
So…
• What is it good for? (strengths)
• What is it bad for? (weaknesses)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 61
So…
• What is it good for? (strengths)
–
–
–
–
Customer satisfaction
Adaptable to changing circumstances
Good for projects with unclear, changing requirements
Good for small teams
• What is it bad for? (weaknesses)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 62
So…
• What is it good for? (strengths)
–
–
–
–
Customer satisfaction
Adaptable to changing circumstances
Good for projects with unclear, changing requirements
Good for small teams
• What is it bad for? (weaknesses)
–
–
–
–
SDCL
Lack of documentation
Unstable requirements
Bad for projects with large teams
Bad for projects in which customer involvement is not possible
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 63
A Comparison of Life Cycle Models (Highlights)
Model
Strengths
Weaknesses
Build-and-Fix
Fine for small programs that do
not require much maintenance
Totally unsatisfactorily for nontrivial
programs
Waterfall
Disciplined approach
Document driven
Delivered product may not meet
client’s needs
Rapid
Prototyping
Ensures that delivered product
meets client’s needs
A need to build twice
Cannot always be used
Incremental
Maximizes early return on
investment
Requires open architecture
May degenerate into build-and-fix
Spiral
Incorporates features of all the
above models
Developers have to be competent
at risk-analysis
RUP
Risk-driven, incremental, lots of
guidance
Complicated, requires a process
expert
OSS
Rapid advances, high-quality
software
Developers do not benefit
financially
Agile/XP
High customer satisfaction
Adaptable to change
Lack of documentation
Requires small teams and customer
involvement
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 64
Today’s lecture
• More Software Process Models
–
–
–
–
–
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
• Quiz 6 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 65
Quiz 6
• Readings:
– Windows 10 article
– Gamasutra article
• Discussion:
– SimSE exercise (week 9)
• Lecture:
– Know characteristics, strengths, and weaknesses of all process models
covered through today
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 66
Reminder
• Homework 3A due Tuesday 11/24, 11:55pm
– No late assignments accepted except for extenuating circumstances
as described in first lecture
– Don’t forget your github username at the top of your document
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 67