SW Process and Agile Software Development - rev2
30
CSE516 – Science for Society Software Process & Agile Software Development April 25, 2014 Ilchul Yoon ([email protected] )
Transcript of SW Process and Agile Software Development - rev2
CSE516 – Science for Society
Software Process & Agile Software Development
April 25, 2014Ilchul Yoon ([email protected])
Software
l A textbook descriptionl Instructions (computer programs) that when executed provide
desired features, function, and performance; l Data structures that enable the programs to adequately
manipulate information and l Documentation that describes the operation and use of the
programs.
l Differences to hardware?l Developed or Craftedl No wear-outl Custom-built, almost always
l A textbook descriptionl Instructions (computer programs) that when executed provide
desired features, function, and performance; l Data structures that enable the programs to adequately
manipulate information and l Documentation that describes the operation and use of the
programs.
l Differences to hardware?l Developed or Craftedl No wear-outl Custom-built, almost always
2
Software Engineering
l Fritz Bauer (1969)l The establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real machines.
l The IEEE definition (1993)l (1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).
l Fritz Bauer (1969)l The establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real machines.
l The IEEE definition (1993)l (1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).
3
Software Engineering Layers
methodsmethods
toolstools
4
a “quality” focusa “quality” focus
process modelprocess model
methodsmethods
Software Process?
Communication Deployment
5
Planning
Modeling
Construction
Software Myths
l Belief looks reasonable in software development, but misleading stakeholders
l Examplesl Management
l Got behind schedule. Let’s add more programmers and catch up.l Outsource to a third party and relax.
l Customerl Statement of objectives is sufficient to start writing programs.l Software is flexible so can be easily changed later.
l Practitioner l Once completed writing a working program, the work is done.l Until program works, we cannot assess its quality.l Applying software engineering will make the entire process slow.
l Belief looks reasonable in software development, but misleading stakeholders
l Examplesl Management
l Got behind schedule. Let’s add more programmers and catch up.l Outsource to a third party and relax.
l Customerl Statement of objectives is sufficient to start writing programs.l Software is flexible so can be easily changed later.
l Practitioner l Once completed writing a working program, the work is done.l Until program works, we cannot assess its quality.l Applying software engineering will make the entire process slow.
6
Software Process
l A collection of work activities, actions, and tasks relevant to software developmentl Framework activities + Umbrella activities
l Process flowl Linearl Iterativel Evolutionaryl Parallel
l A collection of work activities, actions, and tasks relevant to software developmentl Framework activities + Umbrella activities
l Process flowl Linearl Iterativel Evolutionaryl Parallel
7
Prescriptive Models
l Prescriptive process models advocate an orderlyapproach to software engineering
l That leads to a few questions …l If prescriptive process models strive for structure and order,
are they inappropriate for a software world that thrives on change?
l Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?
l Prescriptive process models advocate an orderlyapproach to software engineering
l That leads to a few questions …l If prescriptive process models strive for structure and order,
are they inappropriate for a software world that thrives on change?
l Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?
8
The Waterfall Model
l Classicl Still in use for military domains
l Problems?l Development is not-really sequential.l Unclear requirements at the beginningl Customers should wait under code generation.
9
l Classicl Still in use for military domains
l Problems?l Development is not-really sequential.l Unclear requirements at the beginningl Customers should wait under code generation.
Incremental Process Model
l Produce deliverable increments in each iterationl First increments is often core
productl Get customer feedback
l Useful whenl Staffing problem exists
l Produce deliverable increments in each iterationl First increments is often core
productl Get customer feedback
l Useful whenl Staffing problem exists
10
Evolutionary Process Model
Feedback Milestones
l Prototyping l Quick designl Mainly for requirements
elicitationl Problems?
l Tempted to keep it.
l Spiral Modell Risk-driven developmentl Anchor point milestonesl Teams define spiral objectivesl Adjustable for maintenancel Realistic for large-scale project
11
Risk analysis
l Prototyping l Quick designl Mainly for requirements
elicitationl Problems?
l Tempted to keep it.
l Spiral Modell Risk-driven developmentl Anchor point milestonesl Teams define spiral objectivesl Adjustable for maintenancel Realistic for large-scale project
Concurrent Models
l State transition model for process elementsl can be defined for activities,
actions, or tasks.
12
The Unified Process (UP)
l A use-case driven, architecture-centric, iterative and incremental software process closely aligned with the Unified Modeling Language (UML)l Sometimes, called Rational Unified Process (RUP) after the
Rational Corporation
l Discussion started from UMLl Combined best features of object-oriented analysis and design
methodsl De facto industry standard for OOSDl However, lacks of process framework to guide teams to play
with UML
l A use-case driven, architecture-centric, iterative and incremental software process closely aligned with the Unified Modeling Language (UML)l Sometimes, called Rational Unified Process (RUP) after the
Rational Corporation
l Discussion started from UMLl Combined best features of object-oriented analysis and design
methodsl De facto industry standard for OOSDl However, lacks of process framework to guide teams to play
with UML
13
UP Phasesl Inception
l Requirement gatheringl Rough architecturel Define initial use cases
l Elaborationl Refine use cases, expand architecture
l Constructionl Make use cases operational for end usersl Unit & integration test based on use cases
l Transitionl Beta-testing and feedback collection, support doc. creation
l Productionl Monitoring and maintenance
l Inceptionl Requirement gatheringl Rough architecturel Define initial use cases
l Elaborationl Refine use cases, expand architecture
l Constructionl Make use cases operational for end usersl Unit & integration test based on use cases
l Transitionl Beta-testing and feedback collection, support doc. creation
l Productionl Monitoring and maintenance
14
UP Phases and Typical Work Amount
Phases
15#1 #2 ……….. #niterations
workflows (tasks)
Manifesto for Agile Software Development
16
What is “Agility”?
l Agile: readiness for motion, nimbleness, activity, dexterity in motion
l Agilityl The ability to both create and respond to change in order to
profit in a turbulent business environmentl Companies need to determine the amount of agility they need to be
competitive
l Chaordicl Exhibiting properties of both chaos and order
l The blend of chaos and order inherent in the external environment and in people themselves, argues against the prevailing wisdom about predictability and planning
l Things get done because people adapt, not because they slavishly follow processes
l Agile: readiness for motion, nimbleness, activity, dexterity in motion
l Agilityl The ability to both create and respond to change in order to
profit in a turbulent business environmentl Companies need to determine the amount of agility they need to be
competitive
l Chaordicl Exhibiting properties of both chaos and order
l The blend of chaos and order inherent in the external environment and in people themselves, argues against the prevailing wisdom about predictability and planning
l Things get done because people adapt, not because they slavishly follow processes
17
Agility and the Cost of Change
18
Agility Principles
l Highest priority on customer satisfactionl Admit requirements changes, even late in developmentl Deliver “working software” frequently
l a couple of weeks or a couple of months – prefer shorter scalel Measure of progress
l Work together with customers throughout the projectl Trust individuals and self-organizing teamsl Constant face–to–face conversationl Attention to technical excellence and good designl Simple architecturel Tune
l Highest priority on customer satisfactionl Admit requirements changes, even late in developmentl Deliver “working software” frequently
l a couple of weeks or a couple of months – prefer shorter scalel Measure of progress
l Work together with customers throughout the projectl Trust individuals and self-organizing teamsl Constant face–to–face conversationl Attention to technical excellence and good designl Simple architecturel Tune
19
Human Factors
l Anyway…. Human develops software.l Key traits required for the agile team and members:
l Competence – talent, skills, and knowledgel Common focus – goal-drivenl Collaboration – for task executionl Decision-making ability – autonomyl Fuzzy problem-solving ability – welcoming changesl Mutual trust and respectl Self-organization
l Anyway…. Human develops software.l Key traits required for the agile team and members:
l Competence – talent, skills, and knowledgel Common focus – goal-drivenl Collaboration – for task executionl Decision-making ability – autonomyl Fuzzy problem-solving ability – welcoming changesl Mutual trust and respectl Self-organization
20
An Agile Process
l Customer-driven (scenarios, user stories, feedback, test)l Sequence of short iterationsl Iterative and deliver multiple ‘software increments’l Put emphasis on construction activities
l XPl Scrum
l Customer-driven (scenarios, user stories, feedback, test)l Sequence of short iterationsl Iterative and deliver multiple ‘software increments’l Put emphasis on construction activities
l XPl Scrum
21
Extreme Programming (XP)
l The most widely used agile process, originally proposed by Kent Beck
l Valuesl Communication – informal face-to-face l Simplicity – design for today, but in an efficient wayl Feedback – from… software, customer, team membersl Courage – at changesl Respect – between all stakeholders and team members
l Context l Prefer Object-Oriented development paradigml Consist of practices in four framework activities
l The most widely used agile process, originally proposed by Kent Beck
l Valuesl Communication – informal face-to-face l Simplicity – design for today, but in an efficient wayl Feedback – from… software, customer, team membersl Courage – at changesl Respect – between all stakeholders and team members
l Context l Prefer Object-Oriented development paradigml Consist of practices in four framework activities
22
Extreme Programming (XP)
l XP Planning (or planning game)l Start with “user stories” (listening, use of index cards)l Story assessment and cost assignmentl Story grouping for a deliverable incrementl Make commitment on delivery datel Use “project velocity”, after the first increment. Consider:
l Number of stories implementedl Cost assigned
l Useful for estimating subsequent delivery dates for other incrementsl Useful for determining over-commitment for stories (may adjust)
l XP Planning (or planning game)l Start with “user stories” (listening, use of index cards)l Story assessment and cost assignmentl Story grouping for a deliverable incrementl Make commitment on delivery datel Use “project velocity”, after the first increment. Consider:
l Number of stories implementedl Cost assigned
l Useful for estimating subsequent delivery dates for other incrementsl Useful for determining over-commitment for stories (may adjust)
23
Extreme Programming (XP)
l XP Designl Follows the KIS (Keep It Simple) principle
l Encourage the use of CRC cardsl Class, Responsibility, and Collaborator
l For difficult design problems, create “spike solutions” l Design prototype (risk management)
l Encourages merciless “refactoring”l an iterative refinement of the internal program designl Design optimization
l Design artifacts are minimal and considered transient
l XP Designl Follows the KIS (Keep It Simple) principle
l Encourage the use of CRC cardsl Class, Responsibility, and Collaborator
l For difficult design problems, create “spike solutions” l Design prototype (risk management)
l Encourages merciless “refactoring”l an iterative refinement of the internal program designl Design optimization
l Design artifacts are minimal and considered transient
24
Extreme Programming (XP) – CRC card examples
25
Extreme Programming (XP)
l XP Codingl Recommends the construction of a unit test for a story before
coding commencesl Encourages “pair programming”l Continuously integrate with other work and run smoke testing
l XP Testingl All unit tests are executed daily
l Helps regression testing at code modificationl Combined into “universal testing suite”
l Acceptance tests (customer test) l Focus on overall (visible and reviewable) features and functionality
l XP Codingl Recommends the construction of a unit test for a story before
coding commencesl Encourages “pair programming”l Continuously integrate with other work and run smoke testing
l XP Testingl All unit tests are executed daily
l Helps regression testing at code modificationl Combined into “universal testing suite”
l Acceptance tests (customer test) l Focus on overall (visible and reviewable) features and functionality
26
Extreme Programming (XP)
unit t est cont inuous int egrat ion
accept ance t est ing
pair programming
Release
user st ories values accept ance t est crit eria it erat ion plan
simple design CRC cards
spike solut ions prot ot ypes
refact oring
sof tware incrementproject velocit y computed
27
unit t est cont inuous int egrat ion
accept ance t est ing
pair programming
Release
user st ories values accept ance t est crit eria it erat ion plan
simple design CRC cards
spike solut ions prot ot ypes
refact oring
sof tware incrementproject velocit y computed
Extreme Programming (XP)
28
Scrum
l Originally proposed bySchwaber and Beedle [2001]
l Scrum - distinguishing featuresl Partition development work into packetsl On-going testing and documentation during constructionl Start with user stories (called backlogs)l Release in “sprints” derived from backlogsl Very short meetings (even without chairs) and timeboxing
l Originally proposed bySchwaber and Beedle [2001]
l Scrum - distinguishing featuresl Partition development work into packetsl On-going testing and documentation during constructionl Start with user stories (called backlogs)l Release in “sprints” derived from backlogsl Very short meetings (even without chairs) and timeboxing
29
After 10 years after Agile Manifesto…
The agile movement is in some ways a bit like a teenager: very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times cocky and arrogant. But I have no doubts that it will mature further, become more open to the outside world, more reflective, and also therefore more effective.
- Philippe Kruchten
30
The agile movement is in some ways a bit like a teenager: very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times cocky and arrogant. But I have no doubts that it will mature further, become more open to the outside world, more reflective, and also therefore more effective.
- Philippe Kruchten
