MODULE-3 AGILE DEVELOPMENT

WHAT IS AGILITY?
Agility refers to the ability of a software team to quickly and
effectively respond to changes.
Software engineers need to be agile to accommodate rapid changes in
various aspects of the project.
Agility also includes adopting the philosophy of the Agile Manifesto,
which emphasizes:
 Improved communication among team members, technologists,
business people, and managers.
 Rapid delivery of functional software.
WHAT IS AGILITY?
Agility can be incorporated into any software process by:
 Allowing project teams to adapt and streamline tasks.
 Conducting planning that accommodates the fluid nature of
agile development.
 Eliminating non-essential work products and keeping necessary
ones lean.
 Emphasizing incremental delivery to get working software to
customers quickly, suited to the product type and operational
environment. (These points highlight the essence of agility in software
engineering as described
by Ivar Jacobson)
AGILITY AND THE COST OF
CHANGE
The conventional wisdom in software development is that the cost
of change increases nonlinearly as a project progresses (Figure).
It is relatively easy to accommodate a change when a software
team is gathering requirements (early in a project).
A usage scenario might have to be modified, a list of functions
may be extended, or 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.
Proponents of agility argue that a well-designed agile process
“flattens” the cost of change curve (Figure), allowing a software
team to accommodate changes late in a software project without
dramatic cost and time impact.
WHAT IS AN AGILE
PROCESS?
Any agile software process is characterized in a manner that addresses a
number of key assumptions about the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist
and which will change.
2.It is equally difficult to predict how customer priorities will change as the
project proceeds.
3. For many types of software, design and construction are interleaved. That is,
both activities should be performed in tandem so that design models are proven
as they are created.
4.It is difficult to predict how much design is necessary before construction is
used to prove the design.
5. Analysis, design, construction, and testing are not as predictable (from a
planning point of view) as we might like.
1.AGILITY PRINCIPLES
The Agile Alliance defines 12 agility principles for those who want to
achieve agility:
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. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
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
2.THE POLITICS OF AGILE
DEVELOPMENT
There is considerable debate about the benefits and applicability of agile
software development versus traditional software engineering processes.
Key points include:
1. Pro-Agility View: Agilists view traditional methodologies as overly rigid
and
documentation-heavy, hindering the delivery of working systems.
2. Traditional View: Traditionalists view agile methodologies as undisciplined
and risky, especially when scaling up to enterprise-wide software.
3. Rational Thought vs. Beliefs: The debate often risks becoming a
"religious war," with beliefs rather than facts guiding decision-making.
4. Balanced Approach: There is value in considering the best aspects of
both agile and traditional approaches rather than denigrating either.
3 HUMAN FACTORS
Proponents of agile software development take great pains to
emphasize the importance of “people factors.”
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, not the other way around.
Competence. In an agile development context, “competence”
encompasses innate talent, specific software-related skills, and
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 member.
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 (regardless of process) is
about assessing, analyzing, and using information that is
communicated to the software team;
creating information that will help all stakeholders understand the
work of the team; and 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 (including agile
teams) 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.
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. In the context of agile development, 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 a number of technical benefits, but more
importantly, it serves to improve collaboration and boost team
morale.
EXTREME PROGRAMMING
(XP)
oThe most widely used approach to agile software development.
oDeveloped by Kent Beck, XP focuses on improving software quality
and
responsiveness to changing customer requirements.
oIXP(industrial XP) refines XP and targets the agile process
specifically for use within large organizations.
1. XP 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,
COMMUNICATION

In order to achieve effective communication between software

engineers and other stakeholders ,
1.XP emphasizes close, yet informal (verbal) collaboration between
customers and developers.
2.The establishment of effective metaphors for communicating
important concepts, continuous feedback, and the avoidance of
voluminous documentation as a communication medium.
SIMPLICITY&FEEDBACK

To achieve simplicity,
1.XP restricts developers to design only for immediate needs, rather than consider
future needs.
2.If the design must be improved, it can be refactored at a later time.
Feedback is derived from three sources: the implemented software itself, the
customer, and other software team members.
1. 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.
2. 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.
3. 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&RESPECT

Beck argues that strict adherence to certain XP practices demands

