SOFTWARE ENGINEERING

MODULE-1

1. AGILE DEVELOPMENT: What is Agility?

ANS. Agility, in the context of software development, refers to the ability to
respond swiftly and effectively to changing requirements and environments. It
emphasizes a flexible and collaborative approach that prioritizes customer
satisfaction and rapid delivery of functional software. This concept is
encapsulated in Agile methodologies, which advocate for iterative development
and continuous feedback.
Agility is characterized by several key principles:
Iterative and Incremental Development: Projects are divided into
smaller iterations, allowing teams to develop and deliver software in
manageable increments. This approach facilitates early detection of issues and
adjustments based on user feedback.
Customer Collaboration: Agile methodologies stress the importance of
ongoing communication with customers. This ensures that the development
process aligns closely with customer needs and expectations, fostering a more
user-centered approach.
Cross-Functional Teams: Agile promotes self-organizing teams that
encompass diverse skill sets. This encourages collaboration and enhances
problem-solving capabilities within the team.
Focus on Working Software: The primary measure of progress in Agile is
the delivery of functional software. This focus on tangible outputs helps teams
prioritize tasks that add real value.
Embracing Change: Agile methodologies are designed to accommodate
changes in requirements, even late in the development process. This flexibility
is crucial for adapting to evolving market conditions and user needs.
2. Agility and the cost of change.?
ANS. Agility in software development significantly impacts the cost of change,
primarily by allowing teams to adapt quickly to evolving requirements without
incurring prohibitive expenses. Traditional software development
methodologies often experience escalating costs as projects progress,
particularly when changes are requested late in the development cycle. This is
due to the need for extensive modifications, including architectural redesigns
and additional testing, which can lead to a nonlinear increase in costs.In
contrast, an agile process mitigates these costs through several key practices:
Incremental Delivery: Agile methodologies promote the release of software
in small, manageable increments. This allows teams to incorporate changes
more easily and reduces the overall impact of late-stage modifications.
Continuous Testing and Collaboration: Agile practices such as
continuous unit testing and pair programming further flatten the cost of change
curve. By continuously validating the software, teams can address issues as they
arise, minimizing the need for extensive rework later in the project.
Embracing Change: Agile principles advocate for welcoming changing
requirements, even late in development. This adaptability is crucial for
maintaining a competitive edge and ensuring customer satisfaction.
 3. What is an agile Process?
ANS. Agility in software development is characterized by its adaptability to
changing requirements and unpredictability inherent in most projects. Here are
the key assumptions and principles that define agile processes:
Key Assumptions of Agile Software Processes
 Unpredictable Requirements: It is challenging to foresee which
software requirements will remain stable and which will change, as well
as how customer priorities may shift during the project.
 Interleaved Design and Construction: Design and construction
activities should occur simultaneously, allowing design models to be
validated as they are created, rather than relying solely on pre-defined
designs.
 Planning Uncertainty: The phases of analysis, design, construction,
and testing are often unpredictable, necessitating a flexible approach that
can adapt to changes.
 Agility Principles
The Agile Alliance outlines 12 principles to achieve agility:
 Customer Satisfaction: Prioritize early and continuous delivery of
valuable software to satisfy customers.
 Embrace Change: Welcome changing requirements, even late in
development, to leverage changes for competitive advantage.
 Frequent Delivery: Deliver working software frequently, with a
preference for shorter timescales.
 Collaboration: Ensure daily collaboration between business
stakeholders and developers throughout the project.
 Motivated Teams: Build projects around motivated individuals,
providing them with the support and environment they need.
 Face-to-Face Communication: Use face-to-face conversation as the
most effective method of conveying information within a development
team.
 Working Software as Progress: Measure progress primarily
through the delivery of working software.
 Sustainable Development: Promote a sustainable pace of
development that can be maintained indefinitely by all stakeholders.
 Technical Excellence: Maintain continuous attention to technical
excellence and good design to enhance agility.
 Simplicity: Focus on simplicity, maximizing the amount of work not
done.
 Self-Organizing Teams: Allow the best architectures, requirements,
and designs to emerge from self-organizing teams.
 Reflect and Adjust: Regularly reflect on team performance and adjust
behaviors to improve effectiveness.
 4. Extreme Programming (XP). Other Agile Process Models, A Tool Set
for Agile Processes?
ANS. Extreme Programming (XP) is a prominent agile software development
methodology that emphasizes flexibility, customer involvement, and high-
quality output. It is designed to improve software quality and responsiveness to
evolving customer requirements. Below is a detailed overview of XP, other
agile process models, and tools that support agile processes.
1. Extreme Programming (XP)
Extreme Programming, introduced by Kent Beck in the 1990s, focuses on
enhancing software development practices to adapt to changing user needs. The
methodology is characterized by:
  Frequent Releases: XP advocates for short development cycles,
allowing teams to release functional software regularly. This approach
facilitates quick feedback from customers and the ability to adjust
features based on their input.
 Pair Programming: This practice involves two developers working
