Informatics 43
Introduction to Software Engineering
Lecture 7-1
May 12, 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
• Midterm answers
• More Software Process Models
• Quiz 4 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 2
Today’s lecture
• Midterm answers
• More Software Process Models
• Quiz 4 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 3
Today’s lecture
• Midterm answers
• More Software Process Models
• Quiz 4 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 4
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 5
Processes
• Elements
– Activities (“Phases”)
– Artifacts
• E.g., requirements document, design document, code, test cases…
• Can include process specifications
– 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 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
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
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 5-2
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 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
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 25
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 26
RUP Workflow: Architectural Analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 27
RUP Activity: Use Case Analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 28
The steps of use-case-analysis
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 29
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 30
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 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)
– Complicated (need a process expert to implement it)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 32
Open-Source Software (OSS)
• 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 33
OSS: 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 34
OSS Success Stories
• Operating systems
– Linux
• Web browser
– Firefox
• Compiler
– gcc
• Web server
– Apache
• Database
– MySQL
• Healthcare
– Mirth
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 35
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 36
So…
• What is it good for? (strengths)
– Software that benefits developers (oftentimes extends to the public
at large)
– Some of the greatest minds, motivated and working together to solve
hard problems can result in huge advances
• What is it bad for? (weaknesses)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 37
So…
• What is it good for? (strengths)
– Software that benefits developers (oftentimes extends to the public
at large)
– Some of the greatest minds, motivated and working together to solve
hard problems can result in huge advances
• What is it bad for? (weaknesses)
– Proprietary software
– Software with strict requirements and/or tight deadlines
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 38
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 39
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 40
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 41
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 42
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 43
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 44
XP in Action
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 45
Test-Driven Development
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 46
SimSE XP Demo
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 47
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 48
Some Agile Principles
• Satisfy the customer
– Through early and continuous delivery of valuable software
• Welcome change in requirements
– Even late in development
– Harness change for competitive advantage
• Deliver working software frequently
– In weeks or a couple of months
• Timeboxing
• Sprints
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 49
More Agile Principles
• 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
• 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 50
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 51
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 52
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 53
A Comparison of Life Cycle Models
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
XP
Customer involvement and frequent
releases promote customer satisfaction
Cannot be used for large teams
Requires large time commitment by
customer
Spiral
Incorporates features of all the above
models
Developers have to be competent at riskanalysis
RUP
Risk-driven, incremental, lots of
guidance
Complicated, requires a process expert
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 54
Some real life 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 55
Today’s lecture
• Midterm answers
• More Software Process Models
• Quiz 4 study guide
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 56
Quiz 4
• Textbook:
– Section 4.1
• Discussion:
– SimSE exercise
• Lecture:
– Know characteristics, strengths, and weaknesses of
•
•
•
•
•
SDCL
Spiral
Rational Unified Process (RUP)
Open Source Software (OSS)
Extreme Programming (XP)
Agile
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 57
Reminder
• Homework 2A due tonight, 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 58