Chapter 3

 Agile Development
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
 Syllabus
 Agile Development:
 What is Agility?
 Agility and the cost of change
 What is an agile Process?
 Extreme Programming (XP)
 Other Agile Process Models, A tool set for Agile process
 Principles that guide practice:
 Software Engineering Knowledge
 Core principles
 Principles that guide each framework activity

Textbook 1: Chapter 3: 3.1 to 3.6, Chapter 4: 4.1 to 4.3

 Agile methods

 Dissatisfaction with the overheads involved in software

design methods of the 1980s and 1990s led to the creation
of agile methods. These methods:
 Focus on the code rather than the design
 Are based on an iterative approach to software development
 Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
 The aim of agile methods is to reduce overheads in the
software process (e.g. by limiting documentation) and to
be able to respond quickly to changing requirements
without excessive rework.
The Manifesto for Agile Software Development

“We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work 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
That is, while there is value in the items on the
right, we value the items on the left more.”
Kent Beck et al
 What is “Agility”?
 It encourages team structures and attitudes that make
communication (among team members, between
technologists and business people, between software
engineers and their managers) more superficial.
 It emphasizes rapid delivery of operational software and
de-emphasizes the importance of intermediate work
products (not always a good thing);
 It adopts the customer as a part of the development team
and works to eliminate the “us and them” attitude that
continues to pervade many software projects;
 It recognizes that planning in an uncertain world has its
limits and that a project plan must be flexible.
 What is “Agility”?
 Agility can be applied to any software process.
 To accomplish this, it is essential that the process be
designed in a way that allows the project team to
 Adapt tasks and to streamline them
 Conduct planning in a way that understands the fluidity of an
agile development approach
 Eliminate all but the most essential work products and keep
them lean
 Emphasize an incremental delivery strategy that gets working
software to the customer as rapidly as feasible for the product
type and operational environment.
 What is “Agility”?
 Effective (rapid and adaptive) response to change
 Effective communication among all stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in control of the work
performed
Yielding …
 Rapid, incremental delivery of software
Agility and the Cost of Change
 Agility and the Cost of Change
 The conventional wisdom in software development is
that the cost of change increases nonlinearly as a
project progresses
 It is relatively easy to accommodate a change when a
software team is gathering requirements.
 A usage scenario might be modified,
 A list of functions may be extended,
 A written specification can be edited
 The costs of doing this work are minimal, and the time
required will not adversely affect the outcome of the
project.
 Agility and the Cost of Change
What if:
The team in the middle of validation testing, and an
important stakeholder is requesting a major functional
change.
 The change requires a modification to the architectural design of
the software
 The design and construction of three new components
 Modifications to another five components
 The design of new tests, and so on
Costs escalate quickly, and the time and cost required to
ensure that the change is made without unintended side
effects is nontrivial.
 Agility and the Cost of Change
 A well-designed agile process “flattens” the cost of
change curve, allowing a software team to
accommodate changes late in a software project without
dramatic cost and time impact.
 The agile process encompasses incremental delivery.
 When incremental delivery is coupled with other agile
practices such as continuous unit testing and pair
programming, the cost of making a change is
attenuated.
Plan-driven and Agile specification
 What is an Agile Process?
 A number of key assumptions:
1. It is difficult to predict in advance which software requirements
will persist and which will change. It is equally difficult to predict
how customer priorities will change as the project proceeds.
2. For many types of software, design and construction are
interleaved. It is difficult to predict how much design is necessary
before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable
(from a planning point of view) as we might like.
 How do we create a process that can manage unpredictability?
 The answer: lies in process adaptability (to rapidly changing project
and technical conditions).
 An agile process, therefore, must be adaptable.
What is an Agile Process?

 Is driven by customer descriptions of what is required

(scenarios)
 Recognizes that plans are short-lived
 Develops software iteratively with a heavy emphasis
on construction activities
 Delivers multiple ‘software increments’
 Adapts as changes occur
 Agility Principles - I
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Businesspeople and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need and trust them to get the job
done.
6. The most efficient and effective method of conveying information
to and within a development team is face–to–face conversation.
 Agility Principles - II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity – the art of maximizing the amount of work not done –