courage. A better word might be discipline.
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.
By following each of these values, the agile team fix respect among
it 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.
2 The XP Process
Extreme Programming uses an object-oriented approach.
it encompasses a set of rules and practices that occur within the context
of four framework activities: planning, design, coding, and testing.
Figure illustrates the XP process and notes some of the key ideas and
tasks that are associated with each framework activity.
Planning.
The planning activity (also called the planning game) 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 broad feel for required output and major features
and functionality.
Listening leads to the creation of a set of “stories” (also called user
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 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.
It is important to note that new stories can be written at any time.
After the first project release (also called a software increment) has been
delivered, the XP team computes project velocity.
Stated simply, 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 over commitment has been made for all stories across
the entire development project. If an over commitment occurs, the content of
releases is modified or end delivery dates are changed.
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.
DESIGN

XP design rigorously follows the KIS (keep it simple) principle.

A simple design is always preferred over a more complex
representation.
In addition, the design provides implementation guidance for a story
as it is written—nothing less, nothing more.
XP encourages the use of CRC cards as an effective mechanism for
thinking about the software in an object-oriented context.
If a difficult design problem is encountered as part of the design of a
story, XP recommends the immediate creation of an operational
prototype Called a spike solution.
The intent is to lower risk.
DESIGN

XP encourages refactoring—a construction technique that is also a

method for design optimization.
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.
Refactoring means that design occurs continuously as the system
is constructed.
It is a disciplined way to clean up code that minimizes the chances
of introducing bugs.
A central notion in XP is that design occurs both before and after
coding commences.
CODING

After stories are developed and preliminary design work is done, the
team does not move to code, but rather develops a series of unit
tests that will exercise each of the stories that is to be included in
the current release.
Once the unit test has been created, the developer is better able to
focus on what must be implemented to pass the test.
Once the code is complete, it can be unit-tested immediately,
thereby providing instantaneous feedback to the developers.
A key concept during the coding activity is pair programming.
CODING

XP recommends that two people work together at one computer

workstation to create code for a story.
This provides a mechanism for real time problem solving and real-
time quality assurance. It also keeps the developers focused on the
problem at hand.
In practice, each person takes on a slightly different role.
For example, one person might think about the coding details of a
particular portion of the design while the other ensures that coding
standards (a required part of XP) are being followed or that the
code for the story will satisfy the unit test that has been developed
to validate the code against the story
CODING

As pair programmers complete their work, the code they develop is
integrated with the work of others.
In some cases this is performed on a daily basis by an integration
team.
In other cases, the pair programmers have integration
responsibility.
This “continuous integration” strategy helps to avoid compatibility
and interfacing problems and provides a “smoke testing”
environment that helps to uncover errors early.
TESTING

The creation of unit tests before coding commences is a key

element of the XP approach.
The unit tests that are created should be implemented using a
framework that enables them to be automated.
This encourages a regression testing strategy whenever code is
modified.
Integration and validation testing of the system can occur on a
daily basis.
This provides the XP team with a continual indication of progress
and also can raise warning flags early if things go awry.
TESTING

XP acceptance tests, also called customer tests, are specified by

the customer and focus on overall system features and
functionality that are visible and reviewable by the customer.
Acceptance tests are derived from user stories that have been
implemented as part of a software release.
INDUSTRIAL XP
Joshua Kerievsky describes Industrial Extreme Programming (IXP)
in the following manner:
“IXP is an organic evolution of XP.
It is imbued(inspired) with XP’s minimalist(keeping things simple),
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.
IXP
Readiness assessment.
Prior to the initiation of an IXP project, the organization should conduct a
readiness assessment.
The assessment ascertains(make sure) 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, and
(5) the broader project community will be populated appropriately.
IXP
Project community.
Classic XP suggests that the right people be used to populate the agile
team to ensure success.
The implication is that people on the team must be well-trained,
adaptable and skilled, and have the proper temperament(adjustment in
nature) to contribute to a self-organizing team.
When XP is to be applied for a significant project in a large organization,
the concept of the “team” should morph into that of a community.
A community may have a technologist and customers who are central to
the success of a project as well as many other stakeholders.
IXP
Project chartering(hire).
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.
Test-driven management establishes a series of measurable
“destinations” and then defines mechanisms for determining
whether or not these destinations have been reached.
IXP
Retrospectives.
An IXP team conducts a specialized technical review after a
software increment is delivered,
Called a retrospective, 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. Because 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.
IXP
In addition to the six new practices discussed, IXP modifies a number of
existing XP practices.
Story-driven development (SDD) insists that stories for acceptance tests be
written before a single line of code is generated.
Domain-driven design (DDD) is an improvement on the “system metaphor”
concept used in XP. DDD suggests the evolutionary creation of a domain
model .
Pairing extends the XP pair programming concept to include managers and
other stakeholders. The intent is to improve knowledge sharing among XP
team members who may not be directly involved in technical development.
Iterative usability discourages front-loaded interface design in favor of
usability design that evolves as software increments.
4 THE XP DEBATE
The issues that continue to trouble some critics of XP are,
• Requirements volatility- Because the customer is an active
member of the XP team, changes to requirements are requested
informally.
As a consequence, the scope of the project can change and earlier
work may have to be modified to accommodate current needs.
Proponents argue that this happens regardless of the process that
is applied and that XP provides mechanisms for controlling scope
creep.
XP DEBATE

• Conflicting customer needs. Many projects have multiple

customers, each with his own set of needs.
In XP, the team itself is tasked with assimilating(full understanding)
the needs of different customers.
• Requirements are expressed informally. User stories and
acceptance tests are the only explicit manifestation(fact) of
requirements in XP. Critics argue that a more formal model or
specification is often needed to ensure that omissions,
inconsistencies, and errors are uncovered before the system is
built.
XP DEBATE

• Lack of formal design. XP deemphasizes the need for

architectural design and in many instances, suggests that design of
all kinds should be relatively informal.
Critics argue that when complex systems are built, design must be
emphasized to ensure that the overall structure of the software will
exhibit quality and maintainability.
XP proponents suggest that the incremental nature of the XP
process limits complexity (simplicity is a core value) and therefore
reduces the need for extensive design.
OTHER AGILE PROCESS
MODELS
The most widely used of all agile process models is Extreme
Programming (XP). But many other agile process models have been
proposed and are in use across the industry. Among 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)
1.ASD
Adaptive Software Development (ASD) has been proposed by Jim
Highsmith as a technique for building complex software and
systems.
The philosophical underpinnings(ideas) of ASD focus on human
collaboration and team self-organization.
He defines an ASD “life cycle” that incorporates three phases,
speculation, collaboration, and learning.
ASD
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.
ASD
Collaboration is not easy.
It encompasses communication and teamwork, but it also
emphasizes individualism, because individual creativity plays an
important role in collaborative thinking.
It is, above all, a matter of trust.
People working together must trust one another to (1) criticize
without animosity(hatred), (2) assist without
resentment(displeasure), (3) work as hard as or harder than they
do, (4) have the skill set to contribute to the work at hand, and (5)
communicate problems or concerns in a way that leads to effective
action.
ASD
Learning will help to improve level of real understanding.
ASD teams learn in three ways: focus groups, technical reviews,
and project postmortem
ASD’s overall emphasis on the dynamics of self-organizing teams,
interpersonal collaboration, and individual and team learning, yield
software project teams that have a much higher likelihood of
success.
2 SCRUM
oScrum (the name is derived from an activity that occurs during a
rugby match) is an agile software development method that was
conceived by Jeff Sutherland and his development team in the early
1990s.
oIn recent years, further development on the Scrum methods has
been performed by Schwaber and Beedle.
oScrum principles incorporates the following framework activities:
requirements, analysis, design, evolution, and delivery.
oWithin each framework activity, work tasks occur within a process
pattern called a sprint.
SCRUM
Scrum emphasizes the use of a set of software process patterns .
Each of these process patterns defines a set of development actions:
Backlog—a prioritized list of project requirements or features that provide
business value for the customer.
Items can be added to the backlog at any time.
The product manager assesses the backlog and updates priorities as
required.
Sprints—consist of work units that are required to achieve a requirement
defined in the backlog that must be fit into a predefined time-
box(typically 30 days).
Changes are not introduced during the sprint.
SCRUM
oScrum meetings—are short (typically 15 minutes) meetings held
daily by the Scrum team. Three key questions are asked and
answered by all team members.
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?
oA team leader, called a Scrum master, leads the meeting and
assesses the responses from each person.
oThe Scrum meeting helps the team to uncover potential problems
as early as possible.
SCRUM
oAlso, these daily meetings lead to “knowledge socialization” and
thereby promote a self-organizing team structure.
oDemos—deliver the software increment to the customer so that
functionality that has been implemented can be demonstrated and
evaluated by the customer.
3 DYNAMIC SYSTEMS
DEVELOPMENT METHOD
(DSDM)
The Dynamic Systems Development Method (DSDM) is an agile
software development approach that “provides a framework for
building and maintaining systems which meet tight time constraints
through the use of incremental prototyping in a controlled project
environment” .
The DSDM philosophy is borrowed from a modified version of the
Pareto principle—80 percent of an application can be delivered in
20 percent of the time it would take to deliver the complete (100
percent) application.
DSDM is an iterative software process in which each iteration
follows the 80 percent rule.
DSDM
DSDM life cycle that defines three different iterative cycles,
preceded by two additional life cycle activities:
Feasibility study—establishes the basic business requirements and
constraints associated with the application to be built .
Business study—establishes the functional and information
requirements that will allow the application to provide business
value.
DSDM
Functional model iteration—produces a set of incremental
prototypes that demonstrate functionality for the customer. The
intent during this iterative cycle is to gather additional
requirements by eliciting feedback from users .
Design and build iteration—revisits prototypes built during
functional model iteration to ensure that it provide operational
business value for end users. In some cases, functional model
iteration and design and build iteration occur concurrently.
Implementation—places the latest software increment into the
operational environment.
It should be noted that (1) the increment may not be 100 percent
complete or (2) changes may be requested as the increment is put
into place..
4 CRYSTAL
Alistair Cockburn and Jim Highsmith created the Crystal family of
agile methods with a primary goal of delivering useful, working
software and a secondary goal of setting up software for the next
game.
It emphasizes maneuverability(easy to move) and adaptability in
software development.
Crystal methodologies have core elements common to all and
specific elements
unique to each.
They are designed to be selected based on the specific needs of a
project and its environment.
5 FEATURE DRIVEN
DEVELOPMENT (FDD)
Feature Driven Development (FDD) was originally conceived by Peter
Coad and his colleagues as a practical process model for object-oriented
software engineering.
Like other agile approaches, FDD adopts a philosophy that
(1) emphasizes collaboration among people on an FDD team;
(2) manages problem and project complexity using feature-based
decomposition followed by the integration of software increments, and
(3) communication of technical detail using verbal, graphical, and text-
based means.
FDD emphasizes software quality assurance activities by encouraging
an incremental development strategy.
FDD
In the context of FDD, a feature “is a client-valued function that can be
implemented in two weeks or less.” features provides the following benefits:
• Because features are small blocks of deliverable functionality, users can
describe them more easily; understand how they relate to one another more
readily; and better review them for ambiguity, error, or omissions.
• Features can be organized into a hierarchical business-related grouping.
• Since a feature is the FDD deliverable software increment, the team
develops operational features every two weeks.
• Because features are small, their design and code representations are
easier to inspect effectively.
• Project planning, scheduling, and tracking are driven by the feature
hierarchy, rather than an arbitrarily adopted software engineering task set.
6 LEAN SOFTWARE
DEVELOPMENT (LSD)
Lean Software Development (LSD) has adapted the principles of lean
manufacturing to the world of software engineering.
The lean principles include eliminating waste, build quality in, create
knowledge, defer commitment, deliver fast, respect people, and
optimize the whole.
eliminate waste within the context of an agile software project can be
interpreted to mean
(1) adding no extra features or functions,
(2) assessing the cost and schedule impact of any newly requested
requirement,
(3) removing any superfluous process steps,
LSD