together at one workstation. One writes code while the other reviews it in
real-time, which enhances code quality and promotes knowledge sharing
within the team.
 Continuous Testing: Automated testing is integral to XP, ensuring
that all code is tested continuously. This helps identify defects early in the
development process, reducing the cost and effort required for later fixes.
 Customer Collaboration: XP emphasizes active customer
involvement throughout the development cycle. Regular feedback
sessions help ensure that the product meets user expectations and can
adapt to their changing requirements.
 Simplicity and Clarity: XP promotes the idea of keeping designs and
code as simple as possible. This approach reduces complexity and makes
it easier to implement changes.
 Overall, XP aims to create a responsive environment where teams can
deliver high-quality software that aligns closely with customer needs
while maintaining a sustainable work pace.

2. Other Agile Process Models

 Scrum
Scrum is a widely used agile framework that focuses on managing tasks within
a team-based development environment. It is structured around defined roles,
including the Scrum Master, who facilitates the process; the Product Owner,
who represents stakeholders and prioritizes the backlog; and the Development
Team, which is responsible for delivering the product. Work is completed in
time-boxed iterations called sprints, typically lasting two to four weeks. Each
sprint begins with a planning session and ends with a review and retrospective.
Scrum employs artifacts such as the Product Backlog, a prioritized list of
features, and the Sprint Backlog, which outlines the tasks to be completed in the
current sprint. This framework promotes regular communication, adaptability,
and iterative progress, making it suitable for projects with evolving
requirements.
 Extreme Programming (XP)

Extreme Programming (XP) emphasizes technical excellence and

customer satisfaction through specific practices. One of its key practices
is pair programming, where developers work in pairs to enhance code
quality and share knowledge. Continuous integration is another essential
aspect, ensuring that code changes are integrated and tested frequently,
which helps maintain the functionality of new features alongside existing
code. XP encourages active customer collaboration throughout the
development process, allowing teams to make quick adjustments based
on feedback. The methodology also promotes simplicity, advocating for
designs that meet current requirements while avoiding unnecessary
complexity. XP is particularly effective in projects characterized by high
uncertainty and frequent changes, enabling teams to adapt quickly to new
information.

 Feature-Driven Development (FDD)

Feature-Driven Development (FDD) focuses on delivering tangible,

working software features in a timely manner. The project is broken
down into a list of features, each representing a small, functional piece of
the software. FDD emphasizes creating a domain model to understand the
system's structure and relationships. Each feature is designed and built in
a structured manner, ensuring that the end product aligns with customer
requirements. This methodology is particularly effective for larger
projects where a clear structure and focus on features can enhance
delivery and quality.

 Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method (DSDM) is a framework that

emphasizes delivering software on time and within budget while
accommodating changing requirements. Active user involvement is a key
 feature, as users are engaged throughout the development process to
ensure that the product meets their needs. The methodology promotes
iterative development cycles, allowing for regular feedback and
adjustments. DSDM employs timeboxing to set fixed time periods for
development, ensuring that projects stay on track. This approach is
suitable for projects with moderate to high uncertainty, where user needs
may evolve over time.

 Crystal

Crystal is a family of agile methodologies that prioritize people and

interactions over processes and tools. It recognizes that different projects
require different approaches, allowing teams to select the most
appropriate methodology based on project size and complexity. Effective
communication and collaboration among team members are emphasized
to ensure project success. Like other agile methodologies, Crystal
promotes frequent delivery of functional software to gather feedback and
make adjustments. This approach is particularly beneficial for projects
with high uncertainty, where adaptability and team dynamics are crucial.

 Lean Software Development

Lean Software Development is derived from lean manufacturing

principles and aims to optimize efficiency and reduce waste. Its core
principles focus on eliminating waste by removing non-value-adding
activities from the development process. It emphasizes building quality
into every stage of development to reduce defects and rework.
Additionally, Lean Software Development aims for rapid delivery of
functional software to meet customer needs promptly. This methodology
is effective in enhancing efficiency and ensuring that development
processes are streamlined and focused on delivering value.

A Tool Set for Agile Processes

To support agile methodologies, various tools are available that facilitate
collaboration, project management, and continuous integration. Some key tools
include:
JIRA: A widely used project management tool that helps teams plan, track,
and manage agile software development projects. It supports Scrum and Kanban
methodologies, allowing teams to visualize their workflow and manage tasks
effectively.
Trello: A flexible, visual tool that uses boards and cards to organize tasks.
Trello is particularly useful for teams employing Kanban or similar
methodologies, as it allows for easy tracking of work in progress.
GitHub: A platform for version control and collaboration that enables teams
to manage code changes, conduct code reviews, and automate testing through
continuous integration pipelines.
Slack: A communication tool that facilitates real-time collaboration among
team members. Slack can integrate with other tools, providing a centralized
platform for discussions, updates, and notifications.
Jenkins: An open-source automation server that supports continuous
integration and continuous delivery (CI/CD). Jenkins helps automate the testing
and deployment of software, ensuring that code changes are integrated smoothly
and efficiently.