is essential.
11. The best architectures, requirements, and designs emerge from
self–organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
Not every agile process model applies these 12 principles with equal weight, and some
models choose to ignore the importance of one or more of the principles.
 Agile method applicability
• Product development where a software company is
developing a small or medium-sized product for sale.
• Custom system development within an organization,
where there is a clear commitment from the customer to
become involved in the development process and where
there are not a lot of external rules and regulations that
affect the software.
• Because of their focus on small, tightly-integrated teams,
there are problems in scaling agile methods to large
systems.
 Problems with agile methods

 It can be difficult to keep the interest of customers

who are involved in the process.
 Team members may be unsuited to the intense
involvement that characterizes agile methods.
 Prioritizing changes can be difficult where there are
multiple stakeholders.
 Maintaining simplicity requires extra work.
 Contracts may be a problem as with other
approaches to iterative development.
 Agile methods and software maintenance
• Most organizations spend more on maintaining existing
software than they do on new software development.
• So, if agile methods are to be successful, they have to
support maintenance as well as original development.
• Two key issues:
– Are systems that are developed using an agile approach
maintainable, given the emphasis in the development process of
minimizing formal documentation?
– Can agile methods be used effectively for evolving a system in
response to customer change requests?
• Problems may arise if original development team cannot
be maintained.
Plan-driven and agile development
Plan-driven development
A plan-driven approach to software engineering is based around
separate development stages with the outputs to be produced at
each of these stages planned in advance.
 Notnecessarily waterfall model – plan-driven, incremental
development is possible
 Iteration occurs within activities.
Agile development
 Specification,
design, implementation and testing are inter-
leaved and the outputs from the development process are
decided through a process of negotiation during the software
development process.
 Human Factors
 Proponents of agile software development take great pains to
emphasize the importance of “people factors.”
 As Cockburn and Highsmith state, “Agile development
focuses on the talents and skills of individuals, molding the
process to specific people and teams.”
 The key point in this statement is that the process molds to the
needs of the people and team
 Key traits must exist among the people on an agile team and
the team itself:
 Competence.
 Common focus.
 Collaboration.
 Decision-making ability.
 Fuzzy problem-solving ability.
 Mutual trust and respect.
 Self-organization.
Competence
 In an agile development context, “competence”
encompasses:
 Essential talent
 Specific software-related skills
 Overall knowledge of the process that the team has
chosen to apply.
 Skill and knowledge of process can and should be
taught to all people who serve as agile team members.
Common focus
 Although members of the agile team may perform
different tasks and bring different skills to the project
 All should be focused on one goal—to deliver a
working software increment to the customer within the
time promised.
 To achieve this goal, the team will also focus on
continual adaptations (small and large) that will make
the process fit the needs of the team.
Collaboration
 Software engineering is about
 Assessing, analysing, and using information that is
communicated to the software team
 Creating information that will help all stakeholders
understand the work of the team
 Building information (computer software and relevant
databases) that provides business value for the
customer.
 To accomplish these tasks, team members must
collaborate—with one another and all other
stakeholders.
Decision-making ability
 Any good software team must be allowed the freedom
to control its own destiny.
 This implies that the team is given autonomy—
decision-making authority for both technical and
project issues.
Fuzzy problem-solving ability
 Software managers must recognize that the agile team
will continually have to deal with ambiguity and will
continually be buffeted by change.
 In some cases, the team must accept the fact that the
problem they are solving today may not be the problem
that needs to be solved tomorrow.
 However, lessons learned from any problem-solving
activity may be of benefit to the team later in the
project.
Mutual trust and respect
 The agile team must become what DeMarco and Lister
call a “jelled” team.
 A jelled team exhibits the trust and respect that are
necessary to make them “so strongly knit that the
whole is greater than the sum of the parts”
Self-organization
 Self-organization implies three things:
(1) The agile team organizes itself for the work to be done,
(2) The team organizes the process to best accommodate its local
environment,
(3) The team organizes the work schedule to best achieve
delivery of the software increment.
 Self-organization has several technical benefits;