(4) establishing mechanisms to improve the way team members

find information,
(5) ensuring the testing finds as many errors as possible,
(6) reducing the time required to request and get a decision that
affects the software or the process that is applied to create it, and
(7) streamlining the manner in which information is transmitted to
all stakeholders involved in the process.
AGILE MODELING (AM)
Scott Ambler describes agile modeling (AM) in the following
manner:
Agile Modeling (AM) is a practice-based methodology for effective
modeling and documentation of software-based systems.
Simply Agile Modeling (AM) is a collection of values, principles, and
practices for modeling software that can be applied on a software
development project in an effective and light-weight manner.
AGILE MODELING (AM)
The agile modeling philosophy recognizes that an agile team must
have the courage to make decisions that may cause it to reject a
design and refactor.
The team must also have the humility to recognize that
technologists do not have all the answers and that business experts
and other stakeholders should be respected and embraced.
AM suggests a wide array of “core” and “supplementary” modeling
principles, those that make AM unique are :
Model with a purpose. A developer who uses AM should have a
specific goal in mind before creating the model.
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.
Travel light. As software engineering work proceeds, keep only
those models that will provide long-term value. Every work product
that is kept must be maintained as changes occur.
Content is more important than representation. Modeling should
impart information to its intended 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.
8 AGILE UNIFIED PROCESS
(AUP)
The Agile Unified Process (AUP) adopts a “serial in the large” and
“iterative in the small” philosophy for building computer-based
systems.
The classic UP phased activities—inception, elaboration,
construction, and transition.
Each AUP iteration addresses the following activities:
• Modeling. UML representations of the business and problem domains are
created.
• Implementation. Models are translated into source code.
• Testing. Like XP, the team designs and executes a series of tests to uncover
errors and ensure that the source code meets its requirements.
• Deployment. focuses on the delivery of a software increment and the
acquisition of feedback from end users.
• Configuration and project management. In the context of AUP, configuration
management addresses change management, risk management, and the control
of any persistent work products that are produced by the team.
• Environment management. Environment management coordinates a process
infrastructure that includes standards, tools, and other support technology
available to the team
A TOOL SET FOR AGILE
PROCESS
Definition of Tools in Agile: Tools are defined as anything that facilitates the
work performed by an agile team member and enhances the quality of the end
product.
Types of Tools in Agile Teams:
 Social Tools:
o Starting from the hiring stage .
 Technological Tools:
o Help distributed teams simulate physical presence.
 Physical Tools:
o Used in workshops to manipulate information and coordinate
activities.
Examples of Tools:
 Hiring Tool: Pair programming sessions with prospective team members.
 Collaborative and Communication Tools:
o Low-tech mechanisms such as whiteboards, poster sheets, index
cards, and sticky notes.
o Active communication through team dynamics (e.g., pair
programming).
o Passive communication through "information radiators" (e.g., status
displays).
 Project Management Tools:
o Deemphasize Gantt charts in favor of earned value charts and
test
graphs.
o Optimize team environment, enhance team culture, and improve
processes (e.g., efficient meeting areas, electronic whiteboards,
collocated teams, pair programming, and time-boxing).
SOFTWARE ENGINEERING
KNOWLEDGE
Steve McConnell's editorial highlights the distinction between technology-
specific
knowledge and enduring software engineering principles.
1. Technology-Specific Knowledge:
o Software practitioners often focus on knowledge of specific
technologies (e.g., Java, Perl, C++, Linux).
o This knowledge is necessary for performing specific programming
tasks.
o Technology-related knowledge tends to have a short half-life (about 3
years), meaning it can become obsolete quickly.
2. Enduring Software Engineering Principles:
o McConnell argues that there is another type of knowledge, which
he
calls "software engineering principles."
o These principles do not have a short half-life and are likely to be
useful throughout a programmer's career.
o They form a stable core of knowledge essential for developing
complex systems.
3. Stable Core of Knowledge:
o By the year 2000, McConnell estimated that about 75 percent of
the
knowledge needed to develop a complex system resided within this
stable core.
o This core consists of fundamental principles that guide software
engineers in their work.
4. Application and Evaluation:
o The core principles provide a foundation from which software
engineering models, methods, and tools can be applied and
evaluated.
CORE PRINCIPLES
The core principles of software engineering are essential for both
the process and
practice levels, providing a foundation and guiding values for
effective
development.
Principles That Guide Process:
1. Be Agile:
o Emphasize simplicity and economy of action.
o Keep work products concise and make local decisions when
possible.
2. Focus on Quality at Every Step:
o Ensure every activity and task produces high-quality work
products.
3. Be Ready to Adapt:
o Adapt approaches based on constraints from the problem, people,
and
project.
4. Build an Effective Team:
o Focus on building a self-organizing team with mutual trust and
respect.
5. Establish Mechanisms for Communication and Coordination:
o Address management issues to ensure critical information is
shared
and coordinated effectively.
6. Manage Change:
o Establish formal or informal mechanisms to manage change
requests,
assessments, approvals, and implementations.
7. Assess Risk:
o Identify potential issues and establish contingency plans.
8. Create Work Products That Provide Value for Others:
o Produce only those work products that are necessary and
valuable for
subsequent process activities.
PRINCIPLES THAT GUIDE
PRACTICE
1. Divide and Conquer:
o Emphasize separation of concerns to simplify solving large
problems.
2. Understand the Use of Abstraction:
o Use abstractions to simplify complex elements, starting with high-
level models and refining to lower levels.
3. Strive for Consistency:
o Maintain consistency in requirements models, designs, source
codes,
and test cases for ease of use and understanding.
4. Focus on the Transfer of Information:
o Pay attention to the analysis, design, construction, and testing of
interfaces to ensure clear and accurate information flow.
5. Build Software That Exhibits Effective Modularity:
o Ensure modules are cohesive(fit together) in function, have low
coupling, and are
interconnected simply.
6. Look for Patterns:
o Utilize patterns to resolve recurring problems and create a shared
language for solutions and good architectural practices.
7. Represent the Problem and Its Solution from Different
Perspectives:
o Examine problems and solutions from multiple viewpoints (e.g.,
data-
oriented, function-oriented, behavioral) for greater insight and error
detection.
8. Remember That Someone Will Maintain the Software:
o Apply solid software engineering practices to facilitate future
maintenance activities such as corrections, adaptations, and
enhancements.
PRINCIPLES THAT GUIDE
EACH FRAMEWORK ACTIVITY
Before customer requirements can be analyzed, modeled, or
specified they must be gathered through the communication
activity.
Effective communication is among the most challenging activities
that you will confront(come to face). many of the principles apply
equally to all forms of communication that occur within a software
project.
Principle 1. Listen. Try to focus on the speaker’s words, rather than
formulating your response to those words. Ask for clarification if
something is unclear, but avoid constant interruptions. Never
become contentious in your words or actions (e.g., rolling your eyes
or shaking your head) as a person is talking.
Principle 2. Prepare before you communicate. Spend the time to
understand the problem before you meet with others. If necessary,
do some research to understand business domain. If you have
responsibility for conducting a meeting, prepare an agenda in
advance of the meeting.
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. For example, a participant may create a drawing or a
“strawman” document that serves as a focus for discussion.
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. Each small collaboration serves
to build trust among team members and creates a common goal for
the team.
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. The facilitator should keep the conversation
modular, leaving one topic only after it has been resolved (however, see
Principle 9)
Principle 8. If something is unclear, draw a picture. Verbal communication goes
only so far. A sketch or drawing can often provide clarity when words fail to do
the job
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. Communication, like any software
engineering activity, takes time. Rather than iterating endlessly, the people
who participate should recognize that many topics require discussion and that
“moving on” is sometimes the best way to achieve communication agility.
Principle 10. Negotiation is not a contest or a game. It works best
when both parties win. There are many instances in which you and
other stakeholders must negotiate functions and features,
priorities, and delivery dates. If the team has collaborated well, all
parties have a common goal. Still, negotiation will demand
compromise from all parties.
2 PLANNING PRINCIPLES
The communication activity helps you to define your overall goals
and objectives (subject, of course, to change as time passes).
However, understanding these goals and objectives is not the same
as defining a plan for getting there. The planning activity
encompasses a set of management and technical practices that
enable the software team to define a road map as it travels toward
its strategic goal and tactical objectives.
Principle 1. Understand the scope of the project. It’s impossible to
use a road map if you don’t know where you’re going. Scope
provides the software team with a destination.
Principle 2. Involve stakeholders in the planning activity.
Stakeholders define priorities and establish project constraints. To
accommodate these realities, software engineers must often
negotiate order of delivery, time lines, and other project-related
issues.
Principle 3. Recognize that planning is iterative. As work begins, it
is very likely that things will change. As a consequence, the plan
must be adjusted to accommodate these changes. In addition,
iterative, incremental process models dictate re planning after the
delivery of each software increment based on feedback received
from users.
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. If information is vague or unreliable, estimates will be
equally unreliable.
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. In addition, the project plan
(including the schedule) should be adjusted to accommodate the
likelihood that one or more of these risks will occur.
Principle 6. Be realistic. People don’t work 100 percent of every day.
Noise always enters into any human communication. Omissions
and ambiguity are facts of life. Change will occur. Even the best
software engineers make mistakes. These and other realities should
be considered as a project plan is established.
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. A “high-granularity” plan provides significant work task
detail that is planned over relatively short time increments (so that
tracking and control occur frequently). In general, granularity
moves from high to low as the project time line moves away from
the current date.
Principle 8. Define how you intend to ensure quality. The plan
should identify how the software team intends to ensure quality. If
technical reviews are to be conducted, they should be scheduled. If
pair programming is to be used during construction, it should be
explicitly defined within the plan.
Principle 9. Describe how you intend to accommodate change. Even
the best planning can be obviated by uncontrolled change. You
should identify how changes are to be accommodated as software
engineering work proceeds. For example, can the customer request
a change at any time? If a change is requested, is the team obliged
to implement it immediately? How is the impact and cost of the
change assessed?
Principle 10. Track the plan frequently and make adjustments as
required. Software projects fall behind schedule one day at a time.
Therefore, it makes sense to track progress on a daily basis, looking
for problem areas and situations in which scheduled work does not
conform to actual work conducted. When slippage is encountered,
the plan is adjusted accordingly.
3 MODELING PRINCIPLES
We create models to gain a better understanding of the actual
entity to be built.
In software engineering work, two classes of models can be
created: requirements models and design models.
Requirements models (also called analysis models) represent
customer requirements by depicting the software in three different
domains: the information domain, the functional domain, and the
behavioral 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
Scott Ambler and Ron Jeffries define a set of modeling principles that
are intended for those who use the agile process model but are
appropriate for all software engineers who perform modeling actions
and tasks:
Principle 1. The primary goal of the software team is to build software,
not create models. Agility means getting software to the customer in
the fastest possible time. Models that make this happen are worth
creating, but models that slow the process down or provide little new
insight should be avoided.
Principle 2. Travel light—don’t create more models than you need.
Every model that is created must be kept up-to-date as changes
occur. Therefore, create only those models that make it easier and
faster to construct the software
MODELING PRINCIPLES
Principle 3. Strive to produce the simplest model that will describe
the problem or the software. Don’t overbuild the software. By
keeping models simple, the resultant software will also be simple.
Principle 4. Build models in a way that makes them amenable to
change. Assume that your models will change, but in making this
assumption don’t get sloppy.
MODELING PRINCIPLES