5. Principles that guide practice: Software Engineering Knowledge. Core

principles, Principles that guide each framework activity?
ANS. Software engineering is guided by several fundamental principles that help
ensure the development of high-quality, maintainable, and efficient software
systems. Below are key principles that shape software engineering practice,
each explained in detail.
Core Principles
Principles That Guide Process 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, and make decisions locally whenever possible.
2. Focus on quality at every step. The exit condition for every process activity,
action, and task should focus on the quality of the work product that has been
produced.
3. Be ready to adapt. Process is not a religious experience, and dogma has no
place in it. When necessary, adapt your approach to constraints imposed by the
problem, the people, and the project itself.
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.
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.
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.
7. Assess risk. Lots of things can go wrong as software is being developed. It’s
essential that you establish contingency plans.
8. Create work products that provide value for others. Create only those work
products that provide value for other process activities, actions, or tasks. Every
work product that is produced as part of software engineering practice will be
passed on to someone else. A list of required functions and features will be
passed along to the person (people) who will develop a design, the design will
be passed along to those who generate code, and so on. Be sure that the work
product imparts the necessary information without ambiguity or omission

Principles That Guide Practice Principle

1. Divide and conquer. Stated in a more technical manner,analysis and design
should always emphasize separation of concerns (SoC). A large problem is
easier to solve if it is subdivided into a collection of elements (or concerns).
Ideally, each concern delivers distinct functionality that can be developed, and
in some cases validated, independently of other concerns.
 2. Understand the use of abstraction. At its core, an abstraction is a
simplification of some complex element of a system used to communicate
meaning in a single phrase. When I use the abstraction spreadsheet, it is
assumed that you understand what a spreadsheet is, the general structure of
content that a spreadsheet presents, and the typical functions that can be applied
to it.
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 suggests that a familiar context makes software easier
to use. As an example, consider the design of a user interface for a WebApp.
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.
4. Focus on the transfer of information. Software is about information
transfer—from a database to an end user, from a legacy system to a WebApp,
from an end user into a graphic user interface (GUI), from an operating system
to an application, from one software component to another—the list is almost
endless. In every case, information flows across an interface, and as a
consequence, 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
5. Build software that exhibits effective modularity. Separation of concerns
establishes a philosophy for software.Modularity provides a mechanism for
realizing the philosophy. Any complex system can be divided into modules
(components), but good software engineering practice demands more.
 Modularity must be effective. That is, each module should focus
exclusively on one well-constrained aspect of the system—it should be
cohesive in its function and/or constrained in the content it represents.
Additionally, 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.
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.
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. For example, a requirements model can
be represented using a data oriented viewpoint, a function-oriented viewpoint,
or a behavioral viewpoint . Each provides a different view of the problem and
its requirements.
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. These
maintenance activities can be facilitated if solid software engineering practice is
applied throughout the software process

Principles that guide each framework activity

Communication Principles
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.
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.
3. Someone should facilitate the activity. Every communication meeting should
have a leader (a facilitator) to keep the conversation moving in a productive
direction, to mediate any conflict that does occur, and to ensure than other
principles are followed.
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.
5. Take notes and document decisions. Things have a way of falling into the
cracks. Someone participating in the communication should serve as a
“recorder” and write down all important points and decisions.
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.
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
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.
(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.
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.

Planning Principles 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
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.
3. Recognize that planning is iterative. A project plan is never engraved in
stone. 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 replanning after the
delivery of each software increment based on feedback received from users.
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.
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
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.
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 “highgranularity”
plan provides significant work task detail that is planned over relatively short
time increments (so that tracking and control occur frequently). A “low-
granularity” plan provides broader work tasks that are planned over longer time
periods
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.
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?
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.

Modeling Principles
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.
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 that might otherwise be spent on construction (coding and
testing). Therefore, create only those models that make it easier and faster to
construct the software.
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 (to change).
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. For
example, since requirements will change, there is a tendency to give
requirements models short shrift. Why? Because you know that they’ll change
anyway. 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.
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.
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.
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.
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.
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.

1. The information domain of a problem must be represented and understood.
The information domain encompasses the data that flow into the system (from
end users, other systems, or external devices), the data that flow out of the
system (via the user interface, network interfaces, reports, graphics, and other
means), and the data stores that collect and organize persistent data objects (i.e.,
data that are maintained permanently).
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.
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.
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). Complex problems are difficult to solve in their
entirety. For this reason, you should use a divide-and-conquer strategy.
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. That is the essence of
the problem.

Design Modeling Principles.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.
Validation Principles:
After you’ve completed your first coding pass, be sure you
• Conduct a code walkthrough when appropriate.
• Perform unit tests and correct errors you’ve uncovered.
• Refactor the code.

Testing Principles.
 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.

Deployment Principles
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.

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

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.

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

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