`

• In conventional software development the cost of change increases nonlinearly as a

project progresses (Figure : solid black curve).
• Suppose the team is 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 new components, modifications to the design of new tests, and
so on.
• Costs escalate quickly and the time and cost required.
• Agile process “flattens” the cost of change curve (Figure : shaded, solid curve),
allowing a software team to accommodate changes without dramatic cost and time
impact.
• agile process encompasses incremental delivery.
• incremental delivery is coupled with other agile practices such as continuous unit
testing and pair programming the cost of making a change is attenuated.

Agile software process 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. 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. That is, both
activities should be performed in tandem so that design models are proven as they are
created. 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.

• An agile software process must adapt incrementally. To accomplish incremental

adaptation,
• an agile team requires customer feedback.
• An effective catalyst for customer feedback is an operational prototype or a portion of an
operational system.
• Hence, an incremental development strategy should be used.
• Software increments (executable prototypes or portions of an operational system) must
be delivered in short time periods so that adaptation keeps pace with change
(unpredictability).
The Agile defines 12 agility principles for those who want to achieve agility:
 • “Agile development focuses on the talents and skills of individuals, molding the
process to specific people and teams.”
• a number of key traits must exist among the people on an agile team and the team itself.

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.

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.

Collaboration - Software engineering 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. 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 team exhibits the trust and respect that are
necessary to make them strong.

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.

most widely used approach to agile software development.

• defines a set of five values that establish a foundation for all work performed as part of
XP—communication, simplicity, feedback, courage, and respect.
• To achieve effective communication between software engineers and other
stakeholders XP emphasizes verbal collaboration between customers and developers.
• To achieve simplicity, XP restricts developers to design only for immediate needs, rather
than consider future needs.
• Feedback is derived from three sources: the implemented software itself, the
customer, and other software team members the software (via test results) provides
the agile team with feedback.
• XP makes use of the unit test as its primary testing tactic.
• strict adherence to certain XP practices demands courage. A better word might be
discipline.
• By following each of these values, the agile team inculcates respect among its
members, between other stakeholders and team members.

• Development occurs within the context of four framework activities: planning, design,
coding, and testing.
 Planning. 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.
• 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 (similar to use cases) 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.
• 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.
• Once a basic commitment (agreement on stories to be included, delivery date, and other
project matters) is made for a release.
• 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.
• After the first project release (also called a software increment) has been delivered, the
XP team computes project velocity.
• 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.
• As development work proceeds, the customer can add stories, change the value
of an existing story, split stories, or eliminate them.
 Design. XP design rigorously follows the KIS (keep it simple) principle. A simple
design is always preferred over a more complex representation.
• XP encourages the use of CRC cards as an effective mechanism for thinking about the
software in an object-oriented context.
• CRC (class-responsibility collaborator) cards identify and organize classes that are
relevant to the current software increment.
• If a difficult design problem is encountered, XP recommends the immediate creation of
an operational prototype of that portion of the design. This is called a spike solution
• A central notion in XP is that design occurs both before and after coding commences.
Refactoring means that design occurs continuously as the system is constructed.

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 (software increment).
• Once the code is complete, it can be unit-tested immediately, thereby providing
instantaneous feedback to the developers.
• key concept during the coding activity is pair programming
• 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.
• As pair programmers complete their work, the code they develop is integrated with the
work of others.

Testing. creation of unit tests before coding commences is a key element of the XP
approach.
• Encourages a regression testing strategy whenever code is modified.
• Integration and validation testing of the system can occur daily.
• XP acceptance tests, also called customer tests, are specified by the customer and
focus on overall system features and functionality.

• 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
1. Readiness assessment.
2. Project community
3. Project chartering
4. Test-driven management.
5. Retrospectives.
6. Continuous learning
 1. 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, and
(5) the broader project community will be populated appropriately.

2. Project community
• Classic XP suggests that the right people be used to populate the agile team to ensure
success.
• The people on the team must be well-trained, adaptable and skilled, and have the
capability to contribute to a self-organizing team.
• 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)
3. Project chartering
• Chartering also examines the context of the project to determine how it complements,
extends, or replaces existing systems or processes.

4. Test-driven management
• An IXP project requires measurable criteria for assessing the state of the project and
the progress that has been made to date.
5. Retrospectives
• An IXP team conducts a specialized technical review after a software increment is
delivered. Called as retrospective.
6. 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.

Among 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.
• Consequently, the scope of the project can change, and earlier work may have to be
modified to accommodate current needs.
Conflicting customer needs:
• Many projects have multiple customers, each with his own set of needs. In XP, the
team itself is tasked with assimilating the needs of different customers, a job that may be
beyond their scope of authority.
Requirements are expressed informally:
• User stories and acceptance tests are the only explicit manifestation of requirements
in XP.
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.

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) has been proposed by Jim Highsmith [Hig00] as
a technique for building complex software and systems.
• ASD focus on human collaboration and team self-organization.
• ASD “life cycle” (Figure 3.3) that incorporates three phases,
• speculation
• collaboration
• learning
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)
• Based on information obtained at the completion of the first cycle, the plan is reviewed
and adjusted so that planned work better fits the reality.

Collaboration:
• It encompasses communication and teamwork, but it also emphasizes individualism,
because individual creativity plays an important role in collaborative thinking.
• People working together must trust one another to
 (1) criticize without animosity (means no hatred)
(2) assist without resentment (means no anger)
(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.

Learning:
• ASD teams learn in three ways: focus groups, technical reviews, and project postmortems.
• learning will help them to improve their level of real understanding.
• ASD’s overall emphasis on the dynamics of self-organizing teams, interpersonal
collaboration, and individual and team learning yields success.
• Scrum principles are consistent with the agile development activities within a process that
incorporates the following framework activities: requirements, analysis, design, evolution,
and delivery.
• Sprint - framework activity, in which work tasks occur within a process pattern called a
sprint.
• Figure 3.4 illustrates the overall flow of the Scrum process.
• Scrum emphasizes the use of a set of software process patterns.
• They are effective in projects with tight timelines, changing requirements, and business
criticality.
• 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 (this is how changes are introduced).
• 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 (e.g., backlog work items) are not introduced during the sprint. Hence, the
sprint allows team members to work in a short-term.
Scrum 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?
• team leader, called a Scrum master, leads the meeting and assesses the responses
from each person.
• The Scrum meeting helps the team to uncover potential problems as early as possible.
Demos—
• deliver the software increment to the customer so that functionality that has been
implemented can be demonstrated and evaluated by the customer.

• DSDM life cycle 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
• Assesses whether the application is suitable for the DSDM process.
Business study:
• defines the basic application architecture and identifies the maintainability
requirements for the application.
Functional model iteration:
• produces a set of incremental prototypes that demonstrate functionality for the
customer.
• The intent is to gather additional requirements by eliciting feedback from users as
they exercise the prototype.
Design and build iteration:
• revisits prototypes built during functional model iteration to ensure that each has
been engineered to provide operational business value for end users.
Implementation:
• places the latest software increment into the operational environment.
 • The name “crystal” is derived from the characteristics of geological crystals, each with its
own color, shape, and hardness.

Maneuverability means -“the action of cleverly planning something to get an advantage”

• The Crystal family is actually a set of example agile processes that have been proven
effective for different types of projects.
• The intent is to allow agile teams to select the member of the crystal family that is most
appropriate for their project and environment.

• Feature Driven Development (FDD) is a practical process model for object-oriented

software engineering.
• In the context of FDD, a feature “is a client-valued function that can be implemented in
two weeks or less”.
• Coad suggest the following template for defining a feature:

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

where an <object> is “a person, place, or thing (including roles, moments in time or

intervals of time, or catalog-entry-like descriptions).”

Examples of features for an e-commerce application might be:

Add the product to shopping cart
Display the technical specifications of the product
Store the shipping-information for the customer
A feature set groups related features into business-related categories and is defined

<action><-ing> a(n) <object>

For example: Making a product sale is a feature

• The FDD approach defines five “collaborating” framework activities (in FDD these are
called “processes”) as shown in Figure 3.5.
• FDD defines six milestones during the design and implementation of a feature: “design
walkthrough, design, design inspection, code, code inspection, promote to build”.
Model with a purpose. A developer who uses AM should have a specific goal (e.g., to
communicate information to the customer or to help better understand some aspect of the
software) in mind before creating the model.

Use multiple models. There are many different models and notations that can be used to
describe software. AM suggests that to provide needed insight, each model should present a
different aspect of the system.

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. A model that imparts little useful content is not as valuable as a model with
flawed that provides valuable content.

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.
Many software practitioners think of software engineering knowledge almost exclusively as
knowledge of specific technologies: Java, Perl, html, C, Linux, Windows NT, and so on. Knowledge
of specific technology details is necessary to perform computer programming. If someone
assigns you to write a program in C, you have to know something about C to get your program to
work.
In the domain of technology-related knowledge, there is another kind of software development
knowledge—a kind of “software engineering principles”. These software engineering principles
are likely to serve a professional programmer throughout his or her career.
core principles—the elemental ideas that guide software engineers in the work that they do and
provide a foundation from which software engineering models, methods, and tools can be
applied and evaluated.

Software engineering is guided by a collection of core principles that help in the application of a
meaningful software process and the execution of effective software engineering methods.
At the process level, core principles establish a philosophical foundation that guides a software
team as it performs framework and umbrella activities, navigates the process flow, and produces
a set of software engineering work products.
At the level of practice, core principles establish a collection of values and rules that serve as a
guide as you analyze a problem, design a solution, implement and test the solution, and ultimately
deploy the software in the user community.

Principle 1. Be agile.

• Whether the process model you choose is prescriptive or agile, the basic tenets of agile
development should govern your approach.
• Every aspect of the work you do should emphasize economy of action—keep your
technical approach as simple as possible, keep the work products you produce as
concise as possible.
Principle 2. Focus on quality at every step.

• 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.

• 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.
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.
• These are management issues, and they must be addressed.
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.
• Be sure that the work product imparts the necessary information without ambiguity or
omission.

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.
 • Ideally, each concern delivers distinct functionality that can be developed, and in some
cases validated, independently of other concerns.
Principle 2. Understand the use of abstraction.

• Abstraction is a simplification of some complex element of a system used to

communicate meaning in a single phrase.
• In software engineering practice, we use many different levels of abstraction, each
imparting or implying meaning that must be communicated.
• In analysis and design work, a software team normally begins with models that
represent high levels of abstraction and slowly refines those models into lower levels of
abstraction.
Principle 3. Strive for consistency.

• Whether it’s creating a requirements model, developing a software design, generating

source code, or creating test cases, the principle of consistency makes software easier
to use.
• Consistent placement of menu options, the use of a consistent color scheme, and the
consistent use of recognizable icons all help to make the interface ergonomically
sound.
Principle 4. Focus on the transfer of information.

• information flows across an interface, and therefore, there are opportunities for error, or
omission, or ambiguity.
• The implication of this principle is that you must pay special attention to the analysis,
design, construction, and testing of interfaces.
Principle 5. Build software that exhibits effective modularity.

• Modularity provides a mechanism for realizing philosophy. Any complex system can be
divided into modules (components).
• Modularity must be effective. Modules should be interconnected in a relatively simple
manner—each module should exhibit low coupling to other modules, to data sources,
and to other environmental aspects.
Principle 6. Look for patterns.

• 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.
• Patterns help create a shared language for communicating insight and experience
about these problems and their solutions.
Principle 7. When possible, represent the problem and its solution from a number of
different perspectives.

• When a problem and its solution are examined from a number of different perspectives,
it is more likely that greater insight will be achieved, and that errors and omissions will
be uncovered.
Principle 8. Remember that someone will maintain the software.

• Over the long term, software will be corrected as defects are uncovered, adapted as its
environment changes, and enhanced as stakeholders request more capabilities.

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 jargon.
• 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 that 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.

• Collaboration and consensus occur when the collective knowledge of members of the
team is used to describe product or system functions or features.
• 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.
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.
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.

• Software engineers must often negotiate order of delivery, timelines, and other project-
related issues.
Principle 3. Recognize that planning is iterative.

• It is very likely that requirements will change. Therefore, the plan must be adjusted to
accommodate these changes.
• In addition, iterative, incremental process models dictate replanning 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 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.
• A “low-granularity” plan provides broader work tasks that are planned over longer time
periods. 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.
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.
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.

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.
• 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.

• More importantly, every new model takes time spent on construction (coding and testing).
Therefore, create only those models that make it easier and faster to construct the
software.
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. The result is
software that is easier to integrate, easier to test, and easier to maintain.
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. The
problem with this attitude is that without a reasonably complete requirements model, you’ll
create a design (design model) that will invariably miss important functions and features.
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.
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.
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.

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).
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.

• 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.
Principle 1. Customer expectations for the software must be managed.

• 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.
• A software engineer must be careful about sending the customer conflicting messages.

Principle 2. A complete delivery package should be assembled and tested.

• A CD-ROM or other media (including Web-based downloads) 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 (i.e., hardware, operating systems, peripheral
devices, networking arrangements) as possible.
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 record
keeping mechanisms should be established so that the software team can conduct a
categorical assessment of the kinds of support requested.
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.”