Principle 5. Be able to state an explicit purpose for each model that

is created. Every time you create a model, ask yourself why you’re
doing so. If you can’t provide solid justification for the existence of
the model, don’t spend time on it.
Principle 6. Adapt the models you develop to the system at hand. It
may be necessary to adapt model notation or rules to the
application; for example, a video game application might require a
different modeling technique than real-time, embedded software
that controls an automobile engine.
MODELING PRINCIPLES
Principle 7. Try to build useful models, but forget about building
perfect models. When building requirements and design models, a
software engineer reaches a point of diminishing returns. That is,
the effort required to make the model absolutely complete and
internally consistent is not worth the benefits of these properties.
Principle 8. Don’t become dogmatic about the syntax of the model.
If it communicates content successfully, representation is
secondary. Although everyone on a software team should try to use
consistent notation during modeling, the most important
characteristic of the model is to communicate information that
enables the next software engineering task. If a model does this
successfully, incorrect syntax can be forgiven.
MODELING PRINCIPLES
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.
If you are an experienced software engineer, trust your instincts.
Software work teaches many lessons—some of them on a
subconscious level. If something tells you that a design model is
doomed to fail (even though you can’t prove it explicitly), you have
reason to spend additional time examining the model or developing
a different one
Principle 10. Get feedback as soon as you can. Every model should
be reviewed by members of the software team. The intent of these
reviews is to provide feedback that can be used to correct modeling
mistakes, change misinterpretations, and add features or functions
that were inadvertently omitted
REQUIREMENTS MODELING PRINCIPLES.