It
serves to improve collaboration and boost team
morale.
 In essence, the team serves as its own
management.
Extreme Programming (XP)
 The most widely used agile process, originally
proposed by Kent Beck
 XP Planning
 Begins with the creation of “user stories”
 Agile team assesses each story and assigns a cost

 Stories are grouped to for a deliverable increment

 A commitment is made on delivery date

 After the first increment “project velocity” is used to

help define subsequent delivery dates for other

increments
More recently, a variant of XP, called Industrial XP (IXP)
has been proposed
Extreme Values

 Beck defines a set of five values that establish a

foundation for all work performed as part of XP:
 communication, simplicity, feedback, courage, and
respect.
 Each of these values is used as a driver for specific
XP activities, actions, and tasks.
Communication
 To achieve effective communication between
software engineers and other stakeholders:
 (e.g., to establish required features and functions for the
software),
 XP emphasizes close, yet informal (verbal)
collaboration between
 customers and developers,
 the establishment of effective metaphors for
communicating important concepts,
 continuous feedback, and
 the avoidance of voluminous documentation as a
communication medium.
 Simplicity

 To achieve simplicity:
 XP restricts developers to design only for
immediate needs, rather than consider future
needs.
 The intent is to create a simple design that
can be easily implemented in code.
 If the design must be improved, it can be
refactored at a later time.
 Feedback
 Feedback is derived from three sources:
 the implemented software itself, the customer, and other software
team members.
 By designing and implementing an effective testing
strategy, the software (via test results) provides the agile
team with feedback.
 XP makes use of the unit test as its primary testing tactic.
 As each class is developed, the team develops a unit test to
exercise each operation according to its specified functionality.
 As an increment is delivered to a customer, the user stories or use
cases that are implemented by the increment are used as a basis
for acceptance tests.
 Finally, as new requirements are derived as part of iterative
planning, the team provides the customer with rapid feedback
regarding cost and schedule impact.
Courage
 It is nothing but discipline.
 Most software teams succumb, arguing that “designing
for tomorrow” will save time and effort in the long run.
 An agile XP team must have the discipline (courage) to
 design for today
 recognizing that future requirements may change
dramatically
 thereby demanding substantial rework of the design and
implemented code.
 Respect
 The agile team inculcates respect among its members,
between other stakeholders and team members, and
indirectly, for the software itself.
 As they achieve successful delivery of software
increments, the team develops growing respect for the
XP process.
 The XP Process
 Extreme Programming uses an object-oriented
approach as its preferred development paradigm
 It encompasses a set of rules and practices that
occur within the context of four framework
activities: planning, design, coding, and testing.
 XP – Planning - 1
 The planning activity begins with listening
 A requirements gathering activity that enables the technical members of
the XP team to understand the business context for the software and to get
a feel for required output and major features and functionality.
 Listening leads to the creation of a set of “stories” that describe
required output, features, and functionality for software to be built.
 Each story is written by the customer and is placed on an index card.
 The customer assigns a value (i.e., a priority) to the story based on
the overall business value of the feature or function.
 Members of the XP team then assess each story and assign a cost—
measured in development weeks—to it.
 If the story is estimated to require more than three development
weeks:
 The customer is asked to split the story into smaller stories, and the
assignment of value and cost occurs again.
 XP – Planning - 2
 Customers and developers work together to decide how to
group stories into the next release to be developed by the
XP team.
 Once a basic commitment is made for a release, the XP
team orders the stories that will be developed in one of
three ways:
(1) All stories will be implemented immediately (within a few
weeks),
(2) The stories with highest value will be moved up in the schedule
and implemented first, or
(3) The riskiest stories will be moved up in the schedule and
implemented first.
 XP – Planning – 3
 After the first project release has been delivered, the XP
team computes project velocity.
 Project velocity is the number of customer stories
implemented during the first release.
 Project velocity can then be used to:
(1) help estimate delivery dates and schedule for subsequent
releases and
(2) determine whether an overcommitment has been made for
all stories across the entire development project.
 If an overcommitment occurs, the content of releases is
