2. UNIT I - SOFTWARE PROCESS
AND AGILE DEVELOPMENT
Introduction to Software Engineering,
Software Process, Perspective and Specialized
Process Models –Introduction to Agility-Agile
process-Extreme programming-XP Process.
3. SOFTWARE
Software is: (1) instructions (computer programs) that
when executed provide desired features, function, and
performance; (2) data structures that enable the
programs to adequately manipulate information, and (3)
descriptive information in both hard copy and virtual
forms that describes the operation and use of the
programs.
4. SOFTWARE - Characteristics
Software is developed or engineered; it is not
manufactured in the classical sense.
Software doesn’t “wear out.”
Although the industry is moving toward
component-based construction, most software
continues to be custom built.
5. SOFTWARE – Applications
System software: Collection of programs
written to service other programs.
Example: Compilers, Editors
Application software—Stand-alone programs
that solve a specific business need.
Example: Online ticket booking
6. SOFTWARE – Applications
Engineering/scientific software: Applications
range from astronomy to volcanology, from
automotive stress analysis to space shuttle
orbital dynamics, and from molecular biology
to automated manufacturing.
7. SOFTWARE – Applications
Embedded software: resides within a product or system.
Example: ATM Systems
Product-line software: designed to provide a specific
capability for use by many different customers
Example: Word processing, Spreadsheets
8. SOFTWARE – Applications
Web applications: a set of linked hypertext files that
present information using text and limited graphics.
Artificial intelligence software: Applications within
this area include robotics, expert systems, pattern
recognition (image and voice), artificial neural
networks, theorem proving, and game playing
9. SOFTWARE – Applications
New Challenges:
Open-world computing - to develop systems and
application software that will allow mobile devices,
personal computers
Netsourcing - targeted end-user markets worldwide.
Open source - a growing trend that results in
distribution of source code for systems applications
10. SOFTWARE ENGINEERING
Definition(IEEE):
Software Engineering: (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).
12. SOFTWARE ENGINEERING
Layers – Quality:
an organizational commitment to quality.
Total quality management and Six Sigma
13. SOFTWARE ENGINEERING
Layers – Process:
The glue that holds the technology layers together and
enables rational and timely development of computer
software.
Process defines a framework that must be established for
effective delivery of software engineering technology.
the basis for management control of software projects
14. SOFTWARE ENGINEERING
Layers – Methods:
Tasks: communication, requirements analysis,
design modeling, program construction, testing,
and support.
15. SOFTWARE ENGINEERING
Layers – Tools:
To provide automated or semi automated support
for the process and the methods.
A system for the support of software development,
called computer-aided software engineering
16. SOFTWARE PROCESS
Process: A collection of activities, actions, and
tasks that are performed when some work product
is to be created.
Activity: to achieve a broad objective (e.g.,
communication with stakeholders)
Action: encompasses a set of tasks that produce a
major work product
17. SOFTWARE PROCESS
Process: A collection of activities, actions, and
tasks that are performed when some work
product is to be created.
Task: Small, but well-defined objective that
produces a tangible outcome. (e.g., conducting a
unit test)
19. SOFTWARE PROCESS
Activities – Communication:
To communicate and collaborate with the
customer
To understand stakeholders’ objectives for the
project and to gather requirements that help define
software features and functions.
20. SOFTWARE PROCESS
Activities – Planning:
Software project plan—defines the software
engineering work by describing the technical tasks
to be conducted, the risks that are likely, the
resources that will be required, the work products
to be produced, and a work schedule.
21. SOFTWARE PROCESS
Activities – Modeling:
Creating models to better understand software
requirements and the design that will achieve those
requirements.
22. SOFTWARE PROCESS
Activities – Construction:
This activity combines code generation and the
testing that is required to uncover errors in the
code.
23. SOFTWARE PROCESS
Activities – Deployment:
The software is delivered to the customer who
evaluates the delivered product and provides
feedback based on the evaluation.
24. Objectives of Software
Satisfy users Requirements
High reliability
Low Maintenance Costs
Delivery on time
Low production costs
High Performance
Ease of reuse
25. SOFTWARE PROCESS
Software engineering process framework
activities are complemented by a number of
umbrella activities.
To help a software team manage and control
progress, quality, change, and risk.
26. SOFTWARE PROCESS
Software engineering process framework
activities are complemented by a number of
umbrella activities.
To help a software team manage and control
progress, quality, change, and risk.
27. SOFTWARE PROCESS
Umbrella activities:
Software project tracking and control - allows the
software team to assess progress against the project
plan and take any necessary action to maintain the
schedule.
Risk management - assesses risks that may affect the
outcome of the project or the quality of the product.
28. SOFTWARE PROCESS
Umbrella activities:
Software quality assurance - defines and conducts the
activities required to ensure software quality.
Technical reviews - assesses software engineering
work products in an effort to uncover and remove
errors before they are propagated to the next activity.
29. SOFTWARE PROCESS
Umbrella activities:
Measurement - defines and collects process, project,
and product measures that assist the team in delivering
software that meets stakeholders’ needs.
Software configuration management - manages the
effects of change throughout the software process.
30. SOFTWARE PROCESS
Umbrella activities:
Reusability management—defines criteria for work
product reuse (including software components) and
establishes mechanisms to achieve reusable components.
Work product preparation and production—encompasses
the activities required to create work products such as
models, documents, logs, forms, and lists.
31. SOFTWARE PROCESS
Process Model:
a process was defined as a collection of work
activities, actions, and tasks that are performed
when some work product is to be created.
A framework or model that defines their
relationship with the process and with one another
33. SOFTWARE PROCESS
ASSESSMENT
Capability Maturity Model(CMM):
CMM is used in assessing how well an
organization’s processes allow to complete and
manage new software projects.
34. SOFTWARE PROCESS
ASSESSMENT
Capability Maturity Model(CMM):
Level 1 – Initial: Few processes are defined and
individual efforts are taken.
Level 2 – Repeatable: Depending on earlier
successes of projects with similar applications
necessary process discipline can be repeated.
35. SOFTWARE PROCESS
ASSESSMENT
Capability Maturity Model(CMM):
Level 3 – Defined: The process is standardized,
document and followed.
Level 4 – Managed: Process and product are
quantitatively understood and controlled using
detailed measure.
36. SOFTWARE PROCESS
ASSESSMENT
Capability Maturity Model(CMM):
Level 5 – Optimizing: To plan and implement
change.
CMM is used for improving the software project.
37. Prescriptive Process Models
It is a useful structure to software engineering
work and have provided a reasonably effective
road map for software teams
Also known as Software Development Life
Cycle(SDLC) Model.
38. Prescriptive Process Models
Need:
Process model will bring the definiteness and
discipline in overall development process.
Every process model consists of definite entry and
exit criteria for each phase.
40. Prescriptive Process Models
Waterfall Model:
A linear-sequential life cycle model.
Each phase must be completed before the next
phase can begin and there is no overlapping in the
phases.
42. Prescriptive Process Models
Waterfall Model:
Requirement Gathering and analysis:
The basic requirements of the system must be
understood by software engineer – Analyst.
All these requirements are then well documented and
discussed further with customer, for reviewing.
43. Prescriptive Process Models
Waterfall Model:
Design:
It helps in specifying hardware and system
requirements and helps in defining the overall system
architecture.
Attributes: Data Structure, Software architecture,
Interface representation.
44. Prescriptive Process Models
Waterfall Model:
Coding or Implementation:
The design is translated into machine-readable
form.
Programs are developed in this phase.
45. Prescriptive Process Models
Waterfall Model:
Testing:
Focus on logical internals of software.
To uncover errors, fix the bugs and meet the
customer requirements.
46. Prescriptive Process Models
Waterfall Model:
Deployment and Maintenance:
The longest life cycle phase.
When the system is installed and put in practical use
then error may get introduced, correcting such errors
and putting it in use.
Enhancing system’s services
47. Prescriptive Process Models
Waterfall Model – Advantages:
Simple and easy to understand and use
Each phase has specific deliverables and a review
process.
Phases are processed and completed one at a time.
Works well for smaller projects where requirements
are very well understood
48. Prescriptive Process Models
Waterfall Model – Disadvantages:
No working software is produced until late during
the life cycle.
Cannot accommodate changing requirements.
Adjusting scope during the life cycle can end a
project.
49. Prescriptive Process Models
Incremental Process Model:
Iterative process starts with a simple implementation
of a small set of the software requirements
Iteratively enhances the evolving versions until the
complete system is implemented and ready to be
deployed
50. Prescriptive Process Models
Incremental Process Model – Iterative Model:
Iterative process starts with a simple implementation
of a small set of the software requirements
Iteratively enhances the evolving versions until the
complete system is implemented and ready to be
deployed
51. Prescriptive Process Models
Incremental Process Model – Iterative Model:
The basic idea behind this method is to develop a
system through repeated cycles (iterative) and in
smaller portions at a time (incremental).
53. Prescriptive Process Models
Incremental Process Model – Iterative Model:
During software development, more than one iteration of
the software development cycle may be in progress at the
same time.
Each subsequent release of the module adds function to the
previous release.
The process continues till the complete system is ready as
per the requirement.
54. Prescriptive Process Models
Incremental Process Model – Iterative Model:
rigorous validation of requirements, and verification
& testing of each version of the software against those
requirements within each cycle of the model.
A new technology is being used and is being learnt by
the development team while working on the project.
55. Prescriptive Process Models
Incremental Process Model – Iterative Model:
Advantages:
Some working functionality can be developed quickly and
early in the life cycle.
Results are obtained early and periodically.
Better suited for large and mission-critical projects.
During the life cycle, software is produced early which
facilitates customer evaluation and feedback.
56. Prescriptive Process Models
Incremental Process Model – Iterative Model:
Disadvantages:
More resources may be required.
System architecture or design issues may arise because not
all requirements are gathered in the beginning of the entire
life cycle.
Projects progress is highly dependent upon the risk
analysis phase.
57. Prescriptive Process Models
Incremental Process Model – RAD Model:
RAD - Rapid Application Development
It is based on prototyping and iterative development
with no specific planning involved.
A prototype is a working model that is functionally
equivalent to a component of the product.
59. Prescriptive Process Models
Incremental Process Model – RAD Model:
Business Modeling:
The business model for the product under
development is designed in terms of flow of
information and the distribution of information
between various business channels.
60. Prescriptive Process Models
Incremental Process Model – RAD Model:
Data Modeling:
Information gathered from business modeling is
used to define data objects that are needed for the
business.
61. Prescriptive Process Models
Incremental Process Model – RAD Model:
Process Modeling:
The process model for any changes or
enhancements to the data object sets is defined in
this phase.
62. Prescriptive Process Models
Incremental Process Model – RAD Model:
Application Generation:
The actual system is built and coding is done by
using automation tools to convert process and data
models into actual prototypes.
63. Prescriptive Process Models
Incremental Process Model – RAD Model:
Testing and Turnover:
The data flow and the interfaces between all the
components need to be thoroughly tested with complete
test coverage.
Since most of the programming components have already
been tested, it reduces the risk of any major issues.
64. Prescriptive Process Models
Incremental Process Model – RAD Model:
Advantages:
Changing requirements can be accommodated.
Productivity with fewer people in a short time.
Reduced development time.
Encourages customer feedback.
65. Prescriptive Process Models
Incremental Process Model – RAD Model:
Disadvantages:
Dependency on technically strong team members for
identifying business requirements.
Only system that can be modularized can be built
using RAD.
Requires user involvement throughout the life cycle.
66. Prescriptive Process Models
Evolutionary Process Model:
While developing the software systems, it is often
needed to make modifications in earlier
development phases or tasks sets.
In such cases, the iterative approach needs to be
adopted.
67. Prescriptive Process Models
Evolutionary Process Model – Prototyping:
Initially the requirement gathering is done
Prototype model is a set of general objectives for
software.
It is software working model of limited functionality.
In this model, working programs are quickly produced.
69. Prescriptive Process Models
Evolutionary Process Model – Prototyping:
Communication:
Developer and customer meet and discuss the
overall objectives of the software.
70. Prescriptive Process Models
Evolutionary Process Model – Prototyping:
Quick design:
It includes only the important aspects i.e input and
output format of the software.
It focuses on those aspects which are visible to the
user rather than the detailed plan.
71. Prescriptive Process Models
Evolutionary Process Model – Prototyping:
Modeling quick design:
This phase gives the clear idea about the development
of software as the software is now constructed.
It allows the developer to better understand the exact
requirements.
72. Prescriptive Process Models
Evolutionary Process Model – Prototyping:
Construction of prototype:
The prototype is evaluated by the customer itself.
73. Prescriptive Process Models
Evolutionary Process Model – Prototyping:
Deployment, delivery, feedback:
If the user is not satisfied with current prototype then it is
refined according to the requirements of the user.
The process of refining the prototype is repeated till all
the requirements of users are met.
When the users are satisfied with the developed prototype then
the system is developed on the basis of final prototype.
74. Prescriptive Process Models
Evolutionary Process Model – Prototyping:
Advantages:
In the development process of this model users are
actively involved.
Earlier error detection takes place in this model.
It identifies the missing functionality easily. It also
identifies the confusing or difficult functions.
75. Prescriptive Process Models
Evolutionary Process Model – Prototyping:
Disadvantages:
The client involvement is more and it is not always
considered by the developer.
It is a slow process because it takes more time for
development.
Many changes can disturb the rhythm of the development
team.
76. Prescriptive Process Models
Evolutionary Process Model – Spiral:
The spiral model combines the idea of iterative
development with the systematic, controlled
aspects of the waterfall model.
78. Prescriptive Process Models
Evolutionary Process Model – Spiral:
Determine Objectives:
This phase starts with gathering the business requirements
in the baseline spiral.
In the subsequent spirals as the product matures,
identification of system requirements, subsystem
requirements and unit requirements are all done in this
phase.
79. Prescriptive Process Models
Evolutionary Process Model – Spiral:
Determine Objectives:
This phase also includes understanding the system
requirements by continuous communication between
the customer and the system analyst.
At the end of the spiral, the product is deployed in the
identified market.
80. Prescriptive Process Models
Evolutionary Process Model – Spiral:
Risk Analysis:
Risk Analysis includes identifying, estimating and
monitoring the technical feasibility and
management risks, such as schedule slippage and
cost overrun.
81. Prescriptive Process Models
Evolutionary Process Model – Spiral:
Risk Analysis:
After testing the build, at the end of first iteration,
the customer evaluates the software and provides
feedback.
82. Prescriptive Process Models
Evolutionary Process Model – Spiral:
Development and Test:
The Construct phase refers to production of the actual
software product at every spiral.
In the baseline spiral, when the product is just thought of
and the design is being developed a POC (Proof of
Concept) is developed in this phase to get customer
feedback.
83. Prescriptive Process Models
Evolutionary Process Model – Spiral:
Applications:
Customer is not sure of their requirements which is usually
the case.
Requirements are complex and need evaluation to get
clarity.
Significant changes are expected in the product during the
development cycle.
84. Prescriptive Process Models
Evolutionary Process Model – Spiral:
Advantages:
Changing requirements can be accommodated.
Requirements can be captured more accurately.
Development can be divided into smaller parts and the
risky parts can be developed earlier which helps in
better risk management.
85. Prescriptive Process Models
Evolutionary Process Model – Spiral:
Disadvantages:
Management is more complex.
Not suitable for small or low risk projects and could
be expensive for small projects.
Large number of intermediate stages requires
excessive documentation.
87. Prescriptive Process Models
Evolutionary Process Model:
Concurrent Development Model:
The communication activity has completed in the
first iteration and exits in the awaiting changes state.
The modeling activity completed its initial
communication and then go to the underdevelopment
state.
88. Prescriptive Process Models
Evolutionary Process Model:
Concurrent Development Model:
If the customer specifies the change in the requirement,
then the modeling activity moves from the under
development state into the awaiting change state.
The concurrent process model activities moving from one
state to another state.
89. Prescriptive Process Models
Evolutionary Process Model:
Concurrent Development Model – Advantages:
This model is applicable to all types of software
development processes.
It gives immediate feedback from testing.
It provides an accurate picture of the current state of a
project.
90. Prescriptive Process Models
Evolutionary Process Model:
Concurrent Development Model –
Disadvantages:
It needs better communication between the team
members. This may not be achieved all the time.
It requires to remember the status of the different
activities.
91. Prescriptive Process Models -
Comparison
Waterfall model Spiral Model Prototyping
Model
Incremental
Model
Requirements
must be clearly
understood and
defined at the
beginning only.
The
requirements
analysis can be
gathering can be
done in iterations
because
requirements get
changed quite
often.
Requirements
analysis can be
made in the later
stage of the
development
cycle.
Requirements
analysis can be
made in the later
stage of the
development
cycle.
The development
team having the
adequate
experience
The development
having less
experience
The development
having less
experience
The development
having less
experience
92. Prescriptive Process Models -
Comparison
Waterfall model Spiral Model Prototyping
Model
Incremental
Model
No user
involvement
No user
involvement
User involvement
in all the phases of
the development
process
User involvement
in all the phases of
the development
process
Requirements are
well defined and
the development
effort suggests a
purely linear effort
then the waterfall
model is chosen.
Risk identification
and rectification is
done before they
get problematic.
For handling real
time problems the
spiral model is
chosen.
When developer is
unsure about the
efficiency of an
algorithm or the
adaptability of an
OS then the
prototyping model
is chosen
When limited set
of software
functionality is
needed quickly
then the
incremental model
is chosen.
93. Specialized Process Models
Special process models take many features from one or
more conventional models.
Component based development (Promotes reusable
components)
The formal methods model (Mathematical formal methods
are backbone here)
Aspect oriented software development (Uses crosscutting
technology)
94. Specialized Process Models
Component Based development:
It incorporates many of the characteristics of the
spiral model.
It is evolutionary in nature.
It promotes software reusability.
95. Specialized Process Models
Component Based development – Steps:
Available component based products are researched and
evaluated for the application domain.
Component integration issues are considered.
A software architecture is designed to accommodate the
components.
Components are integrated into the architecture.
Comprehensive testing is conducted to ensure proper
functionality
96. Specialized Process Models
Formal Methods Model:
A set of activities that leads to formal
mathematical specification of software.
Formal methods enable a software engineer to
specify, develop and verify a computer system by
applying rigorous mathematical notation.
97. Specialized Process Models
Formal Methods Model:
When mathematical methods are used during
software development, they provide a mechanism
for eliminating many of the problems that are
difficult to overcome using other software
engineering paradigms.
98. Specialized Process Models
Formal Methods Model:
A basis for software verification
To discover and correct errors that might
otherwise go undetected.
99. Specialized Process Models
Formal Methods Model – Problems:
It is currently time-consuming and expensive
Developers have the necessary background
knowledge to apply formal methods, extensive
training is required to others.
100. Specialized Process Models
Aspect oriented Software Development:
It provides process and methodology for defining,
specifying designing and constructing aspects.
It aims to address crosscutting concerns by
providing means for systematic identification,
separation, representation and composition.
101. Introduction to Agility
Agile Development:
Agile is the ability to create and respond to change.
It is a way of dealing with, and ultimately
succeeding in, an uncertain and unstable
environment.
102. Introduction to Agility
Agile Development:
An umbrella term for several iterative and incremental
software development methodologies.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
103. Introduction to Agility
Agile Process:
The light weight methods are people based rather than
plan based software.
It forces the development team to focus on software
itself rather than design and documentation.
To deliver the working model of software quickly to
the customer.
104. Introduction to Agility
Agile Principles:
To satisfy the customer through early and continuous
delivery of valuable software.
The changes in the requirements must be accommodated,
even late in development.
Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
105. Introduction to Agility
Agile Principles:
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
106. Introduction to Agility
Agile Principles:
Working software is the primary measure of
progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
107. Introduction to Agility
Agile Principles:
Continuous attention to technical excellence and
good design enhances agility.
Simplicity-the art of maximizing the amount of
work not done-is essential.
108. Introduction to Agility
Agile Principles:
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
109. Introduction to Agility
Agile Principles:
The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.
110. Introduction to Agility
Agile Principles:
The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.
111. Introduction to Agility
Extreme Programming
eXtreme Programming (XP) was conceived and
developed to address the specific needs of software
development by small teams in the face of vague
and changing requirements.
112. Introduction to Agility
Extreme Programming
Writing unit tests before programming and
keeping all of the tests running at all times.
Starting with a simple design just enough to code
the features at hand and redesigning when
required.
113. Introduction to Agility
Extreme Programming
Integrating and testing the whole system several times
a day.
Putting a minimal working system into the production
quickly and upgrading it whenever required.
Keeping the customer involved all the time and
obtaining constant feedback.
114. Introduction to Agility
Why is it called “Extreme?”
Code reviews are effective as the code is reviewed all the time.
Testing is effective as there is continuous regression and testing.
Design is effective as everybody needs to do refactoring daily.
Integration testing is important as integrate and test several
times a day.
Short iterations are effective as the planning game for release
planning and iteration planning.
115. Introduction to Agility
Extreme Programming Values
Communication: Extreme Programming
emphasizes continuous and constant
communication among the team members,
managers and the customer.
Face-to-Face communication is preferred
116. Introduction to Agility
Extreme Programming Values
Simplicity: Extreme Programming believes in ‘it is better
to do a simple thing today and pay a little more tomorrow to
change it’.
Take small simple steps to your goal and mitigate failures
as they happen.
Create something that you are proud of and maintain it for
a long term for reasonable costs.
117. Introduction to Agility
Extreme Programming Values
Feedback: The software is delivered early to the
customer and a feedback is taken so that
necessary changes can be made if needed.
The value of the feedback is a continuously
running system that delivers information about
itself in a reliable way.
118. Introduction to Agility
Extreme Programming Values - Courage:
To focus on only what is required
To communicate and accept feedback
To tell the truth about progress and estimates
To refactor the code
To adapt to changes whenever they happen
119. Introduction to Agility
Extreme Programming Values - Respect:
Everyone respects each other as a valued team member.
Everyone contributes value such as enthusiasm.
Developers respect the expertise of the customers and vice
versa.
Management respects the right of the developers to accept
the responsibility and receive authority over their own
work.
121. Introduction to Agility
Extreme Programming Process:
Customer specifies and priorities the system
requirements. The developer and customer together
prepare a story-card in which customer needs are
mentioned.
After developing the story-card the development team
breaks down the total work in small task.
122. Introduction to Agility
Extreme Programming Process:
The efforts and the estimated resources required for
these tasks are estimated.
The customer priorities the stories for implementation.
For accommodating new changes, new story-card
must be developed.
Evaluate, the system along with the customer.
123. Introduction to Agility
Extreme Programming Practices:
The Planning Game - determine the scope of the next release by
combining business priorities and technical estimates.
Small Releases - a simple system into production quickly, and
then release new versions in very short cycles
Metaphor - he architecture of the system to be built in a way that
it is easily understandable by everyone involved in the
development.
124. Introduction to Agility
Extreme Programming Practices:
Simple Design - The system should be designed as simply
as possible at any given moment.
Testing - The developers continually write unit tests, which
need to pass for the development to continue.
Refactoring - restructure the system without changing its
behavior to remove duplication, improve communication,
simplify, or add flexibility
125. Introduction to Agility
Extreme Programming Practices:
Pair Programming: the entire code is written with two
developers at one machine, with one keyboard and one
mouse.
Collective Ownership: the entire team takes
responsibility for the whole of the system. If a pair is
working and they see an opportunity to improve the
code, they go ahead and improve it.
126. Introduction to Agility
Extreme Programming Practices:
Continuous Integration: Code is integrated and tested
many times a day, one set of changes at a time.
40-hour week: The limited number of hours of work
per week for every team members, based on their
sustainability, to a maximum of 45 hours a week.
127. Introduction to Agility
Extreme Programming Practices:
On-site Customer: Include a real, live user on the
team, available full-time to answer the questions,
resolve disputes and set small-scale priorities.
128. Introduction to Agility
Extreme Programming Practices:
Coding Standards: Developers write all code in
accordance with the rules emphasizing
Communication through the code.
The least amount of work possible.
Consistent with the “once and only once” rule (no duplicate
code).
Voluntary adoption by the whole team.