analysis methods are related by a set of operational principles:

Principle 1. The information domain of a problem must be
represented and understood. The information domain encompasses
the data that flow into the system, the data that flow out of the
system , and the data stores that collect and organize persistent
data objects.
REQUIREMENTS MODELING
PRINCIPLES.
Principle 2. The functions that the software performs must be
defined. Software functions provide direct benefit to end users and
also provide internal support for those features that are user
visible. Some functions transform data that flow into the system.
Principle 3. The behavior of the software (as a consequence of
external events) must be represented. The behavior of computer
software is driven by its interaction with the external environment.
Input provided by end users, control data provided by an external
system, or monitoring data collected over a network all cause the
software to behave in a specific way.
REQUIREMENTS MODELING
PRINCIPLES.
Principle 4. The models that depict information, function, and
behavior must be partitioned in a manner that uncovers detail in a
layered (or hierarchical) fashion. Requirements modeling is the first
step in software engineering problem solving. It allows you to
better understand the problem and establishes a basis for the
solution (design). A large, complex problem is divided into
subproblems until each subproblem is relatively easy to
understand. This concept is called partitioning or separation of
concerns, and it is a key strategy in requirements modeling
REQUIREMENTS MODELING
PRINCIPLES.
Principle 5. The analysis task should move from essential
information toward implementation detail. Requirements modeling
begins by describing the problem from the end-user’s perspective.
The “essence” of the problem is described without any
consideration of how a solution will be implemented. For example,
a video game requires that the player “instruct” its protagonist on
what direction to proceed as she moves into a dangerous maze.
DESIGN MODELING PRINCIPLES.