modified, or end delivery dates are changed.
 XP – Planning – 4
 As development work proceeds, the customer can
 Add stories
 Change the value of an existing story

 Split stories, or

 Eliminate them

 The XP team then reconsiders all remaining

releases and modifies its plans accordingly.
Extreme Programming
(XP)
Extreme Programming (XP)
 XP Design
 Follows the KIS principle
 Encourage the use of CRC cards
 For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
 Encourages “refactoring”—an iterative refinement of the internal
program design
 XP Coding
 Recommends the construction of a unit test for a store before
coding commences
 Encourages “pair programming”. The pair programmers have
integration responsibility
 XP Testing
 All unit tests are executed daily
 “Acceptance tests” are defined by the customer and executed to
assess customer visible functionality
 Refactoring
 Is the process of changing a software system in such a
way that it does not alter the external behavior of the
code yet improves the internal structure.
 It is a disciplined way to clean up code that minimizes
the chances of introducing bugs.
 In essence, when we refactor, we are improving the
design of the code after it has been written.
 Industrial XP
 IXP is an organic evolution of XP.
 It is filled with XP’s minimalist, customer-centric, test-
driven spirit.
 IXP differs most from the original XP in its greater
inclusion of management, its expanded role for customers,
and its upgraded technical practices.
 IXP incorporates six new practices that are designed to help
ensure that an XP project works successfully for significant
projects within a large organization.
 Readiness assessment
 Project community
 Project chartering
 Test-driven management
 Retrospectives
 Continuous learning
Readiness assessment
 Prior to the initiation of an IXP project, the organization
should conduct a readiness assessment.
 The assessment ascertains whether:
(1) an appropriate development environment exists to support
IXP
(2) the team will be populated by the proper set of stakeholders
(3) the organization has a distinct quality program and supports
continuous improvement
(4) the organizational culture will support the new values of an
agile team
(5) the broader project community will be populated
appropriately.
Project community
 A community may have a technologist and customers
who are central to the success of a project as well as many
other stakeholders (e.g., legal staff, quality auditors,
manufacturing or sales types)
 Who “are often at the periphery of an IXP project yet
they may play important roles on the project”
 In IXP, the community members and their roles should be
explicitly defined and mechanisms for communication
and coordination between community members should be
established.
Project chartering
 The IXP team assesses the project itself to determine
 whether an appropriate business justification for the
project exists and
 whether the project will further the overall goals and
objectives of the organization.
 Chartering also examines the context of the project to
determine how it complements, extends, or replaces
existing systems or processes.
Test-driven management
 An IXP project requires measurable criteria for assessing
the state of the project and the progress
 Establishes a series of measurable “destinations” and then
defines mechanisms for determining whether these
destinations have been reached.
Retrospectives
 An IXP team conducts a specialized technical review after
a software increment is delivered.
 The review examines “issues, events, and lessons-
learned” across a software increment and/or the entire
software release.
 The intent is to improve the IXP process.
Continuous learning
 Learning is a vital part of continuous process
improvement
 Members of the XP team are encouraged to learn new
methods and techniques that can lead to a higher quality
product.
Other Agile process models
The most common are:
• Adaptive Software Development (ASD)
• Scrum
• Dynamic Systems Development Method (DSDM)
• Crystal
• Feature Drive Development (FDD)
• Lean Software Development (LSD)
• Agile Modeling (AM)
• Agile Unified Process (AUP)
 Adaptive Software Development

 Originally proposed by Jim Highsmith

 ASD — distinguishing features
 Mission-driven planning
 Component-based focus

 Uses “time-boxing”

 Explicit consideration of risks

 Emphasizes collaboration for requirements

gathering
 Emphasizes “learning” throughout the process
Adaptive Software Development
 speculation
 During speculation, the project is initiated, and
adaptive cycle planning is conducted.
 Adaptive cycle planning uses project initiation
information:
 the customer’s mission statement,
 project constraints (e.g., delivery dates or user

descriptions), and
 basic requirements

 To define the set of release cycles (software

increments) that will be required for the project.
 collaboration

 Motivated people use collaboration in a way

that multiplies their talent and creative output
beyond their absolute numbers.
 This approach is a recurring theme in all agile
methods.
 But collaboration is not easy.
 It encompasses communication and teamwork,
but it also emphasizes individualism
 because individual creativity plays an important role
in collaborative thinking
 learning

 The emphasis on “learning” as it is on progress

toward a completed cycle.
 Software developers often overestimate their
own understanding (of the technology, the
process, and the project) and that learning will
help them to improve their level of real
understanding.
 Scrum
 Originally proposed by Schwaber and Beedle
 Scrum—distinguishing features
 Development work is partitioned into “packets”
 Testing and documentation are on-going as the product is
constructed
 Work occurs in “sprints” and is derived from a “backlog” of
existing requirements
 Meetings are very short and sometimes conducted without
chairs
 “demos” are delivered to the customer with the time-box
allocated
Scrum
Dynamic Systems Development Method
 Promoted by the DSDM Consortium
 DSDM—distinguishing features
 Similar in most respects to XP and/or ASD
 Nine guiding principles
1. Active user involvement is imperative.
2. DSDM teams must be empowered to make decisions.
3. The focus is on frequent delivery of products.
4. Fitness for business purpose is the essential criterion for
acceptance of deliverables.
5. Iterative and incremental development is necessary to converge
on an accurate business solution.
6. All changes during development are reversible.
7. Requirements are baselined at a high level
8. Testing is integrated throughout the life-cycle.
Dynamic Systems Development Method

DSDM Life Cycle

 Crystal
 Proposed by Cockburn and Highsmith
 Crystal—distinguishing features:
 Actually, a family of process models that allow
“maneuverability” based on problem
characteristics
 Face-to-face communication is emphasized

 Suggests the use of “reflection workshops” to

review the work habits of the team

“Maneuverability” is a resource limited, cooperative

game of invention and communication, with a primary
goal of delivering useful, working software and a
 Reflection workshops in software engineering
are structured opportunities for teams to pause, discuss, and
learn from their experiences to improve future projects and
processes.
 They facilitate learning about what went well and what
challenges arose during a software development project,
using tools like agile retrospectives to improve team
communication, understanding of their own processes, and
alignment with organizational goals.
Feature Driven Development
 Originally proposed by Peter Coad et al
 FDD—distinguishing features
 Emphasis is on defining “features”
• a feature “is a client-valued function that can be
implemented in two weeks or less.”
 Uses a feature template

• <action> the <result> <by | for | of | to> a(n)

<object>
 A features list is created and “plan by feature” is
conducted
 Design and construction merge in FDD
Feature Driven Development
 Agile Modeling

 Originally proposed by Scott Ambler

 Suggests a set of agile modeling principles
 Model with a purpose
 Use multiple models

 Travel light

 Content is more important than representation

 Know the models and the tools you use to create them

 Adapt locally
 Model with a purpose

 A developer who uses AM should have a specific goal

in mind before creating the model.
 Once the goal for the model is identified, the type of
notation to be used and level of detail required will be
more obvious.
 Use multiple models

 There are many different models and notations that

can be used to describe software.
 Only a small subset is essential for most projects.
 AM suggests that each model should present a
different aspect of the system and only those models
that provide value to their intended audience should
be used.
 Travel light

 As software engineering work proceeds, keep only

those models that will provide long-term value and
abandon the rest.
 Every work product that is kept must be maintained as
changes occur.
 This represents work that slows the team down.
Content is more important than representation

 Modeling should impart information to its

intended audience.
 A syntactically perfect model that imparts little
useful content is not as valuable as a model with
flawed notation that provides valuable content
for its audience.
Know the models and the tools you use to create
them

 Understand the strengths and weaknesses of

each model and the tools that are used to
create it.

Adapt locally

 The modeling approach should be adapted to

the needs of the agile team.
 A TOOL SET FOR THE AGILE PROCESS
 The “tool set” that supports agile processes focuses more on people
issues than it does on technology issues.
 Collaborative and communication “tools” are generally low tech and