The software design model is analogous to an architect’s plans for a house.

It begins by representing the totality of the thing to be built (e.g., a three-
dimensional rendering of the house) and slowly refines the thing to provide
guidance for constructing each detail (e.g., the plumbing layout).
Some methods are data driven, allowing the data structure to dictate the
program architecture and the resultant processing components.
Others are pattern driven, using information about the problem domain (the
requirements model) to develop architectural styles and processing patterns.
Still others are object oriented, using problem domain objects as the driver
for the creation of data structures and the methods that manipulate them.
DESIGN MODELING PRINCIPLES.

Principle 1. Design should be traceable to the requirements model.

The requirements model describes the information domain of the
problem, user-visible functions, system behavior, and a set of
requirements classes that package business objects with the
methods that service them.
The design model translates this information into an architecture, a
set of subsystems that implement major functions, and a set of
components that are the realization of requirements classes.
The elements of the design model should be traceable to the
requirements model.
DESIGN MODELING PRINCIPLES.

Principle 2. Always consider the architecture of the system to be

built. Software architecture is the skeleton of the system to be built.
It affects interfaces, data structures, program control flow and
behavior, the manner in which testing can be conducted, the
maintainability of the resultant system, and much more. For all of
these reasons, design should start with architectural
considerations. Only after the architecture has been established
should component-level issues be considered
Principle 3. Design of data is as important as design of processing
functions. Data design is an essential element of architectural
design. The manner in which data objects are realized within the
design cannot be left to chance. A well-structured data design helps
to simplify program flow, makes the design and implementation of
software components easier, and makes overall processing more
DESIGN MODELING PRINCIPLES.
Principle 4. Interfaces (both internal and external) must be
designed with care. The manner in which data flows between the
components of a system has much to do with processing efficiency,
error propagation, and design simplicity. A well-designed interface
makes integration easier and assists the tester in validating
component 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.
The user interface is the visible manifestation of the software. No
matter how sophisticated its internal functions, no matter how
comprehensive its data structures, no matter how well designed its
architecture, a poor interface design often leads to the perception
that the software is “bad.”
DESIGN MODELING PRINCIPLES.
Principle 6. Component-level design should be functionally
independent. Functional independence is a measure of the “single-
mindedness” of a software component. The functionality that is
delivered by a component should be cohesive—that is, it should
focus on one and only one function or subfunction.5
Principle 7. Components should be loosely coupled to one another
and to the external environment. Coupling is achieved in many
ways— via a component interface, by messaging, through global
data. As the level of coupling increases, the likelihood of error
propagation also increases and the overall maintainability of the
software decreases. Therefore, component coupling should be kept
as low as is reasonable
DESIGN MODELING PRINCIPLES.
Principle 8. Design representations (models) should be easily
understandable. The purpose of design is to communicate
information to practitioners who will generate code, to those who
will test the software, and to others who may maintain the software
in the future. If the design is difficult to understand, it will not serve
as an effective communication medium
Principle 9. The design should be developed iteratively. With each
iteration, the designer should strive for greater simplicity. Like
almost all creative activities, design occurs iteratively. The first
iterations work to refine the design and correct errors, but later
iterations should strive to make the design as simple as is possible
4 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. In modern software engineering work, coding may be (1) the direct
creation of programming language source code (e.g., Java), (2) the automatic
generation of source code using an intermediate design-like representation of
the component to be built, or (3) the automatic generation of executable
code using a “fourth-generation programming language” (e.g., Visual C)
The initial focus of testing is at the component level, often called unit testing.
Other levels of testing include (1) integration testing (conducted as the
system is constructed), 2)validation testing that assesses whether
requirements have been met for the complete system (or software
increment), and (3) acceptance testing that is conducted by the customer in
an effort to exercise all required features and functions. The following set of
fundamental principles and concepts are applicable to coding and testing
CONSTRUCTION PRINCIPLES
Coding Principles. The principles that guide the coding task are
closely aligned with programming style, programming languages,
and programming methods. However, there are a number of
fundamental principles that can be stated:
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. • Select a 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
CONSTRUCTION PRINCIPLES
Programming 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.
CONSTRUCTION PRINCIPLES
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
CONSTRUCTION PRINCIPLES
Testing Principles. In a classic book on software testing, Glen Myers
states a number of rules that can serve well as testing objectives
• Testing is a process of executing a program with the intent of
finding an error. • A good test case is one that has a high
probability of finding an as-yet undiscovered error. • A successful
test is one that uncovers an as-yet-undiscovered error
These objectives imply a dramatic change in viewpoint for some
software developers. They move counter to the commonly held
view that a successful test is one in which no errors are found. Your
objective is to design tests that systematically uncover different
classes of errors and to do so with a minimum amount of time and
effort.
Davis suggests a set of testing principles
Principle 1. All tests should be traceable to customer requirements.
The objective of software testing is to uncover errors. It follows that
the most severe defects (from the customer’s point of view) are
those that cause the program to fail to meet its requirements
Principle 2. Tests should be planned long before testing begins. Test
planning can begin as soon as the requirements model is complete.
Detailed definition of test cases can begin as soon as the design
model has been solidified. Therefore, all tests can be planned and
designed before any code has been generated
Principle 3. The Pareto principle applies to software testing. In this context the
Pareto principle implies that 80 percent of all errors uncovered during testing
will likely be traceable to 20 percent of all program components. The problem, of
course, is to isolate these suspect components and to thoroughly test them.
Principle 4. Testing should begin “in the small” and progress toward testing “in
the large.” The first tests planned and executed generally focus on individual
components. As testing progresses, focus shifts in an attempt to find errors in
integrated clusters of components and ultimately in the entire system.
Principle 5. Exhaustive testing is not possible. The number of path permutations
for even a moderately sized program is exceptionally large. For this reason, it is
impossible to execute every combination of paths during testing. It is possible,
however, to adequately cover program logic and to ensure that all conditions in
the component-level design have been exercised.
5 DEPLOYMENT PRINCIPLES
Deployment activity encompasses three actions: delivery, support, and
feedback.
Because modern software process models are evolutionary or incremental
in nature, deployment happens not once, but a number of times as software
moves toward completion.
Each delivery cycle provides the customer and end users with an
operational software increment that provides usable functions and features.
Each support cycle provides documentation and human assistance for all
functions and features introduced during all deployment cycles to date.
Each feedback cycle provides the software team with important guidance
that results in modifications to the functions, features, and approach taken
for the next increment.
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. This
results in feedback that is not productive and ruins team morale.
Principle 2. A complete delivery package should be assembled and
tested. A CD-ROM or other media containing all executable
software, support data files, support documents, and other relevant
information should be assembled and thoroughly beta-tested with
actual users. All installation scripts and other operational features
should be thoroughly exercised in as many different computing
configurations as possible.
DEPLOYMENT PRINCIPLES
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. If support
is ad hoc, or worse, nonexistent, the customer will become
dissatisfied immediately. Support should be planned, support
materials should be prepared, and appropriate recordkeeping
mechanisms should be established so that the software team can
conduct a categorical assessment of the kinds of support requested
DEPLOYMENT PRINCIPLES
Principle 4. Appropriate instructional materials must be provided to
end users. The software team delivers more than the software
itself. Appropriate training aids (if required) should be developed;
troubleshooting guidelines should be provided, and when
necessary, a “what’s different about this software increment”
description should be published
Principle 5. Buggy software should be fixed first, delivered later.
Under time pressure, some software organizations deliver low-
quality increments with a warning to the customer that bugs “will
be fixed in the next release.” This is a mistake. There’s a saying in
the software business: “Customers will forget you delivered a high-
quality product a few days late, but they will never forget the
problems that a low-quality product caused them. The software
reminds them every day.”