incorporate any mechanism (“physical proximity, whiteboards, poster
sheets, index cards, and sticky notes”
 Active communication is achieved via the team dynamics (e.g., pair
programming), while passive communication is achieved by
“information radiators” (e.g., a flat panel display that presents the
overall status of different components of an increment).
 Project management tools deemphasize the Gantt chart and replace it
with “graphs of tests created versus passed”
 Other agile tools are used to optimize the environment in which the
agile team works (e.g., more efficient meeting areas), improve the
team culture by nurturing social interactions (e.g., collocated teams),
physical devices (e.g., electronic whiteboards), and process
enhancement
 Chapter 4

Principles that Guide Practice

Software Engineering: A Practitioner’s Approach,
7/e
by Roger S. Pressman
 Software engineering practice
Software engineering practice is a broad array of
principles, concepts, methods, and tools that you must
consider as software is planned and developed.
Principles that guide practice establish a foundation from
which software engineering is conducted.
Who does it? Practitioners (software engineers) and
their managers conduct a variety of software engineering
tasks.
What are the steps? Three elements of practice apply.
They are principles, concepts, and methods.
A fourth element of practice—tools—supports the
application of methods.
Software Engineering Knowledge
 You often hear people say that software development
knowledge has a 3-year half-life: half of what you need to
know today will be obsolete within 3 years. In the domain of
technology-related knowledge, that’s probably about right.
 But there is another kind of software development knowledge
—a kind that I think of as "software engineering
principles"—that does not have a three-year half-life.
 These software engineering principles are likely to serve a
professional programmer throughout his or her career.
Steve McConnell

 core principles—the elemental ideas that guide software

engineers in the work that they do: provide a foundation from
which software engineering models, methods, and tools can be
applied and evaluated.
General Principles
 A set of general principles that span software
engineering process and practice:
(1) provide value to end users,
(2) keep it simple,
(3) maintain the vision (of the product and the project),
(4) recognize that others consume (and must understand)
what you produce,
(5) be open to the future,
(6) plan ahead for reuse, and
(7) think!
Principles that Guide Process - I
The set of core principles can be applied to the framework, and by
extension, to every software process
Principle #1. Be agile. Whether the process model you choose is
prescriptive or agile, the basic beliefs of agile development should
govern your approach.
Principle #2. Focus on quality at every step. The exit condition
for every process activity, action, and task should focus on the quality
of the work product that has been produced.
Principle #3. Be ready to adapt. Process is not a religious
experience, and dogma has no place in it. When necessary, adapt
your approach to constraints imposed by the problem, the people, and
the project itself.
Principle #4. Build an effective team. Software engineering process
and practice are important, but the bottom line is people. Build a self-
organizing team that has mutual trust and respect.
Principles that Guide Process - II
Principle #5. Establish mechanisms for communication and
coordination. Projects fail because important information falls into
the cracks and/or stakeholders fail to coordinate their efforts to
create a successful end product.
Principle #6. Manage change. The approach may be either
formal or informal, but mechanisms must be established to manage
the way changes are requested, assessed, approved and
implemented.
Principle #7. Assess risk. Lots of things can go wrong as
software is being developed. It’s essential that you establish
contingency plans.
Principle #8. Create work products that provide value for
others. Create only those work products that provide value for
other process activities, actions or tasks.
Principles that Guide Practice – I
These principles have merit regardless of the analysis and design methods that you
apply, the construction techniques (e.g., programming language, automated tools)
that you use, or the verification and validation approach that you choose.

Principle #1. Divide and conquer. Analysis and design should

always emphasize separation of concerns (SoC). A large problem is
easier to solve if it is subdivided into a collection of elements (or
concerns).
Principle #2. Understand the use of abstraction. At its core, an
abstraction is a simplification of some complex element of a
system used to communication meaning in a single phrase.
Principle #3. Strive for consistency. A familiar context makes
software easier to use.
Principle #4. Focus on the transfer of information. Pay special
attention to the analysis, design, construction, and testing of
interfaces.
Principles that Guide Practice – II
Principle #5. Build software that exhibits effective modularity.
Separation of concerns establishes a philosophy for software.
Modularity provides a mechanism for realizing the philosophy.
Principle #6. Look for patterns. Brad Appleton suggests that:
The goal of patterns within the software community is to create
a body of literature to help software developers resolve
recurring problems encountered throughout all of software
development.
Principle #7. When possible, represent the problem and its
solution from a number of different perspectives.
Principle #8. Remember that someone will maintain the
software.
 Communication Principles – I
Principle#1. Listen. Try to focus on the speaker’s words, rather
than formulating your response to those words.
Principle # 2. Prepare before you communicate. Spend the
time to understand the problem before you meet with others.
Principle # 3. Someone should facilitate the activity.
Every communication meeting should have a leader (a
facilitator) to keep the conversation moving in a productive
direction; (2) to mediate any conflict that does occur, and (3) to
ensure than other principles are followed.
Principle #4. Face-to-face communication is best. But it
usually works better when some other representation of the
relevant information is present.
 Communication Principles – II
 Principle # 5. Take notes and document decisions. Someone
participating in the communication should serve as a “recorder” and
write down all important points and decisions.
 Principle # 6. Strive for collaboration. Collaboration and consensus
occur when the collective knowledge of members of the team is
combined …
 Principle # 7. Stay focused, modularize your discussion. The more
people involved in any communication, the more likely that discussion
will bounce from one topic to the next.
 Principle # 8. If something is unclear, draw a picture.
 Principle # 9. (a) Once you agree to something, move on; (b) If you
can’t agree to something, move on; (c) If a feature or function is
unclear and cannot be clarified at the moment, move on.
 Principle # 10. Negotiation is not a contest or a game. It works best
when both parties win.
Planning Principles – I
 Principle #1. Understand the scope of the project. It’s
impossible to use a roadmap if you don’t know where you’re
going. Scope provides the software team with a destination.
 Principle #2. Involve the customer in the planning activity.
The customer defines priorities and establishes project
constraints.
 Principle #3. Recognize that planning is iterative. A project
plan is never engraved in stone. As work begins, it very likely
that things will change.
 Principle #4. Estimate based on what you know. The intent of
estimation is to provide an indication of effort, cost, and task
duration, based on the team’s current understanding of the work
to be done.
Planning Principles – II
 Principle #5. Consider risk as you define the plan. If you have
identified risks that have high impact and high probability,
contingency planning is necessary.
 Principle #6. Be realistic. People don’t work 100 percent of every
day.
 Principle #7. Adjust granularity as you define the plan.
Granularity refers to the level of detail that is introduced as a
project plan is developed.
 Principle #8. Define how you intend to ensure quality. The plan
should identify how the software team intends to ensure quality.
 Principle #9. Describe how you intend to accommodate change.
Even the best planning can be obviated by uncontrolled change.
 Principle #10. Track the plan frequently and adjust as
required. Software projects fall behind schedule one day at a time.
 Modeling Principles

In software engineering work, two classes of

models can be created:
Requirements models (also called analysis models)
represent the customer requirements by depicting the
software in three different domains: the information
domain, the functional domain, and the behavioural
domain.
Design models represent characteristics of the
software that help practitioners to construct it
effectively: the architecture, the user interface, and
component-level detail.
Modeling principles that are intended for those who
use the agile process model
 Principle #1. The primary goal of the software team is to
build software, not create models.
 Principle #2. Travel light—don’t create more models than
you need.
 Principle #3. Strive to produce the simplest model that will
describe the problem or the software.
 Principle #4. Build models in a way that makes them
amenable to change.
 Principle #5. Be able to state an explicit purpose for each
model that is created.
 Principle #6. Adapt the models you develop to the system at
hand.
 Contd …
 Principle #7. Try to build useful models, but forget about
building perfect models.
 Principle #8. Don’t become dogmatic about the syntax of
the model. If it communicates content successfully,
representation is secondary.
 Principle #9. If your instincts tell you a model isn’t right
even though it seems okay on paper, you probably have
reason to be concerned.
 Principle #10. Get feedback as soon as you can.
Requirements Modeling Principles
 Principle #1. The information domain of a problem must be
represented and understood.
 Principle #2. The functions that the software performs must
be defined.
 Principle #3. The behaviour of the software (as a
consequence of external events) must be represented.
 Principle #4. The models that depict information, function,
and behaviour must be partitioned in a manner that
uncovers detail in a layered (or hierarchical) fashion.
 Principle #5. The analysis task should move from essential
information toward implementation detail.
 Design Modeling Principles
 Principle #1. Design should be traceable to the requirements model.
 Principle #2. Always consider the architecture of the system to be
built.
 Principle #3. Design of data is as important as design of processing
functions.
 Principle #5. User interface design should be tuned to the needs of the
end-user. However, in every case, it should stress ease of use.
 Principle #6. Component-level design should be functionally
independent.
 Principle #7. Components should be loosely coupled to one another
and to the external environment.
 Principle #8. Design representations (models) should be easily
understandable.
 Principle #9. The design should be developed iteratively. With each
iteration, the designer should strive for greater simplicity.
 Agile Modeling Principles
 Principle #1. The primary goal of the software team is to build
software, not create models.
 Principle #2. Travel light—don’t create more models than you need.
 Principle #3. Strive to produce the simplest model that will describe
the problem or the software.
 Principle #4. Build models in a way that makes them amenable to
change.
 Principle #5. Be able to state an explicit purpose for each model that
is created.
 Principle #6. Adapt the models you develop to the system at hand.
 Principle #7. Try to build useful models but forget about building
perfect models.
 Principle #8. Don’t become dogmatic about the syntax of the model. If
it communicates content successfully, representation is secondary.
 Principle #9. If your instincts tell you a model isn’t right even though
it seems okay on paper, you probably have reason to be concerned.
 Principle #10. Get feedback as soon as you can.
Construction Principles

The construction activity encompasses a set of coding

and testing tasks that lead to operational software that is
ready for delivery to the customer or end-user.
Coding principles and concepts are closely aligned
programming style, programming languages, and
programming methods.
Testing principles and concepts lead to the design of tests
that systematically uncover different classes of errors and
to do so with a minimum amount of time and effort.
Preparation Principles

Before you write one line of code, be sure you:

Understand of the problem you’re trying to solve.
Understand basic design principles and concepts.
Pick a programming language that meets the needs of the
software to be built and the environment in which it will
operate.
Selecta programming environment that provides tools that
will make your work easier.
Create
a set of unit tests that will be applied once the
component you code is completed.
Coding Principles
As you begin writing code, be sure you:
Constrain your algorithms by following structured
programming practice.
Consider the use of pair programming
Select data structures that will meet the needs of the design.
Understand the software architecture and create interfaces that
are consistent with it.
Keep conditional logic as simple as possible.
Create nested loops in a way that makes them easily testable.
Select meaningful variable names and follow other local
coding standards.
Write code that is self-documenting.
Create a visual layout (e.g., indentation and blank lines) that
aids understanding.
Validation Principles

After you’ve completed your first coding pass, be sure you:

Conduct a code walkthrough when appropriate.
Perform unit tests and correct errors you’ve uncovered.
Refactor the code.
 Testing Principles
 Al Davis suggests the following:
 Principle #1. All tests should be traceable to customer

requirements.
 Principle #2. Tests should be planned long before testing begins.

 Principle #3. The Pareto principle applies to software testing.

 Principle #4. Testing should begin “in the small” and progress

toward testing “in the large.”

 Principle #5. Exhaustive testing is not possible.
 Deployment Principles
 Principle #1. Customer expectations for the software must be
managed. Too often, the customer expects more than the team
has promised to deliver, and disappointment occurs immediately.
 Principle #2. A complete delivery package should be
assembled and tested.
 Principle #3. A support regime must be established before the
software is delivered. An end-user expects responsiveness and
accurate information when a question or problem arises.
 Principle #4. Appropriate instructional materials must be
provided to end-users.
 Principle #5. Buggy software should be fixed first, delivered
later.